Immutable Root Linux
Brief:
 Immutable Root Linux is a project that aims to provide atomicity and better security to the Linux desktop experience. We accomplish this by making as much of the host OS read-only as possible, and requiring users to Bring Their Own Apps.

 I have a problem with Linux. In Linux, a user's applications, the Linux kernel, and the userspace system programs are all managed through a package manager. As such, installing software requires permission to modify critical system files - permission to write to every file on the system as root; this can be mitigated, for example, by limiting when a user has escalated privelages through sudo (%wheel ALL=(ALL) NOPASSWD /bin/pkgmanager), but still allows users to install possibly malicious software packages on purpose (e.g. sudo pkgmanager install file:///home/evil/secret-backdoor.pkg.tar.xz) or even execute arbitrary code as root if such a vulnerability exists in the package manager.

 As long as user applications and the rest of the operating system are tightly coupled, giving a user permission to install software is fundamentally equal to giving them root access.
 So, how do we fix this? One approach is to leave everything as is, and take the stance that users should not be installing unauthorized software anyways - only system administrators can exec /bin/pkgmangler with root privs, /home is mounted with noexec.

 This approach may work for the big enterprisey shops that Unix was originally used for, but is less practical for a user's desktop PC.

 Other major operating systems approach this problem by packaging applications into a mostly portable format - .exes or .Apps. These applications can be mostly self contained, the application can just be launched by exec'ing the app file. The equivalent in Linux would be compiling software statically, or using Appimage.

 Appimages are fine and all, but they bring with them the problem of Windows .exes - no update mechanism, and no sandboxing.

 Excluding Appimage, there are more-or-less two other per-user package managers: Snappy and Flatpak. Both have a central repository, sandboxing, and a central update tool. Snappy has a wide variety of apps available, but is heavily tied to Ubuntu Linux. Flatpak, on the other hand, is distro agnostic and used in the Fedora Silverblue project, which Immutable Root draws some inspiration from.

 Flatpak was the obvious choice for this project.
 At this point, a normal person might just install Flatpak in their distro of choice and be done with it. I am not a normal person; I wanted something more.

 At this point I decided that, if a user's apps were going to be decoupled from the rest of the OS, we could turn the OS into a kind of immutable monolith - something that the user should not worry about changing, or even something they can change. As simple as it would be to just not give the user root privileges, the fact is that there are probably tens of privilege escalation bugs in our base operating system, besides the fact that some tasks (running xorg, updating the kernel, updating the system image, starting and stopping services) are definitely going to require root.

 I took the nuclear approach - the operating system is immutable, unchanging; attempting to change the running OS state will lead to a cascade of errors across the OS, loading a new OS image requires a reboot, configuration must be applied per-user when applicable. Root is stored on a squashfs image, only files in /etc and /var are mutable.
 That's the current state of Immutable Root; a static squashfs root image and the infrastructure to mount it. Our build process is largely automated. It's up to the user to bring their own apps. We provide a Flatpak runtime, but compiling software from source is certainly encouraged.

 In the future, we'll definitely do something different. For example, not all of /etc needs to be writable - we could make only a select few files writable, for example. Or we could mount the read-write partition with noexec, and then bind-mount files that need to be executable - /etc/runit/{1,2,3,ctrlaltdel}, /etc/sv/*/run, and so forth. Or we could move from using squashfs images to read-only btrfs snapshots. All of these are valid options, and probably options that we will explore as the project evolves.
 Immutable Root project files are synced semi-regularly to ir/, but do not include the compiled squashfs images or rootfs directories. My tiny little webserver only has so much storage, alas.