>From [EMAIL PROTECTED] Sun Jun 17 13:28:12 2001
>So sprach [EMAIL PROTECTED] am Sun, Jun 17, 2001 at 01:00:14PM +0200:
>> However, if "your favorite" TAR program is not able to extract TAR archi=
>ves
>> don't piss on me! Simply send a bug report to the maintainer of "your
>> favorite" TAR program.
>Yes, I piss on you (your words, not mine!), because you constantly attack
>GNU tools with *NO* reason *WHAT* *SO* *EVER*! I have shown that GNU tar is
>*PERFECTLY* able to extract files, even if GNU tar has to deal with tar
>archives which it does not *LIST* correctly. I do not care about this,
>neither does anyone else besides *YOU*, so it's *YOUR* task to patch GNU
>tar!
You really seem to have problems to get it:
1) I warn poeple when FSF programs do make life harder.
2) Before writing useless statements on what I have to do or not:
- Look at the GNU tar source and judge your own. The
GNU tar source is a big pile of spaghetti code. It is
hard to find bugs by people who are not used to work on it.
- Next time you will send me a bug report for cdrecord,
I will tell you that it is _your_ task to find a patch
for the bug. So please stay resonable!
>> >"Please upgrade your shell to something usable like bash. Cannot go on."
>>=20
>> Using the word "upgrade" is very very quetionable in this context.
>Why? Because I imply with the word that a better shell than sh should be
>used? Well, this was my intention. If people want to work with old, overly
>complicated tools which do not support features found in bash, than it's
>their problem.
>> If you overwrite /bin/sh with bash or if you modify the root account
>> to use any other shell than sh (note that this is even /sbin/sh on modern
>> available) you may completely corrupt your installation forcing a re-inst=
>all
>> >from CD.
>Why? Just because the shell scripts are incompatible with bash? So upgrade
>your shell scripts!
Stay reasonable: if you like to force people to change to a nonstandard shell,
you should first "upgrade" several hundreds of kilobytes of shell code from
Solaris and tell the administrators that you are going to give them 7/24 support
for your changes and for bash.
>> ****************
>> STOP! /proc holds information on processes and _not_ information on the
>> system.
>> *********
>*WRONG* (at least for Linux). If other systems don't have such a nice thing
>as the /proc filesystem, it's their problem.
WRONG: /proc is a result of the AT&T OS research group in 1984 (taken from
Plan 9). Solaris implements the /proc idea 100% correctly while Linux added
things that do not belong there. Note that even the things Linux added to /proc
are no primary Linux ideas but ideas also taken from Plan 9. Solaris 9 will most
likely have similar functionality in /system. /proc is a filesystem that
was invented to deal with process address space.
>> - This does not work on Linux because it uses nonstandard places
>> for log files.
>So it's not portable at all. Too bad for the minority of people using
>"standard" Unices.
While it may be more intuitive to have kernel log files in /var/log, they are
for historical reasons placed in /var/adm
>> - If a machine is 'up' for a long time the needed information has been
>> scrolled out.
>So in the "superior" OSes, there's then no way to get this information? Too
>bad...
Of course it _is_ possible:
prtconf
System Configuration: Sun Microsystems sun4m
Memory size: 96 Megabytes
System Peripherals (Software Nodes):
.....
But there is no portable way to do it. The question is: do you really need
su a nonstandard feature?
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
