3 ms·

As I'm reading the comments I'm a bit curious what services people are running, or dependent on CentOS for, that FreeBSD or Debian can not provide? In the past

As I'm reading the comments I'm a bit curious what services people are running, or dependent on CentOS for, that FreeBSD or Debian can not provide? In the past I could see buying into an eco-system of tooling that helped you manage fleets of servers but with Ansible, Docker, etc wouldn't the tooling be agnostic to the OS? What exactly is it that you are running in your infrastructure that doesn't have a stable alternative? - DNS - DHCP - Webservers - Database servers - Firewalls - IDS - VPN - Auth services You can PXE boot, use tools like foreman, upload images to VPS provider(s). At least speaking for FreeBSD you have regular release cycles, security advisories, etc. I'm probably old but this scenario has played out plenty of times and the comments are the same that were on mailing lists when RedHat Linux was moved to Fedora. I remember when the CentOS maintainer(s?) disappeared and delays between CentOS 5/6 and RHEL6. People talked about how their business were so dependent on this OS how could a maintainer just abandon it..etc. Now resources and efforts are split between Alma and Rocky linux at what point do you evaluate what you "really" need from your systems and if the constant wait-and-see, buy-out, merge, fork process just becomes noise. Has it never come up in any risk assessment for large companies to have a contingency if the OS is no longer available or the licensing changes?

CoolCold 3y ago
> Docker FreeBSD is lacking support of Docker - they prefer to think they can ingest system management knowledge into Frontend Developers and suggest to use Jails (with ZFS/Nullfs/VNET/other horrible words for Joe The Svelte Dev ) > upload images to VPS Some still have things running on premises > dependent on CentOS for, that FreeBSD or Debian can not provide Good luck running SAP products on this > FreeBSD you have regular release cycles, security advisories FreeBSD lacks the idea of LTS. At most you (to my knowledge) you may have updates to a) the very minimal set of things aka base system b) it ends in ~ 5 years, not even 7 or 10 c) someone will need to the the job to keep security support for ports tree for 5 years to ensure versions are kept the same. Or in other words - requires more human power on your side comparing to offloading that to the vendor. For some FreeBSD guys example may be needed. Imagine you installed latest Ubuntu LTS (22.04) which has Nginx (as part of the whole distribution provided, not "base"/"ports" separated) and it's version is 1.18 and for next 5+ years it will keep the same version. No surprises. You even run auto-upgrade everynight and reboot server ~ once a month for kernel updates. Then repeat the same on FreeBSD - the ports tree will get updated with newer Nginx ( I've checked https://ports.freebsd.org/cgi/ports.cgi?query=nginx&stype=all https://ports.freebsd.org/cgi/ports.cgi?query=nginx&stype=al... here, it's 1.24.0 and no older versions available) and when 1.25.1 will be become new mainline (probably in 1.26?) your configuration will stop working as they have deprecated "ssl on;" construct. Or, other sample - let's say I'm developing Nginx module and selling it in binary form. I realize that my auditory is Centos/Ubuntu users. I know in advance in that case, which compatibility I need to support in terms of ABI, features, support articles and training. It helps me [as vendor of 3rd party software] with planning and keeping lower costs.
- ZeroSolstice 3y ago
  From reading your response I think there are more questions than answers. I'll quickly go through the first ones and get to the main items. 1. Docker does run on Debian[1][2] which is why I referenced "Freebsd or Debian." For reference I've run and used jails for a number of years with development, staging, and production environments. I don't know why frontend developers would be doing system administration, setting security controls, or that using Docker would count as "system management knowledge." 2. I spoke to the on premise part with foreman[2] and pxe booting. The VPS uploading was in comparison to the default images already available for linux with cloud providers verse FreeBSD. Generally speaking, on your FreeBSD example and most of your points, it reads to me as regular system administration. You can manage your ports and packages just like having .rpm or .dep repos with poudriere[4]. You can lock specific versions of software from automatic updates or not. I'm not really sure why 5 years isn't enough time for a base OS to be supported since you can build your ports from source at anytime. Yes you are required to check the UPDATING file for any breaking changes however if nginx or similar application is critical to your operation and you are speaking to using Docker and other build tools wouldn't you be testing software upgrades anyway? As a vendor wouldn't you have nightly builds to download the latest nginx version and test it? It would seem a bit naive to just "trust" that an auto update would never cause issues because its in LTS. The bigger item to address, if you are purchasing and using SAP products as part of your business or are a vendor producing/selling a module I don't think the CentOS complaint holds water. The risk you have accepted is that you have no control over how the support, development or updates progress but you want no surprises because it affects your ability to get revenue. That would appear, to me, to be a cost you should pass on to your customer, maybe they will move over to Ubuntu and make things a bit easier for you support and training wise. Most people choose CentOS because it was free and not RHEL thats the risk taken and sometimes risks come with new costs. If your module(in this example) makes them enough revenue, similar to anyone running SAP products, they should have the budget to pay for it. [1] https://docs.docker.com/desktop/install/linux-install/ https://docs.docker.com/desktop/install/linux-install/ [2] https://docs.docker.com/engine/install/ https://docs.docker.com/engine/install/ [3] https://www.theforeman.org/ https://www.theforeman.org/ [4] https://github.com/freebsd/poudriere https://github.com/freebsd/poudriere

CoolCold 3y ago

> Docker FreeBSD is lacking support of Docker - they prefer to think they can ingest system management knowledge into Frontend Developers and suggest to use Jails (with ZFS/Nullfs/VNET/other horrible words for Joe The Svelte Dev ) > upload images to VPS Some still have things running on premises > dependent on CentOS for, that FreeBSD or Debian can not provide Good luck running SAP products on this > FreeBSD you have regular release cycles, security advisories FreeBSD lacks the idea of LTS. At most you (to my knowledge) you may have updates to a) the very minimal set of things aka base system b) it ends in ~ 5 years, not even 7 or 10 c) someone will need to the the job to keep security support for ports tree for 5 years to ensure versions are kept the same. Or in other words - requires more human power on your side comparing to offloading that to the vendor. For some FreeBSD guys example may be needed. Imagine you installed latest Ubuntu LTS (22.04) which has Nginx (as part of the whole distribution provided, not "base"/"ports" separated) and it's version is 1.18 and for next 5+ years it will keep the same version. No surprises. You even run auto-upgrade everynight and reboot server ~ once a month for kernel updates. Then repeat the same on FreeBSD - the ports tree will get updated with newer Nginx ( I've checked https://ports.freebsd.org/cgi/ports.cgi?query=nginx&stype=all https://ports.freebsd.org/cgi/ports.cgi?query=nginx&stype=al... here, it's 1.24.0 and no older versions available) and when 1.25.1 will be become new mainline (probably in 1.26?) your configuration will stop working as they have deprecated "ssl on;" construct. Or, other sample - let's say I'm developing Nginx module and selling it in binary form. I realize that my auditory is Centos/Ubuntu users. I know in advance in that case, which compatibility I need to support in terms of ABI, features, support articles and training. It helps me [as vendor of 3rd party software] with planning and keeping lower costs.

ZeroSolstice 3y ago
From reading your response I think there are more questions than answers. I'll quickly go through the first ones and get to the main items. 1. Docker does run on Debian[1][2] which is why I referenced "Freebsd or Debian." For reference I've run and used jails for a number of years with development, staging, and production environments. I don't know why frontend developers would be doing system administration, setting security controls, or that using Docker would count as "system management knowledge." 2. I spoke to the on premise part with foreman[2] and pxe booting. The VPS uploading was in comparison to the default images already available for linux with cloud providers verse FreeBSD. Generally speaking, on your FreeBSD example and most of your points, it reads to me as regular system administration. You can manage your ports and packages just like having .rpm or .dep repos with poudriere[4]. You can lock specific versions of software from automatic updates or not. I'm not really sure why 5 years isn't enough time for a base OS to be supported since you can build your ports from source at anytime. Yes you are required to check the UPDATING file for any breaking changes however if nginx or similar application is critical to your operation and you are speaking to using Docker and other build tools wouldn't you be testing software upgrades anyway? As a vendor wouldn't you have nightly builds to download the latest nginx version and test it? It would seem a bit naive to just "trust" that an auto update would never cause issues because its in LTS. The bigger item to address, if you are purchasing and using SAP products as part of your business or are a vendor producing/selling a module I don't think the CentOS complaint holds water. The risk you have accepted is that you have no control over how the support, development or updates progress but you want no surprises because it affects your ability to get revenue. That would appear, to me, to be a cost you should pass on to your customer, maybe they will move over to Ubuntu and make things a bit easier for you support and training wise. Most people choose CentOS because it was free and not RHEL thats the risk taken and sometimes risks come with new costs. If your module(in this example) makes them enough revenue, similar to anyone running SAP products, they should have the budget to pay for it. [1] https://docs.docker.com/desktop/install/linux-install/ https://docs.docker.com/desktop/install/linux-install/ [2] https://docs.docker.com/engine/install/ https://docs.docker.com/engine/install/ [3] https://www.theforeman.org/ https://www.theforeman.org/ [4] https://github.com/freebsd/poudriere https://github.com/freebsd/poudriere