Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

201–210 of 235 posts

Re: What's wrong with enterprise Linux

#201
post #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…

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

You get to shift your blame on someone else. It's a commercial "covering your behind as a service", that you just blame $vendor when things go bad. It's the game big corps play, sometimes called "compliance".

Re: What's wrong with enterprise Linux

#202
> By locking packages to specific versions and only backporting select fixes, these distributions lag significantly behind upstream versions when it comes to security bugfixes, albeit unintentionally.

And the "upstream versions" are how better from a security POV when they are mostly an incompatible redesign ? Or the OP means that GTK4 has fewer CVEs than GTK3 because it is newer and better ?

A new version of a library (or a program) does not mean a more secure version. It is mostly "new features" and the bugs are left there to rot.

Re: What's wrong with enterprise Linux

#203
post #193

Earlier quoted context omitted.

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.

Nope, API compatibility is also explicitly disavowed:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Re: What's wrong with enterprise Linux

#204

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

Sure, windows advertises 10 years for enterprise:

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/t...

Though for newer releases they partially reduced it to 5 years.

Re: What's wrong with enterprise Linux

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

That brings flashbacks of my PS3. I had one, but I ended up not playing it because every time I switched it on there was a 2 hour mandatory download.

When you only have a couple of hours free time, spending it updating firmware means that I just don't update or use it.

Re: What's wrong with enterprise Linux

#206

Earlier quoted context omitted.

ArchLinux-style rather thsn NixOS style. Just roll the updates when they are ready into your very own test, int, acc, and finally prod.

All those hours hunting for the reasons why something suddenly stopped working every two or three weeks need to be paid. So maintenance cost for Linux servers would either skyrocket or no updates would ever be done for years. There are very good reasons why rolling releases in infrastructure are basically a no-go.

Didn't Google just switch to rolling releases?

Also shout-out to Arch ... I've been using it since ... forever and never really had an issue in update.

Re: What's wrong with enterprise Linux

#207
post #174
post #161

Earlier quoted context omitted.

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.

Well, it had bounds checking.

I always call them mainframes, regardless if the name is micro or whatever is the pedantic nomenclature.

Re: What's wrong with enterprise Linux

#208

Earlier quoted context omitted.

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

Depends, I think. I remember you being able to finagle a passthrough of devices, the underlying software can do that with little issue and once passed through it shouldn't be an issue, but I vaguely remember there being some notion of that being dissuaded. Mostly because of the increased attack surface, I think. Though that was a few years ago now. Qubes OS doesn't really solve much in regards to stability and work r…

> but I vaguely remember there being some notion of that being dissuaded. Mostly because of the increased attack surface, I think.

Using a GPU passthrough indeed decreases the security, but it is still much more secure than anything else. More details: https://groups.google.com/group/qubes-devel/browse_frm/threa...

> Qubes OS doesn't really solve much in regards to stability and work required to update in a professional setting

Couldn't disagree more. All software runs in VMs. The Admin VM never goes to the Internet or runs anything. Therefore it's less necessary to update and reboot it: https://www.qubes-os.org/doc/supported-releases/#note-on-dom...

All VMs are easy to backup/restore in a few clicks; cloning for testing and upgrading are amazingly smooth. All this with a great GUI.

Re: What's wrong with enterprise Linux

#209
post #206

Earlier quoted context omitted.

All those hours hunting for the reasons why something suddenly stopped working every two or three weeks need to be paid. So maintenance cost for Linux servers would either skyrocket or no updates would ever be done for years. There are very good reasons why rolling releases in infrastructure are basically a no-go.

Didn't Google just switch to rolling releases? Also shout-out to Arch ... I've been using it since ... forever and never really had an issue in update.

Same here, I ran Arch on Hetzner Cloud and find it superior in many subtle ways.

Rolling updates mean that I have to carefully choose what to install in order to keep the maintenance costs down. This has the side effect of reducing the attack surface.

I also manually review updates, which means that I keep up with the news in OS land.

I have to reboot once in a while because of updates, which means that I test resilience of my infrastructure.

By comparison, RedHat stack at work feels creepled and ancient.

You need a RedHat account (read: subscription) for pretty much everything, even the most basic documentation or downloads and yet my bugs in their bugzilla linger for months with none even trying to reproduce, let alone fix.

Re: What's wrong with enterprise Linux

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

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.

Post reply on HN