[buug] Buug Digest, Vol 50, Issue 12

[Rick Moen]

Quoting Jeff Anderson-Lee (jonah at eecs.berkeley.edu):

> That does not often work in research computing.  I want to use Linux,  
> but it's a struggle to do so some times without paying for Red Hat  
> Enterprise.

Well, if you actually need the latest and greatest hardware, then that's
a hard requirement.  Most of the time, it's not.

In particular, people new to Linux often assume that you need grossly
overpowered CPUs and gobs of RAM, thus requiring cutting-edge gear.
Even when I'm not merely being cheap, my Linux gear is always based on
chipsets that have been on the market a minimum of 1-2 years.

Thus, if I were looking to get a replacement laptop, my preferred choice
would be a Thinkpad T42 or T42p, which is several models obsolete, but
still really good and an enormously satisfactory Linux machine.


But, anyway, I'm a little puzzled by your reference to RHEL, because in
my experience that distro's vendor kernel and installer often has real
problems on some recently introduced hardware chipsets.  One of my
recent long-term gigs was as the sole guy in charge of Linux hardware
certification for a very large EDA firm:  Vendors would ship the firm
their eval units, and they'd get dropped off at my lab.  It was my task
to recommend or disrecommend their purchase for upcoming quarters.

First thing I'd always do is boot a recent Sidux live CD, because _that_
would reliably figure out all hardware.  That, in turn let me probe the
machine's hardware inventory using lspci, "dmesg | more", /proc/cpuinfo, 
/proc/meminfo, and so on.  I would capture all those details on the
intranet wiki, then finally _try_ the various enterprise distros the
firm used (various levels of RHEL3, 4, and 5, SLES9 and 10 with sundry
service packs).  

It was fairly common for some and in some cases all of the RHEL
installations to be problematic on hardware-support grounds.  Most
common problem was newly-introduced integrated Broadcom NICs.  ACPI 
problems were also very common.  

Sometimes, those problems could be gotten around by playing with kernel
parameters (noapic, nolapic, noacpi, etc.)  Sometimes, the only feasible
workaround was turning off the problematic onboard component and
installing a PCI-E add-on card.