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?

Comments

I use Gentoo - but not for much longer

[QBasicer]

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.

Debian SID

[raxx7]

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 for a while, FreeBSD for life

[Anonymous Coward]

I personally prefer rolling release.
I used to use Arch, until they started trashing their ecosystem. Giving up KISS by adopting systemd, moving /bin, etc. It became a bitch to maintain with all the breaking changes imposed.

Ultimately I found FreeBSD's ports to be amazing rolling release system. Far more stable than Arch, you don't have to break your junk if you don't want to. And that makes me happy. The kernel moves in increments, everything else you compile or download binaries. I end up with a much more optimized and stable system than if I had stuck with Arch. Yet everything on my box is up to date.

Each has its pros and cons. I've had to use Slackware and Ubuntu for my work. They're practically zero maintenance which is probably a good thing for ~generic~ computer users.

Re:So much for stability and uptimes...

[radish]

You know it's interesting. I used to work in finance. We, like you it seems, had a very locked down production environment with huge amounts of testing - pushing builds through multiple stages, reviews and signoffs. Once every month or so we'd shut everything down for a few hours in the middle of the night and roll the world forward. Stability was everything. Downtime was OK if scheduled, a disaster if not.

Now I work at a web company. We push to prod multiple times per day. There's a process, there are reviews and approvals, but it all happens much more quickly and at a more granular level. Change is constant but small, as opposed to infrequent but total. What's more we're a 24/7 operation so no downtime (as visible to the user) is acceptable. We simply can't schedule a few hours to do our rollout - everything has to happen live.

You know what I've noticed? We're no less reliable, overall, than the bank was. Yes we have issues, but they tend to be noticed, and fixed, much much faster. When you change everything all at once you run the risk of not being able to figure out what broke when inevitably something does. Rollback is painful because you have so many interdependent changes - in the end you have to pull the whole release to avoid one small issue in a single module. When you roll frequently the scale of change is small so isolating the bug is trivial, and rolling it back the same. Now of course there are huge differences in risk when you're handling people's money vs their cat photos, but I think the view that people working on an agile schedule don't care about stability, and that the only way to achieve stability is through reducing the frequency of change, is demonstrably wrong.