User: Password:
|
|
Subscribe / Log in / New account

Shuttleworth: Not convinced by rolling releases

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 0:44 UTC (Fri) by fest3er (guest, #60379)
In reply to: Shuttleworth: Not convinced by rolling releases by dlang
Parent article: Shuttleworth: Not convinced by rolling releases

The past four years were a period of relative stability in open source software. Most things just worked together nicely. But we're now entering another period of instability and upheavals. GCC 4.6.x were unusable; v4.7.2 seems to be better. Glibc 2.15-2.17 are unusable; I'm sticking with 2.14.1. More and more packages are refusing to be built by root, and burying this fact deep inside and late in the configure process. Iptables is going through another period of great change. Even OpenOffice/LibreOffice are becoming unusable; KDE *is* now unusable. There's too much being moved around and changed; it will take time for the rest of the OSS world to catch up.

Working to enhance and update a firewall distro, I know what is involved. If you leave out the kernel, binutils, gcc, glibc, udev, grub, iptables and a few other core packages and concentrate on just one 32/64 bit arch, then it might be possible to keep most of the userspace software up-to-date on a rolling basis. Maybe even the kernel could be updated a couple times a year. But it will never be possible to update *everything* on a rolling basis.

To put it simply, OSS instability is unpredictable. To be fair, it seems that there is a period of OSS upheaval every 4-5 years followed by 3-4 years of relative calm. If you can set a rolling release's base near the end of a 'calm period', then you might be able to ride out the storm of upheavals in the base packages while continually rolling out releases of packages that remain fairly stable.

But if 'rolling release' means to jettison the stable core/foundation, the product will end up about as stable as an ark in a hurricane.

Remember: users want systems that work, systems that have fairly stable interfaces. They don't want to relearn how to use their computers as tools every few months or years. Poorly planned rolling releases will put people on the roller coaster of heavy seas when they *really* want to be in their cozy offices using their computers as tools to make money.


(Log in to post comments)

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 1:04 UTC (Fri) by dlang (subscriber, #313) [Link]

I don't think that we are really disagreeing on the goals (although since I am using a KDE desktop right now, I disagree with the statement that it's "unusable" :-)

People want their systems to work. if an upgrade breaks things, it's a problem

However, Mark is correct when he says that one of the lessons that people keep re-learning is that if you have a hard thing to do (in this case, shipping a solid release), focusing on the problem and figuring out how to make it more reliable and easier to do so that you can do it more frequently results in many unexpected benefits.

Remember when Kernel releases were very infrequent "when it's ready"?, moving to a much more frequent release has resulted in a much more reliable kernel, as well as drastically increasing the development speed.

Mark raises the question "could they make releases more frequently", if they can continue to drive down the time between releases, at some point it becomes indistinguishable from a "true rolling release" I put the ultimate limit at 'daily releases', but realistically, if they made 12 releases a year (with good reliability and without breaking users), would that be very different from a true rolling release? I think it would be much closer to a rolling release than the current six month schedule

As to the cause of the upheavals right now, far too many projects don't care about backwards compatibility, and the result is breakage. There is not going to be any way to fix such projects other then for them to get smarter, or for them to be replaced.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 2:07 UTC (Fri) by mmonaco (subscriber, #84041) [Link]

One major reason to do a "release" is that you'll support the included versions by packing bug-fix releases. I got the feeling from Mark's article that the hardness he was referring to was coordinating to do a release, not the difficulty of maintaining X versions of a package. Does the Ubuntu community have the manpower to maintain even more active releases? Would monthly releases mean that the non-LTS support window will be cut much shorter?

(Disclaimer: Arch Linux user)

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 4:29 UTC (Fri) by dlang (subscriber, #313) [Link]

remember that I'm the one who suggested eventually getting to monthly releases, not Mark.

As I see it (and I could be wrong) the support time is based on allowing people who don't want to do every upgrade to upgrade at a more comfortable pace.

faster releases may eventually address that, but it will take time so I would expect that support would not shorten soon, if at all

But the conditions for going to a really fast release cycle would be that the upgrades are bulletproof for the users, so support may shorten

After all, almost all users are comfortable (and for the most part unaware) of their browsers getting upgraded at a rate that would have been unthinkable 10 years ago, but it took making the upgrade seamless for the user (and some teething problems) to get to that point.

I wouldn't expect to see any change in the pace of releases through 2014, but if they are concentrating on trying to get the releases easier and more reliable

but keep in mind, fast releases by themselves make doing upgrades easier because you don't have to change everything every release. If they were to do monthly releases they would only change kernels every 3 releases (if that frequently), same with glibc and gnome. That makes it easy to say that you don't change any two of these key components in the same release, which greatly simplifies testing, upgrades, etc

It also would greatly reduce the pressure to get something that's not really ready into a release as it doesn't hurt as much to back it out and try again in the next release (or the one after that)

It will be interesting to see what (if anything) comes out of this.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 19:13 UTC (Fri) by mike.cloaked (subscriber, #63120) [Link]

So there is a big discussion going on in the Ubuntu world about whether or not to go to a rolling release model - but right now ArchLinux is already a successful rolling release distribution. ArchLinux has excellent developers and the rolling release system works - even with occasional manual intervention needed periodically it is always very up to date without the pain of annual or more frequent complete re-installs from scratch which is a massive advantage compared to non-rolling-release-distributions. So not only is the question of whether or not it is possible to do a rolling release it is demonstrably successful!

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 20:42 UTC (Fri) by anselm (subscriber, #2796) [Link]

it is always very up to date without the pain of annual or more frequent complete re-installs from scratch which is a massive advantage compared to non-rolling-release-distributions

I use Debian, which is a »non-rolling-release-distribution«. I do not do »annual or more frequent complete re-installs from scratch«. Upgrading works just fine and has for a long time.

Debian: Rolling-release distro?

Posted Mar 11, 2013 16:28 UTC (Mon) by Max.Hyre (guest, #1054) [Link]

I use Debian as well, and I follow the unstable branch, doing a dist-upgrade every evening. How much more rolling would you like? :-)

True, I don't use it for production (read: anyone but me depends on it), and I check the list of changes before throwing the switch, because every few months there may be a case where some things would happen that I don't want to follow. Usually waiting a couple of days straightens it out.

Nonetheless, but it’s what I run on my main computer, and I don't remember the last time it was even close to being hosed— at least a couple of years.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 10:48 UTC (Fri) by man_ls (guest, #15091) [Link]

I put the ultimate limit at 'daily releases', but realistically, if they made 12 releases a year (with good reliability and without breaking users), would that be very different from a true rolling release?
Why stop at daily releases? I have embraced the paradigm of continuous delivery and it's not a buzz word, it's really useful. Every push to the repo results in an integration, a run of the test suites and a deployment. Guess what? It works! We made 10~20 deployments per day. Much more stability than with weekly or daily releases, and the very rare breakage is solved in 15 minutes (since we know exactly what broke: the latest push).

A true rolling release should take validation very seriously and run its tests 24/7. I don't know if it's feasible at the scale of a whole distro, but many people are trying it at ever-growing scales (see e.g. this blog) and have not been disappointed. Also, Debian testing (when not frozen) is a good example.

So the key point in the quoted sentence is "good reliability and without breaking users", and continuous delivery has the potential of being better than daily or monthly releases.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 7:47 UTC (Fri) by bagder (subscriber, #38414) [Link]

> More and more packages are refusing to be built by root

Why exactly is that a real problem? Why would you do such a weird thing?

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 10:05 UTC (Fri) by njwhite (guest, #51848) [Link]

Indeed. While it seems odd and unnecessary for the build scripts to care, I can't imagine a good use-case for building as root.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 23:41 UTC (Fri) by HelloWorld (guest, #56129) [Link]

There was once a bug in some build system which contained something like "rm -rf /$foo". It turned out that under certain circumstances, $foo could be empty. It's easy to imagine when you run something like that as root.

Shuttleworth: Not convinced by rolling releases

Posted Mar 9, 2013 11:17 UTC (Sat) by k3ninho (subscriber, #50375) [Link]

>There was once a bug in some build system which contained something like "rm -rf /$foo". It turned out that under certain circumstances, $foo could be empty. It's easy to imagine when you run something like that as root.

The solution to that bash anti-pattern is to create an if-safe-delete function that you know you can trust, and then to use it at the places you might delete /. Write the if-variable-is-empty comparison once, correctly, and record its existence it in the man pages for eternity, so everyone can side-step failures from this.

K3n.

Shuttleworth: Not convinced by rolling releases

Posted Mar 9, 2013 16:08 UTC (Sat) by nix (subscriber, #2304) [Link]

This is also a reason why you shouldn't run installs as root if you have a choice either: use something like fakeroot, then mv into place (possibly repeating anything with systemwide effect the package did, like ldconfig). This is annoying, but necessary :( (doubly necessary with some core packages, like glibc, where if you do a raw 'make install' of a working glibc you are quite likely to end up with an unusable system!)

Not that using a package manager necessarily saves you. An old Solaris bug springs to mind, which thankfully never bit me:

4137237 patchadd 106300-01 results in rm -rf / as root

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 10:35 UTC (Fri) by hummassa (subscriber, #307) [Link]

> KDE *is* now unusable.

Care to elaborate on this? as a day-to-day, 16hours/day KDE (as of yesterday, 4.10.1) user, I find this difficult to imagine. KDE & its apps are, to me, some of the finest in the whole software scene.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 13:17 UTC (Fri) by pboddie (guest, #50784) [Link]

I wouldn't go as far as to say unusable, but as a KDE 3.5 user (at home and work) who has had the experience of setting up KDE 4.x (whatever Kubuntu ships), even though the applications may have reached feature parity with those they replaced (and some may be better), one has to wonder where the last few years went when it comes to elements of the "desktop shell" usability.

The most blatant example of this is the panel, which provides a bizarre array of ineffective controls to change the size that not only fail to do so in a reasonable way, but also look as if they came straight out of a mediocre "god game" on the Commodore Amiga. And even then, they don't seem to permit the thing to occupy the full width of the screen without the clock wanting half of it.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 13:47 UTC (Fri) by niner (subscriber, #26151) [Link]

Just add a panel spacer widget somewhere left of it. Then the clock moves to the far right.

For me KDE 4 fixed the remaining annoying desktop bugs of 3.5. Most important: I use a separate panel for the task manager in the bottom left corner growing up. This frees space on the main panel and gives enough space for window titles. On KDE 3.5, the icons on the desktop move right by the width of this task manager on every login, even though the latter allows windows to cover it. This bug has never been fixed on 3.5.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 14:49 UTC (Fri) by pboddie (guest, #50784) [Link]

I thought I tried the panel spacer, and maybe it more or less did the job, acting like some aggressively spring-loaded gadget but also squashing other applets, but none of this is an improvement over the control of panel applets and icons in KDE 3.5. One would have thought that the usability experts would have stumbled across something nicer than the "it's stuck to the mouse, how do I get it off?" paradigm for configuring the panel arrangement.

I also don't think it helps that the applet chooser (or whatever it is called) is a long thin window that sits above the panel and has to be scrolled large distances horizontally. It's not as if the remaining 90% of the screen is unavailable to show the available applets because we have to keep an eye on the progress of our city/civilisation/spaceships. Also the choice of horizontal scrolling must surely be some kind of joke in the age of the scroll wheel.

And let us not dwell of the function of the scroll wheel as a workspace switcher when the mouse points at the desktop background. A neat hack for some, but when the scroll area of a trackpad maps to the same function, it's like some kind of cruel experiment for many groups of users. "Why does the screen flicker and I sometimes lose all the windows?" Because someone thought it necessary to be able to "scroll" through 50 workspaces in one finger movement.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 14:56 UTC (Fri) by niner (subscriber, #26151) [Link]

Right click on the desktop, Default Desktop Settings / Mouse Actions / Vertical Scroll. Click on Remove.

IIRC the same feature was already in 3.5.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 15:22 UTC (Fri) by pboddie (guest, #50784) [Link]

I did manage to switch it off, but I was just saying that enabling niche features like this by default isn't exactly an encouraging statement of usability progress. In 3.5, I think this only happens if you have the pointer over the pager, which is bad in itself, but not yet another trap set for the less-than-totally-confident user just trying to get his/her pointer to move across the screen.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 16:53 UTC (Fri) by sebas (subscriber, #51660) [Link]

This "niche feature" was on in 3.5 already. I personally find it hugely annoying (as you do), but as with any such things, we get complaints when we change these settings by the vocal crowd of people who claim that 3.5 was the best thing since sliced bread (which says more about their memory, than about bread).

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 22:09 UTC (Fri) by pboddie (guest, #50784) [Link]

Well, I don't see any sign of it in my settings: I looked in the desktop settings as well as in many of the system settings dialogues. I didn't actually use a mouse with a wheel at home until recently, but neither my home nor work desktops suffer from this, so either Kubuntu and Red Hat switched this off or it just wasn't there to begin with, especially since in the former case I had no reason to even switch it off until recently after I first knew of the feature from KDE 4, so it should be enabled by default and exhibit the effect, but that just isn't the case. Maybe I was "in the zone" and in a fit of rage sought it out and hit the switch, but I'm doubting that right now.

I appreciate that people don't like change, which is probably how my remarks are interpreted, but sometimes one has to eliminate disastrously bad features just to avoid the need to have someone hovering behind new users helping them turn all the bad stuff off. And 3.5 still rules, by the way. ;-)

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 22:14 UTC (Fri) by dlang (subscriber, #313) [Link]

on my kubuntu system I just tested and found that it is on.

That being said, I have never knowingly run into this issue before, so it doesn't matter much to me, but I can see why others would care about it (either to love it or hate it)

Shuttleworth: Not convinced by rolling releases

Posted Mar 11, 2013 15:48 UTC (Mon) by nye (guest, #51576) [Link]

It was definitely in all of the 3.5 releases that I recall, but it was not in the first couple of KDE 4 releases (and then there was at least one release in which it was there, but didn't actually work).

I know this because I found it incredibly frustrating to use the system without it.

I'm constantly saddened by drives to remove all the features that differentiate Linux from Windows for me, in the name of the mythical 'new users'. This has already reached the point where I don't bother to use Linux on my home desktop any more; at some point I'll probably end up having to give up on it at work as well :(.

Shuttleworth: Not convinced by rolling releases

Posted Mar 11, 2013 15:58 UTC (Mon) by BlueLightning (subscriber, #38978) [Link]

That's not why features got "removed" in KDE 4. Features unfortunately disappeared because a lot of the workspace code was rewritten from scratch; as time went on they were added back in. For the most part KDE 4 has surpassed the feature set of 3.x by now, so assuming you are a KDE user why give up now?

Shuttleworth: Not convinced by rolling releases

Posted Mar 11, 2013 16:05 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

Binding scrollwheel motions on the root window to "switch desktop" is an excellent feature which (a) is well worth including in a way that makes it easy to enable (b) is no longer a sane default, regardless of whether it was a sane default when it was first added.

Shuttleworth: Not convinced by rolling releases

Posted Mar 11, 2013 19:08 UTC (Mon) by pboddie (guest, #50784) [Link]

Well, I just looked again and I can't find how to switch this feature on or off in KDE 3.5, so unless someone can actually point me to the dialogue in question, I'll take my own experiences with my current desktop over people's recollections.

As for whether it's a useful feature, I'm sure people do like it, but I've always been happy with the Ctrl-F<n> shortcuts and don't use the equivalent workspace-cycling shortcuts that are equivalent to the scrollwheel actions.

I also take exception to the "only new users would hate this" insinuation. First of all, new users might like it if it didn't impact them because of the mousepad scrolling region functionality, which is another area that you either love or hate regardless of whether you are new to computers or not. It is almost like pressing the wrong part of the space bar and experiencing the same effect as holding down Alt-Tab.

But I can see the point of it: you might want to navigate by depth which either means navigating the window stack or navigating workspaces, and the mousewheel provides that extra dimension of navigation. What is quite clear, however, is that no-one thought that this potentially useful function would "leak out" and damage usability elsewhere. We get lectured all the time about how the smart usability people know much more than us, but either the people exposed to the feature with a mousepad during testing were comfortable with it already (and probably using a mousepad they were already familiar with) or it didn't get usability tested in that environment at all.

My regret is that we're still having to deal with such annoyances when we could have moved far beyond them instead by now.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 23:58 UTC (Fri) by alankila (guest, #47141) [Link]

Your comments would mirror mine. I am a relatively happy and new user of KDE 4.10.1 now, and have configured the keybindings to mirror macbooks as far as possible. I got to admit it's awesome to be able to do this, I can use Linux a whole lot like it were OS X at least when it comes to cut, paste, copy, new tab, close tab, etc. operations.

Almost everything bad about KDE (for me) follows about it having too many options, which makes everything ridiculously cluttered and ugly to look at. Therefore a lot of things can be fixed just by disabling everything that can be unchecked. I disable most keybindings, remove most applications, disable most window title bar buttons, etc.

Shuttleworth: Not convinced by rolling releases

Posted Mar 9, 2013 16:09 UTC (Sat) by nix (subscriber, #2304) [Link]

... while I do the opposite and turn most of the bells and whistles on (other than searching/semantic desktop stuff because it *still* doesn't work if $HOME is on NFS). One size really, really does not fit all.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 11:59 UTC (Fri) by jwakely (guest, #60262) [Link]

> GCC 4.6.x were unusable

Why? I think 4.6.3 is a pretty solid release.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 15:05 UTC (Fri) by nix (subscriber, #2304) [Link]

Yeah. Heck, I put off upgrading to 4.7.x for ages because 4.6.x was so solid.

glibc 2.17.x doesn't seem particularly 'unusable' to me, either. It's more usable than the 2.14.x lauded above because the sunrpc stuff is once more linkable against, reverting a pointless compatibility break that bit you if you ever tried to rebuild nfs-utils.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 12:14 UTC (Fri) by robert_s (subscriber, #42402) [Link]

> unusable

You keep using that word, I do not think it means what you think it
means.

Shuttleworth: Not convinced by rolling releases

Posted Mar 8, 2013 16:59 UTC (Fri) by sebas (subscriber, #51660) [Link]

Reading your comment, the instability and rythm you claim do not reflect my experience. In fact, none of the pieces of software or versions you name caused *any* upheaval on my systems. That's not to say there weren't any, Pulseaudio probably being one of the more painful changes in the landscape, for example, and there were a few others. Yet I don't get the feeling that my system becomes unstable every so many years and then stabilizes again. It depends a lot on what you run, and what you do of course, but your general statement does not resonate with me at all.

I don't think that has anything to do with rolling releases though, Rolling Release doesn't mean "ship whatever upstream has just released", but providing a constant stream of updated software. You don't have to ship anything that you deem good enough, and finding out what is and isn't is a matter of testing it with your usecases, or having a group of experienced users run it and report problems. It's certainly a bad idea to "blindly trust upstream, ship it and pray".


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