IRC channel logs

<matrix_bridge><Jeremiah Orians> That or it might be fun

<xyhhx>heya gang. i'd like to try my hand at writing a minimal full source bootstrapped distro

<daddy>ACTION :eyes: xyhhx

<daddy>most important question, what language you using for package definitions?

<daddy>and why is it lua

<xyhhx>part of me wants to replicate what stagex looked like earlier in its life (i'm biased, i helped package a few core packages when it was still young and pre-slop)

<xyhhx>ultimately it will be a container host though, so it probably will look a lot like that and/or talos linux

<xyhhx>but i haven't spent much time looking into how other projects do the full-source bootstrap thing so i'm open to other ways too

<daddy>i think probably biggest lesson learned from stagex is to find a suitable point to use for bootstrapping

<daddy>like, stagex is probably gonna split off the original "bootstrap" packages into a "base" package that builds everything in core that can't be built otherwise

<daddy>but treat it more like a cross-compile rather than "building off of the bootstrapped base".

<xyhhx>right

<daddy>then just build your packages using a non-cyclic dependency graph same way stagex, guix, etc. do

<daddy>and dear god figure out runtime and buildtime dependency management

<daddy>i'm still clawing stagex out of the hell that is dependencies and i wish i had more time to devote to it

<xyhhx>yeah idk i would've liked to keep working on/with stagex but uh.. let's say i don't want to anymore

<xyhhx>*anyway*

<daddy>neither does anyone else :>

<xyhhx>:sob:

<matrix_bridge><Jeremiah Orians> Well static binaries solved the runtime dependency problem for the most part; it just that by the time you get to guile and gcc; you end up wanting to build everything in containers (to catch missed dependencies quickly) and using nix/guix rpath solution to solve the rest. At which point, you just ended up recreating Guix.

<matrix_bridge><Andrius Štikonas> eventually you hit a case where static binaries don't work well for some projects

<matrix_bridge><Andrius Štikonas> I think in live-bootstrap we first hit that point with python

<matrix_bridge><Andrius Štikonas> you can build static python, but then I think some modules don't work well

<matrix_bridge><Andrius Štikonas> xyhhx: note that there is a bit of friction between fully bootstrappable and distro

<matrix_bridge><Andrius Štikonas> how do you start the process

<matrix_bridge><Andrius Štikonas> if you want to use distro tools to do that, e.g. like guix does, then you'll probably have quite a big blob that does bootstrapping orchestration

<matrix_bridge><Andrius Štikonas> if you really bootstrap from hex0/kaem or something similarly small, then you won't have distro tools until quite a bit later

<xyhhx>i think i'm okay with the latter scenario

<xyhhx>tbh i'm still very early in my project though and am nowhere near ready to approach the bootstrapping stuff... this is my first stab at rolling my own linux distro in the first place lol

<lanodan>On my side of things idea is to just have the bog-standard stuff included, so like roughly posix with maybe few optional extras when not too much of a hassle (like perl/python/autotools/… are a mess but lua/samurai/muon/… aren't, but they involve quite a lot of code)

<lanodan>(Part of that choice being because live-bootstrap does the part of going all the way for the messy ones, and I got no reason to duplicate that work)

<matrix_bridge><Jeremiah Orians> xyhhx: my recommendation for creating a distro is first asking what problem are you trying to solve?

<matrix_bridge><Jeremiah Orians> Because if the issue is that you just don’t like the names for commands, then it is just a set of wrappers that you can write and be done. If it is functionality that doesn’t exist anywhere else; then you might have a use case.

<matrix_bridge><Jeremiah Orians> For example if I were to create a distro. I would make all package definitions (and build details) live in a database such that one can eliminate the rebuild the world problem in nix/guix while preserving the functional build chains.

<roconnor>Depending on what you mean by the rebuild the world problem, Supposedly the content addressable store mode in Nix solves it. It's just hard to transition nixpkgs to it.

<matrix_bridge><Jeremiah Orians> Because it is a trivial problem in a database but boatload of work outside of one

<roconnor>What do you think the problem is exactly?

<matrix_bridge><Jeremiah Orians> Well if you update the acceptable dependencies, your package definition changes and that cascades from there. Vs having a unique identity that is independent from the hashes.

<roconnor>Okay I see. You want to reintegrate the dynamic binding (of library) into a nix-like ecosystem.

<roconnor>FWIW, I think this is quite a bad idea, but I understand why people think it is a good idea and want to pursue it.

IRC channel logs

2026-09-04.log