Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

211–220 of 235 posts

Re: What's wrong with enterprise Linux

#211
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…

>>*Think of all the places Linux runs. """Planes, trains, and automobiles""". Medical equipment.* Where is your other embedded equipment??? I love that movie.

You can throw away an old router and put a completely new one in place, and it will work. A pretty easy way to upgrade.

Usually you cannot do the same with a flight computer or a medical device controller.

Re: What's wrong with enterprise Linux

#212
post #195

Earlier quoted context omitted.

We used to do this on several hpux servers at $dayjob. However 95% of those servers have long since been decommissioned, and the remaining server didn't actually need it to begin with. (It was really anything that had an oddball database that needed it)

If it runs Unix is isn't a mainframe. Only half joking.

I would say it's 90% not joking.

A mainframe has hardware different enough to require a different approach to the OS.

Of course a modern variant of System 390 happily runs tons of Linux VMs.

Re: What's wrong with enterprise Linux

#213

Earlier quoted context omitted.

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

Yes, there's substantial value in being able to have a specific bugfix and not have to upgrade an application and a ton of dependencies.

Or not even a fix. A known bug can be mitigated or worked around. Predictable is better.

Re: What's wrong with enterprise Linux

#214

Earlier quoted context omitted.

Absolutely spot on here, there's no reason for the obsession HN (and the wider internet) has with upgrades in these kinds of environments. These are not environments where you can tolerate unplanned downtime, this isn't a silly web app running in us-east.

Upgrades are a necessity if development goes on. And HN is full of developers. On a related note, the new EU Cyber Resilience Act will make upgrades a necessity even in the most constrained environments like pacemakers.

It's easier to do an update with a single security fix rather than an update that rolls in a ton of new functionality that ends up breaking your device. Seen this time and time again with OS/dependency update.

Re: What's wrong with enterprise Linux

#215
post #50

Earlier quoted context omitted.

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…

In 2017 I led a (painful) project to migrate from RHEL5 to Ubuntu 16. Since then, it has been pretty easy to go to 18 then 20, soon 22. The previous migration was in 2010 and was from RedHat 6 (not RHEL) to RHEL5. These projects were for projects that are "ghost deprecated" in that not much time is spent in talking about them but they are critically important to the business, as profit centers and cost drivers, but n…

22 might be difficult depending on what you use from Ubuntu 's repositories; they are converting apt apps to snaps.

Re: What's wrong with enterprise Linux

#216
Doesn't Debian Stable have the very same problem? You get dated software with bugs that are solved in newer versions. The fundamental model of freezing and (endlessly) testing some state of the packages that makes up a distribution simply doesn't make sense in a world with so many and so big changes.

This model is the "waterfall" model for operating systems.

Re: What's wrong with enterprise Linux

#217
“The engineers, maintainers, and testers […] put in the enormous amount of thankless work”

No, they actually get paid pretty well to do it. And pretty sure all the paying enterprise customers are “thankful” for the distribution’s stability and security, or they’d take their business elsewhere.

Re: What's wrong with enterprise Linux

#218
post #197

Earlier quoted context omitted.

I wonder if there would be a market for an enterprise-grade server microkernel OS. It's not the 90s anymore - Nintendo and QNX are shipping tens of millions of microkernel installs every year; and hardware is fast enough that choosing correctness and security over speed is a valid tradeoff. Maybe if I win the lottery...

These things tend to trade 200% performance for 10% security, though. That's not a tradeoff I am comfortable with in anything like all situations.

Not necessarily if you build them right. Nintendo’s Switch is a true microkernel and, if it cost 200% performance, there’s no way it would be viable on a 2015 Tegra X1. The 200% thing is kind of a myth that doesn’t apply to modern practice - now it’s more like 10%.

As for 10% security - it’s more than 10%. Take my same example, the Switch. No bugs have been found to launch unapproved software in the last 4 years. There’s always the Secure Boot bug by NVIDIA in earlier consoles, but not even a WebKit bug will get you homebrew on a Switch. Kind of a big deal…

Another example of this would be Microsoft’s experiments with what would happen if an OS was built with all apps running in managed code - no compiled apps. Performance cost? They got it down to just 7% (though, admittedly, Midori never shipped, but it did host Bing in a few countries for a few years.)

Re: What's wrong with enterprise Linux

#219
post #23
post #13

Earlier quoted context omitted.

Don't you end up with the same problem with the automation that has been running fine for 5 years, then suddenly breaks? And the person that set it up is either gone, or has no clue how they did it 5 years ago.

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

That's an amazing amount of effort expended on something that provides exactly zero revenue. I understand the concept, but I've never been fortunate enough to work in a business where that was practical.

Re: What's wrong with enterprise Linux

#220
post #207
post #174

Earlier quoted context omitted.

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.

Well, it had bounds checking. I always call them mainframes, regardless if the name is micro or whatever is the pedantic nomenclature.

Hmm, section 11.10 of http://wiki.parsec.com/openvms_archive/freewarev70/bliss/bls... says that the built-in vector type does not do bounds checking (tho there are examples illustrating how to define your own vector type that does check).

The string handling functions in chapter 20 require the programmer to pass around separate pointer and length arguments, which is not what I would call proper strings.

Post reply on HN