Hello, old blog friend.
Sorry for neglecting you lately. I don’t allocate as much time to OS research these days as the subject would warrant. I currently prefer to prioritize things like my precarious academic job and hobbies that fit better into the small time slices that I manage to allocate away from it, such as learning Rust and trying to build better Linux performance analysis tools with it.
I know it’s not an excuse, and I would like to get back to OS work at some point. Especially as every day remains a reminder of all that’s wrong about today’s operating systems and the abstractions that they present. And so today, I would like to discuss one particular OS abstraction that IMHO has not aged well and would be in need of a serious redesign in the next generation of operating systems: threads.
A couple of weeks ago, I introduced you to one of my current pet projects, mostly aimed at making my next job easier but which could also be of interest to some of you: CLplusplus. Since then, that project has grown quite a bit, and I think it is now safe to say that it is about 50% there. Not in the usual terms of “50% of the code is written, untested and undocumented”, but in actual whole-project effort terms. Continue reading
In my last post, I discussed my current attempts to build an emulator suitable for OS development. Today, I will discuss another project which I’m simultaneously working on, which is is more closely related to my next job than to OSdeving but could be of interest to some of you readers anyway: CLplusplus, a more modern C++ wrapper to the OpenCL API than what the OpenCL standard will provide.
After spending some time hacking on Numerical Cookbook, I’ve reached enough confidence on my Ada skills to try out another, more ambitious project, which is more directly related to my long-term goal of resuming TOSP development. This week, said project has reached enough maturity for me to consider it camera-ready, so let me introduce you to my latest software experiment, EmulatorKit.
Today, I would like to take this blog’s usual content aside for a second and express how outraged I feel about the attacks that are currently ongoing on the Protonmail encrypted email service.
As of today, end-to-end email encryption as a technology is not ready for the general public, because it is much too difficult to understand, setup and use. Services like Protonmail aim to change that and bring truly private telecommunications to the masses, and this is a cause for which I have the deepest respect.
Of course, I will gladly disagree with them on the technical level :
- Considering the amount of vulnerabilities that get disclosed in them per day, web browsers do not seem to be a safe platform for high-security applications.
- A centralized infrastructure is not a very good fit for a service that goes against the will of nation states, because it means there are only a few people to pressure/torture in order to get control of the infrastructure, and only a few computers to crash in order to bring the service down (as we are experiencing)
But the thing is, even if they are never going to build the perfect encrypted communication tool on their first try, Protonmail have got something running, it is ready right now (or at least it was until someone powerful decided to break it), and it is simple enough that nontechnical (or at least only mildly technical) people can use it easily. From a social point of view, that is something huge.
Thus, my dearest sympathies go to the Protonmail team in their current struggle to stay afloat. And so, dear reader, if you have the financial resources to do so, please go and help them. After being unfairly pressured into paying a huge ransom that turned out to be useless, they need all the financial support that they can get right now.
EDIT: And… they are back up ! Hope their anti-DDoS protection strategy will work.
Long-time readers of this blog will know that I have no fondness for the monolithic kernel design used by legacy operating systems. In addition to stuffing too much functionality into one piece of software, which is a failure at basic software design, and doing so on the single most privileged piece of code on a machine, which is a failure at basic software security, this design practice also has averse effects on performance by requiring frequent context switches between the OS kernel on one hand, and user-mode processes on the other hand.
In this blog post, I will highlight how this context switching overhead can be minimized through the use of more asynchronous system call and interprocess communication primitives. I will then show how these conclusions apply not only to traditional monolithic kernel designs, but also to more modern OS designs.
Want some silly programmer humor ? Here’s a quick attempt at explaining how people would build a bicycle using the real-world equivalent of the programming languages I know of.