'" 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
I think the #Linux#kernel's praised "no regression" rule it massively subverted by one aspect:
Developers that caused a regression in a mainline release (say today's 6.4) are only obliged to fix it in mainline (e.g. for the next release, 6.5 currently).
There is nothing that ensures the fix will be backported to affected stable (e.g. 6.4.y) kernels (ideally quickly, unless the fix is risky).
"[…] It is clear that the current process is based on the learnings, and frustrations, the [#Linux#kernel's CVE] team has faced in the past. […] By taking this position, this effort is now duplicated across thousands of engineering teams ad infinitum, […]"
Well, yeah, but guess what: maybe then the companies behind those engineering teams will join up and invest money to handle the problem "[…] at the source, in a central, efficient and reliable manner. […]". 😬
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
The #CVE count of the #Linux#kernel is not looking good these days compared to any other #OS is it. Maybe time to switch to #FreeBSD or some other system which doesn't claim to find hundreds of significant vulnerabilities every day
I know why Canonical/Ubuntu is doing it like that, but it nevertheless every time feels kinda odd when they switch to a #Linux#kernel series that upstream gave up and tagged "end of life" two-and-a-half months ago already[1] – something the article doesn't even mention.
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]
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):"'"
nvidia choose to not support the wayland stack. or well more generally, the new linux kms+egl gpu stack, since there's a lot other cool things you can built on top of it that aren't wayland
nvidia choose to implement crypto locked down fw in a way that blocks open drivers (even apple got this right!). and no one else can fix it, because it's actual real crypto
[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].
The idea of some kind of microkernel project aimed at the #bsd world has been floating around between me and some of my lab colleagues for some time now.
I think the overall rationale has coalesced enough to warrant talking about it. I will probably aim to produce some kind of vision whitepaper on this, once I get clear of some personal stuff.
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
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].