Hello, I will try to write such a public status update on my activities each month. I'm not sure if I will manage to keep this good resolution on a long period, but let's start. Sorry in advance if this status update is a mess, but that's part of the game, isn't it?
Other reports for 2024: (January), February, March, April, May, June, Summer, September.
On the open-source front, I made a new version of po4a this month. This is a tool to help with the maintenance of open-source documentation: it extracts the content of many documentation source format (Markdown, HTML, AsciiDoc, Groff, etc) and puts it in PO file, which are often used to translate the binary messages of open source applications. Once the translators are done with their manual translation, the tool puts back the translated content in the structure of the original document. This setup makes it easy for the translators to update their work when the original document is modified. Without po4a, it's near to impossible to synchronize translations when the original changes.
This new release of po4a concatenates the work of the community for one whole year, explaining the long list of fixed bugs. In addition, I did a rather intrusive cleanup of the internals, switching from a manual (and crude) handling of the documents' encoding to the PerlIO system, which does so seamlessly. This makes the code easier to read and work with, enabling future evolution. I also reworked the project documentation to present the internals, in the hope of further increasing the community.
On the teaching front, I ranked the last exams of the previous semester, and I did the first hours for the two classes that I have this semester. The first one is about C++ programming and software engineering (all my teaching are in French, sorry). It comes after my teaching on C programming of the fall semester and before a teaching on HPC for our second-year students in fall (so our students have one class per semester with me: C/system, then C++/software engineering, then HPC). My second class of this term is about pedagogy in CS, where my students have to teach concepts of computer science such as NP complete or non-ambiguous language to 10-years old pupils of partner schools using unplugged activities. I do these lectures since several years, and they run rather smoothly, but this year our dean decided that every session must be one hour and half, where they used to be two hours each. This induced quite a lot of adaptations to find a new rhythm. This will probably require more work throughout the semester. I hope that this change is at least beneficial to the students, if not pleasant to us.
This semester, I also decided to follow one class given by Simon Rokicki. That's a classical class on compilers' construction. I must confess that I was not very serious when I first took this class as a student 20 years ago, so I needed a refresh. I love taking classes this way. I rarely manage to save enough time to assist to the lectures and do the practical, but when I do, I love learning things this way. This time, that's even better because Simon decided to follow my C++ class this semester too, which makes things even more interesting.
On the administrative front, this has been another loaded month (I'm in charge of the CS teaching department in my institution). The most time-consuming was the visit of the Toulouse research labs for 3 days with 40 students, but that's also the more pleasant. I had to deal with the resignation of two students who gave up. I often manage to avoid such situations, so it's harsh for me to have two failures the same week. Another point was that our experimentation of last semester for a teaching on the role of computer science in Anthropocene failed. The students are very interested in the topic, but hated the form of that teaching. After discussions with several colleagues, we will keep the topic, but entirely change the content (and the teaching team). HTH.
On the research front on SimGrid, I did almost nothing useful this month. After ~20 years on this research project with weekly or even daily commits, that's a big change for me. I tried to investigate a bug that was reported by a user from Toulouse, but failed to fix it so far.
I'm still co-advising the PhD thesis of Mathieu Laurent (co-advised with Thierry Jéron) on the formal verification of distributed applications through model checking, thought. That's actually the topic of my only useful commit this month: I helped Mathieu in his effort to improve the tool performance, to hopefully find bugs in existing codes. He managed to reduce the memory consumption from gigabytes and growing to only a fixed amount of dozen of megabytes. In addition to the fact that we don't swap anymore, the timings were improved by a factor of 50! He saved many memory copies, at the expense of a relative reduction of our abilities (we lost the ability to use contextual dependence relations, but that's too specific for me to explain it here), and I saved many dynamic casts that were hitting the perfs too. The current status is that there is a bug in SimGrid with which Mathieu struggles, because the logs are 760Mb of text. We need to reproduce the problem on a smaller case to fix it, and hope to find a bug in the verified code.
Our paper with Clément Courageux-Sudan (who defended in December) and Anne-Cécile Orgerie (co-advisor) on the modeling of Wi-Fi networks in Fog infrastructures (for time, energy and CO2 footprint metrics) were rejected from ICPE for bad reasons. The reviewers complain that our work is not reproducible enough while we provide the whole environment, with all source code and scripts that generated the figures of the article. They say we should compare our tool to other simulators in addition to the 3 external tools used in the evaluations. It's dismaying, provided that many papers get accepted without even a comparison to another simulator of the literature, and provided the sorry state of so many tools that are more barely usable PoC written by students and soon forgotten while we try to build a well maintained tool with SimGrid. We suffer from the double blind reviewing process here, as we cannot claim our efforts on the tool, as it would identify us during the reviewing process... Well, that's the usual game. You write paper, get rejected and then blame the reviewers or the process. Hard to think in good faith in such situation.
Our paper with Léo Cosseron (PhD student), Louis Rilling and Matthieu Simonin (co-advisors) on the use of simulated networks between virtual machines to trick malwares that test the network to detect and evade analysis was rejected from EuroSys. We knew this paper was borderline for such a prestigious conference, but it could have make it. At least, the reviews good and give us many leads. That's life, even if these rejections sum up with the one we got back in December with Mathieu and Thierry. I hope that our next papers and the ones still under review will eventually get accepted...
On the SmolPhone front, we
answered with Simon to an Inria call for project to get two years of funding for
2 engineers (4 years in total). The first engineer will build a devboard of the
hardware (or even a first prototype if time permits) while the other engineer
will write the base software that we need on the phone, but that does not
involve any research effort (phone, texts, mails, agenda, etc). Will see if it
gets funded, I've heard that the budget were cut by half or more this year. We
also published a master internship
topic
with Anne-Cécile on the use of an online proxy for the HTML rendering that
cannot take place on tiny devices, but we did not find any student. More
precisely, I was so late to answer to our candidate that he took another topic
in the meanwhile 
The internship of Aloïs Rautureau (co-advised with Simon and Joseph Paturel) on the SmolPhone continues. His goal is to demonstrate the practical feasibility of using a RP2040 for small tasks while offloading larger tasks requiring Linux to a Raspberry Zero. He's progressing steadily, and we have good hopes of having a real PoC by the end of the internship in April.
On the frugal computing front, I almost completed the reading of Héritage et fermeture, a great book on how we will deal with all the legacy that this ending world produces and produced. It's not really easy to read, but really enlightening. It's not only that we have to invent new technical alternatives, as the great dudes of Low Tech lab or the uxn community do with brio. It's not only that we have to imagine new dreams and desirable futures as with SolarPunk SF authors (Becky Chambers, Camille Leboulanger and others). It is also that we have to take note of this legacy as a whole with its zombies technologies and unfortunate dependencies, and try to untangle it all for a new present in which everybody can work, eat, and live. Again, that's a demanding reading, but very interesting. I would not say it's inspiring because it's hard to bring these ideas into practice. Even more because the authors sort of imply that computers are harmful by design and cannot be part of the solution. I keep thinking (hoping) that frugal computing is possible.
After the death of Niklaus Wirth earlier this month, I started reading his book on the Oberon OS. It provides a kernel, a compiler, a text editor, a mailer and some other tools in about 20,000 lines of Modula-2. That's very impressive: other small systems require 10 to 100 times more code to achieve the same result. TempleOS is 100,000 lines of C, and nowhere as usable as Oberon. SerenityOS is 800,000 lines of C++, more complete and more complex. One interesting aspect of Oberon is that it was specifically written to be clean and simple enough to be presented in a book (that is freely available). I'm not done exploring this galaxy yet. I don't plan to revive this dead system, but I'm still curious about the concepts and simplifications that make it possible to build a usable system with so few lines of code that every hobbyist could fully understand it. It seems to me that using the right programming language is one of the keys here.
My explorations of the frugal computing scene led me to the Hare language, a sort of modern programming language intending to be as minimalist as C. This community built a very promising microkernel inspired from Sel4 and plan to build an userland inspired from Plan9 on top of it. I'm a big fan already. This makes me understand why I still have difficulties loving Rust as everybody does, and that's refreshing. Their workflow is refreshing too: they are not using another heavily bloated webapp such as GitHub or GitLab, but rely uniquely on emails to work. The SourceHut web site allows lurking and exploring, but serious things go through git, emails and IRC. Who needs more than that to write code, actually? I've contributed my first patch this month, mostly to assess that my setup is matching their expectations. I'm delighted of what I could contribute next.
See you next month!