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 <g...@gnu.org.ua> 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 <melodra...@online.de>
