Summary

This comes up nearly every cycle, but is worth discussing: revisit whether it is feasible to maintain the 700MiB CD limit on Ubuntu images, or whether we need to shift to a larger image format. Consider:

The pressure imposed by new features such as Unity 2D, GTK+ 2/3, the ability to include more language packs, etc.

The effect of a less universal format on usability of Ubuntu, especially outside the developed world

The discipline imposed by a 700MiB limit, and what limit might be used instead and why

Any measures that can be taken to make more space in the existing images

Policies that we might impose in future (for example, a "balanced budget" requirement for new features)

This has been a controversial discussion, as expected. Please do not make edits to this page advocating one position or another or discussing details as in the Etherpad notes, as it will quickly become unreadable; instead, please use a talk page linked from this one.

Release Note

Ubuntu CD images may now be written directly to USB storage media using tools equivalent to dd. Programs such as Startup Disk Creator are now only needed if you wish to allocate additional persistent storage.

The following changes were suggested, but we will not be making them in this cycle:

Download manual pages from the Internet when they are needed

This amounts to about 21 MiB on the squashfs spread across 508 packages, and manual pages are an item that is particularly useful to sysadmins in offline situations. It is unlikely to be an effective use of time to split these out.

At some point, it might be worth moving translated pages to language packs (about 5 MiB).

Ship the compiler only on the DVD?

The compiler is specifically shipped on the CD for a single purpose: building kernel drivers to get a user onto the network (normally via a DKMS package, rather than expecting the user to invoke the compiler directly). This remains useful for common wireless drivers such as Broadcom, and so we should keep the compiler on our standard images.

However, due to an oversight involving aptdaemon and lintian, the dpkg-dev stack (including g++-4.5 and libstdc++6-4.5-dev) ended up on Natty CD images. We will unpick this dependency chain, saving a considerable amount of space (at least 7 MiB uncompressed).

Use a different compression algorithm

We frequently receive the suggestion that we should use LZMA for the squashfs (as Fedora has started doing recently). However, LZMA is a sufficiently efficient algorithm that it renders rsync ineffective for reducing download sizes of successive builds. With our highly-distributed QA processes and the fact that many of our developers are a considerable distance away from a mirror in terms of network bandwidth and latency, this would be a serious impediment to Ubuntu development, and so we do not plan to make this change at this point.

Colin also suggested removing the LibreOffice Calc application from the default installation (4 MiB uncompressed). No decision was taken on this, so we will hold it in reserve.

Image format

The single-CD form factor has been controversial at one level or another since the foundation of the Ubuntu project, and there has long been pressure to move to a USB or DVD format instead. Discussing this from time to time is healthy. The typical arguments for changing are:

Many modern systems (especially netbooks) no longer include optical drives

When they do, it is often a DVD drive

Some hacks would be unnecessary if not for the space constraint

We could include much more software by default in a larger image

Typical arguments against changing are:

Larger downloads put more users off, especially outside areas with very fast network connectivity (your humble narrator is in a developed-world city and yet has only a 1.5 Mb/s downlink, typically taking two to three hours to download a full CD image, so we should be careful about making generalisations even about everyone in the developed world ...)

A larger image takes longer to install (especially with Wubi, but not exclusively)

A larger image tends to imply a larger installed footprint and greater resource consumption, while a constraint implies a certain amount of lean-and-meanness

The Ubuntu DVD images currently consume most of the available space on a typical single-sided single-layer DVD (4.3 GiB), largely due to deliberately being a superset of the desktop, alternate, and server images. This is not an intrinsic property, and we could trim them down to something more in the area of 1 GiB if we were using these as our standard image format.

Shipping CD images is not exclusive of shipping USB images. We currently instruct people that they can use usb-creator with an Ubuntu CD image to produce a USB image. This is a certain amount of work and is not as good as shipping an image which works as a USB image directly. In Oneiric, we will finally ship hybrid CD/USB images which can be used as either, so USB users will not be disadvantaged. (usb-creator will still be useful for creating live USB images with persistent storage of modifications.)

Mark has indicated that he is a fan of "the laws of physics" - that is, the enforced limit of a CD image is better at keeping us within reasonable resource limits than an arbitrary limit for particular ranges of USB storage media.

Of course, in this case the laws of physics are the laws of engineering, and thus a little bit stretchier. Overburning has been common for a number of years, and we may be able to move to 720 MiB without significant side effects. (Five years ago this was demonstrably a problem for some people, but that may no longer be the case.) Alternatively, http://en.wikipedia.org/wiki/CD-ROM#Capacity indicates that a "700 MiB" CD is 360,000 sectors of 2048 bytes each (plus error correction), which is 703.125 MiB rather than the 700 MiB limit we currently enforce.

Decision: For Oneiric, we will remain with the CD form factor, but add hybrid USB booting. We will do our utmost to keep size down, and believe we still have many tricks up our sleeves that do not involve removing significant functionality. If necessary, we will break the 700 MiB limit and move to 703.125 MiB, or perhaps 720 MiB (in the latter case, probably trickling the extra space in over more than one release cycle).