I made this!!! omg it was and is so hard and slow (and rewarding!!) something is very wrong with my debian kernel usb-storage it freezes all i/o over and over. I shouldn’t be using the iwl minipcie wifi driver that debian has anyway but it lets me download substitutes :s I should go to a library or something for my substitutes and meet people !! I’m so confused :) I spend most of my time waiting for some systemwide usb io block, trying tmpfs mounts and filesystem opti—
https://codeberg.org/xloem/guix-sources # guix-sources hi !!!!!! this calculates the most used origins in the guix operating system so as to generate packed optical media (or anything else) for using the operating system in a source-based way without a substitute server. this is my second guile code ever. i'm running this on a super slow low-end system but i'm dreaming of providing optical media sets and merging into upstream some day, who knows :D i'd have to recode it in a functional style etc. i'm also interesting in seeing if nix could be supported. but it's slow going here ... oh and I have a serious dissociative disorder i'm likely to forget about this project entirely and abandon it. BUT IT WORKS NOW YOU SHOULD BE ABLE TO RUN OFFLINE WITH IT. ummm after i finish building a dvd and fix any bugs. hey did you know the entire guix sourceset of all packages looks like it would fit on a single quad-layer blue-ray? it's the highest-end blueray, holds 128GB. right now it generates manifests that are specific to the guix release and system in question ... because guix 1.4.0 is hashing patches based on filename rather than content for me, and they're stored inside the release package, and referenced by absolute pathname, so it creates different hashes for identical content on each system >_> this is likely a bug because the obverse is true too, if the content changed but the pathname stayed the same it makes package hash collisions!! but i think there are other approaches already that can do this better, it's just hard to find where anybody's made use of them. it's all a learning experience. the code i've explored is really helpful and should stick around (but improve to be more functional and modular) but i think we could likely fix it up somehow guix is likely a really great OS if you are a real dev because you have to build it to do anything at all with it, and it is pointedly designed that way. one of my claims to fame is that i read through the iso9660 spec and calculated how many bytes overhead would be needed for files, dirs, etc! one design concern: packages, gexps, and origins are not treated uniformly -- it is possible some rarely used edge origins may be missed, or the depth of a package miscalculated. the processing of different 'things' should be reviewed and made uniform per the guix manual, which appears to be the source of truth moreso than inline comments. but this is basically part of resolving how to present origins robustly in general by learning the environment better. yay i finally pushed this to the internet! now it will stick around if i lose this computer. UPDATE README?
