The question that ties the two threads together is, “on what distro should NS8 be based?” I’m not presuming to tell the core devs the answer to that question, but I hope I can at least bring some clarity to the points of concern.
First, Neth is a server distro. It needs to be stable, with minimal changes required for the base OS over as long a period as possible. That means it would be highly desirable for it to be based on a LTS server distro, which CentOS 8 no longer is–CentOS 8 proper’s EOL date has been cut by eight years; while CentOS “Stream” is the Beta for RHEL, and on a rolling release model, and therefore not stable. Even aside from any corporate shenanigans, this strikes me as unacceptable.
Neth (and its parent, and its parent) have been RH-based for over 20 years (I was using e-smith in late 1999, and that wasn’t even the first release). There’s a lot of inertia favoring staying that way. We’ve all had to adapt over that time, of course, but we know how the system works. We know how to build packages for it, we know how to set up automated build systems for it, we know what it provides and what it doesn’t provide. This, IMO, strongly favors staying with something EL-based if possible.
Of course, “EL-based” isn’t 100% a good thing–a good bit of the discussion in the other thread is about RH’s shift of direction with EL8, things that are no longer provided, etc., which would give some challenges in building NS8 on EL8. Switching to another EL-based distro does nothing to address those issues. It’s possible that rebasing might help here, but I’m not familiar enough with the landscape to know one way or the other.
The other concern with “EL-based” is that RH might act to further pull the rug out from under EL clones. I don’t think it’s possible to accurately assess the likelihood of this, but it certainly looks more plausible today than it did a week ago.
So with that as background, here’s what I’m seeing as pros and cons for a few distros that have been mentioned:
EL-based
Oracle Linux
Pros:
- It’s here now. It’s an existing, stable product that’s been around for a while.
- Appears to be a drop-in replacement for EL8/CentOS8
- Large installed userbase
- Committed LTS until 2029 for OL8
- Adequate financial backing (as far as we can tell)
- Vendor is sufficiently resourced that further RH shenanigans aren’t likely to be a major problem for the distro–in the worst case, they could diverge from RHEL at that point and we could just follow them.
Cons:
- Oracle. They’ve got some pretty shady history.
- ?
Oracle’s business model for OL seems (to me, at least) more compatible with our needs than RedHat’s did (after acquiring CentOS). There’s only the one software product, not the two in apparent competition like RHEL vs. CentOS. There’s no charge at all for the software, unlike with RHEL. They do sell support (~US$1200/year/server), but everyone gets the same code from the same repos. But their history may be too tough of a pill to swallow.
Rocky Linux
Pros:
- Will be completely community-based, no corporate control
- Project lead should know what he’s doing, given his history
Cons:
- It doesn’t exist yet.
- Since it was only stood up a few days ago, financial stability is uncertain
I’m hopeful this project will link up with Scientific, CloudLinux, etc.–there are a number of organizations who want/need the same basic thing of a community-based EL clone. There may in due course be a reason to separate these, but for the time being (again, IMO) it would make more sense to work together to develop a single, updated, stable EL clone.
CloudLinux’ clone (as yet unnamed, AFAIK)
Pros:
- It has a company behind it with a business reason to develop and maintain it.
Cons:
- Having a company behind it means there’s a profit motive, which may make some people uncomfortable.
- Like Rocky, it doesn’t actually exist yet.
Their announcement sounds good, and it certainly sounds like they’re intending for this to be a community distro, rather than just their corporate distro. Neither this nor Rocky has any track record as yet, but there’s obviously demand for a free EL clone, so assuming they’re managed decently (and assuming no further RH shenanigans), I’d expect they’ll do well. But, again IMO, they’d be more vulnerable to those RH shenanigans, were they to occur, than Oracle would be.
Non-EL-based
IMO, we should avoid this if possible–I just don’t see how any potential benefit from rebasing justifies the cost of retooling the entire development process, even assuming the e-smith template system could be made to work on the target OS (which I’d expect it could, as long as it uses text configuration files and can run Perl). None of these, AFAIK, match the LTS policy that CentOS has had of 10 years from release.
Debian
Pros:
- No corporate control–it’s a non-profit project
- Long-standing, stable server distro
Cons:
- I’m not aware of any unique to Debian, other than the general issue noted above (applicable to all the non-EL-based solutions) that it would require pretty much a ground-up rewrite of Neth
Ubuntu Server
Pros:
- Popular. Admittedly based only on my own observations, it’s probably the most popular Linux distro, and the most popular Linux server distro. Lots of software already available for this platform, and lots of third-party guides.
- Also a long-standing (though not quite so long as Debian), stable server distro.
Cons:
- It does have a company behind it, and therefore a profit motive. And some of Canonical’s decisions haven’t been very popular.
Both of these use apt/dpkg/.deb for packaging, of which I’m not a big fan as a user, though I’ve heard claims that they’re superior for technical reasons.
FreeBSD
Pros:
- Long-standing and stable to a greater degree than any of the others listed
- “Genetic UNIX”–it actually derives from the original Unix source tree, unlike Linux
- It doesn’t have Linus’ irrational hatred of ZFS, so ZFS is baked into the OS
- FreeBSD jails are pretty handy–I use them a lot under FreeNAS to run a variety of software I don’t want interfering with the base OS
Cons:
- It isn’t Linux, meaning a greater degree of difference than would be seen with Debian.
- It doesn’t use all of the GNU tools, meaning there are subtle differences–some of the flags to
sed behave differently, for example. This can lead to considerable frustration.
- Much less popular than Linux (in any form), meaning software availability isn’t as good. If source is available, most anything that will compile on Linux can compile on FreeBSD, and there’s also a Linux compatibility module that can help, but it remains an issue
- As an extension of the last point, no real Docker support
It’s also worth pointing out that there’s a fundamental difference between the BSD license and the GPL, in that the former doesn’t require distributors to release source like the GPL does. This is more a philosophical difference than a technical one, but should be considered.
I hope this is helpful, at least in bringing light to the issues to consider.
