This seems sorta simple to me, I just don’t know how the tools work. If I could just put the base together I can probably make it work, automate it, and simplify it. Just no garuntee of being able to make a product out of it, but I’d want it wrapped up. I hate when I go to try something and I basically have to finish dveloping the app because the dave gave up near the end and just wrote down what you’d need to do. Pisses me off.
If it was just boot an iso, get an ncurses menu, give it IP addresses, tell it what tool it was in the process, bang, cool, then it just… runs. Thats kinda what I have in mind for an “end game”. So I mean if thats “maintained” I guess thats cool.
Alright Imma go whack at this. Felt like shit yesterday.
I’ve seen a lot of discussions about OCI containers and nixOS and why people consider them very important.
OCI containers = everything runs anywhere, end result is the same, even if the binaries themselves aren’t the same
nixOS = as long as the software used to compile and the libraries are identical, all the final binaries are going to have the same checksum / hash. This makes it for a very consistent packaging
Personally, I’m more impressed on the build system that Void and Alpine developers managed to create. Both use similar templates I think. https://build.voidlinux.org/
I wonder if I can donate native aarch64 and armv7 build environments for the Void devs to compile stuff that are flagged with the no-cross-compile option (like LibreOffice). I’d like to contribute somehow to the project, but my package maintainer-fu is at 0.
