"This makes me 20% more productive!"
"So does cocaine."

X is where you find the people who think they run the Internet.

Bluesky is where you find the people who think they ought to run the Internet.

Mastodon is where you find the people who actually do run the Internet, and kind of wish they didn't.

(WIth apologies to Yes, Minister)

Linus @torvalds 's recipe for bad ISA design: https://lore.kernel.org/lkml/CAHk-=wji-hEV1U1x92TLsrPbpSPqDD7Cgv2YwzeL-mMbM7iaRA@mail.gmail.com/

So, this is what you meant, Arch Linux, right?

Greg Kroah-Hartman explains the Cyber Resilience Act for open source developers https://theregister.com/2025/09/30/cyber_reiliance_act_opinion_column/ via
@theregister & @sjvn

Greg K-H explains what #opensource developers need to know about the CRA, but why they don't need to be worried sick about it.

It took me two days, off and on, to read this. I consider it a clear-sighted and well-researched analysis of the coming collapse of the mega-scale AI companies, and OpenAI in particular.

https://www.wheresyoured.at/the-case-against-generative-ai/

Ed Zitron's been loud and consistent in his reporting for a long time.

Benchmarking the different machines in my office with the wonderful kcbench: http://www.kroah.com/log/blog/2025/10/01/the-only-benchmark-that-matters-is.../

#kr2025 is already over! A huge thank you…

... to all the speakers who made this edition such a success,

to our godfather @paulmckrcu who did an incredible job putting together and keeping track of the agenda,

to Jean-Christophe for making the livestream possible and running the sound and video so flawlessly,

to @Aissen for the amazing live blog,

to Erwan for his spot-on mic throws,

to Frank for joining us on this third day and adding that little touch of craziness to the conference,

Really nice talk by @gregkh at @KernelRecipes on the Cyber Resilience Act.

Really comforting, lots of facts-checking and acknowledging that the EU legal people are not against Open-Source developers. They do understand open-source and they did seek (and obtain) information from relevant technical people. It might not be perfect but I also really think it’s a step in the right direction, making manufacturers (and importers and distributors) responsible #kr2025

CRA? D'ont be afraid! You are already doing it!

Just check if your open source project is covered

#kr2025

@gregkh now, doing his "usual non technical talk". After CVEs, CRA!
#kr2025

The #Rust based Binder driver has hit linux-next and thus is slated for inclusion in #kernel 6.18. Congrats to Alice and everyone who helped making this possible!

From the patch description (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=eafedbc7c050c44744fbdf80bdf3315e860b7513):

""We're generally not proponents of rewrites (nasty uncomfortable things that make you late for dinner!). So why rewrite Binder?

Binder has been evolving over the past 15+ years to meet the evolving needs of Android. Its responsibilities, expectations, and complexity have grown considerably during that time. While we expect Binder to continue to evolve along with Android, there are a number of factors that currently constrain our ability to develop/maintain it. Briefly those are:

1. Complexity: […]
2. Things to improve: Thousand-line functions, error-prone error handling, and confusing structure […]
3. Security critical […]

The biggest change is obviously the choice of programming language. We decided to use Rust because it directly addresses a number of the challenges within Binder that we have faced during the last years. […]""

#kernel #rustlang

Some days it's great to get a patch series like this in your inbox: https://lore.kernel.org/all/20250912081718.3827390-1-tzungbi@kernel.org/ implementing a feature to resolve so many reference count issues that a number of us kernel developers have been grumbling about for years.

Bonus is that it "looks like" the pattern that the Rust implementation in the kernel uses so switching between the two languages shouldn't be that difficult as the terminology and usage is not so different.

Pro tip, when sending a bug to the kernel security team, and it's reviewed and shown to not actually be a bug at all due to the report being "written" by a llm which can't actually parse C very well, don't proceed to "curse" the reviewer for pointing this out.

{sigh}

The other day me and @gregkh shot down a draft proposal to add a new role in the CVE ecosystem (SADP: "supplier ADP") that would append data to CVEs with details about dependencies and how they are or are not vulnerable to each particular CVE.

Imagine the amount of dependencies that use curl or the Linux kernel etc. These sweet innocent proposal makers thought in the terms of 5-10 dependencies per CVE. Not tens or hundreds of thousands which is far from unthinkable.

Recording (https://www.youtube.com/watch?v=O8Q8nIzEG6c ) and slides (https://static.sched.com/hosted_files/osseu2025/b3/pdx86-community-health-2025.pdf ) from Hans de Goede's #OSSEU25 talk "Creating a Healthy Vibrant [#Linux] #Kernel Subsystem Community" are now online.

From the abstract: "End 2020 I became the maintainer of the drivers/platform/x86 (pdx86) kernel subsytem. The subject of this talk is my experience in creating a friendly welcoming environment, growing the pdx86 community and how this helped me to avoid burnout by being able to delegate to community members."

https://osseu2025.sched.com/event/25VmE/creating-a-healthy-vibrant-kernel-subsystem-community-hans-de-goede-red-hat #LinuxKernel

The video of my presentation at OSSummit Europe is now available. 🇳🇱🐧

Those were 180 slides in 40 mins. 🫣😁 I hope people find it useful. Thanks! 🙂

Abstract & slides in the comments.

Linux Kernel Self-Protection Project 🐧🛡⚔️
#OSSummit #Linux #OpenSource

https://www.youtube.com/watch?v=nz0GId_zsIk

Suggestion for the week-end: Open Source Summit Europe 2025 video binge watching.

The Linux Foundation has just released all the videos they took at the OSS EU 2025 conference in Amsterdam. They are so many of them that they are hard to count!

https://www.youtube.com/watch?v=IGDWXA32xG4&list=PLbzoR-pLrL6qKwLt8A787ggMLHNivOHve

So, now you can attend OSS EU 2025 and the Embedded Linux Conference Europe 2025 free of charge, or if you attended, you can watch the many interesting talks that you missed.

Thanks to Ross Burton for sharing the news!

our community have always tried to embrace the upstream-first approach to development, and one of the largest roadblocks in that respect is often the Linux Kernel itself.

For better or worse it takes quite a lot of effort to get devicetree files and drivers upstreamed, but this is by far one of the more important goals for wider Linux Mobile adoption: upstream support makes devices more visible and encourages kernel maintainers to take more of an interest in the work we do

with that in mind, we are proposing an adjustment to the community device category requirements: to get your device into the community category it would now HAVE to have a devicetree in upstream, more specifically the upstream kernel needs to boot with some kind of display output and a working USB port - the bare minimum for easy tinkering, testing, and further development.

We hope that this will encourage device maintainers to get involved in upstream kernel development and submit their work rather than keeping everything in a kernel fork that they maintain

We are very open to feedback on this, please let us know what you think in the GitLab issue

https://gitlab.postmarketos.org/postmarketOS/postmarketos/-/issues/116

#LinuxMobile #postmarketOS #linux #kernel

nice https://reviews.freebsd.org/differential/changeset/?ref=1420532