| |||||||||||||
Ubuntu considers “huge” change that would end traditional release cycle (ars technica)Ubuntu considers “huge” change that would end traditional release cycle (ars technica)Posted Jan 23, 2013 16:17 UTC (Wed) by rahulsundaram (subscriber, #21946)In reply to: Ubuntu considers “huge” change that would end traditional release cycle (ars technica) by hadrons123 Parent article: Ubuntu considers “huge” change that would end traditional release cycle (ars technica)
I am using Rawhide and have even been using it as my primary system for months.
https://fedoraproject.org/wiki/Rawhide_improvement_projec...
(Log in to post comments)
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.
|
|||||||||||||