@adamw @bars @marcan Bug tracking is clearly a place where the kernel project falls down badly, agreed. We finally got regression tracking funded, but that's just barely the beginning of the problem.

For bug tracking, one aspect of the problem is a simple unwillingness on the part of many maintainers to bother with a bug tracker. That does not help at all.

The other part is something I'm going to poke people at the LF shindig about next week. Almost everybody who works on the kernel is paid to do it, but there are many areas that no company thinks it needs to worry about funding. Of the 5,000 developers who work on the kernel each year, not a single one of them is tasked with documentation — my own pet peeve. But (almost) nobody is paid to work on tools, and it hurts us in all kinds of ways, including bug tracking.

@leftpaddotpy @marcan How is a forge for each subsystem ever going to work? This is one program we're dealing with, and an awful lot of work is not contained to a single subsystem.

@marcan @bars One of the worst things about working in the kernel — one of the most toxic parts — is the constant stream of nastiness toward our community that comes from outside.

The kernel community is far from perfect; we have a lot of problems and we have been actively working for years (decades) to improve on them.

We are, nonetheless, a project that manages to incorporate nearly 100,000 commits per year, from over 5,000 developers, into a single code base while maintaining a level of quality that — while also certainly in need of improvement — is good enough for deployment into billions of devices.

As for the use of email...email is painful and broken, but we have found nothing better that will work at the scale we need. See https://lwn.net/Articles/702177/ from a few years back. For all its faults, email is distributed, non-proprietary, scriptable, and gives everybody the freedom to choose their tools; it is a highly inclusive solution in a way that proprietary web forges (for example) are not. Someday we'll find something better and move on with a cry of joy, but that day has not come.

Rather than crapping on the kernel community from afar, why not work with us to try to make things better?

@larsmb @failedLyndonLaRouchite As far as I know, I am one of those people who has never has Covid. I've tried to be careful about it, and it seems to have worked.

I, though, feel that I can only be so confident in any pronouncements that I have never had the disease. I know other people who have been very careful and who have been nailed anyway... that and the prevalence of asymptomatic cases says that there is a reasonable chance that I've hosted that virus at some point.

Saying that I may have had it despite the lack of evidence to that effect doesn't strike me as offensive, it's just an acknowledgement of the uncertainties around this whole thing.

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/

@vbabka The thing is, of course, that giving your credit card info over the phone is a pretty safe thing to do in the US. Having people go nuts with it is an obnoxious event on a par with realizing that your puppy has just made a mess on the floor ... you're going to spend a while cleaning things up, but there will be no lasting consequences. Experience says that cleaning up the mess in Europe is not as easy.

OTOH giving some random business — and everybody they leak data to — complete access to all of your accounts at a given institution, all of the transactions you have made there, your bill-paying setup, and more ... *that* could have consequences.

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.

@kernellogger @wagi Hey, *nothing* I do is really beautiful...:) You're talking about the treeplot utility, which is in the gitdm repo. I last used it, I believe, for 5.18: https://lwn.net/Articles/895800/

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."

@yogthos Linux was doing OK before the companies showed up...I was there, after all. But an awful lot of things didn't work very well, we lacked support for a lot of hardware, and so on. If you're getting >90% of your code from companies, they are clearly adding something.

No, it's not altruism on their part, but does that matter?

Anyway, I was challenging the assertion that free software is a transfer of wealth from volunteers to companies; I don't think you've said anything to change minds on that.

@yogthos This can be argued the other way...the vast majority of Linux kernel development is done by people who are paid, often quite well, for that work. Companies have paid for this and have then given it all away. It could be said to be one of the largest transfers from corporations to a common resource ever.

I'm not entirely fond of how free software has become, to many, a way to shed maintenance costs. There are a lot of problems with how things work. But the situation is not quite as portrayed in this cute little image, IMO.

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.

Well, vger (as of right now) no longer directly attempts to deliver to gmail/google/googlemail just to get the ridiculous backlog out of the primary mail paths. Vger (1 machine) is kicking all of that queue over to 8 other machines and letting them go try to get that delivered and queue up somewhere where it's not going to cause everyone else pain.

This should, at least for now, settle out several things, but if you are seeing mail wonkiness give postmaster@ a ping and I'll take a look.

Also if you are on Gmail and doing kernel dev, might be worth looking at other email providers.

@liw @neil @pwaring Surprisingly, I have a *lot* of sympathy for people trying to earn their living with their writing. It's not an easy path, and you have to pick your poison... whether it's overt paywalls, annoying popups, or surveillance advertising, it's going to be annoying to people.

We've found a solution that works well enough for LWN - at least, well enough to keep us from having to get real jobs - but I'm not sure what the best solution is in a general sense.

On the radar: restricting access to "ALTER SYSTEM" in postgresql

Having mutually untrusting users connecting to the same postgresql server is a tricky proposition from the beginning; it's even moreso if, for some reason, some of those users are postgresql superusers. There is a proposal to chip away one piece of the problem by making it possible to disable the ALTER SYSTEM command, which affects global server parameters:

https://lwn.net/ml/pgsql-hackers/CA+VUV5rEKt2+CdC_KUaPoihMu+i5ChT4WVNTr4CD5-xXZUfuQw@mail.gmail.com/

There is disagreement over whether this is a piece of security theater or a useful option for some providers.

On the radar: advancing the Git SHA-256 work.

Moving Git away from the SHA1 hash has been a long and slow process:

https://lwn.net/Articles/898522/

Much of the basic support to use SHA-256 is there, but a lot of the finishing work is not, so it remains unused. Now Eric Biederman has surfaced with a set of patches to provide interoperability between SHA-1 and SHA-256 repositories:

https://lwn.net/ml/git/87sf7ol0z3.fsf@email.froward.int.ebiederm.org/

Someday, maybe, this transition will actually happen. Maybe.