The upcoming release of GNOME 45 — expected September 20th — will bring new features to the Nautilus file manager (now in public beta testing). An anonymous reader shared this report from 9to5Linux: Nautilus in GNOME 45 already received a search performance boost, support for dropping images directly from web pages, an improved Grid View that now indicates starred files too, the ability to display bytes size as a tooltip for folder properties, and a more adaptive design for the sidebar. It also got an improved file opening experience while sandboxed (think Flatpak, Snap, etc.), a more consistent date and time format, a more simplistic definition of the Keyboard Shortcuts window, the ability to refocus the search bar using the Ctrl+F keyboard shortcut, and a better archiving experience.

But there's room for more new features as Nautilus now received new "Search Everywhere" buttons to expand the search scope and a modern full-height sidebar layout, along with refined sidebar sizing and folding threshold. This is what Nautilus looks like in GNOME 45.
The article includes some screenshots, adding that Nautilus "also received some performance improvements to more quickly generate multiple thumbnails, provide users with flickerless transition into and from search, and avoid DBus-activating other apps when it starts."

An anonymous reader shared this report from 9to5Linux: Just a couple of days after celebrating its 32nd anniversary , Linus Torvalds announced today the final release of the Linux 6.5 kernel series as a major update that introduces several new features, updated and new drivers for better hardware support, and other changes.

After seven weeks of RCs, Linux kernel 6.5 is here with new features like MIDI 2.0 support in ALSA, ACPI support for the RISC-V architecture, Landlock support for UML (User-Mode Linux), better support for AMD "Zen" systems, as well as user-space support for the ARMv8.8 memcpy/memset instructions. Also new in Linux 6.5 is Intel TPMI (Topology Aware Register and PM Capsule Interface) support for the power capping subsystem and a TPMI interface driver for Intel RAPL, and the "runnable boosting" feature in the EAS balancer to improve CPU utilization for specific workloads.

This release also improves SMP scheduling's load balancer to recognize SMT cores with more than one busy sibling and allows lower-priority CPUs to pull tasks to avoid superfluous migrations, and improves EXT4 file system's journalling, block allocator subsystems, and performance for parallel DIO overwrites.

llvm-mos adapts the popular LLVM compiler to target the MOS 6502 processor (the 1980s microprocessor used in early home computing devices like the Apple II and the Commodore 64). So developer Onno Kortman used it to cross-compile semu, a "minimalist RISC-V system emulator capable of running Linux the kernel and corresponding userland." And by the end of the day, Kortman has Linux running on a Commodore 64.

Long-time Slashdot reader johnwbyrd shared the link to Kortman's repository. Some quotes: "But does it run Linux?" can now be finally and affirmatively answered for the Commodore C64...!

It runs extremely slowly and it needs a RAM Expansion Unit (REU), as there is no chance to fit it all into just 64KiB.

It even emulates virtual memory with an MMU....

The screenshots took VICE a couple hours in "warp mode" (activate it with Alt-W) to generate. So, as is, a real C64 should be able to boot Linux within a week or so.

The compiled 6502 code is not really optimized yet, and it might be realistic to squeeze a factor 10x of performance out of this. Maybe even a simple form of JIT compilation? It should also be possible to implement starting a checkpointed VM (quickly precomputed on x86-64) to avoid the lengthy boot process...

I also tested a minimal micropython port (I can clean it up and post it on github if there is interest), that one does not use the MMU and is almost barely remotely usable with lots of optimism at 100% speed.
A key passage: I have not tested it on real hardware yet, that's the next challenge .. for you. So please send me a link to a timelapse video of an original unit with REU booting Linux :D
Its GitHub repository has build and run instructions...

Yes, Red Hat Enterprise Linux changed its licensing last month — but how will that affect AlmaLinux? The chair of the nonprofit AlmaLinux OS Foundation, benny Vasquez, tells SiliconANGLE that "For typical users, there's very, very little difference. Overall, we're still exactly the same way we were, except for kernel updates." Updates may no longer be available the day a new version of RHEL comes out, but developers still have access to Red Hat's planned enhancements and bug fixes via CentOS Stream, a version of RHEL that Red Hat uses as essentially a test bed for new features that might later be incorporated into its flagship product. From a practical perspective, that's nearly as good as having access to the production source code, Vasquez said. "While there is a generally accepted understanding that not everything in CentOS Stream will end up in RHEL, that's not how it works in practice," she said. "I can't think of anything they have shipped in RHEL that wasn't in Stream first."

That's still no guarantee, but the workarounds AlmaLinux has put in place over the past month should address all but the most outlier cases, Vasquez said. The strategy has shifted from bug-for-bug compatibility to being application binary interface-compatible... ABI compatibility doesn't guarantee that problems will never occur, but glitches should be rare and can usually be resolved by recompiling the source code. "It is sufficient for us to be ABI-compatible with RHEL," Vasquez said. "The most important thing is that this allows our community to feel stability."

In fact, Red Hat's change of direction has been a blessing in disguise for AlmaLinux, she said... "We view this as a release from our bonds of being one-to-one." Patches can be applied without waiting for a cue from Red Hat and "we get to engage with our community in a completely new and exciting way." AlmaLinux has also seen a modest financial windfall from Red Hat's decision. "The outpouring of support has been pretty impressive," Vasquez said. "People have shown up for event staffing and website maintenance and infrastructure management and we've gotten more financial backing from corporations."
Vasquez also told the site that "the number of everyday people throwing in $5 has more than quadrupled."

Two years after being listed on the Frankfurt Stock Exchange, the Linux-for-enterprise company SUSE is switching back to private ownership. The Register reports: On Wednesday the developer announced that its majority shareholder, an entity called Marcel LUX III SARL, intends to take it private by delisting it from the Frankfurt Stock Exchange and merging it with an unlisted Luxembourg entity. Marcel is an entity controlled by EQT Private Equity, a Swedish investment firm, which acquired it from MicroFocus in 2018.

The announcement offers scant detail about the rationale for the delisting, other than a canned quote from SUSE CEO Dirk-Peter van Leeuwen who said, "I believe in the strategic opportunity of taking the company private -- it gives us the right setting to grow the business and deliver on our strategy with the new leadership team in place." Van Leeuwen took the big chair at SUSE just over three months back, on May 1. The deal values SUSE at 16 euros per share -- well below the 30-euro price of the 2021 float, but above the Thursday closing price of 9.605 euros.

Interestingly, Marcel is happy for shareholders not to take the money and run. "There is no obligation for shareholders to accept the Offer," explains the announcement's detail of the transaction's structure. "EQT Private Equity does not intend to pursue a squeeze-out. Therefore, shareholders who wish to stay invested in SUSE in a private setting may do so." Shareholders who stick around will therefore score their portion of a special dividend SUSE will pay out as part of this transaction. Those who sell will get the aforementioned 16-euros per share, less their portion of the interim dividend. The transaction to take SUSE private is expected to conclude in the final quarter of 2023.

Debian blog: Over 30 years ago the late Ian Murdock wrote to the comp.os.linux.development newsgroup about the completion of a brand-new Linux release which he named "The Debian Linux Release." He built the release by hand, from scratch, so to speak. Ian laid out guidelines for how this new release would work, what approach the release would take regarding its size, manner of upgrades, installation procedures; and with great care of consideration for users without Internet connection. Unaware that he had sparked a movement in the fledgling F/OSS community, Ian worked on and continued to work on Debian. The release, now aided by volunteers from the newsgroup and around the world, grew and continues to grow as one of the largest and oldest FREE operating systems that still exist today.

Debian at its core is comprised of Users, Contributors, Developers, and Sponsors, but most importantly, People. Ians drive and focus remains embedded in the core of Debian, it remains in all of our work, it remains in the minds and hands of the users of The Universal Operating System. The Debian Project is proud and happy to share our anniversary not exclusively unto ourselves, instead we share this moment with everyone, as we come together in celebration of a resounding community that works together, effects change, and continues to make a difference, not just in our work but around the world. Debian is present in cluster systems, datacenters, desktop computers, embedded systems, IoT devices, laptops, servers, it may possibly be powering the web server and device you are reading this article on, and it can also be found in Spacecraft.

OS News' managing editor calls Firefox "the single most important desktop Linux application," shipping in most distros (with some users later opting for a post-installation download of Chrome).

But "I'm genuinely worried about the state of browsers on Linux, and the future of Firefox on Linux in particular..." While both GNOME and KDE nominally invest in their own two browsers, GNOME Web and Falkon, their uptake is limited and releases few and far between. For instance, none of the major Linux distributions ship GNOME Web as their default browser, and it lacks many of the features users come to expect from a browser. Falkon, meanwhile, is updated only sporadically, often going years between releases. Worse yet, Falkon uses Chromium through QtWebEngine, and GNOME Web uses WebKit (which are updated separately from the browser, so browser releases are not always a solid metric!), so both are dependent on the goodwill of two of the most ruthless corporations in the world, Google and Apple respectively.

Even Firefox itself, even though it's clearly the browser of choice of distributions and Linux users alike, does not consider Linux a first-tier platform. Firefox is first and foremost a Windows browser, followed by macOS second, and Linux third. The love the Linux world has for Firefox is not reciprocated by Mozilla in the same way, and this shows in various places where issues fixed and addressed on the Windows side are ignored on the Linux side for years or longer. The best and most visible example of that is hardware video acceleration. This feature has been a default part of the Windows version since forever, but it wasn't enabled by default for Linux until Firefox 115, released only in early July 2023. Even then, the feature is only enabled by default for users of Intel graphics — AMD and Nvidia users need not apply. This lack of video acceleration was — and for AMD and Nvidia users, still is — a major contributing factor to Linux battery life on laptops taking a serious hit compared to their Windows counterparts... It's not just hardware accelerated video decoding. Gesture support has taken much longer to arrive on the Linux version than it did on the Windows version — things like using swipes to go back and forward, or pinch to zoom on images...

I don't see anyone talking about this problem, or planning for the eventual possible demise of Firefox, what that would mean for the Linux desktop, and how it can be avoided or mitigated. In an ideal world, the major stakeholders of the Linux desktop — KDE, GNOME, the various major distributions — would get together and seriously consider a plan of action. The best possible solution, in my view, would be to fork one of the major browser engines (or pick one and significantly invest in it), and modify this engine and tailor it specifically for the Linux desktop. Stop living off the scraps and leftovers thrown across the fence from Windows and macOS browser makers, and focus entirely on making a browser engine that is optimised fully for Linux, its graphics stack, and its desktops. Have the major stakeholders work together on a Linux-first — or even Linux-only — browser engine, leaving the graphical front-end to the various toolkits and desktop environments....

I think it's highly irresponsible of the various prominent players in the desktop Linux community, from GNOME to KDE, from Ubuntu to Fedora, to seemingly have absolutely zero contingency plans for when Firefox enshittifies or dies...

Why aren't more people using Linux on the desktop? Slashdot reader technology_dude shares one solution: Jack Wallen at ZDNet says establishing an "official" version of Linux may (or may not) help Linux on the desktop increase the number of users, mostly as someplace to point new users. It makes sense to me. What does Slashdot think and what would be the challenges, other than acceptance of a particular flavor?
Wallen argues this would also create a standard for hardware and software vendors to target, which "could equate to even more software and hardware being made available to Linux." (And an "official" Linux might also be more appealing to business users.) Wallen suggests it be "maintained and controlled by a collective of people from users, developers, and corporations (such as Intel and AMD) with a vested interest in the success of this project... There would also be corporate backing for things like marketing (such as TV commercials)." He also suggests basing it on Debian, and supporting both Snap and Flatpak...

In comments on the original submission, long-time Slashdot reader bobbomo points instead to kernel.org, arguing "There already is an official version of Linux called mainline. Everything else is backports." And jd (Slashdot user #1,658) believes that the official Linux is the Linux Standard Base. "All distributions, more-or-less, conform to the LSB, which gives you a pseudo 'official' Linux. About the one variable is the package manager. And there are ways to work around that."

Unfortunately, according to Wikipedia... The LSB standard stopped being updated in 2015 and current Linux distributions do not adhere to or offer it; however, the lsb_release command is sometimes still available.[citation needed] On February 7, 2023, a former maintainer of the LSB wrote, "The LSB project is essentially abandoned."
That post (on the lsb-discuss mailing list) argues the LSB approach was "partially superseded" by Snaps and Flatpaks (for application portability and stability). And of course, long-time Slashdot user menkhaura shares the obligatory XKCD comic...

It's not exactly the same thing, but days after ZDNet's article, CIQ, Oracle, and SUSE announced the Open Enterprise Linux Association, a new collaborative trade association to foster "the development of distributions compatible with Red Hat Enterprise Linux."

So where does that leave us? Share your own thoughts in the comments.

And should there be an "official" version of Linux?

In a groundbreaking move, CIQ, Oracle, and SUSE have come together to announce the formation of the Open Enterprise Linux Association (OpenELA). From a report: The goal of this new collaborative trade association is to foster "the development of distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free enterprise Linux source code."

The inception of OpenELA is a direct response to Red Hat's recent alterations to RHEL source code availability. This new Delaware 501(c)(6) US nonprofit association will provide an open process for organizations to access source code. This will enable it to build RHEL-compatible distributions. The initiative underscores the importance of community-driven source code, which serves as a foundation for creating compatible distributions.

Mike McGrath, Red Hat's vice president of Red Hat Core Platforms, sparked this when he announced Red Hat would be changing how users can access RHEL's source code. For the non-Hatters among you, Core Platforms is the division in charge of RHEL. McGrath wrote, "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."

This made it much more difficult for RHEL clone vendors, such as AlmaLinux, Rocky Linux, and Oracle Linux, to create perfect RHEL variant distributions. AlmaLinux elected to try to work with Red Hat's new source code rules. Oracle restarted its old fighting ways with IBM/Red Hat; SUSE announced an RHEL-compatible distro fork plan; and Rocky Linux found new ways to obtain RHEL code. Now the last two, along with CIQ, which started Rocky Linux, have joined forces.

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.

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