Revisit the question of the 700MiB CD limit

Registered by Colin Watson

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)

Blueprint information

Status:
Complete
Approver:
Steve Langasek
Priority:
Essential
Drafter:
Colin Watson
Direction:
Needs approval
Assignee:
Colin Watson
Definition:
Approved
Series goal:
Accepted for oneiric
Implementation:
Implemented
Milestone target:
milestone icon oneiric-alpha-3
Started by
Kate Stewart
Completed by
Colin Watson

Related branches

Sprints

Whiteboard

Work items:
[cjwatson] Convert CD images to hybrid CD/USB images: DONE
[vorlon] Further investigate feasibility of increasing CD limit to 703.125 MiB: DONE
[allison] Prepare USB seeds: DONE
[cjwatson] Switch DVD images over to USB seeds: DONE
[cjwatson] Clarify naming/presentation of new-style DVD images: DONE

[vorlon] http://en.wikipedia.org/wiki/CD-ROM#Capacity indicates that a "700MiB" CD is 360,000 sectors of 2048 bytes each (+error correction). This is 703.125 MiB rather than the 700MiB limit we currently enforce on cdimage.u.c.

pitti, 2011-05-26: Is this missing some WIs to trim down the DVD to a magnitude of 1.5 GB, or has this goal been dropped?

Historical reference for the currently-enforced size limit is: https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027275.html

[rr0hit] Maybe what Fedora guys did with Fedora-15 could be followed. http://fedoraproject.org/w/index.php?title=Features/LZMA_for_Live_Images . They achived 19% better compression for the Desktop spin.

[broder] LZMA has been discussed in the past (https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-squashfs-lzma-redux) but rejected. LZMA is a good enough compression algorithm that it breaks our current ability to do incremental syncs from one daily build to the next, which is necessary for QA.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.