On plant - update 1

A quick reflection on what plant wanted to be:

In 2015 I started exploring the reliable creation of a live CD system for an application, which lead to thinking about the concept of an Operating System based on Guix, which rapidly diverged from Guix.

One of the main ideas was to provide building blocks instead of a monolithic approach to the core (you will find that you can modify Guix to a decent amount for an application, but some parts are designed in a way that (last tested in 2017) you can’t add/override/etc). Furthermore I knew I wanted to test out ideas which would not work with the way Guix as a group works. While Guix and Nix allow yourself to be pretty independent from a central group, in practice you rely on their flow of work, their decisions, the way they upgrade and their infrastructure. Which isn’t bad. I just want to test more decentralization, but made the (decision / mistake) to rely for that part at that time on a network which still needs some tweaks to be ready for this. Furthermore I disagree with some decisions which justify the existence of certain kernel flavors based on interpretation of blobs, licenses, how hardware works, and what some people tell others who ask to run this system (just buy a new/supported device is not an option for many people). Next I dislike the way updates are handled, but we all have to make compromises in what can be maintained, security updates handling, etc. I have my own ideas, which I guess/hope are not that new but just encode certain expectations and contracts. Modularity was also a big goal. Did I mention this should be a generic package manager and also operating system builder through templating and inheritance of the language used (maybe you don’t know that Gentoo, Guix, Nix, etc are package managers). And much more.

I am going to extend on these points as I go through old stacks of papers and digital notes I assembled, but not all of them right now. This is the first copy of nightly notes I’ve started again after a long break on (publicly) thinking about package managers. This one is from 4 days ago. Don’t take this as finished, technically correct, or whatever. It’s just to try and start documenting more publicly what I do. No concept diagrams for now included. It’s mostly written without much editing, and I hope to construct a more long-form technical preview once I get to a point where I can start working on it.

plant should be a set of concepts, protocols, and idealized package guidelines. My version of it would then mean I get to use an implementation of it, for example in Common Lisp. Maye the core could be in C. Maybe it could be entirely Lisp. The goal is just that recipes and binaries can be exchanged. If someone ships an extension to read ebuild-like syntax to build a subset of Gentoo with this? It’s okay. But there needs to be a native package format first. I’m okay with NetBSD, so I don’t really see a future in building yet another Unix-like system (which doesn’t mean that infotropique OS/core is abandoned). When implementations can produce bit by bit the same output for builds, this should work. build-system etc can all be extensons people get however they want them to get (implicit: obtaining and depending on them is managed and documented for packages). I think this is similar to how guix conceptually works, but making all of it hackable (tricky for reprpducibility, so future compromises might apply), without any strong opinion on what plant should look like or run. Even the way you use the network, which network, will be up to you. i2p? tor? “clearnet”? GNUnet? plant doesn’t care. Trade recipes, no binary builds on a central server, … Groups can and probably will form to collaborate, but t really should just be well documented to give everyone what they want it to be. This doesn’t have to contradict reproducible builds, it just has to work differently (and makes it harder).

lose notes, incomplete,…:

  • peer-to-peer exchange
  • build-servers can be setup and binary repositories (of build artifacts) shared, no central default ones
  • consensus tools in addition to human interaction to agree on source locations, etc
  • get rid of central source locations in some way (better documented in older notes)
  • no central registry, build your own etc

  • language (nice to have list):

    • can override and inherit
    • small bootstrap
    • allows embeded language specification
    • no sideeffects
    • portable
    • working with the AST
    • which means
    • Lisp
    • Scheme
    • Common Lisp
    • Clojure
    • hygenic macros