our community have always tried to embrace the upstream-first approach to development, and one of the largest roadblocks in that respect is often the Linux Kernel itself.

For better or worse it takes quite a lot of effort to get devicetree files and drivers upstreamed, but this is by far one of the more important goals for wider Linux Mobile adoption: upstream support makes devices more visible and encourages kernel maintainers to take more of an interest in the work we do

with that in mind, we are proposing an adjustment to the community device category requirements: to get your device into the community category it would now HAVE to have a devicetree in upstream, more specifically the upstream kernel needs to boot with some kind of display output and a working USB port - the bare minimum for easy tinkering, testing, and further development.

We hope that this will encourage device maintainers to get involved in upstream kernel development and submit their work rather than keeping everything in a kernel fork that they maintain

We are very open to feedback on this, please let us know what you think in the GitLab issue

https://gitlab.postmarketos.org/postmarketOS/postmarketos/-/issues/116

#LinuxMobile #postmarketOS #linux #kernel

@darix @ptesarik @larsmb Good news is that it will be trivial to get root on the thing so that you can update the kernel yourself to a more secure one :)

@larsmb Surely nothing has changed in Linux since 2020 :)

nice https://reviews.freebsd.org/differential/changeset/?ref=1420532

Urgent help for OpenPrinting needed!

As many here know, I am co-founder and lead of OpenPrinting since 2001, known as the print guru for Linux and free software by many. I also got one of the 8 fellows of the Linux Foundation for this.

Up to now I was working at Canonical, hired back in 2006 just to run OpenPrinting and also to maintain printing-related Ubuntu packages.

... 🧵

Please boost.

#OpenPrinting #LinuxFoundation #getfedihired

@trini Contact the CNA that created it and get them to reject it, if they don't complain to cve.org.

@larsmb Ah, you seem to have run into a "slopper" https://www.todayintabs.com/p/we-need-to-talk-about-sloppers-b732?_bhlid=cf776e870f09f7dd3876c6b20616bf9a25b260fd

@stsquad @hrw Fixing the lack of almost all riscv soc drivers to be upstream so that I can boot a kernel.org release on one of them (i.e. a normal developer can test their changes) would be a good start. Which is one of the things that article says...

Looks like the risc-v community is learning from history! Hopefully this results in more upstream development efforts: https://riscv.org/blog/2025/07/risc-v-upstreaming/

@jarkko This all happened _WAY_ before ebpf was even a thing...

@vbabka AUTOSEL is there because maintainers and developers do not, or forget to, properly tag "Cc: stable@kernel.org" for their bugfixes.

If they all did that, we would never need to use AUTOSEL at all.

But you know that, stop trying to feed the trolls. It's a beautiful day outside, enjoy it! :)

@jarkko Groups (i.e. big companies) have tried to come up with a standard way for all kernel log messages, as that is what they were used to for their "other" operating systems. They wanted a big book, they could reference, to look up what each message meant and what to do about it if it showed up.

After many "discussions" with the community, I think in the end they got something they could use on the back-end to tokenize the kernel messages from the source, and somehow create unique identifiers they can use in other tools, but I don't remember the specifics. Odds are it's buried in the kbuild system somewhere....

Saving this here to use later. As seen in the comments on yet-another-ai story on Lobsters:

"How could you claim to have a neutral, informed opinion on LLMs without signing up for a bunch of subscriptions and constantly talking to the liar machine to see if it told a truth today?"

One of my fav quotes from this @gregkh interview:

"Open source ends up having better depth of knowledge than closed source has."

(Because for careers in companies you get shifted around while many people in OSS stay in the same field/code for decades.)

https://www.youtube.com/watch?v=-1-OjxPJZcs

Linux Kernel Hardening: Ten Years Deep

Talk by @kees about the relevance of various Linux kernel vulnerability classes and the mitigations that address them.

Video: https://www.youtube.com/watch?v=c_NxzSRG50g
Slides: https://static.sched.com/hosted_files/lssna2025/9f/KSPP%20Ten%20Years%20Deep.pdf

All the slides at this meeting talk about how much time and effort "AI" would help us save, and all I want to do is point out how much time and effort I've sunk so far into keeping AI crawlers from DDoS'ing our infra.

@gregkh linters literally do their job better than a speculation machine

@ptesarik That's what `drivers/staging/` is for, we just took 10+ patches for that subsystem from new submitters yesterday. That's much easier to accomplish than trying to parse the output of an "AI tool" :)

@liw We assign 13 CVEs for Linux every single day. "Fame and fortune" is not something that happens for any of those reports, as a CVE is trivial to get if you actually want to just fix a kernel bug for real.