Question: What utils does base-util use?
Closed this issue · 11 comments
I am guessing that you are probably compiling the coreutils statically and those that do not work get replaced with either busybox or toybox depending what works best. Is it like that? I am on a journey to replace my coreutils with toybox+ubase+sbase, and so I am looking to replace little parts and pieces of my system that do still need the (bloat)""features"" of the GNU coreutils
Hi @xplshn
Baseutils is my own homegrown version of coreutils, essential programs I consider I could bootstrap an entire Linux distro from without relying on anything else.
I mix/mash binaries from CoreUtils + BusyBox + FindUtils + OpenSSH + Procps + ToyBox + UtilLinux + XZ-Utils & some other modern unix tools.
My primary use case is that I often deal with very, very constrained environments, and I use bins from baseutils whenever I need them.
I am on a journey to replace my coreutils with toybox+ubase+sbase, and so I am looking to replace little parts and pieces of my system that do still need the (bloat)""features"" of the GNU coreutils
You could of course use bins from my repos ( Azathothas/Static-Binaries | Azathothas/static-toolbox), however do note that some binaries like git won't work at all because git requires dozens of extra binaries.
Azathothas/Toolpacks is the only repo I would consider is ready for production use as I only keep binaries that work.
Check out pwnwriter/hysp if you want a package manager specifically for Statically-Compiled Binaries.
- If you just want a list of all the binaries that are part of baseutils:
curl -qfsSL "https://api.github.com/repos/Azathothas/Static-Binaries/contents/baseutils/x86_64/" | jq -r '.[].name' | sort -uThis is great work, keep it up! I statically compile everything too. I just wish there were more support for this from projects like GTK, statically compiling is a nightmare nowadays.
Have you perhaps considered compiling these as APE? https://justine.lol/ape.html
Binaries compiled against the Cosmopolitan Lib C can be run everywhere without the need to do any changes to the source code or the host system running the APE binaries. https://github.com/jart/cosmopolitan see https://justine.lol/cosmo3/ if you want to test some binaries, games, etc that were statically compiled agains cosmopolitan lib c, the binaries in Cosmos run in windows, mac, linux, *bsd.
They also run on Arm and X86 if compiled as fat-ape. But you should probably stick to having x86_64 and arm releases. You can also selectively support OSes, so you could make it so that your APE executables run on most *nix platforms and not more than that
Interesting. Is https://github.com/jart/cosmopolitan somewhat like pkgsrc ?
I apologize if that was a dumb question, I do not have c/c++ or any of those backgrounds.
I read on how to build certain things statically and just followed the manuals.
There was a similar discussion at https://news.ycombinator.com/item?id=38457926#38470000 where people suggested pkgsrc as a better alternative, however that went against my require nothing to run constraint I had in my mind when I started these projects.
The benchmarks at https://justine.lol/cosmo3/ seem too good to be true, I probably need to test some binaries myself.
Also, I see that you have more experience (looking at your repos) in these.
If you have free time, I would much appreciate it if we could talk/text somewhere, I could learn things.
I am quite a newbie really, ChatGPT helped me write everything to be realistic, Cosmopolitan is a LibC, building with it produces static binaries that can be run everywhere(depending if you use fat-ape, or ape, or other configuration), cosmocc is a compiler that uses cosmopolitan libc, and cosmos.zip is a release of various open source projects compiled with cosmoscc. pkgsrc in the other hand is just a package manager. If you decide to use Cosmo*(anything of the cosmopolitan derived projects), the binaries will not require shared libraries or anything more to run, optionally, users can install an ape-loader, I do not really understand how it works, I think its job is to interpret the APE code itself, instead of directly running the binary and making it figure out in which system it is, what syscalls to translate and etc.
so something like upx, but for building and shipping binaries? Wait, isn't that AppImage?
also, if you use some socials, let's text there, GitHub issue comments bring back some PTSD memories from days gone....
No, an AppImage still needs to be compiled for an specific architecture, Appimages do not run on BSD, do not run on different ABIs, a Glibc appimage won't run on a Musl based system, etc... Its just for C programs/libraries, so it'd be useful even on go programs if they depend on C libraries. We can chat here: "ssh ssh.chat" , I don't want to leave my Telegram here on Github...
https://github.com/shazow/ssh-chat
You don't need anything more than a correct SSH2 implementation(be it dropbear or openssh).
closed due to morally questionable texts & legal reasons
closed due to morally questionable texts & legal reasons
That is not a valid reason.
ksh93: sudo: This issue will be reported.