Hey there, I have switched to #NixOS recently. I was on #Fedora Kinoite before, which is an "atomic desktop" and was too restrictive to do random standard things.
I try to get my system more stable and less crashy, so I use the linux-longterm #kernel (which did not want to work on Kinoite). This works amazingly well on NixOS.
I haven't understood the language at all, but if you tell me what you need to can see if I can help you write your config.
The #Linux #kernel's #PGP Web of Trust
blog.kleine-koenig.org/ukl/the… (by @ukleinek )
"[…] However there is a problem on the horizon: GnuPG 2.4.x started to reject third-party key signatures using the SHA-1 hash algorithm. […] This doesn't directly affect the kernel-pgpkeys repo, […] When Konstantin imported the updated certificate GnuPG's "cleaning" was applied which dropped all SHA-1 signatures. So Theodore Ts'o's key lost 168 signatures, among them one by Linus Torvalds on his primary UID. […] That made me wonder what would be the effect on the web of trust if all SHA-1 signatures were dropped. Here are the facts: […]"
I wrote a book on Linux Memory Management, published by @nostarch - it's a comprehensive 1300 page exploration of Linux 6.0's memory management code, depth-first, diving into the code and REALLY explaining how things work.
The idea is to avoid hand waving as much as possible and literally explore what the kernel _actually_ does.
It's full of diagrams and careful explanations of logic including a ton of stuff you just can't find anywhere else.
It's currently available in its entirety in draft form via early access when you pre-order.
It's available at nostarch.com/linux-memory-mana…
:)
This exhaustive guide to the Linux memory subsystem is the first major resource since 2004 to cover key concepts and essential techniques for developers.nostarch.com
The #ntsync "driver" to handle Windows locking types enabling #Wine to work much better on many workloads (i.e. games) was merged as part of the main Char/Misc/IIO driver updates for #Linux 6.14:
git.kernel.org/torvalds/c/1384…
'"The driver framework was in 6.13, but now it's enabled and fully working properly. Should make many #SteamOS users happy."'
In case you wonder what was changed to fix the last remaining problems, see lore.kernel.org/all/2024121319…
6/ To follow up once more:
@tuxedocomputers relicensed all full inhouse code in their driver package to GPLv2+ : gitlab.com/tuxedocomputers/dev… 👍
They are working on doing the same for the remaining drivers.
They also submitted a updated version of the patchset making the #Linux #Kernel's module loader treat some of the modules as proprietary; the list of modules handled that way is much shorter now:
lore.kernel.org/all/2024111513…
CC: @waldi
6/ To follow up:
There are now patches under discussion upstream to '"teach the [#Linux #Kernel's] module loader that these modules [from @tuxedocomputers ] are proprietary despite their declaration to be GPLv2 compatible "until the legal stuff is sorted out". "'
lore.kernel.org/all/2024111410…
CC: @waldi #LinuxKernel
5/ TWIMC and for the record:
Werner Sembach from @tuxedocomputers *reverted* Uwe's changes that made the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro "until the legal stuff is sorted out":
gitlab.com/tuxedocomputers/dev…
Wondering why that happened – did they only notice now that the drivers do not compile any more because they use GPL-onlyed symbols, which are inaccessible for any non-GPLv2-compatible module?
CC: @waldi
This reverts commit 9db67459510f18084694c597ff1ea57ef1842f4e. Revert for the time being until the legal stuff is sorted out.GitLab
4/ TWIMC and for the record:
Werner Sembach from @tuxedocomputers now merged Uwe's proposed changes that make the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro. 👏
gitlab.com/tuxedocomputers/dev…
(side note: I suspect the kernel will now taint itself as "proprietary" when loading these drivers, but haven't tried)
CC: @waldi
According to https://docs.kernel.org/process/license-rules.html#id1 "GPL" as parameter to MODULE_LICENSE() means "Module is licensed under GPL version 2". This is not true for this source...GitLab
3/ It got even stranger: it seems @tuxedocomputers provided the wrong license to the #LinuxKernel's MODULE_LICENSE()[1] macro either by accident or on purpose. 🧐
@waldi pointed that out earlier today elsewhere in this thread; PWM maintainer Uwe Kleine-König a little later submitted a bug report asking this to be fixed:
gitlab.com/tuxedocomputers/dev…
[1] they proclaim it's GPL, which according to the #Linux #kernel's docs means "GPLv2" (either -only or -or-later), when in fact the code is GPLv3
According to https://docs.kernel.org/process/license-rules.html#id1 "GPL" as parameter to MODULE_LICENSE() means "Module is licensed under GPL version 2". This is not true for this source...GitLab
TIL: @tuxedocomputers released #Linux #kernel drivers for their machines under the #GPLv3, which makes it impossible for competitors and distros to ship them pre-compiled, as that license is incompatible with the #LinuxKernel's #GPLv2 only license.
They did this purposely, allegedly to "keep control of the upstream pacing" – and want to re-license the code while upstreaming.
github.com/tuxedocomputers/tux…
gitlab.com/tuxedocomputers/dev…
gitlab.com/tuxedocomputers/dev…
gitlab.com/tuxedocomputers/dev…
I was looking into this project's kernel modules to figure out packaging it, and I discovered that this project's license is not compatible with the Linux kernel's own license, thus the combination...GitHub
Linus Torvalds: Rust will go into Linux 6.1
At the Kernel Maintainers Summit, the question wasn't, "Would Rust make it into Linux?" Instead, it was, "What to do about its compilers?"
The Rust in Linux debate is over. The implementation has begun. In an email conversation, Linux's creator @torvalds told, "Unless something odd happens, it [Rust] will make it into 6.1."
🐧 zdnet.com/article/linus-torval…
#linux #rust #linustorvalds #rustlang #it #code #opensource #kernel #linuxkernel
#Linux #kernel patches to allow enabling #PREEMPT_RT (aka proper #realtime support) for x86, ARM64, and Risc-V were posted for review:
lore.kernel.org/lkml/202409061…
"The printk bits required for PREEMPT_RT are sitting in linux-next. This was the last known roadblock for PREEMPT_RT. The RT queue has additionally the "atomic console" for the 8250 UART which is not yet in linux-next.[…]"
See also these earlier other related toots:
fosstodon.org/@kernellogger/11…
fosstodon.org/@kernellogger/11…
I'd really like to read a well researched article that sums up how Linux distros reacted to the massive influx of #Linux #kernel CVE that started ~half a year – both for their #LinuxKernel packages and their live-patching offerings.
But I guess that is an enormous amount of work that no media outlet in this world is willing to pay anyone for writing. 😕
Slide taken from @gregkh's "Why are there so many kernel CVEs?" talk he gave at OSS China yesterday (social.kernel.org/objects/c997… ) #LinuxKernel
Here's a link to the slides for my "Why are there so many kernel CVEs?" talk I gave at OSS China yesterday: https://kccncossaidevchn2024.sched.com/event/ed2b39a9a0cdfc1df18de67ce0c2f6be Link to gi...social.kernel.org
Since I've migrated from screen to tmux years ago, I always felt that missed screen's excellent support for serial devices.
But recently I found github.com/tio/tio which was developed exactly with that use case in mind and I couldn't be happier. Such an amazing tool.
A serial device I/O tool. Contribute to tio/tio development by creating an account on GitHub.GitHub
"Many recent Intel laptops have […] a raw MIPI camera-sensor connected to the IPU6 found in recent Intel laptop chips.
[…] #Linux support for the IPU6 relies on an out of tree #kernel driver with a proprietary userspace stack […]
[…] Linaro has started a project to […] allow these cameras to work without needing proprietary software and Red Hat has joined Linaro in working on this. […]
This work is at a point now where it is ready for wider testing. […]"
The #ext4 data corruption issue[1] in #Linux #kernel v6.1.64 and v6.1.65 that was fixed with #LinuxKernel 6.1.66[2] apparently hit #Debian 12.3 bookworm point release[3]. Fixes are in the works, but preparing them will take a bit[4].
[1] lore.kernel.org/stable/2023120…
[2] git.kernel.org/pub/scm/linux/k…
[3] bugs.debian.org/cgi-bin/bugrep…
[4] fulda.social/@Ganneff/11155162…
