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

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

Perl 5.38 was released this week "after being in development for more than one year," reports Phoronix. "Perl 5.38 brings a new experimental syntax for defining object classes where per-instance data is stored in 'field' variables that behave like lexicals."

"Maybe, just maybe, the new features introduced into the language in this newest version will attract much sought new talent," writes the site I Programmer, noting the argument that Perl is installed by default everywhere — and has the "fun factor... The class keyword is part of the plan to bring effective object-oriented programming to the Perl core while still keeping Perl being Perl."

The Perl docs warn that "This remains a new and experimental feature, and is very much still under development. It will be the subject of much further addition, refinement and alteration in future releases." But "Since Perl 5, support for objects revolved around the concept of blessing references with a package name," notes updated documentation, which points out this new class syntax "isn't a bless wrapper, but a completely new system built right into the perl interpreter." The class keyword declares a new package which is intended to be a class... classes automatically get a constructor named new... Just like with other references, when object reference count reaches zero it will automatically be destroyed.
Phoronx notes that Perl 5.38 also brings a new PERL_RAND_SEED environment variable "for controlling seed behavior for random number generation," along with some new APIs. And I Programmer adds that Perl 5.38 also adds support for Unicode 15.0, adding 4, 489 characters, for a total of 149,186 characters. Other additions include enhanced regular expressions, plus defined-or and logical-or assignment default expressions in signatures.

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.

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

Prominent KDE developer Nate Graham believes that Plasma 6 is now "fairly livable" and recommends KDE developers and power users / enthusiasts start giving it a try. Phoronix reports: He characterized Plasma 6 as: "Basically everything in Plasma compiles with Qt 6, and at this point Plasma 6 is fairly livable. To give you a sense of how livable, it's good enough that over the past 2 months, I've gone on three KDE-related trips from the USA to Europe, with my only computer running Plasma 6 in "current git master" state, with work-in-progress merge requests applied! Its stability has been good enough that this has caused me no apprehension, and indeed, it's been totally fine on each trip. So seriously, if you're a KDE developer or an adventurous user, start living on Plasma 6! Jump right in, the water's fine. :)"

He went on to write more about the current development activities around Plasma 6. He also shared his personal beliefs around Plasma 6.0 release timing although no official release schedule is yet to be determined. Nate's belief is that Plasma 6.0 will likely be ready for release sometime between December and March.

Linux computer vendor System76 shared some news in a recent blog post. "We prefer to disable the Intel Management Engine wherever possible to reduce the amount of closed firmware running on System76 hardware. We've resolved a coreboot bug that allows the Intel ME (Management Engine) to once again be disabled."

Phoronix reports that the move will "benefit their latest Intel Core 13th Gen 'Raptor Lake' wares as well as prior generation devices." Intel ME is disabled for their latest Raptor lake laptops and most older platforms with some exceptions like where having a silicon issue with Tiger Lake. System76 has also added a new firmware setup menu option for enabling/disabling UEFI Secure Boot. The motivation here with making it easier to toggle Secure Boot is for allowing Windows 11 support with SB active while running System76 Open Firmware.

Linux Foundation Europe "has announced the RISC-V Software Ecosystem (RISE) Project to help facilitate more performant, commercial-ready software for the RISC-V processor architecture," reports Phoronix.

"Among the companies joining the RISE Project on their governing board are Andes, Google, Intel, Imagination Technologies, Mediatek, NVIDIA, Qualcomm, Red Hat, Rivos, Samsung, SiFive, T-Head, and Ventana."

It's top goal is "accelerate the development of open source software for RISC-V," according to the official RISE web site. The project's chair says it "brings together leaders with a shared sense of urgency to accelerate the RISC-V software ecosystem readiness in collaboration with RISC-V International." The CEO of RISC-V International, Calista Redmond, said "We are grateful to the thousands of engineers making upstream contributions and to the organizations coming together now to invest in tools and libraries in support of the RISC-V software ecosystem." RISE Project members will contribute financially and provide engineering talent to address specific software deliverables prioritized by the RISE Technical Steering Committee (TSC). RISE is dedicated to enabling a robust software ecosystem specifically for application processors that includes software development tools, virtualization support, language runtimes, Linux distribution integration, and system firmware, working upstream first with existing open source communities in accordance with open source best practices.

"The RISE Project is dedicated to enabling RISC-V in open source tools and libraries (e.g., LLVM, GCC, etc) to speed implementation and time-to-market," said Gabriele Columbro, General Manager of Linux Foundation Europe.
Google's director of engineering on Android said Google was "excited to partner with industry leaders to drive rapid maturity of the RISC-V software ecosystem in support of Android and more."

And the VP of system software at NVIDIA said "NVIDIA's accelerated computing platform — which includes GPUs, DPUs, chiplets, interconnects and software — will support the RISC-V open standard to help drive breakthroughs in data centers, and a wide range of industries, such as automotive, healthcare and robotics."

Michael Larabel, reporting at Phoronix: AMD engineers have been working out many quirks and oddities in system suspend/resume handling to make it more reliable on their hardware particularly around Ryzen laptops. In addition to suspend/resume reliability improvements and suspend-to-idle (s2idle) enhancements, one of their engineers also discovered an easy one-liner as a small step to speeding up system resume time. AMD engineer Basavaraj Natikar realized a missing check in the USB XHCI driver can avoid an extra 120ms delay during system resume time. It's only 120 ms, but it's a broad win given it's for the XHCI driver code and part of their larger effort of improving the AMD Ryzen platform on Linux and this 120ms savings is from altering one line of code.

After leading CodeWeavers for 27 years, Jeremy White has decided to leave the company, prompting the transition to an employee ownership trust. CodeWeavers is known for its CrossOver software and contributions to the Wine project. Phoronix reports: CodeWeavers' President James Ramey is now taking on the CEO role while Director of Development Ulrich Czekalla in turn is stepping up to fill the President role. Jeremy White does continue to serve as Chairman of the Board at CodeWeavers. In addition to selling the CrossOver software, CodeWeavers' PortJump effort aides organizations in porting apps/games to macOS, Linux, or ChromeOS. CodeWeavers also engages in technical consulting services for organizations. Among CodeWeavers' clients is Valve in assisting them with their Steam Play / Proton effort. You can read more about the changes via the CodeWeavers blog.

Last week Linus Torvalds personally cleaned up the x86 memory copy code for Linux 6.4, Phoronix reports — and this week "he's merged more of his own code as he took issue with some of the code merged by Intel engineers as part of their Linear Address Masking enabling." Back during the Linux 6.2 days at the end of last year, Linus rejected the Intel LAM code at the time for various technical issues. Intel then reworked it for Linux 6.4. This time around Linus merged Intel LAM into Linux 6.4 as this new CPU feature for letting user-space store metadata within some bits of pointers without masking it out before use. Intel LAM — like Arm TBI — can be of use to virtual machines, profiling / sanitizers / tagging, and other applications. But this time around there were some less than ideal code that he personally took to sprucing up...

Torvalds reworked around one hundred lines of code for cleaning it up.
It's fun to read Torvalds' commit messages (included in both Phoronix articles). Torvalds begins by writing that the LAM updates "made me unhappy about how 'access_ok()' was done, and it actually turned out to have a couple of small bugs in it too..."

Phoronix shares some overlooked news from AMD's openSIL presentation at the OCP Regional Summit in April. Specifically, that AMD openSIL — their open-source x86 silicon initialization library — "is planned to eventually replace AMD's well known AGESA [BIOS utility]" around 2026, and "it will be supported across AMD's entire processor stack — just not limited to EPYC server processors as some were initially concerned..." Raj Kapoor, AMD Fellow and AMD's Chief Firmware Architect, in fact began the AMD openSIL presentation by talking about the challenges they've had with AGESA in adapting it to Coreboot for Chromebook purposes with Ryzen SoCs... With AMD openSIL not expected to be production ready until around 2026, this puts it roughly inline for an AMD Zen 6 or Zen 7 introduction. The proof of concept code for AMD Genoa is expected to come soon...

The presentation also noted that beyond AMD openSIL code being open-source, the openSIL specification will also be open. AMD "invites every silicon vendor" to participate in this open-source system firmware endeavor.

Phoronix reports: With the financial backing of Amazon Web Services, sudo and su are being rewritten in the Rust programming language in order to increase the memory safety for the widely relied upon software... to further enhance Linux/open-source security.
"[B]ecause it's written in C, sudo has experienced many vulnerabilities related to memory safety issues," according to a blog post announcing the project: It's important that we secure our most critical software, particularly from memory safety vulnerabilities. It's hard to imagine software that's much more critical than sudo and su.

This work is being done by a joint team from Ferrous Systems and Tweede Golf with generous support from Amazon Web Services. The work plan is viewable here. The GitHub repository is here.

A new set of patches have been released for the Intel Linux graphics driver that "can provide 10-15% better performance when operating in the tuned mode," reports Phoronix. From the report: The set of Intel i915 Linux kernel graphics driver patches are about exposing the Intel RPS (Requested Power State) up/down thresholds. Right now the Intel Linux kernel driver has static values set for the up/down thresholds between power states while these patches would make them dynamically configurable by user-space. Google engineer Syed Faaiz Hussain raised the issue that they experimented with the Intel RPS tuning and were able to manage up to 15% better performance. With Counter-Strike: Global Offensive with OpenGL was a 14.5% boost, CS:GO with Vulkan was 12.9% faster, and Civilization VI with OpenGL was 11% faster while Strange Brigade was unchanged. No other game numbers were provided.

But as this is about changing the threshold for how aggressively the Intel graphics hardware switches power states, the proposed patches leave it up to user-space to adjust the thresholds as they wish. Google engineers are interested in hooking this into Feral's GameMode so that the values could be automatically tuned when launching games and then returning to their former state when done gaming, in order to maximize battery life / power efficiency. The only downside with these current patches are that they work only for non-GuC based platforms... So the latest Alder/Raptor Lake notebooks as well as Intel DG2/Alchemist discrete graphics currently aren't able to make use of this tuning option.

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.

Phoronix reports: If you rely on an Intel I219-LM Gigabit Ethernet adapter, you will want to look forward to upgrading your Linux kernel build soon... A fix was committed Thursday after Intel engineers discovered this particular Ethernet chipset had only been running at around 60% of its maximum speed due to a regression introduced back in 2020...

Since the release of Linux 5.8 in mid-2020, this Ethernet adapter had been running at around 60% of its advertised potential due to an e1000e driver regression.

The Rust team released a new version Thursday — Rust 1.69.0 — boasting over over 3,000 new commits from over 500 contributors.

Phoronix highlights two new improvements: In order to speed-up compilation speeds, Rust 1.69 and moving forward debug information is no longer included in build scripts by default. Cargo will avoid emitting debug information in build scripts by default — leading to less informative backtraces in build scripts when problems arise, but faster build speeds by default. Those wanting the debug information emitted can now set the debug flag in their Cargo.toml configuration.

The Cargo build shipped by Rust 1.69 is also now capable of suggesting fixes automatically for some of the generated warnings. Cargo will also suggest using "cargo fix" / "cargo clippy --fix" when it knows the errors can be automatically fixed.

"The fact remains that Google Chrome is the arbiter of web standards," argues FSF campaigns manager Greg Farough (while adding that Firefox, "through ethical distributions like GNU IceCat and Abrowser, can weaken that stranglehold.")

"Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally." Part of Google's official rationale for the deprecation is the following line: "There is not enough interest from the entire ecosystem to continue experimenting with JPEG-XL." Putting aside the problematic aspects of the term "ecosystem," let us remark that it's easy to gauge the response of the "entire ecosystem" when you yourself are by far the largest and most dangerous predator in said "ecosystem." In relation to Google's overwhelming power, the average web user might as well be a microbe. In supposedly gauging what the "ecosystem" wants, all Google is really doing is asking itself what Google wants...

While we can't link to Google's issue tracker directly because of another freedom issue — its use of nonfree JavaScript — we're told that the issue regarding JPEG-XL's removal is the second-most "starred" issue in the history of the Chromium project, the nominally free basis for the Google Chrome browser. Chromium users came out of the woodwork to plead with Google not to make this decision. It made it anyway, not bothering to respond to users' concerns. We're not sure what metric it's using to gauge the interest of the "entire ecosystem," but it seems users have given JPEG-XL a strong show of support. In turn, what users will be given is yet another facet of the web that Google itself controls: the AVIF format.

As the response to JPEG-XL's deprecation has shown, our rallying together and telling Google we want something isn't liable to get it to change its mind. It will keep on wanting what it wants: control; we'll keep on wanting what we want: freedom.

Only, the situation isn't hopeless. At the present moment, not even Google can stop us from creating the web communities that we want to see: pages that don't run huge chunks of malicious, nonfree code on our computers. We have the power to choose what we run or do not run in our browsers. Browsers like GNU IceCat (and extensions like LibreJS and JShelter> ) help with that. Google also can't prevent us from exploring networks beyond the web like Gemini. What our community can do is rally support behind those free browsers that choose to support JPEG-XL and similar formats, letting the big G know that even if we're smaller than it, we won't be bossed around.

On Thursday patches were submitted for bringing Rust infrastructure to the Video 4 Linux 2 (V4L2) framework (within Linux's media subsystem) by Collabora's Daniel Almeida.

Phoronix reports: This provides just enough for working with a prototype VirtIO camera driver written in Rust along with a Rust sample driver. These initial patches are just intended to start the discussion around V4L2 Rust driver support and the actual upstreaming of the Rust support for these camera drivers may still be some ways down the line.

Further adding to the excitement of the upcoming Linux 6.4 merge window is the mainline kernel seeing the Device Tree (DT) additions for Apple's current M2 devices including the MacBook Air, MacBook Pro, and Mac Mini systems. From a report: The upstream kernel still has more work to go around the M1/M2 support compared to the downstream state with Asahi Linux, but at least now with this DT support will provide some basic level of upstream kernel support for the Apple M2. Asahi Linux lead developer Hector Martin today sent in the Apple SoC DT updates targeting the Linux 6.4 cycle for queuing into the SoC tree ahead of the merge window opening around the end of the month. The main addition with this pull request is adding the Apple M2 Device Tree series.