Re: /USR/BIN/CRON
>> > Does every daemon have the right to uppercase its name or just cron has
>> > that right? Is there any item in policy about this exception?
>>
>> There is something more powerful than policy at work here: Unix tradition.
>> Cron has *always* done this.
>
>Tradition may sometimes be braindead.
What is the problem here? The only possible reason for changing this is that
it could be considered to look bad in "ps" output. Of course the alternate
point of view is that if you have a dozen such processes then you may have a
problem with your system and you want them to show up noticably in ps.
>In either case, if tradition is more powerful than policy, it should be
>clearly written somewhere in the policy, or else policy will be useless.
No. The policy has to be defined in a sane way that won't confuse users of
other systems. There are many people who use commercial versions of UNIX and
Linux every day. Linux is already quite different from Solaris and SCO UNIX
(the most popular commercial unices that I've seen used). If we go out of our
way to make it more different then we make it difficult for these users to
convert.
If we can gain some significant advantage of making things different then we
should do so. But we should not lose compatibility with other unices just to
make the output of systems utilities look nice.
>In summary: If there is something more powerful than the policy
>then the policy is useless.
Lots of things are more powerful than policy. If it was otherwise then we
wouldn't call it policy we'd call it a law of physics. We could write in
policy that every application must support transperant fail-over in a clustered
network. The fact that clustering is not truely supported in Linux yet or even
being seriously worked on (IBM's HACMP is not true clustering and neither is the
Linux clone of it) makes this simply impossible.
A policy that is impossible to enforce is a useless policy.
While we're at it why not make the policy specify that every email and file
transfer application must support 1024bit encryption? It makes more sense than
specifying that applications can't change argv[0].
>> While I admit it is peculiar, I see no reason why this should be against
>> policy. There may even be scripts out there that depend on this.
>
>Since Debian is free and comes with source code, we will obviosuly be able
>to change whatever scripts are broken due to cron's own brokenness.
You can't change the scripts that may be in /usr/local/bin.
PS You could write an alias for ps that piped the output through "tr" to
translate all upper-case letters to lower-case.
--
I'll be in Denver from 30 Oct 1998 to 7 Nov 1998 (or maybe a few days longer).
I'll be in London from ~9 Nov 1998. I'd like to meet any Linux users or
users groups in these places at these times.
I plan to work in London for 3 - 6 months...
Reply to: