Here’s a poll to make it easier to weigh up everyone’s opinions - simply select ALL of the ones you are considering and then please add further thoughts in the comments.
Which platforms are you considering? (Select all that apply)
Probably in that order. I will be interested to see what happens with CentOS Stream but I am doubtful it will be close to what we have with CentOS now, but I am keeping an open mind nonetheless.
Rocky looks the most promising as a straight replacement, Debian is a good solid platform and I have considered it in the past due to the popularity of Ubuntu, and I have also considered FreeBSD too because from what I know of it, it performs extremely well.
Maybe this whole thing ends up being a blessing in disguise…
I’m waiting for Rocky Linux or Lenix (Igor Seletskiy’s project) as my preferred solution(s).
One client has green-lighted RHEL if need be, although I’d rather not reward IBM for pulling the rug out from under us.
Debian is always a possibility. I’ve never used it for a public Web server before, but I’ve run a lot of local fileservers on it; so at least I have some grasp of the syntax.
I’m willing to think about Oracle’s FOSS RH clone.
Hi there,
it’s a real pain, after much thoughts I was considering introducing more CentOS in my server farm during the course of CentOS 8, hopefully I did not began too early…
My favorite choice is Alpine Linux for its rock-solid stability, lightning speed, unbeatable slimness and absolutely great features like run-from-RAM and lbu.
Unfortunately Cloudmin/Virtualmin does not officially support it and did not yet invest the time to thoroughly check how well it runs on Alpine.
I am nonetheless basing more and more of our infrastructure on it.
I would love to see the devs investment redirected from CentOS to Alpine Linux, are there any other feeling the same here ?
Debian or Ubuntu is second when a major distro is needed for vendor support.
Now reality dictates that for some specific software we sometimes need a RHEL-compatible OS base so I guess I will give Rocky a spin.
Alpine Linux is likely the dominant distro in containers, because it is very, very small. But, it’s also awful from a usability perspective. It’s designed for containers and from-RAM environments that are never logged into…it just provides the barebones environment you need to run your web apps and services. And, it is intended (I think) to be updated by replacing the whole container…so as far as I can tell the package manager is brain-dead. It knows how to install, and they don’t spend a lot of effort on making upgrades work reliably the way, say, Debian or CentOS does.
They also don’t keep the same software versions throughout the life of a release. Alpine is the most anti-CentOS distribution imaginable. It doesn’t really fit into a conversation about “what do we replace CentOS with” if we’re trying to keep the characteristics we like about CentOS. It may be a distro folks like/want, but if you’re mad at CentOS for ending its longterm stability guarantee you are definitely not interested in Alpine to replace it, because it isn’t even trying to be that kind of distro. Not even in the same category.
If we find time/resources to dive deeper into container-oriented deployment, we’ll definitely look into Alpine, because it is extremely popular in that community (Docker, Kubernetes, etc.). For now, I want a full-featured distro that provides stability and reliability and a nice user experience on the command line. Alpine definitely aint that.
We used to support it, way back in the day. We had one (1) paying customer using FreeBSD. I just couldn’t justify the time it takes to support it, as it is so different from Linux. The decision to drop support came during a time when I was trying to add support for a new version and was running into so many stupid issues that I couldn’t google myself out of. I don’t remember any details at this point (it was nearly a decade ago now, probably), but I know it really burned me out on trying to support it. Especially since nobody using FreeBSD was willing to pay for it.
The only reason I did support it for as long as I did was because the FreeBSD users we did have were almost universally very smart and savvy and knew their way around the system. They were easy to support, even if the OS itself was not. And, they contributed patches and such at a rate far beyond that of Linux users (probably just indicative of the average skill level of FreeBSD users vs. Linux users…if you use FreeBSD you have to really care about FreeBSD, so you probably learn a lot about it).
But, I don’t think we can consider it a reasonable option. We don’t make every decision (or even most decisions) on maximizing revenue, but we have to make a little money or we can’t keep going…we’re pretty much right on the line of “we can’t keep going” at all times. I can’t make a decision that pushes us to the wrong side of that line. Supporting FreeBSD just won’t return enough revenue to support it.
Oh, and Webmin and Virtualmin are still available in ports, as far as I know, so you can run Virtualmin on FreeBSD without a huge amount of pain, though you have to configure it yourself (so, it’s painful, just not hugely painful). Pro will also work on FreeBSD, though we don’t have an installer for it. You’d need to install Webmin from ports and then setup fetching Virtualmin from the wbm package repo.
FreeBSD was actually the second Unix-like system I used. (SCO was the first.) I liked it. It was very powerful, very fast, and very efficient. But there was a lot of turmoil and uncertainty surrounding the licensing in the early 2000’s, with entire huge chunks of it being rewritten due to licensing ambiguities, the exact nature of which I’ve long forgotten.
It also wasn’t very hardware-friendly back then (and still lags behind Linux in that regard). It didn’t make a difference on servers, but it frustrated the attempts of geeks who just wanted to play with it.
I’ve been itching to build something lately. Maybe I’ll build a combined router / firewall / NAS / WebDAV / CardDAV / CalDAV server on OpenSUSE LAMP with Webmin and CSF to give that combination a semi real-world test.
If nothing else, it will help pass the CoronaBoredom; and it will give me an excuse to go to MicroCenter.
I think OpenSUSE is probably a good option, but I haven’t looked at it in a long time. We never had a lot of users back when we supported it and they kept changing their package management tools in incompatible ways (and package management really sucked until zypper came along), so it was just too painful to keep supporting it. I’d be hesitant to expend resources on it without seeing a lot more community interest, though. Or, maybe the SUSE folks will want to throw us a few bucks to add support!
Edit: Also, they still have a release-based version, in addition to the stream-based Tumbleweed, but I don’t know how long the lifecycle is for the releases.
I haven’t used anything SUSE in 15 or 20 years. But a home gateway / NAS / etc. would be a good place to test it because if it doesn’t work out, I can just yank it and put my current router back in place.
I’m not a huge fan of Oracle, but their FOSS distro would be another possibility. Supposedly it’s identical to their Enterprise version and 100 percent binary-compatible with RHEL. I just don’t really trust Oracle not to pull the rug out like IBM did.
On the other hand, a broader installed base wouldn’t exactly hurt them; so as with Igor’s Lenix project, it could just be a case of enlightened self-interest. But Igor came out and said as much. He needs an upstream RH clone, and building it himself is the surest way to have one. I’m still not sure what Oracle’s motive could be other than a bigger footprint.
I will be waiting Q2/2021 to decide where next. For now, all new systems will be CentOS 7 and few CentOS 6 I admin should be converted to CentOS 7 but they are internal storage/VM solutions so danger is very small.
Springdale, Rocky or CloudLinux Lenix are obvious choices.
Agree waiting re Q2 to decide next. Currently on CentOs 8, happy with setup and not downgrading/ moving until more details are published minus the hearsay.