Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

121–130 of 235 posts

Re: What's wrong with enterprise Linux

#121

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…

> LetsEncrypt did us a huge favor by forcing automation vs having the guy who knows how to update the SSL certs every 4.9 years and left 6 months ago.

Not in my experience. There's still a guy who goes around and updates (manually) all the LetsEncrypt certificates every year.

Re: What's wrong with enterprise Linux

#122
I think that one of the biggest problems for my use case is license management for things outside the data center. With windows I can buy a pro license and have it attached to the hardware. I never have to worry about tracking or managing the license. With RHEL I have to make sure that the computer is registered and logged in to the license correctly. There is a lot of extra work for things like developer workstations or instrument controllers etc. If I could just buy a license of a major version of RHEL for $200-$500 and have it locked to the hardware like windows that would relieve a major administrative burden.

Re: What's wrong with enterprise Linux

#123
post #55
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”.

At the same time it is not that convincing point because in lot of cases the value from freezing is pretty small for kernel compared to other software, because kernels strong "do not break userspace" attitude. Version freezing is far more valuable for various other projects that do not take backwards compatibility that seriously.

I thought the Linux kernel had a strong “don’t break userspace” attitude, but it was a free for all in kernel space. If you’re developing kernel modules or have custom hardware with drivers, I could see having a backported kernel as being a major problem for support and development.

Re: What's wrong with enterprise Linux

#124

What is Oracle going to do with the userland/RPM compat with RHEL? It's wonderful that they try to ship every fix from the LTS kernel tree and that UEK users already don't have an expectation of a 100% identical kernel. But you still need userland compatibility, which will be much harder to ensure given the sheer number of RPM packages out there.

The Linux kernel has a pretty strict "don't break userland" policy, and if it does it's a bug, so I wouldn't expect using a newer kernel to be a problem.

Ha. The contents of /sys for example change about every other release, and yes, there's obviously software which depends on it.

Re: What's wrong with enterprise Linux

#125

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…

> LetsEncrypt did us a huge favor by forcing automation vs having the guy who knows how to update the SSL certs every 4.9 years and left 6 months ago. Not in my experience. There's still a guy who goes around and updates (manually) all the LetsEncrypt certificates every year.

Shouldn't he be going around every couple of months?

Re: What's wrong with enterprise Linux

#126
post #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…

Yeah. Us programmers' minds keep looking for a 'solution', but this is one of those solutionless paradoxes modern technology brings. If technology is developing and improving, it will need maintainance. If it's mature and stable, it ideally won't need maintaince or there will be enough knowledgeable workers who know how to do it, and their knowledge won't get obsolete in a short time. Unfortunately, and fortunately, technology is improving.

Re: What's wrong with enterprise Linux

#127
post #47
post #23

Earlier quoted context omitted.

The idea is that you deploy from scratch all the infrastructure every 6 months, first to testing and then to production.

Every 6 months? That seems like a pretty long window for tribal knowledge to get lost. Is 6 months arbitrary or is there some reasoning behind that cadence?

Arguably, tribal knowledge and the dependence on it need to be managed as much as anything else.

Re: What's wrong with enterprise Linux

#128
post #54

Earlier quoted context omitted.

Not necessarily. RHEL-clones are ubiquitous in high-performance computing. Clusters and super-computers are hard to setup, consist of hundreds or thousands of nodes, and are used by scientists who are not programmers by trade. The RHEL-clone model works well for them, as they can't expect their users to keep code up to date with changes in the OS, they are used by known, mostly-trusted users, and the systems they run…

Scientific Linux? Package availability and familiarity get you a long way.

Scientific Linux was an RHEL-clone, and they couldn't keep it going even with RH sources.

> In April 2019, it was announced that feature development for Scientific Linux would be discontinued

Re: What's wrong with enterprise Linux

#129

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. 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…

It won't be. Not until comprehensive integration testing comes as standard.

If you dont have comprehensive integration tests it's less risky just to not upgrade unless you really need to.

Re: What's wrong with enterprise Linux

#130

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…

> LetsEncrypt did us a huge favor by forcing automation vs having the guy who knows how to update the SSL certs every 4.9 years and left 6 months ago. Not in my experience. There's still a guy who goes around and updates (manually) all the LetsEncrypt certificates every year.

We truly live in amazing times! We have language models that sound human and internet from space, but never bothered to schedule that script for updating TLS certs. Or put it in version control for that matter.

Sounds like my org :)

Post reply on HN