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…
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.
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.
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!
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.
So far, I have mostly focused on TOSP from the point of view of end users, because that is the scenario which matters most: if you don’t want to use an OS, you won’t want to develop software for it either. However, developer user experience is also of extreme importance, which is why this post will focus on it.
Aaaand… It’s been three months already ! So let’s review what happened to TOSP during this second quarter of year 2013.
Following the previous observation that I needed more regular milestones in the TOSP development process, in order to boost my motivation and have better visibility on what’s going on, I took a look at agile software development methods. From this, I came to the realization that having such milestone releases involved a more elaborate planning process, where long-term goals are already defined in writing, although in a fuzzy form, while short-term goals are specified in great detail so as to allow for precise project timing.
Consequently, I started to prepare myself for such a combination of coarse-grained and fine-grained planning, defining a project vision and a number of coarse-grained user stories. There still is a lot left to be done, though, such as writing user stories related to the software development experience (both at the system and application level), deciding how future development should be done and what should happen of existing code, and only then starting to plan and begin a first iteration of these new plans.
Meanwhile, I also explored the qualitative questions of system resource organization, screen tearing mitigation, and what a work-oriented operating system should be like, then took interest in the Ada programming language and discovered that it had promizing abilities for system development. In particular, its integrated RPC functionality made me wonder once again about what was the best way to implement RPC, and while I was at it, I also tried to consolidate my previous thoughts on task-based scheduling.
The main issue during this quarter was that I could not provide TOSP with all the care it deserves during May and June, due to a combination of a trip to India and a professional rush to get my current physics research in a publishable form. I have since explored using the Pomodoro technique to ensure that the share of my spare time that is dedicated to TOSP remains constant. It started to give some good results these past few weeks, but one needs to wait a bit more to see if this approach is truly sustainable.
And that’s is for this quarter’s events! Plans for the immediate future include general planning of the software development experience, including that of system services, and a discussion of the “meta” universe around TOSP such as website matters. If everything goes well, I might also be able to define and start a first iteration of TOSP’s new development process, but I may also need the fourth quarter of 2013 for that. Only time will tell…