Sbase – Suckless unix tools(git.2f30.org)
git.2f30.org
Sbase – Suckless unix tools
http://git.2f30.org/sbase/about/
31 comments
http://git.suckless.org/sbase/tree/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://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/
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.
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.
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.
What precisely is wrong with it? Speaking as someone who professionally uses computers, I agree with quite a bit of it.
Your assumptions are incorrect.
> the response by the project creator was "The busybox code sucks."
Whoever that is, they aren't the project creator.
Whoever that is, they aren't the project creator.
"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?
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.
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.
I'd love to see a whole suckless OS someday.
That might be Plan 9--or Project Oberon. ;-)
I'm really looking forward to kOS: http://www.kparc.com/o.htm
That might be Plan 9--or Project Oberon. ;-)
I'm really looking forward to kOS: http://www.kparc.com/o.htm
There are so many things about Plan9 that I deeply love. I need to install 9front and play with it sometime :)
Same on kOS. In case you had not seen them, early kOS screenshots: http://www.reddit.com/r/apljk/comments/1vcioz/arthur_whitney...
Featured live in geocar's presentation: https://www.youtube.com/watch?v=kTrOg19gzP4&list=PLmRrx948XM...
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)
Featured live in geocar's presentation: https://www.youtube.com/watch?v=kTrOg19gzP4&list=PLmRrx948XM...
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)
I'd love to see a whole suckless OS someday.
Morpheus Linux? http://morpheus.2f30.org/
Morpheus Linux? http://morpheus.2f30.org/
Oh… Oh my… +1 for you!
> 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.
Simplify everything!
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.
Simplify everything!
[deleted]
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.
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?
http://git.suckless.org/9base/tree/cal/cal.c http://git.2f30.org/sbase/tree/cal.c
http://tools.suckless.org/
http://git.suckless.org/9base/tree/cal/cal.c http://git.2f30.org/sbase/tree/cal.c
http://tools.suckless.org/
The sbase page on suckless.org is here:
http://core.suckless.org/sbase
> 9base is a port of various original Plan 9 tools for Unix, based on plan9port.
While sbase is supposed to be POSIX-compliant.
http://core.suckless.org/sbase
> 9base is a port of various original Plan 9 tools for Unix, based on plan9port.
While sbase is supposed to be POSIX-compliant.
Since that page links to
[1]: http://git.suckless.org/sbase/
instead of
[2]: http://git.2f30.org/sbase/
I'm guessing [2] is a mirror, and [1] is the original Git repository. They appear to have the same content.
[1]: http://git.suckless.org/sbase/
instead of
[2]: http://git.2f30.org/sbase/
I'm guessing [2] is a mirror, and [1] is the original Git repository. They appear to have the same content.
Thank you.
On IRC, I heard that suckless.org and 2f30 are indeed related.
Also, check ubase http://git.2f30.org/ubase/about/
It looks well written.
no vi?
The suckless editor is called sandy[0].
[0] http://tools.suckless.org/sandy
[0] http://tools.suckless.org/sandy
I wonder why they didn't just make an ncurses frontend to sam. You'd get regex search, selection-based commands and unlimited undo for free...
vis!
http://lists.suckless.org/dev/1409/23497.html
There might be more characters in the announcement than in the repository,though.
http://lists.suckless.org/dev/1409/23497.html
There might be more characters in the announcement than in the repository,though.
It's outside the scope of sbase, but there's work on a vi-like editor too: http://www.brain-dump.org/blog/entry/144/vis_a_highly_effici...
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