rodgers@clausius.mmwb.ucsf.edu (02/17/91)
In <455@bria> mike@bria writes: >In an article, ra.MsState.Edu!it1 (Tim Tsai) writes: >|In article <433@bria>: >||In an article, ms.uky.edu!kherron (Kenneth Herron) writes: >||In my "not-quite-so-humble" opinion, armchair sysadmins deserve DOS. >||You are talking about two things here: system administration and end-use. >||In the DOS world, "end-user" and "administrator" are one in the same. >||Not so in the UNIX world. >| >| It is very often the case in the 386/Unix world.. With prices of >| workstations dropping, more end users will have their own Unix box on >| their desk. >And most of these workstations with be networked, and have a central >authority. Good points, both of you. There is a need to address the issue of stand-alone UNIX cpus. Even in the case of networked systems, the tools for efficient administration are lacking. >... My point was that too many UNIX >"professionals" are not learning the _innards_ of the operating system. >They are using scripts and such (that were designed to make routine jobs >a bit easier) as a _crutch_. And yes, a sysadmin that relies on 'vi' and >has no idea how to use 'ed' is NOT worth a dime. Know why? Sometime, he's >gonna run into a situation where his /usr filesystem got hosed, or the >/etc/termcap got chunked. If something like that stops a sysadmin, then >yep, he's worthless as a plug nickel. You could argue that a good sysadmin also plans ahead, and stores a few essential utilities (including the editor he is most comfortable with, perhaps vi) on an archive medium to be pulled in under mini-UNIX in the event of a major crisis such as the one you describe, or even stores multiple copies of key programs in small administrative directories on different partitions. We do the former. Being a good sysadmin involves much more than conversancy with any given tool or tools. An intimate knowledge of internals without goof general strategic reasoning skills is not of much use.. >It depends. Since Norton attaches itself, virus-like, to my kernel, and >induces the kernel to lie to me about the true state of affairs on the >system, I would count this as a hinderance. I can't speak to Norton, but I share your distrust of a firm known for its involvment in the DOS world trying to use this reputation to barge into the UNIX community. However, there is a crying need for good administrative tools, and this is being addressed by others. Witness the ERSA system from Canada, or the System Manager's Toolkit from the University of California (otl@violet.berkeley.edu for information). Both attempt to address administrative needs starting from the UNIX end of things... Cheerio, Rick Rodgers R. P. C. Rodgers, M.D. (415)476-2957 (work) 664-0560 (home) UCSF Laurel Heights Campus UUCP: ...ucbvax.berkeley.edu!cca.ucsf.edu!rodgers 3333 California St., Suite 102 Internet: rodgers@maxwell.mmwb.ucsf.edu San Francisco CA 94118 USA BITNET: rodgers@ucsfcca
it1@ra.MsState.Edu (Tim Tsai) (02/17/91)
In article <455@bria>: >In an article, ra.MsState.Edu!it1 (Tim Tsai) writes: >|In article <433@bria>: >||In an article, ms.uky.edu!kherron (Kenneth Herron) writes: [lines deleted] >||In the DOS world, "end-user" and "administrator" are one in the same. >||Not so in the UNIX world. >| It is very often the case in the 386/Unix world.. With prices of >| workstations dropping, more end users will have their own Unix box on >| their desk. >And most of these workstations with be networked, and have a central >authority. I wouldn't say most.. Perhaps in large companies and educational institutions. I won't argue further on this though. >||The end-user does not and should not need to know about anything other >||than logging in, reading/sending mail, and using the application(s) that >||meet his/her job requirements. This same end-user has no use for NU. >| There are lots of computer proficient "end-users" who aren't >| sysadmins, and they'll use whatever tools they find necessary. >Computer proficient users can do whatever they like, permissions not with- >standing. However, the thrust of tool development is, and should be, the >computer professional. Hmmm, so you are saying that Norton Utilities weren't developed by computer professionals?? I don't think we're on the same wavelength here. >||Personally, I would never trust an administrator that leaned on menus >||and shrink-wrapped scripts _too_ much. How much is too much? I have >||encountered "sysadmins" who couldn't add a user without some sort of >||script. Not worth a dime, IMHO. >| Sysadmins' gotta start somewhere. Were you born with knowledge of >| Unix internals? What's wrong with packages that ease the job of system >| administrators? By your definition, any sysadmin that relies on a >| full-screen editor isn't worth a dime either. A *REAL* sysadmin would >| use ed, right? >Yes, you do have to start somewhere. My point was that too many UNIX >"professionals" are not learning the _innards_ of the operating system. >They are using scripts and such (that were designed to make routine jobs >a bit easier) as a _crutch_. And yes, a sysadmin that relies on 'vi' and >has no idea how to use 'ed' is NOT worth a dime. Know why? Sometime, he's >gonna run into a situation where his /usr filesystem got hosed, or the >/etc/termcap got chunked. If something like that stops a sysadmin, then >yep, he's worthless as a plug nickel. So what does all this have to do with Norton Utilities? Is ed the _innards_ of the operating system? A sysadmin should be able to adapt to a situation, instead of knowing a few set-procedures well. I think a sysadmin should be able to *FIGURE* out how to use ed with the proper documentation. Some of us also believe in making backups of some of the more useful utilities in case of system crashes. (speaking from the DOS world. I'm not an unix sysadmin, and as a matter of fact, a lowly undergrad. Does this automatically disqualify me from speaking here?? :) [lines deleted] >| How does installing a package make things any more difficult for you? >It depends. Since Norton attaches itself, virus-like, to my kernel, and >induces the kernel to lie to me about the true state of affairs on the >system, I would count this as a hinderance. Virus-like? I don't think so.. We all use these "viruses" in day to day operation.. You may send me e.mail via it1@msstate.edu, but somewhere along the path, that address gets translated to it1@ra.msstate.edu.. There, my system just lied about my true address. What's my point?? If the operation is *COMPLETELY* transparent to the users and the sysadmins, then what's wrong with it? I agree with your other post that this should be handled in the kernel, but until that is done, Norton Utilities is one of the better methods in handling the undelete problem. Not everybody has the patience to wait for Berkeley or AT&T to finally include undeletion of files, and NU offers it NOW. Yes, I am aware of freely available tools, but the ones I've encountered only replace the "rm" program, which is useless if a file was removed using system calls. Perhaps you dislike NU becase it came from a company that specialized in DOS utilities (BTW, symantec is more famous for making Macintosh utilities)?? If so, I don't blame you. I don't use NU, and as a matter of fact dislike it, but I found your arguments questionable. >| I'm glad you aren't my sysadmin. >And, oh boy am I glad you're not my end-user. :-) Let's just say the feelings are mutual.. (smileys for the humor impaired) >-- >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? I'd flame Bill Gates, Microsoft, IBM, and Digital Research, in that order. -- I have lots of common sense. I just choose to ignore it. <Calvin>
mike (02/18/91)
[ in the on-going assault on ol' Pete Norton and his DOS flunkies ... ] In an article, ra.MsState.Edu!it1 (Tim Tsai) writes: >>In article <455@bria>: >>Computer proficient users can do whatever they like, permissions not with- >>standing. However, the thrust of tool development is, and should be, the >>computer professional. > > Hmmm, so you are saying that Norton Utilities weren't developed by > computer professionals?? I don't think we're on the same wavelength > here. I am saying that the NU philosophy was developed by a group of DOS progammers trying to migrate to a "hot" market. The DOS philosophy (if you can even say that DOS has a philosophy) has no place in the UNIX environment. NU is not a tool, it is a monolithic kludge. A tool is a program that does _one_ thing _very_ well, and whose strength lies in the interaction with other tools. And, no, I do not consider things like awk and perl to be tools in the strictest sense, although they are indeed very valuable. [ on to a discussion on the virtues of sysadmins ... ] >>Yes, you do have to start somewhere. My point was that too many UNIX >>"professionals" are not learning the _innards_ of the operating system. >>They are using scripts and such (that were designed to make routine jobs >>a bit easier) as a _crutch_. And yes, a sysadmin that relies on 'vi' and >>has no idea how to use 'ed' is NOT worth a dime. Know why? Sometime, he's >>gonna run into a situation where his /usr filesystem got hosed, or the >>/etc/termcap got chunked. If something like that stops a sysadmin, then >>yep, he's worthless as a plug nickel. > > So what does all this have to do with Norton Utilities? Is ed the > _innards_ of the operating system? A sysadmin should be able to adapt > to a situation, instead of knowing a few set-procedures well. I think > a sysadmin should be able to *FIGURE* out how to use ed with the > proper documentation. Some of us also believe in making backups of > some of the more useful utilities in case of system crashes. (speaking > from the DOS world. I'm not an unix sysadmin, and as a matter of > fact, a lowly undergrad. Does this automatically disqualify me from > speaking here?? :) Naturally, ed has nothing to do with the innards of the operating system. I was trying to make my point two-fold: 1) up-and-coming sysadmins are learning to walk with crutches instead of on their own two feet; 2) a lack of knowledge of UNIX basics (such as using ed) is becoming prevelant. Note that this whole 'ed' thing started when you wondered if using 'vi' was an example of using a crutch. My response was, yes, if that is _all_ that he knows how to use. My bottom line is this: Use whatever you want; but as a sysadmin, you absolutely _must_ be able to survive without extraneous riff-raff, like NU. You can have all of the bootable floppies and backup tapes you want ... something is gonna come down the pike that you don't expect. There is no gizmo that will substitute for knowledge about how things are done. Plain and simple. [ now, onward to the methodologies of NU's undelete ... ] >>It depends. Since Norton attaches itself, virus-like, to my kernel, and >>induces the kernel to lie to me about the true state of affairs on the >>system, I would count this as a hinderance. > > Virus-like? I don't think so.. We all use these "viruses" in > day to day operation.. You may send me e.mail via it1@msstate.edu, > but somewhere along the path, that address gets translated to > it1@ra.msstate.edu.. There, my system just lied about my true > address. What's my point?? If the operation is *COMPLETELY* > transparent to the users and the sysadmins, then what's wrong with > it? [...] I don't think that address translation would fall in the domain of "virus 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. > Perhaps you dislike NU becase it came from a company that specialized > in DOS utilities (BTW, symantec is more famous for making Macintosh > utilities)?? If so, I don't blame you. I don't use NU, and as a > matter of fact dislike it, but I found your arguments questionable. I'm glad you question my aguments; it would be a lousy world if everyone agreed. So, okay, I'll admit it. I am a UNIX purist. Ah well, we all have our faults. :-) -- 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?
thad@public.BTR.COM (Thaddeus P. Floryan) (02/18/91)
In article <457@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? 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. 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. 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'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 of this approach yourself first! :-) Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
mike (02/19/91)
In an article, public.BTR.COM!thad (Thaddeus P. Floryan) writes: |In article <457@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?
kherron@ms.uky.edu (Kenneth Herron) (02/19/91)
In article <466@bria>: >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. Norton is saving all of these; 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... _NO_YOU DON'T_. The whole purpose of this "lying" about free space is that Norton will free the blocks on demand, so as far as a user can tell, the space was never in use to begin with. Stated another way: Norton's is using the free space on your hard disk to save deleted files without making the space any less free; since it's in the kernal it can do that. The blocks "used" by Norton's do not meet the classical definition of in-use, since they're instantly freed upon demand. It think the basic question is: "Do you trust Peter Norton with your kernal?" The same question can be asked about every third-party device driver (including FAS, a public domain product yet!). It's just that Norton's is a somewhat more unusual kernal add-in than most, and, like others have said, it has the stink of DOS about it. I think I'm also detecting a bit of power-user arrogance here, too... -- Kenneth Herron kherron@ms.uky.edu University of Kentucky (606) 257-2975 Department of Mathematics "Never trust gimmicky gadgets" -- the Doctor
it1@ra.MsState.Edu (Tim Tsai) (02/19/91)
In article <457@bria> uunet!bria!mike writes: >[ in the on-going assault on ol' Pete Norton and his DOS flunkies ... ] >I am saying that the NU philosophy was developed by a group of DOS progammers >trying to migrate to a "hot" market. The DOS philosophy (if you can even >say that DOS has a philosophy) has no place in the UNIX environment. Your reason are getting weirder and weirder.. From what I remembered, NU for DOS is a set of small utilities each doing one thing very well.. They may not interact well with each other, but that has more or less to do with the limitations of MS-DOS. Have you actually ever used Norton Utilities on Dos?? Let's name a few of the Norton Utilities commands for DOS (prior to version 5.0, which is another thread): si: report state of the system and do a simple benchmark ds: sort disk directory fa: display file attributes nuformat: format a disk ff: file find plus various other commands Now tell me, how different is the NU philosophy from your so-called "UNIX philosophy"? And again, I have no inside information on who wrote NU for Unix, but Symantec specializes in Macintosh software, and most likely they contracted a group of *UNIX* programmers. >NU is not a tool, it is a monolithic kludge. A tool is a program that does >_one_ thing _very_ well, and whose strength lies in the interaction with >other tools. If that's how you wish to define tool.. My definition of tool is any program that helps me in accomplishing a task. See my paragraph above about "monolithic kludge".. Again, NU is a set of tools, not A tool. >And, no, I do not consider things like awk and perl to be >tools in the strictest sense, although they are indeed very valuable. So you *COULD* consider NU very valuable, if not a tool. >Naturally, ed has nothing to do with the innards of the operating system. >I was trying to make my point two-fold: 1) up-and-coming sysadmins are >learning to walk with crutches instead of on their own two feet; 2) a lack of >knowledge of UNIX basics (such as using ed) is becoming prevelant. Note >that this whole 'ed' thing started when you wondered if using 'vi' >was an example of using a crutch. My response was, yes, if that is _all_ >that he knows how to use. Again, that's what documentation is for.. I use vi almost exclusively, and if I ever need to use ed, I know where to look for the doc. I guess that makes me useless if I ever become a sysadmin huh? >My bottom line is this: Use whatever you want; but as a sysadmin, you >absolutely _must_ be able to survive without extraneous riff-raff, like >NU. You can have all of the bootable floppies and backup tapes you >want ... something is gonna come down the pike that you don't expect. >There is no gizmo that will substitute for knowledge about how things are >done. Plain and simple. I still don't see your logic.. "There is no gizmo that will substitute for knowledge about how things are done" First, if a sysadmin has knowedge about how things are done, then using the "gizmo" only helps him does the job faster/easier. If a sysadmin has no knowledge of how things are done, using ed or whatever is not going to help any. Common sense is probably more important here. >I don't think that address translation would fall in the domain of "virus >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. Again, your definition of virus and mine differ. Gee, I wonder how Sun's quota system works.. Do they actually rewrite the kernel or just patch the appropriate routines... (for those not familiar with Sun's quota system, it keeps up with the space used by each user on a system call level, probably intercepts unlink(), ftruncate(), etc, not unlike Norton's undelete). If Sun send you the "quota" feature as a patch and ask you to relink the kernel, would you call it a "monolithic kludge"? Look, the "freed" blocks are there if you need space. If the hard drive system gets full, those "freed" blocks will get overwritten. If you need to undelete a file, those "freed" blocks are restored.. Look at undelete as a copy command.. If you don't use it, the space is free. If you use it, extra space is used.. I don't see any problem. >I'm glad you question my aguments; it would be a lousy world if everyone >agreed. So, okay, I'll admit it. I am a UNIX purist. Ah well, we all >have our faults. :-) You must use V7 exclusively then. Modern Unices have tons of kludges glued in by various vendors. I can't really name any, but the subject has be debated several times on the net. Using any of these modern Unices would violate your "purist" principal, wouldn't it? I think we should probably drop this subject or take it to e.mail.. The rest of the newsgroup is probably getting very very tired of both of our names now... :) >-- >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? -- I'd never cry if I did find a blue whale in my soup... Nor would I mind a porcupine inside a chicken coop. Yes life is fine when things combine, like ham in beef chow mein... But Lord this time I think I mind, they've put acid in my rain. <Milo Bloom>
it1@ra.MsState.Edu (Tim Tsai) (02/19/91)
In article <466@bria> uunet!bria!mike writes: [lines deleted] >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. Woa. Can somebody confirm this? I thought NU is supposed to overwrite the so-called "freed" space when the "real" disk space starts to run out? [rest of msg deleted to keep inews happy] -- I'd never cry if I did find a blue whale in my soup... Nor would I mind a porcupine inside a chicken coop. Yes life is fine when things combine, like ham in beef chow mein... But Lord this time I think I mind, they've put acid in my rain. <Milo Bloom>
ires@kaspar.UUCP (Bruce R. Larson) (02/22/91)
>||...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. >| That's very funny. Did you learn this by using the program? Or did someone tell you this? I used it for a while because some clients bought it from me, hence I will have to support it. The number of free blocks reported always reflected the true number of free blocks in the system. If I had 40,000 free blocks in a file system, then I'd show about 10,000 blocks after making three stages of gcc and cleaning everything up. [BTW, the reason NU was turned on in a development area is because our development area is also our user space.] Note that I did uninstall NU as soon as I could because I was developing habits that NO system administrator wants to develop # rm -rf * <CR> /* Wait a minute,... which directory was I in? */. If someone is already carrying the baggage of those bad habits in from DOS-land, then why not give it (NU) to them? Of course, the ultimate decision about installing NU *should* lie with the (wo)man who will have to maintain it. Bruce Bruce R. Larson Integral Resources, Milton MA # Temporary address change below Uucp: ..!world.std.com!kaspar.uucp!blarson Internet: blarson@cs.umb.edu
mju@mudos.ann-arbor.mi.us (Marc Unangst) (02/28/91)
ires@kaspar.UUCP (Bruce R. Larson) writes: > If someone is already carrying the baggage of those bad habits in from > DOS-land, then why not give it (NU) to them? Of course, the ultimate Because they *are* bad habits, and thus should be broken at the earliest possible opportunity. People should be encouraged to think about what they're doing before they do it, rather than recklessly deleting files with the mindset of, "well, I can always get it back later if I really need it." -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!umich!leebai!mudos!mju |