Discuss

discuss@lists.centos.org

34729 discussions

Re: [CentOS] I'm looking forward to the future of CentOS Stream
by Gordon Messmer 17 Dec '20

17 Dec '20

On 12/11/20 9:56 AM, Ljubomir Ljubojevic wrote: > And I will repeat that millions of CentOS users found free clone of RHEL > trustworthy enough to use it for production, even without "official > endorsement". Exactly. That's why it's so weird that those people, today, think that CentOS Stream won't be usable, based on their interpretation of the official statements from Red Hat. Red Hat's statements weren't taken into consideration before, but now they're a sign of doom? > If they ... even allowed ANYONE ELSE that was not employed by Red Hat in > 2014 to even come close to learning the secrets of rebuild, no backlash > would have happened I'm going to stop you there, because the CentOS maintainers kept that process out of public visibility long before Red Hat was ever involved. If you think users should know more about the process, then you are pointing fingers at the *wrong* people. I don't want this to become a flame war. So rather than pointing fingers, let's focus on the fact that CentOS Stream promises to be developed in the open, resolving the problem that you're describing. Red Hat is fixing the thing you're complaining about. Red Hat is giving us the thing that has been requested more often, by more people, than any other change in CentOS, and the result is that the press is full of stories about users being angry, because five people on the mailing lists sent a lot of messages. (About half of the traffic in the threads on centos and centos-devel comes from five people, and various people replying to them.) > But no, as soon as Oracle started rebuilding RHEL source code Red Hat > first made things difficult for everyone to create kernels (source code > was not srpms anymore but tar?) You're misinformed. Kernels are still built from SRPM, but the archive used is no longer an upstream release with a series of patches. The reason for the change is not insidious. It's unfortunate that the pristine source + patches can't be maintained, I agree, but speaking as a developer: maintaining hundreds of patches that touch intersecting files and rebasing them all when earlier patches are updated is an incredibly difficult and time consuming task. And, if I remember correctly, applying all of those patches took almost as long as building the kernel. If it takes that long to just prepare the source code, that's a major hit to productivity when a developer needs to work on the code or build the SRPM to validate changes. And, ultimately, there's very little value in shipping those patches when the vast majority of them are already in the current version of the upstream kernel, and they're merely backported to the older release that Red Hat supports. It's an entirely different story when distributions are shipping patches that they don't push upstream, but that's not generally what you see with the kernel package.

15 19

I'm looking forward to the future of CentOS Stream
by Gordon Messmer 17 Dec '20

17 Dec '20

Personally, I think that changing focus on CentOS Stream is going to make CentOS (and maybe even RHEL) better in the same way and for the same reasons that Fedora is a better distribution than Red Hat Linux was. CentOS Stream should fix the biggest problems that CentOS has had in the past, providing a reliable, free LTS distribution with community participation. Having read the announcement, along with hundreds of reactions in blogs, forums, and mailing lists, I am of the opinion that all (or a reasonable approximation thereof) of the vocal concern is the result of the overloaded term "stable" as it applies to software distributions. If we imagine a spectrum of individuals in which one end of the spectrum is individuals whose primary occupation is in release engineering for software distributions and the other end is individuals who primarily consume software distributions, I would expect that individuals on one end to mostly use the term "stable" in the sense of compatibility and semantic versioning, and the other end to use the same term in the sense of having fewer bugs. The use of that word causes people at one end of the spectrum to infer a completely different message than people at the other end intend to communicate. If we never use the ambiguous term "stable" and instead use the terms compatibility and reliability (the two common meanings of "stable" at different ends of the spectrum), I think that various aspects of CentOS Stream will be better than CentOS, or the same as CentOS. With respect to compatibility: I think most developers are familiar with semantic versioning. Semantic versioning is used by some applications and libraries to indicate the nature and extent of changes. The version is presented numerically as Major.Minor.Revision. When new interfaces are added, the minor number is increased. Those changes don’t affect backward compatibility. When individual interfaces are changed or removed, the major number is increased. Those changes aren’t backward compatible. That allows consumers to infer that if an application is compatible with 8.1, then it is also compatible with 8.2 and later, but might not be compatible with 9.0. Red Hat Enterprise Linux applies that concept to the entire software distribution, providing independent software vendors a convenient means of communicating their compatibility. If they’ve tested their application on RHEL 8.2, then any RHEL 8 host patched to at least that release is expected to run the application. Moreover, Red Hat will continue to publish security patches to each given minor release’s channel, allowing consumers to "pin" a host to a minor release. Those hosts will not receive feature updates, but will mitigate vulnerabilities. CentOS Stream isn’t going to feature minor releases, and isn’t going to provide semantic versioning of the distribution. The same application that the vendor has validated on RHEL 8.2 will run on a fully patched CentOS Stream 8 host, but might not run on a host that isn’t fully patched. On the surface, it appears that CentOS users will lose the convenience provided by semantic versioning. I would simply point out that the CentOS developers have never supported running CentOS in any state other than fully patched. They don’t publish security information in the package repositories, and they don’t support any means of pinning a host to a minor release. For practical purposes, CentOS Stream will need to be fully patched for compatibility purposes, just like CentOS is, and will be equally suited for production purposes. To put a really find point on that: Semantic versioning is only meaningful for hosts that are not fully patched. A fully patched host is expected to be compatible with any application validated for that major release. With respect to reliability: Many of the people concerned about the change in focus refer to CentOS Stream as a "beta" for RHEL. That is not how Red Hat or the CentOS maintainers describe CentOS Stream( anywhere that I've seen), and I think it ignores most of the development, testing, and distribution pipeline. At the risk of oversimplifying that pipeline a whole lot, in the future Free Software will pass through several stages on the way to RHEL: Stage 1: (Software Development) The majority of development and testing is done in individual upstream projects, outside of Red Hat. Stage 2: (Release Development, aka Rawhide) The initial work to build and integrate individual packages with the rest of the software distribution is done in what is essentially a development branch of the software distribution. Stage 3: (Stable[1], aka Fedora) Packages that have passed through review and QA are published for general use. There is no minor release, as major releases occur every 6 months and are supported for only 13 months, anyway. Compatibility is maintained by prohibiting significant version changes for applications and libraries "whenever possible." Users expect no new features during a release, but no breaking changes either. Stage 4: (Long Term Support, aka CentOS Stream) Packages that CentOS Stream includes from Fedora have proven reliable in a variety of workloads managed by many users of Fedora. These packages are expected to be very reliable as a result of testing by their developers, by package maintainers, and by real-world users. They are included in CentOS Stream when they are ready. Stage 5: (Long Term Support with Semantic Versioning of the OS, aka Red Hat Enterprise Linux) Packages that RHEL includes from CentOS Stream have a similar level of QA, but package updates that introduce new features and interfaces are accepted only once every six months when Red Hat publishes a minor release. There’s a lot of concern that CentOS Stream will offer less reliability than RHEL, but there’s currently no reason to believe that will be true. There is no evidence that the minor releases that are part of the RHEL lifecycle improve reliability, and as far as I know that's not the reason they're used. Their function is to offer semantic versioning of the OS. CentOS Stream will probably offer the same level of compatibility and reliability that CentOS does today, and should be equally appropriate or inappropriate for production use in the future as CentOS is now in that respect. And that brings me to the one aspect where I think CentOS Stream will resolve the one major, glaring problem that CentOS has today, that most users ignore: Security. With respect to security: Today, CentOS is a release stage after Stage 5 described above. The CentOS maintainers begin work on a minor release after that release is available to RHEL consumers, and the process of rebuilding those packages is often very time consuming. CentOS maintainers have to reverse-engineer the exact order in which packages are built, with the exact set of installed and available packages in the build environment in order to ensure that the resulting package actually uses the same interfaces that RHEL’s packages do. All packages require that ordering and build environment matching, but most packages are published in small sets and ordering is much easier to identify than it is when they are published in a large batch. As a result, security updates can’t be published for CentOS while the maintainers are rebuilding the minor release, because the build dependencies aren’t available yet. Those windows occur every six months, and are typically a month or more in length. [2] Today, CentOS users accept the risk that for roughly two months out of the year, their systems may have known vulnerabilities with no patch to remediate the problem. Personally, I think that’s a huge risk that needs to be weighed against the costs of RHEL licenses whenever CentOS is used in production. The good news is that CentOS Stream looks like it won't have that problem. CentOS Stream updates still won’t be prepared early, while vulnerability details are embargoed, but there aren’t any windows in which CentOS Stream can’t immediately begin work on preparing updates once the embargo ends. That means that CentOS Stream will be as secure as CentOS is today in between minor updates, and significantly more secure than CentOS is today while its maintainers prepare minor releases. The trade-off of significantly improving security in exchange for giving up semantic versioning of the OS is a huge improvement for production purposes. In addition, the announcement of the change in focus indicates that Fedora maintainers should have much better visibility into work going on within the RHEL release engineering process, and more opportunity to participate in that work, and I look forward to that. CentOS’s big security problem has always been compounded by the lack of any external visibility into the process. Based on the information available today, I expect CentOS to be a very reliable, reasonably secure distribution of GNU/Linux with Long Term Support. And judging by Red Hat’s mention that Facebook’s internal groups either are already using an internally curated OS built from CentOS Stream, or will be using it soon, I think I’m not alone in believing that. 1: I’m using the term "stable" here because I expect it to have both common meanings: compatibility isn’t broken within a release, and the software is expected to be reliable. 2: https://en.wikipedia.org/wiki/CentOS#CentOS_version_8

15 20

Re: [CentOS] MTU report question
by Strahil Nikolov 17 Dec '20

17 Dec '20

seems so

1 0

Is Oracle a real alternative to Centos?
by Frank Cox 17 Dec '20

17 Dec '20

Is Oracle a real alternative to Centos? I'm asking because genuinely don't know; I've never paid any attention to Oracle's Linux offering before now. But today I've seen a couple of the folks here mention Oracle Linux and I see that Oracle even offers a script to convert Centos 7 to Oracle. Nothing about Centos 8 in that script, though. https://linux.oracle.com/switch/centos/ That page seems to say that Oracle Linux is everything that Centos was prior to today's announcement. But someone else here just said that the first thing Oracle Linux does is to sign you up for an Oracle account. So, for people who know a lot more about these things than I do, what's the downside of using Oracle Linux versus Centos? I assume that things like epel/rpmfusion/etc will work just as they do under Centos since it's supposed to be bit-for-bit compatible like Centos was. What does the "sign up with Oracle" stuff actually do, and can you cancel, avoid, or strip it out if you don't want it? Based on my extremely limited knowledge around Oracle Linux, it sounds like that might be a go-to solution for Centos refugees. But is it, really? -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com

15 31

https://blog.centos.org/2020/12/future-is-centos-stream/
by Rich Bowen 16 Dec '20

16 Dec '20

The future of the CentOS Project is CentOS Stream, and over the next year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux. Meanwhile, we understand many of you are deeply invested in CentOS Linux 7, and we’ll continue to produce that version through the remainder of the RHEL 7 life cycle. https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates CentOS Stream will also be the centerpiece of a major shift in collaboration among the CentOS Special Interest Groups (SIGs). This ensures SIGs are developing and testing against what becomes the next version of RHEL. This also provides SIGs a clear single goal, rather than having to build and test for two releases. It gives the CentOS contributor community a great deal of influence in the future of RHEL. And it removes confusion around what “CentOS” means in the Linux distribution ecosystem. When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will be to migrate to CentOS Stream 8, which is a small delta from CentOS Linux 8, and has regular updates like traditional CentOS Linux releases. If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options. We have an FAQ - https://centos.org/distro-faq/ - to help with your information and planning needs, as you figure out how this shift of project focus might affect you. [See also: Red Hat's perspective on this. https://www.redhat.com/en/blog/centos-stream-building-innovative-future-ent…]

60 157

CentOS advisories for 8 release
by Olivier Bonhomme 16 Dec '20

16 Dec '20

Hello dear CentOS community, I'm writing on this mailing list because I'm discovering CentOS 8 after several years of practice on CentOS 7. One of my main concern about a distribution is Bug Fixes and Security Fixes. For CentOS 7, all fixes where identified on CentOS-Announces lists with CESA, CEBA and CEEA which is a good thing in order to identify how a distribution can be broken, vulnerable. However, I didn't find any announcement for CentOS 8. I tried to investigate about any changes about announcement policies but I didn't find anything reliable. So I'm asking here what is exactly the status about announcements for CentOS 8 ? Is it a thing who totally disappeared replaced by Red Hat advisories or is it something different ? Or maybe it is just not planned yet ? Explanations would be very welcomed. Thanks for your answer Regards, Olivier Bonhomme

3 3

Software raid Oddity
by Paul R. Ganci 16 Dec '20

16 Dec '20

I have a CentOS 7.9 system with a software raid 6 root partition. Today something very strange occurred. At 6:45AM the system crashed. I rebooted and when the system came up I had multiple emails indicating that 3 out of 6 drives had failed on the root partition. Strangely I was able to boot into the system and everything was working correctly despite > cat /proc/mdstat also indicating 3 out of 6 drives had failed. Since the system was up and running despite the fact more than 2 drives had failed in the root raid array I decided to reboot the system. Actually I shut it down, waited for the drives to spin down and then restarted. This time when it came back the 3 missing drives were back in the array and a cat /proc/mdstat indicated all 6 drives were again in the raid 6 array. So a few questions: 1.) If 3 our of 6 drives of a raid 6 array supposedly fail, how does the array still function? 2.) Why would a shutdown/restart sequence supposedly fix the array? 3.) My gut suggests that the raid array was never degraded and that my system (i.e. cat /proc/mdstat) was lying to me. Any Opinions? Has anybody else ever seen such strange behavior? -- Paul (ganci(a)nurdog.com) Cell: (303)257-5208

3 2

What are the differences between CentOS Linux and CentOS Stream?
by Turritopsis Dohrnii Teo En Ming 16 Dec '20

16 Dec '20

Good day from Singapore, What are the differences between CentOS Linux and CentOS Stream? At the moment, I only know that CentOS 8 support will end on 31 December 2021 while Red Hat Inc will shift its focus to CentOS Stream. Is CentOS Stream going to be very similar to Fedora Linux, shipping with the latest Linux Kernel like 5.10.1? I am looking forward to hearing from you. Thank you. -----BEGIN EMAIL SIGNATURE----- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -----END EMAIL SIGNATURE-----

11 27

What about the AltArch repositories? (+ some experiments with aarch64 on Raspberry Pi)
by Mathieu Baudier 16 Dec '20

16 Dec '20

Hello, given the recent change in direction of CentOS, what will become of the AltArch repositories? (like CentOS 7 aarch64 and the related kernel repositories) I have been experimenting (with some success) with running a regular CentOS 8 aarch64 (ARM 64 bits) on a Raspberry PI 4 (with 4GB RAM), using the aarch64 kernel-rpi2 provided by CentOS 7 AltArch [1]. (a few more technical details below) This is a very different question than what is currently hotly discussed on this list, with the end of the bug-for-bug clone of RHEL, as there were never expectations that such settings would be supported. But on the other hand, I liked to use CentOS for innovation in a given field (mostly Java related) as its stability allowed one to go deep into one direction with "other things being equal" (contrary to Fedora, which is always moving in all directions). I guess that all these "side projects" (and SIGs, etc.) will disappear as well, won't they? Cheers, Mathieu ## More details about running CentOS aarch64 on a Raspberry Pi 4 As for my experiments with running CentOS 8 on a Raspberry Pi 4, a bit more details, so that these efforts are not completely lost. Two approaches were working : - From a plain CentOS 7 AltArch aarch64 installation, perform a CentOS 8 aarch64 install in a chroot (with the --installroot option) + a clean kernel-pi2 install from the CentOS 7 kernel-pi2 repository. Then copy the chroot to an .img file, and use this image to initialise an SD card. - From a plain CentOS 7 AltArch aarch64 installation, perform an in-place upgrade to CentOS 8 (first install dnf from EPEL, then switch the repos, and it works) The second approach had better device support on the Raspberry Pi 4 (most importantly the wifi, which was not working with the first approach), but this was probably a matter of subtle kernel / modprobe configs that were beyond my skills. I thought that I would share all this at some point, and ask for help from the CentOS AltArch developers; but I guess it is irrelevant right now. Both approaches were working equally well on the Raspberry Pi 3 (but Fedora support is good for this version, while Raspberry Pi 4 is not supported, so I tend to use Fedora aarch64 on them). As for what is actually the point of doing all this, this is not for weekend hobby tinkering, and it is relevant for server-side applications. ARM 64 bits is becoming an important platform (hence the fact that RHEL is now supporting it, MacOS will soon completely move to it, etc.) especially if one is interested in climate-friendly low-power IT, also on the server-side. But finding hardware is not easy and the (cheap) Raspberry Pi have 64-bit capable processors, even though the default distrib (Raspbian, based on Debian) does not yet support 64 bits (but they are working on it [2]). After trying many distributions, a paradox was that CentOS was actually the easiest to deploy and use in order to get some results (thanks to the work of the AltArch team!) In my case, the main interest was to test on ARM 64 bits GraalVM, the next generation Java platform, which can compile Java (and other programming languages) to native code. These builds require a lot of memory, but with an extremely slimmed down CentOS 8 and the 4 GB memory of the Raspberry Pi 4, it worked! [3] On a different layer, I could also test Eclipse SWT (Java user interface library) on this architecture (but on the plain CentOS 7 aarch64 with GNOME), and provide some quick feedback to Eclipse developers on their recent support for the whole Eclipse IDE on ARM 64 bits. [4] [1] http://mirror.centos.org/altarch/7/kernel/aarch64/kernel-rpi2 [2] https://downloads.raspberrypi.org/raspios_arm64/images/ [3] https://twitter.com/mbaudier/status/1274263320254722050 [4] https://twitter.com/mbaudier/status/1291421892381937670

3 6

Blog article: CentOS is NOT dead
by Nicolas Kovacs 16 Dec '20

16 Dec '20

Hi, Here's an interesting read which makes a point for CentOS Stream: https://freedomben.medium.com/centos-is-not-dead-please-stop-saying-it-is-a… tl;dr: Communication about Stream was BAD, but Stream itself might be a good thing. Here's why. Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

17 23

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss