Sm64ex is one of the native ports of Super Mario 64 to the PC. These ports are based on decompiled code from the Nintendo 64 game, enhanced and re-compiled for PC, so they run light and smooth without the overhead and limitations of emulation. To build the final game, you must supply a legally-acquired ROM of Super Mario 64 so that the assets can be extracted and compiled into sm64ex. Therefore a pre-built version cannot be distributed: the end-user must compile sm64ex themselves.

Using Nix, we can easily build our own copy. This has the following advantages:

• Using flake.lock we'll be able to freeze the versions of all build and runtime dependencies, enabling us to rebuild exactly the same version on other Steam Decks, or after wiping our Steam Deck for a clean install.
• All the built and installed packages will be stored under /nix so it won't alter or interfere with SteamOS and we can easily remove nix and everything installed through it by deleting /nix.
• We can optionally store our nix config and flake.lock in git so we can roll back to any previous version of our nix config and packages.

Install Nix

"Nix" is the name of:

• A programming language
• A package manager
• A Linux distribution

We are going to be installing Nix the package manager on SteamOS, and then writing a config in Nix the programming language. While NixOS is by far the best way to use Nix, I want my Deck to stay on SteamOS because I like the idea of having a Valve-managed standardized gaming appliance.

I recommend either setting up ssh access to your deck from another machine, or plugging your steam deck into a dock with a keyboard and mouse attached. This will be deeply tedious with the on-screen keyboard and touch screen.

First, enter desktop-mode and get to a terminal. We are going to be doing a single-user install, so we need to chown the /nix directory since it currently belongs to root. If you haven't set a password for the deck user yet, then set one so we can use sudo:

Then chown the /nix directory:

Then we need to download the Nix installer script and run it:

Now either re-launch your terminal or re-launch your ssh shell to get your environment variables set up. This will:

• Add /home/deck/.nix-profile/bin to your PATH
• Add /home/deck/.nix-profile/share and /nix/var/nix/profiles/default/share to XDG_DATA_DIRS
• Set NIX_SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
• Set NIX_PROFILES=/nix/var/nix/profiles/default /home/deck/.nix-profile

Start a Nix config with Flakes and Home-manager

We're going to store our config at ~/.config/mynix, so we create that directory and then write a few config files to it:

And then inside there write a flake.nix.

This config sets up home-manager with flakes and enables automatic garbage collection to clean up old builds in the nix store.

Then we need to apply the config:

That's quite the cumbersome command, but after it has been run once it will enable nix-command and flakes so the next time we want to apply the config we will only have to run:

or

It may complain about the user systemd session being in a degraded state. That is because these units were in a degraded state before Nix was even installed. You can ignore this error:

The first run of this command generates a file called flake.lock which stores the revisions for all of our dependencies so if we install this config with this flake.lock on another machine, it will have exactly the same versions of everything.

Install sm64ex

We need to update our config to install sm64ex. To do that, first lets tell flake.nix to load a separate file by adding ./sm64ex.nix to the modules list.

And we need to create a ~/.config/mynix/sm64ex.nix:

But we can't apply the config just yet. The sm64ex package is expecting that we already have a baserom.us.z64 added to our nix store. Legally rip your baserom.us.z64 and add it to your nix store via:

Then we apply the config:

This will compile sm64ex and install it. But there's two problems we can immediately notice:

1. It does not run when launched.
2. There is no convenient way to launch it.

We will be solving these by creating a .desktop file, introducing nixGL, and writing a wrapper script that makes sm64ex launch from within steam gaming mode properly.

Adding nixGL

If we were running NixOS, graphical programs would work out-of-the-box. Unfortunately on other Linux distributions, we need to wrap our graphical programs so they know where to find the graphics drivers. To perform this wrapping, we will use nixGL. To install nixGL we need to add it as an input in our flake.nix, apply its overlay, and add it as an extraSpecialArgs to have it automatically passed into each module:

And then to apply the nixGL wrapper to sm64ex we need to wrap our package install with config.lib.nixGL.wrap in sm64ex.nix:

Apply the config with:

and we should be able to launch sm64ex from the terminal in desktop-mode. Unfortunately, the Steam Deck built-in controls behave oddly in desktop mode, so unless you're using a separate stand-alone controller, you will probably want it set up to run in Steam gaming-mode where the controls behave normally.

Adding a .desktop file

The first step to getting sm64ex running in gaming-mode is to create a .desktop file. .desktop files are small files with a bit of metadata about a program which can be used by programs such as your "start" / applications menu or an installed program list in Steam.

To add a .desktop file to the sm64ex package, we are going to use an "overlay". This overlay will replace the sm64ex package with a new one we create with the buildEnv function. This new package will contain the nixGL-wrapped version of the original sm64ex package and the .desktop file. We will create the .desktop file using the makeDesktopItem function.

First, we need to find a suitable icon. I used a 256x256 PNG from SteamGridDB. Download whichever icon you want to ~/.config/mynix/icon.png. Then we can update our sm64ex.nix to:

At this point, reboot to reload the .desktop files and go back into desktop-mode. You will see sm64ex in your Start/Applications menu under the "Game" category.

Adding a Steam wrapper

To get controls that work correctly, we still need to add sm64ex to Steam. Unfortunately, Steam messes with the environment variables, so we need to make a small wrapper script that ensures sm64ex can find libGL.so. To do this, we will create a package using the writeScriptBin function and install it with our other packages. Update sm64ex.nix to:

And apply the config with

Adding sm64ex to Steam

Finally, we need to tell Steam about sm64ex. Go into desktop-mode and launch Steam inside desktop-mode. Then go to "Add a Non-Steam Game to My Library".

Then find sm64ex in the list and add it.

Then we need to edit the target, so find sm64ex in your Library, right click on it, and go to Properties.

And update the target to our new wrapper script to: "/home/deck/.nix-profile/bin/steam_sm64ex".

Now you should be able to go back into gaming-mode and launch sm64ex from your Steam library. The controls should work correctly out-of-the-box.

Final Versions

Now you should be able to go back into gaming-mode and launch sm64ex from your Steam library. The controls should work correctly out-of-the-box.

Below are the final versions of our config, but you can also browse my full Steam Deck Nix config which includes sm64ex (Super Mario 64), Ship of Harkinian (Ocarina of Time), and 2Ship2Harkinian (Majora's Mask). It also moves the saves to "~/.persist" and loads my configs for each game into place and read-only.

~/.config/mynix/flake.nix

~/.config/mynix/sm64ex.nix

Sometimes it can be useful to build a graph of docker memory usage over time. For example, I was recently working on reducing the maximum memory of a long-running script. There certainly are heavy and complex options out there like setting up Prometheus and configuring docker to export metrics to it but I threw together a small python script, using only the python standard library, that outputs gnuplot code to render a graph.

Usage

Invoke the python script before starting any docker containers. Then, once a docker container is started, the script will start recording memory usage. Any additional docker containers that are started while the script is running will also get recorded. When no docker containers are left, the script will export gnuplot code over stdout that can then be rendered into a graph.

Each container will get its own line on the graph. All containers will have their start time aligned with the left-hand side of the graph as if they had started at the same time (so the X-axis it the number of seconds the docker container has been running, as opposed to the wall time).

If you'd like, you can insert a horizontal line at whatever memory quantity you'd like by uncommenting the horizontal_lines array below. This can be useful for showing a maximum limit like the paltry 32GiB offered by Cloud Run.

Example Invocation

You can also throw tee in there to save the gnuplot file to make manual adjustments or to render in some other fashion:

Output

The output from the above run would be:

And the gnuplot source:

The script