LWN.net Logo

Ubuntu and Debian look forward

The Ubuntu 5.10 release is out, and the initial reviews are good. The Ubuntu team, however, is not taking time out to drink beer and relax before pondering its next release. Well, OK, maybe they are taking a little time. But, when the hangovers wear off, they are still putting some thought into their next release, which will break some new ground. Meanwhile, the Debian Project is looking forward to its next release as well. In both cases, the planning process gives us a hint of what to expect from these distributions in the near future.

Ubuntu's approach has been to crank out a distribution every six months, integrating a great deal of bleeding-edge software each time. This process has been through three cycles now, with obvious success. The next release (6.04, or "Dapper Drake") will be different, however: Ubuntu has stated that 6.04 will be supported for three years on desktops, and five years on server systems. That is quite a promise for such a young company to make, but, if Ubuntu can live up to it, the popularity of this distribution could grow. Thus far, five-year support has come with a hefty price tag; the prospect of free updates from Ubuntu for that long could make a number of companies wonder just what they are paying for. The fact that Ubuntu's security response time tends to be excellent can only help in that regard.

All this depends on Ubuntu being able to make a credible promise of long-term support. This week, Ubuntu's Jeff Waugh took some steps in that direction with these thoughts on the Dapper release process. If this proposal becomes policy, Dapper will, indeed, be a different sort of release.

The core of the proposed Dapper process is this: the upstream version freeze which was imposed for the 5.10 release will remain in place. Essentially, the distribution will be frozen for the next six months, with the bulk of development effort going into ensuring that it is the most stable, supportable release possible. Another way of looking at it is that all of those users happily downloading the Breezy release now get to be the beta testers for 6.04. This is a major change for Ubuntu, but, as Jeff put it:

We can't just follow the same release process and expect to be able to ship a long term supportable system. 6.04 will be different, so we need to think about it differently.

Of course, too much stability would be contrary to the Ubuntu spirit, so the developers are leaving themselves a bit of room to toss in some newer packages. So 6.04 will have a few, small upgrades, including:

  • GNOME 2.14 (and whatever is the current KDE)
  • Firefox 1.5
  • The modular X.org 7 release
  • OpenOffice.org 2.0
  • A newer kernel, probably 2.6.14

The list of exceptions is expected to be discussed at the upcoming UbuntuBelowZero gathering. The picture coming into focus now suggests that 6.04 will include some major upgrades, but much of the infrastructural code, especially that used on server systems, will remain at the version shipped with 5.10.

The Debian Project got its Sarge release out the door last June. By normal Debian timelines, it is thus quite early to be thinking about pulling things together for another release. Instead, Debian developers should be busily testing the patience of sid users by filling it with unstable, incompatible, major package updates. Well, the developers have indeed been on top of that task, but release manager Steve Langasek is trying to ruin the fun with this plan for the next Debian release, called "etch."

That release will be put together by Steve, along with new co-release manager Andreas Barth. They have a timeline, which involves a toolchain freeze at the end of next July, a general freeze in October 2006, and the etch release is planned, with great precision, for December 4, 2006. July seems like a distant prospect, but Steve notes that this deadline does not leave a whole lot of time for big changes:

What's not spelled out in the above timeline is that this basically leaves people until around the end of the year to to implement any dastardly plans they have that require sweeping changes to the archive, followed by another half a year of comparatively minor changes (you know, the kind that *don't* render half the libraries RC-buggy in a single upload...)

If this timeline holds, we should see the shape of the etch release by the beginning of next year. Looking at the current plan, it seems that etch will have made the switch to gcc 4.0 and (finally) X.org. Another long-delayed advance will be support for the amd64 architecture as an official Debian port. Then there is the crucial business of purging the distribution of non-free documentation, and non-free firmware as well. Tasks on the wishlist include full SELinux support, a default UTF-8 locale, multiarch support, and more.

The following eleven months of stabilization seem glacial by Ubuntu standards, but it is an optimistic timeline for Debian. One interesting change that the project is considering is to continue to allow non-maintainer updates to all packages throughout the etch cycle. Debian developers have historically been the lords of their particular bits of package turf, so non-maintainer updates have always been a sensitive issue. The release managers believe, however, that non-maintainer updates speed the release process - and make Debian a better distribution as well.

Both distributions have a lot to gain if they can make their plans stick. Ubuntu will have produced a stable distribution which it can credibly promise to support for five years, all while keeping its six-month release cycle. Debian, meanwhile, will be able to get a stable distribution out in a timely manner without compromising its high quality standards. In both cases, the end result can only be good for Linux users.

[Update: Ubuntu patron Mark Shuttleworth has posted his position on freezing for 6.04; he is inclined to be more permissive - for a while at least - on what gets into that release.]


(Log in to post comments)

Seems that Ubuntu and Debian get more similar again...

Posted Oct 17, 2005 22:30 UTC (Mon) by cantsin (guest, #4420) [Link]

...if Ubuntu forces such a stabilization process upon itself, and Debian speeds up its release cycle. This gives me some hope that a radical Ubuntu/Debian fork can be avoided.

(That said, it's fantastic what Ubuntu has achieved on the desktop. I installed 5.10/AMD64 on my mother's PC yesterday and am truly impressed by its automatic hardware recognition, graphical bootup, integration of the Gnome system tools, automatic media mounting and simple package update/installation tools. It's the first free desktop Linux with Mac(OS 7/8/9)-like simplicity, ease and usability. Conversely, I would never trade in Debian for my own Unixy, commandline-centric home PC and server setups. Both distributions complement each other perfectly and show how far free software has come.)

-F

Seems that Ubuntu and Debian get more similar again...

Posted Oct 18, 2005 2:04 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link]

That said, it's fantastic what Ubuntu has achieved on the desktop.

I'm mostly happy with Breezy (with KDE), though the upgrade did kill my home system by trying to load both the dpt_i2o driver and the I2O subsystem at the same time, which leads to a kernel panic. Even the Breezy Live CD panics on it.

The machine was tied up prior to the release so I couldn't do any testing on it, but I've put a bug report in now (17897) with a description of how I worked around it. I sure hope this gets fixed before the next kernel update! :-)

That said, KUbuntu works well on both my laptop and my machine at work!

Seems that Ubuntu and Debian get more similar again...

Posted Oct 18, 2005 8:22 UTC (Tue) by stijn (subscriber, #570) [Link]

> impressed by its automatic hardware recognition,

I wonder, how hard is this problem (hard presumably) and how easy is it to deduplicate efforts between different distributions to solve it? Or is it an inevitable exercise that each has to solve on its own?

Seems that Ubuntu and Debian get more similar again...

Posted Oct 18, 2005 10:29 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link]

I wonder, how hard is this problem (hard presumably) and how easy is it to deduplicate efforts between different distributions to solve it? Or is it an inevitable exercise that each has to solve on its own?

This is one of the beauties of open source, if everyone working on this has compatible licensing then anyone can pick the best bits and tricks from others for what they need.

But from my experience things like hotplug, udev and the device-mapper are fairly pervasive across modern distributions.

Seems that Ubuntu and Debian get more similar again...

Posted Oct 18, 2005 13:52 UTC (Tue) by nix (subscriber, #2304) [Link]

Well, not hotplug, soon, one hopes, since udev is meant to supplant it. :)

Seems that Ubuntu and Debian get more similar again...

Posted Oct 18, 2005 18:49 UTC (Tue) by gurulabs (subscriber, #10753) [Link]

udev is not replacing hotplug. Take a look, you'll see that udev is launched by hotplug.

hotplug is a standardized kernel to userland interface (netlink is another).

udev is purely userspace.

Seems that Ubuntu and Debian get more similar again...

Posted Oct 18, 2005 19:45 UTC (Tue) by nix (subscriber, #2304) [Link]

Well, if you're talking about the kernel hotplug interface, of course it's pervasive across Linux distributions, because the Linux kernel is; and indeed udev won't work without it.

I thought you were referring to the hotplug scripts, which are moribund.

Seems that Ubuntu and Debian get more similar again...

Posted Oct 20, 2005 9:21 UTC (Thu) by gallir (guest, #5735) [Link]

New versions of udev replaces hotplug. Ubuntu Breeze has a relatively old
version. Check it out.


Seems that Ubuntu and Debian get more similar again...

Posted Oct 18, 2005 21:10 UTC (Tue) by drag (subscriber, #31333) [Link]

With 2.6 series kernel it seems to be standardizing... I mean in Debian I don't have to install kudzu or discover or anything like that anymore to detect hardware or load anything. I expect that it will be like that for most distros.

The 'best practices' thing is definately at work here. Knoppix benifits Ubuntu benifits Debian benifits Knoppix benifits Debian benifits Ubuntu etc etc etc. For hardware detection I think that Knoppix helped out a lot as well as stuff developed with the help of Freedesktop.org.

Now with /sysfs, udev, hotplug, hal, d-bus, and the like we are able to not only get the kernel modules loaded and /dev files configured but they allow individual programs themselves respond well to new hardware. (after adding your user to camera group) I can plug in my camera and the gnome desktop detects it and launches a nice little program for me to deal with it as a example.

Things that I see that need big improvement is getting X.org to use Linux hotplug and related stuff. X is off in it's own little land right now, practically it's own OS in the way it has it's own hardware configuration and drivers that are seperate from anything the OS itself does. Getting it to be able to respond to new hardware like mouse button configuration, wacom tablet, keyboard configuration and even monitor detection, would be very cool. I think that modular X will go a long way to making this easier.

Then the only other thing that I can think of is getting distros to automaticly setup stuff like dmix software mixer plugin and get rid of the last OSS-only audio program holdouts. Most new sound cards don't support software mixing, most people just use on-board nowadays, and it realy gives the 'hey it's 1995 again' impression when they try to start up a mp3 song player and it won't work becuase the browser took over the sound card with flash or mplayer or whatnot. Just say no to OSS! (sound, not open source software) Problems with sound cards with no hardware mixing capabilities are probably one of the most common problems that I see people asking about on forums and such. Maybe a new type of sound deamon or whatnot, but in reality dmix works if it wasn't for OSS-only programs and programs that default to OSS setup instead of Alsa... and OSS has been obsolete/depreciated for years now.

I used to say 'get a card that doesn't suck', and tell them about dmix and point them to a webpage about setting it up and that's all I could realy do for them.. but it's tough sell when only 1 out of a 100 new sound cards support the nessicary features to get Linux to work with them properly.

Seems that Ubuntu and Debian get more similar again...

Posted Oct 22, 2005 1:37 UTC (Sat) by set (guest, #4788) [Link]

You dont even have to set up dmix anymore, recent versions of alsalib
are smart enough to do software mixing automaticly. Recent discussion
on lkml is proposing janking OSS out. Alsa's OSS emulation cant solve
the mixing problem, though, so we are probably stuck with 'sound daemons'
and legacy OSS software for a while yet...

Seems that Ubuntu and Debian get more similar again...

Posted Oct 22, 2005 2:29 UTC (Sat) by csamuel (✭ supporter ✭, #2624) [Link]

Alsa's OSS emulation cant solve the mixing problem, though

Is that can't as in is not possible with the architecture or as in nobody has implemented it yet?

Seems that Ubuntu and Debian get more similar again...

Posted Oct 24, 2005 10:19 UTC (Mon) by jdthood (subscriber, #4157) [Link]

dmix is currently not able to do everything a sound daemon does. dmix does not provide mixing capability on all kinds of hardware. Unfortunately this means that sound daemons will continue to be required for some time yet.

Ubuntu and Debian look forward

Posted Oct 18, 2005 5:56 UTC (Tue) by drag (subscriber, #31333) [Link]

That Debian release goal seems very ambitious to me. It seems that Debian had very strong dates set in this time...

If they are able to get Etch out into stable by the end of next year I think that such a thing will be one of the best possible things to ever happen to Debian and a great boon to Free software community.

It'll be very interesting to see how the 'pet projects' come along and how many make it into etch. (hope that none hold back the release in any way though.) Things like redoing the init script proccess into a dependancy checking one, utf-8 locales by default, full SELinux support, and so on and so forth. That should give Ubuntu plenty of reasons not to make a full fork (as if the 20,000+ packages they include aren't enough)

Bravo!

Posted Oct 18, 2005 19:29 UTC (Tue) by b7j0c (subscriber, #27559) [Link]

I'm glad to see scheduling issues in Debian given attention. Debian is the most important distribution because so many other groups use it as a baseline for downstream products. Even if users are not installing Debian itself, many of us are relying on Debian to make progress.

Also big cheers to Ubuntu, my desktop of choice. My distro-envy is gone, I don't feel the need to "try out" something else to gain some minor advantage. I have been totally satisfied with it, and the UbuntuForums.org site has never failed to answer my questions.

Ubuntu and Debian look forward

Posted Oct 20, 2005 2:35 UTC (Thu) by allesfresser (subscriber, #216) [Link]

Any chance of getting a switch in the installer that makes it install the -dev packages for each package, or something like that? It's a royal pain in the {body part of choice} to get Ubuntu set up for development, at least in my experience. It's nice that they're making it very easy for non-developers to get running, and I heartily applaud them for the achievement, but could we do something to improve the -dev package support? Feel free to post ways to get all the dev packages for e.g. KDE, Gnome, PyGTK, CLISP, whatever, installed at once, if I'm missing something...

Ubuntu and Debian look forward

Posted Oct 20, 2005 2:52 UTC (Thu) by sbdep (subscriber, #13282) [Link]

apt-get build-dep kdelibs4 will install all the dev packages needed to build kdelibs, which covers just about everything for building most kde applications.

You can do similar with a core gnome package to pull in most of the gnome stack.

Default UTF-8 locale

Posted Oct 20, 2005 23:30 UTC (Thu) by emj (guest, #14307) [Link]

UTF8 is nice but the application support is oh so bad.
  • Gnome can't read my files in non UTF8 folders
  • Mysql can't handle it in fulltext search.
  • irssi doesn't convert
  • ssh doesn't handle remoting to latin1 system
  • The virtual consoles of Linux doesn't support them out of the box for me.

Default UTF-8 locale

Posted Oct 21, 2005 3:23 UTC (Fri) by dvdeug (subscriber, #10998) [Link]

For ssh, use screen. I don't know why the virtual terminals don't work; have you tried unicode_start?

Default UTF-8 locale

Posted Feb 24, 2006 17:06 UTC (Fri) by sorpigal (subscriber, #36106) [Link]

Or try uxterm. It always gives me keybinding issues, but it does do unicode.

Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds