During December of last year I had some time to devote to my own company’s projects. I have a couple different ones brewing in my head that are actually rather large and difficult to narrow down. One big hard part to ideation is getting to the essential parts so you can actually create an acheivable plan. These projects are actually pretty tightly bound together, or at least could be. Those projects are:

  • Establish a QMS for distributed teams.
  • An integrated self-hosting platform for normal users.

Both are very concerned with security and privacy. Both are very concerned with establishing provenance.

Immutable systems#

Most of the month was spent continuing to experiment with Nix. I really like the idea of a functional system configuration from the perspective of creating exactly the same system every time you build it.

I’ve struggled getting theory into practice though. Nix and Python don’t play well together at all and a lot of what I do leverages Python tooling at least. There have also been a number of times where I can get a decent number of the individual things I need to work working, but when it comes to putting them all together in the same environment I run into annoyances that mean my whole process has to be scrapped because it just won’t work that way.

I tried guix for a while as well. I found it worked a bit better where it works, but there’s a whole lot of stuff that doesn’t work and would have to be built by me. I actually did start my own channel and may continue with that as well. The two systems can work together.

I like them both. I really like that with guix you are using an actual programming language and don’t have to rely on “extraBuiltins”, which I wasn’t able to get working reliably with nix as a package manager (worked OK on NixOS though). There’s a lot more activity with Nix, which is good because it means there are more things you have to work with–but it’s also bad in that you end up going down a lot of dead-ends and projects in indeterminate states. One discouraging thing with Nix is how much you are encouraged to abandon the stable release as insufficient to get stuff done with. There’s also an awful lot of stuff in the released nixpkgs that just does not work (such as the trezor-agent package). I did not run into these problems with guix, but instead run into the problem that there’s just a lot more you have to write on your own instead of hoping to find someone else has and are still maintaining it maybe. I also ran into the problem that the trezor-agent in guix is too old for the firmware–so that it actually works and builds correctly and in a completely reproducible way isn’t that much use.

The Nix devshell flake by numtide is pretty cool. It seems to work quite well if the flakes you are using it with do. This same developer also makes flake-utils.

I think I like the Nix design better primarily because guix tries to be too “pure”. I don’t necessarily think it’s a great idea to write shell scripts in lisp, but that’s what you are encouraged to do. This does make the build programs more composable maybe, but I think the Nix idea of just having the build daemon use your standard shell commands is more practical. I’m still very much learning both though and will probably continue to.

When I decided to install one of them on my desktop though I did decide on Nix. The primary reason I did that though is that I thought it would be easier to get some of the programs I need but don’t actually care about to work. Namely Slack and Teams with desktop sharing and all that nonsense. These programs work OK on a normal Linux computer but these are different beasts.

guix channel authentication#

One really neat thing in guix is their channel authentication protocol. It’s meant to ensure the channel contains fully authorized code only. It leverages git commit signatures with gpg. I can see this system being very useful in a development environment governed by a QMS. The pattern seems pretty universally available and sufficient. Another technology I’m looking at does similar things but in a way that binds the signature to the user/device combination rather than just the user–I’m not sure it’s a good idea to have say an employee tracked around by what device they used within the permanent history of the codebase. That tech is radicle and it’s meant to serve as a forge rather than a workstation node perhaps and in that regard maybe the approaches would be complimentary.

Jupyter Book 2#

During this time I also gave Jupyter Book 2 a chance. They made the hard switch from Sphinx to myst as the backend engine. This was actually a pretty nice set of improvements and made the build process simpler. It also worked really nicely in Nix without linker errors and other Nix/Python issues.

Unfortunately all the plugins that worked with Jupyter Book are incompatible. There’s no plantuml plugin for the myst version that I could find. The mermaid integration is cool, and some things it does better than plantuml, but it isn’t a sufficient replacement. They have different sets of diagrams they are capable of rendering. I need my plantuml and other stuff. I’m also a big Python user now (event though I’m not a big fan) and so the lack of sphinx is actually not great for me.

So I’ve gone back to version 1. This means when you use jupyter book create you have to edit the requirements.txt accordingly because it doesn’t.

Cross Platform#

One major component I know this project is going to have is a client program that makes some setting changes on the computer its on and provides an interface to some of the activities the user will perform. I want it to work on desktop and mobile and I don’t want to have to write a bunch of versions. So I’m on the hunt for the right way to do that for me. Some ideas:

  • Slint + rust or something like this.
  • React (Native)
  • Kotlin Multiplatform
  • And I found this BeeWare thing for Python I will probably check out.

I developed on mobile before but the build environment was this custom mostrosity created over a millenia by the company I was working for. None of that applies outside that environment. So this is a brand new thing for me and actually very few of the tools I know have helped me much. I did succeed in using a docker image to build the Slint/rust example and push to my phone though.

Trying to form a foundation#

Part of the issue is that at home I’ve just treated my computers like appliances. I haven’t really spent much effort on them in a long time. I install a version of ubuntu and call it good. Keep some of my important stuff in private git repos. Even time on my own I have spent on learning stuff relevant to the projects I was working on at the time. It helps me learn very fast anything new I need for the person or team I’m working with but I don’t have my own custom environment that I could have had if I’d been developing one over that same period. I have to build it all up from first principles. This is good because it gives me a lot of design-space freedom, but it’s also bad for the same reason. Sometimes things would be much easier if there was a lot less choice.

Some of my choices are really slowing me down right now. Trying to base this stuff on something like Nix or Guix for example. It’d be a lot easier to just continue throwing my environments together as-needed rather than build up a thoughtful approach to it. I’m hoping it pays off in the end after I struggle for a while and I’ll be rewarded with consistent processes and tools that others will want to use so I can get some help and with this monster of an idea I have. Hoping also that my experience to date helps me navigate the many new things I’m going to need to learn.