On the radar: a native OpenWrt system built right from the outset; I want one.

https://lwn.net/ml/openwrt-devel/a8aaa495-da0b-4ddc-8c4f-3e1192d8b012@phrozen.org/

On the radar: debGPT — a large language model designed to help with Debian development.

https://lwn.net/ml/debian-devel/8e684936c9b419c8e5072b6543ee3b2e700ede40.camel@debian.org/

On the radar: the 2023 year in review page (https://discussion.fedoraproject.org/t/2023-the-year-in-review/100689) on the Fedora discussion site ranks participants by the amount of time they spent reading on the site. Something there is tracking your behavior...does Fedora really need to do that?

Just checked my mail and found something straight out of McMansion Hell. This delightful little place will only cost you $12 million — and you get to live in Commerce City, which is even less of a garden spot than it sounds.

(Lest you wonder, I never asked to receive this rag; they figure that if you can manage to live in Boulder, you must be part of the market for this kind of atrocity so you get it whether you want it or not.)

I had this feeling I was being watched on my ride this morning...

"Just store your data in the cloud" they said, "what could go wrong?"

https://arstechnica.com/information-technology/2023/12/dropbox-spooks-users-by-sending-data-to-openai-for-ai-search-features/

If you think you got spam from me — it wasn't me, honest!

It would appear that the folks at belleclair.co.jp are running an open email relay (or have been compromised entirely). Some bright individual has been using it to send out massive volumes of spam and, for reasons known only to them, chose to put my return address on it. That has resulted in just short of 40,000 bounce messages landing in my inbox.

As a way to start your day, that just isn't as fun as it sounds.

A single notmuch command made the bounces go away; a couple of lines in header_checks has, so far, prevented the arrival of about 1,000 more. But spam with my email address on it, it seems, continues to flood the net.

Time to get serious about that DMARC setup in the hope that it might help, I guess. Email is so much fun.

Ah...Sharper Image...where would we be without you...? The "precision of a chainsaw" indeed.

On the radar: !CVE

An alternate list of (alleged) vulnerability numbers for problems that the designated CNA refuses to issue a CVE for.

https://lwn.net/ml/oss-security/c01c1617-641d-4ec2-847f-2e85ea4676f7@notcve.org/

Perhaps this is an effort to identify vulnerabilities that, for whatever reason, the Powers That Be won't recognize. It also looks like a way to circumvent efforts to combat the growing bogus-CVE problem, though.

Aww...they deleted my old videobuf document:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a2fffb488a3c

I'd actually forgotten that I wrote that thing at all, evidently I did it back in 2010...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4b586a38b04

Hopefully it was useful while it lasted.

On the radar: what is the linux-kernel mailing list for? @monsieuricon is suggesting that many or most patch postings be redirected to a separate list:

https://lwn.net/ml/ksummit-discuss/20231106-venomous-raccoon-of-wealth-acc57c@nitro/

I've not jumped into the conversation because I'm still trying to figure out what I think about it. I'm one of those people who actually reads over that list; the broad view it provides is helpful in both the LWN and documentation-maintainer roles. But it *is* painful to keep up with.

LKML has traditionally been the place you post patches to get them reviewed. If that's not its role anymore, what is it for?

LWN is trying to hire a full-time writer/editor:

https://lwn.net/Articles/949461/

Please talk to us if you think you might be interested, and pass on a pointer to anybody else who might be a good fit.

On the radar: who gets on the linux-distros mailing list?

linux-distros is where vulnerabilities and fixes are discussed prior to public disclosure. Given the nature of the material discussed, it is unsurprising that membership is limited. I seriously doubt they would let me on it...

CIQ (Rocky Linux) would like to join:

https://lwn.net/ml/oss-security/20231001130223.GA6586@openwall.com/

There has been some opposition to this membership, seemingly based on the ideas that (1) Rocky Linux isn't doing much of the way of original distribution work, and (2) as a (relatively) community-oriented project, it lacks a way to keep secrets. This view is not universally held, though.

Meanwhile, openEuler also wants in:

https://lwn.net/ml/oss-security/ZSyUUSF_-3YbT14k@workstation/

The concern here is potential legal issues related to openEuler's Chinese origins.

Cool...there's now a archive of all the Whole Earth Catalogs and the various magazines that descended from it:

https://wholeearth.info/

I'm currently dealing with a contractor to replace the gas furnace with a heat pump and actually use all that power that the rooftop panels are generating rather than burning gas. So far so good.

Today I got an email from a third-party site I'd never heard of with an invoice. To actually pay the invoice, the thing demands my login credentials for access to my bank account.

The contractor seemed surprised that I proved unwilling to do that. I guess I understand why phishing is such a lucrative exercise.

On the radar: the ongoing, slow-burning discussion over the sched_ext scheduling class (which allows the writing of complete CPU schedulers in BPF: https://lwn.net/Articles/922405/). This thread has been ongoing since July:

https://lwn.net/ml/linux-kernel/20230726091752.GA3802077@hirez.programming.kicks-ass.net/

with a new message showing up every few weeks. Regardless of how one feels about sched_ext, it is clear that quite a bit of thought has gone into the problem on both sides of the debate.

On the radar: improved tunable handling for glibc. The recent vulnerability has drawn their attention to this aspect of library behavior, and now they are trying to make some changes to prevent the next vulnerability before it happens (or at least before somebody finds it)

https://lwn.net/ml/libc-alpha/20231010180111.561793-1-adhemerval.zanella@linaro.org

So they made a movie about my dad ...

https://fullcirclefilm.co/

...and about a crazy kid named Trevor Kennison and how both recovered their lives after a devastating injury. I've seen it, it's definitely worth a watch. The site lists a lot of upcoming screenings (all just in North America, alas).

So OSS Europe was an interesting experience, this year, in a way.

I did my usual talk, and started with the usual section on kernel releases. When talking about stable updates I tossed in a quick mention that six-year support from the stable team was being phased out — something I understood to be generally known for about the last year. Way at the end of the talk, as my last topic, I discussed at some length the stresses being felt by kernel maintainers.

@sjvn wrote an article about the talk (https://www.zdnet.com/article/long-term-support-for-linux-kernel-to-be-cut-as-maintainence-remains-under-strain/) and made a connection between the stable-policy change and the maintainer issue — something I had not done in the talk. It was a bit of a shift from what I said, but not a bad article overall.

Then the rest of the net filled up with other writers putting up articles that were clearly just cribbed from SJVN's piece — sometimes with credit, sometimes without. I'm getting emails about what a terrible idea this all is, as if I had anything to do with that decision or can somehow change it. I have, it seems, taken away everybody's six-year support, and they're not happy about it.

All because of a 30-second mention of a change that was made public something like a year ago. My 1.5 minutes of fame has given me a new appreciation for this old quote from Rusty Russell: "when a respected information source covers something where you have on-the-ground experience, the result is often to make you wonder how much fecal matter you've swallowed in areas outside your own expertise."

On the radar: reconsidering the kernel's preemption models.

It all started in a discussion on optimizing string operations on x86, but that led to finding ways to allow preemption for long-running operations even in non-preempable kernels.

You see, the kernel offers a number of different models for when kernel code itself can be preempted to run something with a higher priority. All the way from PREEMPT_NONE (no preemption at all) through PREEMPT_VOLUNTARY (preemption at explicitly marked points) and plain PREEMPT (anytime not in a critical section) through to PREEMPT_RT for realtime. Linus was getting grumpy about the scattering of voluntary preemption points, and eventually came around to the idea of maybe dropping PREEMPT_NONE and PREEMPT_VOLUNTARY altogether:

https://lwn.net/ml/linux-kernel/CAHk-=whpYjm_AizQij6XEfTd7xvGjrVCx5gzHcHm=2Xijt+Kyg@mail.gmail.com/

I doubt that's going to happen, but we may see a reduction of options in favor of PREEMPT_DYNAMIC, which allows choosing between voluntary and full preemption at boot time.