Potential Idea (Since it seems like Ubuntu is being completely restructured)

Jon Grossart 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 
vice versa.

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 
packages.

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 
about).

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.

Jon



More information about the ubuntu-devel mailing list