Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

Post reply on HN
Print view View original

91–100 of 235 posts

Re: What's wrong with enterprise Linux

#91

Post by bcantrill »

scrlk wrote: post #17
CrampusDestrus wrote: post #4

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

I'm reminded of Bryan Cantrill's rant about Oracle: https://www.youtube.com/watch?v=-zRN7XLCRhc&t=1981s > "As you know people, as you learn about things, you realize that these generalizations we have are, virtually to a generalization, false. Well, except for this one, as it turns out. What you think of Oracle, is even truer than you think it is. There has been no entity in human history with less complexity or nuan…

So, that rant actually predates Oracle v. Google. (For a bit of a history of my LISA talk that you quoted, and then my added color on Oracle v. Google see [0].) Oracle has shown everyone over and over again who they are; it shows how deep the mistrust in Red Hat has become that Oracle seems benign by comparison.

[0] https://www.youtube.com/watch?v=Zpnncakrelk#t=15m16s

Re: What's wrong with enterprise Linux

#92

Post by tmottabr »

retzkek wrote: post #70
filereaper wrote: post #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…

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…

And after that there is still Extended Support.

RHEL 6 is still under extended support until next year.

Re: What's wrong with enterprise Linux

#93

Post by wkat4242 »

darkhelmet wrote: post #7

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…

In my experience updates are not forgotten. Even automated.

Upgrades however are a different story. The major version changes require a ton of testing and manual massaging. This is why enterprises like to have that infrequently. For the systems that are easier you can still choose to follow the releases quickly.

Because security patches are being back ported is usually not a real issue.

Re: What's wrong with enterprise Linux

#94

Post by voakbasda »

mfer wrote: post #75
darkhelmet wrote: post #7

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…

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, and triply so when the software talks to some kind of cloud services.

For most products, the customer should have the power decide when that hardware reaches EOL. In other words, it should be illegal (and severely punished) to disable or downgrade devices remotely, whether by abdicating the responsibility to maintain their software or by shutting down network services that those devices require to operate fully.

At the very least, that would prevent the proliferation of pervasive networking features that have no business communicating with anyone except their owners.

Re: What's wrong with enterprise Linux

#95

Post by johannes1234321 »

dralley wrote: post #74
johannes1234321 wrote: post #68

Earlier quoted context omitted.

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.

> 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. That entirely depends on your operations model. There's a difference between, say, a nuclear power plant and a colo web hosting shop. With the latter, sure, no problem risking "minor" weekly breakage. With the former, I'd much rather have scheduled, heavily tested and carefully monitored m…

A nuclear power plant control software hopefully isn't connected to external systems, but fully isolated.

And yes, upgrading that is a full blown project.

It is very different from a "living" software environment with ongoing development processes.

Re: What's wrong with enterprise Linux

#96

Post by smarx007 »

freedomben wrote: post #80
smarx007 wrote: post #35

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.

No, I meant to ask how Oracle is going to ensure that they deliver 10s of thousands RPM packages to be sufficiently compatible with those that RHEL ships (following the rhelgate or whatever we should call it).

Re: What's wrong with enterprise Linux

#97

Post by tjalfi »

wmf wrote: post #72
bluGill wrote: post #57

Earlier quoted context omitted.

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

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.

I've also heard of teams that shut down the mainframe for an hour during a time change. It's an easy way to avoid application issues for a small amount of downtime.

Re: What's wrong with enterprise Linux

#98

Post by samstave »

>*What's wrong with enterprise Linux*

For me was when I was trying to incorporate Redhat, Intel and Mirantis as a secure platform for on-prem-cloud as a service offering - and we were setting up the environment with RH, Intel and Mirantis (I was the Mirantis tech PM) - and it was a nightmare of IBM-esque beurocracy.

it reminded me of the nightmares of installing equipment in an IBM/Intel DC in the 90s...

Too fn many non-technical stakes in an undefined landscape and RH attempting to "feel enterprise" with Intel - and it was a disaster. (two FN months to get IP allocations????)

Yeah - I signed off on redhat way before this - but this is what made me hate RHEL.

They got too smarmy, just as LinuxCare did...

But to answer the Q -- They attempted to get 'too enterprisey with it' and emulate those who they were previously trying to take down.

(want some linuxcare stories)

Re: What's wrong with enterprise Linux

#99

Post by rightbyte »

darkhelmet wrote: post #7

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…

If certificate renewal is automatic why do it at all ...

Re: What's wrong with enterprise Linux

#100

Post by darkhelmet »

pavon wrote: post #50
darkhelmet wrote: post #7

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…

That is a good point, however I've not heard of too many cases where organizations intentionally skip RHEL releases. Systems that are being actively developed do regularly upgrade through each RHEL release, and the 10 year support just lets them be lazy about how quickly they do so. The only systems I see intentionally riding out the 10+ year support are deprecated systems that are already announced to sunset by the…

It's one of the things that ground Yahoo to a halt. We spent years migrating from RHEL-4 to 6, then RHEL-6 to RHEL-7, and by the time the projects were pretty much complete, the next sunset was approaching. My cynicism comes from seeing the bad things that "Enterprise Linux" enabled there.

Admittedly, Yahoo was an extreme case. It never solved the really building problem - the culture from the early days was to compile, ship and forget. Once a RHEL-6 package was pushed to our dist/yinst system (packages), it would never be rebuilt unless it was 1) necessary, or 2) It was time to try and figure out how to build it on RHEL-7.

A lot of effort was spent in the later years to try and address this (by burning the old tech stack to the ground), but the culture was pervasive for the longest time. If 10-year-RHEL didn't exist we would have been forced to address the building processes.

If it's hard or error prone, then do it frequently until you get the process nailed down.

Post reply on HN