Potential Idea (Since it seems like Ubuntu is being completely restructured)
jon at grossart.net
Wed Mar 6 20:59:56 UTC 2013
So, first off, I'm not an Ubuntu developer. And my Linux/Ubuntu
experience is basically playing with in Virtualbox and installing as a
dual-boot on a few systems. So, if I get some of the technical details
wrong, don't jump all over me. This is just from the perspective a very
knowledgeable computer user, yet still novice Linux user.
The problem I've always had with Ubuntu is that with the way it worked,
you had to upgrade everything when you went a new release (to get
updated software), or you had to stay back on older software if there
was something you needed (say, older video driver--especially closed
source one for full features). How often does a new Gnome, KDE, Firefox,
gimp, etc need a new kernel or X.org (more irrelevant now with Mir) and
The old method of LTS and periodic releases didn't really help this.
LTSes were starting to once things like Firefox started to get
backported. The new rolling release type idea doesn't help this -- in
fact, it might make it worse since you'll always be at the leading edge.
So, my proposal would be a hybrid approach. Which makes it follow more
of the Windows/OSX style of really releasing an OS with apps being
separate instead of the monolithic complete system that ships now.
1) break Ubuntu into cores
- base OS: kernel, boot, init, most drivers (maybe graphics drivers)
- graphics: graphics drivers, Mir/x.org -- these might have to be
separate channels, or graphics drivers might be in the base OS
- desktop environments
- other applications -- Firefox, GIMP, Libreoffice, etc.
2) each core has choice between stable, current, devel/unstable
- LTS would be equivalent to stable
- rolling release would be current
- devel would be where everything new gets uploaded
3) allow individual packages to bump up channels from the core it's part of
4) PPAs could still be used for very cutting edge things
5) for at least the base os/graphics, DEs, you could still have periodic
cut points that people could be pin to (whether that's the old 6 mo or
the LTS 2 years). These pinned points would only get security updates
for the support period.
This way, if someone has working, older hardware that may or may not be
getting anymore updates (like older graphics cards), then can pin the
appropriate core to stop upgrading. As long as nothing in the other
cores is dependent on something newer, they can still float to newer
Someone could stay on a tested, stable kernel and DE if they want while
still having newer applications.
Someone else could stay on a lock down the display portion if there
graphics card stopped being supported while letting everything else
float on (until a depedency issue arises, which they would be notified
This might help out some of the flavors as well. They would still be
able to upload/break things in the devel channel (opening it up to a
larger audience for testing), while people could be on the newest
official release in the current channel as soon as it's ready to go.
This would definitely make the infrastructure more complex, but it frees
up the bigger picture of allowing the OS to be as stable or up to date
as someone wants.
Of course, it's just an idea and I providing it as food for
thought--please tear it apart.
More information about the ubuntu-devel