'" The data shows that “frozen” vendor #Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux #kernel created by Greg Kroah-Hartman. '"
Annoyed by having to put #sudo in front on #dmesg[1]?
Then use this instead[2]:
$ journalctl -k
It should work if the user executing this is a member of the groups "systemd-journal", "adm", or "wheel".
[1] which is the case if CONFIG_SECURITY_DMESG_RESTRICT is turned on in your #Linux#kernel's .config – which #Fedora recently switched on, something many other distros did already a while ago.
[2] works for the common case, for some fancier stuff you might still need dmesg #LinuxKernel
As #Linux#kernel community, process, and quality problems are discussed due to critical toots from @marcan a quick reminder:
Many problems currently discussed are well known for years; below screenshot from the slide deck mentioned at the start of https://lwn.net/Articles/799134/ shows that.
Things didn't improve much since then. The main reason for that IMHO is not "resistance to change among the elders" – it's lack of funding for people that work out and establish better workflows. #LinuxKernel
Linus re-sorted the #Linux#kernel's MAINTAINERS file again and had this to say:
The answer is "No. No we cannot".
I suggest that all kernel developers will need weekly training sessions, involving a lot of Big Bird and Sesame Street. And at the yearly maintainer summit, we will all sing the alphabet song together.```
😂
<https://git.kernel.org/torvalds/c/c192ac7357683f78c2e6d6e75adfcc29deb8c4ae> #LinuxKernel
Reminder: the support for programming the [#LinuxKernel using #Rust aka #Rustlang is not used for anything at all yet within the #Linux#kernel – and most likely disabled in this user's kernel image]
[EDIT: better ignore this, the example is obsolete; see 3/]
One of the things I find really annoying about #Linux#kernel development:
Things that are right when contributing to one part of the #LinuxKernel are wrong when contributing to another.
Sometimes even rules that I'd consider to be on a higher level are nullified on lower levels. The netdev-FAQ[1] for example tells contributors to not tag changes for stable backporting as explained in stable-kernel-rules.rst[2].
Andrea Righi[1] wrote a #LinuxKernel scheduler in #Rust / #Rustlang using sched-ext[2]; he claims he was "'"pretty shocked to see that it doesn't just work, but it can even outperform the default #Linux scheduler (EEVDF) with certain workloads (i.e., gaming):"'"
Hmmm, immutable #Linux distros are currently ignored by the "How to quickly build a trimmed #LinuxKernel" text I recently added to the #kernel's documentation[1].
Is that fine for now? Or should I add a sentence or two about those?
For @fedora#silverblue at al. it seems using "ostree admin unlock --hotfix" might be the best solution when say doing a bisection.
A #Canonical employee reported some out-of-tree code broke after something internal was renamed recently in #Linux 5.15.y – and as expected was told this is no regression at all, as the #LinuxKernel does not have a binary kernel interface, nor does it have a stable kernel interface:
Christoph Hellwig in a reply also wrote: "given that Canonical ignores our #kernel licensing rules and tries to get away with it I'm not going to offer any help to Canonical at all."
Would be even better if a few people could play this through – but I guess chances are slim anyone seeing this currently has a need for that. #LinuxKernel
Can someone explain to me, how a scheduler should decide which process to run on which core, with such an architecture?
There are 4 different CPU designs inside this system on a chip. I observe that this issue is already troublesome for just 2 different CPU types. #scheduling#linuxkernel
Getting closer and closer to the point where I'll start a git tree[1] with fixes and reverts for #Linux#kernel regressions in the latest stable series, as from here it seems quite a few of the known problems could quickly be solved by a revert or applying fixes already queued[2]/still under review[3].
Sooner or later the #Linux#kernel afaics will need a group of "first level bug responders" to reduce workload and noise for #LinuxKernel maintainers and developers.
E.g. a group of people that triages incoming bug reports[1] and normally only lets those through to the real developers that meet some very basic requirements.
[1] point to dupes, check if the report is sane, check if all basic information is there, ...
#argh: I have to perform a #Linux#kernel bisection on my Thinkpad T14s G1 (AMD) with Fedora's full-blown distro config, as the problem does not occur with a config trimmed by localmodconfig. 😟
Reminder: a #kernel where uname -r prints something like "5.15.0-71-generic" is a vendor kernel that is likely quite different from #Linux 5.15.71[1].
In case of problems with such a kernel you thus must report them to your vendor.
That's because almost all upstream #LinuxKernel developers don't care about problems in such kernels, as they might happen due to modifications the vendor applied.
[1] it in fact is likely based on a much later Linux 5.15.y release
Linus (@torvalds ) helped my fight against #Linux#kernel regressions a lot today by clarifying:
he is perfectly willing to pick-up non-controversial patches directly from the list to ensure they make it into the next release [even when one is immanent].
to avoid having a regression in yet another release, it's totally fine for him to merge fixes for regressions from recent releases on the last minute
Screenshot shows what #Debian removes from the #Linux#kernel src to comply with the DFSG.
This is why:
"""[…] The IETF draft for CIPSO is under a non-free license. The nvidia and riva drivers contain obfuscated source code. The other files contain executable code as static data, without any source for it. […]""" (https://groups.google.com/g/linux.debian.kernel/c/Pqw8klO72FE)
"'"What follows is a letter from Hans Reiser to myself, which he wrote some two months back, and has asked me to publish, with his thoughts on the deprecation of ReiserFS from the #Linux#kernel. I have transcribed it to the best of my ability. Plaintext email may not be the best way to read it, as such, I have […]"'"