Linus Torvalds On Dogfooding The Linux Kernel

[phoronix]

Phoronix: Linus Torvalds On Dogfooding The Linux Kernel

Besides Linus Torvalds examining various elements of code he's merging and build testing it on his AMD Ryzen Threadripper workstation and now also testing more on ARM64 with Ampere Altra, he does these days still believe in "dogfooding" and is in fact running the leading-edge Linux kernel code even during the merge window...

https://www.phoronix.com/news/Linus-Torvalds-Linux-Dogfooding

[NotMine999]

A Linux kernel maintainer that does not run their own code, i.e. "dogfooding", should make you wonder ... and wonder A LOT.

As much as some like to bash (or csh or tcsh, if you prefer) Linus for whatever microaggression he committed in email, I have to respect him a bit more for being willing to "dogfood" his own project, and on the cutting edge at that.

[curfew]

Maybe it should be encouraged as a policy of some sort... For about a month now I've been suffering of a regression that last occurred maybe a couple years ago. Sometimes changing virtual desktops through a keyboard shortcut causes the keys to become "stuck" which leads to accidental input in the window that has got focus at the time. I'm blaming the kernel because I did check dmesg or something way back when and it reported some kernel level error occurring.

[varikonniemi]

A Linux kernel maintainer that does not run their own code, i.e. "dogfooding", should make you wonder ... and wonder A LOT.

As much as some like to bash (or csh or tcsh, if you prefer) Linus for whatever microaggression he committed in email, I have to respect him a bit more for being willing to "dogfood" his own project, and on the cutting edge at that.

You must realize his development machine is not his personal/main machine like it is for many. So even if the worst happened, he could reinstall quite effortlessly.

If your machine is more than a development box you are not supposed to dogfood, especially not the kernel.

[Mathias]

A Linux kernel maintainer that does not run their own code, i.e. "dogfooding", should make you wonder ... and wonder A LOT.

As much as some like to bash (or csh or tcsh, if you prefer) Linus for whatever microaggression he committed in email, I have to respect him a bit more for being willing to "dogfood" his own project, and on the cutting edge at that.

I wouldn't dogfood my new Filesystem on my data-system for quite some time. But if the worst thing that can happen is "system crashes, unsaved work is corrupted" then sure. But I don't think every kernel dev should run the linus-tree during Merge on production systems. If you write server hardware drivers, why should you risk instabilities on your Laptop?

[sobkas]

I have learned hard way this:

https://bugzilla.kernel.org/show_bug.cgi?id=101061

[dlq84]

You must realize his development machine is not his personal/main machine like it is for many. So even if the worst happened, he could reinstall quite effortlessly.

If your machine is more than a development box you are not supposed to dogfood, especially not the kernel.

Booting a live usb and reverting to yesterday's build isn't hard either... Or better yet, have a another kernel in the bootloader list ready to use.

[Mathias]

Booting a live usb and reverting to yesterday's build isn't hard either... Or better yet, have a another kernel in the bootloader list ready to use.

Fedora conveniently keeps around the last 3 kernel versions automatically. If one fails to boot, it auto-stops in grub next time and you can select an older version. I'm sure this is easy to configure on other distros as well. I only recently learned this is not normal on (most?) other distros.

[varikonniemi]

Booting a live usb and reverting to yesterday's build isn't hard either... Or better yet, have a another kernel in the bootloader list ready to use.

Do you realize that a kernel bug could corrupt all filesystems you have modify access to? Only by having ANOTHER system you connect to to make your backups can you ensure they stay uncorrupted. And even in that case you need to use incremental backups without modify permission to ensure your bugged kernel does not command the remote machine to corrupt old backups.

[schmidtbag]

I would say shame on him if he wasn't dogfooding. What's the point of being the primary maintainer of something if you don't experience what your to-be userbase is going to experience? How else is he realistically supposed to identify unexpected problems with code, or at the very least, properly investigate bug reports in a timely manner? It shocks me Arlie would even hint at this being a problem.

Every time a product has a significant issue that customers face within days or even hours of use, that's what happens when the engineers/developers aren't dogfooding. The final product isn't the same thing as a heavily-tweaked beta. Experimenting in an isolated or controlled environment isn't the same thing as working in the real world. This is why medicine is slowed to a crawl - it's considered inhumane to just throw new compounds at people and observe the side effects, and animals such as mice aren't biologically similar enough to suggest humans will be affected the same way.

If we look at this in the perspective of principle: commits ultimately come down to Linus' discretion, so surely, he is obligated to make sure what he lets through works as intended, right? I would find it rather unjust for him to insult and reject a developer's sloppy but stable code while letting through something that could potentially compromise the stability of future systems.