3 ms·

Piggybacking off your comment to add some additional questions; I'm in a similar boat as you. I've always been a user of the Debian and Arch worlds. The RHEL/F

by rewgs 3y ago

Piggybacking off your comment to add some additional questions; I'm in a similar boat as you. I've always been a user of the Debian and Arch worlds. The RHEL/Fedora/etc world has been this "other" part of Linux that I frankly haven't touched much, and haven't yet found a reason to. One thing I'm not totally clear on is what specifically Red Hat offers that people pay for, i.e. what are the details of the "+ stability + patches" of what GP mentioned. Are there paid applications as well? Is paid support a large part of the business model? And so on and so on. I'm still just a little mystified by the RHEL business model, and every time I hear someone talk about it, it's literally vague one-word answers such as "stability," "patches," "support," "enterprise stuff," etc. Even the RHEL FAQ offers essentially just that. I'm still not quite informed enough to be able to confidently lean one way or the other, but I have to say that I can't shake the feeling that RHEL's business model ultimately relies on exploiting their customers' desire to change their systems as little as possible, even if it means the customers eschew more modern systems that make obsolete the need for the kind of products and services RHEL provides. Or to put it another way, RHEL enables their customers to live with "the devil they know," and not adopt more modern best practices. Which isn't necessarily a bad thing, I get it, but also if that is indeed the case, it seems like a rickety foundation upon the already rickety foundation of trying to sell open source software that easily be unseated by, say, the nix model of doing things. I don't know, I could be dead wrong, but starting from what I've seen most other tech companies do and mixing it with a dash of "the idea of paying for Linux seems insane to me"...in lieu of better information, I can't dismiss the above out of hand.

op00to 3y ago
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.
- rewgs 3y ago
  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.
  - op00to 3y ago
    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.

by rewgs 3y ago

op00to 3y ago

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.

rewgs 3y ago
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.
- op00to 3y ago
  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.