[sf-lug] Rick's explanation of his internet setup.
jim at well.com
Tue Jan 3 08:11:05 PST 2006
rick, you mention i/o considerations when you
could you elucidate some? Balance seems to
mean getting a right sufficiency of CPU, RAM,
storage, console (display, keyboard, mouse),
and seems to me other i/o-ish stuff.
my interest is first the bus: PCI is best?
then NIC? then what?
On Jan 2, 2006, at 11:05 PM, Rick Moen wrote:
> Quoting Adrien Lamothe (alamozzz at yahoo.com):
>> I've done some work for an internet cafe, helping to set up and
>> configure game servers running Linux to host the game Half-Life. We've
>> run SuSE, Slackware, Debian and Red Hat successfully on hardware that
>> would probably qualify as "grossly out of balance." So far the servers
>> have worked without a hitch.
> (I note that you mean under WINE or WineX, etc.: Half-Life is _not_ a
> Linux application. It's a DirectX Windows one.)
> When I said "grossly out of balance", I of course meant in the context
> of more typical Linux usage (office-type apps, Web browsing, etc.). A
> typical 3D gamer box has, for _any usage but gaming_, an overpriced CPU
> that goes almost unused, and an overpriced video card that goes almost
> unused. Running those more-typical applications in a native-Linux
> environment heightens that effect, in that Linux itself tends to be
> less CPU-intensive than are Microsoft's Win32 OSes.
> It should go without saying that, when you build a box for Windows 3D
> gaming (whether on straight MS-Windows or in a Win32 emulation
> environment), then a machine such as you describe would _not_ be
> "grossly out of balance" -- because the highly atypical usage model
> works best with exactly that sort of box.
> However, if you handed me the price of one of those machines and told
> me, "Rick, see if you can get better performance for native-Linux
> general-variety desktop or server usage, using the same amount of
> money", I'll guarantee I'd be able to _smoke_ your box -- in that
> radically different usage scenario.
> Why? Because mine would have the money allocated differently among the
> subassemblies, taking _a lot_ away from where it doesn't matter quite
> that much (CPU, video) and sinking more into what relatively lags on
> gamer box (I/O).
>> Well, I've probably been spoiled, because I've been using SuSE Linux,
>> since version 5.1. I've installed SuSE on many systems, some of them
>> purchased at thrift shops, others brand new that I've built for myself
>> and others, and name-brand systems purchased at places like CompUSA.
>> SuSE always worked, out of the box, without problem, on whatever
>> hardware I installed it on. So, when I've gone to AnandTech and Toms
>> Hardware for research, I've found their advice regarding hardware
>> issues (stability, which components play nice with each other, etc.)
>> useful, even from a Linux perspective.
> I note that SUSE Linux usually includes quite a lot of proprietary,
> binary-only hardware drivers -- more than do most distros. Mind you,
> that's fine: It can be handy to have, as you found out. However, the
> point is that _needing_ them is undesirable, when you can avoid it.
> A lot of people with such hardware (winmodems, most USB ADSL bridges,
> certain exotic video chips, some SATA, some sound chips, some ethernet)
> have found out the hard way that the proprietary drivers tend to become
> unusable as the kernel's interfaces change, or when you try to migrate
> the hardware to a new box (ia32 to AMD64, say). And others have found
> themselves with mysterious kernel-level bugs and kernel panics: When
> they try to report those to the Linux kernel mailing list, they're
> surprised to see the bug report rejected because their kernel was
> "tainted" by the proprietary driver. (The kernel coders had to finally
> put in code to detect proprietary drivers and automark any bug reports
> as suspect, because they were being driven crazy by Nvidia users
> reporting "kernel bugs" that originated in Nvidia drivers and couldn't
> be fixed for lack of source code access.)
>> I've recently evaluated several Debian-based distros, due to
>> uncertainty about events at Novell/SuSE and problems experienced with
>> SuSE 10.0. I've tried Kanotix 3-2005, Kubuntu 5.10, and Simply Mepis.
>> So far, I've had problems with all three of those distros, from not
>> installing to having the system lock-up.
> That might have been because, unlike SUSE 9.3, those Debian-based
> distros don't have as huge a collection of proprietary hardware
> Dunno: It's speculation. (Obviously, SUSE 10.0 has separate problems,
> for other reasons entirely.)
> By "SUSE 9.3", I refer to the boxed-set edition that was (lawfully)
> available on a per-seat licensed basis from retail vendors, which has
> much more proprietary code than the various redistributable editions --
> for the simple reason that many of those proprietary codebases lack any
> grant of a right of redistribution to the public.
> sf-lug mailing list
> sf-lug at linuxmafia.com
More information about the sf-lug