We can already do manipulation of individual cells (how do you think Dolly appeared?) and we can already alter DNA without too much trouble. What this technology supplies is the ability to do this to specific cells in a living organism. In terms of ecological damage we already have tools that are capable of wreaking significantly more damage. You do know that genetically modified bacteria and viruses are commonly used in biological research, right?
1) Quake 3 and UT are both dynamically linked against libGL, as are most other Linux 3D apps that I've seen. Which statically compiled ones are you talking about? In any case, I was under the impression that it was hardware support that was being discussed. Most modern 3D hardware is supported under Linux, albeit not to the same level of quality as under Windows.
2) www.openal.org appears to have support for Creative cards. I've certainly seen applications that implement 3D sound under Linux, but can't find the URLs at the moment. Apologies for the lack of a terribly convincing argument.
3) On the one hand you're arguing that USB support isn't a big issue because PS/2/parallel/serial equivilents are available, but on the other hand you're complaining that WinModem support is despite the availability of real Modems? Remember that real Modems are superior to WinModems, a feature not shared by PS/2/parallel/serial equivilents to USB. Please attempt to present a consistant argument.
(also note that I can pick up a real modem for less money than it would cost for me to replace my USB devices with non-USB ones. I think that's a pretty important issue, too)
4) However, force-feedback devices cannot be used at ALL in Linux. - nonsense. The majority of them work without any problems at all. You don't get the force-feedback, but they're still perfectly usable input devices.
Presumably it doesn't protect itself from me taking a photograph of the screen, though. What would be more useful would be if there was no way to directly tie it back to the sender, so the "It wasn't me - that's a forgery" argument could be used.
Of course, that means that I can't guarantee that the mail really comes from the apparant sender. I can't really see how you could have it both ways, though.
As another reference point, when the hard drive in my bridge/firewall died I was able to throw Debian onto it in less than an hour. That was a 486/8MB/160MB drive. Installation onto a server I'd just put together took about 30-40 minutes starting with completely unused hardware. I've no idea what's causing the difference.
That's something that's always confused me. With the exception of wanting optimisations for your particular processor, why is a source based distribution preferable? When I want to install a program, it's generally because I want to use it. Ideally I want to use it in the minimal amount of time possible. What I don't want to have to do is sit around waiting for it to compile first, especially on my slower machines. Debian does this pretty well, and gives me trivial access to the source if I want it.
I'd say automatic X configuration would be one of the most useful improvements. It's not even theoretically that hard nowadays - PCI IDs allow you to identify most modern graphics cards, you can obtain monitor specifications via DDC to avoid asking for frequency ranges, USB and PS/2 mice can be autodetected (as can many serial mice) and that's pretty much it. Ask the user if their mouse has three buttons or not and you're there. XFree 4 does a lot of this (X -configure) and should be shipping with Woody, which makes life a lot easier.
What else? Dselect probably shouldn't appear unless the user really, really wants it. It's an incredibly powerful tool that I use a lot, but the user interface is pretty non-standard. Producing a tool with a non-standard interface is one thing (and arguably a good thing under certain circumstances), but throwing this at people during installation is a bad thing. There should be ways of choosing individual packages without having to deal with dselect.
To be honest, that's about it. The only other thing I can think of is for the installer to try DHCP before asking questions about network configuration, but the ability to override this is obviously pretty important. Some mechanism whereby you could stick a floppy in one Debian machine, run a program that copied a bunch of configuration onto it then insert that during installation of another machine in order to duplicate the setup of the first would be pretty cool, too. I'd have thought that Debconf may make this possible.
Oh, more hardware setup during installation would probably be useful. At the moment (IIRC - the last Debian install I did was a couple of months ago) sound hardware isn't dealt with during installation. It's not too much of a problem for me, but the "I just installed this thing - why do I have to answer more questions afterwards to make all my stuff work" response could do with being minimised.
Great - Aureal had a tradition for closed source Linux support, so it's likely that NVidia (who seem to be following in their footsteps here) would do much the same.
NVidia supply a kernel driver. Like the Aureal drivers, it's a few wrappers that interface with a binary object. If you find yourself having kernel problems when using it, it's unlikely that you'll get much support from the kernel developers because it's difficult to tell whether the bug's due to a problem with the kernel or a problem with NVidia's lump of code that is sitting in kernel space. NVidia also supply an XFree driver. Again, you're using a chunk of binary code with no source availability. One of the end results is that if XFree gets upgraded, there's no guarantee that your NVidia driver will work. Even if it does, it makes it harder to tell whether any strange crashes you have are due to bugs in XFree or bugs in NVidia's code.
By using binary drivers, you're throwing away a great deal of the support that makes free software useful. I was able to work around fundamentally broken hardware in a bunch of machines I once had to deal with due to the fact that I had the source available to me and the authors of that source were willing to talk to me about it. In the end it turned out to be a one line patch. The chances of me being able to do this sort of thing with closed drivers is approximately zero, and the chances of the hardware company providing me with a fix in the timescale I required (the machines arrived on a Thursday. The users were arriving on the Saturday) were not much better.
Not that I'm complaining about NVidia's hardware, of course. What I'm concerned about is that not everybody realises that by using these drivers they do lose one of the major advantages of free software and don't do a great deal to encourage hardware manufacturers to release specifications in future. It certainly doesn't do much to help people on non-i386 platforms.
Oxford blocked Napster earlier this year due to it saturating the network sufficiently badly that people were having trouble streaming their academic data. Still, Oxford also forced the removal of copies of the DeCSS code from webservers in the university so they're not entirely on the side of "Information should be free".
Problem is, the "gradual" appearance of such features will compound UI inconsistency problems.
For Gnome, at least, I'd expect this not to be too much of a problem. The Gnome Foundation has something of a vested interest in having a consistent interface, and groups like Eazel and Helixcode have a vested interest in seeing their code appear in any standard Gnome distribution rather than somebody else's code. I'd imagine that KDE will end up in much the same state.
Dunno about you, but I've had some pretty bad experiences with such GUI tools attempting to modify my config files. In general, they don't seem very robust.
I've seen it done well. Smit (I've only used it on AIX 3.2.3, so I have no idea how this applies to other versions) seems to manage things without too much trouble, and really does make system management easier. It also outputs everything it does as a shell script, so in theory all you have to do to get a brand new system to the same state as an old one is run the smit script from the first machine. It's also useful for seeing just what the thing is doing.
Again, it's in distributors' interests for this to happen. I'd be surprised if there aren't decent config file managers in the not too distant future.
1) You compile in support in the kernel. I'd be surprised if many distributions do this, given that they all ship Apache and similar.
2) You manually change a value in/proc
You really do have to make a concerted effort to give it any real possibility of becoming a security risk.
I honestly have no idea why Debian's X configuration is so awkward, and it's probably the thing that annoys me about it most as well. xviddetect and anXious help, but the xviddetect card database dates back to February. I've just finished hacking together an X setup script for a netbooting system I'm working on - it's now able to write a working XF86Config file for most PCI/AGP based systems with no user interaction at all. This was mostly done using standard Debian tools, so it really shouldn't be too hard to do for Debian. Maybe one of these days I'll get round to registering as a Debian developer...
I was going to try following the steps to build a Pine.deb
For future reference, this is as simple as
cd/tmp
apt-get --compile source pine
dpkg -i *.deb
Now all we need is a Debian wrapper package that has a postinst that spawns a script that does the above, nuking the original package in the process. Voila - Pine conforming to Debian filesystem layout without actually distributing any modified versions:)
Well, if'fn you're interested in messing with USB RIGHT NOW, scarf a copy of the 2.2.16 backport patch at SUSE
Alternatively, get the latest 2.2.18 pre patch from ftp.kernel.org (or your nearest mirror) and enjoy not only USB but also all sorts of previously 2.4 features such as AGP support, DRI with XF86 4 and (finally!) decent NFS. Sure, most of them have been available as separate patches before but it's nice to finally have them in the stable kernel tree.
1) There are very few creature comforts in Linux. Sure stuff like ActiveDesktop or Win98 Explorer (with the integrated preview) are not absolutely necessary, but they're nice to have.
Yes, which is why people are working on things like Nautilus. These features are gradually appearing.
2) Linux has no asthetics. Asthetics goes beyond pretty GUIs into the system itself. There is only so much KDE and GNOME do for you. Once you get into the system itself, its ugly. Initscripts are ugly (except in Slackware). Adding hardware is ugly. The config files are ugly. (My thinking is that the whole mess in/etc could be condensed into a dozen well planned files.)
Yes, the initscripts and so on could probably be made simpler. It would be against the UNIX philosophy of individual programs working together, though, so I don't see it as likely to happen. Rather then dealing with this at the underlying level, it makes far more sense for your distribution to abstract these away from you. Graphical programs that allow you to manipulate init scripts in a more sensible way exist. More structured configuration programs for manipulating configuration files are becoming more common. It won't be long before you really don't have to worry about that sort of thing.
3) Linux has a learning curve shaped like an L.
You're not comparing like with like. As you say later on, Linux isn't an OS. Don't compare Linux with other operating systems - compare distributions. I use Debian here, so I'll compare that with the points you raise.
ALSA: Debian includes a program that asks you what sort of sound card you have. ALSA includes ISAPNP support, so it's pretty good at finding things. No editing of configuration files, no magic numbers.
Telnet: apt-get install telnetd, or pick it from the software installation program of your choice.
NAT: No idea, I'm afraid - I've never needed to do it.
Incidentally, using a telnet server is a fantastically stupid thing to do, especially on a cable modem. You do realise that telnet doesn't encrypt passwords, right? Somebody sitting on the same cable modem segment as you can sniff those passwords as you type them. Use ssh.
4) Linux isn't an OS.
As I said above, I agree. However, you then go on to say:
Linux should be judged by the same ruler as a commercial OS.
Why should it be compared to a commercial OS if it's not an OS? What is far more sensible is to compare distributions with commercial OSs. Debian (Incidentally, I'm not trying to demonstrate any superiority in Debian here - it's just that I maintain a large number of Debian systems, so I have significantly more experience of it than any other Linux distribution) has features that answer several of your points. Software installation is as simple as choosing the program you want from a list and waiting for it to either be read off CD or downloaded along with any other software it depends on. You rarely need to mess about with configuration files yourself. Building from source is something that people keep claiming is a necessary part of running a Linux system, but I can count the number of programs I use that I've had to compile by hand on my fingers. Provided your distribution is reasonably comprehensive, it's just plain not needed.
Most of your claims about the deficiencies of Linux are because you're not using everything that's available to you. The fact that you feel you have to do stuff the difficult way is obviously a very good argument for better documentation being required (and I'll agree that that is one thing that Linux is seriously deficient in having spent several hours yesterday struggling with initrd stuff that now bears little resemblance to the kernel documentation for it). I'm not going to claim that Linux is as ready for the average desktop user as Windows is, but it's not as far away as you're implying.
3D acceleration as supported by 2.4 (and 2.2.18 when it's released) and XFree86 4? 3D sound as supported by various applications and sound cards? Winmodems are supported as much as patents will allow (there appear to be US patents on V.42[bis], V.34[bis] and V.90. I'm not sure what the international situation is), and are hindered by the complete lack of programming information available. I've no idea about force feedback, but I think placing it higher than USB in the desirability stakes is misguided - there is already hardware that requires USB, whereas lack of force feedback doesn't prevent you from using anything.
2.4 comes with a kernel web server, but it only deals with static content and has almost nothing in the way of features. Red Hat are working on their own kernel-based webserver (I'm afraid I can't remember what it's called), presumably including features required to compete with existing web servers. It's the sort of thing that Linus is never likely to let into the kernel, so Red Hat are developing it themselves.
2.4 is now in "Nothing gets done unless it's written down on the TODO list and even then not if it's not really, really necessary". The latest 2.4s have the dire VM from 2.2 replaced with something better (as opposed to something worse earlier in 2.3/2.4) and are now pretty stable. It's not too far off.
The drivers available at linux.aureal.com do not even come close to compiling against 2.4. I just tried, and ended up with several pages of errors for my troubles.
linux.aureal.com contains a bunch of closed source drivers (the source supplied is for a wrapper that interfaces between their closed source drivers and the kernel interface so that it's not restricted to a single compiled kernel) which don't work properly on recent kernels (2.4). There is insufficient information availabile there for a free driver to be developed. Given that that's what I said originally, what's your point?
hdparm -S Set the standby (spindown) timeout for the drive.
This value is used by the drive to determine how
long to wait (with no disk activity) before turning
off the spindle motor to save power. Under such
circumstances, the drive may take as long as 30
seconds to respond to a subsequent disk access,
though most drives are much quicker. The encoding
of the timeout value is somewhat peculiar. A value
of zero means "off". Values from 1 to 240 specify
multiples of 5 seconds, for timeouts from 5 seconds
to 20 minutes. Values from 241 to 251 specify from
1 to 11 units of 30 minutes, for timeouts from 30
minutes to 5.5 hours. A value of 252 signifies a
timeout of 21 minutes, 253 sets a vendor-defined
timeout, and 255 is interpreted as 21 minutes plus
15 seconds.
If Aureal had supplied programming details for their cards rather than providing a bunch of closed source drivers that don't work properly with newer kernels, then support for their cards would be included with the standard kernel and installation would be significantly easier. Blame your hardware vendor for being stupid.
If you don't object to closed source drivers with no sort of guarantee of future support, go NVidia. If you want to use entirely free software, go Matrox.
Slashdot Mirror
We can already do manipulation of individual cells (how do you think Dolly appeared?) and we can already alter DNA without too much trouble. What this technology supplies is the ability to do this to specific cells in a living organism. In terms of ecological damage we already have tools that are capable of wreaking significantly more damage. You do know that genetically modified bacteria and viruses are commonly used in biological research, right?
1) Quake 3 and UT are both dynamically linked against libGL, as are most other Linux 3D apps that I've seen. Which statically compiled ones are you talking about? In any case, I was under the impression that it was hardware support that was being discussed. Most modern 3D hardware is supported under Linux, albeit not to the same level of quality as under Windows.
2) www.openal.org appears to have support for Creative cards. I've certainly seen applications that implement 3D sound under Linux, but can't find the URLs at the moment. Apologies for the lack of a terribly convincing argument.
3) On the one hand you're arguing that USB support isn't a big issue because PS/2/parallel/serial equivilents are available, but on the other hand you're complaining that WinModem support is despite the availability of real Modems? Remember that real Modems are superior to WinModems, a feature not shared by PS/2/parallel/serial equivilents to USB. Please attempt to present a consistant argument.
(also note that I can pick up a real modem for less money than it would cost for me to replace my USB devices with non-USB ones. I think that's a pretty important issue, too)
4) However, force-feedback devices cannot be used at ALL in Linux. - nonsense. The majority of them work without any problems at all. You don't get the force-feedback, but they're still perfectly usable input devices.
Presumably it doesn't protect itself from me taking a photograph of the screen, though. What would be more useful would be if there was no way to directly tie it back to the sender, so the "It wasn't me - that's a forgery" argument could be used.
Of course, that means that I can't guarantee that the mail really comes from the apparant sender. I can't really see how you could have it both ways, though.
does username@ipnumber not work as an address?
Nope. In any case, several ISPs block all outgoing and incoming SMTP traffic at their routers in order to reduce spam.
As another reference point, when the hard drive in my bridge/firewall died I was able to throw Debian onto it in less than an hour. That was a 486/8MB/160MB drive. Installation onto a server I'd just put together took about 30-40 minutes starting with completely unused hardware. I've no idea what's causing the difference.
That's something that's always confused me. With the exception of wanting optimisations for your particular processor, why is a source based distribution preferable? When I want to install a program, it's generally because I want to use it. Ideally I want to use it in the minimal amount of time possible. What I don't want to have to do is sit around waiting for it to compile first, especially on my slower machines. Debian does this pretty well, and gives me trivial access to the source if I want it.
I'd say automatic X configuration would be one of the most useful improvements. It's not even theoretically that hard nowadays - PCI IDs allow you to identify most modern graphics cards, you can obtain monitor specifications via DDC to avoid asking for frequency ranges, USB and PS/2 mice can be autodetected (as can many serial mice) and that's pretty much it. Ask the user if their mouse has three buttons or not and you're there. XFree 4 does a lot of this (X -configure) and should be shipping with Woody, which makes life a lot easier.
What else? Dselect probably shouldn't appear unless the user really, really wants it. It's an incredibly powerful tool that I use a lot, but the user interface is pretty non-standard. Producing a tool with a non-standard interface is one thing (and arguably a good thing under certain circumstances), but throwing this at people during installation is a bad thing. There should be ways of choosing individual packages without having to deal with dselect.
To be honest, that's about it. The only other thing I can think of is for the installer to try DHCP before asking questions about network configuration, but the ability to override this is obviously pretty important. Some mechanism whereby you could stick a floppy in one Debian machine, run a program that copied a bunch of configuration onto it then insert that during installation of another machine in order to duplicate the setup of the first would be pretty cool, too. I'd have thought that Debconf may make this possible.
Oh, more hardware setup during installation would probably be useful. At the moment (IIRC - the last Debian install I did was a couple of months ago) sound hardware isn't dealt with during installation. It's not too much of a problem for me, but the "I just installed this thing - why do I have to answer more questions afterwards to make all my stuff work" response could do with being minimised.
I'll probably think of more. Oh well.
Does my URL really make it that difficult to guess?
Great - Aureal had a tradition for closed source Linux support, so it's likely that NVidia (who seem to be following in their footsteps here) would do much the same.
NVidia supply a kernel driver. Like the Aureal drivers, it's a few wrappers that interface with a binary object. If you find yourself having kernel problems when using it, it's unlikely that you'll get much support from the kernel developers because it's difficult to tell whether the bug's due to a problem with the kernel or a problem with NVidia's lump of code that is sitting in kernel space. NVidia also supply an XFree driver. Again, you're using a chunk of binary code with no source availability. One of the end results is that if XFree gets upgraded, there's no guarantee that your NVidia driver will work. Even if it does, it makes it harder to tell whether any strange crashes you have are due to bugs in XFree or bugs in NVidia's code.
By using binary drivers, you're throwing away a great deal of the support that makes free software useful. I was able to work around fundamentally broken hardware in a bunch of machines I once had to deal with due to the fact that I had the source available to me and the authors of that source were willing to talk to me about it. In the end it turned out to be a one line patch. The chances of me being able to do this sort of thing with closed drivers is approximately zero, and the chances of the hardware company providing me with a fix in the timescale I required (the machines arrived on a Thursday. The users were arriving on the Saturday) were not much better.
Not that I'm complaining about NVidia's hardware, of course. What I'm concerned about is that not everybody realises that by using these drivers they do lose one of the major advantages of free software and don't do a great deal to encourage hardware manufacturers to release specifications in future. It certainly doesn't do much to help people on non-i386 platforms.
Oxford blocked Napster earlier this year due to it saturating the network sufficiently badly that people were having trouble streaming their academic data. Still, Oxford also forced the removal of copies of the DeCSS code from webservers in the university so they're not entirely on the side of "Information should be free".
Bullshit. Your cable modem will filter out all packets not destined for your computer's MAC address.
:)
Really? Cool. Ok, I take that back
Problem is, the "gradual" appearance of such features will compound UI inconsistency problems.
For Gnome, at least, I'd expect this not to be too much of a problem. The Gnome Foundation has something of a vested interest in having a consistent interface, and groups like Eazel and Helixcode have a vested interest in seeing their code appear in any standard Gnome distribution rather than somebody else's code. I'd imagine that KDE will end up in much the same state.
Dunno about you, but I've had some pretty bad experiences with such GUI tools attempting to modify my config files. In general, they don't seem very robust.
I've seen it done well. Smit (I've only used it on AIX 3.2.3, so I have no idea how this applies to other versions) seems to manage things without too much trouble, and really does make system management easier. It also outputs everything it does as a shell script, so in theory all you have to do to get a brand new system to the same state as an old one is run the smit script from the first machine. It's also useful for seeing just what the thing is doing.
Again, it's in distributors' interests for this to happen. I'd be surprised if there aren't decent config file managers in the not too distant future.
The kernel web server is only enabled if:
/proc
1) You compile in support in the kernel. I'd be surprised if many distributions do this, given that they all ship Apache and similar.
2) You manually change a value in
You really do have to make a concerted effort to give it any real possibility of becoming a security risk.
I honestly have no idea why Debian's X configuration is so awkward, and it's probably the thing that annoys me about it most as well. xviddetect and anXious help, but the xviddetect card database dates back to February. I've just finished hacking together an X setup script for a netbooting system I'm working on - it's now able to write a working XF86Config file for most PCI/AGP based systems with no user interaction at all. This was mostly done using standard Debian tools, so it really shouldn't be too hard to do for Debian. Maybe one of these days I'll get round to registering as a Debian developer...
I was going to try following the steps to build a Pine .deb
/tmp
:)
For future reference, this is as simple as
cd
apt-get --compile source pine
dpkg -i *.deb
Now all we need is a Debian wrapper package that has a postinst that spawns a script that does the above, nuking the original package in the process. Voila - Pine conforming to Debian filesystem layout without actually distributing any modified versions
Well, if'fn you're interested in messing with USB RIGHT NOW, scarf a copy of the 2.2.16 backport patch at SUSE
Alternatively, get the latest 2.2.18 pre patch from ftp.kernel.org (or your nearest mirror) and enjoy not only USB but also all sorts of previously 2.4 features such as AGP support, DRI with XF86 4 and (finally!) decent NFS. Sure, most of them have been available as separate patches before but it's nice to finally have them in the stable kernel tree.
1) There are very few creature comforts in Linux. Sure stuff like ActiveDesktop or Win98 Explorer (with the integrated preview) are not absolutely necessary, but they're nice to have.
/etc could be condensed into a dozen well planned files.)
Yes, which is why people are working on things like Nautilus. These features are gradually appearing.
2) Linux has no asthetics. Asthetics goes beyond pretty GUIs into the system itself. There is only so much KDE and GNOME do for you. Once you get into the system itself, its ugly. Initscripts are ugly (except in Slackware). Adding hardware is ugly. The config files are ugly. (My thinking is that the whole mess in
Yes, the initscripts and so on could probably be made simpler. It would be against the UNIX philosophy of individual programs working together, though, so I don't see it as likely to happen. Rather then dealing with this at the underlying level, it makes far more sense for your distribution to abstract these away from you. Graphical programs that allow you to manipulate init scripts in a more sensible way exist. More structured configuration programs for manipulating configuration files are becoming more common. It won't be long before you really don't have to worry about that sort of thing.
3) Linux has a learning curve shaped like an L.
You're not comparing like with like. As you say later on, Linux isn't an OS. Don't compare Linux with other operating systems - compare distributions. I use Debian here, so I'll compare that with the points you raise.
ALSA: Debian includes a program that asks you what sort of sound card you have. ALSA includes ISAPNP support, so it's pretty good at finding things. No editing of configuration files, no magic numbers.
Telnet: apt-get install telnetd, or pick it from the software installation program of your choice.
NAT: No idea, I'm afraid - I've never needed to do it.
Incidentally, using a telnet server is a fantastically stupid thing to do, especially on a cable modem. You do realise that telnet doesn't encrypt passwords, right? Somebody sitting on the same cable modem segment as you can sniff those passwords as you type them. Use ssh.
4) Linux isn't an OS.
As I said above, I agree. However, you then go on to say:
Linux should be judged by the same ruler as a commercial OS.
Why should it be compared to a commercial OS if it's not an OS? What is far more sensible is to compare distributions with commercial OSs. Debian (Incidentally, I'm not trying to demonstrate any superiority in Debian here - it's just that I maintain a large number of Debian systems, so I have significantly more experience of it than any other Linux distribution) has features that answer several of your points. Software installation is as simple as choosing the program you want from a list and waiting for it to either be read off CD or downloaded along with any other software it depends on. You rarely need to mess about with configuration files yourself. Building from source is something that people keep claiming is a necessary part of running a Linux system, but I can count the number of programs I use that I've had to compile by hand on my fingers. Provided your distribution is reasonably comprehensive, it's just plain not needed.
Most of your claims about the deficiencies of Linux are because you're not using everything that's available to you. The fact that you feel you have to do stuff the difficult way is obviously a very good argument for better documentation being required (and I'll agree that that is one thing that Linux is seriously deficient in having spent several hours yesterday struggling with initrd stuff that now bears little resemblance to the kernel documentation for it). I'm not going to claim that Linux is as ready for the average desktop user as Windows is, but it's not as far away as you're implying.
3D acceleration as supported by 2.4 (and 2.2.18 when it's released) and XFree86 4? 3D sound as supported by various applications and sound cards? Winmodems are supported as much as patents will allow (there appear to be US patents on V.42[bis], V.34[bis] and V.90. I'm not sure what the international situation is), and are hindered by the complete lack of programming information available. I've no idea about force feedback, but I think placing it higher than USB in the desirability stakes is misguided - there is already hardware that requires USB, whereas lack of force feedback doesn't prevent you from using anything.
2.4 comes with a kernel web server, but it only deals with static content and has almost nothing in the way of features. Red Hat are working on their own kernel-based webserver (I'm afraid I can't remember what it's called), presumably including features required to compete with existing web servers. It's the sort of thing that Linus is never likely to let into the kernel, so Red Hat are developing it themselves.
2.4 is now in "Nothing gets done unless it's written down on the TODO list and even then not if it's not really, really necessary". The latest 2.4s have the dire VM from 2.2 replaced with something better (as opposed to something worse earlier in 2.3/2.4) and are now pretty stable. It's not too far off.
The drivers available at linux.aureal.com do not even come close to compiling against 2.4. I just tried, and ended up with several pages of errors for my troubles.
linux.aureal.com contains a bunch of closed source drivers (the source supplied is for a wrapper that interfaces between their closed source drivers and the kernel interface so that it's not restricted to a single compiled kernel) which don't work properly on recent kernels (2.4). There is insufficient information availabile there for a free driver to be developed. Given that that's what I said originally, what's your point?
man hdparm
hdparm -S Set the standby (spindown) timeout for the drive.
This value is used by the drive to determine how
long to wait (with no disk activity) before turning
off the spindle motor to save power. Under such
circumstances, the drive may take as long as 30
seconds to respond to a subsequent disk access,
though most drives are much quicker. The encoding
of the timeout value is somewhat peculiar. A value
of zero means "off". Values from 1 to 240 specify
multiples of 5 seconds, for timeouts from 5 seconds
to 20 minutes. Values from 241 to 251 specify from
1 to 11 units of 30 minutes, for timeouts from 30
minutes to 5.5 hours. A value of 252 signifies a
timeout of 21 minutes, 253 sets a vendor-defined
timeout, and 255 is interpreted as 21 minutes plus
15 seconds.
If Aureal had supplied programming details for their cards rather than providing a bunch of closed source drivers that don't work properly with newer kernels, then support for their cards would be included with the standard kernel and installation would be significantly easier. Blame your hardware vendor for being stupid.
If you don't object to closed source drivers with no sort of guarantee of future support, go NVidia. If you want to use entirely free software, go Matrox.