Slashdot Mirror
Greg KH Favors Rolling Release Distros
jones_supa writes In an interesting Google+ post, the lieutenant Linux developer Greg Kroah-Hartman mentions him fully moving to rolling-release Linux distributions: 'Finally retired my last 'traditional' Linux distro box yesterday, it's all 'rolling-release' Linux systems for me. Feels good. And to preempt the ask, it's Arch Linux almost everywhere (laptop, workstation, cloud servers), CoreOS (cloud server), and Gentoo for the remaining few (laptop, server under my desk).' What's your experience? Would in the current situation a rolling-release operating system indeed be the optimal choice?
Don't bother clicking the link. The *entire* post is contained in the summary.
Support the First Amendment. Read at -1
There was an era, probably inherited from the big-iron computing model, where we strived for stability and long uptimes. We didn't install things that we didn't need (with the exception of Fortune perhaps) and locked-down the box at the network stack. Granted, it required a lot of knowledge at the beginning to make sure that the box was indeed secure, but we were proud of setting up a good, usable box that didn't need a lot of maintenance after the fact.
I guess that era is now gone, with rapid-release and lots of little things constantly needing the system to restart.
Do not look into laser with remaining eye.
The real news is, someone is still using Google Plus.
My first program:
Hell Segmentation fault
This really strikes me as something that is going to heavily depend on what the systems are actually doing, how tied to the distro-supplied software the usage is, and how often the releases are.
Even within 'rolling release' distros there is a huge variation in exactly what that means in terms of changes, updates, frequency, which parts are rolled vs versioned, user control over backdating. This combines with a bit of a matrix of use cases for one to find exactly how much manpower using such a distribution within an organization will eat up. So yeah, 'it depends' pretty much sums it up.
For a machine that you would just blindly take updates for anyways, rolling releases are probably convenient.
For mission-critical systems where every change should be tested first, it's probably a bad idea unless rolling back is very easy, as it might be in a VM-with-easy-snapshots environment.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I think rolling releases are good for developers, and gives you that whole agile thingy ...
But really what it instills is a culture of "almost got it" where you'll run the risk of breaking your user's systems and then just say "whoops, we'll fix that next time".
I think it leads to sloppy release engineering (because, after all, it's just a build), and will be fundamentally incompatible with how companies need to do IT.
And every time I see Firefox telling me "It is strongly recommended you upgrade to this version" what I really see is "holy crap, did we inject some garbage in that last one".
I think in general the "continuous release" says "we're not worried that people in the real world can't do this, and we don't care ... we'll fix it on the next release ... maybe".
So, for your personal desktop, or a sandbox, or a toy ... sure, have at it. But for a real machine, doing real work ... I think "continuous release" is a terrible idea.
Because in the real world, we're not prepared to patch Prod system just because you committed some new changes -- we have bigger issues to deal with than constantly updating software to keep you happy.
I should think nobody in a corporate environment is a fan of that. And if you're a small shop of 20 people who are risk takers ... you're not in what I'd call a corporate environment.
Lost at C:>. Found at C.
I've been using Debian unstable in my personal computers for years. Occasionally, something breaks.
But I prefer the long term support of Debian stable and CentOS for internet facing servers and lab workstations.
Here, it's important to be able to get security fixes without fear of breaking anything for years.
Arch breaks. Often. Breakage is the trouble with rolling release distributions, and an intolerable problem for anyone not wanting to spend the time un-breaking things.
Loyal but naive Arch users are always quick to defend it, "my system has never broken" "you must be doing something wrong" etc. but these discussions are always about semantics. Just because it's a one-liner to fix doesn't mean that it isn't broken. If it requires my attention to keep working, then it's broken. Just because it is fixable doesn't mean I want to spend time fixing it.
Arch is a great way to learn Linux, and the Arch wiki is a great resource not exclusive to just Arch. But you'd have to be out of your mind to use it for anything in production. The Arch FAQ makes it pretty clear: YOU, the user, is responsible for keeping your system updated, functional and stable; but the more packages you have installed, the more likely you are to get broken when upstream updates something.
Also from Arch docs:
Warning: Do not be tempted to perform partial updates, as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.
Translation: You want to update package foosicle-1.2 to foosicle-1.3 because it has a security problem. Oh, you don't want to update X, Firefox, KDE, and the kernel? I hope you do want instability then. BTW, stay on top of your updates unless you want to get really hosed.
No thanks.
I use Ubuntu LTS releases on my computers at work for three reasons:
1. Reading the Arch wiki to un-fuck Java after I updated my system to fix a security issue for a different package is not a good use of my time.
2. Not a good use of my time to compile from source because the distribution ships with something ancient or doesn't have it at all (I'm looking at you, RHEL).
3. Will keep getting updates for the lifetime of the hardware.