@gregkh Not that odd... I imagine random dudes talking:
- I used microslop to find bug in Linux kernel and I will have CVE/security vulnerability credits for my CV!
- oh, amazing, was it difficult?
- I just found them easily in usbip, it looks like easy pick.
- I will do the same!

I, for example, noticed that when Google Summer of Code starts, e.g. application process, there is increased amount of contributions doing the same as GSoC applicants but not being part of GSoC. It's like someone found GSoC page with "easy picks" and then hops on the same bus.

Maybe usbip is the same here.

I thought linux.dev was more so for enthuasists and kernel.org for maintainers?

@ljs @axboe @monsieuricon Ah, true, maintainer/reviewer OR “ongoing history with Linux kernel development”: https://korg.docs.kernel.org/linuxdev.html

kernel.org is for maintainers handling code, but there are many people listed in MAINTAINERS which do not handle the code but have M: status, mostly for individual drivers.

@ljs @axboe @monsieuricon But regardless, Josh Law is not a maintainer and should not be such for longer time, considering amount of lies he produced and kept insisting on, even when proven these were lies.

@linux.dev is for maintainers, right? So that's the answer.

To submit patches via SMTP and receive email to a sane IMAP client he can as well use Gmail account - works well and is free. Many people do it, so that's also not a reason to get @linux.dev.

He was told to slow down and learn, but I only see actions still in pursue of some maintainership or other involvement beyond learning. Asking for @linux.dev also feels like asking to legitimize identity or at least get some boost in reputation.

You boost reputation by not sending microslop, not by getting @linux.dev.

@ljs @axboe @monsieuricon There were some more interactions with few more people off-list. Let me forward them.

@airlied @corbet @ljs @monsieuricon Jia Tan also was presenting good faith at some point. Or could come later and say "wait, no, I am a real person, not paid by foo-bar intelligence".
Once trust is lost that person is real, it is difficult to judge whether further statements show good faith or are just trying to salvage whatever operation was there.
And I do understand that this is lose-lose situation, if we stop trusting in general just because one used AI for entire patch and then kept lying about it.

@ljs Yes, except that one about wrapping I am not going to continue the dialogue. When people ask someone 20 times to wrap email and someone still does not do it, probably that person enjoys annoying the community and just sits with the popcorn watching emails...

@ljs Question is whether we should start reverting all their commits (~40), because of non-trusted DCO certificate.

Continuing PyTorch / Linux Foundation database of harvested emails and sending advertisements to them - https://social.kernel.org/notice/B3bhz39OUEdNndylVI

Linux Foundation apologized for "internal marketing operations error" and that "Your email address, along with those of other kernel maintainers, was included in a dataset from a third-party data provider that was improperly imported into our marketing systems without consent verification."

No name for 3rd party provider was given, so GDPR cannot follow to that provider, though...

Linux Foundation also stated they were executing a "permanent deletion". That was 5th of March.

However today I got message from other kernel maintainer, who just got spam/advertisement from the PyTorch Foundation. So saga keeps going.

Maybe they removed only my address from the harvested list. :)

@manut In case you did not find it so far, this might be useful:
https://github.com/guillemj/debian-pkg-neard
https://github.com/sameo/neard-deb.git
And the last packaging for Ubuntu: https://launchpad.net/ubuntu/+source/neard

@manut Awesome, thanks!

New release: neard v0.20, the user-space counterpart of Linux NFC stack

The release includes a few minor fixes.

Source code release:
https://web.git.kernel.org/pub/scm/network/nfc/neard.git/tag/?h=v0.20
https://web.git.kernel.org/pub/scm/network/nfc/neard.git/snapshot/neard-0.20.tar.gz

I should have released it much earlier, though. I think this release thanks to Mark Greer finally dumps Python 2 dependency - last blocker of packaging for Debian. Anyone would like to revive the Debian package?

@cynicalsecurity @tobhe OK, thanks for confirming.

@cynicalsecurity @tobhe If I correctly see in OpenBSD ports, around November DTS was moved from v6.15 to v6.17. In the kernel that was quite an update and T14s got proper USB description (retimers), DisplayPort support and few more less impactful changes. X1E SoC got SCMI cpufreq and several PCI improvements, but nothing stands out as something having ABI impact, so maybe we did not break there anything...

@cynicalsecurity @tobhe If you can replace the DTBs from booted USB stick, then please try older versions, e.g. v6.16. If that confirms that DTS/DTB is the problem, then bisecting would be useful. The sources are taken from:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/snapshot/ and currently at v6.17 in OpenBSD Makefile.

@kernellogger Did he just propose PGP/GnuPG web-of-trust? Isn't this like a 30 year old thing?

Updated guideline: https://social.kernel.org/notice/B4DukxPLisztLVWuEi

Since a year we got some contributions for converting Devicetree bindings from TXT to DT schema as part of some sort mentorship programs (e.g. GSoC). This is great although leads to some misunderstandings in that work, considering mentorships did not ask DT maintainers about some sort of guidance. To clarify:

1. Please convert bindings which have active DTS users. First choose bindings with DTS built by arm64 defconfig, then next choice by arm multi_v7 defconfig. Then any other ARM or different architecture DTS.

2. Be sure dt_binding_check (including yamllint) and checkpatch pass without any warnings. See writing-schema.rst document.

3. Be sure that all DTS files using this binding pass dtbs_check validation. If this means binding needs to be adapted during conversion, mention briefly in commit message changes done comparing to pure TXT->DT schema conversion. Sometimes DTS has to be fixed. Sometimes both - DTS and binding - must be changed, because actual ABI (Linux drivers) is different.

4. Do not send conversions of TXT bindings in staging, because these need to follow standard review process. Bindings in staging are not considered accepted/reviewed DT ABI.

5. Don't ever send output of LLM microslop tools. It's pointless and brings no benefits to the community. Rob already converted all TXT bindings with LLM, so why you doing this again would be beneficial to anyone?

6. Read also Rob's expectations and hints:
https://lore.kernel.org/linux-devicetree/CAL_JsqJp133hGSkja9tabtsE9D7MSA9JErVkmkcy91piHMgfwg@mail.gmail.com/

This is an updated guideline from 2025 https://social.kernel.org/notice/Ai9hYRUKo8suzX3zNY .

I think the graph is not the best representing the phenomena. Probably accuracy = 1.0 is possible only when amount of properties = 0, because even with one property there is a chance employee won't bother enough to input it right knowing how terrible tool JIRA is. IOW, filling even one property to a task in JIRA is such a terrible experience, that people likely will put random data just to shorten the exposure to this horrible interface.

The accuracy of information added to Jira tasks by employees is inversely proportional to amount of detailed information being asked by managers to put there. So called overeager manager law, aka krzk's principle.

@lwn I love the timeline of initial disclosure to Cline:
https://adnanthekhan.com/posts/clinejection/#timeline

"January 1st, 2026: GHSA submitted via private vulnerability reporting on github.com/cline/cline. Same day, email sent to security@cline.bot ..."

January 8th, 2026: Follow-up email sent ... No response received to my email.

January 18th, 2026: Attempted direct message to Cline’s CEO on X with request to review the GHSA containing technical details. No response.

February 7th, 2026: Final attempt — new email to security@cline.bot, no response...

February 9th, 2026: Public disclosure via blog post."

Can we agree that Cline screwed so badly they should never be trusted again as software vendor? Ah, who am I kiddin, that's probably SW workflows managed by AI, so no one cares...