4 ms·

I'm wondering, what ties you so strongly to a single OS? Nay, to a single Linux distribution? I have a hard time imagining, and the only scenarios that come to

I'm wondering, what ties you so strongly to a single OS? Nay, to a single Linux distribution? I have a hard time imagining, and the only scenarios that come to mind are those where things have gone awfully haywire. I'm sure I'm missing something. Enlighten me?

nine_k 6y ago
An existing support contract? If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong.
- webmaven 6y ago
  > If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong. There is a difference between asking "how do I ensure there is one throat to choke when things go wrong?", and "how do I minimize the potential for things to go wrong?" RHEL is a decent solution if you are trying to answer the former question (or both), but many budget conscious orgs focused on the latter and chose CentOS. Red Hat has now pulled the rug out from under them by trimming eight years off the EOL previously committed to with little notice. EOL in this case means "no security updates" so even if your org was prepared, technically, to deal with a zero-day for example by rolling out an update in a timely manner without relying on paying a vendor for hand-holding, that option has now been eliminated. Essentially, you now only get the stability and problem-minimization if you also pay the vendor for support. Otherwise you're stuck with a (relatively) unstable rolling release that will keep your internal teams very busy with a constant stream of minor issues, or potentially trying to roll-your-own updates or backports after the EOL for anything serious. It's difficult to see this as anything other than a naked, money-grabbing betrayal of users.
soraminazuki 6y ago
Software doesn’t run on its own. They rely on bunch of other software that is typically provided by distributions. So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, the entire software industry is suddenly going to have to spend significant amounts of time on repackaging work.
- joana035 6y ago
  There is alien[1], but I'm not sure if it is flawless, because of slightly different ways of doing things across distros like /etc/default vs /etc/sysconfig for example. Depending on how good is the source, its usefulness and dependencies, packaging it to Debian is pretty straight forward. The dh_* helpers[2] does the job automatically most of the time. There is also tools for helping with specific languages, like dh-make-golang, dh-python, etc... [1] https://packages.debian.org/buster/alien https://packages.debian.org/buster/alien [2] https://manpages.debian.org/testing/debhelper/debhelper.7.en.html https://manpages.debian.org/testing/debhelper/debhelper.7.en...
  - soraminazuki 6y ago
    From the looks of it, alien is just a tool to convert between different package formats and is not a replacement for proper packaging work. Very much like how you can’t take a deb package from different releases of the same distro and expect things to work properly, you can’t just take RPMs from CentOS to a whole different distro and expect things to work. It’s not only the differences in the packaging format that you have to take care of. There’s also version differences, path differences, dependency handling, and many other stuff to take care of. These are the kind of tasks which can’t be automated away and require non-trivial amount of work. For organizations that maintain tens, hundreds, or thousands of CentOS packages that spans multiple teams, moving to other distros would be time-consuming and costly. It would certainly pay off if it was driven by technical reasons, but for organizations that are forced to switch by this announcement, this is just pure overhead.
- nix23 6y ago
  >Java , postgres and tomcat That's his stack... >So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, It's not magic, just alien.
  - soraminazuki 6y ago
    > >Java , postgres and tomcat > That's his stack... What’s your point and when did I ever mention Java? > It's not magic, just alien. Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.

nine_k 6y ago

An existing support contract? If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong.

webmaven 6y ago
> If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong. There is a difference between asking "how do I ensure there is one throat to choke when things go wrong?", and "how do I minimize the potential for things to go wrong?" RHEL is a decent solution if you are trying to answer the former question (or both), but many budget conscious orgs focused on the latter and chose CentOS. Red Hat has now pulled the rug out from under them by trimming eight years off the EOL previously committed to with little notice. EOL in this case means "no security updates" so even if your org was prepared, technically, to deal with a zero-day for example by rolling out an update in a timely manner without relying on paying a vendor for hand-holding, that option has now been eliminated. Essentially, you now only get the stability and problem-minimization if you also pay the vendor for support. Otherwise you're stuck with a (relatively) unstable rolling release that will keep your internal teams very busy with a constant stream of minor issues, or potentially trying to roll-your-own updates or backports after the EOL for anything serious. It's difficult to see this as anything other than a naked, money-grabbing betrayal of users.

soraminazuki 6y ago

Software doesn’t run on its own. They rely on bunch of other software that is typically provided by distributions. So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, the entire software industry is suddenly going to have to spend significant amounts of time on repackaging work.

joana035 6y ago
There is alien[1], but I'm not sure if it is flawless, because of slightly different ways of doing things across distros like /etc/default vs /etc/sysconfig for example. Depending on how good is the source, its usefulness and dependencies, packaging it to Debian is pretty straight forward. The dh_* helpers[2] does the job automatically most of the time. There is also tools for helping with specific languages, like dh-make-golang, dh-python, etc... [1] https://packages.debian.org/buster/alien https://packages.debian.org/buster/alien [2] https://manpages.debian.org/testing/debhelper/debhelper.7.en.html https://manpages.debian.org/testing/debhelper/debhelper.7.en...
- soraminazuki 6y ago
  From the looks of it, alien is just a tool to convert between different package formats and is not a replacement for proper packaging work. Very much like how you can’t take a deb package from different releases of the same distro and expect things to work properly, you can’t just take RPMs from CentOS to a whole different distro and expect things to work. It’s not only the differences in the packaging format that you have to take care of. There’s also version differences, path differences, dependency handling, and many other stuff to take care of. These are the kind of tasks which can’t be automated away and require non-trivial amount of work. For organizations that maintain tens, hundreds, or thousands of CentOS packages that spans multiple teams, moving to other distros would be time-consuming and costly. It would certainly pay off if it was driven by technical reasons, but for organizations that are forced to switch by this announcement, this is just pure overhead.
nix23 6y ago
>Java , postgres and tomcat That's his stack... >So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, It's not magic, just alien.
- soraminazuki 6y ago
  > >Java , postgres and tomcat > That's his stack... What’s your point and when did I ever mention Java? > It's not magic, just alien. Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.