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

@fn @ncopa Ouch, that's slow.

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/

@multisn8 Oops, yes, it is "GPD", I've now fixed the post, thanks for catching that.

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

@sjvn @theregister Nice summary of my talk, thanks for doing that!

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.

@ncopa You do NOT want to see the kcbench results for the riscv system I have here, it's so sad it's not even funny. So sad I haven't even powered it on in a few months, it's pretty much useless :(

@kernellogger @jeroen @axboe When using "cloud" machines, many of them have horribly slow storage paths, so yes, it does affect kernel build times on those systems. Now if the "cache" really does anything for that type of storage or not, I do not know, but it can't hurt. Just like running sync 3 times before rebooting :)

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,

@msw @jacques @bagder Are people ignoring the fact that I do not think we have tools that can easily generate those SBOM files today?

Yes, I know about the REUSE tool from the FSFE, that's the best that we currently have but I don't think the output from it is what anyone seems to want these days. I've been publishing the output from that for years for usbutils and no one seems to even have noticed...

Am I just missing all of the wonderful tools out there that can simply generate a SBOM in a variety of needed formats from a project's tarball or normal autotools or meson build process?

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.

@msw @jacques @bagder I have no problem adding additional data like "This config option means you will not be vulnerable" to our records today, if people want to submit that information to us. We take patches and additions to the kernel cve.org records on a weekly basis from vendors that work to narrow down affected kernel ranges and add additional references.

So we could do what you want today, no changes to anything that cve.org does right now would be needed, just send us a patch! But that was not what was being proposed at all, unfortunately.