The only software tool that is required by our hardware is Linux. The rest of the system stack is entirely up to us, and we’re going to develop our own math applications. Here’s an overview of the choices we’ve made to develop our calculator.

Operating system

Several Linux distributions are available here, including Arch Linux and Gentoo, which we deem light and customizable. After some debate, we picked Gentoo for its even wider customization capabilities and the fact the running Arch without systemd is not too easy. Our co-founder Nicolas is also quite proficient with Gentoo, which helped in choosing it.

The Gentoo system showing the details of the graphics driver.

The drawback of the Raspberry Pi Zero in terms of software is its armv6l architecture, for which there are generally no binary packages; we have to cross-compile everything. Build packages on the Pi itself is not possible because it’s not powerful enough. (Especially for SageMath! And we did try.) Two options remain: cross-compiling programs from an x86_64 computer or emulating a host armv6l system in QEMU on a robust computer. We used both.

Desktop environment

Here we have the famous X vs Wayland debate, which we quickly decided in favor of Wayland and its light compositors. This mainly includes sway or even rootston, the example compositor of the wlroots library.

Our requirements in terms of graphics composition are low, even very low since for now we only use a status bar and a full-screen window. There are situations where having two applications side-by-side can be profitable (for instance to list statistical data on the left and plot it on the right), but we think all of them can be implemented with shared widgets inside the same application.

Our first compositor will probably be sway, because we already know how to use and configure it. We can later get something lighter, or we might as well build a trivial compositor if specific performance requirements emerge.

The hardest part will be managing the graphics card. We’ll come back to it!

Graphical user interfaces

The GUIs that we’ll build are quite simple in comparison with the daily challenges of our computers, but they’re still structured. Directly drawing on a surface with the SDL, for instance, is out of the question.

We need a rendering library capable of laying out widgets and handling events with a high level of abstraction. Choices of common libraries are not many: our knowledge mainly extends to GTK and Qt. To avoid the verbose programming style of GLib and exploit C++ abstractions, we selected Qt. Its IDE, Qt Creator, is also a good tool for all the project members that never used this framework before.

Math applications

Our initial intuition was to build for the calculator a trimmed-down version of SageMath. We’d send it all the computation and solving work, which we definitely don’t want to re-implement. SageMath is a good emblem of free and collaborative software, and we wanted to contribute something in return.

It turned out that the design of SageMath does not work well with our trimming plans. The number one problem by far is the monolithic structure of the library, which prevents us from breaking dependencies to the numerous backends. We could not get rid of underlying tools for group theory and advanced linear algebra… plus, it runs Python 2, so we’d have to maintain both Python 2 and Python 3 on the system.

We still tried it. As expected, the number of complementary modules poses serious performance problems: the shell needed about 1m50s and 170 MiB of RAM to just start. This is really constraining, even more so that only a single instance can simultaneously run on the calculator.

We’re hence studying an alternative, less trivial but more viable: Giac. Bernard Parisse’s computer algebra library is one of SageMath’s backends, but can provide all the math functions by itself since it’s running the HP Prime.

---

Here’s for an overview of our software stack. The applications are still lacking so we’re not presenting them right now, but this will happen later on!