Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Higgs-Bugson in the Linux Kernel

blog.janestreet.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: A Higgs-Bugson in the Linux Kernel

#41

Post by burnt-resistor »

stavros wrote: post #25
alexpotato wrote: post #23

Regarding NFS, I've always loved this quote from the CTO at a hedge fund I once worked at: "NFS is lot like heroin: at first, it seems amazing. But then it ruins your life" (This is a place that did almost EVERYTHING via NFS including different applications communicating via shared files on NFS mounts. It also had the weird setup of using BOTH Linux AND Windows permissions on NFS mounts shared between user desktops […

The problem I have with reviews like these is that they're expressed in absolute terms. Yes, NFS might ruin my life, but if it ruins my life less than every other alternative, it's still a win.

The devil is in the details, the devil you know is preferable, and there's yet no perfectly angelic systems or code (because of the widespread allergy to formal methods and job security).. which will lead to less evil, but still imperfect systems.

Re: A Higgs-Bugson in the Linux Kernel

#42

Post by burnt-resistor »

vrnvu wrote: post #20

I'd like to highlight this: >NFS with Kerberos secure, simple, battle tested. no crazy architecture works so well a bug showed up in the kernel :-)

The Linux kernel needs to adopt better testing methodologies because they're almost entirely reliant on meatcloud CI than provably-correct code with invariant contracts.

Re: A Higgs-Bugson in the Linux Kernel

#45

Post by burnt-resistor »

snvzz wrote: post #15

With millions of LoCs, it is no surprise there are bugs. Worse yet, the kernel runs in supervisor mode. This kernel design is bankrupt. There's much better available, such as seL4+Genode.

seL4 exhibited great advances in software engineering processes and advances in correctness, zero-copy microkernel IPC performance, and capabilities-based security, but these need explanation, adaptation, and evangelism to real-world use-cases like Linux.

Microkernels have severe limitations when it comes to transactional boundaries of calling multiple subsystems and rolling back on failure.

Linux has too much inertia to reinvent itself instantly or completely into XYZ.

What would add more value would be gradual conversion to Rust and adding formal verification to C and Rust like specifying invariants in comments/metadata like frama-c and/or flux.

PS: Religious judgement opinion wars are rarely constructive.

Re: A Higgs-Bugson in the Linux Kernel

#46

Post by fragmede »

eqvinox wrote: post #26
stavros wrote: post #25

Earlier quoted context omitted.

The problem I have with reviews like these is that they're expressed in absolute terms. Yes, NFS might ruin my life, but if it ruins my life less than every other alternative, it's still a win.

I'd go as far as saying most networked concurrent file access will ruin your life one way or another, because it's just a hard problem , and it's trying to solve it at a very odd layer; a "classic" fs can't really take advantage of higher layer transactional or other known constraints in order to make things work better…

Google Docs solved the problem at the right layer then.

Re: A Higgs-Bugson in the Linux Kernel

#47

Post by snvzz »

eqvinox wrote: post #18
snvzz wrote: post #15

With millions of LoCs, it is no surprise there are bugs. Worse yet, the kernel runs in supervisor mode. This kernel design is bankrupt. There's much better available, such as seL4+Genode.

Please try keeping your snide comments to issues they actually apply to. This is a logic bug, with the kernel missing a piece of abnormality handling. You can get the exact same bug in a microkernel (or, FWIW, a memory safe, e.g. Rust) implementation; neither of those concepts help here.

>You can get the exact same bug in a microkernel

Absolutely. And yet, it is that much easier to keep a tiny codebase bug-free.

And only that tiny codebase has to run with supervisor privileges.

Re: A Higgs-Bugson in the Linux Kernel

#48

Post by eqvinox »

fragmede wrote: post #46
eqvinox wrote: post #26

Earlier quoted context omitted.

I'd go as far as saying most networked concurrent file access will ruin your life one way or another, because it's just a hard problem , and it's trying to solve it at a very odd layer; a "classic" fs can't really take advantage of higher layer transactional or other known constraints in order to make things work better…

Google Docs solved the problem at the right layer then.

No, Google Docs solved a different problem at the right layer. Their solution isn't transferable to other specific problems that may currently be approached using networked file systems, let alone the generic case.

Re: A Higgs-Bugson in the Linux Kernel

#49

Post by eqvinox »

snvzz wrote: post #47
eqvinox wrote: post #18

Earlier quoted context omitted.

Please try keeping your snide comments to issues they actually apply to. This is a logic bug, with the kernel missing a piece of abnormality handling. You can get the exact same bug in a microkernel (or, FWIW, a memory safe, e.g. Rust) implementation; neither of those concepts help here.

>You can get the exact same bug in a microkernel Absolutely. And yet, it is that much easier to keep a tiny codebase bug-free. And only that tiny codebase has to run with supervisor privileges.

Of course a tiny microkernel code base won't have NFS bugs. It doesn't implement NFS. The bug will instead be in the NFS process/daemon/service/… which considering it's an fs service won't exactly be unprivileged either, even if only by returning maliciously corrupted contents. (e.g. a SUID root file that should not exist.)

And, sure, a microkernel could have better security properties. However, (1) this has no connection at all to this specific bug, and (2) the Linux kernel seems to be doing reasonably well on security properties; or rather the industry seems to have decided it's sufficiently secure, even if not perfect.

Post reply on HN