#Linux 6.16.2 and 6.12.43 are out.

And 6.15.11, too, but note:

""Note, this is the LAST 6.15.y kernel release, this branch is now end-of-life. Please move to the 6.16.y kernel branch at this point in time.""

https://lore.kernel.org/all/2025082012-jingling-alarm-7380@gregkh/

Why are anime catgirls blocking my access to the Linux kernel?

https://lock.cmpxchg8b.com/anubis.html

""The name sure sounds like “mutex”, and that is where the name comes from: “fast, user space mutex”. But, it isn’t really, it’s a building block for concurrency primitives that ushered in a modern world of concurrent performance […]

t was immediately clear that the futex was a huge improvement in highly concurrent environments. Just in that original paper, their tests with 1000 parallel tasks ran 20-120 times faster than sysv locks..

Needless to say, other common operating systems followed suit, including Windows in 2012 and macOS by 2016.

These days, any good locking primitive is going to be based on a futex. […]""

https://h4x0r.org/futex/

Without the Futex, It's Futile

https://h4x0r.org/futex/

Nvidia Tilus: A Tile-Level GPU Kernel Programming Language

https://github.com/NVIDIA/tilus

#HackerNews #Nvidia #Tilus #Tile-Level #GPU #Kernel #Programming #Language #Graphics #Programming #GPU #Development #Nvidia

The #Linux #framebuffer #console is great!

https://www.kernel.org/doc/html/v6.14/fb/fbcon.html

What if it's the only output though and the #kernel runs into a #crash before that console is initialized? You'd have a bad time!

Note that there are many ways to output images, not only through full-blown graphics cards. Tiny I2C and SPI displays also work. Those simple buses can be initialized early enough.

So how can we rework Linux to use, say, a SPI attached OLED display as an *early* console? I am taking notes on that.

Linux Kernel 6.17 RC2 Released: A Smallest RC So Far #linux #kernel
https://ostechnix.com/linux-kernel-6-17-rc2-released/

1x1 on "how to make readers take away a 'both sides are at fault' feeling, when in fact is primarily one side that is the problem here."

[not linking to the story shown in the shot on purpose]

#Linux 6.17-rc2 is out:

https://lore.kernel.org/lkml/CAHk-=wiLHgdvJQkEW-pHcUuXOBJ9JOoKcZkzMaPSW60_-Mh90A@mail.gmail.com/

""So it's been a very calm week, and this is one of the smaller rc2 releases we've had lately. […]

[…] One day we're bound to hit that mythical merge window that doesn't introduce any bugs at all.

This merge window wasn't _that_ good, but maybe it was simply better than most?

Or maybe it's that much of Europe is still on vacation because it's August?

[…]

Let's hope next week ends up as quiet. Wouldn't that be nice?

Linus""

Happy @debian Day!
#Linux #Debian #kernel #OpenSource #OperatingSystem #FOSS

Boot smarter with Unified #Kernel Images (UKI)! See how #openSUSE integrates secure, static #initrds and streamlines boot reliability (from #OBS to deployment). A must-watch for #sysadmins & packagers! #Linux #oSC25 talk. https://youtu.be/Ryf1PIofsqw?si=6pWTOTJrS3-HPjQG

The Evolution of Linux CPU Schedulers: From O(1) to CFS to User‑Space Scheduling - By Codemia

https://codemia.io/blog/path/The-Evolution-of-Linux-CPU-Schedulers-From-O1-to-CFS-to-UserSpace-Scheduling

The number of #Linux computers is on the rise!

Read Linux Professional Institute (LPI) Editor Andrew Oram’s article to learn more and see how @tuxedocomputers built a thriving global business selling #GNU/Linux preinstalled notebooks and desktops, with their own Snap-free #OS, upstream #kernel, and #FOSS values: https://lpi.org/qody

@LPI #LPI #Linux #opensource #TUXEDOComputers #LinuxLaptop #FOSS #LinuxHardware #FOSS #LinuxComputer

Thought #1 (when seeing this article):

It's slow-news season, so someone yet again wrote something about what happens when Linus for one reason or another stops maintaining #Linux, as it's been a while since that topic made the rounds.

Thought #2 (when reading ""When @torvalds goes, the sense of discontinuity will be hard to bear, and the opportunism of commercial interests to grow influence will be non-zero. These are problems now that need addressing before they are ripened by events, and this is where succession planning should take place.""):

I might be wrong, but my gut feeling says that "planning the succession" bears more risk that commercial interests will try to use those plans to grow influence.

Thought #3:

Someone should ask 10 or 15 core developers if they think Linux would be at risk if Linus would be hit by a bus tomorrow.

[edit]

Thought #4:

There for 20+ years now was always someone that was clearly considered "second in command" that could take over when needed (and the current person actually did for one cycle); sure, it's neither public nor written down as such, but it's kind of agreed on among the core developers afaics, so it's not like there is no "succession plan".

[/edit]

https://www.theregister.com/2025/08/14/the_plan_for_linux_after/

Introduction to VirtIO, Part 2: Vhost

https://blogs.oracle.com/linux/post/introduction-to-virtio-part-2-vhost

Jonah Palmer writes: ""[…] #Vhost is a key optimization to #VirtIO that was created to offload data-plane processing from #Qemu into more efficient components.

We’ll start off by taking a more in-depth look into the causes of overhead in the data plane of a pure VirtIO configuration. We’ll talk about the costly operations that are involved, such as VM exits, VM entries, context switches, and userspace processing by Qemu. Then we’ll introduce vhost and elaborate on how it addresses these issues by moving data-plane operations either into the kernel (kernel-based vhost) or into a specialized userspace process (via vhost-user).

We’ll then dive into both #kernel-based vhost and vhost-user architectures, examining each in detail—including their advantages, drawbacks, typical use cases, and how they affect performance. […]"

#btrfs-progs 6.16 is out:

https://lore.kernel.org/all/20250813181054.9949-1-dsterba@suse.com/ & https://github.com/kdave/btrfs-progs/releases/tag/v6.16

Among the highlights are:

* defrag: new option --nocomp to request no compression (#Linux #kernel 6.17)
* build: add build support for Android
* mkfs: print label of existing filesystem if attempting to overwrite
* device usage: fix printing units of partition sizes, used to be in 512B sectors

Thx to #TokeHoilandJorgensen's @toke:

Revert "mac80211: Dynamically set #CoDel parameters per station":
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/?id=4876376988081d636a4c4e5f03a5556386b49087

is our beloved @mtaht in #OpenWrt as well:

https://github.com/openwrt/openwrt/commit/e005cdea10284975e81e77282d654a358f33d640