Hacker News Reader

Comment by catwell | Hacker News Reader

If you're going to argue this then I agree with tptacek, you must also think it's an architectural problem that filesystems cannot all be implemented over FUSE with performance equivalent to their kernel versions.

Yes, TUN is not 0-copy. Is there an equivalent that's as fast as the kernel in any other major OS? (I'm asking that honestly, I have no idea.) If there is, is in-kernel networking on that OS as fast as on Linux?

The Linux network stack is what it is, there have been recent improvements for it (e.g. DPDK), but I think it must not be so bad given it powers most of the Internet.

View on HN

It doesn't have to be "over FUSE". There are microkernels out there like QNX and L4 which solve the filesystem in userspace problem, are extremely fast, and have done this for decades. You likely have a realtime L4 instance in your phone doing the real work talking to the phone network. Heck even my Nintendo Switch has a simple microkernel OS, with an unspectacular ARM processor, and it runs games - one of the most performance sensitive applications that regular people use.

Right, but L4 isn't even an operating system; it's an OS fabric, on which OS personalities are built. Nobody doubts you can build a microkernel architecture where filesystems and VPNs are equivalently performant in userland and the kernel, but nobody has managed to do that for a mainstream OS.

It's telling that xnu started out on Mach with a FreeBSD "personality", and grew into another shaggy monolith.

The L4 in your baseband or your enclave is not running anything resembling a general purpose operating system.

So I guess my argument is: sure, you could design and build VPNOS, the OS where VPNs are fast and never need to touch the kernel. But nobody wants that OS.

Minix. Rumor is it runs on a lot of Intel CPUs...

What is the performance of Minix running general desktop and server workloads?

I won't argue against you here, I like microkernel desing à la QNX, especially with synchronous message passing (MsgSend), and I used to run Minix3 as my main OS some years ago. It relies on a completely different scheduler model though, with different trade-offs. And you can't always avoid copies.

Also, QNX has never seen usage as a general purpose OS on a PC, even though I remember trying a QNX Photon Live CD years ago. I wonder what would work well, and what wouldn't. In particular, are there security issues related to the use of message passing for drivers...

Also, QNX has never seen usage as a general purpose OS on a PC.

It has. QNX 6.2.1 offered a full desktop environment. I ran it as my primary OS for three years (2003-2005) while working on a DARPA Grand Challenge vehicle. The vehicle itself ran QNX, and development was also on QNX. An early Firefox and Thunderbird both ran well. The Eclipse IDE ran. All the command-line GCC tools ran. It worked like a typical UNIX/Linux system, but with more consistent response. No swapping. I could run the real-time vehicle code while compiling or web browsing and the real-time code. That consistency in response time made QNX a nice desktop OS.

It disappeared on the desktop after Blackberry took it over and made QNX closed source again. (For several years, all the source was online. Then one day Blackberry took it down, with no warning.) All the open source projects then stopped supporting QNX. QNX development is now cross-compiled from Windows.

With a small microkernel with a good track record, there's no churn. There's no new kernel every week. The QNX kernel had an update once a year or so. This is a big win when it controls your nuclear reactor.

I mean, there's no churn in "the thing called your kernel", but that doesn't mean there isn't churn in the TCB, which is what you care about in security design. There's no reason the TCB in a microkernel would necessarily be any smaller than that of a monolith.

> With a small microkernel with a good track record [...]

https://media.ccc.de/v/34c3-8730-taking_a_scalpel_to_qnx

I'm sure that QNX's ASLR would be fixed pretty quickly if only it wasn't closed source (a massive shame, AIUI Blackberry aren't even really using QNX for anything seriously, it's used in a few car stereo systems, so it's basically "abandonware" at this point).

Reply on news.ycombinator.com