Hi.
On Mon, Mar 09, 2015 at 02:05:39PM +0100, FRIGN wrote:
> On Mon, 9 Mar 2015 01:51:59 +0100
> Alexander Huemer <alexander.huemer_AT_xx.vu> wrote:
>
> Hey Alexander,
Thanks for you answer FRIGN.
> > 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.
Well, then let me rephrase that. The descriptions are not very distinct.
I try to think myself into a person why has no prior knowledge about
sbase and ubase and from that point of view quite a few questions arise.
> > 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.
Although I largely share that opinion the mistakes of some other entity
does not justify lack of description on the own side.
> > 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.
The seperation is certainly a good idea.
The TODO is more or less just a list. There is no explanation _why_
these tools should be implemented and vi and sh not.
Don't get me wrong, I wouldn't stuff vi in sbase, but I think some
motivational words wouldn't hurt.
> > 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.
Please see the paragraph above. I don't see any motivation explained in
the TODO, just statements of the form 'that should be done' and 'that
should not be done'.
> > 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 admit that my argumentation was a bit pedantic at that point, but that
was intentional.
> 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.
Sure, I don't doubt that, but working with something every day does not
increase the ability to have an out of the (sbase-)box view.
> 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?
That's not what I tried to say, sorry I wasn't clear enough.
> 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.
That's actually a very nice idea, I did not have that thought.
There is indeed no need for a complete split, config.mk-flags for POSIX
and non-POSIX partitions of sbase would be totally sufficient and very
lightweight.
> In any case, based on our tests, sbase beats coreutils in many regards
> (UTF-8, sanity, consistency and even correct behaviour in traversals).
I don't doubt that at all, sbase is some fine piece of software.
> The separation between sbase and ubase is imho a loose concept, and we
> even discussed putting sbase and ubase in one repository.
As long as some ability for seperation remains, why not.
> 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.
Sure.
> > + 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.
Hmm, i am not so sure about that.
I don't want to argue, please just take that as feedback that there are
people why would appreciate a more verbose motivation.
> > + 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?
I don't think so, no, at least the last part 'if not, then why'.
If you like I can make a list.
> > + 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.
Are you refering to [1]? I am not completely sure.
> > + 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.
Sure, they do.
I suggest to put those abbreviation expansions in the according README
files. I am going to send patches for that, just for convenience.
> It's all about the package maintainers who will grasp the difference pretty
> quickly (at least judging from the people I talked to).
Yes, they do.
The 'issues' I am talking about here are very very minor, one might say
pedantic.
My point is that it can't hurt the explain things like the abbreviation
'sbase' in one short line of text. It clears ambiguities for some people
and is not bloat, at least from my point of view.
> > 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.
Hmm, I guess that's a quite philosophical question.
> 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.
Well, I will be happy to send some documentation patches.
Kind regards,
-Alex^Wblackbit
[1]
http://landley.net/toybox/roadmap.html
Received on Tue Mar 17 2015 - 12:29:38 CET