1. 42
  1. 26

    Original CentOS founder Gregory Kurtzer is starting a new 100% compatible RHEL rebuild called Rocky Linux https://github.com/hpcng/rocky

    1. 7

      Now let’s just hope that people complaining about IBM’s move with CentOS will go and pay monthly support and donate money time and equipment to get everything set up.

        1. 2

          This is very useful information, thank you :) .

          I really think your comment should be the top comment.

        2. 20

          I thought most of the point of CentOS was “RHEL, but basically free”. If it’s going to be “what RHEL will be in the future”, then a lot of the value proposition goes away. Why not Fedora at that point?

          1. 7

            My interpretation is that this will be a new stepping stone for changes coming from Fedora before making their way into RHEL. Nevertheless that too doesn’t sound differentiated enough to be sustainable.

            1. 6

              While the Stream lifecycle is shorter than CentOS Linux, it is still 5 years. Stream will still keep the same kernel + rh patches for the full lifecycle, so very different from Fedora model. Stream will be a rolling release for the next minor release of RHEL.

              1. 2

                Actually CentOS patches will go to rhel

              2. 5

                According to the Stream page it’s intended to be “positioned as a midstream between Fedora Linux and RHEL”.

                CentOS started out as an independent community project, but since 2014 it’s effectively been part of Red Hat, which owns the trademark and employs most of its developers. From Red Hat’s point of view all of this makes a lot of sense (Red Hat’s acquisition by IBM probably pays a part in this shift). But for people like you and me who want a “free RHEL” … yeah, it’s not a great change.

                1. 2

                  Free doesn’t pay IBM nothing. They get with this a rolling beta release where they iron out bugs. The CentOS users get…well they get nothing. Maybe Scientific Linux or FreeBSD like other commenters suggested.

                  1. 6

                    FreeBSD is essentially a “rolling release” distro; it’s a fine system but not really a replacement for CentOS’ use case.

                    1. 6

                      That’s not quite true. FreeBSD is at either extreme, depending on what you’re looking at:

                      The base system, which includes the kernel, libc, and a bunch of core libraries and tools, is ABI-stable across an entire major release (supported for 4-5 years, I think). Anything written targeting these is guaranteed to keep working and get security updates for new versions. You can write a kernel module for FreeBSD X.0 and it will keep working for all FreeBSD X.y. Any device ioctl from the base system will keep working in the same way. Anything written using control interface (e.g. the the network configuration interfaces used by ifconfig and friends) has the same guarantees. Between major releases:

                      • All syscalls will keep working via COMPAT interfaces in the kernel (which may optionally be compiled out for small / legacy-free systems).
                      • Control interfaces and device ioctls may change in any way.
                      • Core base system libraries will usually have symbol versioning and so will support old versions. Where there’s a complete ABI break, there’s a userspace compat package that installs the old version, though this may not get security updates.

                      The ports system, which contains all third-party software, is rolling release. If you depend on something like ffmpeg or Qt and want to avoid new versions then you need to either maintain a separate install of the version that you depend on (which is quite easy to do with a fork of the ports tree and configuring poudriere with a different LOCALBASE for all of your fixed-version things), bundle it with your program, or persuade the port maintainer to support multiple versions (a few things do this anyway. I think there are typically 3-4 versions of LLVM in the tree because a bunch of things depend on older ones).

                      In my experience, it’s pretty rare for software to break across even FreeBSD major version upgrades, unless it uses some third-party shiny buzzwordy dependency from ports that doesn’t provide any backwards compatibility guarantees.

                      1. 7

                        The base system, which includes the kernel, libc, and a bunch of core libraries and tools, is ABI-stable across an entire major release (supported for 4-5 years, I think).

                        CentOS is supported for ~10 years, if I’ve understood everything correctly. You also get SELinux and a bunch of other features that are nice for different reasons.

                        FreeBSD is nice in many, many ways, but it is not a replacement for CentOS.

                        1. 3

                          If you need SELinux on FreeBSD then you have MAC (Mandatory Access Control) and also a SEBSD module:

                          You also have other security mechanisms on FreeBSD like Capsicum.

                          1. 1

                            Didn’t know about MAC, cool! Not sure how I’ve missed it :-)

                            One nice thing with SELinux is that it’s included and enabled by default, not kernel patches et c to apply.

                          2. 1

                            Is that still the case?

                          3. 4

                            FreeBSD can be rolling release when you track STABLE or CURRENT and can also NOT be rolling release if you just use RELEASE version.

                            1. 1

                              Yes, but ports/pkg is always a rolling (or semi-rolling if you go with quarterly updates) which differs greatly from the CentOS way of doing it. I’m not saying it’s good or bad, it’s just different.

                              1. 1

                                With CentOS/Red Hat approach you end up with very outdated packages very quickly.

                                With FreeBSD approach you always have up-to-date packages.

                                You can also use Poudriere to create and maintain your own packages versions: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-poudriere-build-system-to-create-packages-for-your-freebsd-servers

                                1. 2

                                  With CentOS/Red Hat approach you end up with very outdated packages very quickly.

                                  Yes, agreed. But you get security updates for them as well.

                                  With FreeBSD approach you always have up-to-date packages.

                                  Yes, and that can be a problem in itself. Imagine that you can’t upgrade to a newer version due to breaking changes, but a new security vulnerability pops up. What do you do?

                                  I work in jurassic operations, it’s terrible and everything we run on is far too old. But we are not a developing organisation, we barely know anything about anything right now. Organisations like mine will always chose CentOS/similar if we get support for it, and we are willing to pay stupid amounts of money.

                                  I used to work in software development as a tester. But not even in a team with virtually no technical backlog (like really!) would we ever chose to use a rolling distribution. That is just wasted work, effort, and money. Imagine trying to reasonably test supported versions for your app if using a rolling distribution.

                            2. 1

                              You can write a kernel module for FreeBSD X.0 and it will keep working for all FreeBSD X.y

                              Only if you recompile. There is NO stable kernel ABI. Currently on 12.2 people must compile the GPU drivers locally, because the binary package is produced on 12.0 or 1 or whatever and it does not work.

                              1. 3

                                I believe the GPU drivers are something of a special case here: They depend on the LinuxKPI module, which does not have the same stability guarantees as the rest of the kernel because it tracks Linux kernel interfaces that can change every minor release of the Linux kernel. For the rest of the kernel, they are much stronger binary-compat guarantees. There’s a process before branching each major release of adding padding fields to a bunch of kernel structures so that anticipated functionality can be added without breaking the KBI. This is the reason that a lot of Adrian’s work on WiFi didn’t get MFC’d: it depended on adding extra fields to structures at various places in the WiFi stack, which would have been KBI-breaking changes and so were not allowed into -STABLE without rewriting.

                            3. 1

                              I know, I’m just saying that people who habe been using CentOS because “it’s redhat but free” might want to move to sometging else. People who needed CentOS for ABI compatibility will have to work with IBM/Redhat on this. Because RedHat doesn’t want to work for free, obviously.

                        2. 12

                          Seems that CentOS just lost the only reason people used it - being a free RHEL clone :)

                          Now people that used CentOS will move either to Oracle Linux (same clone as CentOS just with Oracle logo) or to Ubuntu Linux LTS.

                          Of course after FreeBSD adopted quite a lot Systemd Refugees it will as well welcome the CentOS Refugees :)

                          1. 5

                            Now people that used CentOS will move either to Oracle Linux (same clone as CentOS just with Oracle logo) or to Ubuntu Linux LTS.

                            Well, maybe.

                            At work we use CentOS because some of our our customers use RHEL, and it lets us do cheap CI and testing, with a final round on RHEL before release.

                            On the other hand, we’re still using versions 6 and 7, so this won’t affect us for a while…

                            1. 3

                              Most CentOS users will wait for other to pickup from where CentOS left or move to OpenSUSE leap

                              1. 2

                                Oh, I remember this comment from Twitter. As I said there, it’s reductive to say that the only reason people used CentOS is because it’s a free RHEL clone. I use CentOS because it is RHEL-like and has a longer lifespan than Fedora. I use it at home on some systems and to run a server for my blog and other projects.

                                Also, as I said there, it’s sad when people promote an open source project at the expense of others. I don’t know what your position is with FreeBSD but I hope the larger project has more empathy and general decorum. If your only selling points are “we don’t use systemd” then that’s not so hot. What’s the positive reason I’d want to adopt FreeBSD?

                                • Disclaimer - I work for Red Hat. I’m in comms these days, though, and was not involved in this decision in any way. Overall I don’t think it’s nearly as bad for most users as is being made out, and for companies that are depending on a free clone for their production environments… “I hope a public company will indefinitely supply a part of my infrastructure at no cost” is not a plan I’d feel confident in.
                                1. 2

                                  As I said there, it’s reductive to say that the only reason people used CentOS is because it’s a free RHEL clone. I use CentOS because it is RHEL-like and has a longer lifespan than Fedora.

                                  That reads very much like “People don’t only use CentOS because it’s a free RHEL clone, but I only use CentOS because it’s a free RHEL clone.” to me?

                                  1. 2

                                    I guess you can come to that conclusion if you squint hard and ignore the context of the discussion. My emphasis here is on the clone part. The chief complaint seems to be “CentOS won’t be almost exactly a package-for-package, version-for-version clone of RHEL anymore, it will be slightly different!”

                                    For my purposes that doesn’t really matter. It’s not like Stream is going to be so radically different from RHEL that what I know about working with RHEL won’t transfer, nor am I depending on it to be “identical” to RHEL. A RHEL-like OS that may have slightly newer packages that aren’t quite as well tested as RHEL is likely going to work just fine for my use case. I’m not trying to run certified software on CentOS rather than paying for a RHEL subscription. I just want a reasonably stable OS for light usage – if it were a production server that mattered for a business, I’d look at paying for a subscription.

                                    But I don’t want to, say, learn FreeBSD just to host my personal blog. I don’t want to worry about upgrading every year or so, so Fedora isn’t a good fit. It’s fine on my desktop, I want the latest GNOME and so forth - so I don’t mind upgrading once every six to 12 months. But for my web site and personal servers at home, that’s too often. I could use Debian or Ubuntu, but if I use an Fedora/RHEL-type OS in other situations, I might as well preserve my muscle memory for working with my other systems.

                                    I might be projecting, but I suspect a lot of folks are like me and have used CentOS for non-production uses because we know RHEL and it’s an easy drop-in for a lot of uses for a Linux OS. For a wide swath of use cases, it seems to me that it’ll do just fine.

                                    1. 1

                                      I don’t think your use case is so far off. A lot of people have been using CentOS as “a free, redhat-like distro”, which is 100% not a bad thing for private use (I am not opening the can of worms that is paying for RHEL or SLES).

                                      As per my other comment, I’ve hardly heard of people using Fedora for servers. Might be my debian-centric filter bubble though.

                                      For example we at work use it to build stuff that will run on customers’ server with RHEL (not certified, or our userspace daemons don’t matter) - and I think this is perfectly fine. We kinda NEED to build on this, but we’re not running it on RHEL, if someone would need to pay for a development license of this, then it’s the customer, not us. So we’re on CentOS 7 which will be fine until 2024, but no idea what will then happen.

                                      1. 2

                                        My understanding is that Red Hat is planning to expand the no-cost RHEL plans to cover things like CI/CD (which you could do now with UBI if you have a container use case, but not for some other use cases). It’s not ready today, but my understanding is that we are planning to expand the no-cost subscriptions to cover some of the other CentOS use cases.

                                    2. 1

                                      Your perspective sounds valid for someone not having used Red Hat (without the Enterprise) Linux in the past.

                                      I can’t put my finger on it, maybe it’s simply “server vs desktop” but CentOS always seemed like a full “Red Hat Linux, as in 5.x 6x, 20y ago” replacement to me and Fedora did not.

                                      So it’s not really about being “free”, it’s about still using that thing. (I’m in the Debian/Ubuntu camp, thus my lack of real knowledge about Fedora)

                                      1. 1

                                        Was this meant to be a reply to the parent comment? Because I don’t feel like it really relates to what I said. :)

                                        1. 1

                                          Actually it was meant for you, re: what you answered to jzb, because I didn’t see the focus on a “free RHEL”.

                                          If I arrived at the distro scene today I’d see CentOS as a free RHEL - but my point was that if I want a server that my goal wouldn’t be “I need a free RHEL” but more “I want something that uses RPM and I don’t see Fedora as a server distro”. RHEL-compat is not important and a distro being free is more the norm than the exception.

                                          But maybe I completely missed your point there.

                                2. 8

                                  RH trying to make more money. Makes total sense from a business point of view. I wonder if that will revitalize scientific linux, which was abandoned in favor of Centos.

                                  1. 6

                                    I think the nature of Stream is acceptable. Since it’s a midway point between RHEL minor releases, general quality should be fine. My issue is with the reduced lifetime. Stream is only maintained for the duration of RHEL Full Support, 5 years instead of 10. 5 years is the same lifetime as Debian or Ubuntu but those have mature support for in-place upgrades.

                                    1. 1

                                      those have mature support for in-place upgrades.

                                      Will CentOS Stream not? (Genuine question; I think I might just be misunderstanding you.)

                                      1. 2

                                        I was under the impression that RHEL still had no official in place upgrades. That’s not true anymore.

                                    2. 4

                                      I wonder if the fedora server project will adopt a longer support cadence after this.

                                      1. 2

                                        Fedora is also a RedHat project, so probably won’t.

                                        1. 2

                                          Yes, but it seems a little independent. The messaging out of the fedora project is all about being community driven at least.

                                          1. 1

                                            It’s also bleeding edge, latest versions and released every 6 months. Changing this would be pretty much worthless for RH?

                                      2. 4

                                        IBM changing things?

                                        1. 3

                                          No. Source: https://twitter.com/rbowen/status/1336701110162231296 Disclaimer: I work for redhat, although not in this area, and have no privileged knowledge.

                                          1. 1

                                            Thanks for the info!

                                        2. 4

                                          A while ago I was thinking of trying out CentOS for a maximally stable system, but steered away when I saw the terms “CentOS Stream” and “AppStream.” Sometimes you just know.

                                          1. 5

                                            In a context like this, the word “stream” just feel like a kinda out-of-place buzzword and as you say it just feels awkward.

                                            1. 2

                                              App too

                                            2. 2

                                              Note that “appstream” is not really a CentOS thing per se - it’s basically a way to provide different versions of things like Python or container tools where users/customers have different needs. So - some customers want to stay on Python 3.x that shipped with RHEL 8.0 or whatever, whereas other customers want Python 3.x+2 that shipped later. The idea is to break those things out so they can be supported at a different cadence than RHEL itself because the old model didn’t quite fit and they wanted to offer more choice.

                                              Not that it would change your feelings about “CentOS Stream” but AppStreams are actually a pretty decent concept for RHEL users / customers. Red Hat has many strengths, but naming isn’t in the top 20.

                                              1. 1

                                                It was mostly the name that set off my bullshit alarm, but “more choice” does mean less testing for a given version of a package, and less stability.

                                                On the other hand I’m not clear what is new about the AppStream concept. How is it different from using EPEL or some other package repository?

                                                1. 2

                                                  “More choice” does not mean “less testing” – those packages, in RHEL, have to be supported by Red Hat.

                                                  AppStream is described pretty well here. It’s not meant to replace EPEL, but Red Hat Software Collections (SCL).

                                                  Basically, you choose whether you want, say PostgreSQL 9.6, 10, or 12. The name “AppStream” replaces, IIRC, “modules” which was confusing. As I said previously - Red Hat has many strengths, but naming isn’t in the top 20 for things like this. (To be fair, I don’t have a better idea…)

                                                  1. 1

                                                    “More choice” does not mean “less testing” – those packages, in RHEL, have to be supported by Red Hat.

                                                    I don’t follow. You can have more or less testing within Red Hat, and more or less usage by customers for a given package. It seems obvious that having more choices means less usage and testing for each choice.

                                                    I found a project called IUS which provides repos for more up-to-date packages, and the project is ending with CentOS 8 because of AppStreams. Not sure how IUS fits in with modules, but I imagine there is debate about whether to make things “integrated” at the cost of adding a new kind of thing to the package manager (and the complexity that comes with that).

                                            3. 3

                                              Has any company ever benefited in the long run, from making it harder for devs to work with their products?

                                              1. 2

                                                Apple most glaringly, but pretty much any big tech company has in one way or another.

                                              2. 1

                                                Instead of CentOS being based on RHEL, it will be the other way around? RHEL 9, for example, could be based on CentOS Stream 2021-12. So then you’d freeze there and only take the updates and patches RHEL takes for maximal compatibility? Not trying to defend IBM/Red Hat here, just trying to understand how to get back to the current state of things after the switchover, if possible.

                                                1. 2

                                                  Stream is the branch from which the RHEL minor releases are cut, not major releases. Stream will be moving from 8.x to 8.x+1 and so on.

                                                  Fedora ELN is a testbed for the next major release of RHEL.