The Tor Project: Today the Tor Project, a global non-profit developing tools for online privacy and anonymity, and Tails, a portable operating system that uses Tor to protect users from digital surveillance, have joined forces and merged operations. Incorporating Tails into the Tor Project's structure allows for easier collaboration, better sustainability, reduced overhead, and expanded training and outreach programs to counter a larger number of digital threats. In short, coming together will strengthen both organizations' ability to protect people worldwide from surveillance and censorship.

Countering the threat of global mass surveillance and censorship to a free Internet, Tor and Tails provide essential tools to help people around the world stay safe online. By joining forces, these two privacy advocates will pool their resources to focus on what matters most: ensuring that activists, journalists, other at-risk and everyday users will have access to improved digital security tools.

In late 2023, Tails approached the Tor Project with the idea of merging operations. Tails had outgrown its existing structure. Rather than expanding Tails's operational capacity on their own and putting more stress on Tails workers, merging with the Tor Project, with its larger and established operational framework, offered a solution. By joining forces, the Tails team can now focus on their core mission of maintaining and improving Tails OS, exploring more and complementary use cases while benefiting from the larger organizational structure of The Tor Project.

This solution is a natural outcome of the Tor Project and Tails' shared history of collaboration and solidarity. 15 years ago, Tails' first release was announced on a Tor mailing list, Tor and Tails developers have been collaborating closely since 2015, and more recently Tails has been a sub-grantee of Tor. For Tails, it felt obvious that if they were to approach a bigger organization with the possibility of merging, it would be the Tor Project.

"Looks like there's a storm brewing, and it's not good news," writes ancient Slashdot reader jd. "Whether or not the bugs are classically security defects or not, this is extremely bad PR for the Linux and Open Source community. It's not clear from the article whether this affects other Open Source projects, such as FreeBSD." From a report: A critical unauthenticated Remote Code Execution (RCE) vulnerability has been discovered, impacting all GNU/Linux systems. As per agreements with developers, the flaw, which has existed for over a decade, will be fully disclosed in less than two weeks. Despite the severity of the issue, no Common Vulnerabilities and Exposures (CVE) identifiers have been assigned yet, although experts suggest there should be at least three to six. Leading Linux distributors such as Canonical and RedHat have confirmed the flaw's severity, rating it 9.9 out of 10. This indicates the potential for catastrophic damage if exploited. However, despite this acknowledgment, no working fix is still available. Developers remain embroiled in debates over whether some aspects of the vulnerability impact security.

The Rust vs C battle raging in Linux circles has left even Linus Torvalds scratching his head. "I'm not sure why Rust has been such a contentious area," the Linux creator mused at this week's Open Source Summit, likening the fervor to ancient text editor wars. "It reminds me of when I was young and people were arguing about vi versus Emacs."

The spat over integrating Rust into Linux has been brewing since 2022, with critics slamming it as an "insult" to decades of kernel work. One maintainer recently quit, fed up with the "nontechnical nonsense." Torvalds struck a surprisingly diplomatic tone. He praised how Rust has "livened up discussions" while admitting some arguments get "nasty." "C is, in the end, a very simple language," Torvalds said, explaining its appeal and pitfalls. "Because it's simple it's also very easy to make mistakes. And Rust is not." Torvalds remains upbeat about Rust's future in Linux, nonetheless. "Even if it were to become a failure -- and I don't think it will -- that's how you learn," he said.

ZDNet's Steven Vaughan-Nichols reports: After 20 years, Real-Time Linux (PREEMPT_RT) is finally -- finally -- in the mainline kernel. Linus Torvalds blessed the code while he was at Open Source Summit Europe. [...] The real-time Linux code is now baked into all Linux distros as of the forthcoming Linux 6.12 kernel. This means Linux will soon start appearing in more mission-critical devices and industrial hardware. But it took its sweet time getting here. An RTOS is a specialized operating system designed to handle time-critical tasks with precision and reliability. Unlike general-purpose operating systems like Windows or macOS, an RTOS is built to respond to events and process data within strict time constraints, often measured in milliseconds or microseconds. As Steven Rostedt, a prominent real-time Linux developer and Google engineer, put it, "Real-time is the fastest worst-case scenario." He means that the essential characteristic of an RTOS is its deterministic behavior. An RTOS guarantees that critical tasks will be completed within specified deadlines. [...]

So, why is Real-Time Linux only now completely blessed in the kernel? "We actually would not push something up unless we thought it was ready," Rostedt explained. "Almost everything was usually rewritten at least three times before it went into mainline because we had such a high bar for what would go in." In addition, the path to the mainline wasn't just about technical challenges. Politics and perception also played a role. "In the beginning, we couldn't even mention real-time," Rostedt recalled. "Everyone said, 'Oh, we don't care about real-time.'" Another problem was money. For many years funding for real-time Linux was erratic. In 2015, the Linux Foundation established the Real-Time Linux (RTL) collaborative project to coordinate efforts around mainlining PREEMPT_RT.

The final hurdle for full integration was reworking the kernel's print_k function, a critical debugging tool dating back to 1991. Torvalds was particularly protective of print_k --He wrote the original code and still uses it for debugging. However, print_k also puts a hard delay in a Linux program whenever it's called. That kind of slowdown is unacceptable in real-time systems. Rostedt explained: "Print_k has a thousand hacks to handle a thousand different situations. Whenever we modified print_k to do something, it would break one of these cases. The thing about print_k that's great about debugging is you can know exactly where you were when a process crashed. When I would be hammering the system really, really hard, and the latency was mostly around maybe 30 microseconds, and then suddenly it would jump to five milliseconds." That delay was the print_k message. After much work, many heated discussions, and several rejected proposals, a compromise was reached earlier this year. Torvalds is happy, the real-time Linux developers are happy, print_K users are happy, and, at long last, real-time Linux is real.

An anonymous reader quotes a report from ZDNet, written by Steven Vaughan-Nichols: In a candid keynote chat at the Linux Foundation's Open Source Summit Europe, Linux creator Linus Torvalds shared his thoughts on kernel development, the integration of Rust, and the future of open source. Dirk Hohndel, Verizon's Open Source Program Office head and Torvalds friend, moderated their conversation about the Linux ecosystem. Torvalds emphasized that kernel releases, like the recent 6.11 version, are intentionally not exciting. "For almost 15 years, we've had a very good regular cadence of releases," he explained. With releases every nine weeks, this regularity aims for timeliness and reliability rather than flashy new features. The Linux creator noted that while drivers still make up the bulk of changes, core kernel development continues to evolve. "I'm still surprised that we're doing very core development," Torvalds said, mentioning ongoing work in virtual file systems and memory management. [...]

Shifting back to another contentious subject -- maintainer burnout and succession planning -- Hohndel observed that "maintainers are aging. Strangely, some of us have, you know, not quite as much or the right hair color anymore." (Torvalds interjected that "gray is the right color.") Hohndel continued, "So the question that I always ask myself: Is it about time to talk about there being a mini-Linus?" Torvalds turned the question around. True, the Linux maintainers are getting older and people do burn out and go away. "But that's kind of normal. What is not normal is that people actually stay around for decades. That's the unusual thing, and I think that's a good sign." At the same time, Torvalds admitted, it can be intimidating for a younger developer to join the Linux kernel team "when you see all these people who have been around for decades, but at the same time, we have many new developers. Some of those new developers come in, and three years later, they are top maintainers."

Hohndel noted that "to be the king of Linux, the main maintainer, you have to have a lot of experience. And the backup right now is Greg KH (Greg Kroah-Hartman, maintainer of the stable Linux kernel), who is about the same age as we are and has even less hair." True, Torvalds responded, "But the thing is, Greg hasn't always been Greg. Before Greg, there's been Andrew {Morton) and Alan (Cox). After Greg, there will be Shannon and Steve. The real issue is you have to have a person or a group of people that the development community can trust, and part of trust is fundamentally about having been around for long enough that people know how you work, but long enough does not mean to be 30 years." Hohndel made one last comment: "What I'm trying to say is, you've been doing this for 33 years. I don't want to be morbid, but I think in 33 years, you may no longer be doing this?" Torvalds, making motions as though he was using a walker, replied, "I would love to still do this conference with you." The report notes the contention around the integration of Rust, highlighted by the recent departure of Rust for Linux maintainer Wedson Filho. Despite resistance from some devs who prefer C and are skeptical of Rust, Torvalds remains optimistic about Rust's future in the kernel.

He said: "Rust is a very different thing, and there are a lot of people who are used to the C model. They don't like the differences, but that's OK. In the kernel itself, absolutely nobody understands everything. I don't. I rely heavily on maintainers of various subsystems. I think the same can be true of Rust and C. I think it's one of our strengths in the kernel that we can specialize. Clearly, some people just don't like the notion of Rust and having Rust encroach on their area. But we've only been doing Rust for a couple of years, so it's way too early to say Rust is a failure."

Meanwhile, Torvalds confirmed that the long-anticipated real-time Linux (RTLinux) project will finally be integrated into the kernel with the upcoming release of Linux 6.12.

Linux creator Linus Torvalds has released version 6.11 of the open-source operating system kernel. The new release, while not considered major by Torvalds, introduces several notable improvements for AMD hardware users and Arch Linux developers. ZDNet: This latest version introduces several enhancements, particularly for AMD hardware users, while offering broader system improvements and new capabilities. These include:
RDNA4 Graphics Support: The kernel now includes baseline support for AMD's upcoming RDNA4 graphics architecture. This early integration bodes well for future AMD GPU releases, ensuring Linux users have day-one support.
Core Performance Boost: The AMD P-State driver now includes handling for AMD Core Performance Boost. This driver gives AMD Core users more granular control over turbo and boost frequency ranges.
Fast Collaborative Processor Performance Control (CPPC) Support: Overclockers who want the most power possible from their computers will be happy with this improvement to the AMD P-State driver. This feature enhances power efficiency on recent Ryzen (Zen 4) mobile processors. This can improve performance by 2-6% without increasing power consumption.
AES-GCM Crypto Performance: AMD and Intel CPUs benefit from significantly faster AES-GCM encryption and decryption processing, up to 160% faster than previous versions.

Last October Slashdot reported on René Rebe's discovery of a random illegal instruction speculation bug on AMD Ryzen 7000-series and Epyc Zen 4 CPUs — which Rebe discussed on his YouTube channel.

But this week's YouTube episode had a different ending, reports Tom's Hardware... Two days ago, tech streamer and host of Code Therapy René Rebe was streaming one of many T2 Linux (his own custom distribution) development sessions from his office in Germany when he abruptly had to remove his microphone and walk off camera due to the arrival of police officers. The officers subsequently cuffed him and took him to the station for an hour of questioning, a span of time during which the stream continued to run until he made it back...

[T]he police seemingly have no idea who did it and acted based on a tip sent with an email. Finding the perpetrators could take a while, and options will be fairly limited if they don't also live in Germany.
Rebe has been contributing to Linux "since as early as 1998," according to the article, "and started his own T2 SD3 Embedded Linux distribution in 2004, as well." (And he's also a contributor to many other major open source projects.)

The article points out that Linux and other communities "are compelled by little-to-no profit motive, so in essence, René has been providing unpaid software development for the greater good for the past two decades."

Efforts to add Rust code to the Linux kernel has suffered a setback as one of the maintainers of the Rust for Linux project has stepped down -- citing frustration with "nontechnical nonsense," according to The Register: Wedson Almeida Filho, a software engineer at Microsoft who has overseen the Rust for Linux project, announced his resignation in a message to the Linux kernel development mailing list. "I am retiring from the project," Filho declared. "After almost four years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them."

[...] Memory safety bugs are regularly cited as the major source of serious software vulnerabilities by organizations overseeing large projects written in C and C++. So in recent years there's been a concerted push from large developers like Microsoft and Google, as well as from government entities like the US Cybersecurity and Infrastructure Security Agency, to use memory-safe programming languages -- among them Rust. Discussions about adding Rust to Linux date back to 2020 and were realized in late 2022 with the release of Linux 6.1. "I truly believe the future of kernels is with memory-safe languages," Filho's note continued. "I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix."

New submitter meisdug writes: A new feature has been submitted for inclusion in Linux 6.12, allowing the display of a QR code when a kernel panic occurs using the DRM Panic handler. This QR code can capture detailed error information that is often missed in traditional text-based panic messages, making it more user-friendly. The feature, written in Rust, is optional and can be enabled via a specific build switch. This implementation follows similar ideas from other operating systems and earlier discussions in the Linux community.

An anonymous reader quotes a report from overkill.wtf: The team behind popular emulation tool EmuDeck is today announcing something rather special: they've spent the first half of 2024 working on their very first hardware product, called the EmuDeck Machine, and it's due to arrive before the year is out. This EmuDeck Machine is an upcoming, crowdfunded, retro emulation mini PC running Bazzite, a Linux-based system similar to SteamOS. [...] This new EmuDeck Machine comes in two variants, the EM1 running an Intel N97 APU, and the EM2 -- based on an AMD Ryzen 8600G. While both machines are meant as emulation-first devices, the AMD-based variant can easily function as a console-like PC. This is also thanks to some custom work done by the team: "We've optimized the system for maximum power. The default configuration of an 8600G gets you 32 FPS in Cyberpunk; we've managed to reach 47 FPS with a completely stable system, or 60FPS if you use FSR."

Both machines will ship with a Gamesir Nova Lite controller and EmuDeck preinstalled naturally. The team has also preinstalled all available Decky plugins. But that's not all: if the campaign is successful, the EmuDeck team will also work on a docking station for the EM2 that will upgrade the graphics to an AMD Radeon 7600 desktop GPU. With this, in games like Cyberpunk 2077, you'll be able to reach 160 FPS in 1080p as per EmuDeck's measurements. You can preorder the EmuDeck Machines via Indigogo, starting at $322 and shipping in December.

The Register's Liam Proven reports: Microsoft's in-house professional networking site is moving to Microsoft's in-house Linux. This could mean that big changes are coming for the former CBL-Mariner distro. Ievgen Priadka's post on the LinkedIn Engineering blog, titled Navigating the transition: adopting Azure Linux as LinkedIn's operating system, is the visible sign of what we suspect has been a massive internal engineering effort. It describes some of the changes needed to migrate what the post calls "most of our fleet" from the end-of-life CentOS 7 to Microsoft Azure Linux -- the distro that grew out of and replaced its previous internal distro, CBL-Mariner.

This is an important stage in a long process. Microsoft acquired LinkedIn way back in 2016. Even so, as recently as the end of last year, we reported that a move to Azure had been abandoned, which came a few months after it laid off almost 700 LinkedIn staff -- the majority in R&D. The blog post is over 3,500 words long, so there's quite a lot to chew on -- and we're certain that this has been passed through and approved by numerous marketing and management people and scoured of any potentially embarrassing admissions. Some interesting nuggets remain, though. We enjoyed the modest comment that: "However, with the shift to CentOS Stream, users felt uncertain about the project's direction and the timeline for updates. This uncertainty created some concerns about the reliability and support of CentOS as an operating system." [...]

There are some interesting technical details in the post too. It seems LinkedIn is running on XFS -- also the RHEL default file system, of course -- with the notable exception of Hadoop, and so the Azure Linux team had to add XFS support. Some CentOS and actual RHEL is still used in there somewhere. That fits perfectly with using any of the RHELatives. However, the post also mentions that the team developed a tool to aid with deploying via MaaS, which it explicitly defines as Metal as a Service. MaaS is a Canonical service, although it does support other distros -- so as well as CentOS, there may have been some Ubuntu in the LinkedIn stack as well. Some details hint at what we suspect were probably major deployment headaches. [...] Some of the other information covers things the teams did not do, which is equally informative. [...]

"At The Linux Foundation's Open Source Summit China conference, Linus Torvalds and his buddy Dirk Hohndel, Verizon's Head of the Open Source Program Office, once more chatted about Linux development and related issues," reports ZDNet: Torvalds: "Later this year, we will have the 20th anniversary of the real-time Linux project. This is a project that literally started 20 years ago, and the people involved are finally at that point where they feel like it is done... well, almost done. They're still tweaking the last things, but they hope it will soon be ready to be completely merged in the upstream kernel this year... You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management...."

Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust." On top of that, Torvalds commented, "Another reason has been the Rust infrastructure itself has not been super stable...."

The pair then moved on to the hottest of modern tech topics: AI. While Torvalds is skeptical about the current AI hype, he is hopeful that AI tools could eventually aid in code review and bug detection. In the meantime, though, Torvalds is happy about AI's side effects. For example, he said, "When AI came in, it was wonderful, because Nvidia got much more involved in the kernel. Nvidia went from being on my list of companies who are not good to my list of companies who are doing really good work."

Linux creator Linus Torvalds expressed disappointment with the slow adoption of Rust in the Linux kernel at the Linux Foundation's Open Source Summit China. In a conversation with Verizon executive Dirk Hohndel, Torvalds said, "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different." This resistance has led to "some pushback on Rust," he said. "Another reason has been the Rust infrastructure itself has not been super stable," he added.

Phoronix's Michael Larabel benchmarked AMD's latest Ryzen 9 9950X in several different Linux distros and found that the Zen 5 chip performs up to 16% faster with the Intel-optimized Clear Linux distro. Here's an excerpt from the report: The Linux distributions for this round of testing on the AMD Ryzen 9 9950X included Arch Linux, CachyOS, Clear Linux, Fedora Workstation 40, Ubuntu 24.04 LTS, and a recent daily snapshot of Ubuntu 24.10 in its current development form. Intel's Clear Linux is the one most interesting for looking at on the new AMD Zen 5 hardware. While there hasn't been so much Clear Linux news in recent times, it remains the most well optimized x86_64 Linux distribution out of the box. Clear Linux makes use of compiler function multi versioning, performance-minded defaults, aggressive compiler CFLAGS/CXXFLAGS defaults, optional AVX-512 usage for more libraries, and many other patches and optimizations in the name of delivering the greatest x86_64 Linux performance. And while not Intel's focus, it works typically on AMD hardware too. [...]

Using the same Ryzen 9 9950X system, all of these Linux distributions were tested in their default / out-of-the-box state. [...] When taking the geometric mean of 59 benchmarks run across all of the Linux distributions on this AMD Ryzen 9 9950X system, Intel's Clear Linux easily took the crown. Ubuntu 24.04 LTS -- which was used for all of the Ryzen 9000 series Linux testing so far on Phoronix -- was the slowest. Tapping Intel's Clear Linux netted a 16% improvement on top of the performance offered by Ubuntu 24.04 LTS! Ubuntu 24.04 with the Ryzen 9000 series was already looking great generationally, but as shown today the performance can be even better with further software optimizations.

The Arch Linux powered CachyOS that is tuned out-of-the-box with a similar aim to Clear Linux also performed great. CachyOS was 7% faster than Ubuntu 24.04 LTS based on the geo mean and 3% faster than upstream Arch Linux itself. For different workloads though the CachyOS advantage over Arch Linux varied from a minimal difference to quite significant advantages. From the performance of PHP and Python scripts atop Clear Linux to compiling various server and HPC minded software, Intel's Clear Linux -- and a commendable second place for CachyOS -- were showing that even greater performance can be achieved on the AMD Ryzen 9 9950X. Even for devoted Ubuntu Linux users, these results did show some nice advantages of the upcoming Ubuntu 24.10 release over Ubuntu 24.04 LTS thanks to the GCC 14 compiler. Ubuntu 24.10 performance is also still subject to change since the current daily ISOs haven't yet moved past the Linux 6.8 kernel while Ubuntu 24.10 in October will be shipping with Linux 6.11.

bobdevine writes: The Linux operating system has reached a notable milestone in desktop market share, according to the latest data from StatCounter. As of July 2024, Linux has achieved a 4.45% market share for desktop operating systems worldwide. While this percentage might seem small to those unfamiliar with the operating system landscape, it represents a significant milestone for Linux and its dedicated community. What makes this achievement even more thrilling is the upward trajectory of Linux's adoption rate.

Ars Technica's Dan Goodwin writes: Last Tuesday, loads of Linux users -- many running packages released as early as this year -- started reporting their devices were failing to boot. Instead, they received a cryptic error message that included the phrase: "Something has gone seriously wrong." The cause: an update Microsoft issued as part of its monthly patch release. It was intended to close a 2-year-old vulnerability in GRUB, an open source boot loader used to start up many Linux devices. The vulnerability, with a severity rating of 8.6 out of 10, made it possible for hackers to bypass secure boot, the industry standard for ensuring that devices running Windows or other operating systems don't load malicious firmware or software during the bootup process. CVE-2022-2601 was discovered in 2022, but for unclear reasons, Microsoft patched it only last Tuesday. [...]

With Microsoft maintaining radio silence, those affected by the glitch have been forced to find their own remedies. One option is to access their EFI panel and turn off secure boot. Depending on the security needs of the user, that option may not be acceptable. A better short-term option is to delete the SBAT Microsoft pushed out last Tuesday. This means users will still receive some of the benefits of Secure Boot even if they remain vulnerable to attacks that exploit CVE-2022-2601. The steps for this remedy are outlined here (thanks to manutheeng for the reference).

Here's a question from the blog OMG Ubuntu. "Ever get miffed reading about a major new Ubuntu release only to learn it doesn't come with the newest Linux kernel?

"Well, that'll soon be a thing of the past." Canonical's announced a big shift in kernel selection process for future Ubuntu release, an "aggressive kernel version commitment policy" pivot that means it will ship the latest upstream kernel code in development at the time of a new Ubuntu release.

Yes, even if that upstream kernel hasn't yet seen a formal stable release (and received the requisite newspaper-graphic-topped rundown on this blog). Which is a huge change. Currently, new Ubuntu releases include the most recent stable Linux kernel release at the time of the kernel freeze milestone in the Ubuntu development cycle.
Here's the official announcement by Canonical's Brett Grandbois. "Ubuntu will now ship the absolute latest available version of the upstream Linux kernel at the specified Ubuntu release freeze date, even if upstream is still in Release Candidate status..." It is actually expected that Late Releases will be the exception rather than the norm and in most releases these guidelines will not be necessary as the upstream kernel will release with enough time for the Ubuntu kernel to stabilize. However, adopting a more aggressive kernel version commitment policy does require us to be prepared for a possible Late Release situation and therefore informing the community on what they can expect.

Michael Larabel reports via Phoronix: Intel Linux engineer Colin Ian King discovered that if aligning the slab in the ACPI code via the "SLAB_HWCACHE_ALIGN" flag will offer a measurable improvement in memory performance and reducing the kernel boot time.

Colin explained with this one line kernel patch: "Enabling SLAB_HWCACHE_ALIGN for the ACPI object caches improves boot speed in the ACPICA core for object allocation and free'ing especially in the AML parsing and execution phases in boot. Testing with 100 boots shows an average boot saving in acpi_init of ~35000 usecs compared to the unaligned version. Most of the ACPI objects being allocated and free'd are of very short life times in the critical paths for parsing and execution, so the extra memory used for alignment isn't too onerous."

According to Statcounter, Linux use hit another all-time high in July. For July 2024, the statistics website is showing Linux at 4.45%, climbing almost a half a percentage point from June's 4.05% high.

Is 2024 truly the year of Linux on the desktop?

Nvidia's new R555 Linux driver series has significantly improved their open-source GPU kernel driver modules, achieving near parity with their proprietary drivers. Phoronix's Michael Larabel reports: The NVIDIA open-source kernel driver modules shipped by their driver installer and also available via their GitHub repository are in great shape. With the R555 series the support and performance is basically at parity of their open-source kernel modules compared to their proprietary kernel drivers. [...] Across a range of different GPU-accelerated creator workloads, the performance of the open-source NVIDIA kernel modules matched that of the proprietary driver. No loss in performance going the open-source kernel driver route. Across various professional graphics workloads, both the NVIDIA RTX A2000 and A4000 graphics cards were also achieving the same performance whether on the open-source MIT/GPLv2 driver or using NVIDIA's classic proprietary driver.

Across all of the tests I carried out using the NVIDIA 555 stable series Linux driver, the open-source NVIDIA kernel modules were able to achieve the same performance as the classic proprietary driver. Also important is that there was no increased power use or other difference in power management when switching over to the open-source NVIDIA kernel modules.

It's great seeing how far the NVIDIA open-source kernel modules have evolved and that with the upcoming NVIDIA 560 Linux driver series they will be defaulting to them on supported GPUs. And moving forward with Blackwell and beyond, NVIDIA is just enabling the GPU support along their open-source kernel drivers with leaving the proprietary kernel drivers to older hardware. Tests I have done using NVIDIA GeForce RTX 40 graphics cards with Linux gaming workloads between the MIT/GPL and proprietary kernel drivers have yielded similar (boring but good) results: the same performance being achieved with no loss going the open-source route. You can view Phoronix's performance results in charts here, here, and here.

Azure used to be a cloud platform dedicated to Windows. Now, it's the most widely used operating system on Microsoft Azure. The New Stack's Joab Jackson writes: These days, Microsoft expends considerable effort that Linux runs as smoothly as possible on Azure, according to a talk given earlier this year at the Linux Foundation Open Source Summit given by two Microsoft Azure Linux Platforms Group program managers, Jack Aboutboul, and Krum Kashan. "Linux is the #1 operating system in Azure today," Aboutoul said. And all must be supported in a way that Microsoft users have come to expects. Hence, the need for the Microsoft's Linux Platforms Group, which provides support Linux to both the internal customers and to Azure customers. These days, the duo of engineers explained, Microsoft knows about as much as anyone about how to operate Linux at hyperscale. [...]

As of today, there are hundreds of Azure and Azure-based services running on Linux, including the Azure Kubernetes Service (AKS), OpenAI, HDInsight, and many of the other database services. "A lot of the infrastructure powering everything else is running on Linux," Aboutoul said. "They're different flavors of Linux running all over the place," Aboutoul said. To run these services, Microsoft maintains its own kernel, Azure Linux, and in 2023 the company released its own version of Linux, Azure Linux. But Azure Linux is just a small portion of all the other flavors of Linux running on Azure, all of which Microsoft must work with to support.

Overall, there are about 20,000 third-party Software as a Service (SaaS) packages in the Azure marketplace that rely on some Linux distribution. And when things go wrong, it is the Azure service engineers who get the help tickets. The company keeps a set of endorsed Linux distributions, which include Red Hat Enterprise Linux, Debian, Flatcar, Suse, Canonical, and Oracle Linux and CentOS (as managed by OpenLogic, not Red Hat). [...] Overall, the company gets about 1,000 images a month from these endorsed partners alone. Many of the distributions have multiple images (Suse has a regular one, and another one for high-performance computing, for instance).

"The latest version of the Linux kernel adds an array of improvements," writes the blog OMG Ubuntu, " including a new memory sealing system call, a speed boost for AES-XTS encryption on Intel and AMD CPUs, and expanding Rust language support within the kernel to RISC-V." Plus, like in all kernel releases, there's a glut of groundwork to offer "initial support" for upcoming CPUs, GPUs, NPUs, Wi-Fi, and other hardware (that most of us don't use yet, but require Linux support to be in place for when devices that use them filter out)...

Linux 6.10 adds (after much gnashing) the mseal() system call to prevent changes being made to portions of the virtual address space. For now, this will mainly benefit Google Chrome, which plans to use it to harden its sandboxing. Work is underway by kernel contributors to allow other apps to benefit, though. A similarly initially-controversial change merged is a new memory-allocation profiling subsystem. This helps developers fine-tune memory usage and more readily identify memory leaks. An explainer from LWN summarizes it well.

Elsewhere, Linux 6.10 offers encrypted interactions with trusted platform modules (TPM) in order to "make the kernel's use of the TPM reasonably robust in the face of external snooping and packet alteration attacks". The documentation for this feature explains: "for every in-kernel operation we use null primary salted HMAC to protect the integrity [and] we use parameter encryption to protect key sealing and parameter decryption to protect key unsealing and random number generation." Sticking with security, the Linux kernel's Landlock security module can now apply policies to ioctl() calls (Input/Output Control), restricting potential misuse and improving overall system security.

On the networking side there's significant performance improvements to zero-copy send operations using io_uring, and the newly-added ability to "bundle" multiple buffers for send and receive operations also offers an uptick in performance...

A couple of months ago Canonical announced Ubuntu support for the RISC-V Milk-V Mars single-board computer. Linux 6.10 mainlines support for the Milk-V Mars, which will make that effort a lot more viable (especially with the Ubuntu 24.10 kernel likely to be v6.10 or newer). Others RISC-V improvements abound in Linux 6.10, including support for the Rust language, boot image compression in BZ2, LZ4, LZMA, LZO, and Zstandard (instead of only Gzip); and newer AMD GPUs thanks to kernel-mode FPU support in RISC-V.
Phoronix has their own rundown of Linux 6.10, plus a list of some of the highlights, which includes:

• The initial DRM Panic infrastructure
• The new Panthor DRM driver for newer Arm Mali graphics
• Better AMD ROCm/AMDKFD support for "small" Ryzen APUs and new additions for AMD Zen 5.
• AMD GPU display support on RISC-V hardware thanks to RISC-V kernel mode FPU
• More Intel Xe2 graphics preparations
• Better IO_uring zero-copy performance
• Faster AES-XTS disk/file encryption with modern Intel and AMD CPUs
• Continued online repair work for XFS
• Steam Deck IMU support
• TPM bus encryption and integrity protection

Jowi Morales reports via Tom's Hardware: There's a vast difference between hardware and software developers, which opens up pitfalls for those trying to coordinate the two teams. Arm and x86 researchers encountered it years ago -- and Linus Torvalds, the creator of Linux, fears RISC-V development may fall into the same chasm again. "Even when you do hardware design in a more open manner, hardware people are different enough from software people [that] there's a fairly big gulf between the Verilog and even the kernel, much less higher up the stack where you are working in what [is] so far away from the hardware that you really have no idea how the hardware works," he said (video here). "So, it's really hard to kind of work across this very wide gulf of things and I suspect the hardware designers, some of them have some overlap, but they will learn by doing mistakes -- all the same mistakes that have been done before." [...]

"They'll have all the same issues we have on the Arm side and that x86 had before them," he says. "It will take a few generations for them to say, 'Oh, we didn't think about that,' because they have new people involved." But even if RISC-V development is still expected to make many mistakes, he also said it will be much easier to develop the hardware now. Linus says, "It took a few decades to really get to the point where Arm and x86 are competing on fairly equal ground because there was al this software that was fairly PC-centric and that has passed. That will make it easier for new architectures like RISC-V to then come in."

Google plans to support its own long-term support (LTS) kernel releases for Android devices for four years, a move aimed at bolstering the security of the mobile operating system. This decision, reported by AndroidAuthority, comes in response to the Linux community's recent reduction of LTS support from six years to two years, a change that posed potential challenges for Android's security ecosystem.

The Android Common Kernel (ACK) branches, derived from upstream Linux LTS releases, form the basis of most Android devices' kernels. Google maintains these forks to incorporate Android-specific features and backport critical functionality. Regular updates to these kernels address vulnerabilities disclosed in monthly Android Security Bulletins. While the extended support period benefits Android users and manufacturers, it places significant demands on Linux kernel developers.

Its FOSS writes: When it comes to Linux, we get to see some really cool, and sometimes quirky projects (read Hannah Montana Linux) that try to show off what's possible, and that's not a bad thing. One such quirky undertaking has recently surfaced, which sees a sophomore trying to one-up their friend, who had booted Linux off NFS. With their work, they have been able to run Arch Linux on Google Drive.
Their ultimate idea included FUSE (which allows running file-system code in userspace). The developer's blog post explains that when Linux boots, "the kernel unpacks a temporary filesystem into RAM which has the tools to mount the real filesystem... it's very helpful! We can mount a FUSE filesystem in that step and boot normally.... " Thankfully, Dracut makes it easy enough to build a custom initramfs... I decide to build this on top of Arch Linux because it's relatively lightweight and I'm familiar with how it work."
Doing testing in an Amazon S3 container, they built an EFI image — then spent days trying to enable networking... And the adventure continues. ("Would it be possible to manually switch the root without a specialized system call? What if I just chroot?") After they'd made a few more tweaks, "I sit there, in front of my computer, staring. It can't have been that easy, can it? Surely, this is a profane act, and the spirit of Dennis Ritchie ought't've stopped me, right? Nobody stopped me, so I kept going..." I build the unified EFI file, throw it on a USB drive under /BOOT/EFI, and stick it in my old server... This is my magnum opus. My Great Work. This is the mark I will leave on this planet long after I am gone: The Cloud Native Computer.

Despite how silly this project is, there are a few less-silly uses I can think of, like booting Linux off of SSH, or perhaps booting Linux off of a Git repository and tracking every change in Git using gitfs. The possibilities are endless, despite the middling usefulness.

If there is anything I know about technology, it's that moving everything to The Cloud is the current trend. As such, I am prepared to commercialize this for any company wishing to leave their unreliable hardware storage behind and move entirely to The Cloud. Please request a quote if you are interested in True Cloud Native Computing.

Unfortunately, I don't know what to do next with this. Maybe I should install Nix?

Linux's vDSO (or virtual dynamic shared object) is "a small shared library that the kernel automatically maps into the address space of all user-space applications," according to its man page. "There are some system calls the kernel provides that user-space code ends up using frequently, to the point that such calls can dominate overall performance... due both to the frequency of the call as well as the context-switch overhead that results from exiting user space and entering the kernel."

But Linus Torvalds had a lot to say about a proposed getrandom() upgrade, reports Phoronix: This getrandom() work in the vDSO has been through 20+ rounds of review over the past 2+ years, but... Torvalds took some time out of his U.S. Independence Day to argue the merits of the patches on the Linux kernel mailing list. Torvalds kicked things off by writing:


Nobody has explained to me what has changed since your last vdso getrandom, and I'm not planning on pulling it unless that fundamental flaw is fixed. Why is this _so_ critical that it needs a vdso? Why isn't user space just doing it itself? What's so magical about this all?

This all seems entirely pointless to me still, because it's optimizing something that nobody seems to care about, adding new VM infrastructure, new magic system calls, yadda yadda. I was very sceptical last time, and absolutely _nothing_ has changed. Not a peep on why it's now suddenly so hugely important again. We don't add stuff "just because we can". We need to have a damn good reason for it. And I still don't see the reason, and I haven't seen anybody even trying to explain the reason.


And then he responded to himself, adding:


In other words, I want to see actual *users* piping up and saying "this is a problem, here's my real load that spends 10% of time on getrandom(), and this fixes it". I'm not AT ALL interested in microbenchmarks or theoretical "if users need high-performance random numbers". I need a real actual live user that says "I can't just use rdrand and my own chacha mixing on top" and explains why having a SSE2 chachacha in kernel code exposed as a vdso is so critical, and a magical buffer maintained by the kernel."


Torvalds also added in a third message:


One final note: the reason I'm so negative about this all is that the random number subsystem has such an absolutely _horrendous_ history of two main conflicting issues: people wanting reasonable usable random numbers on one side, and then the people that discuss what the word "entropy" means on the other side. And honestly, I don't want the kernel stuck even *more* in the middle of that morass....
Torvalds made additional comments. ("This smells. It's BS...") Advocating for the change was WiredGuard developer Jason Donenfeld, and more communication happened (and continues to happen... 40 messages and counting).

At one point the discussion evolved to Torvalds saying "Bah. I guess I'll have to walk through the patch series once again. I'm still not thrilled about it. But I'll give it another go..."

"After sixteen years since the introduction of Python 3, the Fedora project announces that Python 2.7, the last of the Python 2 series, will be retired," according to long-time Slashdot reader slack_justyb.

From the announcement on the Fedora changes page: The python2.7 package will be retired without replacement from Fedora Linux 41. There will be no Python 2 in Fedora 41+ other than PyPy. Packages requiring python2.7 on runtime or buildtime will have to deal with the retirement or be retired as well.
"This also comes with the announcement that GIMP 3 will be coming to Fedora 41 to remove any last Python 2 dependencies," adds slack_justyb. GIMP 2 was originally released on March 23, 2004. GIMP will be updated to GIMP 3 with Python 3 support. Python 2 dependencies of GIMP will be retired.
Python 2's end of life was originally 2015, but was extended to 2020. The Python maintainers close with this: The Python maintainers will no longer regularly backport security fixes to Python 2.7 in RHEL, due to the the end of maintenance of RHEL 7 and the retirement of the Python 2.7 application stream in RHEL 8. We provided this obsolete package for 5 years beyond its retirement date and will continue to provide it until Fedora 40 goes end of life. Enough has been enough.

An anonymous reader quotes a report from ZDNet, written by Steven Vaughan-Nichols: Hold onto your SSH keys, folks! A critical vulnerability has just rocked OpenSSH, Linux's secure remote access foundation, causing seasoned sysadmins to break out in a cold sweat. Dubbed "regreSSHion" and tagged as CVE-2024-6387, this nasty bug allows unauthenticated remote code execution (RCE) on OpenSSH servers running on glibc-based Linux systems. We're not talking about some minor privilege escalation here -- this flaw hands over full root access on a silver platter. For those who've been around the Linux block a few times, this feels like deja vu. The vulnerability is a regression of CVE-2006-5051, a bug patched back in 2006. This old foe somehow snuck back into the code in October 2020 with OpenSSH 8.5p1. Thankfully, the Qualys Threat Research Unit uncovered this digital skeleton in OpenSSH's closet. Unfortunately, this vulnerability affects the default configuration and doesn't need any user interaction to exploit. In other words, it's a vulnerability that keeps security professionals up at night.

It's hard to overstate the potential impact of this flaw. OpenSSH is the de facto standard for secure remote access and file transfer in Unix-like systems, including Linux and macOS. It's the Swiss Army knife of secure communication for sysadmins and developers worldwide. The good news is that not all Linux distributions have the vulnerable code. Old OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109. Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable. The bad news is that the vulnerability resurfaced in OpenSSH 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component. Qualys has found over 14 million potentially vulnerable OpenSSH server internet instances. The company believes that approximately 700,000 of these external internet-facing instances are definitely vulnerable. A patch, OpenSSH 9.8/9.8p1 is now available. Many, but not all, Linux distributions have made it available. If you can get it, install it as soon as possible. If for whatever reason you're not able to install a patch, Vaughan-Nichols recommends you set LoginGraceTime to 0 in the sshd configuration file and use network-based controls to restrict SSH access, while also configuring firewalls and monitoring tools to detect and block exploit attempts.

It was analgous to the "Blue Screen of Death" that Windows gives for critical errors, Phoronix wrote. To enable error messages for things like a kernel panic, Linux 6.10 introduced a new panic handler infrastructure for "Direct Rendering Manager" (or DRM) drivers.

Phoronix also published a follow-up from Red Hat engineer Javier Martinez Canillas (who was involved in the new DRM Panic infrastructure). Given complaints about being too like Microsoft Windows following his recent Linux "Blue Screen of Death" showcase... Javier showed that a black screen of death is possible if so desired... After all, it's all open-source and thus can customize to your heart's content.
And now the panic handler is getting even more new features, Phoronix reported Friday: With the code in Linux 6.10 when DRM Panic is triggered, an ASCII art version of Linux's mascot, Tux the penguin, is rendered as part of the display. With Linux 6.11 it will also be able to handle displaying a monochrome image as the logo.

If ASCII art on error messages doesn't satisfy your tastes in 2024+, the DRM Panic code will be able to support a monochrome graphical logo that leverages the Linux kernel's boot-up logo support. The ASCII art penguin will still be used when no graphical logo is found or when the existing "LOGO" Kconfig option is disabled. (Those Tux logo assets being here.)

This monochrome logo support in the DRM Panic handler was sent out as part of this week's drm-misc-next pull request ahead of the Linux 6.11 merge window in July. This week's drm-misc-next material also includes TTM memory management improvements, various fixes to the smaller Direct Rendering Manager drivers, and also the previously talked about monochrome TV support for the Raspberry Pi.
Long-time Slashdot reader unixbhaskar thinks the new option "will certainly satisfy the modern people... But it is not as eye candy as people think... Moreover, it is monochrome, so certainly not resource-hungry. Plus, if all else fails, the ASCII art logo is still there to show!"

Slashdot reader unixbhaskar shared this report from Phoronix: Larry Finger who has contributed to the Linux kernel since 2005 and has seen more than 1,500 kernel patches upstreamed into the mainline Linux kernel has sadly passed away. His wife shared the news of Larry Finger's passing this weekend on the linux-wireless mailing list in a brief statement.
Reactions are being shared around the internet. LWN writes: The LWN Kernel Source Database shows that Finger contributed to 94 releases in the (Git era) kernel history, starting with 2.6.16 — 1,464 commits in total. He will be missed... In part to his contributions, the Linux wireless hardware support has come a long way over the past two decades.
Larry was a frequent contributor to the Linux Wireless and Linux Kernel mailing lists. (Here's a 2006 discussion he had about Git with Linus Torvalds.) Larry also answered 54 Linux questions on Quora, and in 2005 wrote three articles for Linux Journal. And Larry's GitHub profile shows 122 contributions to open source projects just in 2024.

In Reddit's Linux forum, one commenter wrote, "He was 84 years old and was still writing code. What a legend. May he rest in peace."

In 2022, Red Hat announced plans to extend RHEL to the automotive industry through Red Hat In-Vehicle Operating System (providing automakers with an open and functionally-safe platform). And this week Red Hat announced it achieved ISO 26262 ASIL-B certification from exida for the Linux math library (libm.so glibc) — a fundamental component of that Red Hat In-Vehicle Operating System.

From Red Hat's announcement: This milestone underscores Red Hat's pioneering role in obtaining continuous and comprehensive Safety Element out of Context certification for Linux in automotive... This certification demonstrates that the engineering of the math library components individually and as a whole meet or exceed stringent functional safety standards, ensuring substantial reliability and performance for the automotive industry. The certification of the math library is a significant milestone that strengthens the confidence in Linux as a viable platform of choice for safety related automotive applications of the future...

By working with the broader open source community, Red Hat can make use of the rigorous testing and analysis performed by Linux maintainers, collaborating across upstream communities to deliver open standards-based solutions. This approach enhances long-term maintainability and limits vendor lock-in, providing greater transparency and performance. Red Hat In-Vehicle Operating System is poised to offer a safety certified Linux-based operating system capable of concurrently supporting multiple safety and non-safety related applications in a single instance. These applications include advanced driver-assistance systems (ADAS), digital cockpit, infotainment, body control, telematics, artificial intelligence (AI) models and more. Red Hat is also working with key industry leaders to deliver pre-tested, pre-integrated software solutions, accelerating the route to market for SDV concepts.
"Red Hat is fully committed to attaining continuous and comprehensive safety certification of Linux natively for automotive applications," according to the announcement, "and has the industry's largest pool of Linux maintainers and contributors committed to this initiative..."

Or, as Network World puts it, "The phrase 'open source for the open road' is now being used to describe the inevitable fit between the character of Linux and the need for highly customizable code in all sorts of automotive equipment."

"A good portion of my home directory got deleted," complained a bug report for systemd filed last week. It requested an update to a flag for the systemd-tmpfiles tool which cleans up files and directories: "a huge warning next to --purge. This option is dangerous, so it should be made clear that it's dangerous."

The Register explains: As long as five years ago, systemd-tmpfiles had moved on past managing only temporary files — as its name might suggest to the unwary. Now it manages all sorts of files created on the fly ... such as things like users' home directories. If you invoke the systemd-tmpfiles --purge command without specifying that very important config file which tells it which files to handle, version 256 will merrily purge your entire home directory.
The bug report first drew a cool response from systemd developer Luca Boccassi of Microsoft: So an option that is literally documented as saying "all files and directories created by a tmpfiles.d/ entry will be deleted", that you knew nothing about, sounded like a "good idea"? Did you even go and look what tmpfiles.d entries you had beforehand? Maybe don't just run random commands that you know nothing about, while ignoring what the documentation tells you? Just a thought eh
But the report then triggered "much discussion," reports Phoronix. Some excerpts:

• Lennart Poettering: "I think we should fail --purge if no config file is specified on the command line. I see no world where an invocation without one would make sense, and it would have caught the problem here."

• Red Hat open source developer Zbigniew Jedrzejewski-Szmek: "We need to rethink how --purge works. The principle of not ever destroying user data is paramount. There can be commands which do remove user data, but they need to be minimized and guarded."

• Systemd contributor Betonhaus: "Having a function that declares irreplaceable files — such as the contents of a home directory — to be temporary files that can be easily purged, is at best poor user interfacing design and at worst a severe design flaw."

But in the end, Phoronix writes, systemd-tmpfiles behavior "is now improved upon."

"Merged Wednesday was this patch that now makes systemd-tmpfiles accept a configuration file when running purge. That way the user must knowingly supply the configuration file(s) to which files they would ultimately like removed. The documentation has also been improved upon to make the behavior more clear."

Thanks to long-time Slashdot reader slack_justyb for sharing the news.

An anonymous reader quotes a report from ZDNet: At SUSECon in Berlin, SUSE, a global Linux and cloud-native software leader, announced significant enhancements across its entire Linux distribution family. These new capabilities focus on providing faster time-to-value and reduced operational costs, emphasizing the importance of choice in today's complex IT landscape. SUSE Linux Enterprise Server (SLES) 15 Service Pack (SP) 6 is at the heart of these upgrades. This update future-proofs IT workloads with a new Long Term Service (LTS) Pack Support Core. How long is long-term? Would you believe 19 years? This gives SLES the longest-term support period in the enterprise Linux market. Even Ubuntu, for which Canonical recently extended its LTS to 12 years, doesn't come close.

You may ask yourself, "Why 19 years?" SUSE General Manager of Business Critical Linux (BCL) Rick Spencer, explained in an interview that the reason is that on 03:14:08 Greenwich Mean Time (GMT, aka Coordinated Universal Time) Tuesday, January 19, 2038, we reach the end of computing time. Well, not really, but Linux, and all the other Unix-based operating systems, including some versions of MacOS, reach what's called the Epoch. That's when the time-keeping code in 32-bit Unix-based operating systems reaches the end of the seconds it's been counting since the beginning of time -- 00:00:00 GMT on January 1, 1970, as far as Linux and Unix systems are concerned -- and resets to zero. Just like the Y2K bug, that means that all unpatched 32-bit operating systems and software will have fits. The Linux kernel itself had the problem fixed in 2020's Linux 5.6 kernel, but many other programs haven't dealt with it. Until then, though, if you're still running SLES 15 SP6, you'll be covered. I strongly suggest upgrading before then, but if you want to stick with that distro to the bitter end, you can. The new SLES also boasts enhanced security features like confidential computing support with encryption in memory, utilizing Intel TDX and AMD SEV processors, along with remote attestation via SUSE Manager. Additionally, SLES for SAP Applications 15 SP6 offers a secure and reliable platform for running mission-critical SAP workloads, incorporating innovations from Trento to help system administrators avoid infrastructure issues.

SUSE, a Luxembourg-based open-source company, is launching a new vendor- and LLM-agnostic generative AI platform called SUSE AI solutions. The company aims to leverage the potential of AI to gain a stronger foothold in the U.S. market, where it has struggled to establish brand recognition compared to competitors like Red Hat and Canonical. SUSE CEO Dirk-Peter van Leeuwen believes that the open-source model provides infinite potential for enterprise customers, offering support, security, and long-term stability. The company's recent fork of CentOS has attracted a significant number of users, and its portfolio, including Kubernetes service Rancher and security service Neuvector, positions SUSE well in a market where enterprises are looking to consolidate platforms. Despite ownership changes over the years, SUSE remains committed to expanding its presence in the U.S. market.

In 2016, Phoronix remembered how the early days of Linux kernel mode-setting (KMS) had brought hopes for improved error messages. And one long-awaited feature was errors messages for "Direct Rendering Manager" (or DRM) drivers — something analgous to the "Blue Screen of Death" Windows gives for critical errors.

Now Linux 6.10 is introducing a new DRM panic handler infrastructure enabling messages when a panic occurs, Phoronix reports today. "This is especially important for those building a kernel without VT/FBCON support where otherwise viewing the kernel panic message isn't otherwise easily available." With Linux 6.10 the initial DRM Panic code has landed as well as wiring up the DRM/KMS driver support for the SimpleDRM, MGAG200, IMX, and AST drivers. There is work underway on extending DRM Panic support to other drivers that we'll likely see over the coming kernel cycles for more widespread support... On Linux 6.10+ with platforms having the DRM Panic driver support, this "Blue Screen of Death" functionality can be tested via a route such as echo c > /proc/sysrq-trigger.
The article links to a picture shared on Mastodon by Red Hat engineer Javier Martinez Canillas of the error message being generated on a BeaglePlay single board computer.

Phoronix also points out that some operating systems have even considered QR codes for kernel error messages...

ZDNet published a new article this week with their own tips for new Linux users. It begins by arguing that switching to the Linux desktop "is easier than you think" and "you'll find help everywhere". (And also that "You won't want for apps.") That doesn't mean it has everything. For example, there is no version of Adobe Photoshop. There is GIMP (which is just as powerful as Photoshop) but for those of you accustomed to Adobe's de facto standard, you're out of luck. The worst-case scenario is you have to learn a new piece of software to meet your graphic needs. At the same time, you might have to turn to proprietary software. For open-source purists, that's a no-go. But for those who just need to get things done, you'll find a mixture of open-source and proprietary software will give you everything you need to be productive and entertained.
Their article also recommends new users should "weed out Arch-based distributions," while warning that "Linux is more secure, but..." The truth is, any time you have a computer connected to a network, it's vulnerable and it doesn't matter what operating system you use. To that end, it's crucial that you keep your operating system (and the installed applications) up to date. Fortunately, most Linux operating systems make this very easy...

You're probably used to the slow trickle of updates and improvements found in the likes of Windows or MacOS. On Linux, you can count on that process being considerably faster. This is especially important with updates. When a vulnerability is found in an application that affects Linux, it is fixed far faster than it would be on competing platforms. The reason for this is that most Linux software is created and maintained by developers who don't have to answer to boards or committees or have a painfully slow bug resolution process. It might be announced that a vulnerability has been discovered in an application and the fix is officially released the next day. I've seen that very thing happen more times than I can count.

But it's not just about vulnerabilities. Developers add new features to software all the time and even listen to users. You could contact a developer of an open-source application with an idea and find it implemented in the next update. Linux is always evolving and it does so much faster than other operating systems.
And there's one final caveat. "Not all hardware will work (but most will)." I'll say this (and I stand by it): Ubuntu Linux probably has the best hardware detection and support of any operating system on the market. But that doesn't mean it works with everything. Certain peripherals you own could have trouble working with Linux. Two of the more problematic pieces of hardware are scanners and wireless chips. When I find a piece of hardware that isn't supported, here's one thing I've often done: I try a different Linux distribution... (Fedora often ships with a newer kernel than Ubuntu Linux, and therefore supports more modern hardware.)

Keep in mind that most Linux distributions are offered as Live images, which means you can test-drive them without making any changes to your hard drive. This is a great way to tell if a distribution will support all the hardware you need to use.
Agree? Disagree? Share your reactions in the comments...

And what advice would you give to a first-time Linux user?

Slashdot reader BrianFagioli shares his report from BetaNews: The PC community is abuzz with Qualcomm's recent announcement of its Snapdragon X Elite SoC, a powerhouse chipset that promises to revolutionize the performance and energy efficiency of laptops and tablets. While Windows 11 Copilot+ PCs are set to feature this advanced processor, Linux enthusiasts have reasons to celebrate as well. You see, TUXEDO Computers is bringing this cutting-edge technology to the Linux world with its upcoming ARM notebook, positioning it as a strong competitor to Windows 11 Copilot+ devices.

In a recent update, TUXEDO Computers revealed its ambitious project of developing an ARM notebook powered by the Snapdragon X Elite SoC from Qualcomm. This announcement has generated significant excitement, as it presents a viable alternative to traditional x86 notebooks, offering comparable performance with lower energy consumption, directly challenging the dominance of Windows 11 Copilot+... Benchmarks suggest that the Snapdragon X Elite can not only rival but potentially surpass Apple's M2 SoCs, boasting higher energy efficiency. TUXEDO's preliminary tests confirm these impressive claims, setting the stage for a fierce competition with Windows 11 Copilot+ PCs.
"We recently presented a prototype of the ARM notebook we are working on at the Computex computer trade fair in Taiwan," according to TUXEDO's announcement.

"On the software side, a port of TUXEDO OS with KDE Plasma to the ARM platform is our goal for this project running internally under the working title Drako...

"It is quite conceivable that an ARM notebook from TUXEDO will be under your Christmas tree in 2024... If you have subscribed to our newsletter, you will be the first to know."

Liam Proven reports via The Register: The latest version of the systemd init system is out, with the openly confrontational tag line: "Available soon in your nearest distro, now with 42 percent less Unix philosophy." As Lennart Poettering's announcement points out, this is the first version of systemd whose version number is a nine-bit value. Version 256, as usual, brings in a broad assortment of new features, but also turns off some older features that are now considered deprecated. For instance, it won't run under cgroups version 1 unless forced.

Around since 2008, cgroups is a Linux kernel containerization mechanism originally donated by Google, as The Reg noted a decade ago. Cgroups v2 was merged in 2016 so this isn't a radical change. System V service scripts are now deprecated too, as is the SystemdOptions EFI variable. Additionally, there are some new commands and options. Some are relatively minor, such as the new systemd-vpick binary, which can automatically select the latest member of versioned directories. Before any OpenVMS admirers get excited, no, Linux does not now support versions on files or directories. Instead, this is a fresh option that uses a formalized versioning system involving: "... paths whose trailing components have the .v/ suffix, pointing to a directory. These components will then automatically look for suitable files inside the directory, do a version comparison and open the newest file found (by version)."

The latest function, which The Reg FOSS desk suspects will ruffle some feathers, is a whole new command, run0, which effectively replaces the sudo command as used in Apple's macOS and in Ubuntu ever since the first release. Agent P introduced the new command in a Mastodon thread. He says that the key benefit is that run0 doesn't need setuid, a basic POSIX function, which, to quote its Linux manual page, "sets the effective user ID of the calling process." [...] Another new command is importctl, which handles importing and exporting both block-level and file-system-level disk images. And there's a new type of system service called a capsule, and "a small new service manager" called systemd-ssh-generator, which lets VMs and containers accept SSH connections so long as systemd can find the sshd binary -- even if no networking is available. The release notes are available here.

Steven Vaughan-Nichols reports via ZDNet: While Linux and open-source software (OSS) are no longer constantly under intellectual property (IP) attacks, the Open Invention Network (OIN) patent consortium still stands guard over its patents. Now, OIN, the largest patent non-aggression community, has expanded its protection once again by updating its Linux System definition. Covering more than just Linux, the Linux System definition also protects adjacent open-source technologies. In the past, protection was expanded to Android, Kubernetes, and OpenStack. The OIN accomplishes this by providing a shared defensive patent pool of over 3 million patents from over 3,900 community members. OIN members include Amazon, Google, Microsoft, and essentially all Linux-based companies.

This latest update extends OIN's existing patent risk mitigation efforts to cloud-native computing and enterprise software. In the cloud computing realm, OIN has added patent coverage for projects such as Istio, Falco, Argo, Grafana, and Spire. For enterprise computing, packages such as Apache Atlas and Apache Solr -- used for data management and search at scale, respectively -- are now protected. The update also enhances patent protection for the Internet of Things (IoT), networking, and automotive technologies. OpenThread and packages such as agl-compositor and kukusa.val have been added to the Linux System definition. In the embedded systems space, OIN has supplemented its coverage of technologies like OpenEmbedded by adding the OpenAMP and Matter, the home IoT standard. OIN has included open hardware development tools such as Edalize, cocotb, Amaranth, and Migen, building upon its existing coverage of hardware design tools like Verilator and FuseSoc.

Keith Bergelt, OIN's CEO, emphasized the importance of this update, stating, "Linux and other open-source software projects continue to accelerate the pace of innovation across a growing number of industries. By design, periodic expansion of OIN's Linux System definition enables OIN to keep pace with OSS's growth." [...] Looking ahead, Bergelt said, "We made this conscious decision not to include AI. It's so dynamic. We wait until we see what AI programs have significant usage and adoption levels." This is how the OIN has always worked. The consortium takes its time to ensure it extends its protection to projects that will be around for the long haul. The OIN practices patent non-aggression in core Linux and adjacent open-source technologies by cross-licensing their Linux System patents to one another on a royalty-free basis. When OIN signees are attacked because of their patents, the OIN can spring into action.

T2's open development process and the collection of exotic, vintage and retro hardware can be followed live on YouTube and Twitch.

Now Slashdot reader ReneR writes: Embedded T2 Linux is known for its sophisticated cross compile features as well as supporting all CPU architectures, including: Alpha, Arc, ARM(64), Avr32, HPPA(64), IA64, M68k, MIPS(64), Nios2, PowerPC(64)(le), RISCV(64), s390x, SPARC(64), SuperH, x86(64). But now it's going Desktop!

24.6 comes as a major convenience update, with out-of-the-box Windows application compatibility as well as LibreOffice and Thunderbird cross-compiled and in the default base ISO for the most popular CPU architectures.

Continuing to keep Intel IA-64 Itanium alive, a major, up-to-3x performance improvement was found for OpenSSL, doubling crypto performance for many popular algorithms and SSH.

The project's CI unit testing was further expanded to now cover the whole installation in two variants. The graphical desktop defaults were also polished -- and a T2 branded wallpaper was added! ;-) The release contains 606 changesets, including approximately 750 package updates, 67 issues fixed, 80 packages or features added, 21 removed and 9 other improvements.

"Researchers observed a new Linux variant of the TargetCompany ransomware family that targets VMware ESXi environments," reports BleepingComputer: In a report Wednesday, cybersecurity company Trend Micro says that the new Linux variant for TargetCompany ransomware makes sure that it has administrative privileges before continuing the malicious routine... Once on the target system, the payload checks if it runs in a VMware ESXi environment by executing the 'uname' command and looking for 'vmkernel.' Next, a "TargetInfo.txt" file is created and sent to the command and control (C2) server. It contains victim information such as hostname, IP address, OS details, logged-in users and privileges, unique identifiers, and details about the encrypted files and directories. The ransomware will encrypt files that have VM-related extensions (vmdk, vmem, vswp, vmx, vmsn, nvram), appending the ".locked" extension to the resulting files.

Finally, a ransom note named "HOW TO DECRYPT.txt" is dropped, containing instructions for the victim on how to pay the ransom and retrieve a valid decryption key. "After all tasks have been completed, the shell script deletes the payload using the 'rm -f x' command so all traces that can be used in post-incident investigations are wiped from impacted machines."

Thanks to long-time Slashdot reader joshuark for sharing the article.

"Lansweeper's scans of its customers' networks found an awful lot of Linux boxes facing imminent end of life," reports the Register, "with no direct upgrade path." Belgian corporate network scanner vendor Lansweeper periodically collates some of the statistics collected by its users and publishes the results... This year's report says that while a third of its users' Linux machines run Ubuntu, second place goes to CentOS Linux [with 26.05%].

Back in 2020, Red Hat brought CentOS Linux 8's end of life forward from 2029 to the end of 2021. CentOS Linux 9 was canceled, CentOS Linux 8 is dead and gone, leaving only CentOS Linux 7. As we reported in May, CentOS 7's end of life is very close now — the end of June. After this month, no more updates.

Of course, Red Hat will be happy to help you migrate to RHEL. It offers a free tool to switch boxes' package source, but RHEL 7 hits what Red Hat terms "the end of its maintenance support 2 phase" on the same day. RHEL 7 isn't EOL, but you'll need to pay extra for "Extended Lifecycle Support (ELS)" to keep security fixes coming. Lansweeper seems confident this will happen: "Assuming most of the CentOS devices will migrate over to RHEL, we can expect RHEL to comfortably take over first place from Ubuntu soon."
RHEL was already on 20% of the machines scanned by Lansweeper (with Rocky Linux at 1.5%). But the Register argues that instead of switching to RHEL, "the freeloaders running CentOS Linux might well migrate to one of the RHELatives instead. CIQ publishes guidance on how to migrate to Rocky Linux, and will help if you buy its CIQ Bridge service. AlmaLinux has more than that with its ELevate tool to perform in-place version upgrades, as we described back in 2022.

"Or, of course, you could just reinstall with Debian, and run anything you can't immediately reprovision in a free RHEL container image."

"The US Cybersecurity and Infrastructure Security Agency has added a critical security bug in Linux to its list of vulnerabilities known to be actively exploited in the wild," reported Ars Technica on Friday.

"The vulnerability, tracked as CVE-2024-1086 and carrying a severity rating of 7.8 out of a possible 10, allows people who have already gained a foothold inside an affected system to escalate their system privileges." It's the result of a use-after-free error, a class of vulnerability that occurs in software written in the C and C++ languages when a process continues to access a memory location after it has been freed or deallocated. Use-after-free vulnerabilities can result in remote code or privilege escalation. The vulnerability, which affects Linux kernel versions 5.14 through 6.6, resides in the NF_tables, a kernel component enabling the Netfilter, which in turn facilitates a variety of network operations... It was patched in January, but as the CISA advisory indicates, some production systems have yet to install it. At the time this Ars post went live, there were no known details about the active exploitation.

A deep-dive write-up of the vulnerability reveals that these exploits provide "a very powerful double-free primitive when the correct code paths are hit." Double-free vulnerabilities are a subclass of use-after-free errors...

Michael Larabel reports via Phoronix: A massive uptick in traffic to Fedora's package mirrors is causing problems for the Linux distribution. Some five million additional systems have started putting additional strain on Fedora's mirror resources since March and appear to be coming from Amazon's cloud. Stephen Smoogen of Red Hat wrote a blog post today around 5+ million more EPEL-7 systems beginning in March. Fedora hosts the packaging mirrors for Extra Packages For Enterprise Linux (EPEL) to augment the package selection available on RHEL, CentOS, Amazon Linux, etc.

The past three months now there has been a 5+ million surge in Fedora/EPEL traffic and it's placed a strain on the systems. It's about doubling the number of unique IPs connecting to the mirror system. The massive uptick in Fedora/EPEL activity puts additional pressure on Fedora web proxies for mirror data and then the mirrors themselves that tend to be volunteer run. Much of this new traffic is coming from the Amazon/AWS cloud.

BrianFagioli writes: Canonical has officially released the optimized Ubuntu 24.04 image for the Milk-V Mars, a credit-card-sized RISC-V single board computer (SBC) developed by Shenzhen MilkV Technology Co., Ltd.

The Milk-V Mars is the world's first high-performance RISC-V SBC of its size. Powered by the StarFive JH7110 quad-core processor, the board is equipped with up to 8GB of LPDDR4 memory and supports various modern interfaces, including USB 3.0, HDMI 2.0 for 4K output, and Ethernet with PoE capabilities. It also offers comprehensive expansion options with M.2 E-Key and extensive MIPI CSI channels, making it an ideal choice for developers and tech enthusiasts.

"Merged this Friday evening into the Linux 6.10 kernel is the new mseal() system call for memory sealing," reports Phoronix: The mseal system call was led by Jeff Xu of Google's Chrome team. The goal with memory sealing is to also protect the memory mapping itself against modification. The new mseal Linux documentation explains:

"Modern CPUs support memory permissions such as RW and NX bits. The memory permission feature improves security stance on memory corruption bugs, i.e. the attacker can't just write to arbitrary memory and point the code to it, the memory has to be marked with X bit, or else an exception will happen. Memory sealing additionally protects the mapping itself against modifications. This is useful to mitigate memory corruption issues where a corrupted pointer is passed to a memory management system... Memory sealing can automatically be applied by the runtime loader to seal .text and .rodata pages and applications can additionally seal security-critical data at runtime. A similar feature already exists in the XNU kernel with the VM_FLAGS_PERMANENT flag and on OpenBSD with the mimmutable syscall."

The mseal system call is designed to be used by the likes of the GNU C Library "glibc" while loading ELF executables to seal non-writable memory segments or by the Google Chrome web browser and other browsers for protecting security sensitive data structures.

"The fact it's possible at all is a credit to the ingenuity of the open-source community," writes the blog OMG Ubuntu: Switchroot is an open-source project that allows Android and Linux-based distros like Ubuntu to run on the Nintendo Switch — absolutely not something Nintendo approves of much less supports, endorses, or encourages, etc! I covered the loophole that made this possible back in 2018. Back then the NVIDIA Tegra X1-powered Nintendo Switch was still new and Linux support for much of the console's internal hardware in a formative state (a polite way to say 'not everything worked'). But as the popularity of Nintendo's handheld console ballooned (to understate it) so the 'alternative OS' Switch scene grew, and before long Linux support for Switch hardware was in full bloom...

A number of Linux for Switchroot (L4S) distributions have since been released, designated as Linux for Tegra (L4T) builds. As these can boot from a microSD card it's even possible to dualboot the Switch OS with Linux, which is neat! Recently, a fresh set of L4T Ubuntu images were released based on the newest Ubuntu 24.04 LTS release. These builds work on all Switch versions, from the OG (exploit-friendly) unit through to newer, patched models (where a modchip is required)...

I'm told all of the Nintendo Switch internal hardware now works under Linux, including Wi-Fi, Bluetooth, sleep mode, accelerated graphics, the official dock... Everything, basically. And despite being a 7 year old ARM device the performance is said to remain decent.
"Upstream snafus have delayed the release of builds with GNOME Shell..."

This week Red Hat announced one of America's leading pediatric hospitals is using AI to analyze X-rays, "to improve image quality and the speed and accuracy of image interpretation."

Red Hat's CTO said the move exemplifies "the positive impact AI can have in the healthcare field". Before Boston Children's Hospital began piloting AI in radiology, quantitative measurements had to be done manually, which was a time-consuming task. Other, more complex image analyses were performed completely offline and outside of the clinical workflow. In a field where time is of the essence, the hospital is piloting Red Hat OpenShift via the ChRIS Research Integration Service, a web-based medical image platform. The AI application running in ChRIS on the Red Hat OpenShift foundation has the potential to automatically examine x-rays, identify the most valuable diagnostic images among the thousands taken and flag any discrepancies for the radiologist. This decreases the interpretation time for radiologists.
But it also seems to be a big win for openness: Innovation developed internally is immediately transferable to public research clouds such as the Massachusetts Open Cloud, where large-scale data sharing and additional innovation can be fostered. Boston Children's Hospital aims to extend the reach of advanced healthcare solutions globally through this approach, amplifying their impact on patient well-being worldwide.
"Red Hat believes open unlocks the world's potential," the announcement concludes, "including the potential to share knowledge and build upon each other's discoveries. Additionally, Red Hat believes innovation — including AI — should be available everywhere, making any application, anywhere a reality.

"With open source, enabling AI-fueled innovation across hybrid IT environments that can lead to faster clinical breakthroughs and better patient outcomes is a reality."

Michael Larabel reports via Phoronix: The latest RISC-V port updates have been merged for the in-development Linux 6.10 kernel. Most notable with today's RISC-V merge to Linux 6.10 is now supporting the Rust programming language within the Linux kernel. RISC-V joins the likes of x86_64, LoongArch, and ARM64 already supporting the use of the in-kernel Rust language support. The use of Rust within the mainline Linux kernel is still rather limited with just a few basic drivers so far and a lot of infrastructure work taking place, but there are a number of new drivers and other subsystem support on the horizon. RISC-V now supporting Rust within the Linux kernel will become more important moving forward.

The RISC-V updates for Linux 6.10 also add byte/half-word compare-and-exchange, support for Zihintpause within hwprobe, a PR_RISCV_SET_ICACHE_FLUSH_CTX prctl(), and support for lockless lockrefs. More details on these RISC-V updates for Linux 6.10 via this Git merge.

Longtime Slashdot reader DVega shares a report from Phoronix: ReiserFS lead developer and convicted murderer Hans Reiser a few months back wrote letters to be made public apologizing for his social mistakes and other commentary. In his written communications he also made a last request for ReiserFS in the Linux kernel: "Assuming that the decision is to remove [ReiserFS] V3 from the kernel, I have just one request: that for one last release the README be edited to add Mikhail Gilula, Konstantin Shvachko, and Anatoly Pinchuk to the credits, and to delete anything in there I might have said about why they were not credited. It is time to let go."

Hans credits his improved social and communication skills learned in prison among other details shared in the public letters. Per the indirect request by Hans Reiser, SUSE's Jan Kara has now altered the ReiserFS README file with the changes going in today to the Linux 6.10 kernel. The negative language was removed and instead acknowledging their contributions.