Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

61–70 of 235 posts

Re: What's wrong with enterprise Linux

#61

There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to b…

> I'd like to see the RHEL stability model go away too and force people to complete their automation and solve the problems of being able to rebuilding on demand - and actually doing it. Whenever there's a new distribution release it invariably breaks a bunch of things with the automation and you spend more time massaging your playbook so it works again than it would have taken to do it by hand

> Whenever there's a new distribution release it invariably breaks a bunch of things with the automation and you spend more time massaging your playbook so it works again than it would have taken to do it by hand

The rolling-release life is that things break constantly, during each week’s upgrade, but only a little bit at a time (and hopefully in staging). I don’t know if this is better for system administration, necessarily, but if you’re used to a stable-release dynamic of heavy discrete breakage and piles of backported patches, then you might be imagining the same scale of breakage every upgrade, which is isn’t the experience at all. So don’t discard the rolling-release option because of this preconception.

Re: What's wrong with enterprise Linux

#62

If you have to run an "Enterprise Linux", you are probably required by regulations or compliance to have a support agreement in place. Whether it's RedHat or Oracle or something else, security is going take third place to compliance and stability.

"regulations" or "compliance" aren't the only reasons to value stability. If you have a $2 billion facility or a $200 million piece of industrial equipment, you're going to place value on stability regardless of what the regulations say.

Re: What's wrong with enterprise Linux

#63
post #2

> The Case for Oracle Linux I did not see that twist coming. Strangely, the author makes a good point. Oracle or not, sticking closer to the upstream kernel is not a bad way to manage an “enterprise” kernel. Maybe we’ve all been too willing to sit back and accept how RHEL does kernels as “the way”.

But what stops Oracle from just pulling a Red Hat when people switch over to Oracle Linux? Oracle hasn't exactly proven itself to be trustworthy over the years and that's putting it lightly. I think we need a fully open source alternative to RHEL not bound to any company. Something akin to the Debian project that can serve as an upstream reference distro and repository.

Oracle Linux, Red Hat, and Debian are all “fully open source”. What you mean is “not maintained by a corporation.”

Re: What's wrong with enterprise Linux

#64
I think there is something much more fundamental going on...

  1. Maintenance is expensive.

  2. Maintenance of living systems is even more so.

  3. People hate spending money on maintenance.

  4. You reap what you sow.

We can't even get bridge or road maintenance done correctly in the US [0]. Why should we think that IT systems would be any different when we just don't have that culture?

This is not a Linux problem - it's a culture problem (and probably goes well beyond the US).

[0] - https://infrastructurereportcard.org/cat-item/bridges-infras...

Re: What's wrong with enterprise Linux

#65
Talk to the CFOs and CTOs. They fund the hardware refresh cycles and have bonuses attached to regular appeasement of shareholders, the market as well as auditors and controllers.

The initiative begets the spend. The spend and roadmap stretches 10-12 years, chassis fans and PSUs have MTBF that conveniently coincide with Moore’s law and the dark arts of finance, where ownership is good but only to that boundary.

Re: What's wrong with enterprise Linux

#67

There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to b…

I have a customer with systems so old they weren’t at risk for heartbleed. He was excited about that.

Re: What's wrong with enterprise Linux

#68

Earlier quoted context omitted.

> I'd like to see the RHEL stability model go away too and force people to complete their automation and solve the problems of being able to rebuilding on demand - and actually doing it. Whenever there's a new distribution release it invariably breaks a bunch of things with the automation and you spend more time massaging your playbook so it works again than it would have taken to do it by hand

> Whenever there's a new distribution release it invariably breaks a bunch of things with the automation and you spend more time massaging your playbook so it works again than it would have taken to do it by hand The rolling-release life is that things break constantly, during each week’s upgrade, but only a little bit at a time (and hopefully in staging). I don’t know if this is better for system administration, nec…

The difference is: If there is a weekly breakage on a weekly update, delaying with it is just part of the process and timed in.

If you only update every few years, each update becomes a full project distracting from and conflicting with other projects.

Re: What's wrong with enterprise Linux

#69
post #42
post #8

What's not clear to me is that newer software is safer or just less tested. Although it's possible that newer versions are more secure, I couldn't find evidence of it yet. (Links are welcome).

Isn't an unknown vulnerability preferrable to a known vulnerabilty?

There is unknown and unreported, a large amount of unreported vulns are sold on the blackmarket or hoarded for exploit by foreign adversaries.

Re: What's wrong with enterprise Linux

#70

>This collection of software will remain locked at its specific version throughout the lifespan of that Enterprise Linux distribution release – which is often 10 years or more. Is this 10 year assumption true? Are people running 10 year old versions of operating systems today in non-safety or non-high security aspects? 10 years ago today is when the following were roughly released: - Linux 3.8. - RHEL 6.4 with Linux…

Absolutely. RHEL 7 (and downstreams) has maintenance support for another year, so there are many systems that administrators and now looking at upgrading. Speculatively, Red Hat timed the source availability change strategically to coincide with this epoch and force these administrators into a tight spot and hopefully get more subscriptions.

Should these systems have been upgraded sooner? One year has usually allowed plenty of time for testing and rollout of the next major release.

Post reply on HN