Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

111–120 of 235 posts

Re: What's wrong with enterprise Linux

#111

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…

Long term support allows bad behavior but I think it's still useful to reduce the amount of feature/breaking changes happening to software.

Those problems can also be mitigated with mandatory environment rebuilds which is trivial for a lot of setups with infrastructure as code.

At the extreme end, you have Kubernetes/CNCF where 6 months go by and you're many versions behind with a huge changelog of breaking changes you have to fix first. Stable APIs and stable ABIs are very useful here (which enterprise Linux provides).

Re: What's wrong with enterprise Linux

#112

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…

Some time ago I was listening a guy talking about (operational) risk management in financial industry. One of his main points was that the systems in financial organizations should not be completely bug-free and automated. Because when something eventually happens, if there is no-one who has had to fix issues in the systems regularly, there is nobody around who can fix the system efficiently.

An example of argument that belongs to a weird class of arguments you at the same time want to agree and disagree.

Re: What's wrong with enterprise Linux

#113
Businesses only care about security fixes as far as compliance and a reasonable level risk.

It’s more important to them type be able to tell auditors that they are following a mitigation process.

In my case that means all I’m doing is pulling Amazon Linux images and running automatic security updates.

Using Amazon Linux is the path of least resistance because it comes with AWS tooling and it’s already optimized for AWS.

Everything else is basically “who cares?”

Re: What's wrong with enterprise Linux

#114

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

systemd threw the biggest wrench, by far, in my automation workflows (this was before containers came to dominate a lot of the landscape, so everything was managed with init scripts). I like it now, but it also broke things quite frequently in the early days, and there was a looong period of time when you had to shim software to work with systemd. But even still, things like snaps, the way Debian handles system Pytho…

Yup, enterprise Linux insulates you from unneeded change (in the business context). For most companies, systemd will have no impact on the bottom line vs sysvinit vs whatever.

However, paying an extra engineer to sort through all the changes possibly will.

On the other hand, there's some interesting trends like monokernels and minimal OS images that leverage services running off-machine instead of expecting so many local services removing some of the complexity/volatility (DNS, SMTP, federated login)

Re: What's wrong with enterprise Linux

#115

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…

> 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 build it, and so on.

This is known as the out-of-the-loop performance problem. [1]

[1] https://en.wikipedia.org/wiki/Out-of-the-loop_performance_pr...

Re: What's wrong with enterprise Linux

#116

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. So how could this be accomplished? A Nix-OS style approach coupled with an immutable OS core? It is much harder to offer stability guarantees than to just publish updates in a rolling release fashion. And yet big organizations pay b…

ArchLinux-style rather thsn NixOS style. Just roll the updates when they are ready into your very own test, int, acc, and finally prod.

>> ArchLinux-style rather thsn NixOS style. Just roll the updates when they are ready into your very own test, int, acc, and finally prod.

The issue is that a rolling-release approach does not have stability guarantees and forces everything to be upgrading all the time.

This does not work very well if you have specialized hardware or scientific equipment. If the drivers for your lab equipment work with a given release of an enterprise linux, you can't just jump on the next release until you have working drivers ready.

The same is true if you are working with some enterprise software which is only certified to work with a given release of an enterprise linux. Would you really want to run business critical software on a version of the operating system which is not (yet) supported by the vendor?

Re: What's wrong with enterprise Linux

#117
post #78

Earlier quoted context omitted.

Having worked in both kinds of cultures, I tend to agree. Keeping up is ultimately less pain than trying to upgrade things in huge chunks. But it can be really hard to change the culture at a place that has a long history of "ain't broke, don't fix it" engineering.

Less pain yes but more efficient? I'm not sure. The places that don't do constant upgrades also don't usually have teams looking after that. If they time it right they can do with less people. Of course it's less reliable not having as much active knowledge but I do think it can be cheaper if nothing goes wrong.

Yes, that can be the tradeoff, and a reasonable one in the right circumstances. Some projects are like that where there is really no team dedicated to anything more than keeping the lights on.

In my comment, I was thinking of well staffed (or at least close-enough to well staffed) teams making deliberate decisions to defer.

Re: What's wrong with enterprise Linux

#118
post #76
post #72

Earlier quoted context omitted.

This doesn't surprise me. Mainframes aren't just about never failing; they have a whole culture, including ops, around providing availability in ways that actually work.

Starting by having systems programming languages that actually have proper strings, arrays and bounds checking.

[deleted]

Re: What's wrong with enterprise Linux

#119

This whole model is in decline. Most companies have moved to the cloud and are using kubernetes. If you're running servers a datacenter then you might use enterprise linux. You are probably using some kind of virtualization like ESX or Nutanix. You might be using k8s there too. The age of running your own linux servers is ending in a way.

Sorry, and where do you install k8s exactly?

Re: What's wrong with enterprise Linux

#120
post #109

We use Oracle Linux where I work because we used to use Solaris. At one point it looked suspiciously like Redhat had explicitly removed support for some Oracle hardware from their kernel and the UEK saved us. Besides the kernel they also offer a few other extras and optional newer versions like dtrace, support for some extra filesystems and newer KVM. I get the impression that the fact that they're underdogs in the L…

>Redhat had explicitly removed support for some Oracle hardware

Sure, if you already had Oracle as a hardware vendor then the cat is out of the bag, barn doors open w/ horse gone. After that, using their distro isn't going to increase your attack surface much, the killer is already inside the house.

Post reply on HN