| |||||||||||||
Ubuntu to halve support length for non-LTS releases (The H)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)Parent article: Ubuntu to halve support length for non-LTS releases (The H)
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).
(Log in to post comments)
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.
|
|||||||||||||