On Mon, Jan 4, 2021 at 2:54 AM redbaronbrowser via CentOS-devel <centos-devel at centos.org> wrote: > > As for BTRFS, I'm sure this has already been answered, but I'll say it > > again: Red Hat is definitely not at this time interested in BTRFS for RHEL, > > therefore unless Red Hat engineer and business minds are changed, that's not > > going to happen in CentOS Stream. However, a CentOS SIG which adds BTRFS > > would be very welcome. I asked about BTRFS earlier and as far as I can tell, it was not answered - at least not in this thread, or in the context of "CentOS Stream" and what this new commitment to openness would do to change the answer. The reason I asked about BTRFS is because of this: > The issue of BTRFS for RHEL was indirectly answered by the addition of Stratis in RHEL 8. Red Hat put a lot of work into make XFS have the look/feel of BTRFS. Architecturally, Stratis seems to follow the Docker LVM / dm-thinp storage driver, which was an interesting approach, but ultimately ended up being deprecated as a poor model due to its emphasis on correct file system isolation over practical concerns like shared file system caching and performance. It means that it performs poorly at scale, and I suspect the same thing will happen with Stratis. There are too many compromises being made with Stratis, to re-use XFS for a purpose that it wasn't really meant for. BTRFS will prove to be better, having a much larger community to support it, and Stratis will end up a Red Hat only project, that does not get broadly adopted. Even if Stratis might be better - without the community, it will eventually be too expensive to invest in given the limited returns. But, this isn't a discussion about Stratis... I'm just giving some context of what a reasonable community discussion *might* include... The question is about how CentOS Stream can ensure this conversation happens, and that the "community" (not just developers, but USERS... you know, the people that the product is being designed to satisfy?) can provide this feedback, and provide true influence on the direction of RHEL. Right now, Red Hat is deciding to go with Stratis, and drop BTRFS, in direct contrast to what the "community" wants to see. I would argue right now, that one of the *best* reasons to use Oracle Linux instead of CentOS or RHEL, is because Oracle supports BTRFS in their distribution, and if you need BTRFS for an Enterprise Linux distribution, you don't really have a choice any more. Red Hat opted out. > Also, when you say "very welcome" I think you mean Stream SIGs will still need a governance board sponsor to proceed. Which of the governance board members has publicly expressed at any point in 2020 an interest in making Stream SIGs feel very welcome in getting sponsored. I don't understand why SIG requires CentOS Stream, and does not require CentOS. Eventually, we're going to have a paradox to deal with: 1) CentOS Stream is the only supported "free" EL distribution from Red Hat. 2) CentOS SIG will need to support all of: CentOS Stream, RHEL, and at least one other - Rocky? This paradox means that the SIG now have *more* work to do than before. What about projects like RDO? Will they be publishing for Fedora, CentOS Stream, and EL? Will they be able to do this long-term? Or will they end up: A) Dropping EL support, and focusing on CentOS Stream. Now, projects like RDO only work on CentOS Stream, and don't work on RHEL? How will this help RHEL? B) Dropping CentOS Stream support, and only work on RHEL / Rocky? How will this leverage CentOS Stream? This is a mess about to happen. This mess is worse due to the people who claim CentOS Stream is good enough for "95%" of all users. It will lead to SIG specifically targeting CentOS Stream and only CentOS Stream, and no guarantee that their product output will work on RHEL or Rocky, since RHEL and Rocky will be older baselines that cannot be easily or reliably built from a CentOS Stream source. Do the people making the decisions realize this? Because, it leaves me in a state of concern that either they do know this, and they are planning to totally upset the ecosystem (without any consultation with the users who are the most impacted), or they don't know this, and they are soon to be surprised (leaving the users to scramble from one sinking ship to another at their own peril). > Maybe it is unfair for us to toss around the word "charade" or maybe that is the hard reality? Individual people are sincere. I believe Matthew is sincere. However, sincerity doesn't really change the results. I am not claiming anybody here is a bad person or is being less than completely sincere. I am claiming that there are varied interests, and the people with these interests are emphasizing the values that they see, and downplaying the consequences that they are aware of, and the result is basically the same thing. Willingly, or unwillingly, it is a charade - "an absurd pretense intended to create a pleasant or respectable appearance". In this case, Red Hat is killing CentOS as we know it (including using their acquisition of the trademark to force it to die), and selling this as a win for the "community" (= which doesn't seem to include users?) everywhere, because instead of CentOS, an OS distro that inherits the hardened nature of RHEL, you can now run CentOS Stream as a preview of RHEL instead, upstream of RHEL, and it will be good enough for "95% of users" (with no clear definition of who these users are). This is the absurd pretense intended to create a please or respectable appearance. Not everybody is making this absurd pretense, but some still are. Or, perhaps, I just need a little "faith"... it is a Cathedral, and I am basically speaking blasphemy. :-) > > And, honestly, putting my Fedora hat back on, this makes perfect sense. We > > already have the Fedora Project. We don't need a second, overlapping one. > > If you want to work directly on operating system design, come join us over > > in Fedora. If you want to help guide Red Hat's decisions for RHEL minor > > releases, if you want early access to that development, if you want to build > > alternate ideas on that base, you're already in the right place. > Yes, we have a RHEL Insider Fast Ring called the Fedora Project. > What would make perfect sense is to make the RHEL Insider Slow Ring called Stream fall under Fedora Project as well. RHEL minor releases introduce and deprecate functions. RHEL has historically been around 10 years, and that is a long time in Internet years. Docker was in its infancy in RHEL 7.0 time-frame, and thinks like overlayfs were necessary backports to keep RHEL 7 relevant. This is part of the definition of the "slow ring", and ability to contribute to it means ability to influence what decisions get made, despite having stronger requirements for stability from the users. Fedora moves too quickly, and doesn't have a point release. It can be used for production purposes (I've done it before), but it comes at a cost that shouldn't be taken lightly, similarly but to a lesser degree, why CentOS Stream in production use cases would come at a cost that should not be taken lightly. You basically have to be prepared for your systems to break at any time, and have your own testing and stabilization processes in place, to prevent this from happening. Some of us can do this - most of us cannot. And, even for those that can do it - we want to use it sparingly, only where it matters the most. Not everything has to be new all the time, despite what easily excitable developers will push for. We need both an upstream and a downstream to have an effective community. CentOS Stream is not a downstream - it is neither downstream of Fedora, nor downstream of RHEL. CentOS Stream is a branch of RHEL (and RHEL is a branch of Fedora) that runs ahead of RHEL, and acts as a more effective beta program for RHEL. I would love to have a more effective beta program for RHEL, but this is not a replacement for CentOS. Also on the comment of "come join us over in Fedora", I do. Fedora is a very important project that goes beyond RHEL. I'm one of your many "users" who you co-opt as developers according to the Bazaar vs Cathedral models, by doing a lot of the hard work of diagnosing problems and raising them to the attention of people who can fix them, including patches when I am able to. But, companies don't run on just one thing. I work with and on Fedora, so that 2 to 5 years from now, it will be available in EL. It is a long-term investment. The same would apply to CentOS Stream, and the same applies to CentOS. All of these are necessary components. Without CentOS, I don't see how SIG can confirm their products will work on EL - whether RHEL, or Rocky, or Oracle Linux. Possibly, Red Hat will make RHEL free for this limited use case, and effectively constrain the size of the community to either those who pay nearly full list price for RHEL for all systems (as is required today), or special licenses that are encumbered, that might allow a limited amount of "free" usage, but is almost too hard to obtain in the first place, so most people don't bother. -- Mark Mielke <mark.mielke at gmail.com>