Weekly Edition
Return to the Distributions page
| |||||||||||||
Shuttleworth: Not convinced by rolling releases
On his blog, Mark Shuttleworth weighs in at some length on some of the issues that have been swirling in the Ubuntu community over the last few weeks. He thinks there has been some unwarranted melodrama surrounding Ubuntu, Canonical, decision making, and so on. In addition, he is not convinced that rolling releases are the right approach.
But cadence is good, releases are good discipline even if they are hard. In LEAN software engineering, we have an interesting maxim: when something is hard, DO IT MORE OFTEN. Because that way you concentrate your efforts on the hard problem, master it, automate and make it easy. That's the philosophy that underpins agile development, devops, juju and loads of other goodness.
In the web-lead world, software is moving faster than ever before. Is six months fast enough? So I think it IS worth asking the question: can we go even faster? Can we make even MORE releases in a year? And can we automate that process to make it bulletproof for end-users? (Log in to post comments)
Shuttleworth: Not convinced by rolling releases Posted Mar 7, 2013 23:36 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
and a true rolling release is when doing a release is something so easy that they can do it daily.
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) [Link]
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.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 1:04 UTC (Fri) by dlang (✭ supporter ✭, #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 (guest, #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 (✭ supporter ✭, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (✭ supporter ✭, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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
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".
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 0:08 UTC (Fri) by ewan (subscriber, #5533) [Link]
Well that clears the air. Because obviously, if you look at what's been swirling around Ubuntu just recently, the big noise has been all about rolling releases.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 1:31 UTC (Fri) by rsidd (subscriber, #2582) [Link]
He talks about going it alone on Unity too. He doesn't mention Wayland/Mir but presumably the argument is analogous.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 1:37 UTC (Fri) by hadrons123 (guest, #72126) [Link]
I am using Arch linux and it works perfectly than anything else. I don't know what you guys are talking about.
If Mark is not convinced its *his* problem. It doesn't mean ubuntu can't do rolling releases and sustain the same users. The same applies to Fedora as well.
If Arch linux, gentoo, open Suse(tumbleweed) can do it, why not Ubuntu or Fedora?
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 1:48 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
I actually switched away from gentoo on my home system after being unable to rebuild the box after an upgrade failure. They got so entrenched in the 'rolling upgrade' process that they dropped the ball on the 'new or rebuild install' process
They may have fixed this by now, it's been a couple of years.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 6:47 UTC (Fri) by jke (guest, #88998) [Link]
I think there's a lot of misconception about rolling releases. I see a lot of talk from the Ubuntu world about whole distribution releases or y number of releases per x amount of time. It's really not the way to look at rolling releases. Rolling releases are about the continuous releasing packages as they become ready.
With Arch Linux we don't talk about releases unless we're talking about the release of individual upstream projects. For the most part, we don't have large groups of packages that release all at the same time unless that's how it comes from upstream. This happens for example with KDE, for example.
If you're trying to put a version number on your distribution, you're not really rolling.
Given that Shuttleworth opposes them, ... Posted Mar 8, 2013 1:39 UTC (Fri) by HelloWorld (guest, #56129) [Link]
... they're probably a great idea.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 8:33 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
Google and Mozilla can update their browsers frequently due to extensive test suites and very easy ways to try theirs betas and alphas. So a lot of people do that. But even then Mozilla was forced to release Firefox ESR with a yearly support cycle.
Automatic testing is not feasible for a distribution given the variety of software and hardware they are facing. Therefor it is even more important to have enough feedback from users. However, trying a new distro version is harder and takes more time than testing a browser. With shorter release cycle there would be too time for feedback.
A possible solution is to allow parallel installs of packages together with associated config files so a user can selectively try new packages and go back to the older version if something goes wrong. This at least makes it more likely that somebody would test things. But I do not see anything like that in Ubuntu plans.
Rolling testing Posted Mar 8, 2013 12:06 UTC (Fri) by man_ls (subscriber, #15091) [Link] Automated testing is not impossible, it is just harder. And it needs not be the only testing; Debian testing is a good example of how to do things.After all Ubuntu is not developing most of its software, just integrating and packaging it.
Rolling testing Posted Mar 8, 2013 12:37 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
> Automated testing is not impossible, it is just harder.
How one can automatically test that, for example, on a random laptop sound works or the video has proper white balance or the laptop can pair with a random bluetooth device in various supported bluetooth applications? Or one can install on a server with some strange BIOS quirks?
In those cases it is best to ask the user. But for that one needs easy to use infrastructure to try new things without breaking stuff that currently works. Plus one has to listen to the feedback. Without these things one simply would not get enough test data for the rapid release.
> Debian testing is a good example of how to do things.
Debian testing works if one releases every couple of years at best. For rapid releases one has to do much better.
Rolling testing Posted Mar 8, 2013 12:49 UTC (Fri) by man_ls (subscriber, #15091) [Link] You cannot test sound on a random laptop, obviously; but you can check that there is a sound module loaded at boot on a certain set of laptops, not too much problem. Also, for this particular problem Ubuntu is using an industry-standard, well tested kernel for a reason.For the rest of the distro a couple of machines would be enough to test that packages are downloaded and installed, and then that apps start correctly. Getting detailed info about every bug in a package is quite harder, but that would be an area where a distro has to cooperate with upstream. Finally, manual testing à la Debian is great. I don't mean "Debian testing" as a concept, but the Debian "testing" distro (right now frozen): packages are uploaded to unstable, then migrate to testing after 10 days if there are no show-stoppers (where the manual part comes in). For me Debian testing it has worked as a rolling distro for the last 10 years.
Rolling testing Posted Mar 8, 2013 23:02 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
> but you can check that there is a sound module loaded at boot on a certain set of laptops, not too much problem.
How would one pick up laptops? And what about older hardware that may be still popular but it hard to get?
So I just do not see how one can skip user during testing. Surely with unlimited amount of time one can try to solve that problem, but with a more realistic budget spending efforts to simplify testing by users would be more fruitful.
Rolling testing Posted Mar 8, 2013 23:17 UTC (Fri) by man_ls (subscriber, #15091) [Link] Both automated and end-user testing are needed, always. Anyway hardware is the province of the kernel, and they are quite efficient solving this kind of bug. I doubt that Ubuntu patches many sound card bugs nowadays in their kernels.
Rolling testing Posted Mar 8, 2013 23:43 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
> Anyway hardware is the province of the kernel
I wish that would be true. ALSA has many (way too many IMO) knobs that the user space can influence and both Fedora and Ubuntu touch them. Or consider BlueTooth. The kernel support is rather generic it is up to the application framework to deal with various devices. Unfortunately the result is that one may have two devices that require different Linux distros to get them working...
Rolling testing Posted Mar 8, 2013 16:55 UTC (Fri) by jke (guest, #88998) [Link]
> Automated testing is not impossible, it is just harder.
Harder than it should be, IMO.
The testing needs to be in the upstream. It shouldn't be a mess of afterthought and duplicated effort on the part of distributions. Your upstream is probably going to be better at it anyway having the benefit of being intimately familiar with the code and being the recipient of much broader feedback than any one distribution alone.
Again we see the reoccurring wisdom of being part of your upstream as much as possible.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 21:15 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> But even then Mozilla was forced to release Firefox ESR with a yearly support cycle.
and Ubuntu has the LTS releases, nobody is talking about eliminating them.
by the way, where is the demand for google to do something similar with Chrome?
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 23:18 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
> by the way, where is the demand for google to do something similar with Chrome?
Google had benefits of hindsight and created a browser that had almost no extensions API initially, came with a very extensive test suite backed by their ultimate knowledge of Web and from the beginning had a working feedback channel. That allowed them to do the updates without breaking the web while very gradually and carefully exposing more internals for customization as they see the demand. And any breakage they could quickly see and fix.
Still many businesses avoid Chrome exactly because of the lack of a long-term support.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 13:11 UTC (Fri) by lmb (subscriber, #39048) [Link]
I'm convinced that true rolling releases - continuous delivery on the side of the distribution - is exactly the right approach for the future. Packages should be merged when they are ready and pass all tests. (Depending on the component, that could mean different things and possibly even a chunk of packages to merge a whole feature block if dependencies exist, etc.)
Not "just" for the desktop, but also and in particular for enterprise.
Note that "rolling release" does not mean "shortened support cycles for features or less backwards compatibility." That'd be continuous delivery done wrong.
I really wish a distribution would dare that.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 16:26 UTC (Fri) by ebiederm (subscriber, #35028) [Link]
Supply me with a complete automated proof that the package meets all of it's requirements and I might be convinced that automated testing alone is sufficient. Until that time there need to be human beings in the loop who look at things in different ways from the developer giving feedback.
Fundamentally technical solutions alone are inadequate.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 16:37 UTC (Fri) by lmb (subscriber, #39048) [Link]
You will note that I did not include the word "automated" in my comment. That was surprisingly deliberate.
A large number of issues *can* be caught automatically. And I believe overall we're doing way too little automated testing. If you've ever looked at most projects, that is hard to deny; there are huge wins to be had here.
Clearly, not all of the issues can. Neither can everyone run all tests. That requires a distributed approach to testing: running automated tests where they can run (e.g., availability of the hardware or the license key to test compatibility), and perhaps a canary release to a beta tester group whose feedback then (automatically ;-) allows the update for wider distribution. This could (and should) include not just running the code but also source code level patch inspection.
And if the workload is running inside a VM, clone it (and its data), apply patch and see if workload still runs, feed result back.
To anticipate your point, not all analysis of these test results can be automated either. And yes, it should gather not just functional (yes/no) data but also performance, memory usage, etc. Why stop at the simple. ;-)
In short: no, centralized automated tests aren't enough. Even though it'd be amazing if we had more of that already. That does not invalidate continuous delivery.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 17:48 UTC (Fri) by drag (subscriber, #31333) [Link]
What people really want is the ability to run new software.
What they REALLY REALLY want is the ability to run ARBITRARY versions of the software they want. Some people want to run very new software. Some people want to stick around with particular versions because of changes the upstream authors introduce.
Which on Linux they cannot. It's nearly impossible. You can get by somewhat by compiling your own versions, but it quickly gets out of hand if you have to deal with multiple users and multiple departments with their own particular needs. For people using Linux desktop at home they are completely lost.
The problem is not that distributions don't release often enough.
The problem is Linux package management, combined with massive duplication of efforts on the part of each distribution, is used as a band-aid to cover up OS design and management problems.
Linux users SHOULD have the ability to easily install and use whatever software they want, within reason. But they can't. The distributions don't allow it. The repositories provided are a straight jacket around users. If you happen to need the particular version of the particular applications provided by your particular distribution at a particular release then everything is easy for you, but if it doesn't... you are SOL.
I mean if I want to have a particular version of 'Kate' or whatever, why on the earth is the easiest and sanest way to do this is to re-install the entire freaking operating system?!
It's completely ass-backwards.
Distributions shouldn't be in the business of compiling and creating packages. They should be in the business of creating a stable core OS and then collecting packages compiled by software authors and aiding the software authors on issues of integration and stability.
This would enforce relatively static layers between different parts of the Unix/Linux operating system. Remember 'Layers'? The Linux kernel itself is successful because they are utterly dictatorial about what APIs and features they expose to the layers above them and how they go about maintaining those APIs and features. There exists no such layering in userspace, although people are hinting at it with terms like 'Linux plumbing'.
The expressed desire about 'rolling releases' is just a cry in the wilderness. The users don't understand the technical issues, they just want to have the versions of software they want to have. Most of them want newer versions then what distribution provides, so they think the solution is just to have newer versions of the OS _all_the_time_.
This is obviously insane, but they are trained (or in a different light, abused) as users of Linux to think that OS versions dictate application versions, which is opposite of what it should be.
Gnome packages should be built and provided by Gnome.org. KDE packages should be built and provided by KDE, not by Ubuntu, not by Fedora. So on and so forth. That way it will help enforce compatibility between versions and free up users to be able to use the software they want on their own terms and not on the terms of the 'ftp masters' or whoever.
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 20:13 UTC (Fri) by aleXXX (subscriber, #2742) [Link]
Interesting.
But it wouldn't be easy either.
KItware manages to release working binary packages at least of CMake by building those packages on a dedicated machine, which is kept at a software state several years old, so no new dependencies creep in, and additionally by linking most things statically into CMake, instead of using the system packages. But this goes against the Linux distro philosophy.
At least Slackware is a bit easier in this regard due to its superiour package system ;-)
Hmm...
Alex
Shuttleworth: Not convinced by rolling releases Posted Mar 8, 2013 20:15 UTC (Fri) by smoogen (subscriber, #97) [Link]
<pre>
Gnome packages should be built and provided by Gnome.org. KDE packages should be built and provided by KDE, not by Ubuntu, not by Fedora. So on and so forth. That way it will help enforce compatibility between versions and free up users to be able to use the software they want on their own terms and not on the terms of the 'ftp masters' or whoever. </pre>
That works until GNOME, KDE, etc want to have access to something "shared" but different. As has been shown in the past, each party has no want to be compatible with the other because they are sure their way of doing something is the correct way. In the past the only thing that got them to cooperate was the distributions whose job was to make it work. Instead you have lobbed this off to the user.. who as you explained earlier really doesn't care why one wants to use yaml configs and another wants javascript configs.. they just want it to work.
Shuttleworth: Not convinced by rolling releases Posted Mar 9, 2013 3:17 UTC (Sat) by HenrikH (guest, #31152) [Link]
On the other hand, on the OSes that what you want is possible, users often run non-updated old software that has multiple open security holes. And it's a real pain to keep all the software updated.
So IMHO it's not that this is a OS design and management problem but mere a difference in how to do things. There can probably never be one model that fits everyone.
That said, I wish that lib developers would care more about backwards compatibility. There should not i.e be a reason for the latest libSDL to be non-linkable with old software.
Shuttleworth: Not convinced by rolling releases Posted Mar 9, 2013 4:45 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
So you need to provide a way to automatically update packages if there's a security update. It just needs not to be linked to the OS version.
AppStores on Mac and Windows do this just fine.
Shuttleworth: Not convinced by rolling releases Posted Mar 10, 2013 2:39 UTC (Sun) by HenrikH (guest, #31152) [Link]
Which means that as a developer I either have to bundle or link static with all the external libraries that I use/need and thus have to monitor them each for security/bug fixes. And as a user I have to hope and pray that the developers of the app in question does just that.
On Linux I just have to release my deb or rpm and the distribution will take care of the rest. Of course this only works for libraries included in the dustribution, but imho it's still a much improved situation.
Shuttleworth: Not convinced by rolling releases Posted Mar 10, 2013 8:32 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
I used to think like that a couple of year ago.
However, the amount of apps hacking through vulnerable bundled libraries is fairly small. Sometimes attacker might get lucky with the "perfect storm" like the gdiplus vulnerability in Windows. But most of the time, inhomogeneity plays against the attacker in this case - it's hard to write an exploit that would work against several slightly different versions of libraries.
Then there's a question of applications themselves. I think we all can assume that stuff like Word or OpenOffice is probably riddled with undiscovered security holes. Never mind less popular software like Okular or Krita.
So IMO it's better to treat ALL applications as possibly hostile and contain them in various sandboxes as much as possible.
Shuttleworth: Not convinced by rolling releases Posted Mar 10, 2013 17:43 UTC (Sun) by aoeu (guest, #84301) [Link]
That's a lot of effort just to help your users roll back instead of reporting bugs. And at least from my (limited) POV debian already does a decent job of providing both an old and a new version when drastic or religious changes have been made.
Shuttleworth: Not convinced by rolling releases Posted Mar 9, 2013 9:54 UTC (Sat) by HelloWorld (guest, #56129) [Link]
lib developers generally do care about backwards compatibility. Of course there are incompatible releases like libSDL 1.2 and 2.0, but that's why we have shared object versioning, and even per-symbol versioning on GNU systems. Of course, bugs happen, so it's not perfect, but by and large, I think it all works fairly well.
Shuttleworth: Not convinced by rolling releases Posted Mar 12, 2013 19:03 UTC (Tue) by yokem_55 (subscriber, #10498) [Link]
Congratulations, you've just described Gentoo.
Stable core OS (kernel of your choice, stable libc, gcc) and then you can decide from there whether you want "stable" or "unstable" keyworded versions of upstream packages. Mix and match as you desire (within reason).
Shuttleworth: Not convinced by rolling releases Posted Mar 19, 2013 16:00 UTC (Tue) by renox (subscriber, #23785) [Link]
> What they REALLY REALLY want is the ability to run ARBITRARY versions of the software they want.
Doesn't NixOS answer to this desire?
Shuttleworth: Not convinced by rolling releases Posted Mar 19, 2013 16:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Yes. But it also requires to recompile everything on change. Not a good idea for many users.
Shuttleworth: Not convinced by rolling releases Posted Mar 20, 2013 8:36 UTC (Wed) by renox (subscriber, #23785) [Link]
> Yes. But it also requires to recompile everything on change. Not a good idea for many users.
Aren't you confusing NixOS and Gentoo?
Shuttleworth: Not convinced by rolling releases Posted Mar 20, 2013 12:36 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
No, I'm not confusing anything. NixOS compiles packets on install, just like Gentoo. That also allows it to install local packages for non-privileged users.
Shuttleworth: Not convinced by rolling releases Posted Mar 20, 2013 12:51 UTC (Wed) by renox (subscriber, #23785) [Link]
OK, thanks for the clarification, I clearly misunderstood how NixOS works.
|
|||||||||||||