Moving on

Once upon a time, installing Linux on a new computer was a tiresome process requiring a couple dozen floppy diskettes. In 2012, finding a floppy-installable distribution is not an easy task, but few users mind; finding a new system with a diskette drive is even harder. The Linux community was able to leave diskettes behind without a great deal of discontent. Now, though, there are a couple of similar transitions looming that may be a little harder to get past. A number of distributors are struggling with the question of when older hardware can be left behind and what can be done for the users of older systems who are inconvenienced by the change?

In the Debian camp, Steve McIntyre recently raised the alarm: there appears to be no way that the upcoming "wheezy" distribution will fit onto a single CD, at least if one wants a GNOME or KDE desktop environment. Debian, it seems, may have to consider alternatives to those CDs; these could include requiring multiple CDs (bringing back memories of the old floppy days), requiring the use of DVD or USB media, or only supporting a combined CD/network installation. All of these options would have the effect of making Debian less accessible to users with older hardware, a change that is not seen as being desirable in the Debian camp.

As it happens, Debian may have another option: use XZ compression in its binary packages. The additional space gained by this move is impressive—down to about 2/3 of the size achieved with gzip. The biggest downside would appear to be the need to rebuild much of the Debian repository, which is not a small task. But, for the wheezy release, XZ may help the project to avoid some more difficult choices.

But any such gains will clearly be temporary; the size of the software shipped by all distributions is clearly on the increase. This is not just a problem for Debian; Steve Langasek noted that Ubuntu 12.10 will be the first Ubuntu release that will not fit on a CD. In the Fedora camp too, "some folks" are pushing for the abandonment of the CD image for the Fedora 18 or 19 release. Some developers are arguing for a stronger push back against software bloat, but, in general, the consensus seems to be that putting a working distribution with a contemporary desktop environment onto a single CD is an increasingly impractical thing to try to do.

One might well argue that, in an age when bottle openers come with 16GB of storage, worrying about an old medium with capacity measured in megabytes makes little sense. Finding a system that only supports CD as a boot medium is, at this point, possibly even harder than finding one with a floppy drive. There seems to be little point in limiting the size of the installation image to 700MB when computers with such limitations have not been sold in some time. At least, no point unless one's wish is to constrain the overall size of the system in general.

The problem, of course, comes in two forms: old systems and limited network bandwidth. In the parts of the world where distribution hackers tend to be found, CD-only machines are hard to come by. In many other areas where people would like to use Linux, such machines are still in use. One can argue that contemporary Linux distributions may not run well on such limited hardware anyway, but it would still be better to avoid making life harder for the owners of those machines. Network bandwidth also matters: for many people, downloading a full DVD-size image can still be a long and painful exercise; an image limited to CD size has a higher chance of being fully downloaded before the link goes down or other users become too grumpy. Forcing a multi-gigabyte download on such users is not a good way to win friends.

The best answer in this case may be to provide a minimal bootstrap CD image that can then perform an installation from either the network or a USB drive. That allows the installation image to grow for the large numbers of users who can benefit from more software on the installation media while not excluding those who have more limitations. It seems like an approach that can provide the best solution for nearly everybody involved.

The Debian community has been pondering a related question: is the time coming for the distribution to move away from 32-bit builds for the x86 architecture? Ben Hutchings recently posted a proposal to that effect, noting that most new systems have 64-bit processors, and that the number of 64-bit ("amd64") installations has nearly equaled the number of 32-bit installations. Ben would like to see the 64-bit kernel installed by default in the wheezy release and, after perhaps two or three more release cycles, no more 32-bit x86 kernels built at all. These are Debian-length release cycles we are talking about, so the end of 32-bit kernels is far from imminent, but it's still near enough to get attention. (This proposal would not end the building of 32-bit user space, which can run just fine on a 64-bit kernel).

Certainly there are a lot of good reasons to go with a 64-bit kernel on contemporary hardware. Even if user space runs in 32-bit mode (or the upcoming x32 mode), an option that works nicely at this point, a 64-bit kernel will run more efficiently for a number of reasons. Given that there are fewer and fewer reasons to use a 32-bit kernel, perhaps Debian should stop putting resources into building such kernels.

Here, though, the situation is not quite so clear cut. As some developers pointed out, 32-bit-only x86 systems are still shipping. Ubuntu considered moving to a 64-bit kernel for the 12.04 release, but backed off after somebody noticed that 25% of the submissions to the Ubuntu Friendly hardware database came from 32-bit machines. 32-bit processors are still well established in the x86 world, so it seems unlikely that distributors will be able to stop supporting them anytime soon.

The fast-moving nature of technology ensures that distributors will continue to face these questions indefinitely. In general, Linux distributors have erred on the side of keeping support for old hardware; few distributors want to alienate potential users. But supporting older systems is not free; those systems can place constraints on what can be packaged, slow down performance on newer systems, take up developer time, and present testing challenges when nobody has the relevant hardware around anymore. So there comes a point where older systems have to be cut loose. Some newer-style distributions (CyanogenMod, say) are showing signs of having less patience with older hardware—arguably an unsurprising decision for a project supporting well over 50 separate targets. Expect more discussions like the above as distributors try to make the most of their limited development and build resources.

---

(Log in to post comments)