Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

141–150 of 235 posts

Re: What's wrong with enterprise Linux

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

Off-topic, but I have to admit enjoying the liberally mixed metaphors of things leaving and entering barns, bags and buildings.

And the music maker side of me thinks your post has the beginnings of a promising blues lyric. :-)

Re: What's wrong with enterprise Linux

#142
post #75

Earlier quoted context omitted.

Think of all the places Linux runs. Planes, trains, and automobiles. Medical equipment. So many other places. Many places that don't have readily available network access. Yet, many "enterprises" need support here. If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Considering just the m…

> If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network,…

Doesn't matter if the manufacturer provides updates for embedded software if the customer doesn't want to install those updates because they'd have to incur the cost and downtime of retesting and updating their upstream software to address any incompatibilities caused by those fixes. It's more common than you'd think.

Re: What's wrong with enterprise Linux

#143

Earlier quoted context omitted.

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

> Not in my experience. There's still a guy who goes around and updates (manually) all the LetsEncrypt certificates every year. LetsEncrypt certificates don't last for one year, they only last for 90 days, no exceptions. You may be thinking about something different.

They may be talking about the certbot software itself, which does the updating of certs.

Re: What's wrong with enterprise Linux

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

See here for an article that describes how it's done --> https://news.ycombinator.com/item?id=36763935

Re: What's wrong with enterprise Linux

#146

Earlier quoted context omitted.

> If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network,…

> If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network, and triply so when the software talks to some kind of cloud services. Talk to Qualcomm and NXP and MediaTek and Broadcom and STMicroelectronics and.... Seriously, most of this is complete…

One more exception is NXP i.MX 8M Quad, which is used in a Librem 5 phone.

Re: What's wrong with enterprise Linux

#147

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…

How about Qubes OS style, where everything runs in a VM?

Re: What's wrong with enterprise Linux

#148

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…

How about Qubes OS style, where everything runs in a VM?

>> How about Qubes OS style, where everything runs in a VM?

How does Qubes OS work with drivers for specialized hardware such as scientific lab equipment?

Re: What's wrong with enterprise Linux

#149
As a former hobbyist that is now working a lot with RHEL as a sysadmin, I was really surprised to learn how little advantage there actually is with buying Red Hat Support.

You are always limited to their opinionated decisions on what your deployment should look like* (or risk losing support), but at the same time, the support you actually get is next to none.

If I can't fix it myself, it ain't gonna be fixed.

At this point, I don't know what we are paying for anyways.

*As an example, more recent versions of RHEL only allow the use of NetworkManager for permanent network configuration. In a production hypervisor system, NM is completely unsuitable in my opinion. It's full of footguns and that will bite us at some point

Post reply on HN