Weekly Edition
Return to the Distributions page
| |||||||||||||
Ubuntu to halve support length for non-LTS releases (The H)
The H reports
that support for Ubuntu's non-LTS releases will be shortened to nine
months. "In a meeting
of the Ubuntu Technical
Board last night, the technical leadership of Canonical's Linux
distribution decided to halve the support time for non-LTS releases to nine months. At the same time, the developers want to make it easier for users of the distribution to get up-to-date packages on a regular basis without the need to perform explicit upgrades of the whole distribution. Attending the meeting, Matt Zimmerman, Colin Watson and Stéphane Graber unanimously agreed on these points and also clearly voted against moving Ubuntu into a rolling release model. The changes will be implemented in the maintenance schedule starting with the release of Ubuntu 13.04 ("Raring Ringtail") on 25 April."
(Log in to post comments)
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 19, 2013 22:01 UTC (Tue) by Lukehasnoname (subscriber, #65152) [Link]
== Votes ==
* Enable users to continuously track the development focus of Ubuntu without having to explicitly upgrade
* Enable users to continuously track the development focus of Ubuntu as a "rolling release" rather than having to explicitly upgrade
---
I'm not clear on the first bullet point. Does this mean they won't require "apt-get upgrade" on the system just to get one package to update?
Any details on how they'll accomplish that? And what is the middle ground between "more flexibility in package updates" and "rolling release"?
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 19, 2013 22:58 UTC (Tue) by tjc (subscriber, #137) [Link]
I took it to mean that things which previously required 'apt-get dist-upgrade' to install can be installed with 'apt-get upgrade'. But I could be completely wrong.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 19, 2013 23:36 UTC (Tue) by dmitrij.ledkov (subscriber, #63320) [Link]
If one reads the full meeting notes, you will notice that at first a vote was done on a question that included "rolling release" term in it, but TC liked the proposal but not the "rolling release" label, thus they: voted -1, removed reference to rolling release, voted +1.
The details are fuzzy and pending implementation. It is not quite sure if it means: "without changing sources.list" (example SRU/security updates today) or "packages keep the same name", (example SRU/security updates today) or "additional ppa/archives will need to be added" (example Cloud Archive for new OpenStack releases) or "people will need to installed renamed package" (example quantal kernel/X stack in precise is renamed with -lts-quantal suffix).
Please note that only part of the proposal was debated and voted upon. The Technical Committee will meet again in two weeks to continue the rest of the proposal.
Many implementation details will be then announce by respective teams involved: Release Team, Stable Release Updates team, Security Team, Archive Maintainance Team, QA and etc.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 18:36 UTC (Wed) by geofft (subscriber, #59789) [Link]
That can't be it. "dist-upgrade" as a name is entirely a historical accident, and pretty irrelevant today.
"upgrade" means update all packages currently installed, as far as possible, but don't install any new ones.
"dist-upgrade" means update all packages currently installed, but be willing to install new ones.
It just so happened that "upgrade" was the first thing implemented in apt, and when people needed to upgrade between releases, they realized that "apt-get upgrade" wasn't going to work because new releases brought in new dependencies. In practice, nobody had been adding dependencies within a Debian stable release. But as it turns out, adding dependencies is actually a useful thing to be able to do within stable releases, so in general the current recommendation is to use "dist-upgrade" regardless and forget that "upgrade" exists. (aptitude calls it "full-upgrade" for this exact reason.)
The process of upgrading between distro releases, on Ubuntu at least, is preferably done with do-release-upgrade, not any apt-get command (although I've done it with apt-get dist-upgrade and been fine). Certainly apt-get dist-upgrade doesn't _change_ what release you're on, so you need to do that manually.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 1:41 UTC (Wed) by heijo (guest, #88363) [Link]
So that means non-rolling release for the core OS, rolling release for non-core-OS applications?
Also known as the model all other OSes use?
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 6:14 UTC (Wed) by Richard_J_Neill (subscriber, #23093) [Link]
What it basically means is trouble.
Generally, it's a bit risky to jump into a new release the very minute it comes out, usually safer to wait 1 month, especially if it's your primary or only machine.
So... 6 months between releases (sometimes nearer 7), and 9 months of support, so there's now going to be only a 2 month window in which we have to do an upgrade, lest we lose security patches? No chance to skip a version, even when something (eg the initial GNOME3 release) turns out half-baked
I do hope that they will keep critical patches going for 18 months, at least for anything that could have a remote-root type hole.
Rapid (or rolling) releases are basically a great idea because it means that when the end-users find bugs, they are reporting new bugs rather than ones that are already fixed upstream, and they benefit from the fixes. It significantly reduces maintenance work, and means everyone benefits from the latest features. BUT, it is going to need some rather careful management, so that another radical change (eg GNOME2->GNOME3, or PulseAudio, or KDE4), isn't bundled onto unsuspecting users alongside the updates they expect (eg bugfixes in coreutils, the latest firefox, or a python point-release).
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 7:25 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Changes like GNOME2->3 would be perfectly OK if they were parallel-installable.
Adding one more alternative to the desktop manager is not a problem, forcing users to upgrade in the middle of a release cycle definitely is.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 8:23 UTC (Wed) by seyman (subscriber, #1172) [Link]
> Changes like GNOME2->3 would be perfectly OK if they were parallel-installable.
Wouldn't that require 2 different Gnome stacks ? How would a distribution handle binaries (ie would /usr/bin/nautilus be the gnome3 version or the gnome2 one) ?
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 8:43 UTC (Wed) by abo (subscriber, #77288) [Link]
Yes, that's what MATE does. (Its Nautilus fork is installed as /usr/bin/caja)
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 12:39 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Distros should do it by providing two binaries ('nautilus' and 'nautilus3').
Another alternative (used in Windows and Mac OS) is to install another Nautilus in a separate directory, but for whatever reason it's not widely used on Linux-based systems.
co-installability Posted Mar 20, 2013 15:15 UTC (Wed) by sebas (subscriber, #51660) [Link]
You need to change binary names, library versions, and maybe a few other pathes, so I'd advise doing it in collaboration with downstreams. It is entirely doable though, but a little more (and quite boring) work.
We did this with KDE3 and KDE4, and many users were understandably rather thankful for that. :)
Still, users depend entirely on what downstreams *want* to offer, for example some distros (hi Fedora!) didn't ship KDE3, even when it was entirely possible from our POV. That didn't make us many friends from those camps.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 15:49 UTC (Wed) by drag (subscriber, #31333) [Link]
> Wouldn't that require 2 different Gnome stacks ? How would a distribution handle binaries (ie would /usr/bin/nautilus be the gnome3 version or the gnome2 one) ?
Basically, yes.
This was the biggest mistake Gnome devs made. They did a good job of ensuring backwards compatibility for applications by supporting parallel GTK2 and stuff like that, but they didn't allow for user backward compatibility. They had reasons for wanting it done this way, unfortunately users are more important if you want to make sure that they are taken care of.
This forced people to make projects like Mate to fill in the gaps.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 9:26 UTC (Wed) by Cato (subscriber, #7643) [Link]
Given that Ubuntu sometimes breaks things quite severely (e.g. Intel graphics drivers) it's hard to see using a non-LTS Ubuntu again - if there is serious breakage in any new release that isn't fixed, that means you have a choice of a broken system or no security updates.
I'd really like to see a strong separation between 'platform' and 'application' packages, with the latter being upgradable across releases much more easily. I mostly use Linux for servers these days, so risk of breakage is not so bad, but I still need latest release of Python, Django, PostgreSQL, etc, and building from source can be painful. Some sort of separate 'application' package store, preferably across distros and widely accepted (I know there are many candidates) would be great - somewhat like homebrew/ports on Mac perhaps?
(Recently tried building csync and unison on Debian and Mac and failed completely to get both sides to build and work correctly.)
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 16:21 UTC (Wed) by drag (subscriber, #31333) [Link]
We can't depend on distro package management solution because we need the ability to not only support multiple versions of the same application stack on different systems, but we also need to have the ability to roll back changes rapidly if things don't go well.
The solution they have come up with is rather painful. It involves building all the application packages from scratch and installing the rpms to different directories named after the date of the build or the version number of the application. Then have separate post-install scripts that run a bunch of symbolic links out to the system at different points in the file system.
This way we can have multiple versions of the package installed at the same time and it's very quick to roll back or patch systems as all that is needed is to destroy and build a new set of symbolic links.
I can't imagine what it would be like to have to support different versions of the same application across a standardized OS install for the desktop. Different groups with different needs and all that happy stuff. Servers are significantly simpler to manage in this regard and it's already somewhat painful.
I am looking forward to the day when the easiest way to upgrade a the few desktop applications I use on a regular basis doesn't involve downloading a new ISO image for a OS installer.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 18:09 UTC (Wed) by wookey (subscriber, #5501) [Link]
"I am looking forward to the day when the easiest way to upgrade a the few desktop applications I use on a regular basis doesn't involve downloading a new ISO image for a OS installer."
This has never been necessary on Debian.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 11:07 UTC (Thu) by drag (subscriber, #31333) [Link]
> This has never been necessary on Debian.
apt-get dist-upgrade is worse, actually.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 16:14 UTC (Thu) by hummassa (subscriber, #307) [Link]
> apt-get dist-upgrade is worse, actually.
how come? And those days, it's not "apt-get dist-ugprade", but muon upgrader saying "oh, you have these 200 packages to update, let's do it now?", you clicking on "ok", "====>----- x% progress", "=========> 100%, installing", wait for it, (if one of the packages was the kernel) "you need to reset the machine, at some time in the future."
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 18:47 UTC (Thu) by drag (subscriber, #31333) [Link]
Because I want to have the ability to manage a single application without having to manage the entire OS. I want to have the ability to use abritrary versions of abritrary applications in a safe manner regardless of whether or not I am using the 'blessed' version of the OS they were compiled for.
It doesn't support rollbacks. I can't just say "Oh, this application has a incompatibility with a file format that I use, I'll uninstall it and install the older version".
It doesn't help the fact that many of the applications I use don't have a debian package maintainer building it.
> And those days, it's not "apt-get dist-ugprade", but muon upgrader saying "oh, you have these 200 packages to update, let's do it now?"
Don't care. It just makes it easier to do something that I shouldn't have to do in the first place.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 20:34 UTC (Thu) by wookey (subscriber, #5501) [Link]
We know you don't like the whole distro scheme, but I still don't see how being able to do 'apt-get install <package>' and get that updated (plus potentially quite a few other things) or even a dist-upgrade, is _worse_ then downloading a whole new iso-image and re-installing, which is what you claimed above.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 22, 2013 1:51 UTC (Fri) by hummassa (subscriber, #307) [Link]
> Because I want to have the ability to manage a single application without having to manage the entire OS. I want to have the ability to use abritrary versions of abritrary applications in a safe manner regardless of whether or not I am using the 'blessed' version of the OS they were compiled for.
This does not exist, maybe in source-only distros... Too many variables.
> It doesn't support rollbacks. I can't just say "Oh, this application has a incompatibility with a file format that I use, I'll uninstall it and install the older version".
This actually works in Debian with checkpointing-enabled filesystems.
> It doesn't help the fact that many of the applications I use don't have a debian package maintainer building it.
Which applications are those, if I may ask?
> Don't care. It just makes it easier to do something that I shouldn't have to do in the first place.
It also makes you upgrade programs with security vulnerabilities and give you the option of only upgrading what you want.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 22, 2013 8:15 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> This actually works in Debian with checkpointing-enabled filesystems.
But it's all-or-nothing, right?
What I find I'd like to have is being able to upgrade AND downgrade all installed packages belonging to the same source package.
But what drag wants is a distro where everything is compiled statically, AFAICT :)
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 22, 2013 8:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> But what drag wants is a distro where everything is compiled statically, AFAICT :)
or at least, that's what he thinks he wants. I'll bet that if he ever tried to use such a distro, he would quicly become dissatisfied with the horrible overhead (memory footprint, and time needed to load all these libraries into memory, etc) that this would result in.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 16:33 UTC (Wed) by whiprush (subscriber, #23428) [Link]
For servers (especially platforms like Django, rails, etc.) we're working on the Juju Charm Store that will let you deploy stacks on Ubuntu server, defaulting with what's in the archive but ideally having an option of deploying from PPA, upstream trunk, etc.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 16:36 UTC (Wed) by dbenamy (subscriber, #39458) [Link]
For users who want longer support cycles so there's more mature code and less pressure to upgrade, there are LTS releases.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 14:12 UTC (Wed) by leomilano (guest, #32220) [Link]
Maybe they should keep the LTS releases every two years, and add a regular release on the odd years. That is, drop to an annual pace. That, plus PPAs, ought to keep everyone (large OEMs, small OEMs, bleeding edge users, stable OS users, etc) happy, I would think! There could be a bleeding edge kernel PPA in case you purchase new hardware. Wouldn't that cover all bases and release some of the burden at Canonical?
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 14:19 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
PPAs are notoriously incompatible with each other. Especially for infrastructure components like scripting languages.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 15:06 UTC (Wed) by leomilano (guest, #32220) [Link]
Oh, good point, I didn't know. I use PPAs selectively, for instance to keep my KDE up to date, and haven't come across issues, but I see how people could hit binary incompatibilities. Cheers!
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 18:31 UTC (Wed) by wookey (subscriber, #5501) [Link]
Exactly. This is the whole issue. Either you integrate things so that everything works together and is upgraded 'together' (actually sort of 'piecemeal but general moving forward'), or you let components be upgraded separately, but then there is no guarantee than an arbitrary set of components will work together, because the total combinatorial interface-space is huge, and only a small portion of it can ever realistically be tested. Debian and Ubuntu undertake to cover quite a large portion of that interface space, but only so long as your packages comes from their distro repos.
Backports cover another segment of the possible interface space.
I too would like to see more attention given to the ability to go backwards as well as forwards. It's not something that enough attention is paid to, because people are usually going forwards, and that's usually fine. If that was reliable then upgrading things you were perfectly happy with would be less of an issue.
I'm really not convinced about this whole 'core-OS' and 'apps' with a fixed interface between them view of the world. It may be currently popular, but it involves an awful lot of static bundling and that's not something I see as a good thing.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 18:52 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
As the time passes, bundling becomes less and less problematic. Even phones now have 2G of RAM so it's hard to occupy a significant amount of RAM with the executable code and even then stuff like KSM can help here.
Perhaps, selecting a small amount of packages and then guaranteeing forward and backward compatibility is the way to go.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 19:18 UTC (Wed) by mpr22 (subscriber, #60784) [Link] There are more important reasons why bundling is problematic than "uses more disk and RAM".
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 20, 2013 20:09 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
The other big reason is security, but we're moving towards the world where all applications are untrusted and sandboxed by default anyway. Besides, we can be 100% sure that most of the popular apps are vulnerable anyway.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 11:15 UTC (Thu) by drag (subscriber, #31333) [Link]
> Exactly. This is the whole issue. Either you integrate things so that everything works together and is upgraded 'together' (actually sort of 'piecemeal but general moving forward'), or you let components be upgraded separately, but then there is no guarantee than an arbitrary set of components will work together, because the total combinatorial interface-space is huge, and only a small portion of it can ever realistically be tested. Debian and Ubuntu undertake to cover quite a large portion of that interface space, but only so long as your packages comes from their distro repos.
The solution is API layers.
Linux kernel shows us how to do it through having a strict no-internal-api combined with a strict stable-external-api.
So Linux distributions have to decide what their portion of the 'OS'. And then maintain API stability with anything anybody wants to run on top of that.
The biggest step is going to be having the distributions stop compiling everything and learn to pull binaries directly from upstream providers for most of their applications.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 15:16 UTC (Thu) by etienne (subscriber, #25256) [Link]
> The solution is API layers
IMHO, in Unix/Linux, the API is /usr/include (that is why this directory is quite "high" in the hierarchy) - if anything incompatible at the binary level is changed there, you have to recompile all software which did the "#include".
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 18:50 UTC (Thu) by drag (subscriber, #31333) [Link]
Everything you said is extremely terrible. There is no reason it has to be like that.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 21:01 UTC (Thu) by wookey (subscriber, #5501) [Link]
But the kernel is just one interface. A largish one, but still one thing. It's practical to make sure things work with that interface and compatibility breaks are rare (they do still happen - udev has had to be synced with some kernel upgrades, and initramfstools).
But if you try to do this for a much larger piece of the system then you now have ~100 packages-worth of stuff (or maybe 400 or 1000 - depends what you call a core system). And you've got to manage all the possible interface pieces between them and any other software. I think that's a significantly harder job.
And it still doesn't help you with all the pieces outside this box, which still have to arbitrarity work together, unless you are saying that no program that is not part of the OS-layer can have anything to do with any other program that is not part of the OS layer? I'm not sure that's practical. It's OK if all your programs are glorified web-pages or contacts apps (actully that's a tricky one - it has to talk to many other programs), but if your programs are databases, compilers, CMSes, extra language support, UI integration tools, language modules, or web-service pieces and so on, it all gets very sticky quite quickly.
And how are we going to define the OS-layer in a way that satisfies most people? It's easier if your target is 'single user handheld mobiles' than if it's everything from deeply embedded widgets through routers, cars, mobiles, servers, kiosks, laptops, and desktops to supercomputers. Those user groups have very varied ideas of what constitutes a 'core OS'.
It's not that I disagree with the essential concept of your pony - it would be nice, and is clearly desired by at least some people; it's just that I don't see how to deliver it reliably. Nor am I convinced that that world would actually be better in practice than the one we currently have.
But then I like distro world. It satisfies my needs excellently. Yeah sometimes the fact that upgrades bring in other stuff is irritating, but it's never a showstopper. Usually there are backports, add-on repos or PPAs to deal with the awkward cases and I still get the core system reliability.
I guess if linux distros ultimately disappear and everyone really is running Android or something similar then you were right and I was wrong, but I don't see that happening for at least another 10 years.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 3:13 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
there's not much practical difference between 9 months of support and 12 months of support, in each case you need to upgrade with each release.
18 months of support was enough to allow people to skip a release.
being able to skip a release when a distro is introducing major new features (be they Unity, Mir like Ubuntu or Gnome 3 like Fedora) that may end up needing more polishing then they get when first releases.
of course, this is assuming that running a 'supported' distro really has any meaning to people. The older I get the less I believe this. They may _say_ it matters to them, but end up using just about any excuse to delay an upgrade (and I include businesses in this, not just individuals, including very large businesses)
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 17:34 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
I end up skipping a release of Fedora on my work laptop without really meaning to just based on the scarcity of the number of round toits I'm allotted. The personal laptop and more critically the spouse's personal laptop I seem to keep up with.
I just can't seem to justify to myself taking the time dealing with an OS install on the clock at work every six months, even though I personally desire it and have the freedom to do it. I guess deep down I feel like if I'm on the work lappie I should be, you know, doing work. And if I'm not going to do work, wtf would I even boot up the work lappy at all instead of going out and using my personal time to deal with anything other than work? But maybe I'm unique and noone else has that sort of internal conflict.
-jef
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 17:42 UTC (Thu) by dark (subscriber, #8483) [Link] Just look at it this way: the work laptop is a tool that you use to do your work, and maintaining your tools in good condition is part of the work. Chefs spend time cleaning and sharpening their knives, etc.
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 21, 2013 18:02 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
sure I _maintain_ my laptop. Apply updates, make backups, clean off the caked on cheetos orange powder from the keyboard.
But I look at the OS upgrade as more akin to trade-in on leased physical equipment to upgraded models. I do not want to change my office chair or desk every 6 months and to experience the break-in of having to get physically comfortable with same but different ergodynamics. Nor do I want to change my phone every six months, nor do I want to change my physical laptop device every six months.
It's turned out, simply based on my day-to-day experience that the OS upgrade cadence which works for me is about a year. Which to be honest about it is probably about the maximum speed I'd want to upgrade physical devices in my workspace to new models. If the IT department replaced the cisco phone on my desk every six months with newer models with upgraded UX/UI I'd go ballistic on them even if the UX/UI were technically better.
-jef
Ubuntu to halve support length for non-LTS releases (The H) Posted Mar 22, 2013 12:45 UTC (Fri) by jond (subscriber, #37669) [Link]
I like your metaphor, but it really doesn't fit. If you sharpen a knife you end up with the knife, sharpened. If you update your OS big chunks of it might be swapped out for replacements (GNOME 2 to 3 is one example) and you can enjoy the next 6 months learning a new workflow, until the next release replaces it again. (as happened with sysvinit -> F13/upstart → F15 systemd)
|
|||||||||||||