See, this is why I dream of making FU money. So I can spend all my time doing stuff like that.
You don't need FU money.
You should probably try to find one that can either PXE boot or boot from a USB stick, since those are pretty much the easiest ways to quickly test your software.
When you are older, have a job, you need FU money generally. Or no life.
I still think there's room for improving operating system security models, but I don't think it's possible to improve over OpenBSD in this particular dimension.
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.
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.
Most of this, but not all, comes from the traditional academic and industrial-lab research context.
> By contrast, a new language or OS can make the machine feel different, give excitement, novelty. But today that's done by a cool Web site or a higher CPU clock rate or some cute little device that should be a computer but isn't.
> Work on how systems behave and work, not just how they compare. Concentrate on interfaces and architecture, not just engineering.
> Only one GUI has ever been seriously tried, and its best ideas date from the 1970s. (In some ways, it's been getting worse; today the screen is covered with confusing little pictures.) Surely there are other possibilities. (Linux's interface isn't even as good as Windows!)
> There has been much talk about component architectures but only one true success: Unix pipes. It should be possible to build interactive and distributed applications from piece parts.
Chrome is an environment for running AJAX web applications and enabling them to talk to each other; among other services, it provides a graphical user interface toolkit (DHTML), a SQL database (SQLite), security mechanism and policy (via tab-per-process, the same-origin policy, incognito mode, and restrictions in the JS engine), a JIT compiler for a language, and process management (both at the user level, with its process viewer, and at the language level with Web Workers). It has a component architecture built in; several of them, actually: iframes, plugins, JSONP. It is possible in Chrome to build an interactive application from "piece parts"; this is currently called a "mashup".
So Chrome is right in the center of the issues Pike's talk was talking about. Much of this, of course, is made of ideas that don't come originally from Chrome; but Chrome is on the cutting edge of making new stuff possible.