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

191–200 of 235 posts

Re: What's wrong with enterprise Linux

#191

Post by nubinetwork »

tjalfi wrote: post #97
wmf wrote: post #72

Earlier quoted context omitted.

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.

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)

Re: What's wrong with enterprise Linux

#192

Post by midoridensha »

geerlingguy wrote: post #46
bogantech wrote: post #14

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. Whenever there's a new distribution release it invariably breaks a bunch of things with the automation and you spend more time massaging your playbook so it works again than it would have taken to do it by hand

systemd threw the biggest wrench, by far, in my automation workflows (this was before containers came to dominate a lot of the landscape, so everything was managed with init scripts). I like it now, but it also broke things quite frequently in the early days, and there was a looong period of time when you had to shim software to work with systemd. But even still, things like snaps, the way Debian handles system Pytho…

>things like snaps, the way Debian handles system Python

Both these things should not be an issue for anyone, just one or the other.

Re: What's wrong with enterprise Linux

#193

Post by pxc »

mbreese wrote: post #123
zokier wrote: post #55

Earlier quoted context omitted.

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.

I thought the Linux kernel had a strong “don’t break userspace” attitude, but it was a free for all in kernel space. If you’re developing kernel modules or have custom hardware with drivers, I could see having a backported kernel as being a major problem for support and development.

My (spectator's) understanding is that ABI compatibility is not a priority for kernelspace in Linux, but there is care taken for backwards compatibility in other ways (like at an API level). You're just expected to recompile your out-of-tree kernel modules when there's a new kernel version.

Re: What's wrong with enterprise Linux

#194

Post by nubinetwork »

dralley wrote: post #180
johannes1234321 wrote: post #95

Earlier quoted context omitted.

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

At $dayjob, PACS devices use a separate VLAN and can only talk to their servers. Although to be fair, most of the problems with that system are down to the frontend using outdated js/asp/Java code that edge/chrome doesn't support anymore.

Re: What's wrong with enterprise Linux

#195

Post by TylerE »

nubinetwork wrote: post #191
tjalfi wrote: post #97

Earlier quoted context omitted.

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.

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.

Re: What's wrong with enterprise Linux

#196

Post by TylerE »

gjvc wrote: post #105
darkhelmet wrote: post #100

Earlier quoted context omitted.

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

If it's hard or error prone, then do it frequently until you get the process nailed down. Major life lesson -- practice makes perfect.

Practice makes something permanent. Wether that is perpetual perfection or perpetual mediocrity depends on the person.

The average person could practice violin for 500 years and never be invited to play Carnegie Hall.

Re: What's wrong with enterprise Linux

#197

Post by TylerE »

gjsman-1000 wrote: post #48
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…

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.

Re: What's wrong with enterprise Linux

#198

Post by frankreyes »

Enterprise stuff is decided by directors over fancy dinners, charity events, and business class plane flights by bureaucrats. Enterprise Linux needs to learn how to play the lobbying game

This is sometimes called "compliance".

At a previous job we had a bunch of servers that were reaching End of Life and the tech staff already was planning on upgrading, but someone in the bureaucracy with veto and signature powers decided to extend their life to an extended warranty.

We had to keep running those slow and power hungry things for a few more years because we run out of budget.

Re: What's wrong with enterprise Linux

#199

Post by kierank »

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…

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.

Re: What's wrong with enterprise Linux

#200

Post by kierank »

bandrami wrote: post #178
dijit wrote: post #168

Earlier quoted context omitted.

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

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.
Post reply on HN