5 ms·

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

>> 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. So how could this be accomplished? A Nix-OS style approach coupled with an immutable OS core? It is much harder to offer stability guarantees than to just publish updates in a rolling release fashion. And yet big organizations pay big money for that stability or the support to poke an enterprise software provider to get stuff working for their needs.

sam_lowry_ 3y ago
ArchLinux-style rather thsn NixOS style. Just roll the updates when they are ready into your very own test, int, acc, and finally prod.
- thesuperbigfrog 3y ago
  >> ArchLinux-style rather thsn NixOS style. Just roll the updates when they are ready into your very own test, int, acc, and finally prod. The issue is that a rolling-release approach does not have stability guarantees and forces everything to be upgrading all the time. This does not work very well if you have specialized hardware or scientific equipment. If the drivers for your lab equipment work with a given release of an enterprise linux, you can't just jump on the next release until you have working drivers ready. The same is true if you are working with some enterprise software which is only certified to work with a given release of an enterprise linux. Would you really want to run business critical software on a version of the operating system which is not (yet) supported by the vendor?
- AnonymousPlanet 3y ago
  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.
  - fho 3y ago
    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.
    - sam_lowry_ 3y ago
      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.
    - AnonymousPlanet 3y ago
      Every single time I tried using arch, I had nothing but problems with updates. I wasted a lot of time hunting down documentation to things that broke, like mailing, logging, the DE, bluetooth, you name it. Changes that get taken care of by default in other distros. I had some very nasty surprises while using arch. My stable Ubuntu or Debian installs didn't even have a single glitch in the exact same timeframe.
pydry 3y ago
It won't be. Not until comprehensive integration testing comes as standard. If you dont have comprehensive integration tests it's less risky just to not upgrade unless you really need to.
- thesuperbigfrog 3y ago
  >> If you don't have comprehensive integration tests it's less risky just to not upgrade unless you really need to. Exactly. Most of us do not have sqlite-level (https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html) testing so we just do the best we can with the resources we have. This tends to make most "enterprise" shops risk-averse and the motto becomes "if it's not broke, don't fix it".
fsflover 3y ago
How about Qubes OS style, where everything runs in a VM?
- thesuperbigfrog 3y ago
  >> 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?
  - fsflover 3y ago
    Usually devices are connected to specific VMs and the drivers are installed inside them. VMs can run Lunux or Windows. See this: https://www.qubes-os.org/doc/how-to-use-devices/ https://www.qubes-os.org/doc/how-to-use-devices/
  - hju22_-3 3y ago
    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 required to update in a professional setting though, I'd say.
    - fsflover 3y ago
      > 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/thread/31e2d8a47c8b4474?scoring=d&q=GPU& 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-dom0-and-eol 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.

sam_lowry_ 3y ago

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

thesuperbigfrog 3y ago
>> ArchLinux-style rather thsn NixOS style. Just roll the updates when they are ready into your very own test, int, acc, and finally prod. The issue is that a rolling-release approach does not have stability guarantees and forces everything to be upgrading all the time. This does not work very well if you have specialized hardware or scientific equipment. If the drivers for your lab equipment work with a given release of an enterprise linux, you can't just jump on the next release until you have working drivers ready. The same is true if you are working with some enterprise software which is only certified to work with a given release of an enterprise linux. Would you really want to run business critical software on a version of the operating system which is not (yet) supported by the vendor?
AnonymousPlanet 3y ago
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.
- fho 3y ago
  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.
  - sam_lowry_ 3y ago
    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.
  - AnonymousPlanet 3y ago
    Every single time I tried using arch, I had nothing but problems with updates. I wasted a lot of time hunting down documentation to things that broke, like mailing, logging, the DE, bluetooth, you name it. Changes that get taken care of by default in other distros. I had some very nasty surprises while using arch. My stable Ubuntu or Debian installs didn't even have a single glitch in the exact same timeframe.

pydry 3y ago

It won't be. Not until comprehensive integration testing comes as standard. If you dont have comprehensive integration tests it's less risky just to not upgrade unless you really need to.

thesuperbigfrog 3y ago
>> If you don't have comprehensive integration tests it's less risky just to not upgrade unless you really need to. Exactly. Most of us do not have sqlite-level (https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html) testing so we just do the best we can with the resources we have. This tends to make most "enterprise" shops risk-averse and the motto becomes "if it's not broke, don't fix it".

fsflover 3y ago

How about Qubes OS style, where everything runs in a VM?

thesuperbigfrog 3y ago
>> 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?
- fsflover 3y ago
  Usually devices are connected to specific VMs and the drivers are installed inside them. VMs can run Lunux or Windows. See this: https://www.qubes-os.org/doc/how-to-use-devices/ https://www.qubes-os.org/doc/how-to-use-devices/
- hju22_-3 3y ago
  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 required to update in a professional setting though, I'd say.
  - fsflover 3y ago
    > 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/thread/31e2d8a47c8b4474?scoring=d&q=GPU& 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-dom0-and-eol 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.