Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

171–180 of 235 posts

Re: What's wrong with enterprise Linux

#171
post #74

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

It is the countless places that exist at some level between your two extremes of the nuclear power plant and the colo web host that need Enterprise Linux.

My point when I mentioned rolling-release was that I’m very unsure whether they need Enterprise Linux and a bout of desperate firefighting every several years or a rolling-release distro and a small but respected team with a staging environment and a steady supply of handheld fire extinguishers.

I could be convinced the former were the answer in many cases, but I’ve never seen the argument for that move beyond a bare proclamation like you’ve just made. It may also be that the argument for this is so mired in the particulars of a situation that it essentially can’t be articulated, but for me that’s mutually exclusive with it applying to a broad, vaguely defined classes of deployments like you’ve just done. (A complex argument is bound to produce an intricately shaped class.)

My (admittedly theoretical) fear in my initial comment was that the LTS people read about kernel updates every month, think of the breakage their LTS encounters on every kernel update, and nope out. Yet without the humongous pile of backported patches the LTS requires kernel updates are the most benign thing in the world if you can afford the reboots—a decade of them with literally not a single issue can and does happen.

Re: What's wrong with enterprise Linux

#172
post #50

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…

Oh my sweet summer child. There are plenty of enterprises still on RHEL 6, paying extra to keep patches coming. I bet there are still some on RHEL 5. Large, global companies. And of course there are many environments where software and hardware stay frozen for years. Telecoms, factory floors, automotive, finance, disconnected edge devices of all types... they test the absolute crap out of those systems, and pay for every certification availabl, and then leave them running for a decade.

The ability to stay abreast of major version updates is a wonderful attribute of many environments, but definitely far from all.

Re: What's wrong with enterprise Linux

#173

Earlier quoted context omitted.

Okay, that's fair, but do you kind of see how a shiny new domain name & blog with exactly one post and an anonymous author saying you can trust them because they're not affiliated with Oracle... Can you see how that appeal for trust hasn't been built on firm ground?

I didn’t see a particular appeal for trust in the OP. Not mentioning anything about non association would have seemed weirder. Sometimes it’s interesting to read or hear from someone with a high trust score. Other times it’s interesting to read or hear a line of reasoning without - or even negative - trust score. Only going by trust arguably is one of the fundamental problems with tribalism and echo chambers.

You deleted your other comment replying to me, I'm not sure why-- there was nothing wrong with questioning how I initially chose to respond, so I'll paste what I was writing back to you on that topic here:

Your original comment said 1) you didn't see an appeal for trust and 2) went on to make broader statements that trust isn't necessarily required when considering an opinion (on it's merits, independently of high/low trust, was my interpretation of what you wrote)

#2 Does not modify #1 in a way that would prohibit fair treatment of #1 when considering it alone. #1 is a straightforward question about the content of the article.

I didn't choose to address #2 because I agree, trust is not a requirement when considering someone's reasoning. In agreeing with you, there wasn't much for me to add.

Re: What's wrong with enterprise Linux

#174
post #161

Earlier quoted context omitted.

What are some of those languages? I'm curious to learn more.

Several PL/I dialects e.g. PL/S and PL.8, BLISS, Modula-2, ESPOL/NEWP for example. Also Pascal and BASIC compilers with several extensions, e.g. VMS Pascal and VMS BASIC.

BLISS is a typeless word-oriented language like BCPL, so I am surprised to see it in this list. Also I am amused to hear VAX/VMS described as a mainframe operating system.

Re: What's wrong with enterprise Linux

#175

Earlier quoted context omitted.

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.

Could you point to some examples of such breakage?

Re: What's wrong with enterprise Linux

#176

»Defenders will counter that this is a necessary tradeoff – you can’t have both stability and being fully up-to-date on security fixes. I’m not convinced that’s true as there are other Linux distributions that have shown you can have both. Rolling release distributions like OpenSUSE Tumbleweed follow upstream much more closely while still maintaining stability through thorough automated testing. Additionally, distrib…

Also when it comes to things like medical imaging, changes to the graphics stack (which includes userspace drivers) can and have altered how (e.g.) an MRI renders. So you can't go around making major updates to that stack every other week. It has to be certified and then re-certified after major updates and the vendor might need to be involved in that process. And you can't just skip it and "hope" that the MRI results are rendering properly.

Expand that out to all the other similar kinds of applications.

Re: What's wrong with enterprise Linux

#177

Earlier quoted context omitted.

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

Thanks! I never saw a problem with mixing metaphors so long as it still conveyed your thoughts accurately. Language is fluid, let it flow.

Re: What's wrong with enterprise Linux

#178
post #168

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

> 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 Ok, I'll be the unpopular person here. Some bugs, even security ones: are ok. I know that a very significant amount of software is mature these days, but sometimes upgrading causes different bugs, which are either harder to diagnose or even potenti…

A known bug beats an unknown update in a whole lot of enterprise use cases. This drives devs insane but it is true.

Re: What's wrong with enterprise Linux

#179

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 have a customer with systems so old they weren’t at risk for heartbleed. He was excited about that.

That was anybody who used Debian stable

Re: What's wrong with enterprise Linux

#180
post #74

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

So how about a more down-to-earth example. Medical imaging.

Changes to graphics drivers, can, do, and have impacted how things like MRI results get rendered by software. It's going to have at least some networking with the rest of the hospital and difficult to completely airgap, but at the same time you cannot update it willy nilly with the latest and greatest uncertified drivers.

That's precisely where "enterprise" distros are sometimes necessary.

Post reply on HN