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/ [2] https://docs.docker.com/engine/install/ [3] https://www.theforeman.org/ [4] https://github.com/freebsd/poudriere

> Docker would count as "system management knowledge."

Jails count as it. Not even going deeper into interesting questions - forcing team to ditch Docker and start using Jails.

> You can manage your ports and packages just like having .rpm or .dep repos with poudriere[4]

Interesting, I'm giving you examples of working _less_ and you saying - but you can work more!

And no, I/one cannot - who will backport patches for security issues? who even will be reliably track what kind of patches needed, what applied, how to test it and so on. Sounds like a extra spending on hiring some nerds focused on security stuff in this, instead of delegating to vendors.

> Yes you are required to check the UPDATING file for any breaking changes

Thanks, no, again. Sounds like LET'S WORK MORE again. Reading on changes will happen on next LTS version deployment and testing, not as day-to-day activity. Which happens with 2 year cadence and can be planned/prepared for migration.

1. Yeah the jails item was addressed above with Debian being able to run docker so don't go with FreeBSD for that. Again, you don't have to run the same OS for everything. Its not like homogenous environments haven't existed before, organizations run Windows, BSD and Linux together.

2. Plenty of organization manage internal repositories for packages they regularly use or for systems that need pinned versions of software. I haven't worked at any organization that hasn't had this. This was the entire benefit of having integrated system commands like yum, apt, fetch, pkg, etc and using .rpm,.dep, etc and standard package managers / formats. Not all companies release code to upstream repositories how do you think they systematically deploy their code from build tools like bamboo or jenkins?

3. Not even sure what you are talking about here. You don't have to run package updates everyday, you don't have to upgrade your FreeBSD OS everyday, now a 2 year release cycle is ok? but a (5) year supported FreeBSD release cycle is too short? Even if you outsource this to vendors you don't read the release notes, you just upgrade, you don't have to make any backups of your data or software?

At this point I'm not even sure what you do. You write software, it compiles, and it just magically shows up on the Internet?

My point still stands though, there isn't any specific item tying most of the people in this thread to CentOS that they couldn't pay RH or move to Debian/Ubuntu/FreeBSD. CentOS was never free from any of the items you noted above.

Let's address the last one, to make things bit more transparent

> My point still stands though, there isn't any specific item tying most of the people in this thread to CentOS that they couldn't pay RH or move to Debian/Ubuntu/FreeBSD. CentOS was never free from any of the items you noted above.

Hard to say on most people - I have gut feeling most of the population of HN is closer to development than operations and care on Docker/containers as platform, not the OS itself.

Agree on RH, Ubuntu. Don't agree on FreeBSD (due to reasons in previous replies) and largely don't agree on Debian. Debian has a short lifecycle and till recently required extra efforts on firmware blobs. I've superseded Debian to Ubuntu releases after Debian 8 or 9 for myself.

Point is on FreeBSD - it's total outnumbered hero in this list.

> now a 2 year release cycle is ok? but a (5) year supported FreeBSD release cycle is too short?

Right. 2 year (for Ubuntu, not for RHEL family) cadence doesn't automatically deprecate older releases - those still supported. So if you are running on 18.04 you can migrate to 22.04, no need to spend time migrating to 20.04.

For RHEL based, cadence is lower/more time between releases - RHEL 7 on 2014 and RHEL 8 on 2019, RHEL 9 on 2022. Real case, I observe right now, is future migration of Centos 7 systems to something RHEL9 based - Alma or Rocky - skipping RHEL8 base altogether.

> Not all companies release code to upstream repositories how do you think they systematically deploy their code from build tools like bamboo or jenkins?

That's more or less valid point for software out of your distribution's collection - like say Nginx modules which are not prepackaged or much more rarely - it's own software. Much more often home-made software is running in some sort of containers and packaged in Docker images, skipping "distribution" packaging phase.

> 3. Not even sure what you are talking about here. You don't have to run package updates everyday, you don't have to upgrade your FreeBSD OS everyday

I tend to run unattended-upgrades on Ubuntu everyday (by cron) and monitoring checking for security updates pending for more than 2 days, including "need-to-reboot" sign. I'd expect something similar guys in FreeBSD land do (probably `pkg audit -q` or like that)