Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

51–60 of 235 posts

Re: What's wrong with enterprise Linux

#51

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…

How is the problem of TLS certificates related to Redhat Linux or Enterprise Linux? I think these are orthogonal problems.

I think it was an analogy. If you don't do a thing for a long time (updating SSL certificates, updating a Linux system to a major new version), the knowledge of how the systems were maintained/built gets lost. If you have an automated, repeatable process that moves with the times, it is more likely that the process is codified (either in documentation or in infrastructure as data) and easy to repeat.

Re: What's wrong with enterprise Linux

#52
post #5
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”.

> Oracle or not, sticking closer to the upstream kernel is not a bad way to manage an “enterprise” kernel. This is probably a lot better than expecting it to be possible to maintain a secure release with a level of compatibility guarantee for 10+ years.

Maybe, but it's not obvious. There are plenty of novel vulnerabilities in interfaces like io_uring and so forth. It's not that those features are bad, I'm just saying that there are tradeoffs to always getting the new stuff.

Maybe the compromise solution is to use newer kernels but keep certain features turned off until they "bake" properly.

Re: What's wrong with enterprise Linux

#53
post #32

Earlier quoted context omitted.

Red Hat doesn't change as little as possible, at least 30% of the changes to Linux make it to RHEL. Most of the RHEL kernel is a few months behind upstream despite the old version. The next minor release of RHEL, to be released in November, probably will have features up to 6.3 for many subsystems and bugfixes up to 6.5 for example.

Interesting, thank you for the details. This means that in some way, RHEL is ahead of Oracle Linux in terms of kernels? I don't see an UEK version tracking Linux 6.1 at all, AFAIK.

It's true that Red Hat does pull in changes from upstream for several subsystems of Linux. It's genuinely a frankenkernel mixed with code from 6.3, 6.1, etc.

But you're still beholden to what the Red Hat maintainers are pulling in and focusing on. It's still not a general follow upstream wholesale.

You can see and track what UEK is doing by looking at their Github: https://github.com/oracle/linux-uek/commits/uek7/u1

Re: What's wrong with enterprise Linux

#54

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.

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.

Re: What's wrong with enterprise Linux

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

Re: What's wrong with enterprise Linux

#56
>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 2.6.32-358

- RHEL 7 was Beta with Linux 3.10.0

Are these still alive out there?

Re: What's wrong with enterprise Linux

#57

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…

Years back (late 1990s) I worked with some mainframe people. They bragged that everything is hot fixable on the fly so they can apply security updates or replace broken hardware without rebooting. Then they admitted they schedule a reboot every 6 months anyway. Turns out the redundant backup power supply failed in at the same time and one hot patch was not applied to startup scripts and it took a week to figure out what was missing so the system booted again. By rebooting every 6 months they remember everything and so can get the system back up.

I probably have some details wrong in the story above. I worked with those people, but never on the mainframe. I think the point stands though, if you don't do something often it can't be done.

Re: What's wrong with enterprise Linux

#58

Holy.... that Oracle linux page is so friendly it almost makes me puke. I can't believe anyone would fall for them

The same company that just two weeks ago was sending out unsolicited emails asking companies about Java licensing - a friendly shakedown for using the official JRE... https://news.ycombinator.com/item?id=36599118 Frankly, I don't get it Oracle. I would say the priorities are backwards - JRE free, Oracle Linux paid would make more objective sense (especially because the JRE used to be free... and there's a lot of free…

I don't think there is any cross P&L strategy at play....

Re: What's wrong with enterprise Linux

#59
post #53

Earlier quoted context omitted.

Interesting, thank you for the details. This means that in some way, RHEL is ahead of Oracle Linux in terms of kernels? I don't see an UEK version tracking Linux 6.1 at all, AFAIK.

It's true that Red Hat does pull in changes from upstream for several subsystems of Linux. It's genuinely a frankenkernel mixed with code from 6.3, 6.1, etc. But you're still beholden to what the Red Hat maintainers are pulling in and focusing on. It's still not a general follow upstream wholesale. You can see and track what UEK is doing by looking at their Github: https://github.com/oracle/linux-uek/commits/uek7/u1

[deleted]

Re: What's wrong with enterprise Linux

#60

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. In this model, what happens when the next Python2->Python3 breaking change comes along?

Using whatever Python your distribution needed is bad practice. Own your application environment, there are plenty of ways to do this, such as Nix and Docker, which make your Python environments reproducible across systems. Also, Enterprise Linus is one of the reasons (definitely not the only) that the migration took such a long time. Too many enterprise shops that stuck with Python 2 because it's the lazy thing to d…

>Using whatever Python your distribution needed is bad practice. Own your application environment, there are plenty of ways to do this, such as Nix and Docker, which make your Python environments reproducible across systems.

How far down does "own your application environment" extend? How about libc? What is the role of the underlying OS?

Post reply on HN