Other reports for 2024: January, February, March, (April), May.

This new status update attempts to summarize my professional activity for April. It was a mixed month, active on Mc SimGrid, and on the SmolPhone with some wider thinking about frugal computing. If you lack context, look at the bottom of this page for an introduction.

On the teaching front, I went into the gory details of C++, with a lot of information on the implementation of C++, as I think that you need to understand what happens under the hood to full understand C++. So we further spoke of symbol mangling to understand static linking, of vtables and memory representation to understand dynamic linking, and of (co-)variance rules to understand how overriding, overloading and overwriting play together in this language. At the end of the day (and in contrary to what I wrote last month), I'm not completely satisfied of my lectures this year. The reason is that I spoke too much of how C++ implements all these mechanisms, but not enough of why these mechanisms exist, and how to organize your code using them. Because of a agenda conflict with a homework in the statistical class, I had to greatly simplify my own homework on the expression problem. At the end of the day, I fear that the students will understand the internal behavior of tools that they cannot use properly. I will try to improve this with the last 3 lectures by focusing on the use of this language to design solutions.

I see a recurring pattern about my teachings here, where I'm very happy of what I've said during the lectures, until I get a glimpse of what the student understood, at which point I'm much more frustrated, and promise to improve the year after.

On the administrative front, I organized the jury to distribute PhD grants to some of our students, and tried to conduct some prospective thinking about the future of the department. That's definitely not the worst part of this job, as we are really in a good position to tackle our challenges, that are thus rather exciting. ENS Rennes is a great institution, and I know how lucky I am to have it as an employer.

We were rather active on the Mc SimGrid front, but Mathieu did much more than I did. We tested several applications within sthread to search for a wild bug in synchronization primitive misuse (as defined in this very good article even if we use a very different searching approach), but so far we only found bugs in SimGrid itself. As usual, testing a research prototype in the wild raises many issues and corner cases in the tool itself. I fixed most of the issues found during these blind exploration sessions, searching for a bug that may not exist in codes that we do not know.

We found some interesting traces, but they are so long that we do not know for sure whether it's a bug in the tested application (the teaching code of our colleagues in Grenoble), or yet another bug in Mc SimGrid itself. This led to a very interesting line of thinking about reducing and simplifying the counter example traces, to help the operator to understand and identify the bug. Mathieu had very interesting proposals about it, and I think that it could lead to a good paper before the summer.

Mathieu also implemented an augmented version of the ODPOR reduction (that was implemented by Max last year during his internship) to enable the Best-First Search (BFS) exploration of the reduced state space. This means that the exploration strategies implemented by Mathieu during his master internship are now usable with ODPOR, which offers a much better reduction than other DPOR variants. He also implemented a new strategy reducing the amount of context switches, as this paper from Musavati seem to imply that it's a good idea. This line of work is a bit on the back burner right now, as it is very difficult to present in a paper a new set of tricks to reduce the state space and traverse it smartly without any Wild Bug to present along. Our hope is that the work on the trace reduction techniques will help us identify real bugs, that could then be used to justify our reduction and exploration techniques, that we use anyway while searching for more interesting traces.

On the regular SimGrid, some more bugs were reported by the users, but this month I was really reactive on this point and fixed the issues as they got reported. A new user from Russia came up with a nice PR on github fixing a small bug and providing a nice example. Great! Another new user from the University of Chambéry reported some bugs. Luckily, they were rather easy to fix, so I'm glad he helped us improve the code base. And finally, we had another PR improving the Task API that is still rather young and certainly needed some polishing. It's really nice to have such external contributions to the project. They are particularly welcome these days when I don't easily find the motivation to improve the simulation core of SimGrid myself.

We had very interesting prospective discussions with Louis about the future of the TANSIV project, preparing the suite after the defense of Léo in late 2025 already. We envision the ability to apply model-checking on arbitrary applications running in Linux containers interconnected through TANSIV and controlled through several interception techniques. I love the idea that it'd be possible if we put the needed time, but I'm not sure of whether we will actually do that. I already have so much to eat in my plate that I'm not sure I'll find the time and energy it would take. There is a student who may do an internship on lightweight interception of arbitrary applications with me, and if she happens to pick my topic, then I could eventually work on that nice topic, will see. This is one part I like in my job: prospective discussions opening the path to crazy yet probably feasible ideas. Too bad that I cannot pursue all of them, I'd really like to further collaborate with Louis even after Léo's defense.

On the SmolPhone front, we did not find any student for the two internship topics posted last month yet. That's not good, as the chances to recruit someone for this summer greatly reduce with time, but that's life. I think that about one third of the internship topics I publish get selected by a student. Maybe I suck at recruiting, but I think that it's about the same story for my colleagues.

On the funding side, we had our final meeting with Inria officials about our "action exploratoire", and we are funded! We are allowed to recruit 2 engineers for 2 years each, one on the hardware part to finish up the first prototypes and the other one on the software side to ground the applicative framework that can run such hardware. That's really a great news, as it will really help to ramp up the project!

On the software side, we submitted a short paper (very short: 3 pages only) to the 'ICT for sustainability' (ICT4S) conference. The goal was to study the feasibility of the smolphone, in particular the tiny-small design where most of the applications are run on a tiny microcontroller with low power and advanced power management abilities, while more demanding applications are sent on a small Pi Zero processor running Linux. We ran some measurements of the consumption and switching time between usage modes on Aloïs first prototype. The results are encouraging, with many days of full-time usage on a battery as small as 1000 mAh. We need a real prototype to get definitive numbers, because it greatly depends on how often the MCU goes to light sleep during typical operations. So far, the components are measured separately, we did not measure the low power 4G Cat1 modem that we got, and we don't have a working keyboard yet. If that paper gets accepted (the notification was expected on April 30. but is a bit late when I write this), Aloïs will go to Sweden in June to present the corresponding poster.

Now that we get confident on the SmolPhone hardware capacities, I thought further about the kind of software I'd like to have on this material. It lead me to more explorations on the frugal computing front. I explored DuskOS, a minimalist OS intended to run on tiny devices while being maximally useful to its operators. Forth languages do not have users who passively use the provided system, but only operators who adapt their tool to their needs. What a great idea! It is technically very cleaver, with a system to compile into machine code the scripts written by the operator. DuskOS can even use C code as an input. It results in a rather efficient but highly dynamic system where you can redefine everything. Here is another great presentation (in French) about the advantages of Forth for frugal computing.

The graphical interface is typically not the strong point of Forth systems, because they are systems where everything is rebuilt from scratch, and the GUI is one of the last things you had to such a system. Other Forth dialects such as Factor or Minos provide a GUI, but AFAIK it's not the case of DuskOS yet, even if you can already draw on a canvas. DuskOS provides textual UI called Grid, but I could not get it to work for me yet. I hope that it's inspired from the Oberon Project, will see.

The biggest problem with Forth is its syntax, based on the Reverse Polish Notation (RPN). I'm not a designer, but it seems challenging for non-tech savvy people. At some point I got fed up with geek systems and dreamed of really accessible application development solutions. The most frustrating point is that such system used to exist: HyperCard was a simple system to write small interactive and graphical programs. It could be used by anyone (not just programmers) to built tailored mini apps. Teachers would make educational apps, coaches and fans would record basketball statistics, artists would make demos, and secretaries would use it where they use excel these days: for almost anything.

I was really delighted to discover Decker, a modern heir of HyperCard where the application is a deck of cards, each containing interactive controls. It comes with a powerful yet pleasant scripting language called Lil. It's inspired from Lua with some nice improvements to interact with the cards. Since the data can be presented in tables as in a simple spreadsheet, Lil provides SQL-like queries and vector-oriented operations to interact with these data. New widgets can be defined as if they were a card in the card, and the resulting contraptions can be shared between users. But the best feature is certainly that in every Decker application, the edit mode in which you can adapt the application is always one keystroke away. Decker is not a perfect match for the SmolPhone since it does not target embedded systems at all and since it "encourages embracing a sketchy, imperfect approach" with a ditherpunk aesthetic, but that's still very inspiring. It's a great match for the demoscene, but I'm wondering whether we could build a Decker-like application on the technical foundations layered by DuskOS, or something. Vector imaging would be great too, possibly with a mini-PostScript as textual representation.

The idea of operators instead of users also led me to think again the applications I want on the SmolPhone, beyond the fact that they should be easy to adapt and modify. I even have the name for one of these programs: Egeria was supposed to be a lightweight documentation browser, a bit like Zeal but with markdown instead of HTML5. Now, I want to make it more operable and thus more useful. Instead of only looking for the existing doc, it should allow efficient note taking, probably along the Zettelkasten method (other link). Mepo is an highly scriptable GPS application, made by the people behind SXMO. Matrix could be used to access any chat protocols from a remote server and convert it to a simpler protocol that could be served on the SmolPhone. Gosh, that's too much thinking. I go around in circles, but fail to even start anything useful!

I did not do anything on the open-source front. The co-maintainer packaged the latest release of quilt, and I feel very thankful. Widelands is still to be packaged (I did not resize my partition yet), and bugs are accumulating on po4a.

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 forcasts, 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. Aloïs Rautureau is a master student working on the quantification of the tiny-small design where we leverage two chips on the same board to finely adapt the energy consumption to the application needs. He's co-advised with Simon Rokicki and Joseph Paturel.