Hacker News Reader

Comment by pjmlp | Hacker News Reader

Yet the way I see it there is more OS research going on with unikernels and at Microsoft Research labs than with Linux.

Which appears just to be the same old idea of UNIX and mainframes revamped in new package, stuck in C and in a kernel model that has hardly changed.

EDIT: To clarify.

Many use GNU/Linux in the same way as they would be using UNIX SYSTEM V, there is hardly any change.

Add to it that besides new filesystems, adoption of mainframe virtualization and sandboxes concepts, there is hardly anything new happening in OS research in regards to Linux.

What I currently care about is OS research that tries to mimick the Xerox PARC experiences, use of micro-kernels, use of safe systems programming languages and so forth.

View on HN

> What I currently care about is OS research that tries to mimick the Xerox PARC experiences, use of micro-kernels, use of safe systems programming languages and so forth.

Why? When was the last time there was a Linux crash due to it not using a "safe" language? How many people did it effect? Is Linux actually measurably any the worse for using an "unsafe" language?

Would Linux be measurably any better for use of a micro-kernel?

Is anybody going to spend the man-decades (or man-centuries) necessary to re-write Linux using micro-kernels or safe languages, just to wind up at the same level of functionality? No. Ain't nobody got time for that.

So unless you can point to concrete, measurable benefits that are going to come from switching to micro-kernels or Rust or whatever, Linux is going to continue on its way. (I agree that the advantages of micro-kernels are a valid research subject. But you need more than Tannenbaum's "that's the right way to do it". You need a compelling reason where it can do something that people care about that Linux can't do, or where it can do it with much fewer resources (either hardware or programmers), or something of that sort. Merely 10% improvement, say, isn't going to cut it, because you'd have to re-write all of Linux to get that improvement, and it's not worth it.)

Well, you don't need to rewrite all of Linux. What's currently happening is that some subsystems are incrementally being made more accessible from a user context - e.g. a new flag for madvise(2) to make page fault handling in userspace easier, NSUSE to access certain network drivers as userspace libraries, FUSE to cooperate with the in-kernel VFS to get file systems as user processes, virtual consoles outside the kernel and so on.

The demand for microkernel-like features is there, and Linux will progressively be refactored into a hybrid kernel with a standard set of "servers" you plug on top to augment it (systemd appears to be taking the role of the servers in question). Whether this architecture will end up desirable or an awkward worst-of-both-worlds combination remains unclear.

I will let CVE database speak for me in what concerns security.

Micro-kernels are used in many embedded scenarios nowadays. Even your phone or car infotainment system might be running one, e.g. L4, QNX.

GNU/Linux being a UNIX clone will never change. Using a micro-kernel or any other language instead of C simply doesn't work out in UNIX culture.

MINIX 3, Hurd, DragonFly BSD (hybrid) are existing counterexamples. Amoeba, Sprite and Spring were research Unixes with microkernels.

Actually I see them as examples that failed to change UNIX culture in regards to OS design. Always downplayed by the majority of UNIX users.

Yet the way I see it there is more OS research going on with unikernels and at Microsoft Research labs than with Linux.

Unikernels are just the logical continuation of exokernels, except designed to run under a bare metal hypervisor. Though still excellent to see libOS taken to its limits, I find the task of actually turning a full workstation operating system into a secure multi-tenant distributed cluster system to be more versatile, as you could then tailor it to both general-purpose and special tasks, libOS being firmly in the latter - deploying applications.

Singularity was great, though it seems to have stagnated.

Singularity evolved into a few other projects, some of them now on .NET.

The compilation of .NET to native code on Windows Phone 8.x with MDIL, and its successor .NET Native, can be traced back to Bartok. The Singularity's AOT compiler toolchain for Sing#.

Microsoft research then went on to Drawbridge, Midori (still classified) and now IronClad.

Then as programming languages that grew out of it there the M# which was mentioned around two years ago and not much more, and Dafny being used by IronClad.

Minix 3 seems interesting. But for the foreseeable future C seems to be the language of choice for OS development.

Rust is safe(r) and could be integrate/replace with C incrementally.

In theory yes, but I don't think a UNIX clone will adopt it as such. It is a matter of culture.

Better in other OS that are already researching alternative systems programming languages.

Reply on news.ycombinator.com