How to Write an Operating System

Thank you. I'd learned from the original text. I never knew he had released a couple more editions of this.

In fact, I may have to go buy this now!

So Tanenbaum has two OS textbooks in print? How different are they? Why read one rather than the other?

OS security is something that really aught to be discussed separately from OS texts. I mean, not all OSes are multiprogramming or need security. Earlier version of his Operating Systems book taught MS DOS, along with others, for example.

Security exposition is something best left to a separate text, and Matt Bishop's fat book does a good job (not the thin watered down one.)

I wrote Love a personal thank you letter after I read LKD :-)

Actually, it's Unix backwards, but surely you knew that.

Aliens had much more advanced operating systems 75 million years ago. Imagine which operating systems they have NOW! :-)

You say that like it's a bad thing. ;-)

I think there is. Every OS that exists is a mess. Make an OS whose inner workings I can undestand (and therefore are very well documented) while allowing to make commonly used software, and I will worship you.

There's definitely room for improvement over currently used server and desktop operating systems; the security models used by desktop Linux, OS X, Windows, and BSD don't meet the needs of users in a world of malicious software. iOS and Android were able to improve on the situation a good deal by adopting higher-level security models that protect applications (and their data) from one another, but the desktop lags behind.

As far as I know there's no technological reason the same couldn't be done with the server or desktop, it would just be an enormous shift in momentum to get there from where we are now. But if we're willing to stomach shifts in momentum, we could even go further and consider other, more radically different approaches to security than what's commonly used now, such as Microsoft's Singularity.

I don't know enough to say whether an operating system startup could be successful, but I think if it were, it would be less about basic operating systems research than about getting what research we already have into the hands of the masses on the desktop or the server. Presumably by targeting sectors where customers care enough about security to make the difficult switch to a fundamentally incompatible system.

I don't know about OS research specifically but there are a few systems startups about. RethinkDB and Acunu are the first to come to mind.

I tried to build one from scratch based on my own L4 microkernel. Given the bloated nature of monolithic kernels and their irrelevance to embedded space, I had the thought that if I wrote something small and neat it could gain traction for embedded systems. For that I took the BSD virtual memory design, and implemented a complete VM system from scratch. Then I wrote a VFS layer but that one was partially complete. I had demand paging implemented and supporting calls like fork() execve() etc. It was challenging and fun - but an incomplete project, also my biggest error from a startup/making money point of view. Basically having a new kernel is a hard sell nowadays, no matter how neat it is. It was more of an intellectual challenge for me rather than a startup - but still I was in the expectation that it could be a success.

About exactly a year ago, I changed my direction to virtualization. I ditched about %60 of the software that includes all that VM layer and VFS for which I put loads of effort (many man months...). I realized I was out of focus, so I changed my focus to enhancing only the microkernel itself. I decided upon three specific goals: 1) Adding multi-core support for latest ARM cores (e.g. the ones that will be on most high-end mobile phones and devices) 2) Adding fine-grain security and control based on capabilities. (in short, having control over system calls) 3) Adding virtualization support for the linux kernel. Right now I am done with the first two, and about to get done with the 3rd one.

My interest has always been to create something new in the OS/kernel space. After doing much research I decided that L4 microkernel design represents the most promising work in this field. This is because a) monolithic kernels are mature and good for what they are doing b) microkernels can solve certain new problems like virtualization.

Eventually I was convinced that embedded virtualization would be the most interesting problem I could solve. In my opinion there is still room for systems-level work particularly in Virtualization. The APIs are not set in stone. Not many people know how virtualization works, let alone design an interface for it from scratch.

I think new areas like this will come up but its quite important to spot an unsolved problem because if you dive in to write a kernel its an expensive journey.

What about XenSource? I believe they were later than VMware, and they made a tidy sum when Citrix bought them.

Minix is hiring driver developers and kernel hackers.

Systems software research was irrelevant ten years ago when Rob wrote that. Thanks in part to his efforts, there's a great deal of relevant systems software research now: Golang, MapReduce, Hadoop, Tahoe-LAFS, Caja, Chrome (the browser), LuaJIT, seL4, Capsicum, the CLR, HotSpot, V8, Nitro, Tracemonkey, GFS, Sawzall, Pig, Redis, Puppet, Chef, Tor, HTML5, ...

Most of this, but not all, comes from the traditional academic and industrial-lab research context.

If this post were from, say 5 years ago I would have figured it was spot on. But today? Look at all the new OSes coming out now in the mobile/appliance space. Not to mention that Windows Vista/7 was enough of a shift that the learning cost of moving operating systems has gone down relatively (because you'll have to do it regardless).

That's why I love the software industry. We have such a low financial barrier to if you want to play around with even the deepest systems programming techniques, or the highest-level functional programming languages. All you need is a $400 PC.

I am not in school. I have mouths to feed.

When you are an undergrad or recent graduate, you can do this.

When you are older, have a job, you need FU money generally. Or no life.

That is great to hear. I've heard a few stories on how painful that stuff was to track down and write. Bring up always sucks. This sounds like an excellent way for people to dig into writing kernels without forcing people to write all the bootup code before they can do anything.

How do you do device handoff? Are people restricted to an exokernel model or can they handoff to a macrokernel kexec style?

(VMware used to use the Linux kernel to take care of init before they wrote it themselves, so there's definitely a need for this type of thing, even beyond hobbyist.)