Sorry, not being clear again. By a sacrificial box, I mean a box that if the kernel or a driver explodes and crashes the box nothing important is lost. Also, since the kernel may crash while testing, hardware that is somewhat resilient to destruction due to system crashes that require cold reboots would be desirable.
I run the 2.6 kernel also and find it to be plenty stable. I only meant that since the book I'm reading is specific to 2.6 driver develpoment I want to build a box on which to develop and want to build one that can I can sacrifice the files on and can take the punishment of frequent crashing, hence "sacrificial".
Brian D.
--- Tom Bruno crweb@vwords.com wrote:
I personally don't find running kernel 2.6 to be "sacrificial". I find it quite a bit nicer than 2.4. Especially on multi-cpu machines.
Jack wrote:
It's awfully quiet out there. Is the list still up? Am I still subscribed?
Well, let's find out. Is anyone running a
sacrificial
Linux box for testing such things as kernel
patches,
contributions or drivers? I'm going to set one up
for
a 2.6 debian box, so I can follow along with this
book
on Linux device drivers. So I'm looking for some
ideas
for what to load into this box on a hardware level
and
ask anyone if they have a particular device that
needs
to be written for or improved on. My budget is
limited
as I am still doing the Mr. Mom bit.
Brian D.
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
I used to consider my workstation the "sacrificial", "sandbox", or "lab" machine, especially when I mostly ran in Windows(95) on it and only booted to Linux to experiment. (The GUI would be too resource intensive and I'd go back to Windows.)
A while back though, I set up a "test machine" in the basement so I could familiarise myself with Gentoo linux while not loosing too much productivity as I came to be more reliant on the connectivity of the now Linux-dominant workstation. The closest thing to an "essential" service that it provides is off-site access to my email (Squirrelmail on Apache), and I can usually elect not to do anything fatal to the box prior to when I might really need that access.
On Tue, 22 Mar 2005 07:10:11 -0800 (PST), Jack quiet_celt@yahoo.com wrote:
Sorry, not being clear again. By a sacrificial box, I mean a box that if the kernel or a driver explodes and crashes the box nothing important is lost. Also, since the kernel may crash while testing, hardware that is somewhat resilient to destruction due to system crashes that require cold reboots would be desirable.
1: kernel freeze or driver crash is not going to wipe your file system. having a known-good kernel on a boot floppy or in your lilo configuration is a basic necessity when building your own kernel. Backing up all files and installing microparticle filters is advised when you need to do full CYA.
2: All hardware is resilient to destruction due to system crashes that require cold reboots. Microporcessor engineers did away with the HCF machine code instruction long ago.
On Tue, 22 Mar 2005, David Nicol wrote:
1: kernel freeze or driver crash is not going to wipe your file system. having a known-good kernel on a boot floppy or in your lilo configuration is a basic necessity when building your own kernel. Backing up all files and installing microparticle filters is advised when you need to do full CYA.
Actually this is not completely true. A kernel freeze and driver cash could mess up your file system if you are working with file system modules or a interface driver (raid, etc). It is also possible, but not likely that not unmounting your drives properly could also cause similar issues. ;-)
2: All hardware is resilient to destruction due to system crashes that require cold reboots. Microporcessor engineers did away with the HCF machine code instruction long ago.
If you are working with a video card driver you could theoretically drive your monitor incorrectly and mess it up.
In general I would tend to agree with your claims though.
//========================================================\ || D. Hageman dhageman@dracken.com || \========================================================//
-
D. Hageman -
David Nicol -
Jack -
Jonathan Hutchins