I'ld suggest to:
1. Upgrade to #Debian 13 #trixie. Should be almost stable. Release date will be 2025-08-09.
2. Then install the #Linux #kernel from Debian #experimental (6.15.6 right now).
This is supposed to work, TTBOMK.
I'ld suggest to:
1. Upgrade to #Debian 13 #trixie. Should be almost stable. Release date will be 2025-08-09.
2. Then install the #Linux #kernel from Debian #experimental (6.15.6 right now).
This is supposed to work, TTBOMK.
It's looking like #linux #kernel 6.14+ will contain the driver I need for an intel AX201 on a #Debian 12, which doesn't work on my #thinkpad right now (no wifi! agh!).
I'm telling you all that for the context behind this question:
Is it bad/dangerous/unstable to run Debian 12 on kernel 6.14?
Further, should I use the Ubuntu kernel or get the "raw" kernel?
Opinionated posts are welcome and helpful. Please do dump your thoughts at me.
Internet Engineering Task Force @ietf 123 meeting just started w/ #IETFHackathon and we commemorate one & only @mtaht - his life, work & legacy fighting #bufferbloat:
Come and say Hi! if you are with us in Madrid.
Intel quits Clear Linux (their inhouse distro) | Contributing upstream code continues for Linux the kernel
◉Not a tragedy to quit it
◉ ...More resources freed @ Intel to contribute to Linux
◉Intel doesn't really need their own distribution
◉AMD doesn't have an own distro yet contributes upstream to the kernel / other software
◉Slightly sad Intel shut Clear Linux down - but it never really took off (?) in wider sense
https://community.clearlinux.org/t/all-good-things-come-to-an-end-shutting-down-clear-linux-os/10716
The Debian community forums would love to see your bug. Good luck, however you search.
2/ And to quote one bit from @corbet's[1] great #OSSNA25 talk:
""[…] there will be no core development conferences around #Linux and other things in the United States in the foreseeable future. […] this is a real problem […]""
Yes, this is not a formal announcement[2] – but it bears some weight, as Jonathan is well connected and among others sits in the Linux Foundation's Technical Advisory Board (TAB).
[1] https://www.youtube.com/watch?v=hNLBGiwfBSI&t=949s (for context starts a bit earlier; the quoted bit comes about a minute later)
[2] and kinda obvious for some of you
ICYMI: the recording of @corbet's recent #OSSNA25 talk "Three Decades in Kernelland" recently became available:
https://www.youtube.com/watch?v=hNLBGiwfBSI
From the abstract[1]: The #Linux #kernel project has been going for well over 30 years. From its beginnings on floppy diskettes and beige boxes through to its current home in pockets and unseen data centers, the kernel project has been a constant exercise in rapid development and adaptation. I have been present for almost all of the kernel project's history as an observer, contributor, maintainer, and more; all that experience will be boiled down into a fast-moving tour of how the #LinuxKernel got to where it is, what makes it successful, and what may be coming next.
[1] https://ossna2025.sched.com/event/1zfit/three-decades-in-kernelland-jonathan-corbet-lwnnet
Using machine learning to optimize/fine-tune the #Linux #kernel at runtime to the needs of the workload – this is something I guess we'll see way more often in the future.
The recent #ossna25 talk "Improve Load Balancing With Machine Learning Techniques Based on the #sched_ext Framework" from Ching-Chun ("Jim") Huang gives a glimpse into such a future.
@lwn write-up: https://lwn.net/Articles/1027096/
Recording: https://www.youtube.com/watch?v=5VXemIXAOrI
Remember #libobscura ?
The project didn't attract a huge community, but it did teach me stuff so obscure that few people apart from the authors understand it.
So I started writing it down, for everyone's benefit.
If you had questions about #DMABUF, I try to explain it on my #blog :
https://dorotac.eu/posts/DMABUF/
Thanks to all the people who explained it to me. Some parts are really confusing.
(Please report mistakes.)
Obscure kernel bug use-after-free and then the VLAI severity told me "maybe important" before I read the drama https://syst3mfailure.io/rbtree-family-drama/
#kernel #linux #exploitation #vulnerability
https://vulnerability.circl.lu/vuln/CVE-2025-38001#sightings
From the Linux Update newsletter: @linuxnews looks at Linux 6.12 LTS, which makes real-time support an official part of the operating system kernel
https://www.linux-magazine.com/Issues/2025/295/Linux-6.12-LTS?utm_source=mlm
#Linux #kernel #support #LTS #FOSS #extensions #OpenSource
After a clash over some late fixes and disagreements between bcachefs's lead developer and Linus Torvalds, Linux kernel 6.17 may drop bachefs
https://www.linux-magazine.com/Online/News/Linux-Kernel-6.17-Drops-bcachefs?utm_source=mlm
#Linux #kernel #bachefs #patches
2/ Und FWIW zur Info:
* Die oben verlinkte Fixes sind in #Linux Mainline eingeflossen und werden somit Teil von #kernel 6.16-rc6, das Sonntagnacht erscheinen sollte[1].
* Die Fixes werden auch in neue Versionen aller derzeit gepflegten Linux-stable Serien 5.15 und neuer einfließen, die derzeit in ihrer -rc Phase sind und die nächsten Tage erscheinen (etwa 6.12.37 und 6.15.6).
[1] reminder, nutzt statt mainline -rcs ruhig tagesaktuelle git snapshots, die sind genauso gut
""Die #Linux-Community hat bereits reagiert und einen #Kernel-Patch gegen TSA freigegeben, schreibt Phoronix. Dabei wurden die Sicherheitslücken von Microsoft gefunden.""
Was will uns der Autor damit sagen?
Die Sicherheitslücke hat MS natürlich an AMD gemeldet – und das Unternehmen ist bekanntermaßen eine der Größen in der "Linux-Community", daher haben Mitarbeiter von AMD zusammen mit andere Teile der Community im Hintergrund entsprechende Fixes vorbereitet, die Linus Torvalds dann zum Ende des NDA sofort eingepflegt hat.
Und warum eigentlich Phoronix erwähnen, statt auf die Originalquelle zu verlinken[1], wo Interessierte wesentliche Informationen finden?
*shrug* *kopfschüttel*
[1] https://git.kernel.org/torvalds/c/6e9128ff9d8113ef208e5ec82573b96ead100072
Remember #Linux' pktcdvd driver, which allowed direct mounts with UDF of cd-rw drives that required 32kb packets?
That driver is now in now scheduled to be removed with #kernel 6.17, as a patch doing this landed in linux-next today – because that use-case is uncommon these days, as "the world has moved on from those kinds of media. To make matters worse, it's actively breaking setups where it's not even required or useful."
Linux 6.16 RC5 released!
Linux 6.16 RC5 is now live for developers and curious users to try out. All the interesting changes from performance improvements to bug fixes have been integrated to this release candidate.
In the release announcement for this version of the kernel, Linus Torvalds said:
Absolutely nothing in here looks all that odd. The bulk of the changes are to drivers, with all the usual suspects (ie gpu and networking tends to be the most noticeable, but we've got usb, rtc, platform drivers etc too).
And there's various filesystem fixes in here too, with several filesystems having sent updates last week. Not that any of them are particularly large, but there's just several filesystems that all decided to send in their fixes last week: xfs, btrfs, smb and nfs clients, bcachefs and netfs).
Other than that it's the usual random sprinkling of fixes.
Why not try out this awesome pre-release of Linux 6.16?
This weekend I had some time to continue working on Project Merlin, so progress tracking update!:
https://riscoscommunity.org/projects/risc-os-merlin/
New set of #Gentoo #Linux Distribution Kernels (6.1.143, 6.6.96, 6.12.36, 6.15.5) is out. This set brings some major changes:
• I've backported a bunch of changes from sys-kernel/gentoo-kernel to sys-kernel/vanilla-kernel that were missing — notably wider architecture support.
• I've added default #RISCV configs to 6.12 (in addition to 6.15), since Fedora had them.
• All three packages are based off the baseline kernel tarball + upstream patch (vanilla-kernel used to fetch patch-level tarball every time, and gentoo-kernel* used genpatches for patch versions). This should reduce disk space and bandwidth use.
• All three packages now support verify-sig. Rather than verifying the uncompressed tarball signature, we now use upstream `sha256sums.asc` file to verify the compressed tarball and patch.
• sys-kernel/gentoo-kernel* now repackages genpatches. This means patchset that's much leaner and faster to apply (since we just fetch and use the combined upstream patch rather than including point patches). This also means that we are able to release Distribution Kernels before gentoo-sources are done.
The changes still need to be done to 5.15 and 5.10 branches — we're going to do for the next upstream releases of these.