Ubuntu considers end of traditional release cycle | Hacker News Reader

Ubuntu considers end of traditional release cycle

arstechnica.com

49 pointsmacco49 comments

Milestone release vs. rolling release is a red herring. The real problem is the issue of shared libraries and shared dependencies. This is one thing Windows got right--updating one program (usually) doesn't affect other programs on the system. But in Linux, updating one library or program might introduce bugs into all of the programs using it. Hence was born the milestone concept, where we freeze a known stable state of the entire system and use that, because all the interdependent clockwork seems to work ok at that point; and then the rolling release concept, where we acknowledge the need for new software, but update everything, top to bottom, so frequently that breakage is common.

These approaches have the added side effect of making the distro the curator of the galaxy of 3rd-party software running on it. I find this the most surprising thing--why should the OS provider have to spend the energy curating every single well-known program that runs on the OS?

What we really need is a reform in the way dependencies and packages are managed so we can update one aspect of the system (Firefox, Pidgin, etc.) and not drag in new versions of libraries that can introduce bugs in to other parts of the system. Gobo Linux started edging towards this approach but it's sadly no longer maintained.

An approach that combines a stable core--kernel, video/network drivers, etc.--that is thoroughly tested and rarely updated, plus sandboxed apps that update at their own pace and are not curated by the distro maintainer, would be the ideal approach, I think. We could even keep the concept of centrally-sourced packages.

Is this possible given that Ubuntu inherits Debian, or given the general philosophy and practices of OSS? Maybe not. But it'd go a really long way towards assuaging the constant and unforgivable breakage that happens with every new Ubuntu release. (And before someone chimes in with "you're wrong, it works perfectly for me", I have a single anecdotal data point to counter your single anecdotal data point.)

If the distros continue to have their "app store" feel, where you get apps from distro maintainers as a trusted provider, then vaildating the barest amount of security and usability for programs uploaded to their archives would be even more of a chore. It would also tax bandwidth and drive space, FWIW.

Windows got/gets away with it because they provide the OS and a few apps, and says, "go to download.com for all your needs!".

To clarify I think moving towards the Windows approach is precisely what Linux needs. It rightly shifts responsibility away from the distro to the app maintainer. This is not incompatible with the central-sourced model like "apt-get install x"; there could be some central list of non-core packages plus 3rd-party download links that is hosted on a Canonical server. App developers would push their updated app information to that list, and everyone using the OS benefits without having to wait 6 months for Canonical to curate the next edition of their clockwork galaxy.

I'm just spitballing here but the point is that theoretically we could still have something apt-get-ish and not rely on Canonical as the curator.

Could just take debian/ubuntu, remove all library dependencies from all packages and recompile them statically i guess. Not really sure if it's worth it. There's nothing stopping you from running something like debian stable and then manually downloading and installing things like Firefox, which is exactly what you would do on windows.

"To clarify I think moving towards the Windows approach is precisely what Linux needs."

WT-actual-F?

A model where people are trained to download and install random unvalidated garbage from the internet and live with the ad/crap/spy/mal-ware that that entails?

Please god no.

You can, if you want, install new repos and PPAs into ubuntu and debian quite easily, and yes running a decent repo takes maintainance. It's also the reason why debian stable is rock solid.

I already download and install lots of source package, which doesn't seem particularly any better than windows. How many github repositories bother building a deb package?

Compared to the stuff you need to go out and find from somewhere on Windows, the amount of things available from apt on deb or ubuntu is incredible.

You have to go to the web for a basic working system for windows, this is not the case on linux.

I agree, the model where the distro has to maintain packages for every application doesn't really scale.

Ubuntu is moving towards this - they're encouraging developers to submit new applications to an App-Store like interface. There's still some centralised checking, but packaging and updating is the responsibility of the authors. There have been some teething troubles with reviewing applications, but I think the plan is to automate more of it.

That's fine, but as a user this puts that sort of app on an entirely different footing from the 'I know this is going to work because the OS guys did it' that I get from official repos.

I'm not sure how you can say it doesn't really scale. Last I saw there were 30K packages in debian.

I'm not arguing that there should be no other way of installing anything here, but I would think very hard before criticising the current model. It works extremely well.

30K packages in Debian, nearly 20 years after it was first released. I know many apps are broken into multiple packages. By contrast, Apple's & Google's app stores have ~700K apps each, less than five years after they started. I don't believe Debian could handle that kind of scaling.

I have given this thought. My issue with the current model is that, because packages tend to be several months out of date, third parties increasingly point users to their own installers or packages instead of those in the repos. MongoDB and Google Chrome are two examples. Besides making installation more awkward, this dilutes the security value of having the repository in the first place. The repository model only provides security if users don't need to install things outside it.

I want to keep the centralised repository/app store with security guarantees - I think that's valuable for most users. But the responsibility for handling packaging and updating applications needs to shift from the distro to the application developers. This is only for applications, though: system components - core libraries, runtimes, window managers etc. - should still be managed cohesively by the distribution.

Chrome had a debian repo.... and I use chromium anyway, or firefox/iceweasel.

What is a core library or runtime? Where do I draw the line? How do I know that app X is going to rely on the same version as app Y?

Google and Apples' app stores are (comparatively) full of toys and crap, I'm sorry to say. If 1% of the stuff in there is useful I'll eat my hat* . They also have the advantage of targeting a single language and runtime, anything else has to be packaged with the app itself. I don't think this is a good or useful model for an open source ecosystem.

For an open source platform and closed source ecosystem you may be on the money.

(* disclaimer - author does not currently own a hat)

Drawing the line: almost any categorisation has debatable cases, but that doesn't mean it's not worth doing. It's quite obvious that an app like Firefox is different from something like Qt or Python.

Dependencies: the distribution provides, e.g. Qt 4.8 and Python 2.7. Applications that support the distribution work on those versions because their developers knew that's what they needed to support. That's how it already works for open source apps.

Usefulness: if the user wants a shiny toy, they'll go and get one. If that turns out to carry malware, it's just as much of a problem as if they were trying to install something 'useful'. It's not about what you consider useful, it's about what users want to use.

Why should you care: when a new version of, say, Libreoffice comes out, why should I have to wait 2-8 months before I can benefit from it, on the 6 month distro release cycle? Windows users can upgrade the same day. Some things, like Firefox, now get fast-tracked updates, but there isn't the manpower for any distro to do that for all apps.

I guess you and I use/view software differently.

To me the new version hasn't really been released for my 'OS' until the distro packages it. When using a stability-oriented distro like debian, that's important.

Usefulness: if the user wants a shiny toy, they'll go and get one.

If there's something that's not in the standard repos then I have to consider taking the same steps as a Windows user - geting something with less that 100% trust and less than guaranteed stability. Usually at this point I'll look for an alternative that's better supported. I'm not trying to claim I am in any way representative, but my behaviour differs markedly from what your 'user' does.

BTW - There is absolutely nothing to stop someone working on top of a 'normal' distro stuff to deliver cutting-edge apps. In fact it's pretty much been Ubuntu's selling point. It's also what Steam is doing. Just please don't ask distros to stop doing what they do best - make the seamless and painless experience that's made various forms of Linux my platform of choice for many years now.

I guess I'm trying to say - as a user why would I care if someone else packages the app?

All I'm going to get is more security risks (multiple versions of libraries from all sorts of sources) and less compatibility (third party packagers will screw it up as they're not focussed on my distro).

I suppose it wouldn't be absurd to have another repository in Ubuntu, say, for unvalidated packages, kind of like the PPA, but without having to manually add the PPA to your repo.

If, along with main/universe/multiverse/restricted, they had "badlands" or something, that contained all packages that would otherwise be in a PPA, it could be more scalable.

If you want a 'newer-than-distro' program, just use a PPA. It's a solved problem.

No, it's not a solved problem since PPAs are Ubuntu specific both in the sense that nobody else is using them and in the sense that if someone makes a PPA that package depends on a specific Ubuntu release and won't work on any distribution.

There needs to be a way for developers to provide distribution agnostic binaries. Distros can choose to provide whatever package management tools that consume the developer-produced raw data.

"PPAs are Ubuntu specific both in the sense that nobody else is using them and in the sense that if someone makes a PPA that package depends on a specific Ubuntu release and won't work on any distribution."

Well, you can use them on debian, other distros (Fedora etc) have a different model with equivalents.

"There needs to be a way for developers to provide distribution agnostic binaries."

Why? With source the distro maintainers can choose to build it as they like, apply patches if they feel the need, tweak it to run against the lib versions they have decided on etc etc. This is what makes linux distros great, that the binaries are built with and as part of the system.

"Distros can choose to provide whatever package management tools that consume the developer-produced raw data."

Big of you to allow them that freedom...

> There needs to be a way for developers to provide distribution agnostic binaries. Distros can choose to provide whatever package management tools that consume the developer-produced raw data.

What prevents developers from providing statically linked binaries in PPAs right now?

Nothing at all. I don't think there's really a developer appetite for doing this stuff.

There is for commercial server software, but then folks working on that tend to target ultra-stable platforms.

Ubuntu has had something like this for a while now: https://myapps.developer.ubuntu.com/dev/

I really do not like that my windows machine takes longer and longer to log in as every single software provider has to have their own 'phone home' mechanism to see if there's an update. Windows did not 'get it right'.

Windows programs all check on login? Is there something that disallows them from checking from time to time when the machine is idle?

Updating software is orthogonal to software modularity.

You might be interested in the Nix package manager: http://nixos.org/nix/

Among the raft of interesting ideas it brings to the table is application sand-boxing; many versions of a shared library can be installed with dependent apps linking against the version they depend on.

That would be giant liability (and already is on Windows and OS X), as apps have to provide their own versions for libraries (or statically compile), which can't get security updates system-wide.

Just a though: what prevents the OS from keeping several versions of a library installed, linked dynamically to an application that specifies which version it needs?

We'd have to change some system calls, of course, from load("blah.so") to load("blah.so", maj_ver=4, min_ver=2). But couldn't that solve a part of the problem?

Apps already link against specific library versions.

With a package manager that allows multiple installed versions, app could link against library major versions and receive minor version (security) updates automatically.

But all this would still require everything is managed by the package manager.

In Windows it was called "DLL Hell". All the shared dll were in system or system32 and when a program updates it, no one knows what would happen to the other programs. Now it's almost fixed because each program store its libraries it its directory.

Now it's almost fixed because each program store its libraries it its directory.

And wasn't this pioneered on OSX?

my hope is it would have been pioneered by Dr. Obvious

update everything, top to bottom, so frequently that breakage is common.

Breakage is not common for me on Arch. It was probably more common a few years ago in Arch and back several years when I was using Gentoo but I rarely ever have to dive in and fix anything anymore.

I disagree, while Arch is pretty good, core bugs get by that shouldn't get by. An recent example is python2-urwid issues with wicd-curses, which resulted in wireless not working.

shared libraries can be versioned - http://www.ibm.com/developerworks/linux/library/l-shlibs/ind...

Is there a possibility for packages for non-core software to be built statically with all their dependencies? Why not use this approach?

If one is willing to spend a little memory and disk space one can just keep different versions of every library around. I believe PC BSD is doing this (but have not tried it yet myself).

I used to enjoy the "continuous release" aspect of Gentoo. But every now and then it would go horribly wrong and I'd have hours of sorting it out to do.

That was ok since I was a hobbyist who was trying to learn Linux better.. but Ubuntu's always been about "Just Works" so they'll have to be really careful with this.

If they can make it work, it'll be awesome.

This might be of interest: https://www.youtube.com/watch?v=i7pkyDUX5uM&feature=yout...

Theo de Raadt(OpenBSD founder) explain the importance of "Release Engineering".

Just when I decided I'm only going to be using LTS releases in the future. If they actually go through with this I hope there will be a general update option like choosing between "conservative" and "cutting-edge" updates.

The proposal is to keep LTS releases - but lose the interim releases. I assume after an LTS release you'd be given an option "upgrade" to the next LTS testing branch which give you updates until it that LTS is released.

I propose they have three releases: Stable, for the bi-yearly freeze, Testing, for the generally-okay rolling update, and Unstable, for the untested cutting edge stuff.

So, they would essentially adopt the Debian way of doing things? Have a stable release every two years and updates (Debian testing) in between.

one of the things keeping me on ubuntu right now is that 3rd party linux software (be it proprietary or open source stuff that's not in the repositories for some reason, or perhaps that canonical has screwed around with) is today almost always packaged for ubuntu. i imagine that's going to be much harder when there isn't a specific release that those 3rd parties can aim for.

i actually thought ubuntu hit a nice sweet spot with their 6-month release cycle. it was one of the many things they got right in the early years that gave them the leadership position they still have today, even if a lot of us are less fond of what it's become.

On my work machine (laptop) I've been on Debian sid (unstable) for a few years now, which is probably close to what they have in mind. For somewhat experienced users this works great: Occasionally there are a few hiccups, but they are few and usually easy to fix or work around.

But I would not recommend this to inexperienced users, and I think there the current Ubuntu rapid release cycle hits a sweet spot: It's reasonably well tested to be able to recommend it to inexperienced users or set someone (grandparents, ...) up with an Ubuntu box and just let them have a go at it, while also being mostly up to date.

Do they have reason to care less about enterprise use now? Either all the enterprise use is on LTS with support contracts, or they all fizzled out and went back to Windows?

We fizzled out and went back to Debian stable. LTS is far from supported, even when you pay for it.

Meh... It just means am even less likely to use ubuntu in the future.. I have already moved out of it, due to the amount of fixing i need to do, just to compensate for the problems introduced by apt-get update. Now it seems i'll just end up using debian or even fedora. Well, that may actually be a good result..

This is similar to what Chrome and Firefox are both doing now, lots of smaller incremental updates. Problem I'm experiencing now is both browsers are less stable with all the updates.

Now it can incrementally suck more.

Seriously, after the shit ton of badness canonical have pumped into Ubuntu in the last 3 years I couldn't trust them on this.

Reply on news.ycombinator.com