The GNOME Foundation, a non-profit organization supporting the GNOME desktop environment, has been operating at a deficit for several years, depleting its financial reserves. Robert McQueen, the foundation's president, has announced plans to increase fundraising efforts in a new blog post.

McQueen adds: As you may be aware, the GNOME Foundation has operated at a deficit (nonprofit speak for a loss -- ie spending more than we've been raising each year) for over three years, essentially running the Foundation on reserves from some substantial donations received 4-5 years ago. The Foundation has a reserves policy which specifies a minimum amount of money we have to keep in our accounts. This is so that if there is a significant interruption to our usual income, we can preserve our core operations while we work on new funding sources. We've now "hit the buffers" of this reserves policy, meaning the Board can't approve any more deficit budgets -- to keep spending at the same level we must increase our income.

Michael Larabel reports via Phoronix: While Fedora 41 in late 2024 is aiming to have more reproducible package builds, openSUSE Factory has already achieved a significant milestone in bit-by-bit reproducible builds. Since last month openSUSE Factory has been producing bit-by-bit reproducible builds sans the likes of embedded signatures. OpenSUSE Tumbleweed packages for that rolling-release distribution are being verified for bit-by-bit reproducible builds. SUSE/openSUSE is still verifying all packages are yielding reproducible builds but so far it's looking like 95% or more of packages are working out. You can learn more via the openSUSE blog.

Michael Larabel reports via Phoronix: With the Framework 16 laptop one of the performance pieces I've been meaning to carry out has been seeing out Linux performs against Microsoft Windows 11 for this AMD Ryzen 7 7840HS powered modular/upgradeable laptop. Recently getting around to it in my benchmarking queue, I also compared the performance of Ubuntu 23.10 to the near final Ubuntu 24.04 LTS on this laptop up against a fully-updated Microsoft Windows 11 installation. The Framework 16 review unit as a reminder was configured with the 8-core / 16-thread AMD Ryzen 7 7840HS Zen 4 SoC with Radeon RX 7700S graphics, a 512GB SN810 NVMe SSD, MediaTek MT7922 WiFi, and a 2560 x 1600 display.

In the few months of testing out the Framework 16 predominantly under Linux it's been working out very well. With also having a Windows 11 partition as shipped by Framework, after updating that install it made for an interesting comparison against the Ubuntu 23.10 and Ubuntu 24.04 performance. The same Framework 16 AMD laptop was used throughout all of the testing for looking at the out-of-the-box performance across Microsoft Windows 11, Ubuntu 23.10, and the near-final state of Ubuntu 24.04. [...]

Out of 101 benchmarks carried out on all three operating systems with the Framework 16 laptop, Ubuntu 24.04 was the fastest in 67% of those tests, the prior Ubuntu 23.10 led in 22% (typically with slim margins to 24.04), and then Microsoft Windows 11 was the front-runner just 10% of the time... If taking the geomean of all 101 benchmark results, Ubuntu 23.10 was 16% faster than Microsoft Windows 11 while Ubuntu 24.04 enhanced the Ubuntu Linux performance by 3% to yield a 20% advantage over Windows 11 on this AMD Ryzen 7 7840HS laptop. Ubuntu 24.04 is looking very good in the performance department and will see its stable release next week.

Michael Larabel reports via Phoronix: Within yesterday's Linux 6.9-rc4 release is an interesting little nugget by Linus Torvalds to battle Kconfig parsers that can't correctly handle tabs but rather just assume spaces for whitespace for this kernel configuration format. Due to a patch having been queued last week to replace a tab with a space character in the kernel tracing Kconfig file, Linus Torvalds decided to take matters into his own hand for Kconfig parsers that can't deal with tabs... Torvalds authored a patch to intentionally add some tabs of his own into Kconfig for throwing off any out-of-tree/third-party parsers that can't correctly handle them. Torvalds added these intentional hidden tabs to the common Kconfig file for handling page sizes for the kernel. Thus sure to cause dramatic and noticeable breakage for any parsers not having tabs correctly.

Slashdot reader Mononymous writes: The latest release of OpenBSD, the FOSS Unix-like operating system focused on correctness and security over features and performance, has been released. This version includes newer driver support, performance improvements, stability fixes, and lots of package updates. One highlight is a complete port of KDE Plasma 5.

You can view the announcement and get the bits at OpenBSD.org.
Phoronix reports that with OpenBSD 7.5 "there is a number of improvements for ARM (AArch64) hardware, never-ending kernel optimizations and other tuning work, countless package updates, and other adjustments to this popular BSD platform."

"What a time we live in," writes Phoronix, "where Microsoft not only continues contributing significantly to the Linux kernel but doing so to further flesh out the design of the Linux kernel's Rust programming language support..." Microsoft engineer Wedson Almeida Filho has sent out the latest patches working on Allocation APIs for the Rust Linux kernel code and also in leveraging those proposed APIs [as] a means of allowing in-place module initialization for Rust kernel modules. Wedson Almeida Filho has been a longtime Rust for Linux contributor going back to his Google engineering days and at Microsoft the past two years has shown no signs of slowing down on the Rust for Linux activities...

The Rust for Linux kernel effort remains a very vibrant effort with a wide variety of organizations contributing, even Microsoft engineers.

"After being in development since 2019, the huge NetBSD 10.0 is out today as a wonderful Easter surprise," reports Phoronix: NetBSD 10 provides WireGuard support, support for many newer Arm platforms including for Apple Silicon and newer Raspberry Pi boards, a new Intel Ethernet drive, support for Realtek 2.5GbE network adapters, SMP performance improvements, automatic swap encryption, and an enormous amount of other hardware support improvements that accumulated over the past 4+ years.

Plus there is no shortage of bug fixes and performance optimizations with NetBSD 10. Some tests of NetBSD 10.0 in development back during 2020 showed at that point it was already 12% faster than NetBSD 9.
"A lot of development went into this new release," NetBSD wrote on their blog, saying "This also caused the release announcement to be one of the longest we ever did."

Among the new userspace programs is warp(6), which they describe as a "classic BSD space war game (copyright donated to the NetBSD Foundation by Larry Wall)."

Michael Larabel reports via Phoronix: Given the recent change by Redis to adopt dual source-available licensing for all their releases moving forward (Redis Source Available License v2 and Server Side Public License v1), the Linux Foundation announced today their fork of Redis. The Linux Foundation went public today with their intent to fork Valkey as an open-source alternative to the Redis in-memory store. Due to the Redis licensing changes, Valkey is forking from Redis 7.2.4 and will maintain a BSD 3-clause license. Google, AWS, Oracle, and others are helping form this new Valkey project.

The Linux Foundation press release shares: "To continue improving on this important technology and allow for unfettered distribution of the project, the community created Valkey, an open source high performance key-value store. Valkey supports the Linux, macOS, OpenBSD, NetBSD, and FreeBSD platforms. In addition, the community will continue working on its existing roadmap including new features such as a more reliable slot migration, dramatic scalability and stability improvements to the clustering system, multi-threaded performance improvements, triggers, new commands, vector search support, and more. Industry participants, including Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. are supporting Valkey. They are focused on making contributions that support the long-term health and viability of the project so that everyone can benefit from it."

Michael Larabel writes via Phoronix: Fedora Workstation has long defaulted to using GNOME's Wayland session by default, but it has continued to install the GNOME X.Org session for fallback purposes or those opting to use it instead. But for the Fedora Workstation 41 release later in the year, there is a newly-approved plan to no longer have that GNOME X.Org session installed by default. Recently there was a Fedora Workstation ticket opened to no longer install the GNOME X.Org session by default. This is just about whether the X.Org session is pre-installed but would continue to live in the repository for those wanting to explicitly install it.

The Fedora Workstation working group decided to go ahead with this change for the Fedora 41 cycle, not the upcoming Fedora 40 release. So pending any obstacles by FESCo, which is unlikely. Fedora Workstation 41 will not be installing the GNOME X.Org session by default. Long live Wayland.

Michael Larabel, reporting at Phoronix: One of the limitations of AMD's open-source Linux graphics driver has been the inability to implement HDMI 2.1+ functionality on the basis of legal requirements by the HDMI Forum. AMD engineers had been working to come up with a solution in conjunction with the HDMI Forum for being able to provide HDMI 2.1+ capabilities with their open-source Linux kernel driver, but it looks like those efforts for now have concluded and failed. For three years there has been a bug report around 4K@120Hz being unavailable via HDMI 2.1 on the AMD Linux driver. Similarly, there have been bug reports like 5K @ 240Hz not possible either with the AMD graphics driver on Linux.

As covered back in 2021, the HDMI Forum closing public specification access is hurting open-source support. AMD as well as the X.Org Foundation have been engaged with the HDMI Forum to try to come up with a solution to be able to provide open-source implementations of the now-private HDMI specs. AMD Linux engineers have spent months working with their legal team and evaluating all HDMI features to determine if/how they can be exposed in their open-source driver. AMD had code working internally and then the past few months were waiting on approval from the HDMI Forum. Sadly, the HDMI Forum has turned down AMD's request for open-source driver support.

Michael Larabel reports via Phoronix: Back in 2022 Cloudflare announced they were ditching Nginx for an in-house, Rust-written software called Pingora. Today Cloudflare is open-sourcing the Pingora framework. Cloudflare announced today that they have open-sourced Pingora under an Apache 2.0 license. Pingora is a Rust async multi-threaded framework for building programmable network services. Pingora has long been used internally within Cloudflare and is capable of sustaining a lot of traffic while now Pingora is being open-sourced for helping to build infrastructure outside of Cloudflare. The Pingora Rust code is available on GitHub.

Michael Larabel reports via Phoronix: With Valve's release today of the Steam Audio SDK 4.5.2 they have made the software development kit fully open-source under an Apache 2.0 license. Steam Audio 4.5.2 may not sound exciting in the context of a version number but as described in the release announcement is now "the first open source release of the Steam Audio SDK source code." The rest of this work in this Steam Audio SDK release amounts to bug fixes and other standard changes.

In a SteamCommunity.com announcement posted today entitled "Steam Audio Open Source Release," it notes: "The entire Steam Audio codebase, including both the SDK and all plugins, is now released under the Apache 2.0 license. This allows developers to use Steam Audio in commercial products, and to modify or redistribute it under their own licensing terms without having to include source code. We welcome contributions from developers who would like to fix bugs or add features to Steam Audio." You can learn more about Steam Audio via the project site.

An anonymous reader shared this post from Phoronix: With Linux 6.8 the kernel's Rust code was brought up to Rust 1.75 while new patches posted this weekend port the code over to Rust 1.76 and then the upcoming Rust 1.77...

With Rust 1.77 they have now stabilized the single-field "offset_of" feature used by the kernel's Rust code. Rust 1.77 also adds a "--check-cfg" option that the Rust kernel code will likely transition to in the future. This follows the Rust for Linux policy of tracking the upstream Rust version upgrades until there is a minimum version that can be declared where all used features are considered stable.

An anonymous reader shared this report from PCWorld: The Standard Performance Evaluation Corporation, better known as SPEC, has invalidated over 2600 of its own results testing Xeon processors in the 2022 and 2023 version of its popular industrial SPEC CPU 2017 test. After investigating, SPEC found that Intel had used compilers that were, quote, "performing a compilation that specifically improves the performance of the 523.xalancbmk_r / 623.xalancbmk_s benchmarks using a priori knowledge of the SPEC code and dataset to perform a transformation that has narrow applicability."

In layman's terms, SPEC is accusing Intel of optimizing the compiler specifically for its benchmark, which means the results weren't indicative of how end users could expect to see performance in the real world. Intel's custom compiler might have been inflating the relevant results of the SPEC test by up to 9%...

Slightly newer versions of the compilers used in the latest industrial Xeon processors, the 5th-gen Emerald Rapids series, do not use these allegedly performance-enhancing APIs. I'll point out that both the Xeon processors and the SPEC 2017 test are some high-level hardware meant for "big iron" industrial and educational applications, and aren't especially relevant for the consumer market we typically cover.
More info at ServeTheHome, Phoronix, and Tom's Hardware.

Some ZFS news from Phoronix this week. "At the end of last year OpenZFS 2.2.2 was released to fix a rare but nasty data corruption issue, but it turns out there are other data corruption bug(s) still lurking in the OpenZFS file-system codebase." A Phoronix reader wrote in today about an OpenZFS data corruption bug when employing native encryption and making use of send/recv support. Making use of zfs send on an encrypted dataset can cause one or more snapshots to report errors. OpenZFS data corruption issues in this area have apparently been known for years.

Since May 2021 there's been this open issue around ZFS corruption related to snapshots on post-2.0 OpenZFS. That issue remains open. A new ticket has been opened for OpenZFS as well in proposing to add warnings against using ZFS native encryption and the send/receive support in production environments.
jd (Slashdot reader #1,658) spotted the news — and adds a positive note. "Bugs, old and new, are being catalogued and addressed much more quickly now that core development is done under Linux, even though it is not mainstreamed in the kernel."

Michael Larabel writes via Phoronix: While there have been efforts by AMD over the years to make it easier to port codebases targeting NVIDIA's CUDA API to run atop HIP/ROCm, it still requires work on the part of developers. The tooling has improved such as with HIPIFY to help in auto-generating but it isn't any simple, instant, and guaranteed solution -- especially if striving for optimal performance. Over the past two years AMD has quietly been funding an effort though to bring binary compatibility so that many NVIDIA CUDA applications could run atop the AMD ROCm stack at the library level -- a drop-in replacement without the need to adapt source code. In practice for many real-world workloads, it's a solution for end-users to run CUDA-enabled software without any developer intervention. Here is more information on this "skunkworks" project that is now available as open-source along with some of my own testing and performance benchmarks of this CUDA implementation built for Radeon GPUs. [...]

For those wondering about the open-source code, it's dual-licensed under either Apache 2.0 or MIT. Rust fans will be excited to know the Rust programming language is leveraged for this Radeon implementation. [...] Those wanting to check out the new ZLUDA open-source code for Radeon GPUs can do so via GitHub.

In 2003, Hans Reiser answered questions from Slashdot's readers...

Today Wikipedia describes Hans Reiser as "a computer programmer, entrepreneur, and convicted murderer... Prior to his incarceration, Reiser created the ReiserFS computer file system, which may be used by the Linux kernel but which is now scheduled for removal in 2025, as well as its attempted successor, Reiser4."

This week alanw (Slashdot reader #1,822), spotted a development on the Linux kernel mailing list. "Hans Reiser (imprisoned for the murder of his wife) has written a letter, asking it to be published to Slashdot." Reiser writes: I was asked by a kind Fredrick Brennan for my comments that I might offer on the discussion of removing ReiserFS V3 from the kernel. I don't post directly because I am in prison for killing my wife Nina in 2006.

I am very sorry for my crime — a proper apology would be off topic for this forum, but available to any who ask.

A detailed apology for how I interacted with the Linux kernel community, and some history of V3 and V4, are included, along with descriptions of what the technical issues were. I have been attending prison workshops, and working hard on improving my social skills to aid my becoming less of a danger to society. The man I am now would do things very differently from how I did things then.
Click here for the rest of Reiser's introduction, along with a link to the full text of the letter...

The letter is dated November 26, 2023, and ends with an address where Reiser can be mailed. Ars Technica has a good summary of Reiser's lengthy letter from prison — along with an explanation for how it came to be. With the ReiserFS recently considered obsolete and slated for removal from the Linux kernel entirely, Fredrick R. Brennan, font designer and (now regretful) founder of 8chan, wrote to the filesystem's creator, Hans Reiser, asking if he wanted to reply to the discussion on the Linux Kernel Mailing List (LKML). Reiser, 59, serving a potential life sentence in a California prison for the 2006 murder of his estranged wife, Nina Reiser, wrote back with more than 6,500 words, which Brennan then forwarded to the LKML. It's not often you see somebody apologize for killing their wife, explain their coding decisions around balanced trees versus extensible hashing, and suggest that elementary schools offer the same kinds of emotional intelligence curriculum that they've worked through in prison, in a software mailing list. It's quite a document...

It covers, broadly, why Reiser believes his system failed to gain mindshare among Linux users, beyond the most obvious reason. This leads Reiser to detail the technical possibilities, his interpersonal and leadership failings and development, some lingering regrets about dealings with SUSE and Oracle and the Linux community at large, and other topics, including modern Russian geopolitics... Reiser asks that a number of people who worked on ReiserFS be included in "one last release" of the README, and to "delete anything in there I might have said about why they were not credited." He says prison has changed him in conflict resolution and with his "tendency to see people in extremes...."

Reiser writes that he understood the difficulty ahead in getting the Linux world to "shift paradigms" but lacked the understanding of how to "make friends and allies of people" who might initially have felt excluded. This is followed by a heady discussion of "balanced trees instead of extensible hashing," Oracle's history with implementing balanced trees, getting synchronicity just right, I/O schedulers, block size, seeks and rotational delays on magnetic hard drives, and tails. It leads up to a crucial decision in ReiserFS' development, the hard non-compatible shift from V3 to Reiser 4. Format changes, Reiser writes, are "unwanted by many for good reasons." But "I just had to fix all these flaws, fix them and make a filesystem that was done right. It's hard to explain why I had to do it, but I just couldn't rest as long as the design was wrong and I knew it was wrong," he writes. SUSE didn't want a format change, but Reiser, with hindsight, sees his pushback as "utterly inarticulate and unsociable." The push for Reiser 4 in the Linux kernel was similar, "only worse...."

He encourages people to "allow those who worked so hard to build a beautiful filesystem for the users to escape the effects of my reputation." Under a "Conclusion" sub-heading, Reiser is fairly succinct in summarizing a rather wide-ranging letter, minus the minutiae about filesystem architecture.

I wish I had learned the things I have been learning in prison about talking through problems, and believing I can talk through problems and doing it, before I had married or joined the LKML. I hope that day when they teach these things in Elementary School comes.

I thank Richard Stallman for his inspiration, software, and great sacrifices,

It has been an honor to be of even passing value to the users of Linux. I wish all of you well.


It both is and is not a response to Brennan's initial prompt, asking how he felt about ReiserFS being slated for exclusion from the Linux kernel. There is, at the moment, no reply to the thread started by Brennan.

"A Canonical engineer has been experimenting with implementing a Linux scheduler within the Rust programming language..." Phoronix reported Monday, "that works via sched_ext for implementing a scheduler using eBPF that can be loaded during run-time."

The project was started "just for fun" over Christmas, according to a post on X by Canonical-based Linux kernel engineer Andrea Righi, adding "I'm pretty shocked to see that it doesn't just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads (i.e., gaming)." Phoronix notes the a YouTube video accompanying the tweet shows "a game with the scx_rustland scheduler outperforming the default Linux kernel scheduler while running a parallel kernel build in the background."

"For sure the build takes longer," Righi acknowledged in a later post. "This scheduler doesn't magically makes everything run faster, it simply prioritizes more the interactive workloads vs CPU-intensive background jobs." Righi followed up by adding "And the whole point of this demo was to prove that, despite the overhead of running a scheduler in user-space, we can still achieve interesting performance, while having the advantages of being in user-space (ease of experimentation/testing, reboot-less updates, etc.)"

Wednesday Righi added some improvements, posting that "Only 19 lines of code (comments included) for ~2x performance improvement on SMT isn't bad... and I spent my lunch break playing Counter Strike 2 to test this patch..."

And work seems to be continuing, judging by a fresh post from Righi on Thursday. "I fixed virtme-ng to run inside Docker and used it to create a github CI workflow for sched-ext that clones the latest kernel, builds it and runs multiple VMs to test all the scx schedulers. And it does that in only ~20min. I'm pretty happy about virtme-ng now."

serviscope_minor shares a Phoronix post: A six year old Linux kernel mailing list discussion has been reignited over the prospects of converting the Linux kernel to supporting modern C++ code. The Linux kernel is predominantly made up of C code with various hand-written Assembly plus the growing work around supporting Rust within the Linux kernel. While it's not clear yet if there's sufficient weight to make it a reality, a Linux kernel mailing list discussion has been restarted over potentially seeing the Linux kernel C code converted to C++ in the future.

Back on 1 April 2018 was a set of 45 patches by Red Hat engineer David Howells to begin converting the kernel to C++. This would allow the mainline kernel to make use of inline template functions, inline overloaded functions, class inheritance, and other features not currently supported by the Linux kernel with its C code. A bit hard to make serious discussions that day and ultimately the patches resided on the Linux kernel mailing list for six years without much discussion. serviscope_minor adds: It is notable that the current discussion is somewhat different from the infamous discussions in the past.

Michael Larabel reports via Phoronix: AMD engineers are proposing an FPGA Subsystem User-Space Interface to overcome current limitations of the Linux kernel's FPGA manager subsystem. AMD-Xilinx engineers are proposing a new sysfs interface for the FPGA subsystem that allows for more user-space control over FPGAs. The suggested interface would handle FPGA configuration, driver probe/remove, bridges, Device Tree Overlay file support for re-programming an FPGA while the operating system is running, and other capabilities for user-space not currently presented by the mainline kernel. [...] This proposal from AMD hopes to standardize the FPGA subsystem user-space interface in a manner that is suitable for upstreaming into the mainline Linux kernel.