Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

231–235 of 235 posts

Re: What's wrong with enterprise Linux

#231
post #196
post #105

Earlier quoted context omitted.

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.

If the average person were in an exceptionally good environment, they would likely get (much) better over time.

Re: What's wrong with enterprise Linux

#232
post #175

Earlier quoted context omitted.

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?

Here's an example where user space broke, and Linus gets pissed. "SHUT THE FUCK UP" to the maintainer who was defending the kernel change[1][2].

[1]: https://lkml.org/lkml/2012/12/23/75 [2]: https://news.ycombinator.com/item?id=36805308

Re: What's wrong with enterprise Linux

#233

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

I fully agree, moreover this:

> Rolling release distributions like OpenSUSE Tumbleweed follow upstream much more closely while still maintaining stability through thorough automated testing

Shows the author hasn't used Tumbleweed for any reasonable amount of time himself[0][1][2]. I daily drove it for a short while before moving to Fedora.

0: https://github.com/Foundry376/Mailspring/issues/533

1: https://forums.opensuse.org/t/tumbleweed-breaks-after-update...

2: https://www.reddit.com/r/openSUSE/comments/v09hnc/tumbleweed...

Re: What's wrong with enterprise Linux

#234
post #203
post #193

Earlier quoted context omitted.

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

Thank you for sharing this! Nothing helps you remember a fact like having been wrong about it in public. :)

Re: What's wrong with enterprise Linux

#235

Earlier quoted context omitted.

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

Passing through a device is more secure than bare-metal, yes, but I meant it as the Qubes OS project themselves dissuading the notion. And doing so decreases security for the whole system, which is why they advice against it, because you've now given a potential bridge back to the main system. Not that there's been many exploits for that yet, but if such systems were more common, there would be.

Regardless, even with the ease of virtual machines, Qubes OS doesn't really solve problems involved in professional management, nor should it be considered for that given the overhead of the system. It's a neat system, and for general purpose use it's pretty cool, but for stability and work required to update a system, it really doesn't.

Sure, it makes general use-cases pretty easy to update, but those aren't really much of a problem if you've set up a PXE server and have a base image together with default configuration. The issues occur when you're updating servers, which is what I was talking about, because the end-user isn't that important in this context.

Whether you have it running in a hypervisor or bare metal, it all comes back to properly configured backups. Qubes OS doesn't solve this, nor is it meant to. It increases security at the cost of convenience and complexity. Nor does it solve stability in a professional environment, because while it does give you an isolated OS per application or stack of applications, you've now increased your maintenance surface. Servers need to be updated, within a reasonable time frame of ones being provided, and general computing often requires more of that too.

And at the end of the day, while I do like Qubes OS and do like virtual machines, they're not the be all, end all, in regards to security. Exploits exist, and as with all things, the more common they become, the more will be made.

I do still hope for a system like Qubes OS in the future, just not Qubes OS.

Post reply on HN