Ubuntu considers “huge” change that would end traditional release cycle (ars technica)
Posted Jan 24, 2013 0:37 UTC (Thu) by tetley80
In reply to: Ubuntu considers “huge” change that would end traditional release cycle (ars technica)
Parent article: Ubuntu considers “huge” change that would end traditional release cycle (ars technica)
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.
to post comments)