IRC channel logs
2026-06-20.log
back to list of logs
<fossy>to add to some of the previous discussion, i find comparing shpack and live-bootstrap along some of the dimensions outlined here is not particularly sensible <fossy>clearly, shpack and live-bootstrap have different aims/goals <fossy>so it's not fair to criticise one over another's goals <fossy>as to the term "full system bootstrap", you can have whatever definition you like of it, no one really uses this term <fossy>we have "full source bootstrap", which shpack would count as <fossy>but e.g. shpack does not necessarily have the goal of solving trusting trust, while live-boostrap does; this does not immediately mean live-bootstrap > shpack but that they do different things... <fossy>but one of the points of live-bootstrap is to show you can build an entire modern software stack, above the firmware level, using nothing but truly source code (defined as software in the preferred form for modification), which obviously precludes the use of pregenerated files or an existing kernel <fossy>clearly this is not the goal of shpack <fossy>speed in l-b never comes at the cost of these other goals, whereas shpack has taken a different analysis -- there is nothing wrong with this <roconnor>What's the goal of shpack? I'm mostly familiar with live-bootsrap and its lesser intances in nixos and guix. <alganet>I don't know what are the stated goals of shpack, but I know it fits the niche of auditable reproducible builds <alganet>you have something you want to built, and you want a sensible control of the supply chain, shpack fits <alganet>as many have said before, alternatives are good for everyone and variety of thinking and goals benefits everyone <alganet>I think there's a path of discourse in which we still praise live-bootstrap goals in purism as remarkable and still allow other approaches to exist <fossy>11:53 <stabbles> It'd be nice to drop the dependency on Linux, but personally I do not have clear use case for it. The target audience is HPC users who do not own hardware and do not have root privileges. So they have to trust the kernel, drivers, firmware, and sometimes communication libraries anyways. What it would buy them is bootstrapping a recent glibc with <fossy>11:53 <stabbles> certain performance improvements of libmvec if the system version is old. The next experiment I wanna do is drop bwrap/chroot/unshare/namespaces in favor of a Linux Landlock sandbox to just restrict filesystem and network access. That way you could bootstrap a recent C/C++ compiler toolchain/runtime while still using system binaries. That doesn't <fossy>11:53 <stabbles> mean I would rule out eventually looking into running it on bare metal, it's just not a priority. <fossy>really, i want to (representing l-b) push against the idea that this is somehow a competition here <aggi>fossy: again that's misleading the audience <AwesomeAdam54321>Hi everyone, I would like to give a small update on the MIT Scheme bootstrap <AwesomeAdam54321>I've postponed trying to get the source->bytecode compiler (SF) working for now, so I'm porting the runtime tests to SRFI-64 so that I can run them in both mit-guile and mit-scheme <AwesomeAdam54321>Out of the 17 test suite files I've ported so far, 10 load successfully (147/159 tests) <AwesomeAdam54321>I'm hoping I'll be able to port the necessary macros to syntax-case and improve compatibility, to eventually get the SF compiler working. The native-code compiler looks far more complex in comparison