l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Dec 11 10:15

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox] Choosing hardware for Linux
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox] Choosing hardware for Linux

This is a letter I wrote to Rick Moen, and since the information is helpful
to me,
I decided to try posting it. Anyone with pertinent hardware suggestions is
welcome to jump in on the conversation!
Being a Complete Newbie, I am not too clear on this messageboard, or email
or whatever this list is, but, hope it comes through okay, O.
My part of the conversation has:   ">" in front of it.
Rick's answers are without the ">"

> Rick, I, like George Tranter, am interested in the efficacy of using
> with  Linux. Probably  the Mandrake, perhaps red hat?

That's a matter of taste.  Mandrake is a very "desktop" oriented
distribution.  Red Hat splits the difference between that and server
orientation  (though their 8.0 default desktop has many fans, because
it's  simplified and clean if somewhat boring).

> I prefer AMD to Pentium, if I were to put a little box together, what
> would  you suggest buying?

I sympathize with people wanting to pick components like that, because
I'd probably want to do the same.  You'll have the best luck if you
really know hardware well, and can select parts carefully rather than
buying stuff just because vendors have them in stock and suggest them to
you.  Unfortunately, most people really _don't_ know hardware, and end
up basically buying what the vendors want to sell today.

The best hardware is stuff that's been out for at least a year, that's
standard and fairly good quality but not expensive specialty gear, and
that uses technologically superior, simple hardware interfaces.

Thus, one keeps USB and firewire to the bare minimum, one avoids
internal or USB modems, one avoids parallel-port devices other than
printers, and one avoids newly-introduced _or_ exotic _or_ bottom-end
chipsets like the plague.

> I had terrible driver problems with Linux Mandrake on an AMD k7 with
> creative sound card, modem, and usb mouse.

Sorry to hear.  The Soundblaster Live card had driver problems early in
the 2.4.x kernel series, but is said to be better now.  Me, I'm lucky
enough to have a bunch of really _old_ Soundblaster cards around, such
as the SB AWE 64 and AWE 32 PCI cards, and even the ol' reliable SB 16
ISA cards.  It's always great to keep classic, reliable cards around,
and I'd even be tempted to buy them at used computer-parts stores.

Classic cards include:
Matrox G400 and G200 video cards
SoundBlaster AWE64, AWE32, and SB16 cards.
3Com 3C905 and 3C905B PCI ethernet cards.
NetGear PCI ethernet cards with genuine Digital Equipment Corp.  chipsets.
Adaptec 294x series PCI and 154x series ISA SCSI host adapters.

The classic modem is US Robotics V.Everything _external_.  A close
second would be most (not all) US Robotics Sportster _external_ modems.

The classic mouse would be any 3-button PS/2-port mouse.  I'm most fond
of the ones made by Logitech, such as the Trackman Marble trackball, but
many people really love Microsoft's, including various models of the
Intellimouse series.  (Me, I don't like those.)

The classic keyboard would be an IBM Model M, either PS/2 or AT-type
(depending on which your machine uses, though there are also adapters).
If those are too "clicky" for your taste, look for a Keytronics.

Classic RAM is Micron or Mushkin SDRAM -- preferably Mushkin.

Notice that the above list includes no USB.  USB is a great idea, but
there are just a lot of problems with it on Linux, it seems.  It's
inescapable on digital cameras (unless you want to try firewire, which
is often even more problematic), and almost inescapable on scanners,
unless you use SCSI-type flatbed scanners -- which I personally would
insist on, most likely.

> I read that the hardware manufacturers are proceeding to create new
> hardware, which will NOT run Linux.

So, if it'll help, here's my list of places to check Linux support for
just about any hardware you might be curious about:


> Have not used Gimp much, and was not impressed with the quality of the
> graphics but do not know enough to judge it before it totally crashed
> on my Maxtor hard drive. Btw, is it better to run it on my IBM hard
> drive? Or, does it not matter?

Shouldn't really matter.

As a graphics person, you honestly do have an incentive to use MacOS X,
mostly because of all the very mature and professional (if expensive)
software available there, and the fact that basically _all_ of Apple's
hardware is suitable for professional graphics work, whereas you have to
be very selective on i386.

> If YOU were putting  a  box together, what would YOU use?

And this is of course what you are most interested in hearing -- but I'm
obliged in all honesty to admit that my information on new, current
hardware choices isn't up to date, any more.

The last time I had to build up a machine from components, Athlons were
just introduced to the market.  So, following my own criteria, I went
with a K6/233 (best value at that time), instead.  And the great thing
is, that's still a pretty fast machine with Linux, because most things
you're trying to do on Linux is _not_ CPU-intensive.  Of course, some
things are CPU-intensive, and GIMP can be one of them.

Anyhow, I'm lucky in that I received a fair amount of great-with-Linux
hardware when my former employer exited from the hardware business.  So,
I have a number of dual-PIII and PII 2U-format rackmount servers, one of
which runs my domain (linuxmafia.com) from my living room.  And so, I've
not been in the hardware market for quite some time.

Therefore, you can't really trust any specific advice I might give you
about current hardware -- because I'm not familiar enough with it.  My
silly-wild-assed-guess is that I'd look for an Athlon system rather than
PIII or P4.  I personally prefer SCSI over IDE, and like to split disk
activity between two physical hard disks.  (If you use IDE, make sure
that, if you have two hard drives, you put them on different IDE
chains.)  I'd probably use one of the ATI Radeon models, rather than
NVIDIA.  (ATI have been a bit more cooperative with the open-source
community than NVIDIA have, but the technical differences isn't very

I'd probably read on-line materials such as Tom's Hardware Guide and
similar places -- but don't forget that they typically have biases
inherent in their Microsoft-centrism, such as an obsession with faster
CPUs than would be required on a reasonable OS.  The idea is to read
extensively and skeptically, and then try to find quality components
that have been on the market long enough that glitches have probably
been ironed out.

And then, of course, you have to configure the components and the BIOS
ROMs properly.  If you're not good at this, it can be a problem area.

I hope that helps.  Please consider posting on-list in the future, since
I would much rather post there to benefit the community more
efficiently.  You're welcome to try my user group's (CABAL's, in Menlo Park,
near Stanford U.):

Cheers,                    Long ago, there lived a creature with a
Rick Moen                  voice like a vacuum cleaner.  We know little
rick@linuxmafia.com        about it, but we do know that it ate cats.


> I could post your entire answer on the vox as well as your reference page,
> I like it because it leaves out my stuff [grin].

You may if you wish, but I hope you'll become less shy in the future.
Nobody's going to bite, y'know.

> Interesting on the firewire and USB stuff. Gosh, with Apple, you'd
> Better have Firewire and USB, LOL.

Both _can_ work fine on Linux.  Linux distributions have gotten pretty
good at both, but there are holes in the hardware support picture.  For
example, USB is basically a passive channel over which hardware devices
can implement their own communications protocol.  So, software support
for each separate make/model of device is an entirely separate problem.
For example, just last night I was trying to help someone who'd been
given a cheap HP ScanJet 3530 USB scanner.  It turns out that Linux has
a driver that can perfectly see all USB scanner devices, but that
doesn't get you very far unless the scanner _software_ that controls the
scanner process can understand the scanning-control language (device
protocol) the scanner speaks.  It's like designing a radio to
communicate with someone else's radio, and then finding out that he
speaks only Mandarin, and you speak only English.  Unfortunately, HP has
been completely uncooperative with open-source coders, a point I'll
return to, below.

> The scsi thing is funny to me, we were so Happy to get rid of scsi, no
> Counting the daisy chain...but, yes, you are of course correct on the
> stability of it.

For things like CDR/CDRW drives and scanners, the open-source community
wrote the drivers for SCSI first, so they're extremely well debugged.
Since later devices such as USB/firewire/parallel types have essentially
implemented SCSI over those other connection types, the (newer) software
support for those in Linux involves a "shim" connection driver for that
bus cross-connected to a SCSI driver of some sort.  So, making Linux
support those devices is a more-complex process than for the original
SCSI ones, and there's more opportunity for something to go wrong.

> THANK YOU SO MUCH for the information!
> I am beginning to see a pattern, and certainly with open source having to
> play catch up and manufacturers not being so gracious about drivers, it
> would be easier with less than the newest equipment models. Simple when
> considers it. Newbie mentality here, but hopefully progressing to novice

Yes, exactly!  You've figured out my other point:  When a manufacturer
introduces an entirely new type of hardware, e.g., a new sound chipset,
it will usually be glad to lend samples of that hardware to OS driver
authors, along with sample code, provided that the author is willing to
sign a non-disclosure agreement (NDA).  Often, this happens well before
the hardware appears on the market for customers; in fact, it pretty
much has to, because programmers need some time to create and debug

But the thing about open-source programmers is that they _can't_ sign
NDAs if they're creating open-source code:  The very idea of open source
is that all code is going to be fully exposed to public view and
understanding (along with being licensed so that anyone may take over
development).  At most, they might sign an NDA that expires at some
future date when the work is to be released to the public.  The XFree86
Project does this for video chipsets, for example.

Unfortunately, many hardware manufacturers are unwilling to sign any
such agreements:  They regard information about how their hardware works
to be "the family jewels", and making that public for the benefit of
open-source programmers would also make it available to their competitors.
This is true especially with low-end hardware (inkjet printers, cheap
scanners), but also at the high end (video cards' 3D rendering modes).

The open-source community's way of dealing with this is to laboriously
reverse-engineer the hardware -- poking at it with test software to
figure out its programming interface by how it behaves and what it does.
Over time, it's possible to write a very good driver this way, but time
is essential to the effort.  Therefore, it's safest to buy hardware
whose chipsets have been on the market for at least one year.

Further, if you can figure out what sort of hardware driver programmers
themselves are likely to own, that pretty much automatically tells you
which hardware will have really good open-source drivers.  Since they
don't have a lot of money to spend, or get allocated older hardware
within their firms, they tend to use good-quality but non-fancy
components.  Since they spend a lot of time on those components, they're
motivated to improve their performance and stability.

Thus, what I call Moen's Law of Hardware:  "Use what the programmers

> I do not know how to program....

I can recommend the Python programming language, as a cool and relatively
painless way of getting one's feet wet with programming on Linux.
It's a very well-designed language, useful for lots of things, and
it's almost impossible to write unclear Python.

> ...and I am thinking that Linux is way over my head at this time, but
> will only become manageable if I jump in and attempt to use it.

Yeah, that's my experience, in fact.  I didn't really start to "get"
Linux until I stopped dual-booting, and just insisted on making it my
primary computing environment.  It's now a lot easier to do that than
it was in 1992, when I started using Linux:  Things are a lot less

Rick Moen

vox mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.