Skip to content

Language-agnostic abstractions considered harmful

To conclude this first series on programming languages for OS development, I’d like to discuss the closely related issue of communication between programs written in different programming languages. This is an important issue for general-purpose operating systems, because these host, and thus communicate with, programs written in a wide range of programming language. Here, I’ll discuss typical approaches to this problem, and how I think TOSP should go about it. Read more…

On Ada and my OSdeving language criteria

I’ve talked about Ada a couple of times here before, and how I think it might be a very sensible replacement for the C family of programming languages in the specific area of OS development, where compatibility with existing code libraries is less of a critical criteria, and code correctness and portability becomes a lot more important. Today, I’d like to discuss how this language meets the criteria which I’ve set before on a good programming language for OSdeving. Read more…

Constraints on a good OSdeving language

So, after discussing a long, and sadly non exhaustive, list of caveats to C as a language for OS development, many of which were passed on to other languages which tried to mimick C’s design and behavior, an important question remains unanswered: if it is not C, what alternative languages should one use to develop operating systems, in my opinion?

It’s hard to answer this question generally, as the number of programming language designs in existence is truly mind-boggling. But as you will see, by applying a number of reasonable criteria, it is possible to dramatically narrow the amount of languages that would fit realistic OSdever constraints well. Read more…

The problem with C (and its derivatives) as an OSdeving language

During the past year, two very enlightening programming-related things which I did were to read Steve McConnell’s Code Complete and to continue maintaining a complete mid-sized software system written in the fairly primitive Igor Pro development environement. This taught me a lot about programming in a language vs programming into a language, and the limits of this approach to clean coding. Today, I’d like to discuss why in spite of being theoretically suitable for coding anything, C feels to me like a terrible fit for OS development in our day and age.

Read more…

Been away so long I hardly knew the place

About a year ago, in the middle of a major motivational and methodological crisis, I decided that I could not pursue this project correctly anymore. Shortly thereafter, divine punishement struck by pushing a loved one away from me. Lesson learned: never stop an OSdeving project, it can ruin your life!

Then a year passed, full of crazy events like going to Japan, writing a message-based RPC system in Igor Pro (try it, it’s fun!), feeling my mood rollercoaster oscillating between bad and worse, slowly pushing my PhD project forward, deciding that I want to be a software engineer rather than a teacher or researcher long-term, investigating how to sell or open-source the code I made during my PhD, learning many enlightening stuff about Information Security and the way computer networks work, stopped studying Japanese in favor of learning to sing…

In the middle of all this craziness, one thing persisted, though. Periodically thinking about this project. Wondering if I made the right choice by stopping it, if I could start it again, what I would change with the software expertise I gained, what I would keep the same…

Today, with enough content for 16 blog posts in my OSdeving ideas buffer, I decided that it’s time to try to resume blogging. I don’t know yet if I’ll go back to coding, or will remain on the drawing board side. All I know is, I have stuff to write about, maybe stuff to code too, and I’m tired of keeping it all to myself. And I feel ready to try this again.

Expect the first few posts to have a bit of a déjà-vu feeling, with a new spin to it. I have decided to revisit a couple of design decisions which I have made consciously or unconsciously in TOSP history, according to lessons I have since learned about software design and implementation. I also want to discuss the flaws of existing desktop operating systems and the rationale for building a new one a bit more than before, partly because it makes for good motivation, and partly because I also find it fun.

So without much ado… Let’s get back to this! In the beginning, I aim for weekly posting, as a first goal, so see you next thursday.

Putting TOSP in S4 state

Okay, it’s bad news time.

For many months now, I’ve had a really hard time getting enough stuff done in my life, and pushing TOSP forward in particular. I really haven’t been fully satisfied about anything I’ve done in this project for more than 2 years now. It’s not that I lack the ideas, rather that I can’t find a good method to implement them properly. Or allocate enough time to that method. I can’t tell, because it’s a vicious circle: the least things move, the least I feel motivated to push them forward. Trying a new approach brings some extra excitement, but it only lasts for so long…

The core postulate of this project is that the design of current desktop OSs leave much to be desired, and that one could do better with a little bit of effort, and a lot less legacy. But it appears that I either can’t bring the necessary effort, or don’t have enough software development experience to do it efficiently. So I think it’s better to put an end to this instead of leaving this project rot, for now at least. Perhaps I’ll get back to this later, once I have a few more successful medium-large software projects on my back, or when I mysteriously get a lot more spare time on my hands. For now, I want to focus on those “simpler” things in my life, those I’m pretty sure I’m able to sort out, but which for now scream for extra allocated time. Like finding a way to have my lab offer me a trip to Japan in the name of the almighty Science.

Many thanks to those few who followed the TOSP adventure, in any case. Especially to those who left lots of insightful comments on my design posts. If anyone feels like continuing where I stopped, he can feel free to drop me a mail at knights_of_ni AT gmx DOT com, and we’ll discuss that matter a bit more.

But for now… Au revoir!

TOSP-wide plans, part 4: Beyond just code

I think it’s time to conclude upon this first project-wide, coarse-grained overview of what the TOSP project aims to achieve. This last post will go beyond TOSP itself as a software project, however and offer a quick discussion of what would have to be built around it: resources for users and developers, decentralized software and update storage, and so on.

Read more…


Get every new post delivered to your Inbox.