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

> 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

geerlingguy 3y ago
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 Python, and various little changes that have an outsize effect on automated deployment do cause a good amount of churn with automation.
- nijave 3y ago
  Yup, enterprise Linux insulates you from unneeded change (in the business context). For most companies, systemd will have no impact on the bottom line vs sysvinit vs whatever. However, paying an extra engineer to sort through all the changes possibly will. On the other hand, there's some interesting trends like monokernels and minimal OS images that leverage services running off-machine instead of expecting so many local services removing some of the complexity/volatility (DNS, SMTP, federated login)
- midoridensha 3y ago
  >things like snaps, the way Debian handles system Python Both these things should not be an issue for anyone, just one or the other.
mananaysiempre 3y ago
> 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 The rolling-release life is that things break constantly, during each week’s upgrade, but only a little bit at a time (and hopefully in staging). I don’t know if this is better for system administration, necessarily, but if you’re used to a stable-release dynamic of heavy discrete breakage and piles of backported patches, then you might be imagining the same scale of breakage every upgrade, which is isn’t the experience at all. So don’t discard the rolling-release option because of this preconception.
- johannes1234321 3y ago
  The difference is: If there is a weekly breakage on a weekly update, delaying with it is just part of the process and timed in. If you only update every few years, each update becomes a full project distracting from and conflicting with other projects.
  - dralley 3y ago
    > The difference is: If there is a weekly breakage on a weekly update, delaying with it is just part of the process and timed in. That entirely depends on your operations model. There's a difference between, say, a nuclear power plant and a colo web hosting shop. With the latter, sure, no problem risking "minor" weekly breakage. With the former, I'd much rather have scheduled, heavily tested and carefully monitored maintenance windows. And HN tends to underestimate the number of places like the former exist. Backbones of global finance and telecom, industrial facilities of all kinds, etc.
    - johannes1234321 3y ago
      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.
      - dralley 3y ago
        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" distros are sometimes necessary.
        nubinetwork 3y ago

geerlingguy 3y ago

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 Python, and various little changes that have an outsize effect on automated deployment do cause a good amount of churn with automation.

nijave 3y ago
Yup, enterprise Linux insulates you from unneeded change (in the business context). For most companies, systemd will have no impact on the bottom line vs sysvinit vs whatever. However, paying an extra engineer to sort through all the changes possibly will. On the other hand, there's some interesting trends like monokernels and minimal OS images that leverage services running off-machine instead of expecting so many local services removing some of the complexity/volatility (DNS, SMTP, federated login)
midoridensha 3y ago
>things like snaps, the way Debian handles system Python Both these things should not be an issue for anyone, just one or the other.

mananaysiempre 3y ago

> 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 The rolling-release life is that things break constantly, during each week’s upgrade, but only a little bit at a time (and hopefully in staging). I don’t know if this is better for system administration, necessarily, but if you’re used to a stable-release dynamic of heavy discrete breakage and piles of backported patches, then you might be imagining the same scale of breakage every upgrade, which is isn’t the experience at all. So don’t discard the rolling-release option because of this preconception.

johannes1234321 3y ago
The difference is: If there is a weekly breakage on a weekly update, delaying with it is just part of the process and timed in. If you only update every few years, each update becomes a full project distracting from and conflicting with other projects.
- dralley 3y ago
  > The difference is: If there is a weekly breakage on a weekly update, delaying with it is just part of the process and timed in. That entirely depends on your operations model. There's a difference between, say, a nuclear power plant and a colo web hosting shop. With the latter, sure, no problem risking "minor" weekly breakage. With the former, I'd much rather have scheduled, heavily tested and carefully monitored maintenance windows. And HN tends to underestimate the number of places like the former exist. Backbones of global finance and telecom, industrial facilities of all kinds, etc.
  - johannes1234321 3y ago
    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.
    - dralley 3y ago
      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" distros are sometimes necessary.
      - nubinetwork 3y ago