Weekly Edition
Return to the Distributions page
| |||||||||||||
Ubuntu considers “huge” change that would end traditional release cycle (ars technica)
Ars technica reports
that Canonical is considering switching to a rolling release model for the
Ubuntu distribution. "But 14.04 in April 2014 could be the last
version released after just a six-month development period. 14.04 is also
the next 'Long Term Support' or LTS edition. Every two years, Ubuntu is
sort of frozen in place with a more stable edition that is guaranteed
support for five years. If the change Canonical is considering is adopted,
every future edition starting with 14.04 will be an LTS, so the next
version after 14.04 would be 16.04 in April 2016."
(Log in to post comments)
2-year LTS, rolling release in between Posted Jan 23, 2013 14:57 UTC (Wed) by rfunk (subscriber, #4054) [Link]
And we're back to the Debian model, but with a more predictable stable release date.
2-year LTS, rolling release in between Posted Jan 27, 2013 0:37 UTC (Sun) by sciurus (subscriber, #58832) [Link] I assume the Ubuntu rolling release would not have a freeze, like Debian testing does, before a Ubuntu LTS release. There are other problems with Debian testing which LWN has covered.
2-year LTS, rolling release in between Posted Jan 28, 2013 16:37 UTC (Mon) by rfunk (subscriber, #4054) [Link]
I was talking about unstable, not testing. Plenty of people run unstable as their daily system, for precisely the reasons mentioned.
There are even distributions whose purpose is basically to make it easier to install and run Debian unstable: aptosid (formerly sidux): http://aptosid.com/ siduction: http://siduction.org/
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 23, 2013 14:58 UTC (Wed) by hadrons123 (guest, #72126) [Link]
At last everyone has to. Things are changing. If fedora does a rolling release rather than calling the totally unusable 'rawhide' as rolling, Fedora would be the Distro to beat.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 23, 2013 16:17 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
I am using Rawhide and have even been using it as my primary system for months.
https://fedoraproject.org/wiki/Rawhide_improvement_projec...
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 24, 2013 0:37 UTC (Thu) by tetley80 (guest, #88691) [Link] A more pertinent question is: why have the typical mega-freeze to begin with? I believe this is a major failing of many Linux-based distributions (which could more accurately be called separate Linux-based operating systems), in comparison to (shudder) Windoze and Mac OS X. This also prevents a Linux-based OS (in contrast to the Linux kernel) becoming a stable platform (with the exception of Android). In Windoze and Mac land, there is a clear separation between the operating system and the applications that run on top of it. This situation is far less clear in Linux land, where to get an update for an application (say, Gimp, Inkscape, LibreOffice, etc) typically requires the update of the entire distribution. This is, not to mince words, insane. The end result is that we have a mega-freeze that occurs every 6+ months with Fedora, Ubuntu, OpenSuse, as well as multi-year periods for Red Hat and Debian Stable, where applications are stuck at a particular version. (Yes, I could recompile new versions from sources if I had a spare day or week, but nobody needs to do that on Windoze or Mac). I can understand the reasoning for such a mega-freeze: making sure everything gels together. In turn, the reasons for this include that each distribution wants to do things slightly differently (eg. various versions of glibc, gtk, as well as various init mechanisms). Within a rolling distribution, the problems of stale user applications are somewhat mitigated. However, the applications still require a person for creating and maintaining a package. What if they got hit by a bus, are on holidays, or have other pressing issues to deal with? The alternative is that the author(s) of software XYZ need to make N separate packages for N separate distributions, which is typically not practical (it requires having the time as well as access to N distributions). Given the "herding cats" nature of open source development, it would be difficult to solve the inherent problems which prevent "Linux OS" becoming a general platform. One possibility is to create a common OS core (kernel + minimal userspace) which doesn't have any major user applications (ie. no LibreOffice, no Firefox etc), but has the necessary libraries (eg. gtk, qt) to allow such applications. Distributions would then build their things on top of that (ie. add user applications). However, it's likely that there would be no agreement as to what is a "common OS platform", as things would be discussed ad nauseum, with regular flame fests. The real-life solution seems to be to create a platform (recent efforts by Ubuntu, and the idea of "Gnome OS" come to mind) and aim to attract enough users so that it makes other distributions/platforms irrelevant. Alternatively, we can use Android as a good starting point and add things to it so that it becomes self-hosting.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 24, 2013 0:46 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the other view of this is that the preasure of keeping things working all the time instead of tweaking things to work with a particular combination of things will make more people thing about and implement proper backwards compatibility.
The speed of development, stability, and performance of the Linux Kernel improved significantly when they changed from long upgrade cycles to short ones. They still have a testing phase, but when the changes are smaller, the testing is faster and more reliable.
Nobody is suggesting that any upstream release will be automatically rolled into a Ubuntu rolling release, but why should the upgrade of Firefox be held up by testing of a new version of Gnome? going to a rolling release would allow for the different apps that do not have dependencies on each other to get upgraded independently of each other. This would be a win.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 25, 2013 12:29 UTC (Fri) by dgm (subscriber, #49227) [Link]
The problem you describe is one of _interfaces_. Applications can be mixed and matched if they use the same _stable_ interfaces. That way your can evolve (read: fix) the base libraries and Kernel without having to re-check the whole system.
A contemporary Linux system is an amorphous soup of in-flux interfaces in continuous change. Just look at how easily do the KDE and GNOME break compatibility regularly.
> The real-life solution seems to be to create a platform
You cannot solve the "N platforms" problem adding another one. It only morphs into the "N+1 platforms" problem.
The only solution is for someone to sit down and actually _define_ the set of interfaces that applications can use. And write that in stone, for ever. That, and use the same policy that Linus uses for the kernel, namely, user's code SHOULD NEVER be broken by a change in libraries.
We don't need so much change in interfaces. Maybe a revision every 5 years with small and carefully thought out additions in between would be enough. We certainly don't need them changing every 6 months, and much less every day.
Or maybe I'm just silly.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 25, 2013 19:59 UTC (Fri) by raven667 (subscriber, #5198) [Link]
I agree whole heartedly but I would add that creating a platform doesn't always mean adding new code and creating an N+1 problem, it can just be a matter of re-defining code that already exists as part of the stable platform. That's the LSB way more than the PulseAudio/systemd way.
I guess I should also point out that there has been some level of success with creating N+1 platforms though that do out-compete the cacophony of choices and become "the standard", I think PulseAudio fits that bill, as does dbus, systemd might as well. The Linux kernel is also all about consolidating and standardizing its internal interfaces even though it is by definition an amorphous soup that is in-flux, maybe because it is managed as a cohesive whole and less as a collection of independent projects.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 25, 2013 20:24 UTC (Fri) by khim (subscriber, #9252) [Link] That's the LSB way more than the PulseAudio/systemd way. LSB way fails for very simple reason: a lot of "useful and obvious" stuff is done in different way on different distros. How to show a notification? How to play sound or video? How to add your program as a default handler for files it creates? All these task are not standardized by LSB because different distributions do this differently - but these are mundane tasks which are needed to be supported for good user experience! Windows supported them twenty years ago and Android supported them from the day one! Sadly it does not look like we have anyone who can do such API: Canonical is too small and RedHat ignores desktop. Thus we are stuck with this hodge-podge for now. Perhaps Valve can solve this problem? We'll see.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 25, 2013 20:37 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> How to show a notification? How to play sound or video? How to add your program as a default handler for files it creates? All these task are not standardized by LSB
This is an unfair test of whether the "LSB way" works or doesn't work, comparing apples and giraffes, because the examples you have used are not components which are part of the LSB. You seem to be arguing a claim that no one made. Just be cause there is a standardized platform dosen't mean that user apps which use the platform will automatically standardize to one solution per problem, there will be more than one web browser for example.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 26, 2013 0:46 UTC (Sat) by khim (subscriber, #9252) [Link] This is an unfair test of whether the "LSB way" works or doesn't work, comparing apples and giraffes, because the examples you have used are not components which are part of the LSB. And that's exactly my point. You seem to be arguing a claim that no one made. Perhaps we have different ideas about what makes platform, well... platform? IMNSHO platform is something which can be used as basis for something bigger. And you've said I would add that creating a platform doesn't always mean adding new code and creating an N+1 problem, it can just be a matter of re-defining code that already exists as part of the stable platform. That's the LSB way more than the PulseAudio/systemd way. Well, if you want to present LSB as a platform then it's abject failure as a platform: you can only build things which will look more-or-less acceptable in the quarter-century old environment and even by standards of the PC world back then it'll quite limiting. Amiga and Atari supported multimedia back in 1985... and even IBM-PC-derived world joined the club in 1991! If you mean platform is in "something you can spend a lot of time round and get a lot of pointless certificates with" then yes, LSB is a success, but I'm not sure why anyone will want this kind of "platform". Or may be you want to say that there was not enough time to create usable platform out of LSB? Surely you jest: it's over ten years old! Android was not even dreamed up when LSB was already at version 1.0! To create coherent platform someone must spend time to select components for said platform. Components needed to create applications the real users would like to use. GNOME, KDE, etc are doing that, but then they fail on the ABI side (there are no GNOME SDK or KDE SDK with some finalized ABI), LSB succeeds on SDK side but then fails on the usefulness side. In the end Linux does not have usable desktop platform (server side is simpler since LSB is more-or-less sufficient there), which is kind of sad.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 26, 2013 11:58 UTC (Sat) by oak (subscriber, #2786) [Link]
> Or may be you want to say that there was not enough time to create usable platform out of LSB? Surely you jest: it's over ten years old! Android was not even dreamed up when LSB was already at version 1.0!
Was LSB 1.0 aimed at desktop or server?
LSB 4.1 seems to have made xdg-utils a required "submodule":
So one can e.g open mail and browser in standard way...
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 26, 2013 18:49 UTC (Sat) by khim (subscriber, #9252) [Link] So one can e.g open mail and browser in standard way... That's cool, but can I actually register my own program as a web browser? Android offered this ability in version 1.0. Basically LSB is an eclectic set of random technologies and not a cohesive platform because it includes only "mature" things. That's not a way to attract application developers.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 27, 2013 16:12 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
There's xdg-mime, but last I checked, xdg-open didn't use it as a fallback if the KDE, GNOME, or XFCE launchers weren't found (it just gives up and tries $BROWSER and firefox.
This data point probably just goes proves your point about LSB anyways :) .
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 29, 2013 3:58 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Please file a bug report about this.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 30, 2013 23:08 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
It actually seems to have been fixed since I last checked (maybe a few years ago).
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 26, 2013 19:31 UTC (Sat) by raven667 (subscriber, #5198) [Link]
> Well, if you want to present LSB as a platform then it's abject failure as a platform: you can only build things which will look more-or-less acceptable in the quarter-century old environment
That's making a different claim than what I was trying to communicate, you are claiming that the LSB platform didn't go far enough for desktop use, that's a fair point but not the one we are arguing about. When I talk of the "LSB way" I am referring to the ability to wrangle multiple independent projects in a standardized way across distributions as opposed to having all the projects under one roof, like BSD, by writing code to replace them all for example.
There is a question as to whether you can wrangle the independent projects to standardize and provide a sufficient ABI and that is where analysis of the LSB and its suitability in the space that it operates would be helpful to see how it could or wouldn't work for a full desktop.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 26, 2013 21:52 UTC (Sat) by khim (subscriber, #9252) [Link] That's making a different claim than what I was trying to communicate, you are claiming that the LSB platform didn't go far enough for desktop use, that's a fair point but not the one we are arguing about. LSB is not all that adequate for server either. It actually does not even try to do that: you can not install and use any server package without some manual configuration (something similar to SBS). How can you create server packages if you don't know how SQL database should be accessed or where to put files to make the accessible via web server? And if manual configuration is part of the deal you don't need LSB or anything like this: knowledgeable person can even transplant stuff designed for Debian to RHEL or vice versa. When I talk of the "LSB way" I am referring to the ability to wrangle multiple independent projects in a standardized way across distributions as opposed to having all the projects under one roof, like BSD, by writing code to replace them all for example. You are talking as if LSB succeeded. It's not. It's failure. How many LSB-certified programs are out there? How many admins are using them instead of distro-specific packages? Nobody uses LSB and nobody will till it'll provide complete solution. And it'll not happen till someone will force resolution of some thorny issues. You are right: you don't need to have "all the projects under one roof": successful platforms (like MacOS or Android) often include whole projects from outside (MacOS includes bash from GNU and python from Python Software Foundation). But you absolutely do need someone who'll decide what approach will be used to solve thorny problems. LSB-style we'll-only-include-timetested-pieces-which-trigger-no-controversy does not produce a usable platform.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 29, 2013 1:37 UTC (Tue) by peter-b (subscriber, #66996) [Link]
To the contrary, KDE does have a stable ABI. Any binary compiled against KDE 4.x libraries is guaranteed to run unmodified against any KDE 4.y libraries where y >= x.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 30, 2013 9:04 UTC (Wed) by ovitters (subscriber, #27950) [Link]
Same for GNOME. We've been doing that since 2.x, but oh well :P
Stable base, rolling apps Posted Jan 31, 2013 3:14 UTC (Thu) by richarson (subscriber, #74226) [Link]
I'm amazed noone mentioned Chakra Linux:
Originally based on Arch, it tries to provide a stable base and keep user apps up to date (half-rolling releases they call it).
It is pure Qt/KDE, with GTK apps delivered in bundles ala PC-BSD's PBIs.
Maturity? Posted Jan 23, 2013 15:12 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
This could just be a consequence of maturity. If your revenue stream doesn't depend on new products then you're free to review the relevance of shipping such a thing as a "new product" and how often you're going to do it.
Once upon a time Linux (the kernel) would improve so much in a short time that it was worth running "unstable" versions (I recall a period in which everyone I knew ran 1.3.48 or so) just because they were so much better than the stale versions that were "stable". That's not been true for some time.
For a company that's selling software as if it was turnips, maturity is a problem. For a sensible Linux company that is selling something actually valuable (like, support or customisation) a mature Linux is good news because it's a strong foundation on which to build.
One thing that does keep moving is driver support. For devices that (unaccountably) don't have class drivers such as network cards, DVB dongles and arguably graphics cards, two years is too long. So if Canonical is serious about this they will have to offer newer kernels (or backported drivers) for those devices. Or we could bash some heads together and get class compliance from these two groups of devices on the agenda.
Maturity? Posted Jan 23, 2013 16:50 UTC (Wed) by eMBee (guest, #70889) [Link]
isn't updating drivers already an issue for LTS today? so LTS users should not be affected by this, and not would users that switch to the rolling release. the only ones affected might be those who switch from upgrading every 6 months to LTS, and that's assuming that LTS falls behind with driver updates.
greetings, eMBee.
Maturity? Posted Jan 23, 2013 17:03 UTC (Wed) by redden0t8 (guest, #72783) [Link]
Exactly... this won't change anything for LTS users, it's the others who it affects.
The whole "dist-upgrade" thing is part of what pushed me away from Ubuntu. I now use a rolling-release distro (Arch Linux) and couldn't be happier.
(I should emphasize the whole rolling-release thing was only one of several reasons I made the switch, though)
Maturity? Posted Jan 23, 2013 17:51 UTC (Wed) by scientes (guest, #83068) [Link]
LTS releases already have the 6-month release kernels and graphics stacks backported to them, this was decided at the 12.10 planning Ubuntu Developer Summit in Oakland.
http://packages.ubuntu.com/precise/linux-generic-lts-quantal
Maturity? Posted Jan 23, 2013 18:23 UTC (Wed) by madscientist (subscriber, #16861) [Link]
That's good, but the thing that really frustrates me about Ubuntu is that they don't update to Gnome point releases (except for LTS versions of course). The Gnome X.0 releases in March and September, and the Ubuntu releases provide the Gnome X.0 release in April and October (typically). That's all fine.
But then Gnome releases X.1 typically 6 weeks or so after X.0, and X.2 6 weeks after that, and sometimes even X.3, and those are chock full of bug fixes and stability enhancements. But Ubuntu never updates to those in standard releases.
They may pull back a critical fix here or there, but that's it. And so it seems that Ubuntu always has the worst of each Gnome release: they get all the new features in release X.0 without the bug fixes that went into release X.n, then they jump to a new release X+1.0 with lots more new features without fixes for those bugs.
If they start picking up the intermediate Gnome point releases in this "rolling release" model, that would be completely excellent.
Maturity? Posted Jan 23, 2013 17:03 UTC (Wed) by crimsun (subscriber, #13750) [Link]
Indeed--and newer drivers and other portions of other stacks are in place, e.g.,
https://wiki.ubuntu.com/Kernel/Release/Rolling . Testing is available via, e.g., https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport .
Maturity? Posted Jan 23, 2013 21:53 UTC (Wed) by airlied (subscriber, #9104) [Link]
Gpu class driver, naivety is strong with you
Maturity? Posted Jan 24, 2013 1:40 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
So, if it was just the GPUs, that wouldn't be too strange, all three major vendors claim (at least in public) to have secret sauce that sets them apart and a class driver would reveal that to be largely hogwash.
But in the other groups I'm left with a lot of questions - why for example network chipsets but not storage controllers? Why webcams (hardly the most trivial devices) ended up UVC compliant almost down to the very cheapest products on the market while DVB remains an endless series of incompatible chipsets doing much the same things but all in very slightly incompatible ways?
And why the timing? Was AHCI somehow perfectly timed for an opportunity to standardise storage controllers? Is there some clear reason such a standard couldn't have emerged a year earlier? A decade earlier?
USB mass storage shows that you can crank out a standards document even if the contributors can't agree on anything of consequence. Six different ways to do either of two different things, but only six, and not sixty or six thousand. And it also shows that having done that the market explodes.
Maturity? Posted Jan 24, 2013 9:43 UTC (Thu) by robert_s (subscriber, #42402) [Link]
"Why webcams (hardly the most trivial devices) ended up UVC compliant almost down to the very cheapest products on the market while DVB remains an endless series of incompatible chipsets doing much the same things but all in very slightly incompatible ways?"
This may be a rhetorical question, but I'm answering it anyway. Microsoft decreed that webcams had to implement UVC to get its' "designed for windows 7" badge.
Maturity? Posted Jan 24, 2013 12:12 UTC (Thu) by nye (guest, #51576) [Link]
>Microsoft decreed that webcams had to implement UVC to get its' "designed for windows 7" badge.
Does that mean the the only webcams you can confidently assume to be Linux compatible are those with 'Designed for Windows 7' written on them?
That amuses me.
Maturity? Posted Jan 24, 2013 21:31 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
This is indeed correct. I recommend precisely this for people asking about advice on buying compatible webcams. This sort of thing is why market share is actually important.
Maturity? Posted Jan 25, 2013 5:01 UTC (Fri) by rsidd (subscriber, #2582) [Link]
Market share, and the fact that Windows runs on a huge amount of diverse hardware and Microsoft does not want every hardware manufacturer to ship CDs with proprietary buggy drivers that destabilise the OS, any more than the Linux people do. (Perhaps Microsoft did encourage it at one time, but seem to have seen the light.) It's simply easier and more reliable when the "standard" driver is already in the OS and the device obeys the standard. Sometimes interests converge.
Maturity? Posted Jan 28, 2013 12:25 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Yes, they did, but that just brings us back to the same question. ie Why UVC standard webcams, but custom drivers for DVB?
In the past I have given the same advice to people that rahulsundaram mentions below, I'm aware of how this came about and there are plenty of examples, Microsoft also effectively mandated AC97 and HDA, and I think they had some influence on the AHCI situation. But again, why these things and not everything else?
Did somebody at Microsoft consciously say "Oh, we need to standardise webcams, but DVB doesn't matter" ? I'm guessing no. So how did we get here, and what can we do to improve things?
Maturity? Posted Jan 28, 2013 16:17 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Most webcams now ship built-in to computers and so compatibility with the Windows logo program is important. Most DVB devices don't.
Maturity? Posted Jan 29, 2013 16:08 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
That would almost make sense as a reason, except that also built-in to computers are loads of NICs, which still don't have class compatibility even though they've been around since the metaphorical stone age of ISA cards
The driver for something like a Realtek Gigabit Ethernet chip slapped onto a mid-range home PC is nothing very clever and gives no signs that the hardware is clever either (not to say I could build one, I suck at digital electronics and am a danger to myself and others with a soldering iron).
Having a class driver for NICs (even just for wired NICs) would make a lot of people's lives easier, probably even Microsoft's but it hasn't happened even as NICs went from an obscure add-on card you could buy from a specialist to a standard piece of equipment that draws attention for being absent from devices like the MacBook Air.
Maturity? Posted Jan 29, 2013 16:14 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
The low-end NIC market's mostly collapsed down to a handful of vendors capable of producing reasonable drivers. The same's not really true of the webcam market, which up until recently was still full of random mixtures of bridges and sensors with whatever driver the vendor either found somewhere on the internet or got out of the cheapest contractor they could fine. So I suspect there was (a) rather more incentive to go after webcams, and (b) nobody big enough to launch any kind of organised pushback against Microsoft.
Maturity? Posted Jan 30, 2013 13:57 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
OK, I'm not sure I'm entirely convinced but it's at least plausible. This does mean that disappointingly the way forward for more class compliance could be to encourage the existence of some really miserably bad Ethernet chipsets and associated (Windows) drivers so that Microsoft are driven to mandate a class standard for (say) wired Ethernet just to make the screaming stop.
Most of the utterly terrible decisions seem to have already been tried (explicit polling even when idle, PIO data transfers, making the driver do lots of bit-shuffling in software, even physical hardware that claims to be 64-bit but disregards the top 32 bits silently has been tried already) so I'm not sure what we'd have to do to really screw things up, but I have confidence that somewhere at an IHV there is a programmer who is stupid enough to invent something so terrible it can bring about the bright new world that I hope for.
Maturity? Posted Jan 30, 2013 14:36 UTC (Wed) by mpr22 (subscriber, #60784) [Link] It seems to me that there really isn't enough undercutting room in Ethernet card prices any more for a new really terrible, but cheaper-than-status-quo, chip to make any inroads.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 24, 2013 0:36 UTC (Thu) by cjwatson (subscriber, #7322) [Link]
I'm not totally sure I'm convinced by this myself (I'm on the Ubuntu release team and generally fairly heavily involved in this kind of stuff); the six-month cycle is something of a signature, has served us pretty well, and means we get reasonably frequent feedback on things like the installer which people tend to only take another look at around releases. My natural instinct tends to be to stick with the devil we know in the absence of thoroughly compelling arguments to the contrary.
On the other hand, there are certainly advantages to switching model. Six-monthly releases are expensive: as well as the cost of stabilisation alone (which clearly we still have to pay), there are all sorts of ancillary costs both in terms of the highly-qualified developers on the release team having to spin lots of wheels rather than doing other useful development work, and in more traditional terms such as updating marketing collateral, physical media, and the like. Supporting four or five stable releases at once isn't cheap in terms of human attention either, and we could do a better job of issuing timely stable updates if we consolidated on fewer targets. And third-party developers would have to do much less work if they only needed to build for, say, the last LTS and a current rolling release.
It's also worth noting that the current Ubuntu development cycle ("raring") is significantly different from previous ones, because we now gate uploads through a no-increase-in-uninstallability check, rather like that used by Debian testing (indeed, based on the same code, although with some different details of behaviour). Once we figure out the glue code we'll also be gating uploads on a variety of automatic tests. This has already made it a lot more feasible for reasonably technical users who just happen not to be Ubuntu core developers to run the development release all the time without having to watch apt like a hawk, and this was one of the major prerequisites for a rolling release model.
We shall see; things are not yet set in stone.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 24, 2013 1:44 UTC (Thu) by Company (guest, #57006) [Link]
I've not yet seen a discussion of the "app store" model (for lack of a better name), that the GNOME community has been getting excited about.
In that model, the "operating system" (kernel, libc, networkmanager, X, desktop) is getting regular releases in unison and all the other packages - the apps - are on their own schedule(s). This would allow testability, upgradability and other nice things for the core system while not holding back anyone that wants to run the latest libreoffice or Firefox.
A second thing very useful for this approach is flattening the dependency graph. Instead of thousands of components, you get an "Operating System" package, one package per program (potentially shipping its own dependencies) and very little else. Again, this reduces the complexity of the system (foo only breaks if bar is installed and at least version 1.12 but baz isn't installed) and adds a bunch of nice benefits.
Of course, that approach is totally not about choice. And we all know that distros don't succeed if you can't rebuild them on a FreeBSD kernel with an Android libc.
OS vs apps Posted Jan 24, 2013 17:18 UTC (Thu) by rfunk (subscriber, #4054) [Link]
I'm not a GNOME fan, but I'd be a fan of such a model. Is any distribution actually doing it?
The hard and controversial part would be where to draw the line between OS and apps.
OS vs apps Posted Jan 24, 2013 22:17 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]
openSUSE, in a way. Enable the GNOME Stable obs repo. But it ain't entirely smooth. There is also tumbleweed, a rolling repo (no, it is not for testing like Debian testing or rawhide, we have Factory for that). Note that openSUSE works a bit different than other distros thanks to OBS, we use a github like model for distro package development.
OS vs apps Posted Jan 24, 2013 23:13 UTC (Thu) by rfunk (subscriber, #4054) [Link]
Heh, I see great irony in the idea of switching from Ubuntu to openSUSE because of a GNOME repository, since I'm a longtime KDE user who always saw SuSE as the place I'd go if I valued KDE purity over Debian-based administration. I'll have to keep it in mind.
OS vs apps Posted Jan 26, 2013 22:16 UTC (Sat) by Company (guest, #57006) [Link]
Your base system is one single packet? And the apps are single packets and have no other dependencies than that base packet?
OS vs apps Posted Jan 27, 2013 1:12 UTC (Sun) by viro (subscriber, #7872) [Link]
Why the devil would anybody want such an abomination? A bug in a library (and you would have to put a _lot_ of them into the "OS" part) and you are welcome to download hundred of megabytes of binaries. That's completely insane.
OS vs apps Posted Jan 27, 2013 4:46 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Diff-based binary patches are nothing new. Android uses them just fine.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Jan 24, 2013 0:40 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the orticle claims concersn that there will be more frequent updates if this happens. On my systems, i have some update to some package just about every day, so I don't see this as an issue.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Feb 6, 2013 22:20 UTC (Wed) by Baylink (subscriber, #755) [Link]
And I read this piece, and the comments after it, and I have the same reaction I had to Mozilla declaring "Major releases only, now, every few weeks"...
Is there a System Administrator in the house?
Cause the reasons why we freeze releases are quite clear to me, and anyone else who ever has to manage a couple *hundred* machines (much less 30,000), and we (I) find it mind-boggling that they're not clear to everyone else, either.
You play games with release configuration management practices, and what you're doing is making it impossible for professional sysadmin types to practically test your new release to make sure it won't bomb their users machines when they deploy it.
If anyone wants to know why Linux *still* can't make any inroads on the desktop at any kind of real scale? This schidt's it, right here.
Ubuntu considers “huge” change that would end traditional release cycle (ars technica) Posted Feb 7, 2013 5:53 UTC (Thu) by khim (subscriber, #9252) [Link] This is strange because we are managing more the 30'000 desktops here and this change makes perfect sense to us. I mean: to nicely integrate new release of Linux in our system, test it with all the hardware supported, etc we need 3-4-6 month thus non-LTS versions were never even considered so what's the point of ever providing them? Rolling releases will provide newer software for the rare cases where it's really needed (and if newer software is needed campus-wide you can always use a backport).
|
|||||||||||||