UPDATE: Blijkt dat het artikel 73 al sinds 2013 vragen oproept.
Vandaag in het nieuws dat een AIVD agent meegeholpen zou hebben aan het saboteren van het Iraanse kernwapenprogramma. Dit lijkt me uitstekend. Maar politiek Den Haag schijnt van niets geweten te hebben. En dat zou best kunnen, want de AIVD en MIVD mogen agenten dingen laten saboteren zonder toestemming van minister of toetsingscommissie, en dat is raar:
https://berthub.eu/articles/posts/het-curieuze-artikel-73-aivd-mivd/

For those of you who remember stuxnet, more details about how the virus actually might have gotten into the system it was designed for has been disclosed thanks to the Volksrant:

https://www.volkskrant.nl/kijkverder/v/2024/sabotage-in-iran-een-missie-in-duisternis~v989743/

(disclaimer, yes, it's in Dutch, but tools like google translate work well on it, and no, my Dutch is not good enough to read it in the native form, still working on that, ik lees een beetje Nederlands.)

@vbabka @rostedt @qyousef exactly, I'll gladly take dependent patches like that, would prefer to in fact, makes it simpler for everyone involved.

@warthog9 Many thanks to you and
@monsieuricon 's work here and your continued work to keep vger alive all these years, it's one of the primary reasons that Linux development works so well.

Ok, Vger's MX is heading off to point to subspace on Thursday. Web services are staying put for now, so if you link to / use Vger it's staying put (possibly with a massive OS upgrade coming).

The fundamental infrastructure isn't going anywhere even if it has to change it's name, and should lists not want to head off to subspace, infradead, etc I've got https://vger.email up and running and capable of picking things up should anyone want to jump.

End of an era, Vger's been independent of kernel.org from it's start, but it's a non-trivial set of lists that literally keep the Linux kernel community moving, and has since it's inception. It's realistically needed an upgrade to deal with a plethora of problems, and frankly various large e-mail providers have made it nearly untenable to keep doing without it nearly being a full time job (at least at the scale that Vger's at)

It would be very silly to install and boot the stable kernel instead of the usual latest rc, just because it has some specific version number. But stable kernels need testing too!

Dirk: "Are you worried about bugs from LLM hallucinations getting into the #Linux kernel?" Linus: "Well I see all the bugs that come in without LLMs, and so, no I don't." (Paraphrasing the exchange)

Little known fact: first kernel releases were shipped via the postal service.

@oleksandr @kernellogger @vbabka You can't do that, as many many developers do not properly tag real bugfixes with cc: stable, which is why we now take anything with Fixes: on it, when they seem sane.

Again, the patch that caused you problems here was marked this way so that it did get some "soaking" in linux-next and and delayed the stable backport for a few weeks on purpose. It flowed into stable into the correct way, this is as designed.

Well, except for the breakage, but that's what normally happens with hardware, go blame the vendors for that :)

@oleksandr @kernellogger That commit was tagged that way so it would be properly backported, if it's buggy then please let the developers know about it!

@oleksandr What do you mean by "properly reviewed"? They have all passed the normal review process in that they are in Linus's tree. If they are good enough for the next release, why are they not good enough for the previous one?

And as always, reviews for things that you think should not be included are greatly appreciated, we can't do any of this without you!

If you enjoy the hairiest of bug hunts with a thrilling conclusion, this one is for you. The hunt and hair pulling:

https://lore.kernel.org/regressions/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/

and the conclusion:

https://lore.kernel.org/regressions/1105090647.48374193.1700351103830.JavaMail.zimbra@raptorengineeringinc.com/

Hats off to Timothy for seeing this one through to completion!

So, you want to read LKML with Gmail (experimental, testers needed)

https://lore.kernel.org/workflows/20231115-black-partridge-of-growth-54bf2e@nitro/

@exi @kernellogger We will finally get to relax at that time. Or at least we can look forward to the potential to relax, providing us hope when buried neck-deep in stable backports...

@vegard @kernellogger Ah, so back in February we made it 4 years, not 2, so why did everyone freak out a month ago thinking it was going to be 2 years?

Math with dates is hard :)

@kernellogger Yes, that's why the dates are like this.

And I just realized, we never publicly said anything about "2 years support for LTS", the kernel.org page has always had longer dates, all we said was "we will not be doing 6 years anymore".

So no one actually looks at the documentation we write (i.e. the web page), AND I didn't even remember that we had written that back in February of this year, this feels like a "write once, read never" type of file...

So many truths are hidden,
So many facts untold,
Queries left unbidden,
Concealed below the fold.

My head droops to the table,
But I must remain informed:
"Is the kernel stable?"
"How is babby formed?"

RFC for the replacing the Linux kernel #Android #Binder driver with a fully functional #Rust version:

https://lore.kernel.org/lkml/20231101-rust-binder-v1-0-08ba9197f637@google.com/

All the talks from Embedded Recipes 2023 are now online, including "The TTY Layer: the Past, Present, and Future" by @gregkh https://www.youtube.com/watch?v=g4sZUBS57OQ&list=PLwnbCeeZfQ_Mi7gjUpLZxXGOcEBS_K8kH&index=5 #er2023

@davidrevoy @standingpad Use email, that's how the kernel is developed and how bugs are reported, send it to the author of that commit and the mailing list listed in the MAINTAINERS file for the subsystem.

No need to file some ticket in some random web form with some odd account, email. It's simple, and easy (note, turn off HTML mode for it please.)

Good luck!