Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Red Hat Software Open Source Operating Systems Linux

As 'CentOS Stream' Brings Rolling Releases, Some RHEL Development Moves Into CentOS Project (itprotoday.com) 15

It's been five years since the release of CentOS 7, but Indy1 (Slashdot reader #99,447) reminded us that CentOS 8 finally arrived this week -- along with a big new plan for rolling releases.

It Pro Today points out that CentOS already runs on about 16% of all servers, "a number that's only bested by Ubuntu with an estimated 28%," and says that this move "points to CentOS taking a more important role within Red Hat [and] indicates a sea change not only for CentOS, but for the Red Hat Enterprise Linux (RHEL) development pipeline." According to Karanbir Singh, CentOS project lead and Red Hat engineer, Stream will contain the code under development for the next minor RHEL release, which will allow the developer community to discuss, suggest, and contribute features and fixes into RHEL more quickly. "To do this, Red Hat Engineering is planning to move parts of RHEL development into the CentOS Project in order to collaborate with everyone on updates to RHEL," he said.

This would seem to mean that not only will CentOS remain under Red Hat's care and protection, but that CentOS will play a more important role within Red Hat going forward.

This discussion has been archived. No new comments can be posted.

As 'CentOS Stream' Brings Rolling Releases, Some RHEL Development Moves Into CentOS Project

Comments Filter:
  • How might this affect Oracle Enterprise Linux and Oracle VM Server, Fedora, Scientific Linux, Project Atomic, etc? CentOS historically was just unbranded RHEL but the various offshoot 'cousin' distros also were fed from more bleeding edge Fedora weren't they? IBM influence remaining neutral till next major release? So many questions...
    • by Junta ( 36770 ) on Saturday September 28, 2019 @05:49PM (#59247870)

      Scientific Linux was nearly not going to happen for 7 until it diid. I believe it is official that it *really* won't happen for 8, because CentOS is "good enough".

      Oracle will keep doing it's thing, they love the thought of having a relevant OS out there.

      Atomic is still a key tool, though I think they are renaming it.

      Fedora is more aggressive than CentOS.

      I'll say it's getting a bit strange with how many cadences they are doing:
      -Rawhide - bleeding edge of the bleeding edge rolling release
      -Fedora - less aggressive release cycle
      -CentOS Stream - An enterprise rawhide
      -RHEL - the most 'production' recommended cadence
      -CentOS - You'll get your RHEL on a delayed release, but with less mandatory RHN subscription BS.

      • by raymorris ( 2726007 ) on Saturday September 28, 2019 @08:19PM (#59248236) Journal

        https://fedoramagazine.org/fed... [fedoramagazine.org]

        > Rawhide - bleeding edge of the bleeding edge rolling release
        > Fedora - less aggressive release cycle

        Rawhide isn't a release. It's simply fedora/master, aka fedora/development. That is, it's the working copy of Fedora today, or the last day it could actually compile. If Fedora switches from one thing to another, rawhide may contain both of them or neither of them on a given day.

        Going forward, Fedora will be where all of the new stuff starts out. New features and such will go to Fedora first.

        Occasionally, a branch from Fedora will be made. That branch is rhel / centos. New features will not be added directly to rhel / centos, those only get added in fedora.

        When fixes to rhel & centos are needed, they will be done in the centos copy of the release branch. After a short time living in centos with no issues reported, they'll be pulled to rhel.

        So that means you have three levels of usable software:

        Fedora has new features
        Centos has new fixes
        Rhel is reliable, with nothing new and untested

        Whatever work got done on Fedora today will continue to be called Rawhide. As always, today's code is useful only for development - either developing Centos itself or developing a new version of some software designed to work with a future version of Fedora. Anyone *using* the software, as opposed to developing it, should use a numbered release, not rawhide.

  • I wonder how this will impact other RHEL based distributions, such as Oracle Enterprise Linux? Hopefully it allows for a faster release schedule, since there are currently no v8 based images available on OCI for deployment (without uploading our own custom ones)
  • by Anonymous Coward

    I used to be a big fan of Red Hat Linux back in my college days. It was the best Linux distro out there at the time, in my opinion. I was even invited to participate in Red Hat's IPO and made a bundle on that. Very good times, those were.

    But then for some reason Red Hat decided to pull the plug on Red Hat Linux and threw Fedora Core at us. Fedora Core was kind of a piece trash compared to the quality of prior Red Hat Linux releases. And the complete lack of long term support for any Fedora release meant I w

    • by pnutjam ( 523990 )
      Let me tell you about our lord and savior OpenSuse Leap. Stability, with relatively long cycles. It makes an excellent desktop or server.
  • I loathed RedHat and its derivatives for their circular dependencies. Are these a thing of the past? For me, it's been Debian and its cousins all the way for a long time. I wonder whether RedHat has since fixed this madness...

    • by Junta ( 36770 )

      It's funny, the other day I probably wouldn't have said that was a thing, but I actually did run into a trio of their source rpms where 1 depended on 2 to build, which depended on 3, but that depended on 1...

      In that case I told rpmbuild to ignore the build dependency for the first round and it ultimately worked, but it is a thing seemingly still.

    • Yeah, about 15 years ago.

      Source RPMs sometimes require a little bootstrapping, but the future is moving away from even having them.

  • In the companies I work for, If you take in account containerized environments, Alpine Linux and Debian have at least double these figures... For each real server running, 20 or more docker/kubernetes instances with Debian or Alpine are running inside.
  • by Indy1 ( 99447 ) on Saturday September 28, 2019 @05:50PM (#59247874)

    That said, I've been playing with Centos 8 since it got released.

        Before I give my impressions, keep in mind I use linux as a command line only server OS. I don't install X or perform software development. I've been using Centos since version 5, and have historically used mainly RHEL based versions since I started using linux back in the days of Redhat 6.

        I currently oversee several Centos 7 servers at work, including some fairly large (300 TB+) ZFS servers. I've been deploying fewer Centos 7 machines lately because the versions of the kernel, Openssh, and Openssl they're shipping is ancient, and I really prefer TLS 1.3 (which requires Openssl 1.1.1) for services that can use it. However the ZFS (via EPEL) and Samba support in Centos 7 is excellent and easy to get up and running.

        Getting to Centos 8, the kernel (4.18), Openssh, and Openssl is much more up to date (as I expected). However I'm not happy they're doing weird stuff with the Openssh daemon, specifying various ciphers in /etc/crypto-policies/back-ends/opensshserver.config instead of the normal sshd_config file. I disabled that behavior in the systemD startup file, but still not pleased that RHEL chose a non standard way of controlling options in Openssh.

        Also, there's no packaged support yet for ZFS (from EPEL). This isn't Centos's / RHELâ(TM)s fault per se, but it means that if I use 8 for future file servers, I'll need to compile ZFS from source. Mildly annoying, but not a show stopper. Iâ(TM)m guessing that EPEL will get a RPM for 8 out fairly soon to be fair.

        The lack of BTRFS support, while expected, is also disappointing. I donâ(TM)t use BTRFS for a raid file system, but I do prefer it on SSDâ(TM)s over EXT4. Centos / RHEL removed support for BTRFS (which was announced some time ago) in 8.

        One other annoyance I found with 8, is that it doesn't see the storage controller on some server motherboards. I have over a dozen servers that use the Intel S2600GZ motherboard, which has a mildly retarded SAS controller in it. When installing Centos 7, or Ubuntu, or Debian, the controller (and the drives attached) is seen without issue. 8â(TM)s installer, for whatever reason, does not recognize the SAS controller, and did not see the OS drive as a result.
        Going forward, Iâ(TM)m not sure what distribution Iâ(TM)ll use for future servers. Centos 8 is certainly a lot more modern and up to date compared to 7. But with IBM borging RHEL, I question what will happen to Centos in the future.
        Iâ(TM)ve been playing with Debian 10 quite a bit since it came out. While Debian has their quirks too, Iâ(TM)m coming to like APT more and more, as well as the easy ability to upgrade from version to version. Most of my servers stay in use for 8-10 years, so this is important to my use case.

    • You saved me a lot of research and lot more reading. Appreciate your comments. Thanks!

    • by _merlin ( 160982 )

      I have a bunch of CentOS servers as well. I'm not going to roll out CentOS 8 any time soon. My experience is that Red Hat change a bunch of things with each release, sometimes for good reasons, sometimes seemingly arbitrarily. Every major release has serious teething issues, and it's better to let someone else deal with it, and push back on Red Hat to get the things that are definitely broken fixed. Being on the bleeding edge is painful.

      As you mentioned, there's ZFS to worry about. I've had endless tro

    • ZFS isn't in EPEL, it comes from zfsonlinux.org. There is no zfs-release yet for CentOS 8 but it just came out, give them time. You are being dramatic. The 7.7 RPM works fine on CentOS 8 if you want it right now, there is an error installing it but it can be ignored and you must use DKMS and have epel-release installed.

To stay youthful, stay useful.

Working...