4 ms·

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

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.

CoolCold 3y ago
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)

CoolCold 3y ago

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)