On Mon, 9 Mar 2015 01:51:59 +0100 Alexander Huemer <alexander.hue...@xx.vu> wrote:
Hey Alexander, > while reading the README file of sbase I noticed `sponge`, remembered > that that's from moreutils and realized that sbase does not provide a > strict subset of coreutils, what I assumed for some reason. sbase is a strict subset of coreutils + moreutils + plan9, but it's all about providing a sane collection of programs needed for everyday use. > Both definitions make sense, but they are a bit unprecise IMO. These are not definitions, but descriptions. By definition, all tools in sbase are portable and the ones in ubase are non-portable. > The fact that a minor number of tools from coreutils ended up in ubase > and one from util-linux in sbase is clearly because of > (non-)portability. Or insanity on behalf of the FSF. > The binaries in sbase come from these 16 packages on Debian jessie: > (...) > The binaries in ubase come from these 16 packages on Debian jessie: > (...) > That's not totally straight-forward :) Well, the motivation behind sbase is not to start separating it up into the same insane packages the FSF came up with. > Also, some tools in sbase are non-POSIX, but the vast majority is. > Though, even coreutils just contains a subset of the POSIX utilities, > see [1], there are 160 utilities listed. > Most likely it won't make sense to implement all of them, even in the > long run. See the TODO in regard to the motivation behind which tools should be implemented or not. > Over time the list of implemented utilities will grow and sbase will > suck because it contains a confusing number of utilities. > There are people who want/need a strict set of POSIX utilities, nothing > else. Why would it suck? There are not really many more utilities I can think of that should be part of sbase apart from the ones already done and the ones listed in README. I don't know about you, but working on sbase every day, using libutil and libutf, it's actually quite easy to work with it. Projects like toybox go too far integrating each tool too deeply into the "ecosystem". In sbase, each tool more or less stands for itself. > Here are some actions I'd like to discuss: > * Split sbase in two parts > + A collection of a subset of POSIX utilities, implemented suckless > + A collection of portable non-POSIX utilities Why do you assume that non-POSIX-utilities suck more in any regard? If you look at LSB or GNU coreutils, one may come to this conclusion, but the only thing I could imagine is having a special config.mk-flag to only build the POSIX-tools. In any case, based on our tests, sbase beats coreutils in many regards (UTF-8, sanity, consistency and even correct behaviour in traversals). The separation between sbase and ubase is imho a loose concept, and we even discussed putting sbase and ubase in one repository. However, having a set of portable tools and a set of non-portable tools separated is probably the easiest for package-maintainers to follow. sbase even runs on old IRIX-systems without issues, and in case we find a way to implement a tool portably which used to be in ubase, it will be pushed over to sbase. As simple as that. > + A short motivation for each utility in sbase that's not in > coreutils > + A short motivation for each utility in ubase that's not in > util-linux This is obvious to the reader in 99% of all cases if he knows the suckless philosophy. > + For all utilities from coreutils that are not (yet) in sbase, > are they wanted/needed or not. If not, then why. > + For all utilities from util-linux that are not (yet) in ubase, > are they wanted/needed or not. If not, then why. Isn't that already the case? > + For all utilities demanded by POSIX but not (yet) implemented in > either sbase or ubase, are they wanted/needed or not. If not, then > why. Read the TODO and the linked article there on this motivation. > + Why does sbase have the name sbase? > If I did not know the name of the project and should pick one > myself, I'd choose ubase like 'UNIX base'. > sbase may be confusing to some people and should therefore be > clarified. > + Why does ubase have the name ubase? > If I did not know the name of the project and should pick one > myself, I'd choose lbase like 'Linux base'. > ubase may be confusing to some people and should therefore be > clarified. sbase = suckless base ubase = ugly / unportable base However, I agree that this may be confusing for newcomers, but most people don't know about binutils, otherutils, util-linux and even coreutils and still use the tools provided without issues every day. It's all about the package maintainers who will grasp the difference pretty quickly (at least judging from the people I talked to). > I am quite sure the motivation for all those are either in the heads of > the developers or in the ML archive or both, they would just have to be > written down. Real knowledge doesn't have to be stored but is derived from given circum- stances. If you know your way around the suckless and UNIX philosophy, you'll be able to answer most questions up there by yourself, and in any case, even though I also like to write manuals, I see more use in writing, auditing and testing code than writing long paragraphs and speeches about why this and that utility is implemented or not. Cheers FRIGN -- FRIGN <d...@frign.de>
