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…
Following upon my previous post in this series, regarding how to optimize the first contact between potential users and a finished TOSP build, this post will introduce a first batch of user stories regarding what everyday TOSP use should be like. In effect, it can be considered as a short summary of what was discussed in the past few months on this front.
Edit: Oh, and since moving existing documentation to GitHub would be premature as long as I haven’t defined what the current plan is, I have taken the “migration in progress” post away from the front page.
It’s not the first time which I’ve said this, and it won’t be the last: on a modern operating system, prioritizing code with respect to which process it runs in is largely useless and should be replaced with more advanced scheduling mechanisms which can actually grasp the context of tasks. In this post, after a quick reminder of why this is the case, I will discuss ways to achieve task-based scheduling, along with various edge cases which have to be handled properly for such scheduling to work well.
My current investigation of the Ada programming language has led me to an interesting discovery: there is such a thing as programming languages with integrated InterProcess Communication (IPC) functionality. In the case of Ada, that functionality is based on a combination of Remote Procedure Calls (RPC) and distributed objects, and designed for network transparency. Apparently, Ada’s designers also reached the conclusion that message-based communication is the Assembly of IPC in that using it is both error-prone, frustrating, and time-consuming. This discovery led me to think a bit about what I’m trying to achieve with RPC, and whether I’m doing it the way I should.