Norton Go Home! We don't want you!

[uunet!bria!mike]

In an article, public.BTR.COM!thad (Thaddeus P. Floryan) writes:
|In article <457 at bria> uunet!bria!mike writes:
||||It depends.  Since Norton attaches itself, virus-like, to my kernel, and
||||[...]
|||
||...like" behaviour.  Regardless, there _is_ something wrong when a foreign
||entity (ie: NU) attaches itself to my kernel, and induces it to lie about
||the number of free blocks on my system.  'Nuff said.
|
|Far be it for me to defend ANYTHING from the MS-DOS world (esp. when my
|opening line at many users' group meetings (Amiga, UNIX, etc.) here in the
|SF Bay Area is "MS-DOS vadanya" :-) or from Peter Norton and his minions,
|but from the descriptions of how NU insinuates itself into a kernel so as
|to be even able to handle, for example, an unlink() syscall, how does this
|approach differ from ((dynamically) loadable) device drivers?

Consderably. As I have previously stated, my beef with NU is that it
"induces" the statfs() call to lie about the true number of free blocks
on the machine.  Let's think about this for a moment.  Here, there are a
_large_ number of file deletions, ftrunctates, and the like.  Norton is
saving all of these (to a certain point); now, my application comes
along and asks how much disk there is.  The OS lies, saying there are 'x'
free blocks, when there really is not.  I start creating files, and
*whoom* run out of real disk space, and my program (while in the middle of
rebuilding an index to a large database) crashes.  That kind of behaviour
_sucks_.  Period.  Shall we now start putting #ifdef NORTON all through
our code?

If I would come across any (dynamically loadable or not) device driver that
was similarly ill-behaved, I would yank it as fast as you can say
"ed /etc/master; cd /usr/sys; make; cp ./unix /unix".

To be crystal clear on this point: I am not against the concept of file
undeletion, dynamically loadable device drivers, etc. etc.  I am against
NU for UNIX.  'Nuff said.

|Conceptually, detecting file deletions in the kernel (or a "module" thereof)
|seems the correct approach and does not require that everyone's $PATH include
|the directory where a rm-replacement program or shell script resides.

Agreed, and I have stated this.  Just don't give the job to NU.

|The kernel-insinuation approach has also been used on other systems to provide
|bug-fixes and enhancements to kernel-vendor software.  On some systems this
|approach is ALSO the preferred method of inflicting viral action; such is life.

That is true.  You rolls the dices and takes your chances.

|It seems to me, as a casual observer (of this discussion thread), most of
|the comments arise from an innate hatred of Norton, MS-DOS, and their ilk.

I am proud to say that DOS can (and often does) make me physically ill.

|I'm getting the impression the current arguments are stemming from:
|1. you don't have the source to the NU, and
|2. you didn't [think] of this approach yourself first!  :-)

I wouldn't want the source to NU, and I certainly hope that I wouldn't come
up with the Norton approach to the problem of file recovery.

If AT&T would like to donate the SVR4 sources to me, I'll see what I can do
about getting some file recovery in there ... :-)

-- 
Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own.
Title of the week: Systems Engineer    | UUCP: ...!uunet!bria!mike
-------------------------------------------------------------------------------
Remember folks: If you can't flame MS-DOS, then what _can_ you flame?