LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for November 4, 2004Freeing the firmwareFew of us have multiprocessor systems sitting on our desks - or so we might think. The truth of the matter is that a typical computer contains several processors, only one of which is normally considered to be "the" processor. The others make the various subsystems and peripherals work; they live on the motherboard, in the video card, in the network adaptor, etc. Each of those processors needs a program to run. Traditionally, this "firmware" has been burned into some sort of read-only memory in the hardware itself. Manufacturers have figured out, however, that some money can be saved by leaving out the ROM and forcing the host processor to download the firmware at load time. The firmware can be shipped on the installation CD, where it gets put into the system along with the driver.Hardware installation CDs for free operating systems are still rather rare, however - and systems like Linux tend to avoid that approach in the first place. It is much nicer if the operating system simply works with the hardware presented to it without requiring a separate software installation step. The result is an easier experience for the user, and also for the hardware vendor, who typically does not want to try to support even a few of the numerous Linux and BSD variants in widespread use. Shipping drivers with the operating system itself has generally been a successful approach. Linux systems work on a vast variety of hardware, including many devices which have long since ceased to be supported by their manufacturers. With few exceptions, users can upgrade to a new kernel and expect their hardware to still work. There is no need to go scrambling around the net looking for updated drivers. If the driver needs to download firmware into the device, however, the situation changes. Somehow, the driver must get a copy of the firmware to feed to its hardware. The 2.6 kernel has a nice mechanism which allows a driver to ask user space for the firmware bits, but user space must have the firmware to answer those requests. The firmware can usually be found on the installation CD; sometimes it can be downloaded from the net as well. But users would rather not have to go looking for firmware just to make their computers work. And, if the device is not brand new, the installation CD may be lost; at that point, finding the firmware may be just about impossible. So it would be nice if the firmware could be shipped with the operating system itself. The old practice of linking the firmware into the driver itself is frowned upon in recent times for licensing and other reasons. Loading the driver from user space is a fine solution, however; the firmware request mechanisms work nicely, and the distributors can deal with the problem of getting the user-space side of things working in a transparent way. The only problem is that firmware typically comes with a restrictive license which does not have redistribution in mind. In many cases, firmware redistribution is prohibited entirely, or the situation is, at best, ambiguous. Thus, for example, the Prism54 firmware page reads as follows:
We do not yet have a re-distribution license for [the firmware
files] by Intersil (or globalspanvirata or Conexant) but since
Intersil wrote the original GPL driver and then supported the Open
Source community in maintaining it, we figure it's only fair we're
allowed to redistribute them here. Our official permission is
pending.
In today's legal climate, the "we figure it's only fair" license strikes some users as inadequate. Distributors, fearful of being sued, really need to have a license which makes their right to redistribute the firmware clear. Without that license, most of them will not ship the device firmware, and the distribution will not support the hardware in any sort of easy way. So attempts to get vendors to put their firmware under a reasonable license have been going on for years. Recently, those efforts have been stepped up a bit, thanks, especially, to efforts in the OpenBSD camp. The OpenBSD developers, too, have been starting off with quiet, private requests to the vendors. If those requests do not get an acceptable response, however, a call is made for the community to make its feelings clear. The hope is that, if enough people send coherent, polite notes saying that their future hardware purchasing decisions depend on proper free operating system support, the vendors will wake up and allow that support to happen. As the project has announced recently, this approach seems to be having some success. Atmel, for example, has just decided to make its firmware available under a BSD-style license. Theo de Raadt, who is behind the OpenBSD effort to make wireless chipset firmware available, told us that the situation is reaching the point where the vendors can be played off against each other. Enough vendors have made their firmware and/or programming information available that the rest can be credibly threatened with a loss of business if they do not follow suit. Not all vendors are convinced of this fact yet, however, so the OpenBSD folks are asking for help in contacting vendors. If the Linux community joins in with the BSD crowd, our combined voices might just be enough to make a difference. OpenBSD is, in particular, looking to apply pressure against Intel and TI, both of which have not, as yet, made their firmware distributable. Target contacts for TI and for Intel have been published. Interested people are encouraged to contact these vendors and let them know that proper free operating system support is a deciding factor in how they choose hardware. Needless to say, these messages should be professional and polite; flaming vendors will not help, and could be counterproductive. Some in the Linux community will, doubtless, be dismayed by the fact that this firmware is only available in binary form. The Debian project will argue for years on whether a BSD-licensed binary is distributable or not. The fact is that it would be fun to have the source and a toolchain so that interested people could reprogram their hardware. But that is unlikely to happen for most hardware, and, in any case, the situation is little different than with firmware which is distributed in the hardware itself. It's simply a cookie which must be fed to the hardware to convince it to do its job. If we can distribute the cookies with our operating systems, we can have hardware which works out of the box. That seems like a goal worth writing some mail for. [As a postscript, it should be noted that talks with Conexant regarding the Prism54 firmware are proceeding. Prism54 driver hacker Luis Rodriguez tells us that the conversation is continuing and that he is confident that the issue will be resolved soon.]
The state of BSDBeing LWN, we understandably tend to focus on Linux distributions and developments in open source that have are interesting from the Linux perspective. However, Linux distributions aren't the only free OSes worth using. Most LWN readers are probably familiar with the "name brands" of BSD distributions, if not the distributions themselves. This week we thought we'd take a quick look at the status of each of the BSD distributions.
FreeBSDFreeBSD is probably the most widely-used BSD, though it supports fewer hardware platforms than OpenBSD or NetBSD. The FreeBSD project maintains several development branches. The FreeBSD-STABLE branch represents the production-quality release, while FreeBSD-CURRENT is the version in development that's due to become STABLE. The STABLE release, at this time, is taken from the FreeBSD 4.x series, and new development is mostly being done in the 5.x series. The 4.x series is available for x86 and Alpha, while the 5.x series adds AMD's x86_64, Intel's Itanium, pc98 and Sparc 64-bit chips to the Tier 1 architectures. Ports for PowerPC and MIPS are in development. According to the FreeBSD website, the 5.3 release should mark the first STABLE release taken from the 5.x tree. 5.3rc2 was released on October 31. The 5.x release includes a number of interesting features and changes to FreeBSD, including SMPng, Kernel Scheduled Entities (KSE), the UFS2 file system, support for Cardbus and Bluetooth devices, and a move to GCC 3.3.x from GCC 2.95.x. The 4.x release included SMP support, but it was not compiled in the GENERIC kernel by default, and SMPng brings some significant improvements to SMP performance.
NetBSDNetBSD's main claim to fame is portability and the wide range of hardware platforms supported by the OS. Not to disparage Linux or the other BSD distributions, but NetBSD is the undisputed master of portability, with support for everything from x86 CPUs to DEC VAX computers and the Sony PlayStation2. NetBSD also has wide support for emulating other CPU and hardware platforms, including Linux, FreeBSD, Solaris, SunOS, HPUX, Amiga Unix, IRIX, Ultrix and others. FreeBSD and OpenBSD also support binary emulation for many OSes, though not quite as many. NetBSD releases are broken into NetBSD-release, NetBSD-current and formal releases. A formal release is an "official" release, while NetBSD-release is the formal release plus bug fixes for the next release. The NetBSD-current release is the cutting-edge, development version of NetBSD. The NetBSD team is pushing towards version 2.0. The fourth release candidate for 2.0 was tagged on October 8 with a final release expected soon. The current NetBSD release is 1.6.2, released on March 1, 2004.
OpenBSDOpenBSD has a reputation as one of the most secure OSes available, and the main OpenBSD page boasts "Only one remote hole in the default install, in more than 8 years!" The OpenBSD distribution also includes a wide range of cryptographic software and support for cryptography hardware. The OpenBSD team is also active in developing OpenSSH. The OpenBSD team issues a release roughly every six months. OpenBSD 3.6 was officially released on October 29, with a slew of new features, fixes and support for additional hardware. 3.6 adds SMP support for x86 and AMD 64-bit CPUs, a new Network Time Protocol daemon in the base system, and many bug and security fixes. The new release also includes an improved DHCP client and daemon, StackGhost overflow protection for OpenBSD/sparc, and a new hotplug daemon.
Dragonfly BSDThe new kid on the block, DragonFly BSD, forked off of the FreeBSD 4.x tree. DragonFly BSD 1.0 was released on July 12, 2004. The DragonFly team does not maintain separate stable branch as of yet, and DragonFly runs only on x86 hardware. The DragonFly BSD team has several goals for the distribution, including a better packaging system, and a different approach to system design:
It is our belief that the correct choice of features and algorithms can
yield the potential for excellent scalability, robustness, and
debuggability in a number of broad system categories. Not just for SMP or
NUMA, but for everything from a single-node UP system to a massively
clustered system... The existing BSD cores, including FreeBSD-5, are still
primarily based on models which could at best be called 'strained' as they
are applied to modern systems. The true innovation has given way to
basically just laying on hacks to add features, such as encrypted disks and
security layering that in a better environment could be developed at far
less cost and with far greater flexibility.
DragonFly has some lofty goals set for its caching, messaging API, and user API, but it may be some time before these goals are realized. The status page shows the relative development of each of DragonFly BSD's main goals. Readers interested in a history of the BSDs should visit the BSD Family Tree, which details the history of FreeBSD, NetBSD and OpenBSD, with a little about Apple's Mac OS X and Darwin thrown in for good measure.
Enterprise Linux: is it broken?Ever since Red Hat launched its "enterprise" distribution, complaints have been heard from many quarters. The enterprise distributions, it is said, go against the spirit of Linux: they include per-CPU licensing and simply cost too much. Even the vendors of proprietary operating systems sneer at enterprise Linux, stating that it is more expensive than their own offerings.The latest contribution to this debate is this white paper from Lineox. It states:
The Free Software developers created this software to empower
everyone, and for everyone to share. But today's Enterprise Linux
is a lock-in play, designed to draw the customer into expensive
subscriptions and single-vendor service. Customers are made to
agree not to pass service bulletins on to others. While this is
within the letter of the licenses that we crafted for our software,
it's outside of their spirit.
Few readers will be surprised to learn that the answer to this problem is support services offered by Lineox. The company seems, in particular, to want to attract current enterprise Linux customers with less expensive software update services. In other words, they want to capitalize on the enterprise distributors' work in creating the distribution and getting the customer to install it by poaching those customers at support contract renewal time. The attacks on enterprise Linux offerings do not seem entirely justified. One has to wonder just who is really harmed by these business plans. The first place to look might be the customers, who, after all, are paying significant amounts of money for enterprise contracts. Clearly these customers are finding something worthwhile; Red Hat sells hundreds of thousands of subscriptions, and, according to its first quarter results, the renewal rate remains above 85%. In a time when most companies are looking closely at their expenditures, RHEL subscriptions would be allowed to lapse if they were not considered worthwhile. One can claim that these customers are paying premium amounts for the Red Hat brand name. This may well be true; branding has been an explicit part of Red Hat's business plan since the Bob Young days. Customers take comfort in brands; this need not be a problem for people who feel themselves immune to the allure of any particular brand name. The per-CPU nature of RHEL subscriptions irks some people in the community. The restriction applies to support, however. If you just want the security updates, just get them directly from Red Hat's advisories and install them yourself. Red Hat has imposed no restrictions on the software which are inconsistent with its licensing; it is hard to see who is harmed by its activities. The enterprise distributions have not taken any choices away from people who choose not to use them. The quality of the freely-available Linux distributions has never been higher - and many of them offer support to match. Debian's release cycle may be slow, but the project has never dropped security support for its stable distributions in the mean time. Fedora offers many of the features of RHEL without the price tag or the wait; the project has also provided top-quality security support for Fedora Core 1 for the last year. Ubuntu promises bleeding-edge software and 18 months of support for free. SUSE, Mandrakesoft, Conectiva, and others provide reasonably-priced offerings. Companies like Progeny and Lineox, and projects like Fedora Legacy offer support that picks up where the original distributor leaves off. Any of these offerings makes a more than adequate platform for just about any business or personal operation. They have the same software as the enterprise offerings, and they benefit from the work of numerous hackers whose salaries are paid by enterprise subscribers. About the only things they lack are (1) branding, and (2) certifications from vendors like Oracle. Certainly the lack of an Oracle endorsement should not be a major problem for people who find enterprise distributions to be insufficiently free. It is not surprising that many people in the community feel no need for the enterprise offerings. It is unsurprising that some businesses are trying to undercut the enterprise distributors by selling cut-rate repackagings of the enterprise distributions and updates. But it is a little strange that some people feel such a need to condemn the vendors of enterprise Linux and undermine their business. Enterprise subscriptions have helped to bring Linux into new situations and fund the further development of free software, all without violating any licenses or restricting anybody's choices. It is not at all clear that the community would be better off if the enterprise products did not exist.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||