IRC channel logs

2026-06-08.log

back to list of logs

<matrix_bridge><Jeremiah Orians> An alternative bootstrap hardware starting target if one against 8-bits and wants something very unlikely to be compromised. https://bogdanthegeek.github.io/blog/projects/vapeserver/
<aggi>real fascinating, nonetheless 8/16bit might remain relevant for hardware bootstrap itself
<matrix_bridge><Jeremiah Orians> Well, yes. Diversity in options is what would ultimately make it impossible for the whole to be compromised. (As there only needs to be a single honest bootstrap to ddc against)
<aggi>the configurator/steps build system crossed my mind again, which got another advantage
<aggi>if a complete system-integration for a bootable development host got migrated to it
<aggi>this keeps the whole base-package set (in my case the c-toolchain system profile) distribution-agnostic
<aggi>it's not necessary then to choose between any of the complexity with guix/gentoo/etc.. to main those critical base system components
<aggi>*to maintain
<aggi>too this configurator/steps system is fully bootstrappable, and enables reproducible-builds
<aggi>there is no need almost to transition to any other build/packaging system
<aggi>i will however think about a simple dependency tracking mechanism
<aggi>adding a depends metadata file to individual steps/ - noting compile-time depends inside there - could do the trick
<matrix_bridge><Jeremiah Orians> An sqlite database file is probably the one which could enable multiple applications to spawn from a shared knowledge set
<aggi>then hacking a little script which parses all steps looking for the depends metadata, and generate a manifest from this to build steps/ in order these are needed
<matrix_bridge><Jeremiah Orians> Then it just becomes a lookup
<aggi>because i've got ~500 ebuilds here, willing to move those into configurator/steps
<aggi>well, yes, sqlite is an option too (i've already ported it for support with linux2/tinycc/static-linking)
<matrix_bridge><Jeremiah Orians> And tcc should be able to build it without too much trouble
<aggi>since you mention it, sqlite had been a little problematic, i couldn't use it's latest version
<aggi>and it's things like this, why the re-integration for a full release is important
<aggi>too, there's other relevant packages which got blocked, bind9 for example
<aggi>meanwhile all distributions ship latest versions of say sqlite, bind9 already - which aren't compliant with the last remaining c-toolchain integration here
<aggi>things like __thread are a burden, nptl is working with linux2.4 here, and i kept track of all builds which actually need it (it's optional hence)
<aggi>but the __thread language extension inside C-standard remains problematic
<aggi>and _all_ major distributions are trapped inside it already
<aggi>which isn't a problem once you've got and don't bother with depending on c++/gcc/llvm/clang
<aggi>but if free software shall remain portable towards and with different pure c-toolchains, then this battle is lost almost
<matrix_bridge><Jeremiah Orians> The battle remains won, as long as a single chain remains
<matrix_bridge><Jeremiah Orians> More links take time and more people working on it
<aggi>thing is, i had needed a confirmation from some university in germany for example, or any HR office
<aggi>that's why i applied as laboratory engineer at some, with an offer to prepare for some lectures
<aggi>but it's all been denied, ignored
<aggi>i've too succeeded to salvage some older TeTeX implementation, remaining portable with tinycc
<aggi>since i tried to keep in mind a few pieces which i actually needed when studying
<aggi>then again, why would anyone bother with a 20year old TeX implementation?
<aggi>try explaining this to some HR office
<matrix_bridge><Jeremiah Orians> No justification needed. Who does decides.
<matrix_bridge><Jeremiah Orians> HR doesn’t give a fuck as long as the work is done and no shit is being given to stir trouble in an area
<roconnor>24KiB of Flash Storage. I wonder how much bootstrapping that gets you.
<roconnor>As I work through my Compiler Quest I keep wondering how tightly I should be constraining my memory use. Though lazy functional programming is ill suited for low memory devices to begin with.
<siraben>Cross-posting from electronics but might be of interest to some people here https://news.ycombinator.com/item?id=48448493 "Full Reverse Engineering of the TI-84 Plus Operating System"
<siraben>my project over the last few days, mostly to learn how to try to scale up RE and doc writing with coding agents
<siraben>so much capability in 1 MB of flash, and most of it is related to scientific/mathematical processing!
<siraben>roconnor: I looked into that a bit and you can do things like reduce the GC size/trigger GC more often or do something more generational, but it starts eating into wall clock time
<siraben>the biggest payoff would come from changing the representation of strings out of cons cells
<siraben>but, that would also come at the cost of introducing a new primitive in the VM. Given how much storage reduction would be possible maybe it's not so bad
<roconnor>Yeah, my parser if offline so getContents like immidately inflates the input by like a factor of 8 at minimum :]
<roconnor>Anyhow I figure I just get things working first and worry about these sorts of optimizations later.
<siraben>Yes, for sure.
<siraben>Also, those types of optimizations can be explored much more cheaply with LLMs now
<siraben>getting from A to B still requires a lot of human effort!
<roconnor>Also I have no GC at the moment so there is that. :P