5 ms·
http://git.suckless.org/sbase/tree/find.c http://git.suckless.org/sbase/tree/find.c http://git.busybox.net/busybox/tree/findutils/find.c http://git.busybox.net
by anewhnaccount 12y ago
http://git.suckless.org/sbase/tree/find.c http://git.suckless.org/sbase/tree/find.c
http://git.busybox.net/busybox/tree/findutils/find.c http://git.busybox.net/busybox/tree/findutils/find.c
I think one of the main advantages is it's written in the same straightforward, braindead dialect of C as the other suckless projects. They are really easy to dive into. (Hence why, eg, dwm has so many derivative.) I think the suckless folks would consider the fact it doesn't produce a single fat binary to be an advantage too.
It's part of this project: http://morpheus.2f30.org/ http://morpheus.2f30.org/
- prewett 12y agoI think that fat binary might be part of busybox's space saving. Most file-systems I'm aware of have 4k chunk sizes, and I would expect the last chunk of a file to be half filled on average, so if you have 20 utilities wasting 2k, that's a good 40k more on disk. Plus, I expect that many utilities duplicate functionality (error-checking the input IO and printing informative messages), so a monolithic binary could save space with only one copy of the boilerplate, error messages, etc. Anyway, if they would talk about why they suck less, we could evaluate the claim. If they were wrong, people could point it out and they could fix it and verifiably suck less. As it is, we have unsubstantiated claims and fun speculation.