In February of 1994 Jon "maddog" Hall interviewed a young Linus Torvalds (then just 24). Nearly three decades later — as Hall approaches his 73rd birthday — he's shared a long essay looking back, but also assessing today's controversy about Red Hat's licensing of RHEL. A (slightly- condensed] excerpt: [O]ver time some customers developed a pattern of purchasing a small number of RHEL systems, then using the "bug-for-bug" compatible version of Red Hat from some other distribution. This, of course, saved the customer money, however it also reduced the amount of revenue that Red Hat received for the same amount of work. This forced Red Hat to charge more for each license they sold, or lay off Red Hat employees, or not do projects they might have otherwise funded. So recently Red Hat/IBM made a business decision to limit their customers to those who would buy a license from them for every single system that would run RHEL and only distribute their source-code and the information necessary on how to build that distribution to those customers. Therefore the people who receive those binaries would receive the sources so they could fix bugs and extend the operating system as they wished.....this was, and is, the essence of the GPL.

Most, if not all, of the articles I have read have said something along the lines of "IBM/Red Hat seem to be following the GPL..but...but...but... the community! "

Which community? There are plenty of distributions for people who do not need the same level of engineering and support that IBM and Red Hat offer. Red Hat, and IBM, continue to send their changes for GPLed code "upstream" to flow down to all the other distributions. They continue to share ideas with the larger community. [...]

I now see a lot of people coming out of the woodwork and beating their breasts and saying how they are going to protect the investment of people who want to use RHEL for free [...] So far I have seen four different distributions saying that they will continue the production of "not RHEL", generating even more distributions for the average user to say "which one should I use"? If they really want to do this, why not just work together to produce one good one? Why not make their own distributions a RHEL competitor? How long will they keep beating their breasts when they find out that they can not make any money at doing it? SuSE said that they would invest ten million dollars in developing a competitor to RHEL. Fantastic! COMPETE. Create an enterprise competitor to Red Hat with the same business channels, world-wide support team, etc. etc. You will find it is not inexpensive to do that. Ten million may get you started.

My answer to all this? RHEL customers will have to decide what they want to do. I am sure that IBM and Red Hat hope that their customers will see the value of RHEL and the support that Red Hat/IBM and their channel partners provide for it. The rest of the customers who just want to buy one copy of RHEL and then run a "free" distribution on all their other systems no matter how it is created, well it seems that IBM does not want to do business with them anymore, so they will have to go to other suppliers who have enterprise capable distributions of Linux and who can tolerate that type of customer. [...]

I want to make sure people know that I do not have any hate for people and companies who set business conditions as long as they do not violate the licenses they are under. Business is business.

However I will point out that as "evil" as Red Hat and IBM have been portrayed in this business change there is no mention at all of all the companies that support Open Source "Permissive Licenses", which do not guarantee the sources to their end users, or offer only "Closed Source" Licenses....who do not allow and have never allowed clones to be made....these people and companies do not have any right to throw stones (and you know who you are).

Red Hat and IBM are making their sources available to all those who receive their binaries under contract. That is the GPL.

For all the researchers, students, hobbyists and people with little or no money, there are literally hundreds of distributions that they can choose, and many that run across other interesting architectures that RHEL does not even address.
Hall answered questions from Slashdot users in 2000 and again in 2013.

Further reading: Red Hat CEO Jim Whitehurst answering questions from Slashdot readers in 2017.

After Red Hat's decision to only share RHEL source code with subscribers, AlmaLinux asked their bug report submitters to "attempt to test and replicate the problem in CentOS Stream as well, so we can focus our energy on correcting it in the right place."

Red Hat told Ars Technica they are "eager to collaborate" on their CentOS Stream distro, "even if we ultimately compete in a business sense. Differentiated competition is a sign of a healthy ecosystem."

But Red Hat still managed to ruffled some feathers, reports ZDNet: AlmaLinux Infrastructure Team Leader Jonathan Wright recently posted a CentOS Stream fix for CVE-2023-38403, a memory overflow problem in iperf3. Iperf3 is a popular open-source network performance test. This security hole is an important one, but not a huge problem.

Still, it's better by far to fix it than let it linger and see it eventually used to crash a server. That's what I and others felt anyway. But, then, a senior Red Hat software engineer replied, "Thanks for the contribution. At this time, we don't plan to address this in RHEL, but we will keep it open for evaluation based on customer feedback."

That went over like a lead balloon.

The GitLab conversation proceeded:

AlmaLinux: "Is customer demand really necessary to fix CVEs?"

Red Hat: "We commit to addressing Red Hat defined Critical and Important security issues. Security vulnerabilities with Low or Moderate severity will be addressed on demand when [a] customer or other business requirements exist to do so."

AlmaLinux: "I can even understand that, but why reject the fix when the work is already done and just has to be merged?"

At this point, Mike McGrath, Red Hat's VP of Core Platforms, AKA RHEL, stepped in. He explained, "We should probably create a 'what to expect when you're submitting' doc. Getting the code written is only the first step in what Red Hat does with it. We'd have to make sure there aren't regressions, QA, etc. ... So thank you for the contribution, it looks like the Fedora side of it is going well, so it'll end up in RHEL at some point."

Things went downhill rapidly from there...

On Reddit, McGrath said, "I will admit that we did have a great opportunity for a good-faith gesture towards Alma here and fumbled."

Finally, though the Red Hat Product Security team rated the CVE as "'Important,' the patch was merged.
Coincidentally, last month AlmaLinux announced that its move away from 1:1 compatibility with RHEL meant "we can now accept bug fixes outside of Red Hat's release cycle."

This Thursday AlmaLinux also reiterated that they're "fully committed to delivering the best possible experience for the community, no matter where or what you run." And in an apparent move to beef up compatibility testing, they announced they'd be bringing openQA to the RHEL ecosystem. (They describe openQA as a tool using virtual machines that "simplifies automated testing of the whole installation process of an operating system in a wide combination of software and hardware configurations.")

Last weekend in Portland, Oregon, the Software Freedom Conservancy hosted a new conference called the Free and Open Source Software Yearly.

And long-time free software activist Bradley M. Kuhn (currently a policy fellow/hacker-in-residence for the Software Freedom Conservancy) hosted a lively panel discussion on "the recent change" to public source code releases for Red Hat Enterprise Linux which shed light on what may happen next. The panel also included:

• benny Vasquez, the Chair of the AlmaLinux OS Foundation
• Jeremy Alison, Samba co-founder and software engineer at CIQ (focused on Rocky Linux). Allison is also Jeremy Allison - Sam Slashdot reader #8,157.
• James (Jim) Wright, Oracle's chief architect for Open Source policy/strategy/compliance/alliances

"Red Hat themselves did not reply to our repeated requests to join us on this panel... SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel."

One interesting audience question for the panel came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years, but said he was "responsible for bringing the CentOS team onboard to Red Hat." Wade argued that CentOS "was always doing a clean rebuild from source RPMS of their own..." So "isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, 'This thing is not the equivalent to RHEL.'"

In response Jeremy Alison made a good point. "None of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters." But this led to an audience member asking a very forward-looking question: what are the chances the community could adopt a new (and open) enterprise Linux standard that distributions could follow. AlmaLinux's Vasquez replied, "Chances are real high... I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that." And Oracle's Wright added "to the extent that the market asks us to standardize? We're all responsive."

When asked if they'd consider adding features not found in RHEL ("such as high-security gates through reproducible builds") AlmaLinux's Vasquez said "100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options." And CIQ's Alison said "We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that."

AlmaLinux's Vasquez emphasized later that "We're just going to build Enterprise Linux. Red Hat has done a great job of establishing a fantastic target for all of us, but they don't own the rights to enterprise Linux. We can make this happen, without forcing an uncomfortable conversation with Red Hat. We can get around this."

And Alison later applied a "Star Wars" quote to Red Hat's predicament. "The more things you try and grab, the more things slip through your fingers." That is, "The more somebody tries to exert control over a codebase, the more the pushback will occur from people who collaborate in that codebase." AlmaLinux's Vasquez also said they're already "in conversations" with independent software vendors about the "flow of support" into non-Red Hat distributions -- though that's always been the case. "Finding ways to reduce the barrier for those independent software vendors to add official support for us is, like, maybe more cumbersome now, but it's the same problem that we've had..."

Early in the discussion Oracle's Jim Wright pointed out that even Red Hat's own web site defines open source code as "designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit." ("Until now," Wright added pointedly...) There was some mild teasing of Oracle during the 50-minute discussion -- someone asked at one point if they'd re-license their proprietary implementation of ZFS under the GPL. But at the end of the panel, Oracle's Jim Wright still reminded the audience that "If you want to work on open source Linux, we are hiring."

Read Slashdot's transcript of highlights from the discussion.

Long-time Slashdot reader Amiga Trombone shares a report from Phoronix: With Red Hat now restricting access to the RHEL source repositories, AlmaLinux and other downstreams that have long provided "community" rebuilds of Red Hat Enterprise Linux with 1:1 compatibility to upstream RHEL have been left sorting out what to do. Benny Vasquez, Chair of the Board for the AlmaLinux OS Foundation, wrote in a blog post yesterday: After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible*.

We will continue to aim to produce an enterprise-grade, long-term distribution of Linux that is aligned and ABI compatible with RHEL in response to our community's needs, to the extent it is possible to do, and such that software that runs on RHEL will run the same on AlmaLinux.

For a typical user, this will mean very little change in your use of AlmaLinux. Red Hat-compatible applications will still be able to run on AlmaLinux OS, and your installs of AlmaLinux will continue to receive timely security updates. The most remarkable potential impact of the change is that we will no longer be held to the line of "bug-for-bug compatibility" with Red Hat, and that means that we can now accept bug fixes outside of Red Hat's release cycle. While that means some AlmaLinux OS users may encounter bugs that are not in Red Hat, we may also accept patches for bugs that have not yet been accepted upstream, or shipped downstream."

Steven Vaughan-Nichols writes via ZDNet: I'd been waiting for Oracle to throw its hat into the ring for the Red Hat Enterprise Linux (RHEL) Linux source-code fight. I knew it was only a matter of time. On July 10, Oracle's Edward Screven, chief corporate architect, and Wim Coekaerts, head of Oracle Linux development, declared: "IBM's actions are not in your best interest. By killing CentOS as a RHEL alternative and attacking AlmaLinux and Rocky Linux, IBM is eliminating one way your customers save money and make a larger share of their wallet available to you."

In fact, Oracle now presents itself as an open-source Linux champion: "Oracle has always made Oracle Linux binaries and source freely available to all. We do not have subscription agreements that interfere with a subscriber's rights to redistribute Oracle Linux. On the other hand, IBM subscription agreements specify that you're in breach if you use those subscription services to exercise your GPLv2 rights." As of June 21, IBM no longer publicly releases RHEL source code -- in short, the gloves are off, and the fight's on. But this is also just the latest move in a fight that's older than many of you. [...]

Mike McGrath, Red Hat's vice president of core platforms, explained why Red Hat would no longer be releasing RHEL's code, but only CentOS Stream's code, because "thousands of [Red Hat] people spend their time writing code to enable new features, fixing bugs, integrating different packages and then supporting that work for a long time ... We have to pay the people to do that work." That sentiment is certainly true. But I also feel that Oracle takes the worst possible spin, with Screven and Coekaerts commenting: "IBM doesn't want to continue publicly releasing RHEL source code because it has to pay its engineers? That seems odd, given that Red Hat as a successful independent open source company chose to publicly release RHEL source and pay its engineers for many years before IBM acquired Red Hat in 2019 for $34 billion."

So, what will Oracle do now? For starters, Oracle Linux will continue to be RHEL-compatible through RHEL 9.2. After that release -- and without access to the published RHEL source code -- there are no guarantees. But Screven and Coekaerts suggest that "if an incompatibility does affect a customer or ISV, Oracle will work to remediate the problem." As for Oracle Linux's code: "Oracle is committed to Linux freedom. Oracle makes the following promise: as long as Oracle distributes Linux, Oracle will make the binaries and source code for that distribution publicly and freely available. Furthermore, Oracle welcomes downstream distributions of every kind, community, and commercial. We are happy to work with distributors to ease that process, work together on the content of Oracle Linux, and ensure Oracle software products are certified on your distribution."

John.Banister writes: SUSE announced that they're spending $10 million on maintaining a fork of RHEL, with the source code of the fork to be freely available to all. I don't know that people who want to copy RHEL source will necessarily see copying the source of a fork as furthering their goals, but it could be that SUSE will build a nice alternative enterprise Linux to complement their current product. And, I reckon, better SUSE than Oracle, since I keep reading comments on people getting screwed by Oracle, but not so many on people getting screwed by SUSE. ZDNet's Steven Vaughan-Nichols writes: This all started when Red Hat's VP of core platforms, Mike McGrath, declared, "CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal." That may not sound like much to you, but those were fighting words to many open-source and Linux distributors. According to Linux's fundamental license, the GPLv2, no restrictions can be placed on distributing the source code to those who've received the binaries. In the view of many in the open-source community, that's exactly what Red Hat has done.

Others see this as the latest step in the long dance between Red Hat's business licensing demands and open-source licensing. Red Hat has had conflicts with the RHEL clones since 2005, when Red Hat's trademarks were the issue of the day. Usually, these fights stayed confined to the RHEL and its immediate clone rivals. Not this time.

Dirk-Peter van Leeuwen, SUSE CEO, said this: "For decades, collaboration and shared success have been the building blocks of our open-source community. We have a responsibility to defend these values. This investment will preserve the flow of innovation for years to come and ensures that customers and community alike are not subjected to vendor lock-in and have genuine choice tomorrow as well as today." What does that mean? While SUSE will continue to invest in and support its own Linux distributions, SUSE Linux Enterprise (SLE) and openSUSE, SUSE plans on creating its own RHEL-compatible clone. Once completed, this new distro will be contributed to an open-source foundation, which will provide ongoing free access to alternative source code.

Wednesday Greg Kroah-Hartman announced the release of the 6.4.2 kernel. "All users of the 6.4 kernel series must upgrade."

The Hacker News reports: Details have emerged about a newly identified security flaw in the Linux kernel that could allow a user to gain elevated privileges on a target host. Dubbed StackRot (CVE-2023-3269, CVSS score: 7.8), the flaw impacts Linux versions 6.1 through 6.4. There is no evidence that the shortcoming has been exploited in the wild to date.

"As StackRot is a Linux kernel vulnerability found in the memory management subsystem, it affects almost all kernel configurations and requires minimal capabilities to trigger," Peking University security researcher Ruihan Li said. "However, it should be noted that maple nodes are freed using RCU callbacks, delaying the actual memory deallocation until after the RCU grace period. Consequently, exploiting this vulnerability is considered challenging."

Following responsible disclosure on June 15, 2023, it has been addressed in stable versions 6.1.37, 6.3.11, and 6.4.1 as of July 1, 2023, after a two-week effort led by Linus Torvalds. A proof-of-concept (PoC) exploit and additional technical specifics about the bug are expected to be made public by the end of the month.
ZDNet points out that Linux 6.4 "offers improved hardware enablement for ARM boards" and does a better job with the power demands of Steam Deck gaming devices. And "On the software side, the Linux 6.4 release includes more upstreamed Rust code. We're getting ever closer to full in-kernel Rust language support."

The Register also notes that Linux 6.4 also includes "the beginnings of support for Apple's M2 processors," along with support for hibernation of RISC-V CPUs, "a likely presage to such silicon powering laptop computers."

End-of-life for Red Hat 7 is scheduled to happen in one year. Thursday Red Hat announced an add-on option for four more years of "extended support" for RHEL 7: As we near the end of the standard 10-year life cycle of RHEL 7, some IT organizations are finding that they cannot complete their planned migrations before June 30, 2024. To support IT teams while they catch up on their migration schedules, Red Hat is announcing a one-time, 4 year ELS maintenance period for RHEL 7 ELS. While Red Hat is providing more time, we strongly recommend customers migrate to a newer version of RHEL to take advantage of new features and enhancements...

For organizations that need to remain on a major release beyond the standard life cycle, we offer the Extended Life Cycle Support (ELS) Add-On. This add-on currently extends support of major releases for up to 2 years after the end of the standard release life cycle. As an optional, add-on subscription, ELS gives you access to troubleshooting for the last minor release, selected urgent priority bug fixes and certain Red Hat-defined security fixes...

ELS for RHEL 7 is now available for 4 years, starting on July 1, 2024. Organizations must be on RHEL 7.9 to take advantage of this. Compared to previous major releases, ELS for RHEL 7 (RHEL 7.9) expands the scope of security fixes by including updates that address Important CVEs. It also includes maintenance for Red Hat Enterprise Linux for SAP Solutions and Red Hat Enterprise Linux High Availability and Resilient Storage add-ons. And to help you create your long-term IT infrastructure strategy, Red Hat plans to offer ELS for 3 years for both RHEL 8 and 9.

When you're ready to upgrade from RHEL 7 — or any other version — Red Hat is here to help. We offer in-place upgrade tools and detailed guidance to streamline upgrades and application migrations. You can also engage Red Hat Consulting to plan and execute your upgrade projects.
CentOS 7 will also hit its end-of-life in one year on June 30 of 2024.

gatzke writes: Upsetting many in the open-source community was Red Hat's announcement last week that they would begin limiting access to the Red Hat Enterprise Linux sources by putting them behind the Red Hat Customer Portal and publicly would be limited to the CentOS Stream sources. In turn this causes problems for free-of-cost derivatives like AlmaLinux moving forward. Red Hat this week issued another blog post trying to address some of the criticism.

Red Hat's blog this week featured a post by Mike McGrath, the VP of Core Platforms Engineering at Red Hat. In the post he talks up "Red Hat's commitment to open source." Some of the key takeaways include:
"Despite what's currently being said about Red Hat, we make our hard work readily accessible to non-customers. Red Hat uses and will always use an open source development model. When we find a bug or write a feature, we contribute our code upstream. This benefits everyone in the community, not just Red Hat and our customers.
... We will always send our code upstream and abide by the open source licenses our products use, which includes the GPL. When I say we abide by the various open source licenses that apply to our code, I mean it.
... I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.
... Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity."

Long-time Slashdot reader internet-redstar writes: In little longer than 1 year, RHEL7 and CentOS 7 will go EOL. Large enterprises with thousands of these servers are struggling to meet that deadline. Now they also have the option to use Project78 from Linux Belgium which offers a Cloud and OnPrem version to aid in the transition to RHEL 8 or Rocky Linux 8. It promises a 100% success rate for in-place OS upgrading and a 95% success rate for application migrations in a Upgrade-as-a-Service package.
In April Red Hat's senior technical marketing manager shared their thoughts about next year's end of life for CentOS Linux and the End-of-Maintenance for Red Hat Enterprise Linux 7 (along with some tips): The good news is that these events won't require a complete infrastructure overhaul. Tools are available to move from your current configuration to a place where you'll have years of support. While June of '24 may sound a ways off, do not delay. It will be here faster than you think. Start planning now. Start moving soon. Give yourself plenty of runway, and don't forget that we aren't just your software vendor at Red Hat. We are your partners and are here to help you with these transitions.
UPDATE (7/3): Thursday Red Hat announced an add-on option for four more years of "extended support" for RHEL 7: As we near the end of the standard 10-year life cycle of RHEL 7, some IT organizations are finding that they cannot complete their planned migrations before June 30, 2024. To support IT teams while they catch up on their migration schedules, Red Hat is announcing a one-time, 4 year ELS maintenance period for RHEL 7 ELS. While Red Hat is providing more time, we strongly recommend customers migrate to a newer version of RHEL to take advantage of new features and enhancements...

For organizations that need to remain on a major release beyond the standard life cycle, we offer the Extended Life Cycle Support (ELS) Add-On. This add-on currently extends support of major releases for up to 2 years after the end of the standard release life cycle. As an optional, add-on subscription, ELS gives you access to troubleshooting for the last minor release, selected urgent priority bug fixes and certain Red Hat-defined security fixes...

ELS for RHEL 7 is now available for 4 years, starting on July 1, 2024. Organizations must be on RHEL 7.9 to take advantage of this. Compared to previous major releases, ELS for RHEL 7 (RHEL 7.9) expands the scope of security fixes by including updates that address Important CVEs. It also includes maintenance for Red Hat Enterprise Linux for SAP Solutions and Red Hat Enterprise Linux High Availability and Resilient Storage add-ons. And to help you create your long-term IT infrastructure strategy, Red Hat plans to offer ELS for 3 years for both RHEL 8 and 9.

When you're ready to upgrade from RHEL 7 — or any other version — Red Hat is here to help. We offer in-place upgrade tools and detailed guidance to streamline upgrades and application migrations. You can also engage Red Hat Consulting to plan and execute your upgrade projects.

"CentOS Stream will now be the sole repository for public RHEL-related source code releases..." Red Hat posted this week on its blog, arguing that "The engagement around CentOS Stream, the engineering levels of investment, and the new priorities we're addressing for customers and partners now make maintaining separate, redundant, repositories inefficient."

Long-time Slashdot reader slack_justyb notes this means patches and changes will now hit CentOS Stream before actually hitting RHEL, which "will make it difficult for other distributions such as Alma Linux, Rocky Linux, and Oracle Linux to provide assured binary compatibility as their only source now will be ahead of what RHEL is actually using."

"Some commentators are pointing out that it's possible to sign up for a free Red Hat Developer account, and obtain the source code legitimately that way," writes the Register. "This is perfectly true, but the problem is that the license agreement that you have to sign to get that account prevents you from redistributing the software." Hackaday notes that beyond the the GPL v2 license on the kernel, Red Hat also has "an additional user agreement that terminates access to updates if the code is re-published."

Rocky Linux officially "remains confident in its ability to continue as a bug-for-bug compatible and freely available alternative to Red Hat Enterprise Linux, despite changes in accessibility." While this decision does change the automation we use for building Rocky Linux, we have already created a short term mitigation and are developing the longer term strategy. There will be no disruption or change for any Rocky Linux users, collaborators, or partners... The project pledges to keep its promise to maintain the full life-span of support for Rocky 8 and 9, and to continue to produce future RHEL-compatible versions as long as the option remains, allowing organizations to maintain the flexibility, control, and freedom they rely upon for their critical infrastructure. This is the open source way.
Gregory Kurtzer, founder of the Rocky Linux project, calls Red Hat's move "a minor inconvenience for the Rocky Linux team," but with "no disruption to Rocky Linux users. Moving forward we are becoming even more stable, supported, and secure."

AlmaLinux also weighs in: Can you just use CentOS Stream sources?
No, we are committed to remaining a downstream RHEL clone, and using CentOS Stream sources would make us upstream of RHEL. CentOS Stream sources, while being upstream of RHEL, do not always include all patches and updates that are included in RHEL packages.

Is Red Hat trying to kill downstream clones?
We cannot speak to Red Hat's intentions, and can only point to the things they have said publicly. We have had an incredible working relationship with Red Hat through the life of AlmaLinux OS and we hope to see that continue.

The Red Hat Package Managers for LibreOffice "have recently been orphaned," according to a post by Red Hat manager Matthias Clasen on the "LibreOffice packages" mailing list, "and I thought it would be good to explain the reasons behind this." The Red Hat Display Systems team (the team behind most of Red Hat's desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what's needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.

The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.

We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.

Any community member is of course free to take over maintenance, both for the RPMs [Red Hat Package Managers] in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Commenters on LWN.net are now debating its impact.

One pointed out that "You will still find it in GNOME Software, which will install a Flatpak from FlatHub rather than an RPM from the distro."

For Red Hat's 30th anniversary, North Carolina's News & Observer newspaper ran a special four-part series of articles.

In the first article Red Hat co-founder Bob Young remembers Red Hat's first big breakthrough: winning InfoWorld's "OS of the Year" award in 1998 — at a time when Microsoft's Windows controlled 85% of the market. "How is that possible," Young said, "that one of the world's biggest technology companies, on this strategically critical product, loses the product of the year to a company with 50 employees in the tobacco fields of North Carolina?" The answer, he would tell the many reporters who suddenly wanted to learn about his upstart company, strikes at "the beauty" of open-source software.

"Our engineering team is an order of magnitude bigger than Microsoft's engineering team on Windows, and I don't really care how many people they have," Young would say. "Like they may have thousands of the smartest operating system engineers that they could scour the planet for, and we had 10,000 engineers by comparison...."

Young was a 40-year-old Canadian computer equipment salesperson with a software catalog when he noticed what Marc Ewing was doing. [Ewing was a recent college graduate bored with his two-month job at IBM, selling customized Linux as a side hustle.] It's pretty primitive, but it's going in the right direction, Young thought. He began reselling Ewing's Red Hat product. Eventually, he called Ewing, and the two met at a tech conference in New York City. "I needed a product, and Marc needed some marketing help," said Young, who was living in Connecticut at the time. "So we put our two little businesses together."

Red Hat incorporated in March 1993, with the earliest employees operating the nascent business out of Ewing's Durham apartment. Eventually, the landlord discovered what they were doing and kicked them out.
The four articles capture the highlights. ("A visual effects group used its Linux 4.1 to design parts of the 1997 film Titanic.") And it doesn't leave out Red Hat's skirmishes with Microsoft. ("Microsoft was owned by the richest person in the world. Red Hat engineers were still linking servers together with extension cords. ") "We were changing the industry and a lot of companies were mad at us," says Michael Ferris, Red Hat's VP of corporate development/strategy. Soon there were corporate partnerships with Netscape, Intel, Hewlett-Packard, Compaq, Dell, and IBM — and when Red Hat finally goes public in 1999, its stock sees the eighth-largest first-day gain in Wall Street history, rising in value in days to over $7 billion and "making overnight millionaires of its earliest employees."

But there's also inspiring details like the quote painted on the wall of Red Hat's headquarters in Durham: "Every revolution was first a thought in one man's mind; and when the same thought occurs to another man, it is the key to that era..." It's fun to see the story told by a local newspaper, with subheadings like "It started with a student from Finland" and "Red Hat takes on the Microsoft Goliath."

Something I'd never thought of. 2001's 9/11 terrorist attack on the World Trade Center "destroyed the principal data centers of many Wall Street investment banks, which were housed in the twin towers. With their computers wiped out, financial institutions had to choose whether to rebuild with standard proprietary software or the emergent open source. Many picked the latter." And by the mid-2000s, "Red Hat was the world's largest provider of Linux...' according to part two of the series. "Soon, Red Hat was servicing more than 90% of Fortune 500 companies." By then, even the most vehement former critics were amenable to Red Hat's kind of software. Microsoft had begun to integrate open source into its core operations. "Microsoft was on the wrong side of history when open source exploded at the beginning of the century, and I can say that about me personally," Microsoft President Brad Smith later said.

In the 2010s, "open source has won" became a popular tagline among programmers. After years of fighting for legitimacy, former Red Hat executives said victory felt good. "There was never gloating," Tiemann said.

"But there was always pride."
In 2017 Red Hat's CEO answered questions from Slashdot's readers.

According to Phoronix citing multiple local North Carolina news outlets, Red Hat is cutting "hundreds of jobs" in an initial round of layoffs announced today. From the report: According to WRAL, Red Hat CEO Matt Hicks is said to have told employees in an email "we will not reduce roles directly selling to customers or building our products," which is hopefully good news for their many upstream Linux developers they employ that ultimately build Red Hat Enterprise Linux and associated software products. Red Hat will begin notifying affected employees today in some countries while the process will continue through the end of the quarter. IBM, which acquired Red Hat in 2019, has already slashed some five thousand positions so far in 2023.

An anonymous reader shares a report: For Red Hat, which turned 30 on March 27, it was a cause for celebration. From a business that got started in one of its co-founder's wife's sewing room, it became the first billion-dollar pure-play open-source company and then the engine driving IBM. It has been a long strange trip. Sure, today, the tech world is dominated by Linux and open source software, but in 1993, Linux was merely an obscure operating system known only to enthusiasts. Red Hat played a significant role in transforming the "just a hobby" operating system into today's major IT powerhouse. Red Hat co-founder Bob Young, who previously ran a rental typewriter business, was one of those who became intrigued by Linux. In 1993, he established ACC Corporation, a catalog company that distributed Slackware Linux CDs and open-source software.

[...] In 2003, Paul Cormier, then Red Hat's vice president of engineering and now the company's chairman, spearheaded the shift from the inexpensive prosumer Red Hat Linux distribution to the full business-oriented Red Hat Enterprise Linux (RHEL). At the time, many Linux users hated the idea. Even inside Red Hat, Cormier said that many engineers were initially opposed to the new business model, causing some to leave the company while others stayed. The change also upset many users who felt Red Hat was abandoning its original customers. However, enterprise clients had a different perspective. Whitehurst, who became Red Hat CEO in 2008, said, "Once RHEL was in the market, we had to fully support it to make it truly consumable for the enterprise." They succeeded, and Red Hat continued to grow. This is the model that turned Red Hat into the first billion-dollar-a-quarter pure open-source company. Impressive for a business built around an operating system once considered suitable only for the "lunatic fringe." Then, in 2018, IBM acquired Red Hat for a cool $34 billion. There was nothing crazy about that move.

[...] Another change that was already present in Red Hat, a shift towards supporting the cloud, has accelerated. Today, while RHEL remains the heart of the business, the Linux-powered cloud has become increasingly important. In particular, Red Hat OpenShift, its Kubernetes-powered hybrid cloud application platform, is more important than ever. Where does Red Hat go from here? When I last talked to Cormier and Red Hat's latest CEO, Matt Hicks, they told me that they'd keep moving forward with the hybrid cloud. After all, as Cormier pointed out, "the cloud wouldn't be here" without Linux and open source. As for Red Hat's relationship with IBM, Cormier said, "The red lines were red, and the blue lines were blue, and that will stay the same."

An anonymous reader quotes Neowin: Google Project Zero is a security team responsible for discovering security flaws in Google's own products as well as software developed by other vendors. Following discovery, the issues are privately reported to vendors and they are given 90 days to fix the reported problems before they are disclosed publicly.... Now, the security team has reported several flaws in CentOS' kernel.

As detailed in the technical document here, Google Project Zero's security researcher Jann Horn learned that kernel fixes made to stable trees are not backported to many enterprise versions of Linux. To validate this hypothesis, Horn compared the CentOS Stream 9 kernel to the stable linux-5.15.y stable tree.... As expected, it turned out that several kernel fixes have not been made deployed in older, but supported versions of CentOS Stream/RHEL. Horn further noted that for this case, Project Zero is giving a 90-day deadline to release a fix, but in the future, it may allot even stricter deadlines for missing backports....

Red Hat accepted all three bugs reported by Horn and assigned them CVE numbers. However, the company failed to fix these issues in the allotted 90-day timeline, and as such, these vulnerabilities are being made public by Google Project Zero.
Horn is urging better patch scheduling so "an attacker who wants to quickly find a nice memory corruption bug in CentOS/RHEL can't just find such bugs in the delta between upstream stable and your kernel."

Long-time Slashdot reader destinyland writes: They say "always be learning" — but do podcasts actually help? I've been trying to find podcasts that discuss programming, and I've enjoyed Lex Fridman's interviews with language creators like Guido van Rossum, Chris Lattner, and Brendan Eich (plus his long interviews with Donald Knuth). Then I discovered that GitHub, Red Hat, Stack Overflow, and the Linux Foundation all have their own podcast.

There's a developer podcast called "Corecursive" that I like with the tagline "the stories behind the code," plus a whole slew of (sometimes language-specific) podcasts at Changelog (including an interview with Brian Kernighan). And it seems like there's an entirely different universe of content on YouTube — like the retired Microsoft engineer doing "Dave's Garage," Software Engineering Daily, and the various documentaries by Honeypot.io. Computerphile has also scored various interviews with Brian Kernighan, and if you search YouTube enough you'll find stray interviews with Steve Wozniak.

But I wanted to ask Slashdot's readers: Do you listen to podcasts about computer science? And if so, which ones? (Because I'm always stumbling across new programming podcasts, which makes me worry about what else I've been missing out on.) Maybe I should also ask if you ever watch coding livestreams on Twitch — although that gets into the more general question of just how much content we consume that's related to our profession.
Fascinating discussions, or continuing work-related education? (And do podcasts really help keep your skills fresh? Are coding livestreams on Twitch just a waste of time?) Most importantly, does anyone have a favorite geek podcast that they're listening to? Share your own experience and opinions in the comments...

What's the best podcast about computer science?

An anonymous reader quotes a report from VentureBeat: Red Hat is perhaps best known as a Linux operating system vendor, but it is the company's OpenShift platform that represents its fastest growing segment. Today, Red Hat announced the general availability of OpenShift 4.12, bringing a series of new capabilities to the company's hybrid cloud application delivery platform. OpenShift is based on the open source Kubernetes container orchestration system, originally developed by Google, that has been run as the flagship project of the Linux Foundation's Cloud Native Computing Foundation (CNCF) since 2014. [...] With the new release, Red Hat is integrating new capabilities to help improve security and compliance for OpenShift, as well as new deployment options on ARM-based architectures. The OpenShift 4.12 release comes as Red Hat continues to expand its footprint, announcing partnerships with Oracle and SAP this week.

The financial importance of OpenShift to Red Hat and its parent company IBM has also been revealed, with IBM reporting in its earnings that OpenShift is a $1 billion business. "Open-source solutions solve major business problems every day, and OpenShift is just another example of how Red Hat brings business and open source together for the benefit of all involved," Mike Barrett, VP of product management at Red Hat, told VentureBeat. "We're very proud of what we have accomplished thus far, but we're not resting at $1B." [...]

OpenShift, like many applications developed in the last several decades, originally was built just for the x86 architecture that runs on CPUs from Intel and AMD. That situation is increasingly changing as OpenShift is gaining more support to run on the ARM processor with the OpenShift 4.12 update. Barrett noted that Red Hat OpenShift announced support for the AWS Graviton ARM architecture in 2022. He added that OpenShift 4.12 expands that offering to Microsoft Azure ARM instances. "We find customers with a significant core consumption rate for a singular computational deliverable are gravitating toward ARM first," Barrett said.

Overall, Red Hat is looking to expand the footprint of where its technologies are able to run, which also new cloud providers. On Jan. 31, Red Hat announced that for the first time, Red Hat Enterprise Linux (RHEL) would be available as a supported platform on Oracle Cloud Infrastructure (OCI). While RHEL is now coming to OCI, OpenShift isn't -- at least not yet. "Right now, it's just RHEL available on OCI," Mike Evans, vice president, technical business development at Red Hat, told VentureBeat. "We're evaluating what other Red Hat technologies, including OpenShift, may come to Oracle Cloud Infrastructure but this will ultimately be driven by what our joint customers want."

"From the maintainer of Ubuntu Unity and the Unity desktop environment, here comes blendOS," writes 9to5Linux, "a GNU/Linux distribution that aims to be the last distribution you'll ever use, especially if you distro hop." blendOS is here to offer you "a seamless blend of all Linux distributions," as its creator wants to call it. blendOS is based on Arch Linux and GNOME on Wayland, but it lets you use apps from other popular distributions, such as Fedora Linux or Ubuntu.

This is possible because you can use the native package managers from Arch Linux (pacman — included by default), Fedora Linux (dnf), and Ubuntu (apt), which are included as containers using Distrobox/Podman. However, the DNF and APT package managers aren't included in the live ISO image, nor blendOS's own blend package manager.... It also follows a rolling release model, since it's derived from Arch Linux.

Even if it comes with the GNOME desktop by default on the live ISO image, blendOS will let you deploy a new installation with another popular desktop environment, such as KDE Plasma, MATE, or Xfce, or even window managers like Sway or i3. Apart from the fact that you can install any app from any of the supported Linux distributions, blendOS also comes with out-of-the-box support for sandboxed Flatpak apps, which you can easily install directly from the Flathub Store app, which is a Web App that puts the Flathub website on your desktop.

An anonymous reader quotes a report from ZDNet: One bit of accepted wisdom in some cloud circles is that OpenStack, the open-source Infrastructure as a Service (IaaS) cloud, is declining. Nothing could be further from the truth. It's alive, well, and growing like crazy. According to the 2022 OpenStack User Survey, OpenStack now has over 40 million production cores. Or, in other words, it's seen 60% growth since 2021 and a 166% jump since 2020. Not bad for a so-called also-run, eh? It's not just telecoms, where OpenStack has become the backbone of major cell companies such as China Mobile and Verizon. Nor is it just other major companies such as the Japanese instant messaging service LINE, the on-demand, cloud-based financial management service company Workday, Walmart Labs, and Yahoo. No, many other, much smaller companies have also staked their cloud future on OpenStack.

Why? There are many reasons. As Jonathan Bryce, executive director of the Open Infrastructure Foundation (OpenInfra Foundation), OpenStack's parent organization, said, "OpenStack supports the ever-changing world of infrastructure where now we have GPUs, FPGAs, smart NICs, and smart storage. At the same time, you can still get direct access to the underlying hardware." This, in turn, enables "OpenStack users to create such amazing things as telecom cloud workloads on the cloud that can do edge transcoding video. With this, people can watch 4K videos on their phones using 5G." Another reason for OpenStack's growing popularity is its Kubernetes integration. Thanks to Linux OpenStack Kubernetes Infrastructure (LOKI), Kubernetes is now deployed on over 85% of OpenStack deployments. In addition, Magnum, the OpenStack container orchestration service, is also gaining popularity. 21% of users are now running production workloads with it. [...] Kubernetes is also very useful with hybrid clouds. OpenStack is often used in hybrid clouds. Indeed, 80% of OpenStack users are deploying it in hybrid clouds. To make it easier to build out hybrid clouds, operators are turning to Octavia, an open-source, operator-scale load-balancing program. Today, not quite 50% of OpenStack deployments are using Octavia. OpenInfra Foundation's general manager Thierry Carrez said: "Hype is nice, but substance lasts, and as OpenStack deployments continue to grow in staggering numbers, the OpenStack community is proving that it's not only alive and well, but also delivering indisputable value to organizations."