Here is what I did in September. That was another exciting but exhausting month. Sorry for the length of that report.

If you lack context, look at the bottom of this page for an introduction to the cited projects, or refer to previous similar reports: January 2024, February, March, April, May, June, Summer, (September).

On the teaching front, each new term is rather packed, as I do most of my teachings during the first semester (fall+winter). In the first year of our curriculum, I teach C programming. That's a basic but intense course. It starts with a lab on a paper computer to understand how a computer really works internally, before getting into the depth of the C language. This year, I introduced a lab using the shutorial (shell tutorial) in an attempt to teach the basics of the terminal usage. The tool is promising, but it needs more polish. We tried to install it on the students' machines, but it happened before the Install Party, so they still had their windows box only. The shutorial behave weirdly in WSL, and we have some bugs to fix before trying again next year. I should also translate it from French to English and internationalize, so that it can enter Debian. As usual, I see many flaws in my lectures when I teach them, and then change many things. Instead of giving the syntax during the lectures (which is boring, difficult since some students already know it but not all of them, and time-consuming), I added annexes to each lab with the syntax to know. A great source of inspiration here is this C++ book where the syntax comes as a help to the exercises that have the central place. I also overhauled the lecture notes to split them by week instead of by topic. Maybe the day when I'm happy with my lectures is the day when they become useless For the time being, I did not have enough time to say all what I should say each week, and hope to find a better balance next year. Only 2 lectures remain in this class, before Guillaume Didier continues with networking for the end of the semester.

For the second year students, I teach a class called High-Performance Computing, but it's a bit misleading. The goal is mostly to ensure that they keep programming in C for another year because we noticed that they tend to forget their programming-fu very quickly. This class is mostly practical, with only 4 classes and 8 labs. I do speak of performance, MPI and such stuff, but my current thinking on frugal computing forbids me to turn my students into prospective specialists of HPC. Instead, the class became a sort of philosophical discussion on the program performance (the bottlenecks and how to alleviate them) and correction (aka, the difficulties that you must solve when your program becomes parallel and distributed for sake of performance), but with a critical thinking on the limits of the current approach (gigantic machines, with overly complex control mechanism). I hope to introduce material on unbloated software, maybe when we get a prototype of the SmolPhone next year. That's the third year that I teach this class, and I begin to feel home here. We use SimGrid since the first year to study the performance of the MPI program written during the labs, and this year, I introduced a lab on the correction of multithreaded applications using Mc SimGrid as a debugging tool. The intent was merely to get feedback on the tool, but unfortunately my lab assignment was not well-chosen, as the requested application was cyclic, with a possible infinite path that would not occur in real systems, but that breaks our software model checker. It was still an interesting lab, both for us to find some bugs in Mc SimGrid and for the students to struggle with concurrency.

I also teach some research methodology to our second year students this term, with some documents on the bibliographical work and many classes on scientific presentations, but it starts only in October: they need to have something to present in their year-long project to fully benefit of that class.

I do not teach to our third year students who prepare the Agreggation, but I teach pedagogy and didactic of Informatics to our last year students (in M2). During the first half of the semester, I give some methodological advices for the future teaching assistant that they all are, and they visit the teachings of many faculty colleagues who accept to host them. That way, they can see how people do teach, get hints from more people, and think about this important part of their future career. This year, I opened that class. It's now available to all M2 students in CS and not only the ones coming from ENS, and I tried to enroll all faculty colleagues and not only a bunch of friends. We have only one extra student, but that's a good start. During the second half of the semester, we will invent new unplugged activities in line with the student's research. More to come in November.

I had many interesting discussions with a new colleague who was a student at ENS 3 or 4 years ago. That's her first year as associate prof, and I was happy to discuss of the difficulties that you face when starting in that role. The best advice I could give in this case is to not struggle with Powerpoint presentations in your lectures. They are a real burden to create (I used to spend up to 20 hours to build the presentation of a 2 hours class) and they make your class less beneficial to the students. If you write on the board, you're sure that they have the time to write on their paper too. When you speak with no slide behind you, they get less distraction. For the code excerpt and the complex diagrams, you can put them all on a sheet that you print and distribute. It allows the students to annotate the figures as they understand them. I cannot remember why I used to use slides in my lectures when I was teaching in Nancy.

The second (and last) advise is to not make it perfect the first year. Sleeping is important, and instead of over-preparing each session, you should ensure that it will be better the year after. I mean that if you decide to not exactly follow your script during the lecture (which is possible only if you don't have a slides set), make sure to write it down so that next year, that improved version is the normal one. I often improve my classes right after the sessions. And if you don't have the time to, write some ideas on a paper, scan that paper, and save it on your disk where you will find it next year.

On the unplugged activities' front, I remotely helped in the organization of a fall camp for young people on networking. It will leverage several new unplugged activities that were invented during the Facto ANR project. It's a bit inflated to speak about it in my report since I was not really active on that project, but that's still a great initiative that deserves the advertisement. Kudos to Anne-Cécile and all the colleagues who actively took part in it.

On the Mc SimGrid front, we wrote and submitted a paper to the SAC-SVT conference with Mathieu and Thierry. We present our adaptation of the ODPOR algorithm to traverse the reduced LTS in random order, to avoid being stuck in uninteresting parts of the state space. We also present our first algorithm to find the critical transition of a given failure. It wasn't an easy task as the paper pitch was not clear to us at first, but I think we managed to write a rather interesting paper, which summarizes our work rather well. I now hope that it will get accepted. If not, we'll have to rework the paper again and again while we're already on the next thing with Mathieu: our feeling is that we did not find any wild bug yet because of the tool performance. So we started thinking about a parallelization schema that would be efficient without complicating this code that is already hard enough to read.

We wrote an internship proposal on the decomposition of dependency relationships. We think that it could be another interesting approach to improve the exploration efficiency, but it was not picked by any student. Maybe next summer, if we don't change our mind in between.

The last thing on that front is the publication of this paper, which reuses the technical infrastructure that I wrote with Mathieu and Emmanuelle for our MBI paper on the evaluation of tools that search bugs in MPI programs. I'm a bit sad that the authors decided to remove SimGrid from the list of evaluated tools when they added more benchmarks to the base. This makes our tool invisible to the readers, although the initial paper was showing that it's a very strong candidate in this category. I contacted the authors and really hope that we'll make it back in the journal version of that paper, if it gets published. I don't care being a co-author, but it's very important that Mc SimGrid gets the publicity it needs. We need users to get useful feedback, and to eventually find a wild bug.

On the regular SimGrid front, I released a new version of that software. I had to, to organize the lab on Mc SimGrid with my students (see above). SimGrid v3.36 got released on September 9, i.e. 536 years after Anne of Brittany became a duchess (I love stupid release names). The previous version of SimGrid was almost one year ago, so the git was full of good changes to release. I still should fix the bug reports and merge the pull request that we have on that software. Sorry, people.

Guess what? The SimGrid4 paper got refused yet again. It's now at least the third time that we have to profoundly rework this paper because the reviewers don't like our presentation and our contribution. They recognize the usefulness of the work (otherwise, I guess we would not resubmit), but they always want us to change things. It lasts since the summer 2023 already, and I feel bad because Henri said that such a paper would be interesting, but very hard to get accepted. He was right... This time again, the reviewers are right, and the requested improvements will really make the paper better. We even discovered some flaws in the tool documentation from their remarks. Let's hope it's the last time Fred and Henri have to rework this paper before it gets accepted (and I'm thankful to them for taking care of it).

On the TANSIV front, we still plan to submit a paper to the EuroSys conference. That community loves experimental results, so Léo worked hard to get all the planed experiments working. Of course, some of them showed unacceptable limits to the tool accuracy, so Louis worked to reduce the buffer bloat problem while Léo proposed a nice optimization to improve the tool performance, making it possible to simulate gigabyte networks. Earlier, Tansiv was stressing the test computer so much that it led not only to slow experiments but also induced some noise in the results. As you can see, I did not do much personally. I hope I'll manage to participate decently to the paper writing next month.

On the SmolPhone front, we found our candidates to the engineering positions. Victorien Elvinger will be our software engineer, starting probably in December or maybe in January. I'm so glad we found him because he is a very strong candidate and I'm sure we will do incredible things together. On the hardware position, we have two very strong candidates, but we are still waiting for the security clearance. Such procedure takes time unfortunately, and you always have the possibility to get a rejection. The good point is that it's unlikely that we get two rejections, and both candidate are strong. Of course, the second person in our ranking knows the situation and could decide to leave for another position of the security clearance takes too long before the first person in our ranking to get rejected, but I'm still confident that it will work. I'm so eager to really start that project now. I want to have a real device in my hand.

In the meanwhile, we wrote an internship proposal with Olivier Barais, and it got selected by Aurel Hamon. He will work one day per week during the whole year, exploring the alternatives for the cloud rendering of the web pages. HTML5 is too large for the SmolPhone, but it's even too large to be the only alternative out there. Our hope is not only to design a technical solution for the cloud rendering (which is not exactly a new scientific contribution), but also maybe a better/simplified formalism to represent textual information (something between Gemini and HTML5), and to interact with remote applications (between HTML2, Google Forms and Mosh). Or something. We are still studying the bibliography, so we don't know yet what contribution we target.

After 7 years of usage, my FairPhone broke, and I had to buy a new one. I picked a simple Galaxy A5, and hope to experiment with PostMarketOS on it. The camera of that device does not work with that system, but it's still damn exciting.

On the frugal computing front, I discovered a great presentation (in French) about post-growth world. In short, the author claim that progress was seen to be linear, and going toward efficiency and performance. But unfortunately we reached the point where increasing efficiency only comes at the price of reduced robustness. He claims that we should now aim at increasing the robustness of our systems, even if it comes at the price of a somewhat reduced efficiency, because compensating the lack of robustness in our world becomes too expensive (in terms of energy and efforts). It's very interesting, but rather hard to apply to computer science. He makes a point about the TCP packet being one approach to the system robustness, but it's completely wrong (the guy is a biologist). Packet switching was invented to improve the efficiency of the link usage, that was notoriously bad with circuit switching.

Fortunately, Anne-Cécile pointed me to that great article of 2013 making a similar point, with a great application to computers this time. The subtitle reads "Esteem for efficiency should be tempered with respect for robustness", and the author imagine new research on algorithms which would not aim at finding the perfect algorithm for the perfect machine, but to find robust algorithms that could (often) succeed on faulty machines. Very interesting. We were thinking about the kind of processor you'd need for the smolphone to remain 10 or 15 years, about how to design the hardware to ensure that it will gracefully age, but what if the solution was to instead make the software robust to the aging and faulty hardware instead? This is so inspiring!

On the open-source front, I did not do much beyond merging some pull requests on the po4a software. Bugs accumulate as usual, so if you feel so, I'd love to see your pull requests about it

Ok, enough. Sorry for the length of that report. That's the problem when you like too much what you're doing.

Context: The projects I'm working on these days

SimGrid is a simulator of distributed systems developed by a team of friends since 2000. It takes a distributed application (written in C++/C/Python using our dedicated APIs or in C/Fortran using the MPI standard), and it executes the application on a fast but realistic network simulation. It provides timing and energy consumption forecasts, allowing one to prototype, study or profile distributed systems in a wide range of settings, Over the years, it grounded the experimental sections of 630 scientific articles around the globe. This paper gives a somewhat outdated overview of the framework, but the replacement is still under review.

Mc SimGrid is a software model checker (SMC) embedded in the SimGrid framework. It exhaustively tests the applications that can run on top of SimGrid, exploring all possible orders of events to find bugs that only occur after a specific sequence of events. In some sense, it's related to fuzzing that tries to feed the application with random data to find bugs, but instead it exhaustively "randomizes" the events' scheduler. More info in this paper. That's the context of Mathieu Laurent's PhD thesis, co-advised with Thierry Jéron. We work on improving Mc SimGrid to eventually make it a widely usable tool. To that extend, we first aim at finding a wild bug, i.e. a bug that exists out there in an application rather than a synthetic bug that we add to test our tools.

TANSIV is a contraption interconnecting virtual machines with a simulated network to study arbitrary applications. The key difficulty is to synchronize the time of the virtual machines with the simulated one. The first challenge is to precisely pause and restart virtual machines, which is easy in the slow emulated mode but much harder in the fast hardware-accelerated mode. The second challenge is that the simulated time is discrete, but the wall clock of the VMs is naturally continuous. This is the PhD topic of Léo Cosseron, co-advised with Louis Rilling. More details are given in this paper.

SmolPhone is an action research on digital sufficiency as defined in this article. Other relevant keywords are low-tech and empowerment in IT systems. Its practical aspects consist in designing a sort of long-lasting smartphone. The goal is not to optimize a typical smartphone but rather to explore unusual hardware & software architectures. I take this as a journey to reconsider the way we design computing systems. Some more details are given in this short paper. Amaury Hamon is a master student co-advised with Olivier Barais (and a bit with Simon Rokicki too).

po4a is a free software to ease the maintenance of documentation's translation. It makes it it easy to track the modified parts in the original documents so that translators can update their work when the documentation changes. Largely adopted by the community, it is now a key component of several renowned open source projects including Debian and F-droid. This project is on slow development/maintenance-only mode these days. I try to keep up with the request of the community, but I really need the help of the existing power users to be somewhat reactive.