Red Hat, the IBM-owned open source software firm, is acquiring Neural Magic, a startup that optimizes AI models to run faster on commodity processors and GPUs. From a report: The terms of the deal weren't disclosed. MIT research scientist Alex Matveev and professor Nir Shavit founded Somerville, Massachusetts-based Neural Magic in 2018, inspired by their work in high-performance execution engines for AI. Neural Magic's software aims to process AI workloads on processors and GPUs at speeds equivalent to specialized AI chips (e.g. TPUs). By running models on off-the-shelf processors, which usually have more available memory, the company's software can realize these performance gains.

Big tech companies like AMD and a host of other startups, including NeuReality, Deci, CoCoPie, OctoML and DeepCube, offer some sort of AI optimization software. But Neural Magic is one of the few with a free platform and a collection of open source tools to complement it. Neural Magic had so far managed to raise $50 million in venture capital from backers like Andreessen Horowitz, New Enterprise Associations, Amdocs, Comcast Ventures, Pillar VC and Ridgeline Ventures.

An anonymous reader shared this report from Phoronix: Intel's Linux kernel test robot has reported a 3888.9% performance improvement in the mainline Linux kernel as of this past week...

Intel thankfully has the resources to maintain this automated service for per-kernel commit/patch testing and has been maintaining their public kernel test robot for years now to help catch performance changes both positive and negative to the Linux kernel code. The commit in question causing this massive uplift to performance is mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes. The patch message confirms it will fix some prior performance regressions and deliver some major uplift in specialized cases...

That mmap patch merged last week affects just one line of code.
This week the Register also reported that Linus Torvalds revised a previously-submitted security tweak that addressed Spectre and Meltdown security holes, writing in his commit message that "The kernel test robot reports a 2.6 percent improvement in the per_thread_ops benchmark."

Linux creator Linus Torvalds has blasted the AI industry as "90% marketing and 10% reality" even as he acknowledged AI's transformative potential. Speaking to TFiR, Torvalds said he would "basically ignore" AI until the hype subsides, predicting meaningful applications would emerge in five years.

The Finnish software pioneer singled out ChatGPT and graphic design as current practical use cases. His criticism follows Baidu CEO's recent warning of an impending AI bubble burst, claiming only 1% of companies would survive the fallout. "I think AI is really interesting, and I think it is going to change the world. And, at the same time, I hate the hype cycle so much that I really don't want to go there," Torvalds said.

It was originally created back in 2005 by Sun Microsystems for its proprietary Solaris Unix systems, "for troubleshooting kernel and application problems on production systems in real time," explains Wikipedia. "DTrace can be used to get a global overview of a running system, such as the amount of memory, CPU time, filesystem and network resources used by the active processes," explains its Wikipedia entry.

But this week, Gentoo announced: The real, mythical DTrace comes to Gentoo! Need to dynamically trace your kernel or userspace programs, with rainbows, ponies, and unicorns — and all entirely safely and in production?! Gentoo is now ready for that!

Just emerge dev-debug/dtrace and you're all set. All required kernel options are already enabled in the newest stable Gentoo distribution kernel...

Documentation? Sure, there's lots of it. You can start with our DTrace wiki page, the DTrace for Linux page on GitHub, or the original documentation for Illumos. Enjoy!
Thanks to Heraklit (Slashdot reader #29,346) for sharing the news.

Ancient Slashdot reader szo shares a report from Phoronix: Quietly merged into this week's Linux 6.12-rc4 kernel was a patch that removes a number of kernel maintainers from being noted in the official MAINTAINERS file that recognizes all of the driver and subsystem maintainers. [...] [Greg Kroah-Hartman who authored the patch] simply commented in there: "Remove some entries due to various compliance requirements. They can come back in the future if sufficient documentation is provided." [...] The commonality of all these maintainers being dropped? They appear to all be Russian or associated with Russia. Most of them with .ru email addresses. Linux creator Linus Torvalds has since commented on the situation: Ok, lots of Russian trolls out and about. It's entirely clear why the change was done, it's not getting reverted, and using multiple random anonymous accounts to try to "grass root" it by Russian troll factories isn't going to change anything. And FYI for the actual innocent bystanders who aren't troll farm accounts - the "various compliance requirements" are not just a US thing.

If you haven't heard of Russian sanctions yet, you should try to read the news some day. And by "news," I don't mean Russian state-sponsored spam. As to sending me a revert patch - please use whatever mush you call brains. I'm Finnish. Did you think I'd be *supporting* Russian aggression? Apparently it's not just lack of real news, it's lack of history knowledge too.

jd writes: Linus Torvalds is not a happy camper and is condemning hardware vendors for poor security and the plethora of actual and theoretical attacks, especially as some of the new features being added impact the workarounds. These workarounds are now getting very expensive, CPU-wise.

TFA quotes Linus Torvalds:

"Honestly, I'm pretty damn fed up with buggy hardware and completely theoretical attacks that have never actually shown themselves to be used in practice.

"So I think this time we push back on the hardware people and tell them it's *THEIR* damn problem, and if they can't even be bothered to say yay-or-nay, we just sit tight.

Because dammit, let's put the onus on where the blame lies, and not just take any random shit from bad hardware and say 'oh, but it *might* be a problem.'"

"Google is developing a Linux terminal app for Android," reports the blog Android Authority. "The Terminal app can be enabled via developer options and will install Debian in a virtual machine.

"This app is likely intended for Chromebooks but might also be available for mobile devices, too." While there are ways to run some Linux apps on Android devices, all of those methods have some limitations and aren't officially supported by Google. Fortunately, though, Google is finally working on an official way to run Linux apps on Android... This Terminal app is part of the Android Virtualization Framework (AVF) and contains a WebView that connects to a Linux virtual machine via a local IP address, allowing you to run Linux commands from the Android host...

A set of patches under the tag "ferrochrome-dev-option" was recently submitted to the Android Open Source Project that adds a new developer option called Linux terminal under Settings > System > Developer options. This new option will enable a "Linux terminal app that runs inside the VM," according to its proposed description. Toggling this option enables the Terminal app that's bundled with AVF...

Google is still working on improving the Terminal app as well as AVF before shipping this feature... What's particularly interesting about the patch that adds these settings is that it was tested on "tangorpro" and "komodo," the codenames for the Pixel Tablet and Pixel 9 Pro XL respectively. This suggests that the Terminal app won't be limited to Chromebooks like the new desktop versions of Chrome for Android.

Formed in 2021 by cybersecurity professionals (and backed by high-powered VCs including Dell Technologies Capital), Halcyon sells an enterprise-grade anti-ransomware platform.

And this month they announced they're offering protection against ransomware attacks targeting Linux systems, according to Linux magazine: According to Cynet, Linux ransomware attacks increased by 75 percent in 2023 and are expected to continue to climb as more bad actors target Linux deployments... "While Windows is the favorite for desktops, Linux dominates the market for supercomputers and servers."
Here's how Halcyon's announcement made their pitch: "When it comes to ransomware protection, organizations typically prioritize securing Windows environments because that's where the ransomware operators were focusing most of their attacks. However, Linux-based systems are at the core of most any organization's infrastructure, and protecting these systems is often an afterthought," said Jon Miller, CEO & Co-founder, Halcyon. "The fact that Linux systems usually are always on and available means they provide the perfect beachhead for establishing persistence and moving laterally in a targeted network, and they can be leveraged for data theft where the exfiltration is easily masked by normal network traffic. As more ransomware operators are developing the capability to target Linux systems alongside Windows, it is imperative that organizations have the ability to keep pace with the expanded threat."

Halcyon Linux, powered through the Halcyon Anti-Ransomware Platform, uniquely secures Linux-based systems offering comprehensive protection and rapid response capabilities... Halcyon Linux monitors and detects ransomware-specific behaviors such as unauthorized access, lateral movement, or modification of critical files in real-time, providing instant alerts with critical context... When ransomware is suspected or detected, the Halcyon Ransomware Response Engine allows for rapid response and action.... Halcyon Data Exfiltration Protection (DXP) identifies and blocks unauthorized data transfers to protect sensitive information, safeguarding the sensitive data stored in Linux-based systems and endpoints...

Halcyon Linux runs with minimal resource impact, ensuring critical environments such as database servers or virtualized workloads, maintain the same performance.
And in addition, Halcyon offers "an around the clock Threat Response team, reviewing and responding to alerts," so your own corporate security teams "can attend to other pressing priorities..."

An anonymous reader quotes a report from Liliputing: The Fedora Asahi Remix GNU/Linux distribution is now shipping with alpha versions of OpenGL, OpenCL, and Vulkan graphics drivers that allow you to play some games on Macs with M1 or M2 series processors. But there are a few things to keep in mind. One is that most of the PC games you're likely going to want to play are designed to run on Windows PCs with DirectX drivers and x86 processors. So there's some emulation required to get them to run on Macs with ARM-based processors, a Linux-based operating system, and Vulkan drivers.

Some of the work was also made possible by the folks at Valve, who developed the Proton software that allows many PC games to run on Linux. And during a live demo at XDC 2024, developer Alyssa Rosenzweig demonstrated the Steam game client loading and running on an Apple Silicon Mac running Asahi Linux. For that reason, it takes a lot of RAM -- according to the Asahi team, "most games require 16GB of memory due to emulation overhead." So you're probably not going to be able to do much entry-level gaming on an entry-level Mac with just 8GB of RAM.

Some of the titles that have been confirmed to be playable include Cyberpunk 2077, The Witcher 3, Fallout 4, Control, Portal 2, and Ghostrunner. But there's a difference between playable and smooth. Developers say performance improvements will be required before "newer AAA titles" can run at 60 frames per second or higher. But less demanding games like Hollow Knight should run at full speed.

Phoronix's Michael Larabel reports: Yesterday when announcing the Linux 6.12-rc2 kernel, Linus Torvalds asked that the kernel maintainers do a better job moving forward with their commit messages. In particular, Torvalds is hoping that kernel maintainers will do a better job using an active, imperative voice when describing the changes within their pull requests.

The Linux creator explained in the 6.12-rc2 announcement: "Anyway, on a completely different note: I try to make my merge commit messages be somewhat "cohesive", and so I often edit the pull request language to match a more standard layout and language. It's not a big deal, and often it's literally just about whitespace so that we don't have fifteen different indentation models and bullet syntaxes. I generally do it as I read through the text anyway, so it's not like it makes extra work for me. But what *does* make extra work is when some maintainers use passive voice, and then I try to actively rewrite the explanation (or, admittedly, sometimes I just decide I don't care quite enough about trying to make the messages sound the same). So I would ask maintainers to please use active voice, and preferably just imperative. [...]"

"Pine64 has confirmed that its open-source e-ink tablet is returning," reports the blog OMG Ubuntu: The [10.1-inch e-ink display] PineNote was announced in 2021, building on the success of its non-SBC devices like the PinePhone (and later Pro model), the PineTab, and PineBook devices. Like most of Pine64's devices, software support is largely tackled by the community. But only a small batch of developer units were ever sold, primarily by enthusiasts within the open-source community who had the knowledge and desire to work on getting a modern Linux OS to run on the hardware, and adapt to the e-ink display.

That process has taken a while, as Pine64's community bloggers explain:

"The PineNote was stuck in a chicken-and-egg situation because of the very high cost of manufacturing the device (ePaper screens are sadly still expensive), and so the risk of manufacturing units that then didn't have a working Linux OS and would not sell was huge."

However, the proverbial egg has finally hatched. The PineNote now has a reliable Debian-based OS, developed by Maximilian Weigand. This is described as "not only a bare-bones capable OS but a genuinely daily-usable system that 'just works'" according to the Pine64 blog. ["This is excellent as it also moves the target audience from developers to every day users. You should be able to power on the device and drop into a working Gnome experience."] It is said to use the GNOME desktop plus a handful of extensions designed to ensure the UI adapts to working well with an e-ink display. Software pre-installed includes Xournal++ for note taking, Firefox for web browsing, and Foliate for reading ebooks, among others. [And it even runs Doom...]

Existing PineNote owners can download the the new OS image, flash it to their device, and help test it... Touch and stylus input are major selling points of the PineNote, positioning it as a libre alternative to leading e-ink note-taking devices like the Remarkable 2, Onyx BOOX, and Amazon Scribe.
"I do not (yet) have a launch date target," according to the blog post, "as behind-the-scenes the Pine Store team are still working on all things production."

But the update also links to some blog posts about their free and open source smartwatch PineTime...

A sophisticated malware strain has infected thousands of Linux systems since 2021, exploiting over 20,000 common misconfigurations and a critical Apache RocketMQ vulnerability, researchers at Aqua Security reported. Dubbed Perfctl, the malware employs advanced stealth techniques, including rootkit installation and process name mimicry, to evade detection. It persists through system reboots by modifying login scripts and copying itself to multiple disk locations. Perfctl hijacks systems for cryptocurrency mining and proxy services, while also serving as a backdoor for additional malware. Despite some antivirus detection, the malware's ability to restart after removal has frustrated system administrators.

The Arch Linux team has announced a collaboration with Valve, working to support critical infrastructure projects like a build service and secure signing enclave for the Arch Linux distribution. Tom's Hardware reports: If you're familiar with Valve and Steam Deck, you may already know that the Deck uses SteamOS 3, which is built on top of Arch Linux. Thanks to the Arch Linux base and Valve's development of the Proton compatibility layer for playing Windows games on Linux, we now have a far improved Linux gaming scene, especially on Valve's Steam Deck and Deck OLED handhelds. While Valve's specific reasons for picking Arch Linux for Steam Deck remain unknown, it's pretty easy to guess why it was picked. Mainly, it's a particularly lightweight distribution maintained since March 2002, which lends itself well to gaming with minimal performance overhead. A more intensive Linux distribution may not have been the ideal base for SteamOS 3, which is targeted at handhelds like Steam Deck first.

As primary Arch Linux developer Levente Polyak discloses in the announcement post, "Valve is generously providing backing for two critical projects that will have a huge impact on our distribution: a build service infrastructure and a secure signing enclave. By supporting work on a freelance basis for these topics, Valve enables us to work on them without being limited solely by the free time of our volunteers." Polyak continues, "This opportunity allows us to address some of the biggest outstanding challenges we have been facing for a while. The collaboration will speed up the progress that would otherwise take much longer for us to achieve, and will ultimately unblock us from finally pursuing some of our planned endeavors [...] We believe this collaboration will greatly benefit Arch Linux, and are looking forward to share further development on the mailing list as work progresses."

Long-time Slashdot reader dmitrygr writes: Debian Linux booted on a 4-bit intel microprocessor from 1971 — the first microprocessor in the world — the 4004. It is not fast, but it is a real Linux kernel with a Debian rootfs on a real board whose only CPU is a real intel 4004 from the 1970s.
There's a detailed blog post about the experiment. (Its title? "Slowly booting full Linux on the intel 4004 for fun, art, and absolutely no profit.")

In the post dmitrygr describes testing speed optimizations with an emulator where "my initial goal was to get the boot time under a week..."

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?