Xref: utzoo alt.security:2280 comp.misc:12201 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!utkcs2!ornl.gov!de5 From: de5@ornl.gov (Dave Sill) Newsgroups: alt.security,comp.misc Subject: Re: password ageing && security in general Message-ID: <1991Apr23.123159.23267@cs.utk.edu> Date: 23 Apr 91 12:31:59 GMT References: <1507@lehi3b15.csee.Lehigh.EDU> <19222@rpp386.cactus.org> <1991Apr19.113211.20509@cs.utk.edu> <19227@rpp386.cactus.org> Sender: usenet@cs.utk.edu (USENET News Poster) Reply-To: Dave Sill Followup-To: comp.misc Organization: Oak Ridge National Laboratory Lines: 55 I've redirected followups to comp.misc (not alt.flame). In article <19227@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F Haugh II) writes: > >UNIX, at least "real UNIX", is not a "hack". It was a very cohesive >system, well thought out and thoroughly understood by its implementors. From the Jargon File (not the latest version): hack: 1. n. Originally a quick job that produces what is needed, but not well. 2. n. An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed. It's clear that you're aware of only the first meaning or ignoring the second for some reason. I think UNIX qualifies as a hack under def'n 2. >The paradigm that a file is a file is a file is well designed and >implemented. Contrariwise, the BSD notion that a file is a symbolic >link is a socket is a ??? is a collection of "hacks". How about when a file is a device? Or a pipe? Sure, it's a handy abstraction, when it works. Symlinks aren't much different. Weighing the pros and cons, I think I'll keep them all. >Ritchie, Pike, Kernighan, et al, are not "hackers". By your narrow, negative definition. This is what brought this whole thing up: you refuse to acknowledge the command usage of "hack" and "hacker" in the positive sense. >Stallman I can't speak for, but given the grotesque thing called "emacs", >yes, Stallman is a hacker, and it isn't something to be proud of. It >would be possible to implement "emacs" in far less memory, but of course >it wouldn't be a programming language and a desert topping. Then it wouldn't be Emacs, John. Like it not, some people *like* Emacs, and have the resources to run it. The existence of smaller, differently- abled (aka handicapped :-) editors doesn't automatically make Emacs "bad". >Emacs >is provably no more powerful than vi in it's programming abilities, yet >it consumes vastly more resources. This is something clearly to be proud >of ... This is simply ignorant. Machine language entered on the console via DIP switches is provably no more powerful than your favorite HLL, be it C, Pascal, C++, Lisp, Ada, Prologue, or whatever. "Power" is a fairly useless measure of the merit of a program when other factors such as ease of use, portability, robustness, expandability, customizability, etc. aren't also evaluated. -- Dave Sill (de5@ornl.gov) It will be a great day when our schools have Martin Marietta Energy Systems all the money they need and the Air Force Workstation Support has to hold a bake sale to buy a new bomber.