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.
Today, as another filler until I get enough time to resume OSdeving, I had some time to try out a quick performance test that has important implications for PC OSdeving : is it still possible, as of today, to get decent graphics performance out of software rendering in case a dedicated GPU driver is not available ? I’m not talking about displaying millions of triangles per second here, just displaying bitmap animations at a modern screen’s native refresh rate. Well, let’s find out !
Hi everyone !
In case you are wondering, I’m not back working on TOSP just yet. My PhD has now entered its worst phase, with a dreadful last month of manuscript writing and an awfully ill-timed conference next week to make things worse. So I still cannot engage in a long-term personal programming project yet.
However, I have a little spare time left to code stuff I like at home. So I decided to practice my Ada a bit by translating some of Numerical Recipes‘ code snippets in Ada 2012, using my own coding style and a different name to avoid trademark lawsuits. I like it, it’s fun and full of bit-sized programming tasks that I can easily start and stop whenever I like. And at the same time, it also teaches a lot of enlightening stuff about how seemingly mundane decisions in programming language design, such as array bounds, can profoundly affect day-to-day coding in that language.
Which leads me to today’s thoughts on heap memory allocation and why I think we’re really overusing it these days.