Hmm, seems[1] people submitting #Linux#kernel pull request in #github for torvalds/linux[2] do not get a helpful "you are wrong here" message[3] from the KernelPRBot any more.
Does anyone know if the service/the bot was abandoned? Or is it just broken?
[Edit] should be working again, see replies! [/Edit]
The Linux kernel include/linux/math.h header has macros
roundup(x, y)
and
round_up(x, y)
What do you think they do? Would you know the difference between the two without looking it up? What happens if you mix them up? How significant is the single underscore there?
Wait, what? Building #Linux now (e.g. since [1], which is in 6.10-rc1) requires #python[2]? At least when building the msm graphics driver? Uhh, interesting. 🧐
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
…if there is still enough time for PREEMPT_RT to make it into the next longterm #kernel: might be possible, but then everything has to be ready mid or late September for 6.12, as that will be the next LTS #Linux.
'"[…] I introduced that "no regressions" rule something like two decades ago, because people need to be able to update their kernel without fear of something they relied on suddenly stopping to work. […]"'
Follow the link for context and other statements that did not fit into a toot.
2/ Also note that Linus' message[1] indirectly explains why you might not be able to claim "no regressions" when you only find a problem after updating from one longterm aka LTS #Linux#kernel series to a later one:
By then others might have started relying on the new behaviour, hence fixing the regression might be impossible without causing a regression for those other people – and then you might lose out.
Documentation/process/stable-kernel-rules.rst[1] now mentions how to tag commits you do not want to see backported to stable/longterm series without an explicit request.[2]
Ohh, and it now mentions the difference between stable@kernel.org and stable@vger.kernel.org, too.[3]
@mntmn Thanks! I was thinking if porting #FreeBSD to #MNTPocketReform could be a nice project to learn more about the #ARM architecture (and #kernel programming in general).
"'[…] This seems to be a regular-sized release, maybe even slightly on the smaller side. All the stats look fairly normal […]
We don't have any new filesystems, and the xfs online repair work means that the bcachefs fixes aren't even the biggest filesystem change any more. But all of that is dwarfed by all the usual driver updates […]
“Building Bridges, Not Barriers: Embracing Upstream Support for Lasting Results“ (https://www.youtube.com/watch?v=zwyE44A9-8E) is an inspiring presentation from Texas Instruments. And it is spot on, here’s a picture of my TI OMAP3 IGEPv2 board (released in 2009) running the latest Linux mainline kernel.
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 https://github.com/tio/tio which was developed exactly with that use case in mind and I couldn't be happier. Such an amazing tool.
"'[…] #git was created as a tool to unblock future #Linux#kernel releases — not intended as a global reinvention of all source code management; Linus’s comments highlight that he explicitly saw source code management as the domain of other tools that would then interface with git. […]'"