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've been using Gentoo for many years, and temporarily switched to Funtoo on my personal laptop. I've since graduated and don't spent nearly as much time on my laptop as I used to, which these days mainly runs MythTV.
I don't think I'd continue with Gentoo - it takes too much time to sort through updates, figure out which packages need to be masked, etc. I'd rather go to Arch next, although I was considering Debian unstable.
Recently, my video card stopped being supported by the newest nvidia graphics, and the newer versions of Xorg weren't compatible. My masked list is growing as more and more packages have deeper dependancies on newer versions of Xorg. I always figured Portage should honour my masked packages and keep everything at the latest version without stepping on my masked packages, but it wants me to do everything manually. If package 1.2.3 is incompatible with my Xorg, I'll mask 1.2.3 and newer. There is a slight chance, however, that 1.2.4 will be compatible, but it doesn't matter, since Portage made me masked out 1.2.3 and newer, I'll never even know.
x86, oh yes, I'm pro.
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 Gentoo on all my personal machines for the last decade or so.
Works fine as long as you pay attention.
--dost
*sigh* back to work...
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.
Congrats you can upgrade your latest hot shite box to the latest hotness. Fantatsic. Now what about those servers that have millions of people trying to contact your business through? Hell to the No.
You want your systems to be running stable, known working, and reliable code. Who cares if it's version 10 and not version 10.0.4134. Let the dev monkies play with the updates in the background and when a service release is out test it further.
Unless there is a positive gain (security, feature release, or annual patch) then the old code is just fine. It works, don't touch it, leave it the hell alone and go play with your crap in your lab.
Another reason I hate the DevOPS movement. Combines the worst of habits of a Dev Monkey and a System Admin.
Wheel of Time: Book by Book and Sumview (summary review) Bigdady92 style: http://bigdady92.blogspot.com/
In software development, especially server-side web development this is called continuous integration (CI for short). I have nothing against it, if automated testing, instant rollback and other things are in place. And if the distro has solid quality control and feature management. ... Somehow I doubt that though.
If a distro crew knows what they are doing, I'd trust them with rolling releases. ... Maybe I should try this Arch Linux thing out. Any experiences? Any advice?
We suffer more in our imagination than in reality. - Seneca
rolling release, while in the case of Gentoo initially more tedious to set up than just 'click install' is a refreshing departure from packaged distros. from a devops standpoint its no more or less manageable either. I create a base gentoo image and DD it to servers. afterwards salt takes over and doles out configuration. port tree zaps, use, and merge can also be controlled and if some security vulnerability is found in a compiled option for an application, you can command your servers to recompile the affected package without that option instead of waiting for a workaround or patch, which might not be feasible in a production environment.
Good people go to bed earlier.
Try Void Linux, a rolling distro that doesn't suck:
- System-wide LibreSSL by default (maybe the first linux distro to do so) ... and more.
- runit instead of systemd
- multilib aware
Agreed. Also, even if it's not _broken_, I don't want things constantly changing under my feet without even being able to meaningfully talk about what changed in different versions.
It's good to be able to say "here are the major changes between "Windows 7 and Windows 8". It's definitely good to be able to say "this software works on Windows 8", rather than "this software works on versions released between 2013-10-12 and 2015-01-03".
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.
That is why we use CentOS for most of our critical servers at work. There's something to be said for 10-year support cycles.
The trick is that then the upgrade at 8 years is a nightmare.
The real problem is that people don't know what they've installed, how they've configured it, and how to upgrade it. Devops really is the answer. My puppet modules work at least on CentOS, CentOS -1, and Fedora/Fedora -1, so I figure out changes on Fedora, and eventually retire the CentOS -2 releases. My CentOS 5 is all gone, just about everything works on CentOS 7 and can be deployed when I get a chance. If you're up against year 8 and you don't know what's on your 8 year-old box, the first thing to do is to be able to replicate it, and then you can think about upgrading.
This makes the idea of a rolling release less desirable, except to get new features/fixes faster. The sad part is that traditional distros take absolutely no responsibility for upgrades - there's no community expectation of a standard - something dovecot has done this poorly and MailScanner has done this wonderfully. If a million people have to upgrade dovecot to get from CentOS 5 to CentOS 7 then a million people have to figure out how to do the upgrade. That works against the idea of why distros were formed.
Since you still have to do it all yourself, at least devops makes it manageable. It would be neat if you didn't have to do it all yourself. That's an inevitability.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)