wilber@alice.UUCP (10/24/87)
Eric Green sez: >1) If there is NO security, then there is nothing to get around, and, >2) If there is NO security, then there is DEFINITELY no need to get > around it. > >Remember, RMS's background is not commercial high-security data >processing, but, rather, academia, research, and program development, >where security is actually an IMPEDIMENT to productivity, because it >impairs the sharing of code, algorithms, test data, and other things >of that sort. If I had no file security on my single user machine it would be a major impediment to my productivity since about once a week I would accidently trash the system by deleting or overwriting some critical file I didn't intend to modify. Being permanently logged in as super user is like carrying a loaded gun everywhere you go. Even more fundamental is memory protection so one rogue process doesn't bring the system crashing down. I once did some hacking under MS-LOSS (pity me) and every time a pointer in some undebugged piece of code went astray the kernel (or what passes for a kernel in MS-LOSS) would get wedged and I'd have to reboot the system. In UNIX, where the superblock in core doesn't always coincide with what's on disk, this could fry your file system. What RMS could do without violating his security philosophy is provide the standard UNIX protection capabilites except with no passwords. That way anyone who wanted to could log in as root whenever there was a reason for it but normally the system would protect you from your own stupidity. On another GNU matter that has been brought up: Yeah, the GNU software eats up a lot of memory (GNU Emacs fits on my machine but Scheme doesn't) but RMS is right to put the emphasis on making things fast and simple instead of squeezing out bytes. In a few more years we'll all have desk top PC's with 64Mb. So why sweat it?
farren@gethen.UUCP (11/02/87)
In article <7399@alice.UUCP> wilber@alice.UUCP writes: >... RMS is right to put the emphasis on making things fast and simple >instead of squeezing out bytes. In a few more years we'll all have >desk top PC's with 64Mb. So why sweat it? But GNU Emacs is neither fast nor simple. Why sweat it? Because we have to; we don't have desk top PC's with 64MB, and when we do, who's to say that GNU won't have grown to follow? Please note: this is NOT a flame about RMS's programming ability. GNU Emacs is a wonderful thing, especially considering the manner in which it has been written and distributed. Thanks are due to RMS for having done it at all, but I sure do wish that he'd done it more compactly. -- ---------------- Michael J. Farren "... if the church put in half the time on covetousness unisoft!gethen!farren that it does on lust, this would be a better world ..." gethen!farren@lll-winken.arpa Garrison Keillor, "Lake Wobegon Days"
matt@oddjob.UChicago.EDU (D 1 4 U 2 C) (11/02/87)
Why is there all this talk that Richard Stallman's GNU operating system will not have even the most elementary security features? If this is the declared intent of the GNU project, would somebody point me to a reference? It seems to me that a very few people on the net asserted without evidence that they expected GNU to have no protection mechanisms, and now lots of people believe it! Matt Crawford
randy@umn-cs.UUCP (Randy Orrison) (11/03/87)
In article <7399@alice.UUCP> wilber@alice.UUCP writes: >What RMS could do without violating his security philosophy is provide >the standard UNIX protection capabilites except with no passwords. >That way anyone who wanted to could log in as root whenever there was a >reason for it but normally the system would protect you from your own >stupidity. Or, he could implement standard UNIX protection capabilities as it is now, except supply the default /etc/passwd with all the password fields blank. And the default umask set to 0. That way, he (and others with similar feelings) could have their zero security, but others (with other needs) could change things... I really doubt that RMS has any intention of getting rid of such 'security' features as limitations on memory accesses. What we need here is for RMS or someone who knows him to let us know exactly what's going to be in GNU, so we can start putting in requests for what we want. (Does anyone know what's going to be in GNU? Does anyone know what's already in GNU? for example, how far along is the kernel? Is there a kernel yet?) Disclaimer: If i had time, i'd help. Maybe after I graduate and am only working 40 hours a week, instead of 60~ between school and work. -- Randy Orrison, University of Minnesota School of Mathematics UUCP: {ihnp4, seismo!rutgers!umnd-cs, sun}!umn-cs!randy ARPA: randy@ux.acss.umn.edu (Yes, these are three BITNET: randy@umnacca different machines)
kyle@xanth.UUCP (11/04/87)
In <14059@oddjob.UChicago.EDU>, matt@oddjob.UChicago.EDU (D 1 4 U 2 C) writes: > It seems to me that a very few people on the net asserted without > evidence that they expected GNU to have no protection mechanisms, > and now lots of people believe it! Particularly absurd are the claims that there will be no memory protection. Memory protection in a multi-tasking operating system is not paranoia, it's common sense.
nate@cpocd2.UUCP (11/05/87)
In article <278@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >GNU Emacs is a wonderful thing, especially considering the manner in which >it has been written and distributed. Thanks are due to RMS for having >done it at all, but I sure do wish that he'd done it more compactly. I'm curious. How much smaller do you think GNU Emacs could be and still have the functionality and expandability that it currently has? In other words, if RMS were to start over from scratch with Emacs, do you think he (or anyone else, for that matter) would be able to make either the sources or the executable be significantly smaller? My guess is no. --woodstock -- "How did you get your mind to tilt like your hat?" ...!{decwrl|hplabs!oliveb|pur-ee|qantel|amd}!intelca!mipos3!cpocd2!nate <domainish> : nate@cpocd2.intel.com ATT : (602) 961-2037