What Linux distro is powering your production server?
Posted by sdns575@reddit | linuxadmin | View on Reddit | 263 comments
Hi,
as in the title, what Linux distro is powering your production server (I mean at work) and why? Do you use/need distro support?
Actually I'm using a mix of Debian 12 and AlmaLinux 9.5.
I use Debian12 on my backup server for ZFS, on monitoring server and internal NAS. I tried ZFS on Alma but the last major update broke ZFS dkms compilation.
I use AlmaLinux 9.5 for several web server faced on internet with SELinux mainly due to long LTS support and AppStream modules.
A testing server with Proxmox for VMs staging and testing.
Now planning a remote server for remote encrypted backup.
What about your choice?
Thank you in advance.
w0___0w@reddit
Arch minimal with incus + Alpine containers
ScheduleVirtual2281@reddit
Fedora 42
posixmeharder@reddit
Debian for servers and (altought non-Linux still UNIX & OSS) OpenBSD for firewalls/routers.
sdns575@reddit (OP)
Hi,
I also use OpenBSD as firewall. OpenBSD and pf are very good choice.
What make Debian your default?
posixmeharder@reddit
Oh, I totally missed your question. We went Linux for default because of compatibility with a larger base of software. And Debian in particular because of their values, and then the stability and ease of maintenance.
circularjourney@reddit
Why learn two systems in 2025? 15-20 years ago I could probably buy that argument, but now? I don't see it. Always open to change my mind though.
posixmeharder@reddit
Because the company was started, you guessed it, 20 years ago.When 100M was still considered standard for servers, and Soekris was still a thing. Those little machines were even our datacenter routers before Dell released the R2x0 serie. Two of them fitted in one U side by side with a custom bracket.
Aside from the historical (hysterical ?) reasons, there's still places where we find OpenBSD more stable or more compatible (IPsec tunnels for example). Since some of our clients (airlines and tour operators) value more stability rather than raw performance, we stuck with it and maintained our knowledge.
Hebrewhammer8d8@reddit
For OpenBSD, do you run on vendor like Dell, HP, Lenovo, ETC, or customize white white box?
On OpenBSD, run IPS and/or DPI?
posixmeharder@reddit
We went trough the whole Dell R2x0 serie since 2013. Initially with 1G NICs, then 10G and now 40G. In 2015 we considered Lanner appliances but compatibility was a concern and since our solution was working the risk was considered too high.
No IDS/IPS directly on routers/firewalls, except for customers with dedicated firewalls with Suricata, but a mix of netflow analysis with pmacct and custom scripts. We're considering integrating Akvorado, but more for capacity planning/fine grained peering analysis, but that would require to enable PF states on our routers AFAIK and that would greatly impact performance :/
420GB@reddit
Interesting choice with OpenBSD, you just rocking raw
pf
or a more customized image?posixmeharder@reddit
Vanilla packet filter for client dedicated firewalls, pf configured through Ansible for infrastructure firewalls, and pf (stateless) + openbgpd & openospfd for routeurs. It's worth mentioning that we used M:Tier LTS packages for a while to get longer upgrade periods, but with CARP, pfsync and a bit of planning it's been flawless since.
ImageJPEG@reddit
I used to rock a raw pf IPv6 firewall on OpenBSD.
And it was simple/easy to use and set up.
Wish Linux had it.
Previous-Weakness955@reddit
Is it really that onerous to type “distribution”?
Sad-Astronomer-696@reddit
Proxmox for VMs, Debian 12 (VM) on everthing that works and like 2 or 3 Windows servers (VM) for those 10 users that need them.
In total like 25 production servers + a few back up and testing ones
starscreamscream@reddit
Since containers and Docker have become a standard in app deployment, there is no matter what distro runs them.
UbieOne@reddit
RH
archiekane@reddit
Debian.
sdns575@reddit (OP)
Hi and thank you for your answer.
Can you elaborate why Debian is on your way?
cribbageSTARSHIP@reddit
I used open media vault for a while but they mount drives weird, amongst other things. So I switched to Debian. If you want a GUI for a Debian server you can install cockpit
brussels_foodie@reddit
Or webmin.
archiekane@reddit
Absolute stability, long term security updates, exceptionally easy config.
sdns575@reddit (OP)
About long term security updates, debian stable has 3 years of support from security team plus 2 years supported by LTS team.
How is the support from LTS team?
cribbageSTARSHIP@reddit
Yup Debian with cockpit on server, Arch at work station. Been that way a decade.
keesbeemsterkaas@reddit
I've been using debian since version 2.2. Update paths are predicatable, backports are stable, os upgrades are nearly painless (except for occasional config redo's).
"It just works".
archiekane@reddit
There was this one time when Apache moved from 2.2 to 2.4 and guess who didn't read the apt package news?
Yeah, that was fun while I worked out the differences in configuration files.
Other than that, past decade has been pretty flawless for upgrades.
keesbeemsterkaas@reddit
Yeah, that's the one I meant. I think the 2.0 to 2.2 was also a bit of a pain.
But on the level of nodejs or the javascript ecosystems this is all peanut-level breaking changes.
I've also tried ubuntu a few times - but didn't have the same level of updatability. But probably is also doable if you treat ubuntu the same way you treat debian (not too many weird external dependencies, read the docs).
human_with_humanity@reddit
How do u manage that? Using ansible or something?
the_real_swa@reddit
Used be all CentOS and RHEL but after the RH stint about the GPL, it is all Rocky for me now!
I am not the only one it seems:
https://rocky-stats.tiuxo.com/auto.html
eraser215@reddit
Checking EPEL stats is an extremely inaccurate way of tracking distribution adoption. What's the RH stint?
erikschorr@reddit
Ubuntu Server LTS, about 200 instances in ESX and bare metal.
i2295700@reddit
Almost 4k RHEL instances here...
Is the support needed? Most of the time not, but it is good to have that option and have a company as a counterpart where you can escalate etc.
No_Rhubarb_7222@reddit
Heyo, Red Hatter here. I often hear “pay for support” then people talk about support cases. Or, I’ll hear customers ask “how many support cases did we open” when talking renewal. Personally, I’d be happy if customers never had to open a case. Because that means all the other stuff we do, engineering & QE practices, infrastructure management, interoperability testing, hardware and software partnerships, are all working. So “support” can mean talking to our TSEs or us doing all the practices to make things “just work.”
FlatwormAltruistic@reddit
We ended the support contract and migrated to CentOS after they failed to help with one quite critical bug. It happened years ago when there was more exotic hardware. It wasn't even the problem that they were not able to assist, but it was more like they asked for information we had already given. It just left us feeling like they are illiterate there. Just some stupid runaround and wild goose chase. Oh and CentOS had this problem fixed. One of the engineers started testing on CentOS and everything worked fine there. Support seemed to be clueless even when they were shown the patch that was applied in CentOS and fixed that specific issue. It took ages to get that patch in them repos. We managed to migrate everything to CentOS before that happened.
So one bad experience can be enough to not trust their ability to help.
Zarndell@reddit
And then they shafted CentOS. Fuck Red Hat.
carlwgeorge@reddit
This doesn't really make sense to me.
If this was classic CentOS, it didn't really apply unique patches (other than de-branding) as its goal was "bug-for-bug" compatibility with RHEL. Fixing something that wasn't fixed in RHEL was a non-goal.
If this was modern CentOS, it's now the major version branch of RHEL, so if something is fixed there it means it's queued up for the next minor version of RHEL, so you just have to wait and update (or request the fix also be backported to the current minor version of RHEL).
You mentioned it happened years ago, but that could be either classic or modern CentOS depending on how many years it was. Can you share any more details on this? Or do you happen to remember the patch that was applied in CentOS to fix this issue?
No_Rhubarb_7222@reddit
That does sound odd considering that RHEL was the upstream for CentOS Linux and any changes in CentOS Linux, literally had to be passed through RHEL first. Unless you’re talking about CentOS Stream, which is upstream to RHEL and would get things before RHEL?
With any large support organization there are different skill levels. But also, there’s a reason we have the “Request Manager Escalation” button there. There’s also processes for you technical sales people (SAs) to engage with support and/or engineering. But, of course, you have to know that these additional options exist and how to engage them.
Znarl@reddit
Paying for support is like paying for insurance. You very much do your best never to make a support request and do everything you can yourself. But if you get stuck and need help having support means you'll never left alone to solve your problems.
sdns575@reddit (OP)
Hi and thank you for your answer.
4k is huge from my point of view!
Why RHEL and RHEL virtualization are the way to go for you?
i2295700@reddit
Currently most virtualization is VMWare. Satellite makes life easier, together with Puppet this is quite manageable.
We also run a little bit of AIX and i ordered the first production OpenBSD boxes as well last week.
human_with_humanity@reddit
Is puppet better for managing rhel than ansible? Just started learning ansible.
FlatwormAltruistic@reddit
You could use both. They both work a bit different.
The puppet wants to reach the desired state while Ansible is describing actions and the desired state may or may not be the same on consecutive runs.
If using both, then do not manage resources with puppet if you modify or set it up with Ansible. Ansible can be good for one time or more space recurring actions, i.e. initializing, certificate update, specific service update while puppet can still manage OS, ensure correct DNS, firewall, NTP is set up. Maybe also manage users and their keys on the machines. The stuff that should not change so fast and should be ensured in a specific state even if a malicious actor (or idiot engineer) happens to change them.
gordonmessmer@reddit
You'll get differing opinions on that question. I think one of the practical differences is whether or not you need orchestration.
A lot of the community will differentiate "configuration management" from "orchestration" based on ideas about whether a system is declarative or imperative. And even opinions about what those terms mean can vary. Many people will tell you that if a set of items must be applied in a specific order, then it is imperative and not declarative.
Ansible executes tasks in order. It can execute tasks across a fleet of systems in a specific order. (I think the idea that this makes Ansible imperative kind of silly.) That means that Ansible can be used for orchestration across a deployment of diverse systems supporting an application or service. At least in the past, Puppet did not support deployment-wide orchestration unless you licensed Puppet Enterprise. Their licensing model has changed significantly since the last time I used Puppet, so I don't know if that's still the case. But, because I typically support complex services, I also typically require a tool that support orchestration.
i2295700@reddit
Not really, we migrated from cfengine to puppet quite some time back and use it currently on Linux and AIX (no more Solaris here).
I don't think it is better for RHEL than ansible (or salt or whatever). Ansible is easier to begin with, but with growing systems and growing complexity every automation tool requires more rules to be still readable/usable.
Also, we do hourly runs of the puppet agent and think about going to 30 minutes, to get rid of errors done by humans etc. This is not something where i see absible fitting. For me ansible is for automation of deployments, puppet is doing configuration management as well (and enforces these settings).
It's nice to deploy things just by pushing some changes through the different environment and one hour later you can just see where this caused problems.
xouba@reddit
OpenBSD? What for, if you don't mind me asking?
i2295700@reddit
Currently to supplement our RHEL management servers, increase our chances in case of a successful hack/worm affecting Linux.
I also plan them to add to our external dns cluster and maybe some proxies we provide.
mad_redhatter@reddit
About 700 servers running a mix of different RHEL versions here. Red Hat provides us sales and technical reps that are really good at suggesting products for our use-cases.
Kahless_2K@reddit
Can I dm you with some questions about your experience running rhel at this scale?
i2295700@reddit
Sure, will answer if possible. Probably later out tomorrow since it's s nice Sunday. :)
xouba@reddit
Hey, would you mind another DM about that? I promise not to ask more than one or two ... Hundred questions.
i2295700@reddit
Sure, go ahead
ThemesOfMurderBears@reddit
Yep, support is a mitigation of risk. We’ve got ~700 RHEL servers.
dizzygherkin@reddit
Thought I was running a lot at 300ish
dogturd21@reddit
Fellow Red Hatter - I worked in the hosting division , and we had upwards of 45k servers .
crimson-gh0st@reddit
Same
_Old_Greg@reddit
Damn... How much are you paying for licenses?
weedos@reddit
Not much (for the company at least) most of the vm’s are probably virtual machines and as such covered by rhel virtual data center license.
buoncri@reddit
debian
Windows-Helper@reddit
Privately, Ubuntu server
At work mostly Windows, but some Ubuntu VMs and some Oracle Linux VMs of a software vendor (he does everything support-wise, so he could choose)
feedc0de_@reddit
Archlinux setup with ansible on around 50 servers total
Suitable-Mail-1989@reddit
why did you choose arch ?
feedc0de_@reddit
because we got tired of constantly outdated software, missing packages, we were coming from ubuntu/debian environments and there their package manager is called "sudo make install". 99% of packages we needed just werent packaged
SVP988@reddit
We were running on centos until rhel killed it. Moved to rocky road all the way...
johnklos@reddit
NetBSD 10.1.
TomB1952@reddit
I think "production server" is a bit strong for what I do but I have several servers running Ubuntu Server.
I'm an Arch guy for desktops, though.
NECooley@reddit
RHEL (and I think a few CentOS and CentOS stream) for servers because of enterprise support we never use, Ubuntu for workstations because that’s what the head of IT said we were allowed, I suspect it’s the only desktop distro he’s ever heard of. Wouldn’t even let us use a binary compatible distro like Kubuntu or Pop. Not like we have Ubuntu premium or a support contract or anything.
gordonmessmer@reddit
Kubuntu and Pop_OS! are pretty different. At least in that Pop_OS! is a fork of Ubuntu. It's fair to call that one "compatible." But Kubuntu is just a flavor of Ubuntu. It's not "compatible with" Ubuntu, it is Ubuntu.
vnpenguin@reddit
All my servers are running under RHEL/Alma/Rocky
pixelised@reddit
Alpine for me
Akorian_W@reddit
For Servers I have not seen any reason to migrate away from Debian. I run debian 12 atm and it works like a charm. Puppet runs regularly and with it I manage all configuration I need. I use unattended upgrades as well.
Currently I am running \~10 Instances
Substantial_Tough289@reddit
Ubuntu
Reasonable_Flower_72@reddit
Debian... ( with taste of Proxmox )
TheCosmicist@reddit
Homelab, but NixOS. Everything is in a config file, semi containers, bare metal works perfectly fine
herocoding@reddit
"Red Hat Enterprise Linux" RHEL.
Really great (commercial and individual) support.
the_smosher@reddit
RHEL, Oracle Linux, some Cent still, and a small handful of Ubuntu.
Eiodalin@reddit
Shocking probably in the minority here but we are mostly running ubuntu server 20.04/22.04/24.04 for VMs.
It runs pretty well, our of the box saving alot of work for us
For bare metal Debian/proxmox mix
Kurse71@reddit
RHEL, of course
cdbessig@reddit
Alma nowadays. Gave rocky a shot at first but when redhat came all scorched earth against them I figured Alma was the safer bet. We also run plesk on a few server so they now support alma and not rocky too.
gordonmessmer@reddit
I don't know man... I think the Rocky and CIQ groups spent years engaged in a scorched earth misinformation campaign against Red Hat. I can't think of literally anything I would describe in the other direction.
cdbessig@reddit
Fair point. Was easy to not be informed of that… until the point red hat came punching back. Then it was like, my company doesn’t need this drama.
gordonmessmer@reddit
CentOS Stream. Partly for technical reasons, but also for engineering culture reasons.
As far as technical reasons go, I think that Stream is a major workflow improvement over CentOS. As a Fedora package maintainer, I understand their development process well, and it makes more sense to me than many other systems.
But culture is also a really big factor in that decision. Red Hat's announcement of the changes in the CentOS workflow caused a lot of confusion, and still, today, a lot of people criticize CentOS Stream based on myths and misunderstandings. One of my highest priorities in social engagement is helping people understand engineering practices better, because a lot of those myths and misunderstandings hold us back as an industry. Helping people understand why various development practices work the way they do is important to developing a better engineering culture, and improving systems everywhere. So I advocate for CentOS Stream, because it actually implements a bunch of practices that i think are really important and which produce more reliable systems. And part of that is putting my money where my mouth is... running CentOS Stream so that everything I say is backed by first-hand experience.
Connect_Potential-25@reddit
Would you mind elaborating on the engineering culture reasons? Why should someone choose CentOS Stream for production workloads over alternatives like RHEL, Fedora, or OpenSUSE?
gordonmessmer@reddit
I don't necessarily recommend Stream over RHEL. It does have some nice characteristics for self-supported users, but RHEL also has some very distinct advantages.
What I recommend is Stream over the old CentOS Linux model. Both the old CentOS Linux and CentOS Stream deliver a major-version stable LTS system, but they do it in different ways. The old CentOS Linux model had two processes that both delayed bug fixes. First, some bug fixes were delayed by RHEL's minor-version release model. Second, bug fixes were delayed even further by the process of preparing a new CentOS Linux minor release.
The minor release process created delays of 4-6 weeks, twice per year, during which no updates shipped to CentOS Linux users. I think that was very bad for the project's security posture.
But the practice of delaying updates for minor releases, by itself, can be seen as a process flaw. In RHEL, most minor releases are supported for 4-5 years. In order for Red Hat to deliver a minor release that remains (mostly) feature stable for 4-5 years, they have to defer some types of updates to the next minor release. That's the compromise inherent in RHEL's release model. But CentOS Linux didn't have LTS minor releases, so delaying those updates was all cost and no benefit.
I have an illustrated guide that describes the mechanics of the branching release model, and a second part that describes they "why" behind it.
But since CentOS Linux wasn't meaningfully a branching model, dropping minor releases from the workflow makes the system more secure and more reliable. It also makes the workflow a whole lot less complex.
Understanding the purpose of branching releases and overlapping maintenance windows is really important to building reliable systems, because if you don't need the overlapping maintenance windows, then it becomes obvious that minor releases are a bug, not a feature in your use case.
sdns575@reddit (OP)
Hi,
Why dropping minor release from the workflow make the system more secure and more reliable?
Thank you in advance
gordonmessmer@reddit
Regarding security:
Take a look at https://en.wikipedia.org/wiki/CentOS#Latest_version_information
For any release of CentOS you'd like to consider, click on the "show" link to expand the table that describes the release dates for RHEL and the corresponding CentOS systems. You can ignore the ".0" releases... it doesn't really matter how much delayed they were. But for every minor release after that, look at the "Delays" column.
RHEL 8.1 was released on 2019-11-05. CentOS 8.1 was released on 2020-01-15, 71 days later. When Red Hat released RHEL 8.1, the CentOS group started working on their rebuild of that release, and until that release was ready, they couldn't push any more generally-available patches. If RHEL 8.1 included security patches, or if Red Hat published any new security patches during that 71 day period, CentOS Linux users didn't get them until 2020-01-15. The delay wasn't consistent from release to release, but basically all minor releases had some very significant delay, during which they were all unpatched.
Getting rid of the minor releases means that CentOS Stream users get security patches without the delay in preparing a minor release.
Regarding reliability:
Take a look at Red Hat's illustration of the RHEL lifecycle: https://access.redhat.com/support/policy/updates/errata#RHEL9_Planning_Guide
The most reliable system is the one that gets bug fixes earliest. The longer a bug affects systems, the less reliable they are.
In RHEL's model, some types of bug fixes don't ship to systems during the maintenance window for a minor release. They will only ship in a new minor release, so systems will only get them if they upgrade from the minor release they're on to the new minor release, and only when they upgrade to the new release. That means that some types of bug fixes don't ship to customers for up to 6 months. By definition, those systems are less reliable than they would be if the bug fix shipped as soon as it was ready.
In RHEL, as in all stable release models, there is a trade-off. Delaying updates to the next minor release makes systems less reliable, but it also reduces change rate in industries that prefer fewer changes to better reliability. It creates platforms for developers where they can continue to use a minor release for builds, which they need to do to properly support customers in the industries that prefer fewer changes to better reliability. It increases the value of validation processes like FIPS. It's bad for reliability, but you get some advantages in return.
CentOS Linux never got those advantages, because it didn't continue to maintain minor releases after a new release was available. It was a fundamentally different release model than RHEL. In RHEL most minor releases are maintained for 4 years. In CentOS Linux, most releases were supported for something like 4.5 months. Delaying updates in CentOS Linux to match RHEL meant that CentOS systems took all of the reliability disadvantages of RHEL's model, but didn't get any of the advantages that RHEL got in return.
Getting rid of minor releases means that bug fixes can ship to CentOS Stream systems as soon as they pass QA and other tests, which makes CentOS Stream systems more reliable.
Accomplished_Drag693@reddit
At work? RHEL. At home? Gentoo.
RespectNarrow450@reddit
You can se mostly Ubuntu LTS for web apps (great community support and stability), and RHEL for enterprise workloads that need official support. Also use Proxmox for VM management and a bit of Debian for lightweight internal services.
imzeigen@reddit
A lot of guys are going to hate me here. But been using oracle linux for a few years. Still have some redhats here and there and a bunch of old debians that I'm to lazy to upgrade. But mostly oracle linux. Free packages, some servers I have license to have ksplice those that I don't want to reboot that often. And just a few of oracle autonomous linux that started as a POC and ended up in production. Count me in as a oracle hater for all the bad they have done done open source projects but some times they do good enough things
BlueFlatchy@reddit
AlmaLinux, Rocky, RHEL, Ubuntu, SLES, a few other of brands.
dorkquemada@reddit
Debian, Almalinux and Talos Linux
cribbageSTARSHIP@reddit
I've been considering diving into kubernetes from docker, and saw Talos. Is it very hard to learn?
dorkquemada@reddit
Talos can also deploy a simple cluster inside docker for you to get your feet wet. I'll be honest while the OS is relatively simple and built for exactly 1 purpose (to run Kubernetes) the API first approach and the precision required to get things working can be frustrating if you're just starting out.
For a more traditional Kubernetes experience you could also look into k3s / rancher
cribbageSTARSHIP@reddit
The API approach doesn't bother me. I know enough about networking to run opnsense and I've been daily drinking Linux for over a decade.
Is Talos to kubernetes what NixOS is to Linux?
Im_a_goodun@reddit
redhat and oracle linux(unbreakable) pfsense for firewalls (not linux i know but close)
Suitable-Mail-1989@reddit
it’s freebsd
Im_a_goodun@reddit
yes i know, that is why i said I know it isn't linux.
jdaglees@reddit
Debian.
moonman407@reddit
Debian for servers with packages/services directly installed. Stability, familiarity, and ease of use.
PhotonOS for servers that are just going to be running container workloads. It's snappy and much lighter.
Darkk_Knight@reddit
I use Debian 12 and ProxMox. Both solid platforms.
IrrerPolterer@reddit
Production server?! It's all GKE...
rmfausi@reddit
Debian, of course.
raboebie_za@reddit
SLES. Pretty much that or RHEL for customers running SAP.
The OS support is required for SAP to provide any support. Does actually work just fine on any free distro so most non prod servers run openSuSE.
jaschweder@reddit
25k Amazon Linux 2
Suitable-Mail-1989@reddit
what will you do when they eol amzn2 in the end of June 2026 ?
jaschweder@reddit
I'm in the process of migrating those to AL2023
Severus157@reddit
Scientific Linux 6, CentOS 7, Rocky 9.3-Rocky 9.5
certciv@reddit
Scientific Linux is not one mentioned much in the thread. Can you say a little more about your use case and why it's preferred?
Severus157@reddit
It was a Free RHEL like Rocky or Alma on the base of RHEL 6. Scientific Linux though has been discontinued. We are still working to get anything upgraded. But it shows it's quite difficult to upgrade from SL6 to Rocky 9 and getting everything ported.
gordonmessmer@reddit
Scientific Linux isn't mentioned much, because it has been discontinued:
https://en.wikipedia.org/wiki/Scientific_Linux
Beautiful-Airport690@reddit
Suse
quiet0n3@reddit
Amazon Linux 2023, about 700 ish servers worth.
Suitable-Mail-1989@reddit
but only can use it in ec2 or virtual machines like kvm, virtualbox, vmware, … they don’t provide iso to install in physical servers, hope they will provide it in next Amazon Linux, btw, i love AL too
Suitable-Mail-1989@reddit
i chose ubuntu/alma for instances in oci and al2023 minimal with 2GB EBS for ec2, raspbian (based on debian) for raspberry pi and ubuntu for some physical instances which can’t be booted with debian or rocky/alma
brauliobo@reddit
Archlinux. Incredibly better than Amazon Linux, Ubuntu Server and Debian I used before
Suitable-Mail-1989@reddit
why it is better ?
NoDoze-@reddit
Debian is preferred for all of them.
sdns575@reddit (OP)
Hi,
Can you elaborate the choice of Debian?
If feel it more customizable versus RHEL and derivatives.
It is really stable but a 10 years of LTS would be great
NoDoze-@reddit
I'm not sure what answer you're looking for? LOL it always comes down to personal preference.
We always prefer debian because the minimal install, is well, minimal. You could install on 512MB. Other distro min installs are still full of bloat. Debian works every time, even after upgrades, Cistom packages, old packages, new packages... it just works.
zack822@reddit
Centos on the last 12 being supported for patching by third party and the rest Debian.
Finishing a migration on the centos boxes currently
_pixelcoder_@reddit
CentOS
_the_r@reddit
Debain11/12 mostly
Some legacy servers still running CentOS7 and one Windows server for a service that does not run in a real OS at all 😔
sdns575@reddit (OP)
Hi,
Why debian?
_the_r@reddit
We wanted a rock solid solution after RedHat announced the changes on CentOS. Switching to RH was not a solution, CentOS Stream as rolling release is nothing I wanted as server OS.
sdns575@reddit (OP)
Oh I understand, many migrated to the debian side after the centos "thing"
gordonmessmer@reddit
The CentOS "thing" is simply that Red Hat improved the process, but a vocal portion of the user community has never taken the time to understand the how and why of the release models. CentOS Stream is an accross-the-board improvement over the old process.
sdns575@reddit (OP)
Well, you are right and CentOS was never be 1:1 with RHEL for some points..but the event broke users trust this is the real problem.
This could be:
A misunderstanding of the community but I don't know if the community was wrong about that after reading the CentOS 8 EOL after one year, after reading from redhat site that CentOS stream should only be used for testing purpose...this simply was translated to CentOS kill because no one said nothing about the new process and Stream was not so good at the start. Many users deployed CentOS 8 on their server and then received a kick with 1 year of EOL...for many this was a pain.
Bad communication statement from HQ (if I don't remember wrong you said this on some post). Better to not release CentOS 8 or leave it until the entire EOL.
Is gone and that event happened, no matters who made the error but users trust is gone at the time. This not impies that CentOS stream is not a good product, that RHEL is not a good product and the same for AlmaLinux/RockyLinux.
I think that today users and admins are afraid that this could happen again...take AlmaLinux and RockyLinux that are young project that without cloudlinux/tuxcare/CIQ funding could go in EOL very fast. If this projects don't reach a good user base in N years (if only a small number of user use it why spend money to maintain it?) they could be marked as "failed".
This not happened on Debian side, in 30 years Debian never took a bad move loosing users trust like the CentOS "thing", also Ubuntu/Canonical with its own bad thing like amazon search, unity, snap, putting the distro under PRO subscription did not lose user trust like made RHEL.
Actually using AlmaLinux/RockyLinux is a long term bet. FOR example I should see how AlmaLinux 9 will handle 10 years of support being based on CentOS stream that has 5 years of EOL and no one talked about this (probably they will get patches from rocky/oracle sources). No matters if they have enterprise support from Tuxcare or CIQ.
One time, if I remember correctly, when user did ask what distro for a server there were a ton of users that recommended CentOS as server OS. Today I can't see the same for Alma or Rocky, instead I see RHEL suggested as in the past, some Alma/Rocky and a ton for Debian.
gordonmessmer@reddit
I am not aware of anything on Red Hat's site that says that Stream should only be used for testing purposes.
I am aware of a description of the model that says that Stream was not designed for "production" environments. But while that statement might scare some users, Red Hat had the same position regarding CentOS Linux: it was not designed for production use. They make the same recommendation with regard to RHEL itself, for the free self-supported licenses: not recommended for production use. That's not because any of those are bad per se, it's simply that Red Hat has a very specific definition of "production" that is deeply intertwined with their definition of "support." From Red Hat's point of view, a production environment is one that needs the type of support they offer.
If you thought that CentOS Linux was OK for production use despite Red Hat's point of view that is it not designed for production, but you think Stream is not OK for production use because of Red Hat's point of view that it is not designed for production, then it's possible that you're just using Red Hat's point of view as a rationalization for your biases.
Yeah, I agree on that point. A lot of community sentiment would very probably be more positive if the change had happened before CentOS Linux 8 was released.
Debian is a good project, with excellent governance. But if you think they haven't lost users, I think you aren't considering how and why Ubuntu became a significant project. There are a ton of users whose needs Debian was not meeting, due to slow development processes, infrequent releases, and no formal support. (I do not mean "helpdesk". I mean an organization that is empowered to ship bug fixes in Debian for bugs that affect Debian user environments. I mean an organization that can establish formal support arrangements with third party software vendors to resolve integration issues.)
Debian lost a ton of users to Ubuntu.
I don't know what user communities you participate in, but I have seen lots of evidence to the contrary. In fact, I would really strongly suggest that the reason that there are so many forks of Ubuntu is exactly because of those moves breaking user trust.
A lot of that is influence by where you are asking. You are asking for feedback on a social media platform, where misinformation and bias have a lot of influence.
Reddit is social media, not a support forum. Its design rewards social interactions, not technical ones. Experts tend to spend their time in places where their expertise is valued, and that is not on reddit. There are some experts here, but far fewer than on sites designed for support rather than socializing.
sdns575@reddit (OP)
Yes, I know that experts spend their time in places....I'm not an expert so I'm on reddit...I'm asking why, you, an expert are here on reddit...
gordonmessmer@reddit
I'm not saying there are no experts. I'm saying there are fewer than there would be on a site that was designed to promote expertise rather than social engagement. There are obviously some experts. There are Red Hat engineers participating in this thread. It doesn't get more expert than that!
I'm not saying that there's no expert feedback, either. I'm saying that it's harder to identify because people will click the down arrow when they read things they dislike. Especially when they read comments that don't reinforce their biases. It's very common to see expert feedback with low (even negative) scores.
Because I'm trying to engage in community building. I think that it's not enough to build good systems, the user community needs to understand what makes systems good. The people who are building good systems today will someday retire. As an industry, we need to recruit new engineers, and it's much harder to build an engineering community if potential engineers have spent their past stewing in myths.
carlwgeorge@reddit
CentOS Stream isn't a rolling release.
_the_r@reddit
They call it continuous delivery distribution. Still it's a kind of RR
gordonmessmer@reddit
Continuous Delivery is not "rolling," CD is "automation."
Automation is good, it makes things more reliable. Computers are far more reliable at repeating processes than humans are. That's why we use them.
carlwgeorge@reddit
It has major versions and EOL dates per version. That's the opposite of a rolling release. "Continuously delivered" is just a convoluted way to say it doesn't have minor versions.
gordonmessmer@reddit
Yeah... one of Red Hat's discussions of CentOS Stream used the term "rolling", and that caused a lot of confusion. CentOS Stream is not a rolling release.
What they meant was that the updates that RHEL gets in a new minor release appear in CentOS Stream when they finish QA and are ready. That's good! Fixing bugs makes systems more reliable!
Delaying those bug fixes in RHEL is bad for reliability, but it's necessary to support RHEL's release model. By delaying some types of updates until the next minor release, RHEL provides nearly feature-stable LTS branches, which are wanted in fields like medicine and automotive. It's a compromise: some things are worse so that other things can be better. But CentOS Linux never had LTS minor releases, so the delays made systems worse without making anything better for CentOS Linux users.
uosiek@reddit
50/50 Ubuntu Server and Debian
SaintEyegor@reddit
RHEL 8.10
I hate rewarding them for their shitty behavior but management decided to go RHEL.
gordonmessmer@reddit
Red Hat has made the CentOS project more open to the community, and made the distribution more secure. It's hard to paint that as "screwing the community."
SaintEyegor@reddit
Turning it from a production stable OS into something that’s not “bug compatible” with RHEL means that’s it’s not suitable for use in production environments.
gordonmessmer@reddit
There has never been a project that was bug-for-bug compatible with RHEL. Red Hat does not publish the build root info or other information that would be required for a reproducible build of RHEL, and they have historically also not published packages from most of their release lifecycles. The QA engineers from the old CentOS project tried to tell users, "We came up with the phrase “bug-for-bug” compatible during EL5 as a GOAL to aim for. CentOS was NEVER bug-for-bug compatible," but users tended to ignore that message because it didn't align with their desire to run an Enterprise OS.
RHEL isn't "bug for bug" compatible with itself. RHEL engineers release updates that fix bugs, breaking bug-for-bug compatibility with the previous state of RHEL.
"Bug for bug" is a hobgoblin. It's a non-goal. A reliable system fixes bugs that affect the workloads that require it. It's good that CentOS Stream and AlmaLinux aren't trying to be "bug for bug" compatible with RHEL and fixing bugs that affect its users. That's what a Free Software project is supposed to do.
CentOS Stream is no less a stable LTS than CentOS Linux was.
mr_d_jaeger@reddit
Debian and Alpine Linux
AsleepDetail@reddit
RHEL in much of the government space, back when I had a job in the government space until the beginning of the year.
This is due to federal requirements, FedRamp, FIPS and all that jazz. But the tools for STIG’ing and the easy nature of building images with composer-cli make it easy to rollout and manage.
serenetomato@reddit
I'm using Ubuntu server 24.04 for my prod server privately and at work. Archcraft for my personal laptop.
Rudi9719@reddit
Work? RHEL through and through..
Personally I use Proxmox, Debian, Nix and some RHEL for my lab
Maya-X@reddit
Diet Pi OS installed on Debian 12 is out of this world with all lighter and features is unbelievable
maggo787878@reddit
99% debian the Rest is Alma or Rocky
ub3rdud3@reddit
~6000 RHEL servers
advanttage@reddit
My webservers are all Debian.
My homelab is a mix of Raspberry Pi OS and Armbian. My homelab is also entirely single board computer and arm based.
jasonmacer@reddit
Oracle Linux 8.x - 9.x and CentOS 7.9-8.2
Muted_Elephant3997@reddit
Ubuntu server for like 10 years, but will change to Debian when time permits.
03263@reddit
Ubuntu 20 I think. Everything then runs in docker with Ubuntu again!
lungbong@reddit
Debian, we've had it since at least Sarge and only decommissioned our last Etch server last year.
Traditional-Scar-667@reddit
Ubuntu Server LTS
sdns575@reddit (OP)
Hi,
When CentOS 8 was announced to 1 year EOL my first tought was Ubuntu and I started using it but than I found snap and I turned around and gone with debian and successively with AlmaLinux.
What is the key point of using Ubuntu LTS in your usage case?
Thank you in advance
_BearsEatBeets__@reddit
Not OP, but we chose Ubuntu because of its popularity. We figured there’s plenty of resources online to fix any potential issues we might ever get. Very rarely is the OS the problem.
We don’t use Snap at all for it and install packages with apt. Snap is ass, and thankfully not mandatory.
HoustonBOFH@reddit
This. Ubuntu is one of only two distributions where you can install it totally free and add support later if you want. (SUSE is the other) This is good for my clients as it gives them peace of mind. And having only one flavor makes me more efficient.
Krychle@reddit
Big same
Anxious-Science-9184@reddit
We run RHEL/Rocky in production. RHEL for critical systems (DB2, IBM MQ, Websphere, etc) that require a support contract. Rocky for stuff like Postfix/Squid/Dns/etc where we do not necessarily need to pay for an escalation path.
blissed_off@reddit
Debian or Ubuntu. I haven’t decided which one I hate more. Probably Ubuntu.
GuzziGuy@reddit
I'm small scale, half a dozen servers for different things... all on Ubuntu LTS. I like the very well-defined release and support schedule; I know I can get 2 or 4 years out of one install.
And I use it as my desktop so it's easy that I use largely the same packages etc.
bobj33@reddit
About 100,000 Red Hat Enterprise machines in our compute cluster.
zig-zac@reddit
Fedora server
Full-Entertainer-606@reddit
Rocky 8 & 9,Proxmox Debian, VSphere, and a few Ubuntu.
I use Rocky 9 when I can for stability and my personal familiarity with the RHEL environment. Sometimes, certain things require Rocky 8 or a version of Ubuntu, so I use those when I have to.
Our Linux footprint is very small, when compared to others at around under 50 machines. But when I first started at this job, we had 1 RHEL FTP server, vSphere, and multiple WAMP or WA(MSSQL)P stack machines. It’s an uphill battle against Windows, but I feel good about it.
Melladay@reddit
We use a mix between RHEL, Ubuntu LTS and Alma
serverhorror@reddit
Redhat, Rocky, Amazon Linux, Azure (whatever they provide), although, with containers it's even less clear.
If you run an OpenShift cluster on premise and most people use containers based on ... whatever. What's really the distribution powering your business systems?
ChanceTechnical3449@reddit
well it's up to the administrator to keep the containers safe; to set up guidelines and rules not to let it become a jungle. You do not want a deveoper to run _whatever_ they like. That can quickly become a highway to hell.
serverhorror@reddit
If only it was that easy.
We all agree on that theory, and then some projects just come along and tell you that it's "this" or nothing.
ChanceTechnical3449@reddit
that's sad, really sad..
serverhorror@reddit
I have yet to see a company that doesn't do it that way.
There might be exceptions, generally though ... that's how it works.
iteranq@reddit
Tutti Frutti
catwiesel@reddit
debian
BlackJackHack22@reddit
Ubuntu.
I grew up with Ubuntu and I just don’t have the time to learn my way around another distro. I know the commands, I know how to debug, and I can get work done. As much as I feel like Ubuntu is losing its touch, I simply wish I had the time to learn my way around another distro
FalconDriver85@reddit
SUSE for SAP, RHEL for other things, but most of our machines are Windows Servers by the way. Also in AKS the managed hosts and containers use Azure Linux IIRC (but I’m not the one working on/maintaining K8s, so…)
NeuralNexus@reddit
Rocky, Amazon Linux, Oracle Linux, Ubuntu, Debian.
damjank12@reddit
Debian 12, Oracle Linux 8/9 with UEK
dogturd21@reddit
Oracle Linux is surprisingly reliable , but since it’s derived directly from RH it better be.
damjank12@reddit
Hence why i switched all “other” flavors to ol8 and 9… mainly all are already at ol9 with uek7 - it is a tank-rocket, could not be more happy and surprised how far it came 👌⭐️
suburbanplankton@reddit
I'm in healthcare; everything (Linux) is RHEL.
sdns575@reddit (OP)
Hi and thank you for your answer.
I mean you use RHEL in healtcare for stability and support.
ravigehlot@reddit
RHEL based Rocky Linux
DeesoSaeed@reddit
A mix. Suse SLES, Oracle Linux, Rocky, Ubuntu LTS...
theodiousolivetree@reddit
Almalinux and Redhat
TxTechnician@reddit
Suse leap
dgcxyz@reddit
Freebsd
Ancient_Swim_3600@reddit
Ubuntu 16 LTS.
btRiLLa@reddit
RHEL
readyflix@reddit
openSUSE Leap
drosmi@reddit
We’re on mostly rocky 8. Our footprint is shrinking because lots of stuff is ec2 instances running al2 or al2023 (gotta watch that deadline!) or has migrated to kubernetes.
URPissingMeOff@reddit
Dozens of Rocky 9x on bare metal. A few leftover Rocky 8x on VPS used for secondary DNS
382_27600@reddit
Debian for most RHEL for a couple.
dougs1965@reddit
Sixteen servers running a variety of tasks, all on Debian Stable. No need for vendor support, everything just works and if it doesn't I can fix it.
One Windows server running a single windows-only sector-specific back-end application which I wish I could do in some other way. When it fails we rebuild the machine, restore data from backup, and carry on where we left off.
Desktops are a mix.
Odd_Cauliflower_8004@reddit
I usually go with a mix of Ubuntu lts and rocky/alkaline, it depends . Pihole goes on rhel like because I know I can reliably launch yum update and forget about it. In case I need as close to bleeding edge performance a s possibile, I use Ubuntu lts.
l3landgaunt@reddit
I run Ubuntu server and install plasma for the desktop environment for my main server but for my laptop, I’m running Manjaro since arch works really well and it’s easy to install
shikkonin@reddit
Why does your server have a desktop environment!?
l3landgaunt@reddit
I use it for other things too
aaronryder773@reddit
Debian.
I have been experimenting a lot with rhel based distro and I think I am starting to prefer them over Debian. Alma seems to be great so far
madras_hot@reddit
Out of curiosity, what do the rhel distros offer you that appeals?
aaronryder773@reddit
The fact that I can use Ansible. I know I can use Ansible with Debian based distro too but Debian based distro is quite hands-on in terms of installation. Want to install mysql? It prompts me for a password during installation. Not saying it's a bad thing I like this feature and often use it. I have to run few extra steps to disable it though. On rhel based distro, I can just install mysql and it generates a temp password which can be found in logs. This is just one example btw, there are other packages as well which require me to be hands on when on Debian and I have to run few additional steps to disable it
Also, freeipa server is such a great software, it's not perfect but wish it came with Debian as well.
And lastly, selinux is so much better than apparmor imho.
madras_hot@reddit
Interesting - thanks for the reply & info 👍
hrudyusa@reddit
Running Rocky 9.5 b/c it is the closest to the old Centos.
boxheadmoose@reddit
RHEL with some Ubuntu/Debian (customer specific)
Shoddy_Hurry_7945@reddit
Ubuntu Server
MangoEven8066@reddit
Redhat
noc-engineer@reddit
Red Hat. Because the regulatory body pretty much require multiple layer support contracts etc and thats what our subcontractors have chosen anyways. Some legacy CentOS (even some 5.x) and some Rocky Linux, but I suspect everything VMware is going to be RHEL sometime in the future. I have given up a long time ago to get Proxmox inside the enterprise...
---ruthless---@reddit
l
PurpleBear89@reddit
I used to run a lot of Amazon Linux but since they changed how they handle updates, I’m deploying new machines on Debian.
gordonmessmer@reddit
What do you dislike about the new model?
It's a lot like Debian, in that it's a stable LTS. But it has additional features that allow users to build reproducible images so that their processes are more repeatable. It's hard to see that as a flaw.
PurpleBear89@reddit
It uses dnf now and requires you to jump release trains to get updates. It wouldn’t be that crazy if a new train wasn’t released every week but it lacks the simplicity of Debian where you either have updates or not.
But I’m a Debian guy at heart so that’s probably why I prefer the Debian way..
gordonmessmer@reddit
I would not expect Amazon Linux to rebase to new upstream release series any more often than Debian does.
Do you have any examples of that happening?
PurpleBear89@reddit
Every time I login into one of these boxes, the greeting tells me to switch trains to get updates!
gordonmessmer@reddit
It sounds like some things about both Debian and AL2023 might be unclear.
Amazon Linux 2023 is a stable LTS, similar to other stable LTS systems like Debian Stable in many ways.
A major version of Amazon Linux is maintained for a total of 5 years (though the timeline for 2023 is 6 years). A major version of Debian is maintained for a total of 5 years.
A major version Amazon Linux has a "standard support" phase of 4 years, followed by a maintenance support phase of 2 years. A major version of Debian has a standard support phase of 3 years, followed by a maintenance support phase of 2 years.
During the standard support phase of Amazon Linux, there will be a new minor version (a new release train) every 3 months. During the standard support phase of Debian, there will be a new minor version every 2 months.
A new minor release in both Amazon Linux and Debian can potentially include new features, provided that they are backward-compatible with the earlier releases in the same major.
In Amazon Linux, the AMI and repository associated with a minor release remain available, so that you can continue to build new instances and images with the exact feature set that you have previously tested until you intentionally move to a new minor release. Debian does not provide that functionality. It just rolls to the new minor release for all users on Debian's schedule.
Amazon Linux is actually a lot more feature-stable and reproducible than Debian is.
https://docs.aws.amazon.com/linux/al2023/ug/release-cadence.html
PurpleBear89@reddit
I didn’t mean to start anything but, oh well, here we are.
Everything you said is about right and I’m not saying AL23 is better or worse. Most things in our world isn’t anyways.
All I’m saying is I prefer the Debian way coupled with unattended upgrades enabled. I only need to plan moving to the next big release and can apply updates as they come in until then.
I’m sure plenty of people prefer the AL2023 way. To each their own I guess!
gordonmessmer@reddit
I don't mean to appear combative... The language that Amazon uses is, I think, legitimately ambiguous, and I have known a lot of people to come to the wrong conclusion about how it works.
If I were to describe the difference between Debian and AL2023 in the simplest terms, it would probably be that moving to a new release train on AL2023 is intentional, while moving to a new release train on Debian is mandatory and automatic.
As an SRE, I do think that AL2023's model has important advantages over Debian, and especially over unattended upgrades. To me, unattended upgrades means no testing process, no canary, and no rollout coordination.
I personally use CentOS Stream, which is similar to Debian. But I build testing, canary, and coordination into my rollout process, locally. Updates aren't unattended.
Yncensus@reddit
Debian for everything, if possible.
Oracle Linux for Oracle DBs
SuSE SLES for SAP
Ubuntu if some useless vendor is requiring it (looking at you, M$)
RedHat if some other vendors do not like Oracle Linux.
sep76@reddit
2-300 debian servers. 4-5 ubuntu probably due to some app support requirementd
craigleary@reddit
It’s a split depending on the product line but I don’t have many. Ubuntu lts for storage and kvm setups because zfs is natively supported. Almalinux for anything that gets a control panel.
syncdog@reddit
CentOS 9, at least until Linode adds CentOS 10.
toolz0@reddit
Almalinux
tofqu@reddit
We have Oracle Linux 9. 200 servers.
IridescentKoala@reddit
Talos and AMazon Linux for k8s nodes.
Underknowledge@reddit
Any NixOS bros around?
IridescentKoala@reddit
Don't worry, if there were you'd hear all about it.
Alarming-Estimate-19@reddit
Debian or Rocky Linux if long-term support is needed
landsverka@reddit
Couple hundred Rocky 9 VMs
forwardslashroot@reddit
Rocky Linux desktop for both workstations and servers.
-eschguy-@reddit
Debian
hys275@reddit
Rocky !
cmdr_scotty@reddit
Currently Ubuntu on 2 of my vms, the other three and host are now Debian.
Slowly migrating everything over from Ubuntu which has made a world of difference. (2 of them can now run on 512mb of ram)
Anticept@reddit
Debian in the servers that are serving webpages or proxmox hypervisor. It doesn't need to change much.
Ubuntu LTS with pro attached if i need things that are newer but still need the stability.
AlmaLinux for FreeIPA because I don't need packages to move much at all to serve up identity management, and it's far better supported in the RHEL sphere.
FreeBSD underpins opnsense.
punkwalrus@reddit
Over the years, various jobs:
Ugh, one job was FreeBSD, because their former lead admin was a huge hobbyist freak. Then got fired because he lost his shit at the owner too many times in an aspie meltdown. Started his own hosting company, and then vanished to obscurity when that failed. The first three years I worked there, my main job was "get us off of FreeBSD and onto something industry standards!" which was CentOS/RedHat at the time.
That job was hard, because I only knew FreeBSD from a hobbyist level (in fact, I was the first and only job applicant who had ANY experience), and the admin pro tempore was a guy who didn't know FreeBSD and was so angry in the FreeBSD forums, he'd been banned under several usernames. It was my first hard lesson in "what happens when a hobbyist maverick runs your IT stack," and while I learned many great things, I'll never do that again at that scale.
Deepesh_Ramnani@reddit
Oracle Linux!
Kahless_2K@reddit
We have a mix, but the most numerous and important workloads are on RHEL or Oracle Linux.
RHEL is preferred, but we will use Oracle Linux for Oracle DB workloads for the benefits of dealing with a single vendor.
ctofone@reddit
Ubuntu LTS Bsd for FW proxmox and esx
Inevitable_Score1164@reddit
RHEL, Ubuntu, SUSE Enterprise
Sylogz@reddit
Oracle Linux 9, Oracle as a company may suck but we like the Linux distro. Been running it for 10+ years and even the support has been great when needed. Nice to be able to use same distro for dev, qa, staging and prod.
GoaGonGon@reddit
RHEL
andrewthetechie@reddit
At home: Talos and Debian.
At work: Ubuntu and Amazon Linux
unkilbeeg@reddit
I use Debian. The only exception is if I need Oracle DB, in which case I need something Red Hatish. In my case, the last time that happened, I used Scientific Linux 6.0, which was a clone of Red Hat EL6.
When the instructor who liked Oracle retired, the new instructor preferred MariaDB, so we didn't need Red Hat any more.
themisfit610@reddit
Amazon Linux 2023 at the AMI layer and a mixture of Ubuntu 24 and Alpine at the container level. A few exceptions for legacy CentOS things that run in isolation.
linuxgfx@reddit
Oracle 8/9 with UEK, Alma 9, Ubuntu 12-14-16-18-20-22-24.04 that we plan on migrating to Alma for longer LTS and a few Debian 11 and 12.
Crazy_Emphasis_1737@reddit
Fedora 42 with KDX
ghost103429@reddit
ucore
HLingonberry@reddit
Surprised not to see more Amazon Linux here. We have in the range of 20k instances.
Sekhen@reddit
They are my docker hosts. But the containers them self run our custom Debian setup.
Sekhen@reddit
Debian. Always Debian.
Capable_Agent9464@reddit
Debian and Ubuntu server.
TuxTool@reddit
Datacenter: Ubuntu/Redhat for VMs, certain standalone servers, Proxmox for our KVM hosts, and Linux Mint for my work desktop
Home: Linux Mint on laptop and one of my Desktops (other is Windows).
deltatux@reddit
Work decided to go Ubuntu Linux, would have preferred Debian but Ubuntu is familiar enough for me. I run Debian personally in my lab.
ImageJPEG@reddit
Professionally, we use Proxmox which hosts Windows Servers. At home, I rent a VPS that I use FreeBSD with.
GloriousLion18@reddit
Fedora
michaelpaoli@reddit
Currently Debian, mostly Debian stable. But the answer will vary depending upon $work, and has included, e.g. Debian, Ubuntu, Red Hat, CentOS, SUSE, AWS Linux AMI, and probably some others that aren't popping to mind at the moment.
KarmicDeficit@reddit
Currently RHEL, CentOS, Ubuntu, Debian, and Rocky. Trying to standardize on RHEL for mission-critical and Rocky for everything else.
deathsfaction@reddit
Rocky8 and Rocky9.
Still some legacy CentOS to be updated.
Jabba25@reddit
Rocky here mostly
exmagus@reddit
BarbieOS.
Alma Linux
itastesok@reddit
Some on Debian, some on Ubuntu Server
IpswichMesh@reddit
Flatcar
RageBull@reddit
Nice try North Korea!
trisanachandler@reddit
Ubuntu
m1nhC@reddit
All RHEL. I build DISA STIG compliant RHEL images with Packer and then upload the AMIs in AWS. Then deploy them to whichever customer production environment we need to build.
TellMeYourOwnPolitik@reddit
Our servers are all on Suselinux.
NHzSupremeLord@reddit
Alma9, debian 12, CentOS 7 (the legacy ones)
dahimi@reddit
ubuntu
AtlAWSConsultant@reddit
RHEL.
. . . And Windows. 🤮
peace991@reddit
Debian and Ubuntu shop.