Re: [bug-inetutils] some notes on inetutils-1.8

[melodramus]

this gets a bit into deep. but i feel a need to clarify some things
here. sergey, take this as a challenge rather than a rant, please.

On Tue, 17 Aug 2010 22:22:45 +0300
Sergey Poznyakoff <address@hidden> wrote:

> If we were to talk about 'traditional' places, then it is '/usr/sbin',
> not '/bin'.

well, i did not try all existing syslogd packages but the ones i tried
placed syslogd in /bin. so it was. i agree that /sbin is the better
place. the idea that daemons belong into libexec seems to come from
redhat. at least i found docs and discussions about libexec targeting at
them.

> > is GNU against *nix?
> 
> It is not *against* anyting. It is *another kind of system*, plain and
> simple.  It may look similar in certain aspects (and it does, indeed),
> but that does not mean it must mimic the others.

aehm, this attitude probably explains why so many people go on
barricades when they see RMS. you may not understand what i mean yet but
that's normal if one believes in something and feels right and peaceful
with it. however, there is no GNU _system_ yet. there is an idea of
that, a vision, possibly not the worst. but it is not existing yet. just
having lots of tools and a creeping own kernel that is not used by most
of us is not carrying the term system. the gnu tools are also not
refusing to install on other systems and in other environments. this is
why they should behave well there. this is like foreigners coming to a
country and learning the common rules of behaviour and the language.
would you have answered if i had written in german? sorry but the
german language is far more elaborated than the english one. so why
should i mimic it, if i'm not already better in it? how do you think
about foreigners coming to your country, settling, occupying some
important parts of your infrastructure and turning their language into
the first language for these parts by actually forbidding your native
language? yes, this is an abstract example but it fits to how you argue
about GNU being some ownstanding and self-reflective world on my
_linux/posix_ home system. and, most of the GNU tools actually mimic
*nix.

sorry if this was harsh but we should discuss inetutils in terms of
reality and not in terms of ideology, i believe. please understand that
GNU is not against anything but its proponents argue and act like being
against everything already established and working in the environment
of the niche GNU is placed in.

> 
> > > The -? option is quite often used in GNU implementations as a
> > > shorthand for --help, so there was no "breaking traditions" here.
> > > Try `tar -?', as an example.
> > 
> > try sed -h and see how nicely a GNU tool can come along with good
> > rites (which doesn't forbid sed -? in parallel.) why so
> > separatistic??? i don't get the sense of this split. what is wrong
> > with -h that you
> 
> As far as I can tell, there is nothing wrong with it.  It was selected
> as a short equivalent for --hop, that's all.

aehm, we were already further in this discussion. go some lines up and
read about 'sed -h' and why.

> > is good habits and practices, routine and
> > normality, and all what makes the live of an admin easier
> > (especially in mixed environments) just worthless to you?
> 
> Please don't exaggerate.  Speaking about help options and help output,
> the truth is that (1) there is no established shortcut option for that
> purpose, -h and -? being widely used variants (I have no notion which
> one is more frequent) and (2) help features on UNIX systems are either
> absent at all or rudimentary at best (see Alfred's reply to this
> regard), which makes talking about 'good practices' pointless. To wit:
> 
> $ /usr/sbin/syslogd -?
> syslogd: cannot open pid file: Permission denied
> syslogd: child pid 73148 exited with return code 1
> $ /usr/sbin/syslogd -h
> syslogd: illegal option -- h
> usage: syslogd [-468ACcdknosTuv] [-a allowed_peer]
>                [-b bind_address] [-f config_file]
>                [-l [mode:]path] [-m mark_interval]
>                [-P pid_file] [-p log_socket]
> $ mv -?
> mv: illegal option -- u
> usage: mv [-f | -i | -n] [-v] source target
>        mv [-f | -i | -n] [-v] source ... directory
> $ mv -h
> mv: illegal option -- h
> usage: mv [-f | -i | -n] [-v] source target
>        mv [-f | -i | -n] [-v] source ... directory
> 
> All examples taken from the recent FreeBSD. Do you call this kind of
> option handling a ``good habit''? Is that kind of help output a
> ``good practice''? Does it make the ``live of an admin easier''?
> Are we suppose to mimic it just because ``that is a *nix way'' and to
> ``treat the elders'' nicely?  If so, I have to strongly disagree.

it seems that you misunderstand the terms tradition and good_practice
and their relationship. tradition is generated from the assembled good
practices and values of the past (tradition also assembles bad practices
and values, but these are seen as being good from internal position.)
command-line options are there for users like admins. they generate
the tradition of good options, not the developers. there is common
agreement about the usefulness and availability of certain options. that
a tool doesn't provide these is not an argument against this agreement.
there are tons of lousy interfaces you can always find out there on the
net. they are the results of bad practices. those occur very easily
because developers have to implement interfaces so often that they begin
to play with them (sometimes only for convenience or without thought.)
but, this is bad practice and what makes admin's life annoying.

in the end, there is one open question to this. do you want to follow
good practice or not? don't look aside but decide independently for
your project. i hope that you decide well. and i hope that you
understand that good practice is to be analyzed on a per-target base:
*nix, *dows, *osx...

> Regards,
> Sergey

best wishes,
MeloDramus <address@hidden>