Those of you on the Linux platform may be wondering about CentOS 8 Stream so I thought it would be useful to start a thread on the subject...

Let's start with a review of the EOL (End of Life cycle) dates...

• CentOS 5 - March 31, 2017 (*** EXPIRED ***)
• CentOS 6 - November 30, 2020 (*** EXPIRED ***)
• CentOS 7 - June 30, 2024
• CentOS 8 - December 31, 2021

The first thing to note there is that if you're on CentOS (or RHEL) 5 or 6, you're already past the end of life cycle and should be making plans to upgrade, sooner rather than later.

The second thing to note is that CentOS 8 actually expires (at the end of this year) before CentOS 7. How can that be?

The reason is that Red Hat has decided to switch to a new CentOS model, rechristened "CentOS Stream". You can read about it here.

While not everyone is happy about it, and we haven't received a lot of feedback from A-Shell developers about their intentions, I don't see much alternative for us other than to play along. So the plan is to retire the -el8 line sometime in the next year (or s0) and replace it with a -cs8 (for CentOS Stream 8) line, with a -cs9 line to be added later this year.

In fact, I've just now created a /dist/65dev/bin-linux-cs8 (beta)/ distribution directory containing the 6.5.1697.1 beta release. (The 'beta' designation will be dropped after a bit more field experience with it.)

So far, it appears to be nearly identical to the CentOS 8 version, and the -cs8 and -el8 executables work in either environment, so I don't expect much of an issue for those switching from the old CentOS 8 to CentOS 8 Stream. (Note that the same cannot be said of the jump from -el7 to -el8 or -cs8! Those executables are not cross-compatible, and the migration in general from CentOS 7 to 8 may involve a number of minor complications.) But if you're on Linux, unless you want to make the case for switching to the Debian/Ubuntu distribution, you're going to have to deal with these upgrade issues eventually so you might as well get to it. In particular, if you're still on version 5 or 6, you might as well just bypass 7 now and go directly to 8. (Aside from the obvious reasons, the upgrade from 5 to 7 is also not painless, and may not be any easier than going directly from 5 to 8.)

I've been watching Rocky Linux. As I understand, this is most of the original CentOS development team. Rocky Linux is supposed to be the same as the CentOS project originally was, i.e. (100% bug-for-bug compatible downstream from RHEL)

Red Hat claims CentOS Stream should be capable of running most workloads, but it's a development environment. It's meant to funnel it's code to RHEL, so it's now the upstream from RHEL. That's a huge departure from what we're used to. While Centos 5/6 shouldn't be in the field anymore from a security standpoint, the fact that they are speaks to the stability of RHEL. Personally, I'm not sure I can trust that Stream is going to be stable enough to use for production systems.

If stability was the only defining factor, we would still be on AMOS!

Thanks for the headsup Jack.

Unfortunately, at the moment it's rather difficult to evaluate the viability of Rocky Linux; it doesn't even exist yet. The goal seems in line with what production users want, but I'm not sure it matters that much to A-Shell internal development. While ideally we would want to compile/link A-Shell itself under the same platform/version that the users are running, the vast majority of incremental differences between the RHEL and CentOS Stream (and possibly Rocky Linux) equivalent are probably not going to affect the physical executable. So it may not matter that much from my perspective. It's more of a problem for dealers delivering complete production solutions.

It's interesting to note that the Stream model is analogous to our Stable vs Development model. (Although Stream is probably more stable than our Development version, since I don't think they intend to add features to the upstream release.) It seems that invariably, whatever the model, if there are two options, they will divide the base into warring camps.

Would you be more comfortable, or think others would, if we continued to maintain the -el# releases, but compiled/linked them under RHEL# rather than CentOS or CentOS Stream?

I have no idea. They're a so many possibilities it's hard to know right now. We have know idea how Stream really going to be developed. How are they going to handle breaking changes for features for RHEL 9/10/etc.?

Obviously, we have no way of knowing if Rocky Linux will come to fruition, so no way to really evaluate that currently. Just putting it on the radar as it would probably be where a lot of people end up if it turns out to be a community replacement for CentOS.

I suppose compiling/linking in RHEL may be the best/easiest solution to ensure major version compatibility.

Have you seen Rocky Linux has been released?

https://rockylinux.org/

Not sure it warrants any changes or not, just make you aware if you weren't already.

Whenever I install Linux, I always just go for plain old Debian. You could have a non-free microsabio repo and we could do apt-get ashell

Being able to use apt-get would be very nice, as would getting everyone to embrace one platform or another. Traditionally nearly all the interest has been on the RHEL/CentOS side, where I'm currently maintaining versions 7, 8/CS8 and 9. But especially in the UK, interest seems to have shifted to the Debian side. In response to that I'm currently maintaining Ubuntu 20 and 22 versions. (I think those are based on Debian 11 and 12, respectively, but am not yet sure whether it would be better to drop the Ubuntu stuff and just deal with the "plain old Debian".) I played with an early version of Rocky Linux a couple of years ago, but haven't gotten any inquiries about it since Stephen's post above, so am not sure whether that's worth the effort.

In any case, I'm looking forward to a spirited debate on the subject at next month's Conference. So I advise you to prep your representative Steve so he's able to present your best arguments! Maybe even a demonstration of apt-get ashell!

I don't recall a consensus on which flavor of Linux would be the preferred future for A-Shell being reached at the conference. We need to work on updating our ansible provisioning to handle a newer OS once CentOS 7 is out of date.

What direction would be best the take?

Indeed, that was one of the resounding failures of the Conference -- there didn't seem to be any consensus on a preferred platform, or even if such a fantasy was even possible (given that some A-Shell developers have decreasing amounts of control over their customers' computing environments). For the moment, the vast majority are still on CentOS 7 but all seem to realize that they need to make a decision soon. We've released versions for CentOS Stream 8, RHEL 9, Debian 10, Debian 12, Ubuntu 20 and Ubuntu 22, although I can't say I'm thrilled at the prospects of staying up to date with all of them.

Even though it might seem like crossing the border into foreign territory for those of us growing up in CentOS/RHEL country, I'm leaning towards Debian 12 or Ubuntu 22 LTS. They're both essentially the same as far as A-Shell is concerned; Debian is a bit leaner, more geared towards OEMs, and slightly more difficult to install from scratch, while Ubuntu is a bit more user-friendly, at least from the installer and desktop perspectives and seems to have more packages available. But probably most A-Shell sites would not be able to tell the difference. The LTS (Long Term Support) regimes are similar. Ubuntu 22 LTS has end of 'standard support' through June 2027 with end-of-life in 2032. Debian's target dates are 2028 for standard support and it remains to be seen for its LTS phase (which is handled by another outside group).

From the admin standpoint, the biggest change in crossing over to the Debian/Ubuntu side is the pivot from yum to apt for package management. Migrating users is probably going to be a hassle no matter what, but I'm guessing there are scripts and various recipes available for simplifying it.

Traditional CentOS is gone, leaving just the 'stream' version, which appears somewhat scary to most of the developers I've talked to. But RHEL 9 is now free for up to 16 servers (I think), and offers a wider (and more confusing) array of support options. There's also Rocky Linux, although aside from the previous mention in this thread, I hadn't receiving any inquiries about it and haven't seriously checked it out. (But the door isn't completely shut either.) Currently I think we have only one end-user site running EL9, and it's in 32 bit mode (which is one advantage perhaps of EL9). Debian and Ubuntu have (I think) discontinued 32 bit support. While 64 bit doesn't necessarily offer direct architectural advantages to A-Shell apps, eliminating the need to maintain both 32 and 64 bit packages could be an administrative advantage. I'm pretty sure we've worked the kinks out of A-Shell 64 (under Debian / Ubuntu at least), although there still aren't many production sites running it, so there could well be further problems to sort out.

The most complicated 64 bit conversion was to the AXL / DYNLIB interface, which uses a lot of pointers and handles that all had to change to 64 bit. (ASB doesn't have a 64 bit integer type, forcing us to use X8 instead, which introduces some complexities due to the fact that it's technically a string, not a numeric type.) I think most if not all AXL-interfacing apps should be ok though after recompilation with the updated bsi modules. The most tangible new capability opened up by the 64 bit version (under Linux) is the ability to use the Microsoft SQL Server ODBC connector. Not that it's any better than the Easysoft version, but there's no charge, eliminating what previously was an obstacle to sites that increasingly inhabit heterogeneous environments with SQL Server somewhere on the network and IT / management grumbling about why they can't query their A-Shell / Linux / application data like they do "everything else". In the past, some clever and industrious types have worked around that by exporting from Linux to a PC and then from there to SQL Server, but it's now a lot easier to connect directly.