If I want to stop receiving messages from you, I click "block and report as spam," which is dramatically faster and more effective, Jack.

"Subscribing" to mailing lists via sourcing a pop3 mailbox from lore.kernel.org now works. Should be of particular interest to gmail users.

I'll document after some more initial testing.

Humans: "I hate instances that allow more than 500 characters in a post. This is a microblogging service! If I wanted to read an article, I would read it on a real blog."
Same humans: "So, here's my thoughts on $thing. Thread 1/300."

I'm aware that the social.k.o home timeline isn't loading. Not sure why -- nothing obvious in the logs. I'm poking more.

Why didn't anyone warn me that the story line in Death Stranding is super messed up?

I'm aware that vger.kernel.org isn't able to deliver mail right now, but it's still not something I can fix (at least, not until we complete the migration).

All the right people have been alerted.

Critic: "EVs are too dangerous because Li-ion batteries are prone to overheating and exploding".
Same critic: *sticks a Li-ion battery into their ear where it's as close as possible to the brain*

If you wrote a crawler to retrieve lore.kernel.org messages instead of, you know, cloning the underlying git repositories and doing it locally, you are a bad person and you should feel ashamed.

My plans to register kernel.wtf to work as an easy alias for bugzilla bugs (kernel.wtf/217884) fell through because kernel.wtf is already registered.

Looks like migadu.com is having mail delivery problems. 📭

Every so often I see a post about how LLMs fail logic puzzles.

And... yes? Of course they do. The only way it could solve it is if it has seen the puzzle before or a substantially similar one. (But that might cause it to give the answer to the similar one, not the correct answer.)

Why is this even tested so often or considered surprising? It is, in essence, an autocomplete. It does not understand logic. It has no concept of a correct answer. It gives the most likely completion.

I hear you, but until vger migration is completed (some time hopefully in the next few months), I'm still not able to do anything about vger mail delivery issues.

Man, centos is so hostile to mirror admins. Instead of just requiring a username/password for mirroring, they restrict primary mirror access by IP, and to make any changes they require that mirror admins open a ticket on some very slow webby thing.

Every time someone claims that they have replaced OpenPGP with "something easier," I always look to see how they handle key management and trust delegation, and usually discover that it's just handwaved away.

Questions like this are a reminder that key management and trust delegation are the exact thing that makes OpenPGP "too hard" in the eyes of most people.

https://www.reddit.com/r/linuxquestions/comments/16c16fu/how_can_i_verify_the_pgp_keys_for_linus_torvalds/

Anyone else has `alias ungz=gunzip`?

The first of each month works as a regular reminder of how many mailman-2 servers there still are out there.

Did you ever wonder how those kernel releases make it to a mirror near you? Wonder no more, I've documented the process of delivering the latest set of stable kernels.

https://youtu.be/_MnZdrBJOwI?si=kfzFgfjr_yi8F4md

Oh no.

Here is a hopefully-useful notice about Linux kernel security issues, as it seems like this knowledge isn't distributed very widely based on the number of emails I get on a weekly basis:

- The kernel security team does not have any "early notice"
announcement list for security fixes for anyone, as that would only
make things more insecure for everyone.

- The kernel community does not assign CVEs, nor do we deal with them
at all. This is documented in the kernel's security policy, yet we
still have a number of people asking for CVE numbers even after
reading that policy. See my longer "CVEs are dead..." talk for full
details about how the CVE process is broken for projects like Linux:
https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/

- You HAVE to take all of the stable/LTS releases in order to have a
secure and stable system. If you attempt to cherry-pick random
patches you will NOT fix all of the known, and unknown, problems,
but rather you will end up with a potentially more insecure system,
and one that contains known bugs. Reliance on an "enterprise"
distribution to provide this for your systems is up to you, discuss
it with them as to how they achieve this result as this is what you
are paying for. If you aren't paying for it, just use Debian, they
know what they are doing and track the stable kernels and have a
larger installed base than any other Linux distro. For embedded,
use Yocto, they track the stable releases, or keep your own
buildroot-based system up to date with the new releases.

- Test all stable/LTS releases on your workload and hardware before
putting the kernel into "production" as everyone runs a different %
of the kernel source code from everyone else (servers run about
1.5mil lines of code, embedded runs about 3.5mil lines of code, your
mileage will vary). If you can't test releases before moving them
into production, you might want to solve that problem first.

- A fix for a known bug is better than the potential of a fix causing a
future problem as future problems, when found, will be fixed then.

I think I need to give another talk about this issue to go into the above in more detail. So much for me giving a technical talk at Kernel Recipes this year...

PSA: don't get COVID. It sucks.