Why you Shouldn’t Write your Own Kernel Anymore

As a programmer and manager of embedded software products for a living, I think that operating system programming is so much fun that it will eventually be outlawed. I’ve previously published two articles on OSNews, So, you want to write
an operating system
and Climbing
the kernel mountain
, and tried to summarize my experience in designing operating system kernels as well as technical traps that can be easily avoided.

You don’t know that you are wasting your time

I meant to write follow-up articles on the subject, but instead was sent by court order to Article Title School for two years. In the meantime, the world, and my perception of things – not just article titles – evolved. While I hope that someone, somewhere, found the advice helpful enough to start writing a kernel, I’ve realized in the meantime that the fun of doing that from scratch has – for all intents and purposes – actually been outlawed.

I hope I catch you before you burn any proof that you ever downloaded the Intel System Programming Manuals, as you look nervously through the window for the Code Police to come and send you to coder rehab. Cheer up, writing your own kernel is not really outlawed and you don’t have to move to writing accounts receivable software in C#. A lot of people with commitment, strong programming skills and free time are working on such projects as you read this, even though there is no point anymore. Some projects, such as Syllable and SkyOS, have made major progress towards a usable and stable operating environment and never fail to legitimately impress OSNews readers with their skills. The irony of such an opinion on OSNews is not lost on me. I expect kernel hobbyists to dismiss this article in the same way as I would have two years ago. Giving up rare skills that you built over a long time is not easy to accept. As a recovering kernaholic, I would love nothing more than being proven wrong by a strong, one-two punch demonstration, and to be conned into participating in a hobby OS project.

To be honest, I’m not holding my breath. Unless your only objective is to displace Robert Szeleney as the most admired underdog OS developer, your effort is probably wasted. I need to explain how I slowly evolved to this conclusion, and how this is a positive development. There is one piece of information and two colliding storylines that come into play.

How you can learn from being punched in the nose repeatedly

The piece of information first. I became a manager out of experience, not out of a Harvard MBA, so I like to hope that anyone with a decent business training will read the rest of the article and say “yes, so what?”. Well, pfft! to you – that’s the sound of the tongue sticking out. I haven’t been taught product positioning in school, or how to focus on what you’re really good at. I’ve learned by coming back from customers with a bloody nose.
Moving on to the first storyline. Last year, I seriously considered joining the Syllable project. It is the only desktop OS project on the market that I know of, that is at the same time usable, open source, and where I could make a significant contribution, unlike Linux for which an individual contribution is a drop in the ocean. The Syllable kernel has significant shortcomings. You can feel the round-robin scheduler and dysfunctional VM as you use the desktop. The lack of consistent primitives or clear notion of processes has obnoxious side effects such as the application server not closing windows of an application when it crashes. I thought I could help out instead of criticizing from my armchair. I did a lot of work on replacing the basic kernel with something that could support the rest of Syllable being dropped on top, and compete performance-wise with the Linux kernel.

Now for the second storyline. I created a company that develops, sells and promotes a software component architecture for consumer electronics products. The company has been around since 1998, and the product started out as software that I enjoyed writing – an operating system. Essentially, the product offered two opposed features. First, a component based operating system for consumer electronics products, the first of its kind, that lets you replace any system policy such as scheduling, memory management and power management, by your own. Second, a component model that basically transfers the well-known benefits of Corba, DCOM or .NET such as increased code-reuse and cleaner isolation, to the Consumer Electronics world. The re-use is a massive problem at the moment in the industry, since manufacturers have essentially moved from being hardware companies producing VCRs and analog TVs that had little custom software, to being software companies producing DVD-RWs and Digital TVs that require staggering amounts of custom software. We tried really, really hard to pitch our operating system to customers.

If they wanted the component model and the re-use benefits, they needed the OS, take it or leave it. Well, they left it, consistently, in Japanese, Korean, Dutch, French, English, and other languages. Whoops. We blamed the failure on a lot of things, but eventually, we faced the obvious facts.
One, the interface of a desktop, server, or embedded OS kernel has been refined over time to become a more programmable machine than the instruction set. It’s a standard conceptual interface. The same way you have the Intel and ARM instruction sets that support similar operations, you have posix, Windows and µITRON APIs for memory management and semaphores, but they are conceptually identical. If you offer radically different primitives, application programmers will not make use of it, for the sake of portability of either the code or their knowledge.

Two, a platform needs applications and a developer community in order to succeed. You have neither when you create a kernel from scratch. You could copy an existing design and API in order to have applications and developers, but it has already been done. Linux and BSD are free and fit almost any purpose.

Three, a new OS and code re-use are contradictory. For some reason, we couldn’t sell to our prospects that they could re-use a lot more code than they currently do, and could architect their software a lot better, by throwing all their code away and rewriting it for our OS. Our prospects had the nerve not to want to invest millions of dollars to rewrite software they already had.

Four, you can be the world’s best, or even really, really good, at only one thing. Everyone acknowledges this is true for a small to mid-size team, and I believe this applies to any organization, even the size of Microsoft or with Google’s coffers. Microsoft does a lot of things, all of which lose a remarkable amount of money on fire and motion, except for their operating system and tightly related core applications. Google’s managers won’t touch anything not clearly related to search. Management droids even have a name for this: the hedgehog concept. Hedgehogs are really stupid animals, but they are superior to many, in the sense that they only know one thing, rolling into a ball of spikes when attacked.

Fifth, there is no entitlement when you design something. Your users, whether they pay for a commercial product, or they use a Free/Open Source piece of code, do not care that you spent thousands of hours of really hard work to come up with what you offer to them. Syllable and SkyOS are really neat technical achievements, but they are less functional than Linux and are not attracting normal users in droves. Linux still has to figure out how to be better than Windows on the home desktop in order to win users over.

Armed with this reality check, my company repositioned its product away from the operating system and sharply on the component model and code-reuse. Essentially that meant porting our OS on top of the popular platforms in Japanese Consumer Electronics – Linux and TRON at the moment – then removing what wasn’t needed anymore. All of a sudden, customers started calling us to buy our product. By focusing on our one good idea, we were then able to make our component model cover a lot more needs, and today I think it is really a decent product. In retrospect, trying to shift them to a new OS had felt like pushing a rope.

Do I like working on what we sell now? Along with a couple of the programmers that were attached to doing kernel development, I really did mind that the market chose the least fun feature to work on. I couldn’t use my kernel programming experience anymore. Then, I realized that in comparison to writing kernel code, anything else is easier. It’s like training for a tennis match with weights and then removing them for the big game.

The skills you build for kernel development, the precision, rigor, testing, careful debugging, can be reused with nine times the efficiency when working on something above the kernel. You just have to find what can really motivate you and has a purpose to work on.

My company is not the only one that had this epiphany, it looks like. The Tao Group used to sell, guess what, an operating system for consumer electronics. You probably have heard of them as part of the Amiga saga. Their claim to fame is the Virtual Processor architecture, that lets you write portable but hand-tuned assembly code. Somehow they make this work. When the penny dropped, their OS, as a product, was taken out and shot, and now they are very successfully selling their one good idea. Their VP architecture allows very efficient, graphical content, that is portable across all CE devices. The JVM they designed on top of their VP architecture is mighty. They’ve found their one good idea and swept the rest under the rug.

Okay, so the second storyline was a bit longer than the first. If you don’t hear from me for the next two years, please send me care packages at the Article Writing School. Now, both storylines are high speed trains going towards each other and they just collided.

How you can make the world a better place

The epiphany about our product and the lack of purpose for yet another OS spilled into my intention to work on Syllable. In the end, I didn’t. The Syllable project has assembled a small group of talented people and I believe that they are absolutely right in trying to fix the lack of integration on a desktop that most distributions of Linux suffer from. Today, the user experience that the Linux desktops offer is best described as goofy. A well integrated kernel and desktop API, with a managed code approach to RAD such as what Mono offers, would make things a lot more consistent for the user. However, in light of the epiphany, my opinion is that the Syllable team is severely misguided about how to solve the problem. They want to be the best at such an integrated desktop while also having a good kernel, drivers and what have you.

Let’s ignore the typical kernel that is still stuck in “bootloader stage”. Most kernel projects start with an idea such as, let’s create an OS around this new filesystem thingie. Then, night after night, a small, expanding team of programmers duplicates scheduling, virtual memory, a posixish API, the windows registry, device drivers for ISA network cards and an USB stack. Two years later, the filesystem thingie is implemented. You have to commend the project developers for going that far, but, then that thingie is not as useful as it sounded, and the project is repositioned as a general purpose OS of sorts. Worse, it actually is useful, but nobody will ever benefit from it because their favorite application doesn’t work on this strange OS. Worse for the project, somebody steals the idea and releases it for Linux with great success. In any case, a lot of effort was spent in duplication, while producing nothing new to the OS world, or the users, you know, the ones that throw us a bone once in a while so that we can afford to keep having fun programming.

In terms of desktop or server operating systems, I cannot think of a single new idea that cannot be implemented as part of an existing OS. With the sourcecode of time-tested, free kernels readily available, and the previous statement that the basic kernel interface can be built on top of, there is no excuse not to experiment with the new idea as part of an existing kernel, or userland. For instance, I think that there is a lot of merit to having device drivers and other modules running as their own task, even a kernel one, and working asynchronously by communicating with the kernel exclusively through messages. This is a cool challenging project, and for the end users, it means they can unload and reload modules without any chance for failure, since you cannot have threads still left in the code being unloaded. The system also scales up on SMP a lot better than locking all over the place. You might be tempted to write a kernel just around that idea, but there is no justification not to patch Linux to work this way. It will be a lot of work to modify and re-test device drivers, but a lot less work than doing it from scratch. It can be done incrementally, always shipping an OS that works even though not all device drivers and kernel modules benefit from the new idea yet.

Guess what, the DragonFlyBSD project is exactly about that, and they started with the FreeBSD code base.
I’m a bit more familiar with embedded operating systems dynamics than servers and desktops ones. Their users, software engineers that work for consumer electronics giants, are really smart. They are a tough and rewarding crowd to sell products to. They have well understood that their customers, you and me buying basically the same DVD recorder every year, don’t care about some obscure edge that a custom OS would give them anymore, so they’ve standardized on OS platforms. It used to be commercial RTOS products, or free specs such as TRON, now the industry is pretty much migrating to Linux as the lowest common denominator for products. Even if your project is open source and free, if it’s basically a me-too kernel chasing Linux’s tail lights, nobody will care. Take Linux and apply your one good idea to it, and a lot more people will care.

I don’t believe there is a market, either in terms of paying customers, or in terms of people that will actually use your code as their daily environment, for writing a kernel from scratch anymore. This is depressing when you have mastered the art of architecting your wait queues, scheduler and semaphores so that everything is really efficient and maintainable. Any domain of human knowledge gets commoditized over time, this is good for everyone, and the experts have to learn to adapt their expertise to a higher-level problem set.

The good news is that the operating system is not limited to the kernel and the open-read-write-close interface anymore. A surprisingly minuscule amount of university research has gone into concepts that will extend an existing OS to develop applications quicker and with higher quality. Almost all of the inroads have been made by private corporations or non-funded open source efforts, and as modestly demonstrated by my company, there is room for a lot of new, really cool projects to work on.

As kernel developers, your skills are an edge over other people in terms of writing and delivering code to plug a hole that you have identified somewhere in the operating system. If you shift your focus to plugging it instead of duplicating existing and time-tested software, I can’t imagine how much better the software environment will become for all of us.

About the author
Emmanuel Marty is a founder and the Chief
Technical Officer of
NexWave Solutions, the supplier of the first commercially available component architecture for consumer electronics, in use at top manufacturers. He has been working with computers since the age of 10. Currently aged 28, he lives in Montpellier, France, with his wife and twin daughters.

If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.


  1. 2004-09-03 2:19 pm
  2. 2004-09-03 3:33 pm
  3. 2004-09-03 3:49 pm
  4. 2004-09-03 3:53 pm
  5. 2004-09-03 3:55 pm
  6. 2004-09-03 3:58 pm
  7. 2004-09-03 4:35 pm
  8. 2004-09-03 4:38 pm
  9. 2004-09-03 5:08 pm
  10. 2004-09-03 5:12 pm
  11. 2004-09-03 6:09 pm
  12. 2004-09-05 5:24 am
  13. 2004-09-05 4:56 pm
  14. 2004-09-06 3:15 am
  15. 2004-09-06 4:23 pm
  16. 2004-09-06 5:26 pm
  17. 2004-09-06 6:42 pm
  18. 2004-09-07 5:09 am
  19. 2004-09-07 12:43 pm
  20. 2004-09-08 6:58 am
  21. 2004-09-10 8:43 pm
  22. 2004-09-10 9:08 pm
  23. 2004-09-10 9:43 pm
  24. 2004-09-10 11:14 pm
  25. 2004-09-11 12:30 pm