Frankly this about page sucks. I want to like this project, but there is only one sentence on what it's supposed to replace and why. Apparently this is supposed to be better than busybox somehow. No information on why busybox sucks, no information on how sbase sucks less. Is sbase better because it is smaller, faster, better architected, more POSIX compliant, more useful features, what? What are the tradeoffs for this? If you're going to make the claim that you suck less, at least say WHY you suck less.
Even Google doesn't seem to know what sucks less about suckless. The best I could come up with was "sbase vs busybox" which leads me to [1], where this exact question was asked, to which the response by the project creator was "The busybox code sucks." Not helpful at all, which was pointed out one post later, to which another project member said "Try to read it [the code?] and understand it." Great. Like I have time to read the code of every project before I decide to use it.
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.
I 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.
I kind of like that they manage to present their project there without bashing other projects, apart from the whole name and approach of course.
It's a bit difficult to confirm, but given the name and approach this project is probably a part of the suckless community (however big that is and who might be in it), and on their page there is http://suckless.org/philosophy and some other pages, that would explain what to expect from sbase. Granted, that is not very concrete.
Maybe you didn't see the "sucks" page they also link to cat-v's "considered harmful" page which I have to assume is maintained by people that don't professionally use computers.
"Like I have time to read the code of every project before I decide to use it."
I can only wonder how you make your decisions on what projects (binaries?) to use.
About pages, Google searches for x vs y, blog posts, forum comments, etc. Am I on the right track?
The bigger question is why you are even evaluating some new project in the first instance. Is there something wrong with the project you are using now? If so, can you articulate it?
Perhaps a user's intended use of a project is relevant.
As one example, consider the case where the user intends to compile and if necessary modify the code, and wants to know that this is a viable option, e.g. if something breaks. In that case does it make sense for the user to read the code?
This user might ask "Is the sbase code easier to work with than the busybox code?"
Another user might intend to rely on others to do compilation and modification (e.g., if something breaks) and then make binaries available.
Is it possible these two users might evaluate a project differently?
Suckless gets a bad rep (probably because of their openness about their opinions of the projects of which they create alternatives); but, honestly, they have made some of my absolute favorite utilities. dwm, dmenu and st serve as the foundation for my whole workflow.
I'd love to see a whole suckless OS someday. I know it's been around for some time, but it seems like this might be the first step towards that.
Also:
- "Arthur wrote an SQL in 20 lines of K, and a dynamic window manager in around 60 of C...kOS's kernel is under 60 lines of C as well (including annotations; paging, filesystem, syscalls, etc)." (https://news.ycombinator.com/item?id=9002302)
- "k includes language, files, procs, ipc, webserver, dbms, ..z includes graphics...edit.k is 1KB code + k/ztk(9KB)." (http://kparc.com/o.htm)
- "kOS doesn't use the Linux kernel code. It supports a few of the same syscalls: clone, execve(!), epoll_create, epoll_ctl, epoll_wait, dup2, stat, rename, unlink, getcwd, chdir, fstat, getdents, open, close, read, write, ftruncate, mmap2, munmap, ioctl, gettimeofday, socket, bind, connect, listen, acccept, socketpair, setsockopt...execve just runs another k interpreter (regardless of what you tell it to do) though, so it can just be used to run more k programs." (https://news.ycombinator.com/item?id=8744769)
> Suckless gets a bad rep (probably because of their openness about their opinions of the projects of which they create alternatives)
I didn't know that, but it doesn't surprise me. However I also love the software the project produces. Especially when they release new versions of tools where whole features have been removed to fix bugs.
I can't stand the attitude of the suckless project. Apparently all software is bloated unless in it is written in C, statically linked, and configured only by modifying a config.h file and rebuilding.
Thanks, but I'll just keep on using the GNU coreutils, Emacs, etc.
Wait. Is that really related to suckless.org? I've just checked that suckless.org Unix tools are called "9base", not "Sbase", and is different code. Could someone explain that?
Even Google doesn't seem to know what sucks less about suckless. The best I could come up with was "sbase vs busybox" which leads me to [1], where this exact question was asked, to which the response by the project creator was "The busybox code sucks." Not helpful at all, which was pointed out one post later, to which another project member said "Try to read it [the code?] and understand it." Great. Like I have time to read the code of every project before I decide to use it.
[1] https://bbs.archlinux.org/viewtopic.php?id=176854