Hacker News new | past | comments | ask | show | jobs | submit login

One benefit is if you pick a major version of RHEL or an LTS Ubuntu, you know that you’ll have 10+ years of consistent APIs and ABIs. If you stick to latest upstream distros, you can run into unexpected API incompatibilities causing bugs and breakage.



Right, I get that, and I totally empathize with customers that would want that. But that's also part and parcel to the "devil you know" I mentioned. Like, in my experience -- which, sure, is absolutely not in a world that has ever touched RHEL, so once again I want to stress that I could definitely be talking out of my ass -- the safer place is actually to continually roll close to the cutting edge.

Very, very generally, updates tend to play better with or expect that the software it's working with is also updated; and so, while yes it can be stable to stick with a particular version for 10+ years, the value of that stability drops as time goes on, as the software/OS in question has more and more trouble operating in the context of/with other/newer software, and so 5+ years into that 10+ year timespan, that stability you're supposedly paying for doesn't feel very stable at all -- and that doesn't even begin to touch what happens once those 10+ years run out and you need to get with the times.

Which is all to say: this is why rolling releases exist. Better to get used to surfing the wave all the time, rather than sitting on the beach for years and then having to swim an Olympic race after you're out of shape. I'm mixing metaphors here but you get the idea.

What's more, obviously riding the wave can be a little tiring, and thus more and more best practices are borne out of that problem -- which is why I mentioned nix in my last comment. I'm not even a nix user, have never done more than read about it, lest one think that I'm yet another nix zealot on HN, but I do think that it or something like it is a very very good solution to the pains that can be had by constantly staying up to date. I for one will always be more interested in that kind of route, rather than agreeing to the golden handcuffs of long-term support. While not in a RHEL-like setting, I've been bitten by the "I just want this old thing to keep going and never change" problem too many times before.

Like, I was listening to the most recent episode of Linux Unplugged, and they had a member of the RHEL team on, and when asked about the value proposition of RHEL, he said something to the effect of that it's not just the software, but being able to offer the specific versions with the specific patches in particular combinations of other software with whatever patches. And I couldn't help but think -- isn't he basically just describing nix? Nix's whole thing is to super easily enable declaring specific versions of software in specific combinations, and to be able to recall it with a config file -- Matthew Croughan's talk at SCALE this year was essentially...that, and doing it super easily. And perhaps if we aren't keeping so much old software alive, it wouldn't all need so many patches to allow all the various combinations required.

I don't know. It all seems like a very heavy-handed, people-y solution to a problem that we've mostly solved, and perhaps even eliminated the conditions for to exist in the first place.

Anyways, this is all mostly hypothetical pontification, and I'm sure that those who actually work with RHEL on a daily basis could poke tons of holes in my point of view. Would love that actually, as like I said I feel very much like an outsider looking in. But it just seems like a goal that is fundamentally flawed.


I agree with you in theory, but most large enterprises will never, ever be able to make rolling OS releases happen for political and even structural reasons. When the EOL comes, they pay for extended lifecycle support and hope for sunnier days in the future.

For those enterprises, the value of the stability RHEL provides goes UP as time goes on, because the longer you wait, the more risky and costly it is to migrate to the new version/solution/etc.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: