haugj@pigs.UUCP (Joe Bob Willie) (08/20/88)
In article <Aug.18.12.47.56.1988.19639@topaz.rutgers.edu> kaldis@topaz.rutgers.edu (Theodore A. Kaldis) writes: >You are confusing *Dennis* Ritchie, the developer of the C programming >language (and co-author, along with Brian Kernighan, of the book of >the same title) with Ken *Thompson*, the developer of UNIX (which >ironically started out as a *single*-user operating system). this really belongs in comp.os.silly-questions, but here goes anyway ... is unix REALLY a multi-user operating system? or does it just act that way because it is a multi-tasking o/s? i know most of the actual history behind unix, and i recall reading once that dennis didn't consider unix to even be an operating system. so, what features does unix have which prevents it from being a single user operating system with a very clever single user program (init) running? -- jfh@rpp386.uucp (The Beach Bum at The Big "D" Home for Wayward Hackers) "Never attribute to malice what is adequately explained by stupidity" -- Hanlon's Razor
gwyn@smoke.ARPA (Doug Gwyn ) (08/21/88)
In article <365@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >is unix REALLY a multi-user operating system? or does it just act that way? If it looks like a duck, walks like a duck, quacks like a duck, ... If you don't define your terms, how are we expected to be able to understand your question? The answer has to be yes, a multi-user OS really is a multi-user OS. >i recall reading once that dennis didn't consider unix >to even be an operating system. This is a funnier UNIX joke than 99% of the ones recently posted.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (08/22/88)
In article <365@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >so, what features does unix have which prevents it from being a single >user operating system with a very clever single user program (init) >running? Primarily, the concept of user and group ids and protections based on them. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/23/88)
In article <365@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: | is unix REALLY a multi-user operating system? or does it just act that | way because it is a multi-tasking o/s? i know most of the actual history | behind unix, and i recall reading once that dennis didn't consider unix | to even be an operating system. Any multitasking o/s can be a multiuser system, provided that the user agent (shell or whatever) is a normal process. Given this, you can have multiple user agents running, connected to several users. Note that this does not claim that any such o/s will work WELL for multiple users, since the issue of response, etc, may make a system impractical with more than one user. The dispatcher must give the CPU to the correct processes to allow adequate response, often enough enough to give the illusion of continuity, keep long running jobs going, and do all of this without using all the resources of the machine deciding who runs next. It is desirable to have a memory manager which can swap and/or move processes in such a way that useful work can be done in a reasonable memory space. It is desirable to have front end processing of incoming characters, either in something like a device driver, or using a separate front end communications computer. In my opinion, any multasking system fits the definition of multiuser, but there are a lot of other details which make it a GOOD multiuser system. Comments, clarifications, etc will undoubtedly follow. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
barmar@think.COM (Barry Margolin) (08/23/88)
In article <11945@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > Any multitasking o/s can be a multiuser system, provided that the user >agent (shell or whatever) is a normal process. Given this, you can have >multiple user agents running, connected to several users. If "multiuser" means that more than one person can use the system simultaneously, that is true, but I don't think this is a reasonable definition of multiuser. For example, Symbolics Lisp Machines run a multitasking O/S, and you can have multiple user agents (one on the bitmapped console, others on Telnet clients, X servers, or serial terminals) , but all the processes share a single address space. In particular, the userid and the file server connections are global variables, so all the processes are considered to be owned by the same user. So, multiple people can be using the system, but only one "user" is ever logged in. There are other pieces of global state that might not cause trouble, but would probably cause confusion among multiple users. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
spolsky@eniac.seas.upenn.edu (Joel Spolsky) (08/24/88)
In article <11945@steinmetz.ge.com| davidsen@crdos1.UUCP (bill davidsen) writes: | In article <365@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: | | | is unix REALLY a multi-user operating system? or does it just act that | | way because it is a multi-tasking o/s? | | Any multitasking o/s can be a multiuser system, provided that the user | agent (shell or whatever) is a normal process. Given this, you can have | multiple user agents running, connected to several users. | | Note that this does not claim that any such o/s will work WELL for | multiple users ... Right! For example, OS/2 (ack barf) is a multitasking operating system that will never work very well for multiple users, simply because the assumption that there is only one user is so pervasive: --there is no concept of file ownership --a single process, the "foreground" process, gets the largest slices of cpu time because that's the one that the single user sees --the system assumes one keyboard, one mouse, and one monitor, and probably (I dont know this) assumes that the monitor is mapped into main memory. Joel Spolsky Bell Communications Research and Yale University (neither of whom I speak for :-)
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/25/88)
In article <4871@netnews.upenn.edu> spolsky@eniac.seas.upenn.edu.UUCP (Joel Spolsky) writes: | In article <11945@steinmetz.ge.com| davidsen@crdos1.UUCP (bill davidsen) writes: | | In article <365@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: [ joe's question, my answer, joel's agreement with me ] | Right! For example, OS/2 (ack barf) is a multitasking operating system | that will never work very well for multiple users, simply because the | assumption that there is only one user is so pervasive: [ good reason's not to run OS/2 on your VAX ] One other which comes to mind: processes are allowed to diddle their own priority. I like the idea, but only if I'm the only one allowed to use it! -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
madd@bu-cs.BU.EDU (Jim Frost) (08/25/88)
In article <4871@netnews.upenn.edu> spolsky@eniac.seas.upenn.edu.UUCP (Joel Spolsky) writes: |Right! For example, OS/2 (ack barf) is a multitasking operating system |that will never work very well for multiple users, simply because the |assumption that there is only one user is so pervasive: [...] | --the system assumes one keyboard, one mouse, and one monitor, and | probably (I dont know this) assumes that the monitor is mapped | into main memory. It's possible to change the video driver to work with anything but the supplied drivers certainly want video buffer access. jim frost madd@bu-it.bu.edu
mitch@Stride.COM (Thomas Mitchell) (08/27/88)
>| | is unix REALLY a multi-user operating system? ... because it is a multi-tasking o/s? Yes, not because it is multi-tasking but because of ownership. >| Any multitasking o/s can be a multiuser system, provided that the user >| agent (shell or whatever) is a normal process. No must have ownership or all tasks look the same. Without ownership it is only multi-tasking. Well -- multitasking and multiuser. Each person has a differing concept about multi everything (user, tasking, processor). In a multiuser OS there should be the concept of ownership. However, the hooks of ownership need not be available to the user. A multiuser OS also need not be multitasking. As I thought about all the permutations it became useful to write them down. Start with a single user OS. (loader) Then a multitasking single user OS. (multi-loader) Then move to a virtual operating system which permits any user to believe that he is the only user on the machine. The OS imposes virtual (solid) walls between one user and another. If this is a multi user environment we may have multiple users on different terminals. No user can see, feel or in any way learn about the other. When one user is 'idle' the OS places an idle loop in his time slice so even a stop watch cannot see the other user. The simplest of this type of virtual environment would permit the user a single task. Up scale from this each user could have the option of multiple processes (tasks). Down scale, only one of many could be active at any time. Say the machine has one console. When I sit down and login there is no clue that you were there yesterday. Then begin to provide tools to share resources. Visible ownership advisory Visible ownership enforced Invisible ownership enforced Resource locking advisory Resource locking enforced Quotas (processor, disk, I/O, printer paper) Communication Services -- virtual users (lpr) --------------------------------------------------------------------------- Unix is not the OS of the future. It is the environment the OS of the future will be written in. -- Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702)322-6868 TWX: 910-395-6073 FAX: (702)322-7975 MicroSage Computer Systems Inc. Opinions expressed are probably mine.
bell@fmeed1.UUCP (John Bell) (09/01/88)
> In article <365@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: > ... >i recall reading once that dennis didn't consider unix >to even be an operating system. I believe that the refered-to comment is in "UNIX Implementation" by *Ken Thompson*, published in The Bell Systems Technical Journal, Vol. 57, No. 6, Part 2 [July-August 1978] (the famous (first) UNIX issue). In section 4.3 of that article, Ken says (remember, refering to Version 7!): " There are some other things that the system does for the user - a little accounting, a little tracing/debugging, and a little access protection. Most of these things are not very well developed because our use of the system in computing science research does not need them. There are some features that are missed in some applications, for example, better inter-process communication. _The_UNIX_kernel_is_an_I/O_multiplexer_more_than_a_complete_operating_ _system_. [Emphasis added by bell@fmeed1] This is as it should be. Because of this outlook, many features are found in most other operating systems that are missing from the UNIX kernel. For example, the UNIX kernel does not support file access methods, file disposition, file formats, file maximum size, spooling, command language, logical records, physical records, assignment of logical file names, logical file names, more than one character set, an operator's console, an operator, log-in, or log-out. Many of these things are symptoms rather than features. Many of these things are implemented in user software using the kernel as a tool. " __________ The quotation is copyright 1978 American Telephone & Telegraph Company, and is reproduced without its permission. UNIX is a (registered?) trademark of AT&T. -- John D. Bell, c/o Ford Motor Co. Electronics Division - DPTC, Dearborn, MI voice: (313) 845-3040 UUCP: ...!uunet!umix!teemc!fmeed1!bell "You may be right, I may be crazy, But it just may be a lunatic you're looking for." - Billy Joel
darin@taurus.laic.uucp (Darin Johnson) (09/02/88)
> | | is unix REALLY a multi-user operating system? or does it just act that > | | way because it is a multi-tasking o/s? > | > | Any multitasking o/s can be a multiuser system, provided that the user > | agent (shell or whatever) is a normal process. > | Note that this does not claim that any such o/s will work WELL for > | multiple users ... > > Right! For example, OS/2 (ack barf) is a multitasking operating system > that will never work very well for multiple users, simply because the > assumption that there is only one user is so pervasive: > > --there is no concept of file ownership > --a single process, the "foreground" process, gets the largest slices > of cpu time because that's the one that the single user sees > --the system assumes one keyboard, one mouse, and one monitor, and > probably (I dont know this) assumes that the monitor is mapped > into main memory. Similar problems exist for Amiga. AmigaDOS is a fairly well built multi-TASKing operating system, but when you try to have multiple user's you run into some problems. File ownership is a problem, but isn't too severe (considering that you normally only let good friends on :-). The biggest problem is that a requester will pop up on the screen for certain AmigaDOS 'notifications' (such as 'please insert volume xx:'). There is a program to automatically deal with these though. Time slicing isn't a big deal, tasks have a normal concept of priority (since a single user often sees >1 window there isn't a concept of a "foreground process"). The most annoying problem though is when the user on the serial port runs a window oriented program (some versions of Emacs, a game, etc.) causing that to come up on your monitor. In my case, the user has dialed in on a modem using the only telephone line in the house, so it is a pain to call up and tell him what he's doing wrong :-) One of these days, I'll write a talk program... To summarize, here is a list of things that would make the Amiga a better multitasking machine. This probably applies to most multi-tasking machines also. 1) the concept of "owning" the monitor, keyboard, and mouse. (don't let user's on serial ports own them easily) 2) have programs know how to deal with stdin/stdout only. (for example, an Emacs program I use automatically pops up a new window to use, when it could easily just use ANSI terminal sequences) 3) have enough programs and commands that don't use graphics/etc. so that user's can get along. 4) a concept of "users". This can be as simple as "login joe" ala Lisp machines, or can have passwords, etc. Home directories, etc. would be nice. There are some other items I could list, but they aren't really that major. Darin Johnson (...pyramid.arpa!leadsv!laic!darin) (...ucbvax!sun!sunncal!leadsv!laic!darin) "All aboard the DOOMED express!"