An anonymous reader shared this article from the Linux blog OMG! Ubuntu: The System Monitor app Ubuntu comes with does an okay job of letting you monitor system resources and oversee running processes — but it does look dated... [T]he app's graphs and charts are tiny, compact, and lack the glanceability and granular-detail that similar tools on other systems offer.

Thankfully, there are plenty of ace System Monitor alternatives available on Linux, with the Rust-based Resources being the latest tool to the join the club. And it's a real looker... Resources shows real-time graphs showing the utilisation of core system components... You can also see a [sortable and searchable] list of running apps and processes, which are separated in this app.
It's also possible to select a refresh interval "from very slow/slow/normal/fast/very fast (though tempting to select, 'very fast' can increase CPU usage)." And selecting an app or process "activates a big red button you can click to 'end' the app/process (a submenu has options to kill, halt, or continue the app/process instead)..."

"If you don't like the 'Windows-iness' of Mission Center — which you may have briefly spotted it in my Ubuntu 23.10 release video — then Resources is a solid alternative."

T2 SDE is not just a Linux distribution, but "a flexible Open Source System Development Environment or Distribution Build Kit," according to a 2022 announcement of its support for 25 CPU architectures, variants, and C libraries. ("Others might even name it Meta Distribution. T2 allows the creation of custom distributions with state of the art technology, up-to-date packages and integrated support for cross compilation.")

And while working on it, Berlin-based T2 Linux developer René Rebe (long-time Slashdot reader ReneR) discovered random illegal instruction speculation on AMD Ryzen 7000-Series and Epyc Zen 4 CPU.

ReneR writes: Merged to Linux 6.6 Git is a fix for the bug now known at AMD as Erratum 1485.

The discovery was possible through continued high CPU load cross-compiling the T2 Linux distribution with support for all CPU architectures from ARM, MIPS, PowerPC, RISC-V to x86 (and more) for 33 build variants. With sustained high CPU load and various instruction sequences being compiled, pseudo random illegal instruction errors were observed and subsequently analyzed.

ExactCODE Research GmbH CTO René Rebe is thrilled that working with AMD engineers lead to a timely mitigation to increase system stability of the still new and highest performance Zen4 platform.
"I found real-world code that might be similar or actually trigger the same bugs in the CPU that are also used for all the Spectre Meltdown and other side-channel security vulnerability mitigations," Rebe says in a video announcement on YouTube.

It took Rebe a tremendous amount of research, and he says now that "all the excessive work changed my mind. Mitigations equals considered harmful... If you want stable, reliable computational results — no, you can't do this. Because as Spectre Meltdown and all the other security issues have proven, the CPUs are nowadays as complex as complex software systems..."

SpzToid writes: Ubuntu 23.10, codenamed Mantic Minotaur, is the 39th Ubuntu release, and it's one of the three smaller interim releases Canonical puts out between long-term support (LTS) versions. This last interim before the next LTS doesn't stand out with bold features you can identify at a glance. But it does set up some useful options and upgrades that should persist in Ubuntu for some time.

Two of the biggest changes in Ubuntu 23.10 are in the installer. Ubuntu now defaults to a "Default installation," which is quite different from what the "default" was even just one release prior. "Default" is described as "Just the essentials, web browser, and basic utilities," while "Full" is "An offline-friendly selection of office tools, utilities, web browser, and games." "Default" is somewhat similar to what "Minimal" used to be in prior versions, while "Full" is intended for those who are offline or have slow connections or just want as many options as possible right away.

Elsewhere in the installer, you can now choose ZFS as your primary file system. There's also an experimental option to set up Trusted Platform Module (TPM) full-disk encryption rather than rely entirely on passphrases to encrypt your disk. This brings Ubuntu up to speed with Windows in offering a way to both secure your system and find out the hard way that you lack a backup key to get in after messing with your boot options. (Kidding! Somewhat.)

Michael Larabel reports via Phoronix: For those making use of GPU-accelerated AV1 video encoding with the latest AMD Radeon graphics hardware on Linux, the upcoming Mesa 23.3 release will support the high-quality AV1 preset for offering higher quality encodes. Merged this week to Mesa 23.3 are the RadeonSI Video Core Next (VCN) changes for supporting the high quality AV1 encoding mode preset.

Mesa 23.3 will be out as stable later this quarter for those after slightly higher quality AV1 encode support for Radeon graphics on this open-source driver stack alongside many other recent Mesa driver improvements especially on the Vulkan side with Radeon RADV and Intel ANV.

Hell freezes over and pigs fly south to their winter feeding grounds. Microsoft has published guidance on how to download and install Linux. From a report: The Seattle-area proprietary OS vendor has published a helpful guide entitled "How to download and install Linux," inspiring reactions from incredulity to amusement. In the humble opinion of The Reg FOSS Desk, it really isn't bad at all. Microsoft suggests four alternative installation methods: using Windows Subsystem for Linux 2, using a local VM, using a cloud VM, or on bare metal. It almost feels cruel to criticize it, but it seems that this really amounts to two methods. WSL version 2 is a VM. It's right there in the screenshots, where it says:

Installing: Virtual Machine Platform
Virtual Machine Platform has been installed.

So the choices boil down to either on the metal, or in a VM. That leaves only the question of what kind of VM: the built-in one, an add-on VM, or a cloud VM. Perhaps the subtext of the article is something more subtle. Could it be a tacit admission that you might need a free-of-charge OS for your PC? The Windows 10 upgrade program that began back in 2015 was meant to end a year later. In fact, it didn't. We described a documented workaround in 2016, but the free upgrades continued to work, even in 2020. Which? magazine reported it was still working in July 2023.

Thursday ZDNet reported... As security holes go, CVE-2023-4911, aka "Looney Tunables," isn't horrid. It has a Common Vulnerability Scoring System score of 7.8, which is ranked as important, not critical.

On the other hand, this GNU C Library's (glibc) dynamic loader vulnerability is a buffer overflow, which is always big trouble, and it's in pretty much all Linux distributions, so it's more than bad enough. After all, its discoverers, the Qualys Threat Research Unit, were able to exploit "this vulnerability (a local privilege escalation that grants full root privileges) on the default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, and Debian 12 and 13." Other distributions are almost certainly vulnerable to attack. The one major exception is the highly secure Alpine Linux. Thanks to this vulnerability, it's trivial to take over most Linux systems as a root user. As the researchers noted, this exploitation method "works against almost all of the SUID-root programs that are installed by default on Linux...."

The good news is that Red Hat, Ubuntu, Debian, and Gentoo have all released their own updates. In addition, the upstream glibc code has been patched with the fix. If you can't patch it, Red Hat has a script that should work on most Linux systems to mitigate the problem by setting your system to terminate any setuid program invoked with GLIBC_TUNABLES in the environment.

It started when Linux blogger Bryan Lunduke complained about how the Linux Foundation was reducing the six-year long-term support (LTS) window for the Linux kernel to two years. Lunduke argued that the Foundation seemed more interested in funding compliance best practices — as well as artificial intelligence and blockchain projects.

In an online discussion, Linux kernel maintainer Greg Kroah-Hartman had this response: Did anyone think to actually ask the developer who is maintaining the long-term support kernel versions why he made that change (back in February?), i.e. me...? No, I guess that would take too much effort, and wouldn't result in such a click-bait headline.

"LTS kernels are no longer supported for 6 years because it turns out no one used them." doesn't have that same fun sound... In a second comment Kroah-Hartman also clarified that in fact "The amount of resources and other stuff that the Linux Foundation provides to the Linux kernel community has increased over the years, including last year. " Just because new people are brought in with new projects (that the LF member companies want to host) does not mean that somehow less is being given to the kernel community at all. It is not a zero-sum game here at all, that's not how the LF works in any way.

Again, this would have been easy to verify if someone just asked us.

So to repeat, no "abandonment" is happening here at all, the opposite is happening, just like it has for the entirety of the Linux Foundation's existence, support has grown every year.
Thanks to long-time Slashdot reader whoever57 for sharing the news.

An anonymous reader quotes a report from ZDNet: Microsoft's proprietary protocol, Remote Network Driver Interface Specification (RNDIS), started with a good idea. It would enable hardware vendors to add networking support to USB devices without having to build them from scratch. There was only one little problem. RNDIS has no security to speak of. As Greg Kroah-Hartman, the Linux Foundation fellow responsible for stable Linux kernel releases, wrote in November 2022 on the Linux Kernel Mailing List (LKML), "The Microsoft RNDIS protocol is, as designed, insecure and vulnerable on any system that uses it with untrusted hosts or devices. Because the protocol is impossible to make secure, just disable all RNDIS drivers to prevent anyone from using them again."

He added, in another message, "The protocol was never designed to be used with untrusted devices. It was created, and we implemented support for it, when we trusted USB devices that we plugged into our systems, AND we trusted the systems we plugged our USB devices into." That's no longer the case. Kroah-Hartman concluded, "Today, with untrusted hosts and devices, it's time just to retire this protocol. As I mentioned in the patch comments, Android disabled this many years ago in their devices, with no loss of functionality."

[...] But now, sick and tired of having a built-in Windows security exploit in Linux, Kroah-Hartman has decided that enough was enough. He's disabled all the RNDIS protocol drivers in Linux's Git repository. That means that while the RNDIS code is still in the Linux kernel, if you try to build Linux using this new patch, all your RNDIS drivers will be broken and won't build. This is one step short of purging RNDIS from Linux.

Yesterday the "temporary suspension" of automatic Snap registrations was announced on Canonical's Snapcraft forum by developer advocate Igor Ljubuncic, after what was described as a "security incident". On September 28, 2023, the Snap Store team was notified of a potential security incident. A number of snap users reported several recently published and potentially malicious snaps. As a consequence of these reports, the Snap Store team has immediately taken down these snaps, and they can no longer be searched or installed. Furthermore, the Snap Store team has placed a temporary manual review requirement on all new snap registrations, effectively immediately...

We apologize for any inconvenience this may cause our snap publishers and developers. However, we believe it is the most prudent action at this moment. We want to thoroughly investigate this incident without introducing any noise into the system, and more importantly, we want to make sure our users have a safe and trusted experience with the Snap Store. Please bear with us while we conduct our investigation. We will provide a more detailed update in the coming days.
Some background from the Linux blog OMG Ubuntu: This isn't the first time the Snap Store has had issues with icky uploads. In 2018 an innocuous-sounding app hid crypto-mining capabilities unbeknownst to users. Not disclosing this in its description rendered it malware (Canonical later clarified to say crypto-miners are allowed so long as they're disclosed).

In this instance it appears that folks have uploaded apps purporting to be official apps/tools for crypto ledger tool Ledger and these apps were able to get folks backups codes (which people enter thinking it's legit) and ...the bad actors can use that to extract funds.

Liam Proven writes via The Register: Steam OS is the Arch-based distro for a handheld Linux games console, and Valve is aggressively pushing Linux's usability and Windows interoperability for the device. Two unusual companies, Valve Software and Igalia, are working together to improve the Linux-based OS of the Steam Deck handheld games console. The device runs a Linux distro called Steam OS 3.0, but this is a totally different distro from the original Steam OS it announced a decade ago. Steam OS 1 and 2 were based on Debian, but Steam OS 3 is based on Arch Linux, as Igalia developer Alberto Garcia described in a talk entitled How SteamOS is contributing to the Linux ecosystem.

He explained that although Steam OS is built from some fairly standard components -- the normal filesystem hierarchy, GNU user space, systemd and dbus -- Steam OS has quite a few unique features. It has two distinct user interfaces: by default, it starts with the Steam games launcher, but users can also choose an option called Switch to Desktop, which results in a regular KDE Plasma desktop, with the ability to install anything: a web browser, normal Linux tools, and non-Steam games.

Obviously, though, Steam OS's raison d'etre is to run Steam games, and most of those are Windows games which will never get native Linux versions. Valve's solution is Proton, an open-source tool to run Windows games on Linux. It's formed from a collection of different FOSS packages, notably: [Wine, DXVK, VKD3D-Proton, and GStreamer]. The result is a remarkable degree of compatibility for some of the most demanding Windows apps around [...]. You can view Garcia's 49-page presentation here (PDF).

slack_justyb writes: Richard Stallman revealed his diagnosis of lymphoma at the GNU Hacker's meeting in Biel, Switzerland yesterday. He did not share much about his health condition but did indicate that it is "manageable" and that he expects to be around for many more years ahead.

An anonymous reader shares a report: The Cloud Native Computing Foundation has returned to Shanghai for the city's first Kubecon since the pandemic. During a keynote that switched languages several times, demonstrating the challenges faced by both AI and human translators in keeping up, Jim Zemlin, executive director of the Linux Foundation, threw out several crowd-pleasing statistics while also highlighting some projects likely to make one or two companies squirm a little. On the statistics front, Zemlin joked that the Linux Foundation was likely the largest software company in the world, noting that if one took an average software developer's salary -- he put the worldwide mean as being $40,000 -- and multiplied it by the number of developers contributing to the foundation, the payroll would come to around $26 billion -- more than Microsoft's $24 billion R&D payroll.

The statistic was somewhat tongue in cheek as Zemlin pointed out that none of the developers working on Linux Foundation projects actually work for the Linux Foundation. However, the sheer quantity of engineers involved highlighted another issue noted by Zemlin: the "paradox of choice" when selecting the correct open source project for a given purpose when the number on offer reaches the hundreds, thousands, and beyond. Reflecting the increasing maturity of some elements of the open source world, he also emphasized the opportunities for companies to increase revenues and profits through the use of open source. WeChat, Alibaba, and Huawei all received nods -- unsurprising considering the location -- as Zemlin noted a virtuous circle whereby improvements go back into projects, meaning better profits, meaning more improvements, and so on. It all sounded very utopian, although darkening clouds were signaled by the addition of OpenTofu to the list of projects Zemlin was keen to boast about, including open source efforts around large language models.

An anonymous reader shared this report from Phoronix: One of the new features merged for the Linux 6.6 kernel was multi-grained timestamps for the VFS layer and wiring it up for the EXT4, Btrfs, XFS, and Tmpfs file-systems. This alternative though to coarse-grained timestamps ended up exposing some problems and this week ahead of Linux 6.6-rc3, the feature has been stripped entirely from the kernel.

Multi-grain timestamps were intended for addressing cases where the current coarse-grained timestamps can be ineffective for updating creation/modification times with a lot of I/O potentially happening within the once per jiffy timestamp... Multi-grained timestamps though were only to be selectively enabled to avoid the performance overhead.

Christian Brauner of Microsoft who originally submitted the feature for Linux 6.6 went ahead and submitted the pull request, which has already been honored, for dropping the short-lived kernel feature... "As there are multiple solutions discussed the honest thing to do here is not to fix this up or disable it but to cleanly revert. The general infrastructure will probably come back but there is no reason to keep this code in mainline."

An anonymous reader quotes a report from TechCrunch: When HashiCorp announced it was changing its Terraform license in August, it set off a firestorm in the open source community, and actually represented an existential threat to startups that were built on top of the popular open source project. The community went into action and within weeks they had written a manifesto, and soon after that launched an official fork called OpenTF. Today, that group went a step further when the Linux Foundation announced OpenTofu, the official name for the Terraform fork, which will live forever under the auspices of the foundation as an open source project. At the same time, the project announced it would be applying for entry into the Cloud Native Computing Foundation (CNCF).

"OpenTofu is an open and community-driven response to Terraform's recently announced license change from a Mozilla Public License v2.0 (MPLv2) to a Business Source License v1.1 providing everyone with a reliable, open source alternative under a neutral governance model," the foundation said in a statement. The name is deliberately playful says Yevgeniy (Jim) Brikman from the OpenTofu founding team, who is also co-founder of Gruntwork. "I'm glad your reaction was to laugh. That's a good thing. We're trying to keep things a little more humorous," Brikman told TechCrunch, but the group is dead serious when it comes to building an open fork. [...]

"The first thing was to get an alpha release out there. So you can go to the OpenTofu website and download OpenTofu and start using it and trying it out," he said. "Then the next thing is a stable release. That's coming in the very near future, but there's work to do. Once you have a stable release, people can start using it. Then we can start growing adoption, and once we start growing adoption, some of the big players will start stepping in when some of the big players start stepping in other big players will start stepping in as well."

At the Open Source Summit Europe in Bilbao, Spain, the Linux Foundation this week announced the launch of the Unified Acceleration (UXL) Foundation. The group's mission is to deliver "an open standard accelerator programming model that simplifies development of performant, cross-platform applications." From a report: The foundation's founding members include the likes of Arm, Fujitsu, Google Cloud, Imagination Technologies, Intel, Qualcomm and Samsung. The company most conspicuously missing from this list is Nvidia, which offers its own CUDA programming model for working with its GPUs. At its core, this new foundation is an evolution of the oneAPI initiative, which is also aimed to create a new programming model to make it easier for developers to support a wide range of accelerators, no matter whether they are GPUs, FPGAs or other specialized accelerators. Like with the oneAPI spec, the aim of the new foundation is to ensure that developers can make use of these technologies without having to delve deep into the specifics of the underlying accelerators and the infrastructure they run on.

Steven Vaughan-Nichols writes via ZDNet: BILBAO, Spain: At the Open Source Summit Europe, Jonathan Corbet, Linux kernel developer and executive editor of Linux Weekly News, caught everyone up with what's new in the Linux kernel and where it's going from here. Here's one major change coming down the road: Long-term support (LTS) for Linux kernels is being reduced from six to two years.

Currently, there are six LTS Linux kernels -- 6.1, 5.15, 5.10, 5.4, 4.19, and 4.14. Under the process to date, 4.14 would roll off in January 2024, and another kernel would be added. Going forward, though, when the 4.14 kernel and the next two drop off, they won't be replaced. Why? Simple, Corbet explained: "There's really no point to maintaining it for that long because people are not using them." I agree. While I'm sure someone out there is still running 4.14 in a production Linux system, there can't be many of them.

Another reason, and a far bigger problem than simply maintaining LTS, according to Corbet, is that Linux code maintainers are burning out. It's not that developers are a problem. The last few Linux releases have involved an average of more than 2,000 programmers -- including about 200 new developers coming on board -- working on each release. However, the maintainers -- the people who check the code to see if it fits and works properly -- are another matter.

Researchers have discovered a never-before-seen backdoor for Linux that's being used by a threat actor linked to the Chinese government. From a report: The new backdoor originates from a Windows backdoor named Trochilus, which was first seen in 2015 by researchers from Arbor Networks, now known as Netscout. They said that Trochilus executed and ran only in memory, and the final payload never appeared on disks in most cases. That made the malware difficult to detect. Researchers from NHS Digital in the UK have said Trochilus was developed by APT10, an advanced persistent threat group linked to the Chinese government that also goes by the names Stone Panda and MenuPass.

Other groups eventually used it, and its source code has been available on GitHub for more than six years. Trochilus has been seen being used in campaigns that used a separate piece of malware known as RedLeaves. In June, researchers from security firm Trend Micro found an encrypted binary file on a server known to be used by a group they had been tracking since 2021. By searching VirusTotal for the file name, ââlibmonitor.so.2, the researchers located an executable Linux file named "mkmon." This executable contained credentials that could be used to decrypt the libmonitor.so.2 file and recover its original payload, leading the researchers to conclude that "mkmon" is an installation file that delivered and decrypted libmonitor.so.2.

The Linux malware ported several functions found in Trochilus and combined them with a new Socket Secure (SOCKS) implementation. The Trend Micro researchers eventually named their discovery SprySOCKS, with "spry" denoting its swift behavior and the added SOCKS component. SprySOCKS implements the usual backdoor capabilities, including collecting system information, opening an interactive remote shell for controlling compromised systems, listing network connections, and creating a proxy based on the SOCKS protocol for uploading files and other data between the compromised system and the attacker-controlled command server.

Slashdot reader Leading Edge Boomer wants to help "a retired friend whose personal computing has always been with Windows."

But recently, they were gifted a laptop that's running "some version of Linux..." Probably he's not even aware that there are different distributions for different purposes. He seems open to learning about this different world. What recommendations might Slashdot readers have to bring him up to speed as a competent Linux user? I really don't want to hold his hand, and he's smart enough to learn on his own.
"Mint is the answer," argues long-time Slashdot reader denisbergeron. "First make him use Mint, because it's easy and there a lot of documentation and the community is very strong."

But long-time Slashdot reader spaceman375 thinks they can solve the problem with just three letters. "Show him the man command. When he feels confident, or breaks it pretty hard, then I'd agree — install mint and go from there. But start with man."

Is that it? Is it as simple as that? Share your own thoughts and opinions in the comments — along with your learning tools for beginners.

What's the best Linux resource for a retired Windows user?

This week saw the public beta-testing release of "Linux Mint Debian Edition". Besides listing download locations, its release notes also list out the project's three goals:

- Ensure Linux Mint would be able to continue to deliver the same user experience
- See how much work would be involved if Ubuntu was ever to disappear.
- Guarantee the software we develop is compatible outside of Ubuntu.

9to5Linux reports: Based on the Debian GNU/Linux 12 "Bookworm" operating system series, Linux Mint Debian Edition 6 is powered by the long-term supported Linux 6.1 LTS kernel series and features the latest Cinnamon 5.8 desktop environment that was introduced with the Linux Mint 21.2 "Victoria" release in July 2023⦠[T]his release comes with a new look and feel thanks to newly added folder icons with different color variants, improved consistency of tooltips to look the same across different apps and desktops, support for symbolic icons that adapt to their background, and full support for HEIF and AVIF

When Linus Torvalds announced Linux kernel 6.6's first release candidate, it included a newly-stable version of KSMBD, which is Samsung's in-kernel server for the SMB protocol (for sharing files/folders/printers over a network).

An announcement in 2021 had said that "For many cases the current userspace server choices were suboptimal either due to memory footprint, performance or difficulty integrating well with advanced Linux features."

LWN noted at the time that Linux has been using "the user-space Samba solution since shortly after the beginning." In a sense, ksmbd is not meant to compete with Samba; indeed, it has been developed in cooperation with the Samba project. It is, however, meant to be a more performant and focused solution than Samba is; at this point, Samba includes a great deal of functionality beyond simple file serving. Ksmbd claims significant performance improvements on a wide range of benchmarks...One other reason — which tends to be spoken rather more quietly — is that a new implementation can be licensed under GPLv2, while Samba is GPLv3.
The Register notes that when Samba switched to GPL 3, "one result was that Apple dropped Samba from Mac OS X and replaced it with its own, in-house server called SMBX." And they also remember that a month after its debut in 2021, "Linux sysadmins got to enjoy KSMBD's first security exploit." What's changed now is that it has faced considerable security testing and as a result it is no longer marked as experimental. It's been developed with the assistance of the Samba team, which itself documents how to use it. It's compatible with existing Samba configuration files. As the team says, "It is not meant to replace the existing Samba fileserver 'smbd', but rather be an extension and will integrate with Samba in the future...."

KSMBD is also important in that placing such core server functionality right inside the kernel represents a significant potential attack surface for crackers... The new bcachefs file system will not be going into kernel 6.6, and its developer is not happy.
"It's taken some time to get KSMBD to a state that was considered stable," points out Linux magazine. That time has come, and KSMBD is planned for Linux kernel 6.6.: But why is KSMBD important? First off, it promises considerable performance gains and better support for modern features such as Remote Direct Memory Access (RDMA)... KSMBD also adds enhanced security, considerably better performance for both single and multi-thread read/write, better stability, and higher compatibility. In the end, hopefully, this KSMBD will also mean easier share setups in Linux without having to jump through the same hoops one must with the traditional Samba setup.

An anonymous reader quotes a report from Ars Technica: A download site surreptitiously served Linux users malware that stole passwords and other sensitive information for more than three years until it finally went quiet, researchers said on Tuesday. The site, freedownloadmanager[.]org, offered a benign version of a Linux offering known as the Free Download Manager. Starting in 2020, the same domain at times redirected users to the domain deb.fdmpkg[.]org, which served a malicious version of the app. The version available on the malicious domain contained a script that downloaded two executable files to the /var/tmp/crond and /var/tmp/bs file paths. The script then used the cron job scheduler to cause the file at /var/tmp/crond to launch every 10 minutes. With that, devices that had installed the booby-trapped version of Free Download Manager were permanently backdoored.

After accessing an IP address for the malicious domain, the backdoor launched a reverse shell that allowed the attackers to remotely control the infected device. Researchers from Kaspersky, the security firm that discovered the malware, then ran the backdoor on a lab device to observe how it behaved. "This stealer collects data such as system information, browsing history, saved passwords, cryptocurrency wallet files, as well as credentials for cloud services (AWS, Google Cloud, Oracle Cloud Infrastructure, Azure)," the researchers wrote in a report on Tuesday. "After collecting information from the infected machine, the stealer downloads an uploader binary from the C2 server, saving it to /var/tmp/atd. It then uses this binary to upload stealer execution results to the attackers' infrastructure."

An anonymous reader quotes a report from 404 Media: Historically, video game preservation efforts usually cover two types of games. The most common are very old or "retro" games from the 16-bit era or earlier, which are trapped on cartridges until they're liberated via downloadable ROMs. The other are games that rely on a live service, like Enter the Matrix's now unplugged servers or whatever games you can only get by downloading them via Nintendo's Wii Shop Channel, which shut down in 2019. But time keeps marching on and a more recent era of games now needs to be attended to if we still want those games to be accessible: indies from the late aughts to mid twenty-teens. That's right. Fez, an icon of the era and indie games scene, is now more than a decade old. And while we don't think of this type of work until we need it, Fez, which most PC players booted on Windows 7 when it first came out, is not going to magically run on your Windows 11 machine today without some maintenance.

The person doing that maintenance, as well as making sure that about 70 of the best known indie games from the same era keep running, is Ethan Lee. He's not as well known as Fez's developer Phil Fish, who was also the subject of the documentary Indie Game: The Movie, but this week Lee started publicly marketing the service he's been quietly providing for over 11 years: maintenance of older games. "The way that I've been pitching it is more of like, the boring infrastructure," he said. "Let's make sure the current build works, whereas a lot of times, people feel like the only way to bring a game into a new generation is to do a big remaster. That's cool, but wouldn't have been cool if Quake II just continued to work between 1997 and now without all the weird stuff in between? That's sort of why I've been very particular about the word maintenance, because it's a continuous process that starts pretty much from the moment that you ship it."

As he explains in his pitch to game developers: "the PC catalog alone has grown very large within the last 15 years, and even small independent studios now have an extensive back catalog of titles that players can technically still buy and play today! This does come at a cost, however: The longer a studio exists, the larger their catalog grows, and as a result, the maintenance burden also grows." Just a few of the other indie games Lee ported include Super Hexagon, Proteus, Rogue Legacy, Dust: An Elysian Tail, TowerFall Ascension, VVVVVV, Transistor, Wizorb, Mercenary Kings, Hacknet, Shenzhen I/O, and Bastion. [...] With the PC, people assume that once a game is on Windows, it can live on forever with future versions of Windows. "In reality, what makes a PC so weird is that there's this big stack of stuff. You have an x86 processor, the current-ish era of like modern graphics processors, and then you have the operating system running on top of that and its various drivers," Lee said. A change to any one of those layers can make a game run badly, or not at all.

The (Arch Linux-powered) Steam Deck was released in February of 2022 — and Phoronix reports that's helping Linux's market share on Steam. "While July was at 1.96% for Linux, the August numbers [from SteamPowered.com] show a 0.14% dip to 1.82%. Interestingly, macOS dipped by 0.27% to 1.57% while Windows rose by 0.4% to 96.61%. For those wondering why the Steam Linux numbers dropped while the Steam Deck continues to be very popular, it's possibly again another month impacted by large swings in Chinese traffic... SteamOS Holo that powers the Steam Deck gained another 2% marketshare to now commanding around 44% of the reported Linux gamers.

Among Linux gamers, AMD CPUs power around 71% of the systems. In part due to the Steam Deck being powered by an AMD APU. Meanwhile Steam on Windows has the AMD CPU marketshare at around 33%.

ZDNet's Steven Vaughan-Nichols shares what's new in the release of Linux 6.5: The biggest news for servers -- and cloud Linux users -- is AMD Ryzen processors' P-State support. This support should mean better performance and power use across CPU cores. Intel Alder Lake CPUs have also received improved load balancing in a related development. RISC-V architecture fans will be pleased to find Linux now has Advanced Configuration and Power Interface (ACPI) support. ACPI is used in Linux and other operating systems for power management. It's vital for laptops and other battery-powered systems.

For better security, people using virtual machines or sandboxes based on Usermode Linux for testing, or running multiple versions of Linux at once, now have Landlock support. Landock is a Linux Security Module that enables applications to sandbox themselves by selecting access rights to directories. It's designed to be used by unprivileged processes while following the system security policy. To make talking with the rest of the world easier, Linux 6.5 now supports USB 4v2. This new USB-C standard will support up to an eye-watering 120Gbps. And while we're still getting used to Wi-Fi 6E, the Wi-Fi Alliance is already working on bringing us Wi-Fi 7. When Wi-Fi 7 arrives, with its theoretical maximum speed of 46Gbps, Linux will be ready. As usual, the new Linux has many more built-in audio and graphics drivers. The Bcachefs filesystem didn't make it into Linux 6.5, notes Vaughan-Nichols. "While the Bcachefs filesystem looks good, there's been a lot of developers fighting about the development process. These personal arguments have led Torvalds to decide not to incorporate Bcachefs into Linux 6.5."

Linus Torvalds announced Linux 6.5's delivery in a brief post on August 27.

When Amazon Linux 2023 was released on March 15, it was supposed to be offered as a virtual machine image that organizations could run on their own servers. From a report: "When Amazon Linux 2023 becomes generally available, it will be provided as a virtual machine image for on-premises use, enabling you to easily develop, test, and certify applications from a local development environment," the web titan's FAQs stated at the time. "This option is not available during the preview." But that commitment has since vanished from the FAQ: it's not there right now nor in this capture of the page on June 2. And it's not clear whether Amazon intends to enable on-premises usage of its Linux distribution.

Those who use Linux in their businesses have been asking Amazon to clarify the situation for eighteen months, starting with a GitHub Issues feature request opened on March 15, 2022, and a similar inquiry posted a year later. In late June, Rotan Hanrahan, a technology consultant based in Dublin, Ireland, chided Amazon for failing to explain what's going on. "I see no evidence of any outreach to the community to explain this, nor any requests for technical assistance (assuming the issue is technical)," he wrote. "If the issue is bureaucratic in nature, we might never see the promised VM image. Some clarification from Amazon is overdue."

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

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.