The Reasons Nobody Gets Any Help

Right now the situation for developers of minor operating systems seems somewhat bleak. Windows and the Unixes compete in the server world, and Windows and MacOS X compete on the desktop. Linux even gets ported to every embedded device, leaving few niches for the hobbyist or sidelined operating system developer. Some have even gone so far as to say that New Operating Systems Won’t Stand a Chance. As anyone who reads OSNews can tell you, however there are a wealth of new systems with new ideas that just aren’t taking off. Given all these new ideas some – like capability security from EROS for example – should be good enough to catch on, so why aren’t they?

There are many intertwined reasons for this phenomenon, and a good place to start looking at them is the duality of opposites between operating system standards – POSIX most prominent among them – and innovative, revolutionary ideas. One the one hand, implementing a standard such as POSIX gives a new operating system a leg up and a library of working or partially working software, always a boon to an OS looking to build a userbase. On the other hand, the real gain of many revolutionary ideas like orthogonal persistence (definition: making RAM persistent by writing it to disk at checkpoints rather than using a filesystem to permanently store data) can only come from breaking compatibility with these standards and with mainstream computer use, isolating the project in question! If we ever hope to go beyond Unix and Windows a solution must be found so that new systems can do their own thing without cutting themselves off from the rest of the world.

The Unununium project found an interesting way to handle this that actually helps solve a couple of other issues, too. Rather than require that all programs for their operating system be written in a compiled language like C and link to their system calls to start with, they’re building a Python interpreter that can talk to the OS. This will render any standard Python code which doesn’t link to special operating system features or other software (a sizable minority) nearly instantly portable, irrespective of the fact that they implement that orthogonal persistence I was talking about above.

The next largest problem for new operating systems is, of course, hardware driver support. Thanks to fragmentation and disagreement in the OS community every new system must over years of work laboriously build its very own unique library of drivers to drive the very same hardware everyone’s already using on more mainstream operating systems! Some people think Linux is slow to gain hardware support, but at least it eventually does. Most hobby and academic projects can expect to be abandoned before they gain enough driver support to even match Torvalds’s kernel.

Here, at least, there is an apparent solution: a standard interface for device drivers to talk to kernels with. The problem is that it was tried and Project UDI‘s efforts at a Unified Driver Interface failed to be adopted by anyone with enough political clout or driver support to count. Even the companies that created, funded and poured effort into UDI haven’t actually adapted their operating systems to use it. The F/OSS software community doesn’t support it either, as when the debate about a driver API/ABI for Linux came up on Slashdot a month or two ago, the overwhelming opinion was that not forcing drivers to link to the kernel sources would lead to too many proprietary drivers! This sort of attitude might work for a system with Linux’s following, but no new OS is going to gain any support by forcing manufacturers or even other hobbyists and researchers to rearchitect their hardware drivers for each new, quirky kernel they want to run them on. UDI may not “benefit the Free Software movement”, but for those of us who hope to someday see our kernels running on real, everyday hardware it is a godsend. And just imagine if a major kernel like Linux or a BSD fork did support it, rendering many of its drivers usable under hobby system XYZ! UDI may be sponsored by proprietary software makers, even the latest “Great Satan” SCO, but it has reasonable technical merit and does the job it’s intended to do. More hobby and academic kernels should be UDI-compliant.

Yet what peril even awaits those who can write or obtain device drivers? The lack of runnable software. Every operating system that is developed must always have every single program of new software ported to it, even its own development toolchain. Again, while standards like POSIX and other similarities to mainstream operating systems can make this work easier, it is still a major piece of work. The integration of interpreted and high-level languages into the userland of the OS also helps in this regard, but more needs to be done. Every operating system ports certain important pieces of software like its toolchain and usually some user stuff like a text editor as well, and we have tutorial websites like BonaFide OS Development and The OSFAQ Wiki. Put them together! When you port a piece of extremely useful or common software you think everyone else will support, write about how you did it so everyone can learn from your experience! I know I will, and this collaboration should help with the effort of getting a userland set up.

Of course these few ideas won’t make the world an OSdevers paradise, but I humbly think they will help. Standardized device drivers will aid new OSes in picking up the hardware support they often desperately need, while high-level and interpreted languages at the basic levels of systems will provide a small but substantial software base to systems getting onto their feet. Finally, I’d love to see an effort to document how common, everyday programs can be ported to new operating systems, because we all know mucking about in the GCC source tree without a map is nobody’s idea of fun.

About the author:
Eli Gottlieb is an operating system hobbyist whose pet kernel lives at Glider. He hopes he’s helpful, or at least sparks off good dialectics in the comments.

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


  1. 2005-12-28 2:30 pm
    • 2005-12-28 2:54 pm
      • 2005-12-29 3:44 am
        • 2005-12-29 4:26 am
      • 2005-12-29 8:43 am
    • 2005-12-29 10:15 am
  2. 2005-12-28 2:51 pm
  3. 2005-12-28 3:04 pm
    • 2005-12-28 3:26 pm
    • 2005-12-28 3:27 pm
    • 2005-12-28 3:30 pm
  4. 2005-12-28 3:32 pm
  5. 2005-12-28 3:35 pm
    • 2005-12-28 4:36 pm
    • 2005-12-29 12:51 am
  6. 2005-12-28 4:10 pm
    • 2005-12-28 10:08 pm
  7. 2005-12-28 4:35 pm
    • 2005-12-28 10:06 pm
      • 2005-12-29 6:19 am
        • 2005-12-29 11:13 am
  8. 2005-12-28 4:37 pm
    • 2005-12-28 5:20 pm
  9. 2005-12-28 4:48 pm
  10. 2005-12-28 4:56 pm
  11. 2005-12-28 5:30 pm
    • 2005-12-28 9:12 pm
    • 2005-12-29 12:08 am
    • 2005-12-29 12:58 am
  12. 2005-12-28 5:30 pm
  13. 2005-12-28 5:32 pm
    • 2005-12-28 8:19 pm
      • 2005-12-28 8:42 pm
        • 2005-12-28 10:30 pm
          • 2005-12-29 8:55 am
          • 2005-12-29 9:45 am
          • 2005-12-29 11:33 pm
  14. 2005-12-28 5:52 pm
    • 2005-12-28 6:08 pm
  15. 2005-12-28 6:51 pm
    • 2005-12-28 11:35 pm
    • 2005-12-29 6:53 am
      • 2005-12-29 3:39 pm
        • 2005-12-29 4:20 pm
          • 2005-12-29 4:40 pm
  16. 2005-12-28 6:59 pm
    • 2005-12-28 7:24 pm
    • 2005-12-28 8:15 pm
      • 2005-12-28 8:59 pm
        • 2005-12-28 10:38 pm
        • 2005-12-29 4:17 pm
    • 2005-12-28 9:35 pm
  17. 2005-12-28 7:38 pm
    • 2005-12-29 12:19 am
      • 2005-12-29 9:07 am
        • 2005-12-29 3:35 pm
          • 2005-12-29 8:33 pm
  18. 2005-12-28 7:54 pm
  19. 2005-12-28 8:00 pm
  20. 2005-12-28 10:01 pm
  21. 2005-12-28 10:11 pm
  22. 2005-12-28 10:18 pm
  23. 2005-12-28 11:00 pm
  24. 2005-12-29 12:32 am
  25. 2005-12-29 3:08 am
  26. 2005-12-29 12:57 pm
    • 2005-12-29 1:31 pm
  27. 2005-12-29 2:17 pm
  28. 2005-12-29 4:07 pm
    • 2005-12-29 11:13 pm
  29. 2005-12-29 7:54 pm
  30. 2005-12-30 6:44 pm