Joe Pranevich -- Wonderful World of Linux 2.4 (Quite Nearly There Edition)Sep 14, 1999, 13:32 (156 Talkback[s])
(Other stories by Joe Pranevich)
[ This is the third edition of this article. It has been superseded by a later edition-lt ed ]
(Before we begin, I am still missing information on video4linux, SCSI, sound, ftape, and other subsystems. If you know something that I didn't include, please let me know. I can barely keep up with the kernel traffic and reading patches as-is; going back over archives is not something that I'm capable of at the moment.)
A long time ago, in a galaxy not to far from this one, I wrote an article. It wasn't much, just a laundry list of the new and improved features of Linux 2.2. That was a long time ago and the newness of Linux 2.2 is beginning to wear off; it's even lost that new kernel smell. And so with anxious eyes, we set our sights towards the future of Linux: Linux 2.4. In the Linux world, it is uncommon to announce release dates; new versions are released when they are ready and not before. With that said however, Linux 2.3 has entered into a feature freeze and looks to be ready for the masses sometime around Christmas.
Before we move into the meat and bones of the situation, I always like to step back for a moment and say a few things. Linux 2.2 marked a major milestone in Linux's evolution: it was the first kernel release which truly caught the eye of the all-seeing media. No longer would just obscure computer publications trumpet the latest and greatest from the Linux worl, but mainstream publications as well. With the attention has come the inevitable FUD (Fear, Uncertainty, and Doubt) that we prayed would never come, but out of this media molasses we have emerged as a stronger community. While many of Linux's weak points were trumpeted and many members of the Linux community despaired, there were still the legions of kernel hackers that worked day and night to take those weaknesses, acknowledge them, and work to fix them. I think they've done wonderful job.
As a side effect of the increased media attention, many members of the media chose to use my original article as a guide, a reference to the new changes and features in Linux 2.2 in the absence of any official press release. To be honest, I was flattered. I do ask however that you cite the source whenever possible (both myself and the community who made this document possible) and if you require any clarifications, please do not hesitate to email me at the addresses below with your questions. If you would like to reprint or translate this article in full or in part in any medium, please email me at the address below so that I can be aware of your work before you do so. I will make a list of translations that I am aware of available.
This is still a draft document and may not be 100% accurate. Caution is advised. Also, new subsections have been added based on comments I received. I may keep or removed them later depending on user input. Some of these subsections will become full-blown articles at some point in the future. Please let me know what you think.)
Now, without further ado, Linux 2.4. This draft of the WWoL2.4 is subtitled the "quite nearly there" edition and will be definitely followed by a number of later drafts, at least 3 of which I will term "final". We all have different notions of what changes are important, if I don't mention a particular update that you feel is important, by all means please let me know. However now that a feature freeze has been announced, it is likely that we will soon have the first "final" draft in approximately three weeks give or take a couple years.
Joe - email@example.com (Home) firstname.lastname@example.org (Work)
< Many thanks to linuxtoday for providing me with the spiffy email addy. Other than the email, I'm in no way associated with nor speak for Linux Today. This work also has absolutely nothing to do with Lycos, my employer. The views here are all mine and this article does not constitute an endorsement from Lycos or any other such thing. They are however a pretty damn fine company to work for. >
Linux 2.2 was a great improvement over Linux 2.0. It supported many new file systems, it supported a completely rethought caching system for file names, and it was much more scalable than Linux 2.0. Linux 2.4 will build on the great advancements provided under Linux 2.2 to become an even better platform for desktop, server, and embedded tasks. However, it is the intent of the Linux kernel developers to get Linux 2.4 into the hands of the end users more quickly. To meet this goal, Linux 2.4 will understandably not be as different from Linux 2.2 as Linux 2.2 was from Linux 2.0. I think you will agree however that the advancements in Linux 2.4 will be just as noteworthy as previous versions. (Or else I wouldn't need to be writing this!)
What, at the core, is the Linux kernel? Just as the kernel is the heart of the Linux (or GNU/Linux or whatever) Operating System, the kernel itself can be divided into core and non-core parts. Linux is much more than just a collection of assorted device drivers, as any operating system must be. It's what binds these drivers together into a cohesive unit that matters. It's the scheduler, the resource allocator, the virtual filesystem layer, memory management, and so many other unsung features that are the real heroes of the Linux world. These are the portions of the Linux operating system that really define what is Linux because on every platform that Linux has been ported to from i386 (Intel-compatible PC), to ARM (embedded devices), to Sparc64 (high-end servers) this code is the same. In many ways, this "heart" of Linux 2.4 is different than Linux 2.2's and most of the subsystems that I just listed have been changed in one way or another.
Linux 2.2 and earlier Linux's included a base resource management system which was used rather bluntly to allocate and keep track of IO ports and IRQ lines and the other limited niceties of computer architectures. Unfortunately it was deficient in a number of important ways which proved crucial to the needs of a modern desktop operating system. The new system under Linux 2.4 includes a much more generic implementation which allows for nested resource groups, removed the dependencies on pre-defined resource types, and otherwise made it easier to use for a majority of the tasks required by driver developers. Additionally, this has laid the groundwork for ISA PnP support which is discussed more fully later in this article. This quick hack by Linus will probably be one of the most influential changes to go into the 2.4 kernel.
The virtual filesystem layer (VFS) has also been heavily modified from earlier Linuxes. Linux 2.2 featured a number of wonderful changes to this layer that allowed for better caching and a much more efficient system overall. However, the system in Linux 2.2 still had a number of important limitations which were resolved in time for Linux 2.4. One major limitation to the way Linux 2.2 handled things was its use of two buffers for caching: one for reading and one for output. As you can imagine, this made things very complicated as the kernel developers had to code with kid gloves to always ensure that these caches were in synch when they had to be. Linux 2.4 brings this wall completely down by removing the multiple cache system and putting all the work into a single page caching layer. This change makes Linux 2.4 more efficient, the code is easier to understand for developers, and the amount of memory needed for the caches have been split roughly in two. During the course of this rewrite, many race conditions (errors caused when multiple processes "race" for access to unprotected variables) were removed and the code streamlined to allow significantly better scaling to higher-end systems and disk writes to happen faster when multiple volumes are involved.
One common problem with Linux 2.2 that interfered with high-end (Intel?) machines was its process limitations. Linux 2.2 only allowed you to have 1024 processes or threads running at once. With high-end systems with many thousands of users, this could become a problem very quickly. Linux 2.4 has gotten rid of this relic and implemented a scalable limit which can be configured at run time and is only limited by the amount of memory in the system. On high-end servers with as little as half a gigabyte of RAM installed, it is easily possible to support as many as 16 thousand processes at once. Other users have reported being able to run many more than that on their specific systems. This was one of the major bottlenecks that kept Linux out of the Enterprise markets.
In terms of memory consumption, Linux 2.4 will require approximately the same amount of memory as does Linux 2.2. Some subsystems have been added or expanded and some have been streamlined. Some obsolete code has been removed. There are even certain cases where some systems will require less memory than Linux 2.2! It should be noted also that Linux 2.4 will also support /more/ memory than its predecessor. As of Linux 2.4, up to 4 gigabytes of RAM will be supported on Intel machines. This additional RAM will not be treated in exactly the same way as lower RAM (due to Intel design features) but will however be used by many in-kernel structures.
One often overlooked portion of the Linux kernel is the program loader; the bit that takes your programs, loads them properly, and runs them. Many people are not aware however that Linux 2.2 added support for a "misc." binary loader, a flexible module designed to allow you to associate binary types with "helper" applications in much the same way as Windows or a comparable operating system would. This would, for example, allow you to associate all Windows applications on your machine with WINE (Windows Emulator) so that when you typed "./notepad.exe" the right thing would happen. (However it is generally not a good idea to take this concept to the extreme at the kernel level and many of the "associations" provided by Windows would be best left handled by your window or file manager. It would be a bad idea, for example, to be able to run "/etc/passwd" and have it come up in a text editor.) This was considered a big win by many because it allowed many different groups, such as the WINE and Dosemu (DOS Emulator) groups, to publish instructions for making their programs run "native" by the kernel.
Linux 2.2 and Linux 2.0 included support for running Java applications (or rather, starting a Java interpreter/compiler when necessary) and was the first OS to do so at the kernel level. When a java application was executed, the Java binary loader would load up your Java interpreter with the proper arguments. Naturally, it would be easy to implement this functionality using the newer "misc." loader type and instructions were provided with Linux 2.2 on how to do so. Linux 2.4 will finally put the old binary loader to rest and all users who used the old module will have to upgrade their configuration to make the new association.
Linux 2.4 will be much more dependent on the ELF format than Linux 2.2 was, although Linux 2.2 was the first version of Linux to require the kernel to be compiled as ELF. (ELF is an advanced binary format that includes support for multiple code and data sections, easier support for shared libraries, and other niceties. It is approximately akin to the Win32 format, however better designed and without nearly as much cruft.) By more fully exploiting the ELF binary format, the kernel developers could make some pieces of code more modular and easy to maintain. Many types of drivers will become more "plug and play" (if I me be so bold as to abuse that term) as they will be initialized based on how they are linked rather than by having an explicit initialization line in the core code.
In addition, there are some other noteworthy changes to Linux 2.4 that I should mention before we move on into the specific subsystems. Linux 2.4 will be in some ways more standards compliant than previous Linuxes with the adoption of support for POSIX clocks and timers, allowing for non-rtc devices to be used as clocks internally. (This would be specialized hardware, generally.) The NFS filesystem, the standard network filesystem used under most UNIXes, now supports most of the features of version 3 of the protocol and Linux will better be able to communicate with machines which communicate with this standard (this will be discussed further in the filesystem section, below.) In addition, some minor changes were made to the threading model and elsewhere to make things more compatible.
The Many Flavors of Linux
While infrastructure is the heart of the Linux operating system, it is the parts of the operating system that are specific to the individual flavors of Linux that are most obvious to the end users. These "arms and legs" of the Linux operating system include all of the architecture dependent and independent driver code which control the processors, disk drives, ports, and everything else that provides real access to the computer. For the purposes of this article, I will be concentrating on i386 Linux because it is the flavor that I am most familiar. There have been great advancements in every port since the launch of Linux 2.2 however most of these ports are beyond my direct experience. (If there is interest in this material, I will be more than happy to write appendixes if someone would provide me with a list of updates to a specific port.) Since the launch of Linux 2.2, there have been only one new port (SuperH) integrated into what will be Linux 2.4 but this may change before release.
On Intel-compatible hardware, Linux 2.4 includes the same excellent support for processors as did Linux 2.2. This includes optimizations for 386, 486, 586 (Pentium), and 686 (Pentium Pro / Pentium II / Pentium III) processors, as well as "compatible" counterparts such as those made by AMD and Cyrix. Additionally, Linux 2.4 will include additional support for hardware present with modern chips. While Linux 2.2 includes support for Intel's Memory Type Range Registers (MTRRs) to increase performance to some kinds of high-bandwidth devices, Linux 2.4 has taken this support even further by supporting variants common to the compatible chips. (This includes both the double MTRRs present with AMD K7 processors and the MCR variant preferred by Cyrix.) Linux 2.2 also included support for the IO-APIC (Advanced Programmable Interrupt Controller) which allowed interrupts to be spread across multiple processors in a multi-processing system. Linux 2.4 will, as expected, take this to the next level and support some high-end systems which actually contain multiple IO-APIC controllers; this will allow these machines to scale even better than before.
To my knowledge, the only multi-processor systems which we still do not completely support are some very old 486 ones that mix 486DX and 486SX chips in the same system. This is mainly because the SX chips did not contain math coprocessors and there is some difficulty in making sure that applications that need floating point math get to work on the right one. As you can imagine, there isn't much call for this feature. (There may be other buggy chipsets combinations that are unsupported, however I am not personally aware of them.) Considering that no one in their right mind will still be using such a system (they could easily upgrade to a chip with a FPU), I don't consider this much of a limitation.
Linux 2.4 and Merced (ia64)
While not yet delivered to the starving masses, Intel's 64-bit replacement to the x86 line is coming down the pipeline. While Linux 2.4 does not include any direct support for the chip (since it is not out yet, that would be difficult), there are multiple groups working to make sure that there will be Linux on Merced immediately after its release. This porting process is no doubt simplified by Linux's existing support for 64-bit processors (including Compaq's Alpha chips and the Sparc64) which are already merged into the main Linux tree. This means that much of the gruntwork in making 64-bit Linux on Merced a reality (making sure that the kernel and all its drivers do not believe that they "know" what the size of datatypes are and how numbers are stored internally, etc.) is already completed. (And has been for quite some time.)
I do not want to imply that there are no remaining problems that keep Linux from being "perfect" on 64-bit systems; that is not the case. However a vast majority of the difficult and subtle parts are completed and all that remains are problems derived from a legacy world.
Linux 2.4 and Pre-386 Intel Chips
Surprisingly, I do get a number of questions about pre-386 Linux. The answer, at least right now, is that there is no such animal. A sister project, ELKS (Embeddable Linux Kernel Subset) is working to make a Linux-like operating system run on these machines, including protected mode support for chips that support it. This project is separate from Linux-proper however and is outside the scope of this document.
Buses - ISA, PCI, USB, MCA, etc.
Processors however are just a small part of the guts of a computer. Equally important to its operation is its bus architecture, the component of the system that is responsible for (or irresponsible towards, as the case may be) internal and external devices. Linux 2.4 has not yet touched much on the internal workings of many of the supported busses, including (E)ISA, VLB, PCI, and MCA except to work them into the new resource management subsystem and fix bugs. The biggest news in this area is that ISA PnP, the somewhat misguided attempt to support device configuration and detection on the ISA bus, is finally supported at the kernel level! In the future, this will allow PnP devices to "just work" and not need any supplementary configuration utilities to function properly.
There is more exciting news from this front however. Universal Serial Bus, a new external bus type just now coming into prominence for devices such as keyboards, mice, sound systems, and scanners is now supported in the Linux kernel. At the time of this writing, the support is not 100% and many individual and common USB devices are not supported or not completely supported. I would be confident however that the number of devices which are supported will only rise over time, just as we observed a similar rise in the number of framebuffer devices that are now supported. (The framebuffer was a new feature to Linux 2.2, see below.) Currently, keyboards and mice are working mostly as you would expect. Support for sound systems is coming along rapidly. Other devices, such as modems and network cards, already have preliminary support however their drivers are not complete.
In addition to USB, I2O device (Intelligent Input/Output) support, an extension of PCI, has been added in Linux 2.4. In theory, this will allow for more operating system independent devices and drivers to exist. Many I2O devices are already functioning and more will be added before Linux 2.4.
PCMCIA support, the semi-external bus common in laptop computers, is now supported from within the standard kernel distribution. No longer will PCMCIA users need to download and install separate packages to get their systems to work properly.
Linux and ISA Plug-and-Play
I have heard time and time again the question "When will Linux support Plug-and-Play?" that in and of itself can mean many things and the Linux kernel has included support for many kinds of "Plug-and-Play" devices for several revisions. Support for ISA PnP, the Plug-and-Play specification that works as a superset of the ISA bus, has long been a sore point for many Linux users. I am happy to say that Linux 2.4 will finally include direct support for configuring PnP devices although (as of this writing) many or most drivers have not been updated to probe for their supported ISA PnP cards.
Block Devices - Disk Drives, RAID Controllers, etc.
From most user's points of view, there are three different fundamental types of devices under Linux: block devices, character devices, and network devices. We will discuss each of these in turn.
Block devices are hardware whose data can be best expressed in an array of bytes that can be accessed individually. (This is simplified a bit.) To use a more computer savvy term, block devices are devices that support random access; allowing a user to seek to a specific place anywhere on the device to read from or write to (this is also simplified a bit). Common examples of block devices are harddisks, floppy drives, (anything that you can imagine as a "drive", mostly.), ramdisks, etc. If a device has special features (for example, can be ejected), it will support these extras through ioctls (I/O controls) which any program can use. Linux 2.2 already supports the most common types of storage media for enterprise and desktop use including RAID controllers, IDE and SCSI disks, and many others. Linux 2.4 will build on this in a number of important ways.
IDE is the most common type of disks used in PCs today. Each IDE controller actually supports two separate disks (harddrives, cdrom drives, etc.) which appear under Linux as separate block devices. Linux 2.4 has improved on Linux 2.2's support of IDE by more than doubling the number of IDE controllers allowed in a system to 10. (Previously, 4 was the maximum allowed.) This boosts Linux to a theoretical limit of 20 IDE devices. There have also been some changes to allow for better support for DVDs and CD-ROM changers. While it may not be ready for Linux 2.4, there is ongoing work to allow Linux to fully support rewritable CDs and DVDs in a transparent fashion, for the time being however these should be considered read-only under normal circumstances but a previously formatted disk image can be copied out to the disk directly. And finally, Linux 2.3 has access the UDMA features of many new hardware chipsets and can work better around the bugs present in some pieces of hardware.
The SCSI subsystem has advanced in Linux 2.4, the most obvious example being in the number of new SCSI controllers supported. The long awaited SCSI rewrite has not happened for Linux 2.4 although a major cleanup effort is underway.
One idea adopted from the commercial UNIX world into Linux is the concept of a "raw" I/O device. A raw device is one whose accesses are not handled through the caching layer and whose actions are immediately and always synchronous with the "hard" data on the disk or elsewhere. This idea has many enterprise uses as it allows Linux to better maintain data integrity in the case of a system failure for ultra-important data. Also, this capability has been exploited by database applications which feel that they can do a better caching job than the native filesystem. What kept this idea from being adopted before was that commercial UNIXes did not provide a scalable process to allocate and access these devices, rather they required that a "raw" device node be allocated for each and every block device on the system. After much thought and many rejected ideas, this functionality was finally allowed in by creating a pool of "raw" device nodes which then can be associated with any arbitrary block device. Thus, we need only have nodes allocated for the number of raw devices that we will be using at any one time.
Block filesystems can be used in many ways. The most common way to use a block devices is to mount a filesystem on it. (Internally, the filesystem code is like an overlay on the block device driver.) It should also be mentioned that these filesystems (as well as nearly everything else) will work with all versions of Linux and are not only applicable to i386 Linux.
Linux 2.4 includes all of the new filesystems present in Linux 2.2. These filesystems include FAT (for MSDOS), NTFS (for Windows NT/2000), VFAT and FAT32 (for Windows 9x), HFS (for Macintoshes), and many, many others. All of these filesystems have been rewritten to some extent, sometimes a very large extent, to support the new page caching system and will be more efficient because of it. On the flip side however, binary-only filesystem modules designed for Linux 2.2 will not work with Linux 2.4. (Unlike some software firms, Linux does not generally provide for back-compatibility at the module level. Generally, open source modules can adapt quickly enough and binary module providers are expected to do the same or release the code.)
Some users will however notice major improvements to allow for better compatibility with other systems. OS/2 users will finally be able to both read and write to their disks under Linux. (This change is a long time in coming.) NT users unfortunately don't yet have that luxury unless they wish to use an "experimental" driver which may lead to disk corruption under certain situations. Linux 2.4 will also include a couple of improvements designed to make it interoperate better with other UNIX-like operating systems. Key to this is Linux 2.4's upcoming support for the IRIX efs filesystem and the IRIX disklabel (partition table) format. Also, support for NextStep has also improved as the UFS driver now supports its CDROMs.
Users who mount Windows shared drives via SMB (Server Message Block protocol) will be pleased that there will no longer be a compile time option for enabling workarounds for (released broken) Win9x systems. Instead, Linux will be able to detect what kind of system it is connecting to and enable bug fixes as needed. This will make Linux a considerably better option for heterogeneous networks. (This is a SMB client only, the popular Samba package can be used if server features or access to printers is desired.)
Of special importance to many Linux users is Linux's ability to mount the shared drives of UNIX operating systems. Linux 2.4 includes for the first time the ability to access NFS shares which conform to version 3 of the NFS protocol. NFS version 3 includes many advantages over previous versions and it has been one of Linux's most often requested features for the enterprise user.
There are still some pieces of support that is currently lacking in Linux 2.4. There is no support for journalizing filesystems, for instance. Due to the relatively low fsck times and the ease of data recovery journalizing filesystems support, this is considered by many to be an entrance requirement to the enterprise. HFS+, the successor to HFS and the filesystem used on some Macintosh disks, is not yet supported. Also not supported is the UDF format, the format commonly used on DVD drives. It is hoped that these and other "missing" features will be completed before 2.4 is ready for release however there will be a code freeze coming soon.
Another, more complicated variety of block device is the frame-buffer. A frame-buffer is simply a section of memory that represents (or is) video memory to such an extent that writing to this memory affects the colors of the pixels on a screen. This is more complicated than some other block devices because it supports ioctls to change the palette and other functions associated to video. (Which it might be possible to "format" this device and mount a filesystem from it, I wouldn't recommend you try.)
Linux 2.4 includes a number of new drivers and improvements to old drivers. Especially important here is Linux's support for many more "standard" VGA cards and configurations, at least in some mode. (Probably less than optimally.) Please remember that this feature can be bypassed and (on i386) is only necessary for people with certain systems which cannot be supported in any other way. At this time, the XFree project provides many more drivers to many more video cards than the kernel can support so it is not necessary to use this feature to get X Windows support. (There is also a library which will allow you direct video manipulation on some hardware, if you don't mind security conscious binaries.)
Character Devices - Keyboards, Mice, Consoles, and Ports
The next kind of device that Linux recognizes are character devices. These are any devices which can be read from or written to but don't have a "location" per se and can't be accessed outside of order. This includes terminals, ports, keyboards, mice, and other things that you would expect. Linux 2.4 also features improvements in this area.
The biggest news on this front is that Linux 2.4 will support for the first time keyboards and mice attached to the Universal Serial Bus. When plugged in, these input device will behave just as if they were "normal" keyboards and mice. Additionally, Linux will now work on more systems, including broken (or specially embedded) ones where the keyboard is not pre-initialized by the BIOS. Also, better support is provided for machines without keyboards in some cases. (Mostly for buggy machines that don't handle the lack of a keyboard as well as one would like.)
As much as it may not appear so, all versions of Linux output to the screen in character mode. (Linux supports a built-in extended vt100 interface to handle cursor positioning. This is done using a very small text-mode only frame-buffer device.) In the case of a frame-buffer, Linux 2.2 and later support overlaying the framebuffer driver with a terminal driver allowing identical (sometimes even better) features as (than) the built-in text mode.
Linux 2.4 does not include many major changes to this subsystem however it does for the first time support redirecting the console (the primary display used for Linux kernel messages) to the parallel port for, for example, a printer. (Earlier versions of Linux already supported redirecting messages to serial ports.) This functionality will be of primary interest to some developers and server applications which want to maintain a hard-copy of kernel and debug messages that Linux uses.
Of course, Linux would not go far without excellent support for ports, the truest form of character device. These can generally be divided between serial and parallel varieties.
Serial support for Linux 2.4 has not changed much and many of the same limitations from 2.2 still apply. (In particular, setting module options is generally done with an external utility rather than the standard parameters passed to modules.) Later versions of Linux 2.2 and all versions of Linux 2.4 will allow one to share IRQs on PCI serial boards; previously this was only allowed on ISA cards and on-board serial ports. Some other pieces of multiport hardware will be better supported under Linux 2.2. More updates and new drivers are flowing in regularly.
In contrast, the parallel port subsystem has undergone some major overhauls since 2.2. There is now a generic parallel port driver for abstracted communication with "unknown" types of parallel devices. This could be used, for example, by programs that want to poll the parallel port for Plug-and-Play information as we described earlier. It is these changes that allow us the side-effect of being able to use the parallel port as a console. Also, Linux 2.4 supports using all the different modes of modern parallel ports, including writing to the parallel ports using DMA, if supported in the hardware. This will speed up access to printers and other parallel devices.
Infra-red support has progressed since Linux 2.2 and there have been many changes in this area, including better network support.
In a separate department, there has been some (but little) work since 2.2 on supporting so-called "WinModems" (or "soft modems" or "Linmodems"). These are modems which exist largely in software and whose drivers are often only provided by the manufacturer for Windows. (Hence the common name.) While no code has been submitted to Linus for the support of these beasts, it is possible that we may see some support for them before 3.0. One major obstacle here is that each and every WinModem is different; it is unlikely that a driver for one would be applicable to another and the sheer number of different types of WinModems would make this difficult or impossible to ever get a decent selection of hardware supported. Impossible odds have never phased open source developers however and I for one will not be surprised when the first driver makes it into the kernel, someday. Much of the legwork has already been completed.
There are some other places where some people feel that Linux 2.4 could improve, of course. With the addition of USB we have the chance to have multiple keyboards and mice attached to the same bus. Linux 2.4 however does not have internal multi-heading of these devices; you cannot assign one keyboard and one mouse to one terminal and another set to a different terminal. Support for this is provided in the GGI project, however this project's code has not yet (and may never be) synched into the mainstream kernel. (It is however a good place to check if you need this functionality.)
Linux is not commonly regarded as a "user friendly" operating system. Therefore, one would be surprised to learn that Linux 2.4 (and some later versions of Linux 2.2) includes support for its first speech synthesizer card. These cards will allow Linux users to hear all Linux output, including messages early in the boot process. Very few operating systems can boast such complete support for these devices at the kernel level. (Other patches and utilities are still required to get the full use out if these cards, however their presence in the kernel is a giant leap in the right direction for Linux.)
Multimedia: Sound, TV, Radio, etc.
On the complicated side of the character device list, we have some of the "fluffier" devices to be supported by Linux. Linux, in its emerging role as a desktop platform, tries very hard to support these devices, including sound cards, TV and radio tuners, and other sound and video output devices. To be honest, Linux 2.4 does not include as many ground-breaking changes as Linux 2.2 did in this respect. Linux 2.4 does however include updates and new drivers for a variety of sound and video cards, including full duplex support. Linux 2.4 and some later versions of Linux 2.2 also include code which will allow some sound devices to more easily allocate memory in required ranges; this should make the configuration and use of some cards much easier.
Networking and Protocols
Even further distant from the simplicity of keyboards and mice, networking and network hardware is one of the major areas where Linux has always excelled. These beasts are neither "character" nor "block" but inhabit a special space free of the need for device nodes. Linux 2.4 will included many improvements to this layer including new drivers, bug fixes, and new functionality added on to existing drivers.
The Linux model of network sockets is one which is standard across most UNIX variants. Unfortunately however, the standard does have some deficiencies but these deficiencies can be corrected without breaking the standard altogether. Under Linux 2.2 and previous versions, if you have a number of processes all waiting on an event from a network socket (a web server, for instance), they will all be woken up when activity if detected. So, for every web page request received, Linux would wake up a number of processes which would each try and get at the request. As it does not make sense for multiple processes to serve the same request, only one will get to the data; the remainder will notice that it doesn't have anything to process and fall back asleep. Linux is quite efficient at making this all happen as quickly as possible, however it is still very inefficient... but there is a better way. Linux 2.4 includes changes which implement "wake one" under Linux which will allow us to completely remove the "stampede effect". In short, "wake one" does exactly as its name indicates: wakes up only one process in the case of activity. This will allow applications such as Apache to be even more efficient and make Linux an even better choice as a web server.
Linux 2.4 also includes a completely rewritten networking layer. In fact, it has been made an unserialized as possible so that it will scale far better than any previous version of Linux. In addition, it contains many optimizations to allow it to work with the particular quirks of the networking stacks in use in many common operating systems, including Windows. It should also be mentioned at this point that Linux is still the only operating system completely compatible with the IPv4 specification (Yes, IPv4) and Linux 2.4 boasts an IPv4 implementation that is much more scalable than its predecessor. As Linux 2.2 became completely compatible with the specification, the use of "colon mode" for aliasing was depreciated. This functionality was completely removed in Linux 2.4 and may require some advanced users to partially rewrite scripts.
Next to the new network layer, the next most important improvement in the Linux 2.4 network layer is the addition of code to handle the DECNet protocols. This allows for better interoperation with specialized Digital/Compaq systems.
For the low-end desktop users, PPP is an important part of day to day life. Linux 2.4 includes some major rewrites and modularization of much of the code, including a long awaited combination of the PPP layers from the ISDN layer and the PPP layer used on serial devices, such as modems.
I appreciate any comments that you may have, especially changes that you feel are important that I missed. For the purpose of keeping my email sorted into nice, neat piles, please respond to email@example.com. (Yes, .com. Watch the .com.) If you really, really want I can also be reached at firstname.lastname@example.org.