[sf-lug] My latest NUC adventure

Rick Moen rick at linuxmafia.com
Thu Jul 18 13:36:53 PDT 2019


Quoting Akkana Peck (akkana at shallowsky.com):

> Of course, I want hardware virtualization support, and I've been
> burned before when a supposedly snazzy CPU turned out not to have
> it. If I google a CPU and find a page like this
> https://ark.intel.com/content/www/us/en/ark/products/95443/intel-core-i5-7200u-processor-3m-cache-up-to-3-10-ghz.html
> are these the only flags I need to look for?
>   Intel Virtualization Technology (VT-x)
>   Intel Virtualization Technology for Directed I/O (VT-d)

Please pardon my quoting a 2007 mailing list post in which I addressed 
this point:

  Here's something that you're well advised to try on new-ish
  CPUs, preferably before buying:

  Boot a Linux live CD, then check the CPU flags line in /proc/cpuinfo.
  We're checking for two things:  (1) x86_64 support.  (2) virtualisation
  support.

  The virtualisation information won't be accurate unless your kernel
  revision is at least 2.6.15 for Intel CPUs,or 2.6.16 for AMD ones.

  o  Flag "lm" (long mode" proves that the CPU is x86_64-capable.
  o  Flag "vmx" on Intel CPUs or "svm" on AMD CPus proves full
  virtualisation.

  Full hardware support for (Xen, KVM) virtualisation requires that the
  CPU support the "VT" instruction extensions on Intel, or the equivalent
  "SVM" (aka "AMD-V") extensions on AMD.

  In 2007, I would not buy an x86 CPU failing either of those two
  criteria.  That is, I'd made sure /proc/cpuinfo showed _both_ "lm" and
  also either "vmx" or "svm".




> Should bugs like Spectre/Meltdown be a consideration?
> I'm guessing no, since 7th and 8th generation Intel CPUs are what
> I'm seeing in current laptops, and it looks like even most 9th gen
> CPUs don't have protection against those bugs.

{shrug}  If you get a vulnerable CPU, the only thing you can do is rely
on mitigations from the kernel developers, anyway.  The smart money
holds that we've not heard the last of security problems resulting from
predictive execution, so my view is you're going to have some variant of
that problem with any x86_64 CPU of recent vintage -- in the case of the
very latest generations, predictive execution bugs not yet known (at
least by the general public).



> For sure. I was all hot for the Dell XPS 13, which everybody seems
> to love. Then I googled wi-fi chipsets and found that the current
> XPS 13 uses a wi-fi card called a "Killer 1435", which is some kind
> of modified Broadcom card (ugh), and it works fine for some Linux
> users and not at all for others. And in the last 2-3 years Dell
> started *soldering it in* so it's not even replaceable like it was
> on earlier models.

Ugh!  Yes, the prior convention of putting the damned thing on a miniPCI
board used to be the saving grace:  If you got a clunker, you could just
write it off to Dell 'chipset du jour' syndrome and pick up a good
Intel-type replace card for cheap.

One of the reasons I am a bit wary of Dell is that, when you least
expect it, they switch a key component to a problematic and usually
brand-new chipset (because they could get it cheaper), and/or make dumb
moves like making subassemblies soldered-on (again, because it's
cheaper).  People who've drunk the Dell Kool-Aid forget (or never knew)
that Michael Dell built the company by price-undercutting Compaq by
using cut-rate and ever-changing parts.

Anyway, there's really no substitute for test-booting the specific unit
you hope to buy on a live distro, and running 'lspci', etc., to make
sure about the chipsets.



> > Always handy:  https://www.linux-on-laptops.com/
> 
> That used to be a great resource, but it looks like it's mostly
> bitrotted. It doesn't have any of the models I'm considering, and
> when I clicked on entries for much older but similar models, almost
> every page was gone, except for one page in Russian.

Obviously that can and will happen on a site that merely links to
individuals' write-ups on their own Web sites.

Where that page is 'gone', it's gone because the individual who created
and hosted it ceased using that hosting or moved/renamed the page and
neither updated the www.linux-on-laptops.com entry nor made sure the old
URL had an HTTP 302 referral handler.

If you want to help the www.linux-on-laptops.com site, whenever you find
a page of interest is 'gone', see if you can find it at a new URL or via
Internet Archive, and submit a URL revision if you find it.  If you
cannot find even an Internet Archive-cached version, send feedback to 
www.linux-on-laptops.com's maintainers that the specific page is broken
and has no replacement.

That's the only way this community resource works.  And, if you do get a
new laptop and install Linux on it, please consider creating a write-up 
page and submitting it.

www.linux-on-laptops.com still links to my 2004 write-up about a
now-ancient Dell Inspiron 7000:
http://linuxmafia.com/~rick/inspiron7000.html



> In theory I like the idea of buying from vendors that support Linux.

Call me a cynic, but I greatly question what 'support' means in this
context.   (In IT, the term 'support' has decades of history having
vague and doubtful meaning, generally.)

Does 'support Linux' merely mean 'made sure there is some driver for all
the chipsets'?  If so, that arguably has some tiny amount of value,
except that such vendors in the past have often claimed all the hardware
'has Linux support', but upon examination it turns out that some of the
chipsets work at all, or work reasonably, only with a proprietary
binary-only driver that's normally available only direct from
manufacturer download, cannot be lawfully distributed by distros, and
is prone to be broken by kernel upgrades.

For example (speak of the Devil), back around 2000, Dell used to
'support Linux' by offering Red Hat Linux preloads on specific models
(at a surcharge over having an MS-Windows preload), and their
documentation claimed all the hardware was 'fully Linux supported', but
this included a winmodem that worked only with a manufacturer-issued
binary-only driver that functioned only on 2.2.x kernel.  If the user
tried to load Red Hat Linux from normal images, the winmodem's 'full
Linux support' vanished until the user chased down and retrofitted the
proprietary driver.  Then, once 2.4 kernels replaced 2.2 ones, oops, not
even that worked any more.

Does 'support Linux' mean helping Linux in any way?  If so, I've never
seen any giveback to Linux of any value from such a vendor.

Does 'support Linux' mean merely they offer whatever's the popular
distro du jour as a preload?  If so, first, I probably want a different
distro, and I'm going to want to install it in my own way.  So, given
that I'm going to blow away anything that's preloaded, why would I
particularly like the idea of the preload being one thing I'm going
to blow away versus another?  I don't -- and I really don't appreciate
there being a price premium (as there usually is) for the thing I'll
blow away being Linux.

Last, the hardware from these Linux-specialty hardware OEMs tends not to
be best of breed.  I.e., one can do substantially better, and for less
money, from non-specialty vendors.

But Views Differ.[tm]




More information about the sf-lug mailing list