On Mon, 9 Mar 2015 01:51:59 +0100
Alexander Huemer <alexander.huemer_AT_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 <dev_AT_frign.de>
Received on Mon Mar 09 2015 - 14:05:39 CET