The Steam Survey results for July 2023 were just published and it points to a large and unexpected jump in the Linux gaming marketshare. Phoronix reports; According to these new numbers from Valve, the Linux customer base is up to 1.96%, or a 0.52% jump over June! That's a huge jump with normally just moving 0.1% or so in either direction most months... It's also near an all-time high on a percentage basis going back to the early days of Steam on Linux when it had around a 2% marketshare but at that time the Steam customer size in absolute numbers was much smaller a decade ago than it is now. So if the percentage numbers are accurate, this is likely the largest in absolute terms that the Linux gaming marketshare has ever been.

When looking at the Steam Linux breakdown, the SteamOS Holo that powers the Steam Deck is now accounting for around 42% of all Linux gamers on Steam. Meanwhile, AMD CPU marketshare among Linux gamers has reached 69%. The Steam Survey results for July show Windows 10 64-bit losing 1.56% marketshare and Linux gaining the healthy 0.52% of that. This is also the first time the Linux gaming marketshare outpasses Apple macOS on Steam!

Google's long-running project to split up ChromeOS and its Chrome browser is currently in beta and should be live in the stable channel later this month. The flags that turn on the feature by default were spotted by Kevin Tofel from About Chromebooks. Ars Technica reports: The project is called "Lacros" which Google says stands for "Linux And ChRome OS." This will split ChromeOS's Linux OS from the Chrome browser, allowing Google to update each one independently. Google documentation on the project says, "On Chrome OS, the system UI (ash window manager, login screen, etc.) and the web browser are the same binary. Lacros separates this functionality into two binaries, henceforth known as ash-chrome (system UI) and lacros-chrome (web browser)." Part of the project involves sprucing up the ChromeOS OS, and Google's docs say, "Lacros can be imagined as 'Linux chrome with more Wayland support.'"

On the browser side, ChromeOS would stop using the bespoke Chrome browser for ChromeOS and switch to the Chrome browser for Linux. The same browser you get on Ubuntu would now ship on ChromeOS. In the past, turning on Lacros in ChromeOS would show both Chrome browsers, the outgoing ChromeOS one and the new Linux one. Lacros has been in development for around two years and can be enabled via a Chrome flag. Tofel says his 116 build no longer has that flag since it's the default now. Google hasn't officially confirmed this is happening, but so far, the code is headed that way.

Michael Larabel, reporting at Phoronix: Alpine Linux remains one of the most popular lightweight Linux distributions built atop musl libc and Busybox. Alpine Linux has found significant use within containers and the embedded space while now sadly the most prolific maintainer of packages for the Linux distribution has decided to step down from her roles. Alice "psykose" who is easily responsible for the highest number of commits per author over the past year has decided to step down from maintaining her packages.

These Alpine aports stats put her at 13,894 commits over the past year. In comparison, the second most prolific packager saw just 2,053 commits... Or put another way, psykose has 6.7x the number of commits as the next packager. The 13.8k commits is also about half of the 26.8k commits seen in total over the past year. Over the weekend I was alerted to the fact that psykose/nekopsykose has begun dropping maintainership of packages she maintained. All of her recent alpinelinux/aports commits two days ago were removing packages she oversaw.

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.

This week the Slackware Linux project is celebrating its 30th anniversary. It is the oldest Linux distribution that is still in active maintenance and development. The Register reports: Version 1.0 of Slackware was announced on the July 16, 1993, and project lead Patrick Volkerding, who still maintains the distribution today, celebrated with a modest announcement: "Hey folks! It's time to acknowledge another one of those milestones... 30 (!) years since I made the post linked below announcing Slackware's first stable release after months of beta testing. Thanks to all of our dedicated contributors, loyal users, and those who have helped us to keep the lights on here. It's really been a remarkable journey that I couldn't have anticipated starting out back in 1993. Cheers! :-)"

The Register shares its collection of "signs that Wayland is becoming the favored way to get a GUI on Linux." - The team developing Linux for Apple Silicon Macs said they didn't have the manpower to work on X.org support.

- A year ago, the developers of the Gtk toolkit used by many Linux apps and desktops said that the next version may drop support for X11...

- One of the developers of the Budgie desktop, Campbell Jones, recently published a blog post with a wildly controversial title that made The Reg FOSS desk smile: "Wayland is pretty good, actually." He lays out various benefits that Wayland brings to developers, and concludes: "Primarily, what I've learned is that Wayland is actually really well-designed. The writing is on the wall for X, and Wayland really is the future." Partly as a result of this, it looks likely that the next version of the Budgie desktop, Budgie 11, will only support Wayland, completely dropping support for X11. The team point out that this is not such a radical proposition: there was a proposal to make KDE 6 sessions default to Wayland as long ago as last October...

- The GNOME spin of Fedora has defaulted to Wayland since version 25 in 2017, and the GNOME flavor of Ubuntu since 21.04.

- [T]here's now an experimental effort to get Wayland working on OpenBSD. The effort happened at the recent OpenBSD hackathon in Tallinn, Estonia, and the developer's comments are encouraging. It's already available as part of FreeBSD.

SiliconANGLE reports that Red Hat's decision to limit access to RHEL sources "has sparked outrage in some circles," but observers contacted by the publication "were mostly sympathetic" to Red Hat's position: Most acknowledged that the company's explanation that it couldn't keep funding the development of software that competitors then gave away for free was reasonable. But not Bill Ottman, founder and chief executive officer of Minds Inc., a social network built on open-source code." They are completely embarrassing themselves by betraying the community and their own model," he said. "Their best bet is to immediately reverse course and apologize."

Others were more inclined to agree with Josh Amishav, founder and CEO of data breach monitoring firm Breachsense. "If we want commercial entities to support our underlying operating system, they need to find ways to be profitable," he said. "If you disagree with Red Hat's policy change, then there are plenty of excellent Linux alternatives to choose from."

Some saw the move as a consequence of pressure inside IBM to justify the $34 billion it paid to buy Red Hat nearly five years ago. "Red Hat has to change to protect its business," said Joe Brockmeier, head of community at open-source developer Percona LLC and a former Red Hat employee. "They seem to have tried to find the least harmful way to do that. It's a necessary decision, although one that could have been communicated a little better." Brockmeier agreed with Red Hat's argument that it can't continue to fund innovations and give them away for free. "Copying a company's product isn't what open source is about," he said. "The code is what allows every company and individual to run, study, modify and distribute work based on a project. The members of the community can do those things; what they are finding harder to do is to 'clone' RHEL."

Not everyone buys the argument that IBM needed to wring more revenue out of its subsidiary. "Considering IBM's gross profit for [fiscal 2022] was $32.863 billion, this certainly wasn't a make-or-break decision for IBM's profitability," said Kadan Stadelmann, chief technology officer at Komodo, developer of a cryptocurrency and blockchain platform. And there's some risk to Red Hat in closing down source code access. "By totally removing free and open-source software, Red Hat may not necessarily increase revenues that much while alienating its large community of open-source developers," Stadelmann said.

There's evidence that's already happening, at least for now. Red Hat's action has both energized and elevated the profiles of some open-source alternatives.

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.

According to Statcounter, the Linux share on the desktop has passed 3% for the first time. GamingOnLinux reports: While it has been close a couple of times, the trend according to their stats is pretty clear that Linux use has been slowly rising over the last few years. This does not include ChromeOS, even though it's based on Linux, as they track that separately so this is just plain desktop Linux.

Across this year their stats show for Linux:

January - 2.91%
February - 2.94%
March - 2.85%
April - 2.83%
May - 2.7%
June - 3.07%

Linus Torvalds has delivered the first release candidate for version 6.5 of the Linux kernel, but warned this release may not go entirely smoothly. From a report: Torvalds's headline assessment of rc1 is "none of it looks hugely unusual." "The biggest single mention probably goes to what wasn't merged, with the bcachefs pull request resulting in a long thread (we didn't hit a hundred emails yet, but it's not far away)." As The Register reported in 2022, bcachefs is a filesystem that's been in development for nigh on a decade without being added to the kernel.

Kernel-watching outlet Phoronix on Sunday wrote that the filesystem is in good shape but debate over "code changes needed to the kernel outside of the kernel module itself" have proved contentious. As a result, conversation on the Linux kernel mailing list is "often becoming heated" when the topic turns to bcachefs. In his announcement post for rc1, Torvalds wrote "Let's calm this party down."

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."

The June Steam Survey results show that AMD CPUs have gained significant popularity among Linux gamers, with a market share of 67% -- a remarkable 7% increase from the previous month. Phoronix reports: In part that's due to the Steam Deck being powered by an AMD SoC but it's been a trend building for some time of AMD's increasing Ryzen CPU popularity among Linux users to their open-source driver work and continuing to build more good will with the community.

In comparison, last June the AMD CPU Linux gaming marketshare came in at 45% while Intel was at 54%. Or at the start of 2023, AMD CPUs were at a 55% marketshare among Linux gamers. Or if going back six years, AMD CPU use among Linux gamers was a mere 18% during the early Ryzen days. It's also the direct opposite on the Windows side. When looking at the Steam Survey results for June limited to Windows, there Intel has a 68% marketshare to AMD at 32%.

Beyond the Steam Deck, it's looking like AMD's efforts around open-source drivers, AMD expanding their Linux client (Ryzen) development efforts over the past two years, promises around OpenSIL, and other efforts commonly covered on Phoronix are paying off for AMD in wooing over their Linux gaming customer base.

Reactions continue to Red Hat's announcement that they'd start limiting access to Red Hat Enterprise Linux sources, reports Ars Technica: Rocky Linux, launched by CentOS co-founder Greg Kurtzer as a replacement RHEL-compatible distro, announced Thursday that it believes Red Hat's moves "violate the spirit and purpose of open source." Using a few different methods (Universal Base Image containers, pay-per-use public cloud instances), Rocky Linux intends to maintain what it considers legitimate access to RHEL code under the GNU General Public License (GPL) and make the code public as soon as it exists.
"These methods are possible because of the power of GPL," explains Rocky Linux's blog post. "No one can prevent redistribution of GPL software. To reiterate, both of these methods enable us to legitimately obtain RHEL binaries and SRPMs without compromising our commitment to open source software or agreeing to TOS or EULA limitations that impede our rights. Our legal advisors have reassured us that we have the right to obtain the source to any binaries we receive, ensuring that we can continue advancing Rocky Linux in line with our original intentions.... [O]ur unwavering dedication and commitment to open source and the Enterprise Linux community remain steadfast."

"In the unfortunate event that Red Hat decides to ramp up efforts to negatively impact the community, Rocky Linux will persist to continue serving the best interests of the entire open source community. As a reminder, we welcome everyone to contribute to our efforts. You can learn more about how you can join us and all of the various ways to contribute on our wiki."

Ars Technica notes that AlmaLinux is "also working to keep providing RHEL-compatible updates and downstream rebuilds." "The process is more labor intensive as we require gathering data and patches from several sources, comparing them, testing them, and then building them for release," wrote Jack Aboutboul, community manager for AlmaLinux, in a blog post. "But rest assured, updates will continue flowing just as they have been."

The Software Freedom Conservancy's Bradley M. Kuhn weighed in last week with a comprehensive overview of RHEL's business model and its tricky relationship with GPL compliance. Red Hat's business model "skirts" GPL violation but had only twice previously violated the GPL in newsworthy ways, Kuhn wrote. Withholding Complete Corresponding Source (CCS) from the open web doesn't violate the GPL itself, but by doing so, Red Hat makes it more difficult for anyone to verify the company's GPL compliance.

Kuhn expressed sadness that "this long road has led the FOSS community to such a disappointing place."
Red Hat argued that they "do not find value in a RHEL rebuild." Rocky Linux dismissed this view as "narrow-minded," and RHEL-derived AlmaLinux even responded with specific examples, also noting its contributions to the RHEL and CentOS communities. AlmaLinux's community manager wrote "When executed properly, downstream rebuilds provide tremendous value and are a tremendous asset to upstream projects."

And ITWire shares one more reaction: German open source vendor SUSE says it will not be making any changes to its policies on source code access, emphasising "that the freedom to access, modify, and distribute software should remain open to all".

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.

Wikipedia defines the Yocto Project as "a Linux Foundation collaborative open source project whose goal is to produce tools and processes that enable the creation of Linux distributions for embedded and IoT software that are independent of the underlying architecture of the embedded hardware."

This week the Linux Foundation shared an update on the 12-year-old Yocto Project: In an effort to support the community, The Yocto Project announced the first Long Term Support (LTS) release in October 2020. Today, we are delighted to announce that we are expanding the LTS release and extending the lifecycle from 2 to 4 years as standard.

The continued growth of the Yocto Project coincides with the welcomed addition of Exein as a Platinum Member, joining AMD/Xilinx, Arm, AWS, BMW Group, Cisco, Comcast, Intel, Meta and WindRiver. As a Member, Exein brings its embedded security expertise across billions of devices to the core of the Yocto Project...

"The Yocto Project has been at the forefront of OS technologies for over a decade," said Andrew Wafaa, Yocto Project Chairperson. "The adaptability and variety of the tooling provided are clearly making a difference to the community. We are delighted to welcome Exein as a member as their knowledge and experience in providing secure Yocto Project based builds to customers will enable us to adapt to the modern landscape being set by the US Digital Strategy and the EU Cyber Resilience Act."

"We're extremely excited to become a Platinum Partner of the Yocto Project," said Gianni Cuozzo, founder and CEO of Exein. "The Yocto Project is the most important project in the embedded Linux space, powering billions of devices every year. We take great pride in contributing our extensive knowledge and expertise in embedded security to foster a future that is both enhanced and secure for Yocto-powered devices. We are dedicated to supporting the growth of the Yocto Project as a whole, aiming to improve its support for modern languages like Rust, and assist developers and OEMs in aligning with the goals outlined in the EU Cyber Resilience Act."

Linux magazine reports that "Former Snap co-developer Alan Pope, who left Canonical in 2021 after 10 years with the company, has developed unsnap, a script that replaces snaps with Flatpaks where available. The script, hosted on GitHub, has been tested by the developers for use on Ubuntu and all derivatives that offer snapd and packages in the Snap format."

Pope clarifies its status on GitHub: Let's say it's "Pre-alpha", as in "It kinda works on my computer". Unless you plan on contributing (see below) it's probably not ready for you, yet.
And Pope notes the existence of "related projects" like the custom-desktop project by Natan Junges "which provides a set of packages to revert an existing Ubuntu install back to something many users may appreciate more." And "deb-get enables Ubuntu users to install and update deb-based packages of popular applications"

But Linux magazine tested out unsnap: The flatpak list command can be used to determine which snaps were converted to Flatpak format. For snaps with a Flatpak equivalent, unsnap converted these snaps cleanly, and all of the programs remained functional. The script left the remaining snaps and the infrastructure untouched...

An equivalent Flatpak must be available, which is very often the case with graphical applications. With a little manual work, the Snap infrastructure can also be removed.

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."