Changing CentOS in mid-stream
shifting focus" will qualify as the final "down". Regardless of whether this change turns out to be a good thing, it certainly marks the end of an era that began in 2004.
How we got here
CentOS was born out of an effort to build and distribute packages from the RHEL source provided by Red Hat. The initial CentOS release — CentOS 3.1 (based on the RHEL 3 release), came out in March 2004. There was also a CentOS 2 release (based on RHEL 2), but that showed up two months later. CentOS quickly attracted attention from users looking for a relatively stable system during a time when distributors were doing their best to separate free "community" distributions from the paid-for "enterprise" variants. LWN first mentioned CentOS in February 2004, and looked more closely in early 2005.
CentOS proved to be the stable base it promised to be; that CentOS 2 release, for example, was supported until June 2009 and CentOS 3 had support until November 2010. There were some challenges, though; also in 2009, project co-founder Lance Davis disappeared, along with his control over the project's domain name and bank account. That situation was eventually worked out, happily, but not before the project survived some significant turbulence, forcing it toward more transparency in its governance and finances.
The project also had trouble making timely releases in 2009, a problem that would resurface the following year — and often thereafter. Creating a CentOS release is not a simple or particularly fun job, so volunteers have often proved hard to come by. In 2011, this problem caused the project to fall dangerously behind on security updates while trying to produce the CentOS 6.0 release — a problem that would plague the project for much of the year. In 2012, Oracle tried to use the update delays as a way to market Oracle Linux to CentOS users.
At the beginning of 2014, Red Hat acquired the
CentOS project, taking ownership of the trademarks and hiring several
CentOS developers. At the time, a governing board was set up, and Red Hat
promised that the project would be run in a "public, open, and
inclusive
" way. A small fuss over
version numbers raised concerns about how a post-acquisition CentOS
would be run but, for the most part, things continued as before, just on a
more solid footing. The project announced a
rolling release at the end of that year.
After that, CentOS appeared to settle into a steady routine of relatively predictable releases; the project mostly managed to stay out of the news. The Scientific Linux distribution, another popular RHEL-based offering, stopped making new releases in 2019, with sponsor Fermilab stating that it would switch to CentOS 8 instead. With support promised through May 2029, that seemed like a good bet. CentOS had become boring, predictable, and reliable.
CentOS Stream
In September 2019, a blog post by Red Hat CTO Chris Wright introduced CentOS Stream, describing it this way:
This new offering was parallel to the existing CentOS distribution, Wright
said; "this means that nothing changes for current users of CentOS
Linux and services
". And nothing did change for most of those
users, who paid little attention to the CentOS Stream product.
That story changed on December 8, though, as can be seen in another
blog post from Wright: "we’ve informed the CentOS Project
Governing Board that we are shifting our investment fully from CentOS Linux
to CentOS Stream
". No longer would CentOS Stream be a parallel
offering; now it is the only offering. He added that:
To drive home the point that the deal has truly been altered, Red Hat
announced that the end-of-life date for CentOS 8 had been moved
forward to the end of 2021, taking away over seven years of support that
had once been promised for that release. CentOS users who are concerned
that CentOS Stream might not be suitable for production use are encouraged
to "contact Red Hat about options
".
To a first approximation, CentOS Stream looks a lot like CentOS, but the relationship between the two distributions and RHEL differs. While traditional CentOS is derived from official RHEL releases, CentOS Stream gets (most) updates before they go into RHEL. It is, in effect, a rapidly changing snapshot of what the next RHEL release might look like. A package that might update once in CentOS, after being released in RHEL, may update several times in CentOS Stream before becoming an actual RHEL package.
This new arrangement is better for some users. Anybody who wants to ensure that their code will work with the next RHEL release can test on CentOS Stream and get an early warning of any problems. Users who would like to get fixes more quickly may also like CentOS Stream better. For many production users, though, the prospect of "updates several times daily" lacks appeal. These users tend to want their platforms to be stable with minimal changes; a system that looks a lot like the beta test for RHEL is not what they had in mind. The unhappiness in the CentOS user community is thus easy to understand. "Furthering enterprise Linux innovation" wasn't their goal for CentOS.
Now what?
Most users understand that Red Hat was never under any obligation to maintain a stable platform for them while asking nothing in return. But many of them had made commitments based on the promise of support for CentOS 8 into 2029; Red Hat's decision to back away from that promise feels like a betrayal of trust. Had Red Hat left the CentOS 8 schedule unchanged but announced that there would be no CentOS 9 release, the level of complaining would have been much lower.
To many, the decision also makes a mockery of the allegedly open nature of CentOS project governance. This decision was handed down from a Red Hat corporate office and the CentOS board had, as this message from longtime CentOS contributor and board member Johnny Hughes makes clear, no real prospect of changing it. The nature and goals of the CentOS project (as seen by its users) have been fundamentally changed by corporate fiat, and the "community" had almost no say in the matter.
So now CentOS 8 users have one year in which to implement any changes they will make in response to the end of support. (Note that the CentOS 7 support schedule remains unchanged, with support going through June 2024). Some may find that CentOS Stream works well enough for them in the end. It is, after all, unclear how unstable this distribution will actually be; presumably all packages added to it will have been through the RHEL quality-assurances processes. CentOS Stream could prove to be mostly a marketing artifact — a way of making CentOS look more dangerous to drive RHEL subscription sales without actually making CentOS worse.
Many users may not want to take that chance, though. Some may sign up for RHEL subscriptions, but most are likely to go looking for alternatives. There is a lot of talk about creating a new community-based, CentOS-like project to rebuild RHEL as before. These efforts might succeed, but it is worth remembering how CentOS struggled before it got proper financial support. Creating this kind of distribution involves a lot of tedious, detailed work, and volunteers to do that work will still be hard to find.
There are other existing community-based distributions that offer a long-term stable platform, of course. These include Debian, Ubuntu LTS, openSUSE Leap, and various others. Most of these are likely to be entirely suitable for a wide range of production deployments. Each has its own quirks, but so does CentOS.
An alternative that some may consider is to give up on the idea of an "enterprise" distribution altogether. These distributions were created in an era when one would buy an actual, physical computer, deploy it somewhere, and expect it to do its job for years. Such systems still exist, but it is increasingly common to just order up new virtual machines when there is a job to be done, and to discard them when they are no longer useful. The value offered by long-term-stable distributions in this new world is less clear. Many systems that are deployed on CentOS might actually be better off using distributions with near-mainline kernels and more current software.
It will take time for the dust to settle from this change, and Red Hat may
have burned some community trust that will prove hard to get back. But the
community should also remember that CentOS has been an immensely valuable
gift from actors across the free-software community, with Red Hat playing a
large
part in its making and support. We may or may not like this change, but a
"thank you" to Red Hat for its part in the creation of 15 years (so
far) of CentOS is entirely appropriate.
Posted Dec 10, 2020 17:01 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link] (6 responses)
Posted Dec 10, 2020 17:29 UTC (Thu)
by amacater (subscriber, #790)
[Link]
Posted Dec 10, 2020 22:21 UTC (Thu)
by gbalane (subscriber, #130561)
[Link]
Posted Dec 11, 2020 11:55 UTC (Fri)
by ve9cbc (guest, #137183)
[Link]
Posted Dec 11, 2020 23:04 UTC (Fri)
by nknight (subscriber, #71864)
[Link] (2 responses)
Posted Dec 13, 2020 18:32 UTC (Sun)
by lkundrak (subscriber, #43452)
[Link] (1 responses)
Posted Dec 13, 2020 19:54 UTC (Sun)
by rra (subscriber, #99804)
[Link]
Posted Dec 10, 2020 17:21 UTC (Thu)
by Tomasu (guest, #39889)
[Link] (151 responses)
My first attempt at linux was RH back in the late 90s or early 2000s. It took days to a week or more to download the CDs and they wouldn't even boot. Mandrake however worked fine till rpm blew up a couple times and I switched to debian. After that it's been a mix of debian, gentoo and ubuntu. Back with debian now though and I don't forsee it changing till something crazy happens.
Never had a particularly high opinion of RH or RH based distros and it's typically borne itself out. Self fulfilling? Perhaps. Never once tried RHEL for more than a quick demo iirc (if that even.. not sure).
Posted Dec 10, 2020 17:22 UTC (Thu)
by Paf (subscriber, #91811)
[Link] (1 responses)
Definitely going to miss it.
Posted Dec 17, 2020 23:16 UTC (Thu)
by daniel (guest, #3181)
[Link]
Posted Dec 10, 2020 19:01 UTC (Thu)
by eutopiafound (subscriber, #101473)
[Link] (148 responses)
Posted Dec 10, 2020 19:15 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link] (143 responses)
Posted Dec 11, 2020 6:54 UTC (Fri)
by mebrown (subscriber, #7960)
[Link] (9 responses)
Posted Dec 11, 2020 7:37 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
Posted Dec 13, 2020 20:38 UTC (Sun)
by sjj (guest, #2020)
[Link] (7 responses)
Posted Dec 17, 2020 23:22 UTC (Thu)
by daniel (guest, #3181)
[Link] (6 responses)
Posted Dec 25, 2020 22:31 UTC (Fri)
by jospoortvliet (guest, #33164)
[Link] (5 responses)
Posted Feb 4, 2021 14:17 UTC (Thu)
by emailstorbala (guest, #144622)
[Link] (4 responses)
So technically a customer who has paid money is paying for an issue case support and not for the RHEL itself. And support types differ and it payment also differs.
Posted Feb 4, 2021 14:28 UTC (Thu)
by pizza (subscriber, #46)
[Link] (3 responses)
This is _not_ the case for RHEL (and its derivatives..)
Red Hat packages everything shipped in RHEL, and shoulders all of the maintenance work.
Upstreams only tend to care about RHEL (and backporting fixes to decade-old releases) when Red Hat is paying their salaries. (which, to be fair, they do quite a lot of!)
Posted Feb 4, 2021 20:33 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Feb 5, 2021 6:35 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Feb 5, 2021 14:29 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Dec 11, 2020 10:34 UTC (Fri)
by mbanck (subscriber, #9035)
[Link] (132 responses)
Posted Dec 11, 2020 12:50 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
That's not what I am saying. I'm saying that people are reading too much into these news. However I like my job and therefore I'm not sure how much of what I know I can say publicly. :)
Posted Dec 11, 2020 19:08 UTC (Fri)
by joib (subscriber, #8541)
[Link] (130 responses)
> as best I understand this right now, what happened here was basically a cock-up. Someone in the CentOS community, assuming everything for CentOS 8 would be the same as before (which was a perfectly reasonable assumption), put the 2029 EOL date on a wiki page. From there it made its way to some other places, including the official download page, where it was present for a while. I don't know the ins and outs of exactly who added it where when, but it seems like it was never actually *intended* - we never meant to declare CentOS 8 support would run till 2029 because this whole thing was under consideration. But it did, mistakenly, get out there. Speaking personally I agree it sucks that we had that date up and it's now being changed.
Posted Dec 12, 2020 17:51 UTC (Sat)
by LightDot (guest, #73140)
[Link] (129 responses)
Posted Dec 12, 2020 19:08 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
You're assuming that Red Hat were involved. The whole point of COMMUNITY is that there are senior CentOS people OUTSIDE of IBM/RH, and it could easily have come from there. In fact, from another post, it sounds like it probably did.
Cheers,
Posted Dec 12, 2020 20:04 UTC (Sat)
by pizza (subscriber, #46)
[Link] (127 responses)
Yes and no.
The CentOS Board was free to tell Red Hat to go pound sand. But that would likely result in CentOS-the-project ceasing to exist altogether, because CentOS was in dire straits before Red Hat acquired the CentOS team and dumped a ton of extra resources into it. Since then, Red Hat has continued to provide nearly all of the funding and resources for CentOS-the-project.
Putting together and maintaining "Classic CentOS" is a _lot_ of unglamorous, tedious work, even when completely piggybacking on top of RHEL's source packages. Hardly anyone was willing to do any of this work before; and that's only shrunk since then.
(The common thread here seems to be the highly naive expectation that _someone else_ will indefinitely perform (and/or pay for) the very tedious work involved in maintaining glacially-stable distributions for commercial use..)
Meanwhile, Red Hat's investment into CentOS has made it _much easier_ for third parties to come along and recreate "Classic CentOS" -- all development is now completely in the open, including the tooling used to put everything together. Instead of packages being developed in private and dumped over the wall every six months, it's all out in the open using a CI model. Thanks to CentOS Stream, now anyone can act like Oracle and claim they're better than RHEL because they ship Red Hat's work before Red Hat does.
Posted Dec 12, 2020 23:00 UTC (Sat)
by nknight (subscriber, #71864)
[Link] (123 responses)
Posted Dec 13, 2020 0:06 UTC (Sun)
by pizza (subscriber, #46)
[Link] (27 responses)
Um, except for the fact that it's a RHEL clone. Which means it needs to closely copy whatever Red Hat does. Which means that Red Hat still has near-total control over what goes into CloudLinux's offering. After all, if it diverges, then it's no longer a RHEL clone.
After all, the entire point of using "RHEL clones" is to piggyback on top of the obscene amount of engineering and QA work that Red Hat puts into making RHEL "stable".
Posted Dec 14, 2020 7:36 UTC (Mon)
by nknight (subscriber, #71864)
[Link] (26 responses)
Posted Dec 14, 2020 12:22 UTC (Mon)
by pizza (subscriber, #46)
[Link] (24 responses)
I will believe this when Oracle's investment into "Oracle Linux" crosses the 9 digit threshold. Or at least when Oracle's contributions to Linux (be it the kernel or any significant stack) make it into the top ten for mulitple release cycles.
Oracle Linux (especially its pricing model) is only viable today because Oracle relies on Red Hat to do the overwhelming majority of the engineering effort.
Posted Dec 15, 2020 0:19 UTC (Tue)
by nknight (subscriber, #71864)
[Link] (23 responses)
Posted Dec 15, 2020 2:48 UTC (Tue)
by pizza (subscriber, #46)
[Link] (22 responses)
Whoops, I stand corrected; I conflated the two.
The thing is, my point is even stronger with respect to CloudLinux -- While Oracle is generally a crappy corporate player, they _do_ invest money into upstream Linux, and employ a lot of engineering talent. If CloudLinux is to become anything other than JustAnotherRHELClone (ie successfully "fork" RHEL in a way that makes RHEL irrelevent, as you suggest will happen within five years) they're going to have to substantially step up their sustained investment, which also implies coming up with a way to pay for that investment.
Posted Dec 16, 2020 0:00 UTC (Wed)
by nknight (subscriber, #71864)
[Link] (21 responses)
Posted Dec 16, 2020 0:59 UTC (Wed)
by pizza (subscriber, #46)
[Link] (20 responses)
You seem to completely lack the awareness that if Red Hat goes away, all of these "Free RHEL rebuilds" go away too, because putting together (and providing a decade's worth of support for) what ClearLinux is mechanically cloning costs a hell of a lot more than a million dollars.
Look at LWN's "top Linux contributors" pages going back, well, forever. Red Hat is consistently #2 in the Kernel, and is a dominant funder for many (most?) of the plumbing layers (toolchains, sound, graphics, general desktop, multiple server-focused middleware stacks, virtualization, etc etc) -- a total of $668.5 million on R&D efforts in FY2019 alone, all of which went into publicly-released Free (or Open Source) Software. RHEL subscriptions paid for all of that.
So be careful what you wish for.
> We do *not* match your mental model of us.
Who is this "us" you speak of? Choosing beggars that seem to believe that they're somehow entitled to tell others what work they should be doing? (For free!)
Yeah, this change in CentOS sucks, no two ways about it. It affects me too; fortunately the uses I have for CentOS are just fine with the CentOS stream model. But I'm not going to trash Red Hat for making that change, because they owe me nothing. Instead, I will say "thank you for continuing to provide, and integrate/test/support all of this Free Software" because whether or not I actually use RHEL/CentOS/Fedora, I still heavily benefit from Red Hat's ongoing investments, and want to see them continue.
Posted Dec 16, 2020 1:09 UTC (Wed)
by nknight (subscriber, #71864)
[Link] (19 responses)
Posted Dec 16, 2020 1:30 UTC (Wed)
by pizza (subscriber, #46)
[Link] (18 responses)
*snort* It was not a "community brand", it was owned by the founders of CentOS. There was no "hijacking" either; CentOS could have politely told Red Hat to get lost. (And if they had, CentOS probably wouldn't have survived another year, not because of reprisals, but because the CentOS folks were already quite burnt out and were having major problems getting code/updates shipped)
Meanwhile, Red Hat's "economic power" is the only reason CentOS (and Scientific Linux, and Oracle Linux, and ClearLinux) ever existed to begin with. Ya know, that whole "binary RHEL rebuild" thing.
Posted Dec 16, 2020 3:31 UTC (Wed)
by nknight (subscriber, #71864)
[Link] (17 responses)
Posted Dec 16, 2020 3:43 UTC (Wed)
by pizza (subscriber, #46)
[Link] (16 responses)
Um, you're the one being all negative here, but whatever...
> I’m done entertaining you.
I'm sorry you feel that way.
Posted Dec 16, 2020 9:40 UTC (Wed)
by nknight (subscriber, #71864)
[Link] (15 responses)
Posted Dec 17, 2020 23:27 UTC (Thu)
by daniel (guest, #3181)
[Link] (14 responses)
Posted Dec 17, 2020 23:48 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (12 responses)
As an outsider, every time I interact with the apt suite of tools I find myself confused and searching the Internet because I can't remember which tool I need to install to answer my query or even ask a simple `--help` about. It makes me really happy to have dnf as a frontend to my package management. Maybe someone could write a simple dnf-like tool in front of dpkg and finally kill off the apt mess, but who knows. That still wouldn't help alleviate the nightmares about trying to untangle dpkg creation tools and recipes and am much happier with .spec files, but that's a different thing.
(FWIW, I started with Fedora Core 5 using apt-rpm until yum was useful enough to ignore it.)
Posted Dec 18, 2020 1:42 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
There's no need for dpkg shenanigans.
Posted Dec 18, 2020 14:54 UTC (Fri)
by zlynx (guest, #2285)
[Link] (9 responses)
Just yesterday I needed to know what had installed the file /etc/OpenCL/vendors/mesa.icd
The command to find that on Ubuntu is "dpkg -S /etc/OpenCL/vendors/mesa.icd". On Fedora it is "rpm -qf /etc/OpenCL/vendors/mesa.icd"
I don't think "apt" or "dnf" handles that at all.
There are actually a lot of things the higher level apt or dnf commands don't do.
Posted Dec 18, 2020 15:15 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (7 responses)
This isn't true for dnf. yum/dnf has whatprovides and if you don't have the package installed and want to query against the repository metadata, you can use dnf repoquery (with yum, repoquery was a separate tool shipped as part of yum-utils).
Posted Dec 18, 2020 15:35 UTC (Fri)
by amacater (subscriber, #790)
[Link] (6 responses)
Many Red Hat users have got used to using dnf/yum - in the case of yum, that's a third party contribution to Red Hat.
dpkg -S queries at the same level as a raw rpm command
apt will do much of what you want. In some circumstances, you might want apt-file. apt-cache search foo is also useful and apt-cache is included in apt. [First came deity, then apt-get, then aptitude with a superior solver for package dependencies, then apt - the name goes back to Wed, 4 Mar 1998 19:58:33 +0000 (GMT) and the corresponding post on the debian-devel-mailing list - https://lists.debian.org/debian-devel/1998/03/msg00332.html ]
[For the curious, there was apparently a point at which Red Hat considered adopting something other than RPM right back at the beginning. Of the surviving distributions: Slackware is first, a few months later is Debian, a couple of months later is Red Hat and SUSE is an independent entity out of Jurix. And, for the purists: Debian packaging and Red Hat packaging are largely equivalent when all's said and done. A Debian package can be stripped apart using cpio and tar - an rpm requires a specific binary to do this if I remember rightly.]
Posted Dec 18, 2020 16:23 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
That's an odd way to phrase it given that it wasn't a contribution to the company as such, just happens to be an open source project not originating from any particular vendor like the vast majority of the distribution and I am not sure why it is relevant.
In any case, for the record, Seth Vidal who was the primary developer of Yum (and a key contributor to CentOS for that matter) and was an active direct contributor to Fedora during the time that Yum became default in Fedora (and subsequently RHEL, derived from Fedora adopted it) and was an employee of Red Hat for several years while working on Yum among other things till he passed away.
Some more backstory: https://www.linuxfoundation.org/blog/2013/07/in-memoriam-...
Posted Dec 18, 2020 17:14 UTC (Fri)
by amacater (subscriber, #790)
[Link] (1 responses)
There's not a lot to choose between them, as I wrote: I've had someone complain at me that it was harder to check signatures of packages in Debian because Debian signs the package manifest - but, meh, apt[-get|itude] checks that for you automatically and will whinge at you if the package list is out of date.
Posted Dec 18, 2020 18:29 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
To be more accurate, YUP is from Yellow Dog. Yum although it shares some history with YUP is significantly different and originated from Duke university with Seth Vidal as the primary developer. Technically, similar to dpkg vs Apt. As you noted, just a higher level tool - I consider this as a package manager vs higher level dependency resolver (in Dnf - there are multiple libraries that handle different aspects and the resolver logic is part of libsolv - Originating from Opensuse). In Debian, there have been different resolvers in the past (Smart for example - Canonical at one point was considering making it the default resolver for Ubuntu).
Posted Dec 18, 2020 22:53 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
If I remember my SuSE history correctly, it started a few months before Red Hat as a Slackware derivative. Then they rebased it on Jurix, before starting to use rpm as their packaging solution.
Cheers,
Posted Dec 29, 2020 16:06 UTC (Tue)
by jwilk (subscriber, #63328)
[Link] (1 responses)
It's ar, not cpio: https://manpages.debian.org/deb.5
Posted Dec 30, 2020 18:23 UTC (Wed)
by anselm (subscriber, #2796)
[Link]
RPM packages are basically cpio archives with a header attached in front. There's an rpm2cpio program that will remove the header so the rest can be fed to cpio.
Posted Dec 18, 2020 19:54 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Dec 18, 2020 2:12 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
apropos 'apt(-.*|)\>'
should do the trick.
Don't bother with the APT User Guide in package "apt-doc", though. As far as I can tell, it's desperately undermaintained.
Posted Dec 18, 2020 1:13 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Remember, what floats my boat may well sink yours, and vice versa.
My main package management tool is emerge, and there's a good community for me there, too ... :-)
Cheers,
Posted Dec 15, 2020 6:36 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link]
I am curious how you get that impression, because it couldn't be further from truth.
Posted Dec 13, 2020 11:47 UTC (Sun)
by johannbg (guest, #65743)
[Link] (94 responses)
That makes no sense Red Hat always has direct control over the trademark it owns and related products including the ability to end them thus it has indirect control over any derivatives that are based strictly on those same products as well.
A good example of this is when Red Hat made the poor management choice and sacrificed it's ethical values for profit when it started to obfuscate it's source code release in an attempt to make business harder for downstream consumers of RHEL's source code that rebranded, rebuild, and redistribute it.
Posted Dec 13, 2020 12:33 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (83 responses)
What do you mean?
Posted Dec 13, 2020 12:51 UTC (Sun)
by johannbg (guest, #65743)
[Link] (82 responses)
Posted Dec 13, 2020 13:50 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (44 responses)
For one, due to the sheer amount of patches in the RHEL kernel the process was starting not to scale. Every six months thousands and thousands of patches are applied. Just applying all the patches from an RPM would take several hours.
Second, no one in the CentOS community had even noticed that, for the ability for the community to rebuild was not affected at all. The whole thing came up when some Debian engineers went looking for kernel patches in RHEL6's 2.6.32 kernel to fix a bug. Well, they could have asked the upstream maintainer perhaps, since he worked for Red Hat: in the last couple years I have helped several times with backports for various processor erratas back to 3.14 or so.
Third, that's not obfuscation. There's countless open source projects that are developed within closed doors, with new releases consisting of code drops from a private repo to GitHub. Instead Red Hat is doing *all* development upstream first and providing the list of commits (99% of which apply with zero conflicts given how closely the RHEL8 kernel tracks upstream). Talk about double standards...
Posted Dec 14, 2020 7:37 UTC (Mon)
by nknight (subscriber, #71864)
[Link] (43 responses)
Posted Dec 14, 2020 13:52 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (42 responses)
Posted Dec 14, 2020 22:13 UTC (Mon)
by paulj (subscriber, #341)
[Link] (33 responses)
Posted Dec 15, 2020 6:51 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (32 responses)
1) that is nothing more than the definition of "source code", which is the actual term used by the GPL. Source code has a week known meaning in the industry that does not include the history.
2) the GPL also says that "for an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable" again with no reference to the history
3) "making modifications" does not require a git tree (ever done a shallow clone?). "Debugging", "identifying changes for the purpose of porting them to a different derivative", "collaborating with other people in the same organization" are not activities that the GPL talks about.
That said I am not sure how CentOS Stream will handle kernel changes. Maybe the git tree will be public after all, I don't know. The list of patches already is.
Posted Dec 15, 2020 7:57 UTC (Tue)
by nknight (subscriber, #71864)
[Link] (1 responses)
Posted Dec 15, 2020 10:03 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link]
Posted Dec 15, 2020 9:17 UTC (Tue)
by paulj (subscriber, #341)
[Link] (29 responses)
"The source code for a work means the preferred form of the work for making modifications to it."
That is the literal licence text.
Is it /possible/ to make modifications without the information of what patches were applied to the stock linux kernel source? Of course! Just as it was /possible/ for people to make modifications to NVidia's obfuscated C X11 driver back in the day. Just as it is /possible/ to make modifications to the binary object code, either with a hex editor or by disassembling the code and editing the assembly code. These are all /possible/.
However, that's not the bar the licence sets. The licence sets the bar at "preferred" - precisely because Stallman anticipated that otherwise some would try work around the GPL with obfuscation.
You and your technical colleagues at RedHat clearly prefer using the git form, with the information of each 'modification' to the stock kernel code preserved, so as to make it easier to shuffle, update, re-order, drop, and work with all the changes. That is the preferred form.
The form you release has deliberately had that information stripped, so as to obfuscate it, and make it harder for others to work with.
Posted Dec 15, 2020 9:25 UTC (Tue)
by paulj (subscriber, #341)
[Link] (7 responses)
Your src.rpm form has the ability - indeed was /designed/ - to convey the original code and each change separately (the source and "patches") in a way that preserved this critical information. RedHat long created src.rpms of the kernel (from some other SCM I think) with the stock kernel code as the source, and the changes as patches. RedHat deliberately chose to collapse the source, and remove that information - critical to the preferred form for working with that code - to disadvantage others.
You could either publish the git, or (again) split out the source and each change as a patch in the src.rpm.
Posted Dec 15, 2020 11:10 UTC (Tue)
by paulj (subscriber, #341)
[Link] (6 responses)
Posted Dec 15, 2020 13:52 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (5 responses)
Posted Dec 17, 2020 23:58 UTC (Thu)
by daniel (guest, #3181)
[Link] (4 responses)
Posted Dec 18, 2020 0:12 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Who is going to determine what the "spirit" of the license is and how is that going to be enforced?
A license is a legal agreement. If something is not covered explicitly by the terms of the license that it is intended to cover, that is just a bug and should be fixed. Having clarity within the license is more effective than attempting to attach unspecified terms outside of it.
Posted Dec 18, 2020 1:11 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
And then that bug-fixed version of the license will get rejected by those intentionally taking advantage of the gray areas in the old license, while accusing its creators as being clueless zealots who are out of touch with what businesses need from "modern" software development.
Posted Dec 18, 2020 1:42 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
>And then that bug-fixed version of the license will get rejected by those >intentionally taking advantage of the gray areas in the old license
...Which is fine. Arguably this already happened with GPLv2 and GPLv3. The old and new versions have clear delineations and the choices are transparent to everyone as opposed to talking about the nebulous spirit of the license which really can mean anything from "The author of the license thinks this way" to "the project using the license thinks it should be interpreted this way" to "this person in LWN who is connected to neither wishes the license has this expanded interpretation although the plain reading of the license doesn't really say that". It is not the job of a software license to mandate healthy best practices around a community. If that was the case, even GNU wouldn't past that test given that bash git changelog has a lot of tarballs checked in directly on a routine basis.
Posted Dec 18, 2020 1:17 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
The musings/writings of (people within) the FSF is a good determinant of the GPL. If the wording of a licence is not clear a Judge has two options - to interpret it in favour of the defendant(s), or to interpret it in the light of explanatory text by the authors. Both are valid approaches.
And I think, in UK courts, Judges have been known to read Hansard and use the contents thereof to ignore the explicit black letter of the law on the basis that "MPs were misled when asked to vote on it".
Cheers,
Posted Dec 15, 2020 14:24 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
No, that clause was intended to ensure source code was supplied in an easily-machine-readable/modifiable form, as opposed to, say, delivered on reams of paper where it would first need to be OCR'd.
( https://lwn.net/Articles/431651/ )
Posted Dec 15, 2020 14:36 UTC (Tue)
by paulj (subscriber, #341)
[Link] (3 responses)
Note that today, git might be considered that medium. The source code on that medium defined as having to be in the "preferred form for making modifications".
Obfuscated source - i.e. sources with information removed (so as to frustrate others) - is not source code, as the GPL requires it.
Posted Dec 15, 2020 16:23 UTC (Tue)
by pizza (subscriber, #46)
[Link] (2 responses)
No, "medium" refers to something physical. Paper, tape, compact disc, or even the internet. How those bits are organized on that medium doesn't matter as long as that _medium_ is "machine readable" and "customarily used for software interchange".
(And yes, in the early days of the FSF/GNU, distributing software on machine-readable paper was very much still a thing!)
> Obfuscated source - i.e. sources with information removed (so as to frustrate others) - is not source code, as the GPL requires it.
But revision history is not source code, and the GPL covers *source code* only.
So yes, deliberate obfuscating the source code is a no-no, but how is distributing one big patch vs 100 smaller patches "obfuscating" the source code?
The GPL does not require revision control or any associated metadata with change history beyond "complete corresponding source code" is supplied for stuff distributed in binary form -- ie everything needed to recreate the distributed binaries. If you're distributing stuff purely in source code form, then you can supply the complete original work (modified or not), a random ten-line snippet, or anything in between, and deliver it etched into a slab of granite.
And while the GPL requires that any changed files "carry prominent notices stating you changed the files and the date of any change", note that applies at time of *distribution* -- it doesn't matter that I modified file1.c on 2020-11-20 and file 2.c on 2020-11-25, only that I publicly distributed my modified version of both on 2020-12-01, and a patch file clearly shows what was modified, and the "when" is "the timestamp of the patch file"
And before you say that a patch file doesn't satisfy that requirement, because it lies outside the files themselves, I should point out that revision control doesn't either, as that what/when change metadata is also not part of the actual files.
Posted Dec 15, 2020 16:50 UTC (Tue)
by paulj (subscriber, #341)
[Link] (1 responses)
I think it pretty obvious how collapsing and removing information about the constitution of code obfuscates it - be it by a compiler transforming C code into object code; or a RedHat src.rpm building system turning a series of commits in a git tree into one big blog of a patch.
The wording in the licence is "preferred form", and there is a simple test: Would the RedHat engineers prefer to work with the collapsed big-patch, or with the broken-out patches? The answer to that is obvious, given how RedHat engineers work.
Posted Dec 15, 2020 17:26 UTC (Tue)
by pizza (subscriber, #46)
[Link]
In other words, by virtue of their use of HTTP over the internet, Red Hat is using "a medium customarily used for software interchange" to distribute their complete corresponding source code.
> I think it pretty obvious how collapsing and removing information about the constitution of code obfuscates it - be it by a compiler transforming C code into object code; or a RedHat src.rpm building system turning a series of commits in a git tree into one big blog of a patch.
Please stop bringing up the red herring of distributing [partially] compiled sources, because (1) everyone agrees that is an explicit GPL violation, and (2) RH has never done that.
What's being "obfuscated" are the sequence and history of individual changes. The *source code* is the same either way.
Meanwhile, it's been nearly a decade since RH made this change -- see https://lwn.net/Articles/432012/ -- and nothing new has transpired since. You don't have to like what RH is doing. That's fine, a lot of others feel the same way (including our fine LWN editor). However, it is _not_ a GPL violation -- unless you are also arguing that most of what's available on gnu.org is violating the GPL as well. Say what you will about RH, but I trust that the FSF knows how follow their own license.
Posted Dec 15, 2020 20:28 UTC (Tue)
by madscientist (subscriber, #16861)
[Link] (15 responses)
It was not required that people publish their local RCS or SCCS repositories to comply with the GPL: they simply published source tarballs, same as appears now on the ftp.gnu.org site.
Even today I don't think the GNU project requires development of all its software to be performed in a publicly-accessible SCM, and if not to publish the contents of the SCM repository when making releases. Of course, it's moot these days because all GNU projects I'm aware of do it anyway, out of convenience.
Posted Dec 15, 2020 22:31 UTC (Tue)
by paulj (subscriber, #341)
[Link] (14 responses)
That aside, what is preferred can change over time. Things that were preferred in the 80s and 90s need not be (and are unlikely to be, in tech) preferred in the 2020's. And the GPL drafting seems to have been careful to explicitly specify the forms and technologies, no doubt to future-proof it.
Posted Dec 18, 2020 0:01 UTC (Fri)
by daniel (guest, #3181)
[Link] (13 responses)
Posted Dec 18, 2020 10:44 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (12 responses)
I'm not sure I agree with you, in the context of what the GPL is intended to enable.
While you would prefer the full revision history if you're trying to unpick why the distro did something, that's not something the GPL requires - only identification of the changes, and the ability for a recipient to make further changes. One big patch meets both of those requirements; you can clearly see what Red Hat got from upstream, and what changes Red Hat applied, and you can make further changes yourself.
Posted Dec 18, 2020 11:23 UTC (Fri)
by paulj (subscriber, #341)
[Link] (11 responses)
You're hitting a bug in some Free Software you're using, and you want to fix it. You go to the project's website. They have 'make dist' tarballs, and they have a git repository.
Which will you prefer to download, to make your modifications?
Posted Dec 18, 2020 11:28 UTC (Fri)
by paulj (subscriber, #341)
[Link] (9 responses)
You want to figure out which of their changes from stock is the problem. You might want to bisect through all the changes, to find the problem change, so you can fix it.
Which form would you prefer to start with?
Posted Dec 18, 2020 11:34 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (7 responses)
Now you've changed from what the GPL requires - it does not require the upstream to make it easy for me to identify which change is problematic, only that I can identify changes from the version my upstream received, and modify it.
If I want to fix-forward, then the version with stock kernel and all their changes is just fine - I don't need to know which change is problematic, I need to know what the bug is and fix it there. I only need to identify the problem change if I simply want to undo some of my upstream's changes but not all of them, and the GPL does not require upstream to make it easy for me to do that, as long as I can comfortably edit and rebuild the work as I received it.
Posted Dec 18, 2020 11:39 UTC (Fri)
by paulj (subscriber, #341)
[Link] (6 responses)
The GPL defines source code as "preferred form for modifications" - deliberately framed that way to remain general and be apply across technologies, and across time as tools and preferences change.
Asking questions about how developers work today, what they prefer to have in doing that work - within the confines of what the distributor has available - seems the correct way to me to figure out what "preferred form" should mean.
Posted Dec 18, 2020 11:45 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (5 responses)
If I am modifying the code, then I want the code as a whole on my filesystem - the output of `tar x` or similar. Revision control history is not something I need or usually want to make modifications to code.
You changed from making modifications to finding bugs introduced by modifications that my upstream made. In that situation, I'd like revision control history, as part of identifying the bug, not as part of modifying the code. Once I've identified the bug, I'll go back to the final form I was given and fix that.
Posted Dec 18, 2020 12:53 UTC (Fri)
by paulj (subscriber, #341)
[Link] (4 responses)
Flip it around: Say you're a distributor of other people's copyleft software. You have a git tree tracking changes.
Do you want to try dance on pins to argue that the workflow that is the easiest (and practical - given scaling) for you, is somehow not preferable for others, and acceptable within the licence, trying to justify nformation-striping you added to frustrate competitors?
Or do you just export that git tree (with whatever git filter), to make sure you accommodate others, and err on the side of staying clearly within the licence?
Posted Dec 18, 2020 13:21 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
But I use such a system, not to track the code, but to allow multiple people to work together on the code without conflicting. The VCS is a side-effect of that, used while I'm producing the work to allow several modifications to happen in parallel while providing me with a way to integrate them together into a final form that I release to my customers.
FWIW, when I worked somewhere that *did* distribute other people's copyleft software, every lawyer we dealt with said that the maximum the licence demanded was a tarball from my upstream, and a diff that could be applied with my changes to get to the modified version we shipped.
So, you can dance on pins trying to stretch the licence to require my development workflow to be shipped with my modified code, or you can stay clearly within the licence.
Posted Dec 18, 2020 15:40 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
And, as an aside while you're thinking about where stretching this goes, my preferred form for modification of code is downloaded to the filesystem of a fast machine with a decent 32" monitor attached and an editor set up to my preferences. I use that for every modification I make, including the ones I have that are in the upstream Linux kernel.
A VCS is entirely optional for modifying code, given a decent editor with good undo facilities and auto-commenting of lines. It makes it much, much easier to share my modifications with people, and to track what is the code I got from upstream versus what I've modified, but I do not use the VCS as part of actually modifying the code. In contrast, I do use the fast computer, the editor, and the monitor as part of actually modifying code - I've never made a kernel modification without a monitor and an editor of my choice.
Posted Dec 18, 2020 17:38 UTC (Fri)
by paulj (subscriber, #341)
[Link] (1 responses)
If monitors were specific to software source code, and you needed a very specific monitor unique to a code-base in order to modify it, and it was typical in software for proprietary vendors of code-base to sell such monitors along with source-code; and if someone created a copyleft licence that required all the tools to be passed along to those the redistributed the code to; then yes... maybe you could require people to supply monitors.
However, in this world, the hardware is usually general, and the general hardware is usually not supplied. So, that's a super-hypothetical world.
The GPLv3 does require the tools - other than general-purpose - to be supplied as part of the source code.
Posted Dec 18, 2020 17:57 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
But the VCS is also a general purpose tool, like a monitor, and when it comes to modifying code (e.g. to add support for a new printer type), I have no interest in what's in the VCS, whereas I do have a deep interest in having decent tools for actually making my changes. Indeed, if you give me the choice between my current monitor and a distribution tarball of the code, or a monitor half the area (a 22" or so) and full VCS history for a project I want to modify, I'll take the tarball and my current monitor every single time.
While I don't work at Red Hat, I suspect the same is true of their engineers too - full VCS history is nice, but good tools are far more important if you're modifying the code.
Posted Dec 18, 2020 12:16 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
And note that the ideal form for identifying their bug so I can fix it is not just the full revision history, but also full access to all the people involved in writing the changes so that I can talk to them about what they did, why they did it, and what the interactions with other changes are.
Taking your interpretation at face value, I could argue that because that's my preferred form of the code for fixing bugs, I have a right to your time if you distribute code to me (directly or indirectly). The GPL limits it to my preferred form for making modifications, and when I'm modifying code, I do that via a working copy and an editor, not via a VCS of some form.
Posted Dec 18, 2020 11:29 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
The `make dist` tarballs. That gets me something that's close to what I'm actually using to start from, and has handled a lot of the details of whatever build system the project uses already - so there's less work for me in getting to the point where I can build their code and run with it.
This changes if I want to contribute the fix back, but it's the desire to contribute that pushes me to the extra hassle of the git tree, not details of how I'd fix the problem.
Posted Dec 14, 2020 23:58 UTC (Mon)
by nknight (subscriber, #71864)
[Link] (7 responses)
Posted Dec 15, 2020 0:54 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
Posted Dec 15, 2020 8:04 UTC (Tue)
by nknight (subscriber, #71864)
[Link] (2 responses)
If Red Hat can't get their developers not to shove client names into commit messages (seriously? this would get you *immediately* escorted off the premises at many companies with sensitive clientele), well, just another reason not to trust them.
Posted Dec 15, 2020 10:01 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Dec 15, 2020 23:51 UTC (Tue)
by nknight (subscriber, #71864)
[Link]
A source tree of the Linux kernel of such importance is going to be seen by a *lot* of people over time, not all of whom are going to be vetted or trustworthy. If this were the concern, Red Hat would have much deeper problems.
Posted Dec 15, 2020 11:08 UTC (Tue)
by paulj (subscriber, #341)
[Link] (2 responses)
They'd have to remove that information, in whatever way.
Posted Dec 15, 2020 23:17 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Dec 18, 2020 0:04 UTC (Fri)
by daniel (guest, #3181)
[Link]
Posted Dec 13, 2020 14:15 UTC (Sun)
by pizza (subscriber, #46)
[Link] (36 responses)
Come on.
Oracle's sales strategy in this case could be best summed up as "We're selling Red Hat's stuff for cheaper than Red Hat sells it."
Which they could easily do because they were relying on Red Hat to perform all of the actual development/engineering work.
(Yes, Oracle's strategy is a bit more nuanced than this, but at the end of they day, they take RHEL, rebuild it, and sell support packages along with "value add" like better integration with Oracle's other offerings.)
Posted Dec 13, 2020 16:09 UTC (Sun)
by johannbg (guest, #65743)
[Link] (35 responses)
Anyway the big irony in Red Hat's management deciding to solve a broken sales strategy by obfuscation their source code and expecting that competing company would change its business practice ( Yeah like Larry "lawnmower" Ellis would suddenly grow a conscience ) as a result of that, is that Red Hat's entire business model is built around taking advantage of the openness of thousands of Free Software developers.
Does Red Hat contribute back to communities yes but does it contribute back in a reasonable proportion with the profit it makes profiting of the open source community and it's contributors well that is an material for an entire news article *wink* *wink* *nudge* *nudge*
Posted Dec 15, 2020 14:45 UTC (Tue)
by paulj (subscriber, #341)
[Link] (34 responses)
There are many companies at this, by various means. Some directly exploitative, taking free software of others and selling it with improvements they do not release back (or release only with great delay), and/or even with portions they will never release the code for. Others indirectly exploitative, by taking free software of others and profiting from it but - as you point at - largely not contributing back with support (employment, say) for those who supplied them with the software.
I think we need next-generation copyleft licences, to address this. Licenses that give users their freedom, but that also empower the actual authors of Free Software and shield the authors better from the parasitical tendencies of corporations - which the current GPL allows.
Posted Dec 15, 2020 17:52 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (32 responses)
Those are violations of the GPL, and thus tortious (or even criminal) conduct for which the exploiter can be pursued by the copyright holder in a court of law.
(Yes, this is expensive. No, that expensiveness is not something that can be remedied by redrafting the licence on your software. Fixing that requires the assistance of legislators, not just lawyers.)
Posted Dec 15, 2020 19:09 UTC (Tue)
by paulj (subscriber, #341)
[Link] (31 responses)
There is at least one company who a) I know has improvements to software I have helped write; b) State they discharge their GPL obligations by giving the source to their customers with their binaries (i.e., they do not avail of the "offer to any 3rd party" clause in the GPL); d) Yet we never ever could get these improvements. I don't want to go into too much detail, but I strongly suspect side-contracts must be in place that penalise any of their customers if they publish or further distribute these changes to the GPL software.
Another example is the rise of large "cloud" companies, which are not in the business of distributing software. They are massive users of Free Software, and they often make fixes and improvements to that Free Software - but they are under no obligation to give those changes back, as they do not distribute. Some are good, and give back; others view these changes as a competitive advantage and are secretive even about what changes they made - never mind giving the changes back!
I would like a copyleft that completely barred private discharge of the source obligation to solve the first issue, and the second issue seems to me like it could only be fixed with some kind of clause requiring that modifications be made public, based on some reasonable condition to avoid requiring every speculative or dead-end change to have to be made public. E.g., perhaps require that any modifications that are put into use be made available publicly, always.
As for addressing expense, from talking to legal types, I think there may be non-legislative changes to licence text that could be made to make it easier to take action against violaters. E.g., in a number of jurisdictions one can only claim for demonstrable damages, so a licence that explicitly specified a monetary cost for use outwith the copyleft terms (e.g., X% of revenue of any controlling entity of the violator?) could make the licence easier to enforce. This could be done with a meta-licence, I guess - but it would be more universal and less hassle/confusing for developers if it was specified in the same licence.
Posted Dec 15, 2020 20:50 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (30 responses)
Note that their claim (b) - if true - IS a full and complete discharge of their responsibilities. The GPL does NOT entitle random 3rd parties (including other copyright holders) to request copies of other peoples' source.
It entitles CUSTOMERS to receive a copy of the source. If that copy is not provided when customers receive the binary it is *then* that the "random 3rd party" rule kicks in on the assumption that the original customer may have further distributed the binaries.
And you could well be right with your suspicions in (d), but I suspect that is a breach of neither the letter nor the spirit of the GPL :-(
Cheers,
Posted Dec 15, 2020 22:35 UTC (Tue)
by paulj (subscriber, #341)
[Link] (24 responses)
I think by banning wholly private discharge of the source code distribution obligation. I.e., I would want a licence that obliges the GPL licensee to make the source available to all, if to any, always.
Posted Dec 15, 2020 23:31 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (19 responses)
Which is COMPLETELY AGAINST the spirit of the GPL.
The whole point of the GPL is to protect *users* against an *abusive upstream*. You are said upstream. The GPL is there to protect your users *against you*. Sorry.
Cheers,
Posted Dec 16, 2020 0:05 UTC (Wed)
by paulj (subscriber, #341)
[Link] (18 responses)
The GPL does not exist to allow parasitic corporations to exploit Free Software developers, taking their code and making money of it with effectively-proprietary modifications to their customers, restricting the distribution of those modifications through side-contracts.
If you think those corporations need protecting, we're just going to have fundamentally disagree. And I think you're no friend of Free Software.
Posted Dec 16, 2020 0:26 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (17 responses)
You clearly don't understand what the Free Software Foundation thinks is "Free Software", nor what is the intent of the GPL.
The GPL has NEVER been a "friend of the software developer" - if that's what you want you need the BSD licence.
I repeat - that corporation is your *downstream* *user*. The GPL is there to protect *downstream*!
Cheers,
Posted Dec 16, 2020 10:32 UTC (Wed)
by paulj (subscriber, #341)
[Link] (16 responses)
I really do not care about the interests of such parasites, and I'd like to find a copyleft licence that discourages such parasites, to the benefit of the rest of the community.
And I don't see a problem with a copyleft licence protecting the interests of Free Software developers, as long as it still protects the freedom of users.
Posted Dec 16, 2020 11:57 UTC (Wed)
by pizza (subscriber, #46)
[Link] (13 responses)
As Wol pointed out, "parasitic corporations" are still "users", so what you are saying is that "I want some uses/users to have more rights/freedoms than others".
Posted Dec 16, 2020 12:16 UTC (Wed)
by paulj (subscriber, #341)
[Link] (12 responses)
The GPL already excludes users who want to keep modifications they distribute to others proprietary. The problem is that some corporates have found a way to /effectively/ keep their modifications proprietary, while (arguably) staying technically within the law - by placing their restrictions on /other/ users in side-contracts.
These users are already outside of the spirit of the GPL, as far as I'm concerned. They are taking freedoms away from others. I have no time or sympathy for them. I will be glad to see that loophole closed off in future copyleft licences.
Posted Dec 16, 2020 12:24 UTC (Wed)
by paulj (subscriber, #341)
[Link] (9 responses)
If you're a Free Software developer that things there should be /no/ restriction on freedoms for users, then go and use a BSD licence. You (and your users) won't get the benefits that copyleft can bring. And that's a subjective decision, and that's fine.
Posted Dec 16, 2020 16:41 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (8 responses)
You quite clearly have never bothered to read the GPL properly. The pre-amble states that yes, it does place obligations ON THE DEVELOPERS. The following is taken from clause 0 of the GPLv2
> Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
While this does not explicitly cover the case of some one/thing who is both a downstream and an upstream, I think it is quite clear that the intent of this section (and of the rest of the licence) is to re-iterate the fact that downstream owes NO OBLIGATION WHATSOEVER to upstream. This is the - intentional - reversal of the normal state of affairs where downstream needs permission from upstream to do anything even as little as wiping its nose despite paying through its nose for the privilege...
That's why I said "if you want freedom FOR THE DEVELOPERS you need the BSD licence". The GPL frees your users from any obligation to you. If you don't like it, tough, that's what it is intended to achieve.
Cheers,
Posted Dec 16, 2020 17:13 UTC (Wed)
by paulj (subscriber, #341)
[Link] (7 responses)
The intent of the GPL is to ensure the downstream has all the rights its upstream received. That is, the downstream /must/ be free to be able to distribute the changes onward. And that includes back to the original source!
I.e. the original upstream can *also* be a further-downstream - the benefits of Free Software are intended to extend to the original developer, as much as to any other users. It's a two-way street (but the parasites want to skew that street to themselves). So you are just wrong that the upstream-and-downstream has no obligation to its upstream, for the whole idea of copyleft is that a downstream of that upstream-and-downstream ought to be able to supply the changes back to the original upstream, and hence make the original upstream a downstream of the upstream-and-downstream as well as an upstream.
Copyleft intended to guarantee that freedom for the "downstream", by imposing obligations on the "upstream-and-downstream" intermediary - which reduce the freedom of that "upstream-and-downstream" inter-mediary.
That some think they have a found a way to prevent their downstreams from exercising the rights that the original upstream - the copyright holder - wanted all downstreams to be able to exercise, is a problem that I would like to see fixed.
The BSD isn't useful here to the original upstream. The BSD licence has its uses, but this scenario isn't one of them.
Posted Dec 16, 2020 17:30 UTC (Wed)
by pizza (subscriber, #46)
[Link] (5 responses)
"ought to be able" is not the same as "must"
> That some think they have a found a way to prevent their downstreams from exercising the rights that the original upstream - the copyright holder - wanted all downstreams to be able to exercise, is a problem that I would like to see fixed.
For what it's worth, I agree with you. I just don't think this addressable/fixable from within the scope of a copyright license.
Ultimately this is a question of freedom of association -- "Sure, you're completely free to pass on these modified GPL sources; that's your right. But if you do that, I'll exercise my right to stop doing business with you."
Posted Dec 16, 2020 17:41 UTC (Wed)
by paulj (subscriber, #341)
[Link] (4 responses)
They should just not be able to use it to prevent others from exercising their copyleft rights to distribute. And that can be done easily by just making it a general requirement (with reasonable exceptions to address ability to do R&D in private, desert island residents and dissidents) to make source available, so that it ceases to be a tool to control others with.
In this day of a plethora of places that will host Free Software source for free, it's easy to make code available, and it's reasonable to generally require those who modify Free Software to do so.
Posted Dec 16, 2020 17:54 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
Private contracts are used to place far more onerous conditions on things far more basic and important than copyleft software; what makes software so special here?
For example, as part of my severance package from the last gig, there was an anti-disparagement clause. If I trashed-talked my former employer within a certain period of time, I'd have to return the money they paid me. I was free to say no, and trash my employer all I wanted, but instead I voluntarily entered into a contract that restricted my freedom of speech and used that money to pay off some debts.
Should this "Waiving my rights to X in exchange for certain considerations" sort of contract be made illegal? (if yes, why? If no, how X == free speech materially different from "X == redistribution of copyleft software"?)
Posted Dec 17, 2020 12:26 UTC (Thu)
by paulj (subscriber, #341)
[Link] (1 responses)
The copyright holder can't stop others exercising their freedom of association either.
The copyright holder can however require that the obligation to distribute modifications to the source be broader, such that others can not wield freedom of association as a weapon to restrict copyleft rights.
And if such parasitic companies don't like that, they're still perfectly free to not use that software. The authors are free to choose their licence for their software, and others are free to make their own decisions.
Posted Dec 17, 2020 13:20 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Oh, yes it does; if I make use of or incorporate certain software in my last two jobs, I can be terminated on the spot.
> The copyright holder can't stop others exercising their freedom of association either.
Their attempts to create "ethical licenses" certainly do; under "field of use restrictions"
> The copyright holder can however require that the obligation to distribute modifications to the source be broader, such that others can not wield freedom of association as a weapon to restrict copyleft rights.
The actual "software" has no rights or permissions -- only "persons" do. I (or my employer), as a "person", have the permission granted by the software's author (ie the license) to redistribute that copyleft software. I can chose not to do so for any reason -- Because I don't like you. Because it's Tuesday. Because I promised my mother that I wouldn't. Because I signed a contract with my employer/supplier/whatever to not do so. And so forth.
What you are asking is for the license to unconditionally force/compel folks to redistribute the software to unrelated third parties. There are significant practical and legal problems with that. I'm not saying it's impossible, just that it's going to take a lot of care to draft, and the resulting license will probably see even less use than the AGPL -- Which is already considered so toxic that it's only significant use is as a deliberate poison pill.
Posted Dec 16, 2020 20:24 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
And you are showing your inability to follow a logical argument. If I rely on that company's software (never mind that some of it is your GPL software), I cannot afford for *them* to follow *their* right to freedom of association, and refuse to associate with me.
I have entered into a - supposedly mutual - beneficial arrangement with them, and neither of us wishes to jeopardise it. You are an outsider to that agreements, and by agreeing to the GPL you surrendered any rights you may have had. If you don't like it, it's your right to refuse to associate with the GPL.
It is a fundamental requirement of the free market, that people are not coerced into doing business with people they would rather avoid. This is what's wrong with modern "free market" capitalism, where the big players are free to buy, force out of business, or otherwise destroy their smaller competitors and force customers to do business with them. In this particular case, unfortunately that company does not want to do business with you, and their customers do not want to antagonise them.
YOU SAID the GPL requires you to pass on all the rights you received. But you are objecting to this company exercising those self-same rights that you received and passed on.
Cheers,
Posted Dec 16, 2020 19:21 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
And that includes the freedom NOT to distribute changes back to the original source.
You're arguing with your heart, not your head. And that way leads to disaster ... "The road to hell is paved with good intentions". You've already assumed (from no evidence whatsoever) that I am opposed to what you want. I'm not. Just like many other people here, my head tells me you can't have it. Doesn't mean I don't wish we could :-)
"Man proposes. Nature opposes". What you want is not achievable. Not without tying logic up in a granny knot and bashing it over the head with a rolling pin.
Cheers,
Posted Dec 16, 2020 16:27 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
So you want to discriminate between users - which is FORBIDDEN by the *concept* of copyleft. You won't - can't - find a copyleft licence that agrees with you. (Oh - and as I pointed out - the GPLv3 not only did not attempt to close that loophole, it quite deliberately opened it even wider!)
And those same users you have no sympathy for includes a LOT of hardware vendors - if you hadn't noticed, a lot of kernel developers feel similarly to you. The *problem* is that, as soon as you have the sort of licence *you* desire, the practical consequence will be that linux is sidelined and becomes completely irrelevant.
Sadly, sometimes practicality has to trump idealism, or the idealists will become irrelevant sighing winds in the desert :-(
Cheers,
Posted Dec 16, 2020 16:53 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Some users think they've found a loophole, that is against the spirit of the GPL and copyleft. (And I completely disagree with you that the spirit of copyleft /intentionally/ allows for corporates to restrict re-distribution of modifications by their downstreams - that's absurd, the entire point of copyleft is to ensure the recipients get the right to distribute!).
I don't get your point about hardware vendors. If you mean the likes of graphics vendors with closed blobs, they may well be in direct violation of the GPL already - that's not the case I'm talking about.
I sense I'm down a rabbit hole with you.
Posted Dec 16, 2020 13:04 UTC (Wed)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Dec 16, 2020 13:23 UTC (Wed)
by paulj (subscriber, #341)
[Link]
So I'd be happy to exempt natural persons from some obligations designed to tackle an issue that manifests itself mostly with corporations. If a reasonable balance of obligations and wording can be found that doesn't need to distinguish between natural persons and other bodies, that's fine too.
Posted Dec 16, 2020 1:08 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (3 responses)
Posted Dec 16, 2020 1:31 UTC (Wed)
by bkuhn (subscriber, #58642)
[Link]
The issue of mandatory upstream distribution of source changes to copylefted software has been a hotly debated topic since I first got involved in copyleft licensing policy and drafting in the late 1990s. The two primary positions within this debate have been outlined well already in this thread. I think most copyleft theorists believe that modifiers (modulo the danger situations with dissidents that pabs identified) have a moral obligation to make generally useful improvements available to the general public. The problem, and this goes back to the points pabs raised, is how to draft policy that respects the privacy rights of some types of modifications while assuring that truly generally useful changes that the world deserves, morally speaking, can be codified into a copyleft license.
Much of this debate reminds me more recently of the so-called “Ethical License” initiatives. In those initiatives, its proponents argue that since there are immoral things done by companies with software (such as helping USA's ICE lock children up in cages) that the licenses are not ethical if they don't prevent that.
The flaw in the logic is the idea that every moral and social problem that relates to software can be fixed with its license. Having spent years enforcing copyleft licenses and drafting them, I've concluded that you have to be selective how you use the tool of copyleft. And, it's not that I'm just critical of new ideas: I'd argue that GPLv2§2(a) is a great example of a well-intentioned clause meaning to get to a good policy outcome that is just annoying to comply with in practice. We should all comply with it because it's required, but I would never include that clause or one like it again in a future copyleft license.
Similarly, when I hear people clamoring for features for copyleft licenses, I worry about future-proofing. It's hard to do. Anyway, I encourage anyone who wants to talk about real-world drafting of copyleft to join the copyleft-next project.
Posted Dec 16, 2020 10:38 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
The obligation to distribute generally could be to the greatest extent reasonable, subject to any external restrictions on distribution. So the desert island denizen, as long as they make available to anyone else on the island, would be fine.
The dissident can be protected by exempting any person (not corporation) from the obligation, where doing so would put lives at risk of oppression.
Posted Dec 16, 2020 13:05 UTC (Wed)
by mpr22 (subscriber, #60784)
[Link]
Posted Dec 16, 2020 0:20 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (4 responses)
Actually, version 3 of the GPL makes this intent even clearer - the wording of v2 effectively made the vendor *force* the source onto the user. Under v3, if the vendor merely makes the source *available* (by, for example, providing a download link) it stops the "random 3rd party" rule from kicking in.
In other words, if I point my users at a *private* *intranet* site, so long as they have access to said private site at the time I supply the binaries, then I can pull that source download site AT ANY TIME.
Cheers,
Posted Dec 25, 2020 19:12 UTC (Fri)
by sammythesnake (guest, #17693)
[Link] (3 responses)
Three years might be an interminable age or a blink of the eye depending on the circumstances, though.
Posted Dec 25, 2020 20:01 UTC (Fri)
by sfeam (subscriber, #2841)
[Link]
Posted Dec 27, 2020 1:13 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
In other words, you must comply with clause 6, but you can choose between (a) or (b) (or (c) or (d) or whatever).
Cheers,
Posted Dec 27, 2020 1:16 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Comply with (a) OR (b) OR (c) OR (d) OR (e).
Your choice - if you want to ignore 6(b) that's perfectly fine so long as you comply with one of the others.
Sheesh - talk about people not being able to understand plain simple English ... (or American :-)
Cheers,
Posted Dec 15, 2020 20:48 UTC (Tue)
by joib (subscriber, #8541)
[Link]
> There are many companies at this, by various means. Some directly exploitative, taking free software of others and selling it with improvements they do not release back (or release only with great delay), and/or even with portions they will never release the code for. Others indirectly exploitative, by taking free software of others and profiting from it but - as you point at - largely not contributing back with support (employment, say) for those who supplied them with the software.
There are, of course, licenses which provide monetary compensation to the developers, but those are called proprietary, not open source. The universe is, for better or worse, under no obligation to give money to you or me as a reward for writing free software.
> I think we need next-generation copyleft licences, to address this. Licenses that give users their freedom, but that also empower the actual authors of Free Software and shield the authors better from the parasitical tendencies of corporations - which the current GPL allows.
In a way, I completely agree with that. GPLv3 is in many ways fine, but doesn't go nearly far enough to protect e.g. against service providers. But it also seems to me a quixotic quest. GPLv3, modest improvement to GPLv2 as it was, already caused a schism in the GPL-using community, many of which explicitly chose to stay with GPLv2-only. Not to mention AGPL, which is regarded as outright poison by many. And a hypothetical GPLv4 which would close the "service provide loophole", would probably look like an even stronger version of AGPLv3. I think very few would jump on that train.
The other approach is maybe to take a step back and think about what we're actually trying to achieve, and whether there are other more fruitful avenues to get what we want. If we want devices that we own, and can tinker with, maybe pushing for Right to Repair type legislation, including the ability to boot our own code instead of the manufacturer signed one? And push for open specified protocols, so we can replace the original manufacturer black box software with our own?
But those are more legal or political changes. Getting out in the street protesting, lobbying etc. is certainly uncomfortable, but OTOH maybe the alternative idea of enacting social change by coding away in our basements was always an impossible dream anyway.
Posted Dec 14, 2020 7:45 UTC (Mon)
by nknight (subscriber, #71864)
[Link] (9 responses)
Good news for Red Hat is they can just shut down CentOS outright in five years. Nobody will care anymore.
Posted Dec 14, 2020 12:42 UTC (Mon)
by pizza (subscriber, #46)
[Link] (8 responses)
You keep repeating this, but that doesn't make it true.
Again, what promise has Red Hat broken *to its paying customers*? And how exactly did they "personally" break them?
(Because "Broken promises" to "paying customers" is also known as a "breach of contract" which is legally actionable)
> How long do you really think it will be before we pull a MariaDB and not just rebuild but outright fork and take the community with us?
MariaDB was a *developer* revolt; in other words, those who were doing most of the work left, and continued doing the work under a new umbrella. The general userbase followed because Oracle (yes, that same Oracle that is being held up as the Savior of CentOS users) largely let MySQL wither on the vine.
Meanwhile, you want to Fork CentOS? That's easy! Just figure out a source of sustained funding to pay a bunch of full-time engineers to maintain and develop things that no volunteer would ever choose to do on their own (plus pay for obscene amounts of bandwidth) and convince the general userbase that being incompatible with RHEL is okay.
Posted Dec 14, 2020 23:57 UTC (Mon)
by nknight (subscriber, #71864)
[Link] (7 responses)
Fool me thrice...
Posted Dec 15, 2020 2:38 UTC (Tue)
by pizza (subscriber, #46)
[Link] (6 responses)
But you still haven't provided an example of one of a "broken promise" Red Hat that made made "personally" and "explicitly" to one of their paying customers.
Posted Dec 15, 2020 7:54 UTC (Tue)
by nknight (subscriber, #71864)
[Link] (5 responses)
Posted Dec 15, 2020 14:14 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
(...Or have you not actually asked?)
Posted Dec 15, 2020 23:56 UTC (Tue)
by nknight (subscriber, #71864)
[Link] (3 responses)
Posted Dec 16, 2020 0:17 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
Nope. But... that's not a broken promise. That's not having any good answers.
Posted Dec 16, 2020 1:12 UTC (Wed)
by nknight (subscriber, #71864)
[Link]
Posted Dec 16, 2020 1:15 UTC (Wed)
by nknight (subscriber, #71864)
[Link]
https://blog.centos.org/2019/07/ibm-red-hat-and-centos/
"Our mission, governance, and objectives remain the same. We will continue to execute the existing project roadmap. Red Hat associates will continue to contribute to the upstream in the same ways they have been. And, as always, we will continue to help upstream projects be successful and contribute to welcoming new members and maintaining the project.
We will do this together, with the community, as we always have."
Posted Dec 13, 2020 18:31 UTC (Sun)
by LightDot (guest, #73140)
[Link] (2 responses)
Posted Dec 16, 2020 5:44 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
It does look that way, but.. I think it's actually more nuanced than that. If you go back to the original "Red Hat is acqu-hiring CentOS" announcements and press releases from early 2014, they laid out a long-term vision that looks pretty darn close to the new/currentFedora -> ELN -> CentOS Stream -> RHEL tiered development model that Red Hat has embraced.
It is not debatable that CentOS was in bad shape prior to Red Hat (effectively) taking it over. While it's highly likely that if not Red Hat, someone else would have come along, it's not debatable that CentOS was not sustainable in its former form, and it's also not disputable that under Red Hat's "ownership" CentOS has flourished, and with everyone -- including RHEL, CentOS, all the other "RHEL clones" and their end-users -- heavily benefiting. RHEL has gone from being developed entirely behind closed doors to fully in the open, with open tooling that any sufficiently motivated third party can deploy to generate their own rebuilds. This represents a huge leap beyond what RHEL and CentOS were using previously. External entities/communities can actually meaningfully participate in development of new features instead of simply accepting/rebuilding whatever Red Hat threw over the wall every six months. Indeed, if folks are so inclined, they can actually ship stuff before it ends up in a Red Hat release! Sure, Red Hat dominates the new process just as they were before, but they were (and still are) doing the vast majority of the actual engineering and QA work; of course they're going to put that into what they consider to be most relevant for their overall business needs.
It took an entire RHEL release cycle to implement that original vision and build the open tooling to support it. RHEL/CentOS8 is the result, and they're now moving to the next phase of what they said they were intending to do nearly seven years ago. So sure, the Embrace and Extend bits are there, but have they actually Extinguished anything?
Sure, the discontinuing of the classic CentOS model is disappointing -- but nothing lasts forever. I think the real question is: Are folks are better off now than they were in 2014? It's hard to argue that they are not; at worst it's about the same,with folks wanting a "Free RHEL rebuild" having to step up and volunteer their time/money to make it happen in a sustainable manner, something that they were failing to do in the pre-RH CentOS days. But, thanks to all of the tooling and process improvements that Red Hat paid for, the amount of sheer thankless drudgery that is needed to produce a modern RHEL-clone/rebuild (eg Oracle Linux, ClearLinux, and RockyLinux, and whatever else comes along) has been vastly reduced.
But all that said, all of those rebuilders will still be following Red Hat's coat tails, because at the end of the day, Red Hat continues to invest more into RHEL (and by proxy, all of its clones) than everyone else combined, probably by a factor of 2-3x. This is why I feel that ClearLinux (or whatever) isn't going to make RHEL irrelevant -- RH is only in its dominant position because it invests so much (into all of the various ecosystems' upstreams, not just RHEL itself) -- In other words, it's not because of any inherent superiority of RH or RHEL, but because RH is undertaking (and/or underwriting) such a large proportion of the overall effort.
In order for someone else to rise to that level of prominence, they have to out-invest Red Hat. Which requires a pretty large chunk of sustained funding, to the tune of literally hundreds of millions of dollars a year. I laud ClearLinux for their $1M pledge, but it is simply delusional to think that level of investment will somehow render RHEL (and by proxy, RH) "irrelevant".
> I'd say that the majority of the damage is caused by drastically changing the CentOS 8 as-we-know-it EOL.
Yeah, I agree. If the shortened CentOS-as-we-know-it EOL was actually the intent all along (and to be honest, it does seem that way based on the historical record) then this is really a textbook case of one hand not knowing what the other hand was intending.
Posted Dec 16, 2020 11:20 UTC (Wed)
by amacater (subscriber, #790)
[Link]
Colleagues suggested - "well, we can just move to Amazon Linux - it's free" but https://aws.amazon.com/amazon-linux-2/faqs/ suggests that the only Linux currently is in the form of virtual machines if you want to run Amazon Linux on premises and there is no support. Out of the frying pan into the fire.
The new AWS Graviton 64 bit ARM instances are probably not running CentOS. Is there anybody with an authoritative viewpoint on this?
We already know from comments further up the stack that FB are apparently using CentOS Streams. Enquiring minds would like to know.
Posted Dec 11, 2020 11:16 UTC (Fri)
by joib (subscriber, #8541)
[Link] (3 responses)
Posted Dec 11, 2020 18:34 UTC (Fri)
by AdamW (subscriber, #48457)
[Link] (2 responses)
Posted Dec 13, 2020 5:08 UTC (Sun)
by bojan (subscriber, #14302)
[Link] (1 responses)
Posted Dec 14, 2020 23:35 UTC (Mon)
by rgmoore (✭ supporter ✭, #75)
[Link]
More important, it works seamlessly. If I hadn't read it here, I never would have known there was a change. That's the goal: the only thing users notice is fewer problems.
Posted Dec 10, 2020 20:23 UTC (Thu)
by maniax (subscriber, #4509)
[Link] (2 responses)
So most hosting providers have been using CentOS mostly because they don't have to upgrade for ~8 years (which wasn't the case with Debian), and they'd get also backports of fixes and features (the diff size for the CentOS/RHEL kernels is insane, and I don't think it's the only package that gets such treatment).
So there's a definite market for stuff that works and gets updates and doesn't really change (and it's not a small one). As someone affected, I really want a crystal ball right now...
Posted Dec 11, 2020 12:04 UTC (Fri)
by lsl (subscriber, #86508)
[Link] (1 responses)
If Stream turns out to work well enough to e.g. run OpenStack/RDO on top of it and not have to deal with regular issues due to delayed/missing packages in CentOS or similar things, then this change might turn out to be a win for this use case.
Sure, to profit the most from this arrangement you probably want to engage with the relevant communities. But arguably, you're going to want to do this anyway when running something like this.
Posted Dec 12, 2020 18:22 UTC (Sat)
by LightDot (guest, #73140)
[Link]
Ending CentOS as it once was would be less of an impact if CentOS Stream 8 would be kept alive for the full lifetime of the RHEL 8, not just for the first 5 years.
Posted Dec 10, 2020 22:00 UTC (Thu)
by philipstorry (subscriber, #45926)
[Link] (3 responses)
Such systems still exist, but it is increasingly common to just order up new virtual machines when there is a job to be done, and to discard them when they are no longer useful. The value offered by long-term-stable distributions in this new world is less clear. Obviously, I'm wanting to use the various cloud and container solutions, if only to keep my skillset current. Spinning up a new machine (either on local ESX infrastructure or on a cloud platform) for transient work and short term projects is very useful. I do it for both Linux and Windows machines, depending on project requirements. But my company still has a PBX, a call logging system, an asset management system, assorted network infrastructure (SMTP relay, nagios) and more. These things run the company, and need to be persistent due to availability or data permanence requirements. The applications that we use are still built to assume a persistent server underneath them. Maybe that'll change over time. But I suspect not - it's easier the developers of such solutions to keep assuming you'll install a local MariaDB/PostgreSQL instance than to lock themselves into a specific cloud platform. So I think there will still be plenty of demand for LTS distributions. They're not sexy, they don't get as much noise made about them - but they're what most people in business will reach for when they need a distro.
Posted Dec 11, 2020 7:36 UTC (Fri)
by kleptog (subscriber, #1183)
[Link]
Even so, there is a trend the see these as cattle, not pets. If you want to upgrade your PBX, do you run an upgrade script or install a new server with the new version? The latter is more logical if you want to have a test setup somewhere to test the new configuration beforehand. Upgrade scripts are not repeatable, reinstalls are. Yet these servers are full of software that needs regular security updates.
And if you're rebuilding these servers each upgrade anyway, upgrading to a new release of the distribution just isn't that exciting any more. Change the release name at the beginning of the install script, run it a few times to deal with package name changes and you're done. Sure, you don't want to do it too often, but the difference between 10 years and 3 years is marginal. In fact, if you wait 10 years, chances are everyone has forgotten how it works.
Put the scripts under revision control and suddenly you know why setting X is the way it, because three years ago Pete used it to work around some bug.
Posted Dec 11, 2020 8:28 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Dec 12, 2020 10:45 UTC (Sat)
by ringerc (subscriber, #3071)
[Link]
This can be incredibly effective for some applications and workloads.
Posted Dec 11, 2020 5:26 UTC (Fri)
by alison (subscriber, #63752)
[Link] (6 responses)
I always believed that the purpose of Fedora was to drive out bugs in future RHEL packages. Obviously there are other differences between RHEL and Fedora, but why does RHEL want to have both? Maybe Fedora is just a desktop "spin" of CentOS Stream that builds for more arches? Will the next announcement from RH reveal that CentOS Stream is a rolling release of Fedora?
Posted Dec 11, 2020 6:57 UTC (Fri)
by mebrown (subscriber, #7960)
[Link] (3 responses)
Posted Dec 11, 2020 8:45 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
Posted Dec 11, 2020 12:50 UTC (Fri)
by kashyap (guest, #55821)
[Link] (1 responses)
I was pointed out that the "ELN"[1] part in the above comment isn't quite right. But the rest sounds fairly accurate. (Documentation of Fedora ELN: https://docs.fedoraproject.org/en-US/eln/)
PS: /me is a Red Hatter, but speaking for myself, of course.
Posted Dec 11, 2020 13:31 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
For clarity, I am not a Red Hatter, but I do follow the fedora-devel mailing list; my description of ELN is based on what I've understood from mailing list posts. The Fedora documentation is more likely to be right than I am!
Posted Dec 11, 2020 7:33 UTC (Fri)
by re:fi.64 (subscriber, #132628)
[Link] (1 responses)
Stream is essentially a complete snapshot of a future RHEL release, as in, a future RHEL will likely be identical to a former Stream, including minor releases. In contrast, Fedora is essentially a different distribution that also happens to be a distant base for RHEL; a Fedora version is snapshotted and heavily modified to become a major release, that major release is modified in place.
If the distros were wooden furniture, RHEL would be a finished desk, Stream would be the unpainted and unsanded desk, and Fedora would be the tree.
Posted Dec 11, 2020 21:49 UTC (Fri)
by mmcgrath (guest, #44906)
[Link]
Posted Dec 11, 2020 7:37 UTC (Fri)
by re:fi.64 (subscriber, #132628)
[Link] (7 responses)
Posted Dec 11, 2020 18:11 UTC (Fri)
by mcatanzaro (subscriber, #93033)
[Link] (6 responses)
Fedora: moves very quickly, changes now show up in RHEL 9
CentOS Stream: rolling, yes, but very slow rolling, where everything is going out to paying customers soon; changes now show up in RHEL 8.4
Posted Dec 12, 2020 15:36 UTC (Sat)
by mstone_ (subscriber, #66309)
[Link] (1 responses)
Posted Dec 12, 2020 20:57 UTC (Sat)
by lsl (subscriber, #86508)
[Link]
Other than that, I guess it's a matter of preference. Do you prefer to deal with lots of new packages dumped onto you every six months or have a continuous trickle of smaller updates? It really depends on your usage and update patterns. Of those models, Red Hat appears willing to fund one but not the other. That sucks if you prefer the point-release model, sure.
Still, the CentOS project itself always had its issues dealing with those big SRPM dumps, leading to delays and causing pain for other projects building something on top of CentOS. If the continuous release model's better funding story makes more resources available to the project it might be the better and healthier choice for the CentOS project overall.
Doing both models isn't really an option without a lot more outside contributors willing to stem the load. That's probably the only way for CentOS to stop being at the mercy of today's particular itches as perceived by RH management.
Posted Dec 13, 2020 15:38 UTC (Sun)
by mroche (subscriber, #137163)
[Link] (3 responses)
This technically isn’t true with OpenShift 4. OKD and OCP are sibling distributions of the project, based off of the same code. The main, major difference between the two is one uses RHCOS and the other FCOS. Those two projects are relatively unrelated.
Posted Dec 13, 2020 16:09 UTC (Sun)
by mcatanzaro (subscriber, #93033)
[Link] (2 responses)
Posted Dec 13, 2020 16:44 UTC (Sun)
by mroche (subscriber, #137163)
[Link] (1 responses)
Formerly the Origin project used to be the “core”, but OpenShift is now comprised of an amalgamation of repositories rather than one monorepo. Repos for operators, the installer, CI workflows, etc.
There is also the OKD specific repo which is for reporting OKD issues and where you can find the installers to deploy it. Openshift is more of an image stream (not to be confused with ImageStreams) than standard software deployment now that it utilizes CoreOS.
Posted Dec 15, 2020 22:26 UTC (Tue)
by Jligon (guest, #120386)
[Link]
FCOS and RHCOS are both ostree based linux distros related by build tools and testing, using CoreOS Assembler and kola. Same teams work on both of them. FCOS uses Fedora repos as sources, and RHCOS uses RHEL content.
Posted Dec 11, 2020 7:46 UTC (Fri)
by Otus (subscriber, #67685)
[Link]
When it was a case of a few big servers, it was at least possible to upgrade them every two years or whatever. Try doing that with dozens of smaller instances.
Sure, you can automate it, but a major reason to isolate everything in its own VM or container in the first place is to avoid breakage when making changes to other components. You don't want to have to break and fix each of them very often for major OS upgrades.
Posted Dec 11, 2020 9:35 UTC (Fri)
by sluna (subscriber, #109644)
[Link] (2 responses)
IMHO Red Hat get an incredible amount of feedback and testing out of CentOS (e.g. via https://bugzilla.redhat.com/). Is it correct to say that RHEL8 wasn't production-ready until CentOS8 was seriously tested by the community?
> There is a lot of talk about creating a new community-based, CentOS-like project to rebuild RHEL as before. These efforts might succeed, but it is worth remembering how CentOS struggled before it got proper financial support. Creating this kind of distribution involves a lot of tedious, detailed work, and volunteers to do that work will still be hard to find.
True. However, we don't know until we try. Those of you interested, please head over to https://rockylinux.org/
> An alternative that some may consider is to give up on the idea of an "enterprise" distribution altogether. These distributions were created in an era when one would buy an actual, physical computer, deploy it somewhere, and expect it to do its job for years. Such systems still exist, but it is increasingly common to just order up new virtual machines when there is a job to be done, and to discard them when they are no longer useful. The value offered by long-term-stable distributions in this new world is less clear. Many systems that are deployed on CentOS might actually be better off using distributions with near-mainline kernels and more current software.
In my view, those virtual machines might well be running on top of "enterprise" distributions like CentOS, so there is still a need for it.
Posted Dec 11, 2020 15:23 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (1 responses)
As a general comment from someone not related to Red Hat, but dabbling as a FOSS author for more than 20 years now: Having users test out your stuff is not the panacea you'd think it is. You don't want bug reports—what you want is bugfixes. Getting bug reports mostly means you need to consider and/or fix issues that none of your paying customers (or, for a smaller project, yourself) are seeing and/or care about. In any larger project, there are so many bugs of different kinds and severities that you're not likely to be able to weed out all of them anyway.
Posted Dec 14, 2020 18:53 UTC (Mon)
by bfields (subscriber, #19510)
[Link]
There's some truth to that, but fortunately my experience has been very positive. First, I haven't find it that hard to minimize the time spent on upstream reports that aren't interesting. That probably varies a lot depending on the project--more popular and user-exposed projects probably require more triage.
Second, some upstream bug reports have been very useful. Either they've caught things early, or hit on a reproducer for a serious but rare crash, or just invested a lot of work in investigating the problem. In the upstream NFS world we've been lucky to have some really outstanding bug reporters.
Posted Dec 11, 2020 15:46 UTC (Fri)
by psadauskas (subscriber, #46534)
[Link] (1 responses)
But, the process to create an account, and then figure out how to download an ISO, was far, far harder than it needed to be. And then, once I got it installed, I could never figure out how to satisfy the license management CLI tool that would allow me to install any packages. After a couple hours, I gave up.
They’ll never do this (because IBM), but I would be far more likely to get my toes wet in the RHEL ecosystem if they had an easy-to-obtain “community supported” version of RHEL. I already use Fedora for my desktop, so would prefer to stick with an RPM distro for my home server(s), but I understand I’m not their target market. I get the feeling they don’t even want to bother talking to you unless you’re gonna spend $10k/mo on their services.
Posted Dec 11, 2020 21:50 UTC (Fri)
by mmcgrath (guest, #44906)
[Link]
Posted Dec 11, 2020 22:09 UTC (Fri)
by BirAdam (guest, #132170)
[Link] (1 responses)
Posted Dec 18, 2020 1:59 UTC (Fri)
by daniel (guest, #3181)
[Link]
Posted Dec 11, 2020 22:14 UTC (Fri)
by martin.langhoff (subscriber, #61417)
[Link] (5 responses)
And what it has become is essentially Debian's updates-testing. And that is _not_ a bad thing at all. I ran Debian exclusively for 10+ years, and updates-testing was what I tracked. Official RHEL is essentially a couple-weeks-old CentOS minus any updates marked buggy or downvoted in Koji.
With the Fedora, Fedora ELN and CentOS Stream, RH has now a fully open, fully transparent process for RHEL. That took... 15 years(?). Each change, while upsetting to some, was a change towards more transparency, more clarity. The RHEL of yore was built inhouse, with proprietary tooling - this affected key packages (ie: kernel) as well as the distro compose.
So early CentOS was really horrid to create -- and not really a reliable clone of RHEL -- because CentOS devs had to kludge a lot of stuff that was RH internal. Same with early Fedora -- we lived that at OLPC. To their credit, Fedora/RH folks worked to replace their build infra with fully public tools and infra.
Today, from soup to nuts, Rawhide, Fedora and CentOS are fully transparent. At the very end of the pipe, RH corporate sneaks in some logos, and makes some money to pay developers and yes, does provide a more stable, more reliable, certified, certifiable(!), build. This is a good endgame.
Posted Dec 12, 2020 3:12 UTC (Sat)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Dec 12, 2020 18:44 UTC (Sat)
by martin.langhoff (subscriber, #61417)
[Link] (1 responses)
If you want to make your own stable-er CentOS Stream, you can replicate the package selection. Make a repo tracking CentOS Stream updates, put rules so that you only pick packages that meet your criteria - some age, no koji downvotes, maybe fast track anything with a CVE in the changelog...
Posted Dec 12, 2020 20:03 UTC (Sat)
by LightDot (guest, #73140)
[Link]
Posted Dec 13, 2020 5:29 UTC (Sun)
by Otus (subscriber, #67685)
[Link] (1 responses)
Not only is that a shorter time, but it is unpredictable.
(I get that that's what they want to sell, but it was the main "selling point" of CentOS over other distros IMO.)
Posted Dec 26, 2020 4:10 UTC (Sat)
by imgx64 (guest, #78590)
[Link]
Posted Dec 13, 2020 9:26 UTC (Sun)
by jorgegv (subscriber, #60484)
[Link]
The result: production systems using VDO, rendered nonworking, and non trivial rollback. I have been bitten myself by this one.
Reference: https://bugs.centos.org/view.php?id=17928
Indeed, when I decided to use CentOS trata ago, I did not expect this.
Posted Dec 13, 2020 11:22 UTC (Sun)
by ctg (guest, #3459)
[Link] (2 responses)
Now, we could pay a lot of money and use RHEL as the base.
But the problem is that we are, in theory, paying for support. And because we have changed core packages, e.g. the kernel, as soon as we asked for support, I'm sure it would be "no way, you're not running RHEL as the kernel is different. So we can't support that".
I'm not hurling around accusations and anger here, but it's a change in the ecosystem that we have to adjust to - find another distro, just build and maintain all our own packages (either from scratch, or by rebuilding all the RHEL SRPMS etc, and being our own mini-Centos).
Just waiting for the dust to settle.
I'm sure we can't be the only people doing this and in the same boat, but then again, there can't be that many.
Posted Dec 13, 2020 13:28 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link]
The more likely answer would be to ask you to reproduce the problem with the distro kernel to make sure it wasn't something custom you did that caused the problem ie) you are responsible for your own patches. If the problem is reproducible with the distro kernel, the vendor has to take responsibility for that. That's realistically the only way to support it.
Posted Dec 15, 2020 16:21 UTC (Tue)
by mattdm (subscriber, #18)
[Link]
Posted Dec 13, 2020 16:42 UTC (Sun)
by amacater (subscriber, #790)
[Link] (1 responses)
Many in the CentOS community now realise the nature of the community and that that community may be different to what they had thought: many on all sides feel betrayed / upset: goodwill on all sides has been lost. The status quo ante has changed.
This will hit any large user who has significant numbers of machines to cope with - whether they're currently on RHEL or CentOS.
Lots of folk are throwing around threats/promises to move to Debian / OpenSUSE / Others / SLES / Ubuntu (distributions alphabetically).
Ubuntu LTS has a five year support lifetime - it is stable within that time,modulo package fixes and packages that have to be removed as unmaintainable. Releases are on a fixed timeframe. You can do this for free for yourself / purchase paid for support from Canonical.
Any way up that you look at it, this is a huge, previously unappreciated, change to the Red Hat model and to everyone's prior understanding and large communities of users will be affected. Those who choose to move to a different distribution will have to unlearn muscle memory and widen their skills base: everyone will have to revise their expectations.
Now can we all stop imputing to malice what can reasonably be explained by lesser /understanding on all sides, learn by the increased knowledge that we have all gained, and return to being appreciative of each other, please?
Posted Dec 14, 2020 4:49 UTC (Mon)
by Seirdy (guest, #137326)
[Link]
For stable distros, I'd rather look at Slackware or Debian since they aren't as controlled by a single company.
Alpine is also a decent contender; its support isn't as long (2 years), but it's small and simple enough for upgrades to be rather painless. It's much more than the "container/chroot OS" that many see it as.
Posted Dec 13, 2020 19:49 UTC (Sun)
by cyperpunks (subscriber, #39406)
[Link]
It can't be used to build and test RHEL software as CentOS is ahead, not behind RHEL, which
It can't be used as LTS distro for stable stateful services such as databases (MySQL, LDAP etc).
I see no reason to prefer CentOS over Fedora as desktop OS.
A valid purpose is as QA for RHEL Next, which is great for QA departement in RHEL, but who else?
Which brings us back to the early days of Fedora:
From: Konstantin Ryabitsev <icon@linux.duke.edu>
Mike Chambers wrote:
Let me, err, relay how things are looking from outside of RH in the
--- BEGIN IRC LOG ---
Cheers,
--
Posted Dec 17, 2020 23:10 UTC (Thu)
by daniel (guest, #3181)
[Link] (1 responses)
Posted Dec 19, 2020 19:32 UTC (Sat)
by smoogen (subscriber, #97)
[Link]
The island of RPM is steadily shrinking will eventually sink beneath the ways of deb.
apt is equivalent to yum/dnf not to RPM.
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Absolutely agree. As Bob Dylan sings, "The times they are a changin'.'"
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Yes, I remember running "rpm --rebuilddb" and then spending an afternoon cleaning up the mess in the 90's and early aught's, but it did get fixed. (rpm 4, or 4.2ish).
As someone who started their Linux journey on Red Hat 4 (not rhel 4), this is sad. IBM (owner of Red Hat) and, I believe, is the real villain here. They don't seem to care about end users (or really even small businesses). If you need another example, look at the decline in quality that is weather underground, it may be glitzier now, but it has less substance and fewer features.
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
I'm personally not buying this. You're planning such a major change and don't check what is being told to the users?Changing CentOS in mid-stream
At the very least, communication between Red Hat decision makers and the Red Hat's own CentOS team was lacking, the communication towards the CentOS users even more.
The choice of words here "we’ve informed the CentOS Project Governing Board that we are shifting our investment fully from CentOS Linux to CentOS Stream" leaves little doubt as to who decided for whom, and when, doesn't it?
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
There's one tool you need to know: apt (and apt-file). It can do everything.
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
You can use "apt-file search /etc/OpenCL/vendors/mesa.icd". It optionally can search for it in the remote repositories.
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Mandatory upstream distribution and its problems
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
> The CentOS Board was free to tell Red Hat to go pound sand.Changing CentOS in mid-stream
To what effect?
Red Hat controls CentOS entirely, doesn't it? Including the copyright over the CentOS name. All they could have done is resign and walk away, without changing anything as a consequence.
Basically Red Hat actually pulled the embrace extend extinguish maneuver here, although I'm 110% certain that it was never the intention and it actually pains me to see this phrase mentioned in connection with Red Hat.
I've been looking at the various online comments, from those very moderate to those over the top, and summarizing that, and my personal concerns, I'd say that the majority of the damage is caused by drastically changing the CentOS 8 as-we-know-it EOL, after the wide spread adoption, combined with the CentOS Stream 8 shortened lifespan.
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
(above a certain size you have to roll out your own distro anyway)
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
You can run PostgreSQL/MySQL on an ephemeral instance, as long as the data disk is permanent.
Changing CentOS in mid-stream
Fedora vs. CentOS Stream
Fedora vs. CentOS Stream
Fedora vs. CentOS Stream
Fedora vs. CentOS Stream
Fedora vs. CentOS Stream
Fedora vs. CentOS Stream
Fedora vs. CentOS Stream
What exactly Stream is
What exactly Stream is
What exactly Stream is
What exactly Stream is
What exactly Stream is
What exactly Stream is
What exactly Stream is
What exactly Stream is
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
I read the CentOS Stream FAQ:
Changing CentOS in mid-stream
and it doesn't mention "a year after 9 is released". I think "repositories representing RHEL 8 bits" means binary yum repositories, not source git repositories, so you can keep using CentOS Stream 8 as long as RHEL 8 is supported. However, I'm not sure what are the older repositories that are being discontinued
What happens when CentOS Stream switches from RHEL 8 to RHEL 9 based content?
Around the time the RHEL 9 Public Beta is issued, an additional set of CentOS Stream repositories and ISOs will be available. The existing CentOS Stream repositories representing RHEL 8 bits will continue to be available, and changes to these bits will continue as before for the duration of the RHEL 8 Full Support Phase. At that time, the older repositories will be discontinued, although sources will continue to be available.
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
* In some ways this goes back as far as the "commercial" Red Hat Linux -> Red Hat Enterprise Linux / Fedora split out in 2003 or so.
* Red Hat maintained a source release policy - this allowed White Box Linux, CAOS, CentOS and others to build a clone distro.
* Various of these failed - CentOS built up a large community of users - some *because* it was bug for bug compatible with RHEL.
* Lots of people benefited from the implicit ten year "don't change" of RHEL compatibility - especially universities / big projects.
* Individuals often use(d) CentOS as a proving ground/for training - CentOS users also found bugs and security holes.
* Red Hat folk sometimes recommended CentOS for others who couldn't afford RHEL / could reliably do their own support.
* Many CentOS users also have Red Hat machines and licences - hardware support for one often worked for both.
* Some users moved from one to the other for cost or other reasons.
* Once Red Hat took on CentOS, both sides benefited from a pool of experience and work others had done to some degree.
The changes were poorly communicated to the widest world, even if Red Hat folk thought that everybody knew the plans.
Some folk who were expecting a ten year lifespan for Red Hat 8 (and CentOS 8) ,reasonably, based on precedent, have been caught out.
There is a change in relative position and precedence between Fedora, CentOS Streams and the final RHEL: opinions on the stability of CentOS Streams differ.
More than 750 folk have joined Greg K. to essentially attempt to replicate the state of CentOS 7 and CentOS 8 ante quo, potentially.
Cloudlinux and others have also volunteered to build a solution. Other solutions may already exist - Scientific Linux continues to supports 7.*, Springdale Linux is supporting an academic community - and so on.
Debian releases when it's ready - but normally on a two-three year time frame at the moment. It is supported for a year after release an d there are commercially supported options for extended support. Debian stable is stable within that time modulo package fixes and packages that have to be removed as unmaintainable
Changing CentOS in mid-stream
Changing CentOS in mid-stream
makes CentOS useless as development platform for RHEL8
Subject: Re: fedora core 3 goals.
Newsgroups: gmane.linux.redhat.fedora.devel
Date: Mon, 03 May 2004 20:33:58 -0400
Organization: Linux@DUKE
Reply-To: Development discussions related to Fedora Core <fedora-devel-list@redhat.com>
> I think Red Hat went out on a limb and went ahead and told everyone what
> was going to happen with changing to Fedora and letting us in on how
> this thing will work in general.
format everyone will understand...
<rh_pr> We are announcing Red Hat Project! A community-based
distribution!
<oss_crowd> rh_pr: Neat.
<rh_dev> rh_pr: Uh... I'm not ready.
* rh_pr is away: promoting rhel
<oss_crowd> rh_dev: what do we do?
<rh_dev> oss_crowd: I'm not sure.
<rh_legal> rh_dev: don't do anything until I say it's ok.
<oss_crowd> rh_dev: what can we do to help with Red Hat Project?
<rh_dev> oss_crowd: uh... file bugs and help test things.
<oss_crowd> rh_dev: didn't we always do that?
<rh_sales> hey, all, if you really want a stable system, don't use
fedora project. It will eat your brane. Buy RHEL instead.
<rh_dev> rh_sales: stfu
--- rh_pr removes voice from rh_sales
<fedora_us> hey, all, check out our neat community-driven system for
red hat development
<oss_crowd> fedora_us: ooooh!
<rh_pr> fedora_us: I like your name
--- fedora_rh joined the channel
<rh_legal> much better
<rh_pr> We are announcing Fedora Project! A community-driven
distribution!
<oss_crowd> rh_pr: Neat!
* fedora_rh waves
<fedora_us> I'm not dead yet.
<fedora_rh> fedora_us: don't confuse things.
<fedora_us> fedora_rh: does this mean we're merging?
<fedora_rh> fedora_us: maybe
<rh_legal> fedora_rh: don't do anything until I say it's ok.
--- fedora_us joined #limbo
<oss_crowd> fedora_rh: so, what can we do to help?
<fedora_rh> oss_crowd: uh... file bugs and help test things.
<oss_crowd> sigh... didn't we always do that?
<fedora_rh> oss_crowd: I know, let's all go in the circle and say our
names.
* oss_crowd goes in the circle and says their names. This
lasts several months.
<fedora_rh> So, there will be the following features in the next
release of Fedora Core.
<oss_crowd> Uh... Hold on. Who gets to decide?
<rh_sales> We do. That stuff will be neato for RHEL-4.
<oss_crowd> MMkay, then. When do _we_ get to suggest things?
<fedora_rh> oss_crowd: feel free to talk among yourselves.
* oss_crowd talks among themselves about new features.
<fedora_rh> btw, feature X will be disabled in the release.
* oss_crowd glares at fedora_rh
<oss_crowd> fedora_rh: nice of you to tell us while we were sitting
here talking.
<rh_dev> oss_crowd: sorry, it's just not happening.
<oss_crowd> rh_dev: when do we get to decide what's happening?
<rh_dev> oss_crowd: Dunno, I'll ask rh_legal
<rh_legal> rh_dev: ugh, /msg me
<rh_sales> rh_dev: let's not do anything rash here.
* fedora_us gets tired of sitting in #limbo
<oss_crowd> fedora_rh: I want to see more of the "community" part of
the whole "community-based" thing
<oss_crowd> rh_dev: how about at least a publicly accessible CVS/SVN
tree?
<rh_dev> oss_crowd: Yeah, that would be cool.
<oss_crowd> rh_dev: finally, some movement. When is that going to be
up?
* rh_dev is away: talking to rh_legal
* oss_crowd tries to occupy themselves and do things like
fedoranews and fedorapeople.
<oss_crowd> Uh... ping?
<fedora_uh> oss_crowd: what's up?
<oss_crowd> fedora_rh: We're feeling kinda useless. What exactly is our
role, again?
<fedora_rh> oss_crowd: well, it would be really helpful if you could
test some things and file the bugs.
<oss_crowd> fedora_rh: ugh. We ALWAYS did that.
* oss_crowd begins to wonder what exactly is the purpose of
fedora_rh
<fedora_rh> oss_crowd: it's the open-development, proving-grounds for
new technology component of Red Hat, as opposed to RHEL.
<rh_sales> Told ya it'll eat your brane.
--- rh_pr kicks rh_sales from the channel (you're a dolt)
<oss_crowd> fedora_rh: so, let me get this straight. Effectively, you
want us to download the packages you release, test things,
file bugs, and submit patches.
<fedora_rh> oss_crowd: Sure, why not?
<oss_crowd> ...but when it comes to things like features, direction of
the project, and which software to include in the
distribution, it's the decision of Red Hat?
* fedora_rh is away: I AM RH
<fedora_us> I'm still not dead.
<oss_crowd> fedora_rh: How is that different from how things were
before the whole "publicly-supported distribution" thing?
<oss_crowd> rh_dev: where is that long-promised public CVS/SVN repo?
<rh_dev> dunno, talk to fedora_rh
<fedora_rh> oss_crowd: look, such things don't happen in a week, ok?
<oss_crowd> IT'S BEEN A YEAR!
--- rh_sales joined the channel
<rh_sales> EAT YOUR BRAAAAAANE.
<oss_crowd> /mode +b rh_sales
--- You're not ops in here.
<oss_crowd> figures
--- END IRC LOG ---
--
Konstantin ("Icon") Ryabitsev
Duke Physics Systems Admin, RHCE
I am looking for a job in Canada!
http://linux.duke.edu/~icon/cajob.ptml
[2. OpenPGP digital signature --- application/pgp-signature; signature.asc]...
fedora-devel-list mailing list
fedora-devel-list@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
The island of RPM
The island of RPM