Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Now, I doubt that they will ever get there, but unlike a lot of management, it looks like Mark is getting the correct lesson from lean, agile, devops, etc.
Shuttleworth: Not convinced by rolling releases
Posted Mar 8, 2013 0:44 UTC (Fri) by fest3er (guest, #60379)
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.
Posted Mar 8, 2013 1:04 UTC (Fri) by dlang (✭ supporter ✭, #313)
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.
Posted Mar 8, 2013 2:07 UTC (Fri) by mmonaco (guest, #84041)
(Disclaimer: Arch Linux user)
Posted Mar 8, 2013 4:29 UTC (Fri) by dlang (✭ supporter ✭, #313)
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.
Posted Mar 8, 2013 19:13 UTC (Fri) by mike.cloaked (subscriber, #63120)
Posted Mar 8, 2013 20:42 UTC (Fri) by anselm (subscriber, #2796)
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 (subscriber, #1054)
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.
Posted Mar 8, 2013 10:48 UTC (Fri) by man_ls (subscriber, #15091)
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?
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.
Posted Mar 8, 2013 7:47 UTC (Fri) by bagder (subscriber, #38414)
Why exactly is that a real problem? Why would you do such a weird thing?
Posted Mar 8, 2013 10:05 UTC (Fri) by njwhite (subscriber, #51848)
Posted Mar 8, 2013 23:41 UTC (Fri) by HelloWorld (guest, #56129)
Posted Mar 9, 2013 11:17 UTC (Sat) by k3ninho (subscriber, #50375)
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.
Posted Mar 9, 2013 16:08 UTC (Sat) by nix (subscriber, #2304)
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
Posted Mar 8, 2013 10:35 UTC (Fri) by hummassa (subscriber, #307)
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.
Posted Mar 8, 2013 13:17 UTC (Fri) by pboddie (subscriber, #50784)
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.
Posted Mar 8, 2013 13:47 UTC (Fri) by niner (subscriber, #26151)
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.
Posted Mar 8, 2013 14:49 UTC (Fri) by pboddie (subscriber, #50784)
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.
Posted Mar 8, 2013 14:56 UTC (Fri) by niner (subscriber, #26151)
IIRC the same feature was already in 3.5.
Posted Mar 8, 2013 15:22 UTC (Fri) by pboddie (subscriber, #50784)
Posted Mar 8, 2013 16:53 UTC (Fri) by sebas (subscriber, #51660)
Posted Mar 8, 2013 22:09 UTC (Fri) by pboddie (subscriber, #50784)
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. ;-)
Posted Mar 8, 2013 22:14 UTC (Fri) by dlang (✭ supporter ✭, #313)
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)
Posted Mar 11, 2013 15:48 UTC (Mon) by nye (guest, #51576)
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 :(.
Posted Mar 11, 2013 15:58 UTC (Mon) by BlueLightning (subscriber, #38978)
Posted Mar 11, 2013 16:05 UTC (Mon) by mpr22 (subscriber, #60784)
Posted Mar 11, 2013 19:08 UTC (Mon) by pboddie (subscriber, #50784)
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.
Posted Mar 8, 2013 23:58 UTC (Fri) by alankila (subscriber, #47141)
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.
Posted Mar 9, 2013 16:09 UTC (Sat) by nix (subscriber, #2304)
Posted Mar 8, 2013 11:59 UTC (Fri) by jwakely (subscriber, #60262)
Why? I think 4.6.3 is a pretty solid release.
Posted Mar 8, 2013 15:05 UTC (Fri) by nix (subscriber, #2304)
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.
Posted Mar 8, 2013 12:14 UTC (Fri) by robert_s (subscriber, #42402)
You keep using that word, I do not think it means what you think it
Posted Mar 8, 2013 16:59 UTC (Fri) by sebas (subscriber, #51660)
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 © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds