moriarty@fluke.UUCP (Jeff Meyer) (09/29/85)
In article <236@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: >> All in all, a very holistic system to program for. > >*FLAME ON* You just blew your credibility buddy *FLAME OFF* > >Seriously, though. What makes OS/9 more "holistic" than UNIX? Back when >I was a tadpole "holism" was merely a method of approaching a problem. >It meant looking at the problem as a whole instead of a bunch of little >unconnected peices. The opposite is "reductionism" (not "conventionalism"), >which means breaking the problem down into parts small enough to deal with. Egads! I can't exist on the net without credibility! What I meant was that OS-9, *as an operating system* seems to have been designed with a unified, complete and solid idea of what they wanted and how in general it was to be implemented (though the actual software is quite modular in form, which would not be holistic). In particular, after watching several revisions of OS-9 come along with new features, I've been startled with how easily the new features fit into the current call structure of the operating system. Opening a named pipe is done through open(), and you read and write from it with no special features like sockets, etc. Forks are done by giving the name of your function and the parameters to a OS-9 system call, and the routine is forked into a child process -- no having to place both parent and child code into a big "if" statement. All these features seem to have been snuggled into the old OS call interface with no problem a'tall (although this is less obvious at the shell level). I admit that I was using the term in a manner one associates with Japanese car commercials... "WHAT TO DO IN CASE OF AN ALIEN ATTACK: ONE) Hide beneath the seat of your plane and look away. TWO) Avoid eye contact. THREE) If there are no eyes, avoid all contact." Moriarty, aka Jeff Meyer ARPA: fluke!moriarty@uw-beaver.ARPA UUCP: {uw-beaver, sun, allegra, sb6, lbl-csam}!fluke!moriarty <*> DISCLAIMER: Do what you want with me, but leave my employers alone! <*>
peter@graffiti.UUCP (Peter da Silva) (10/02/85)
> In article <236@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: > >> All in all, a very holistic system to program for. > > > >*FLAME ON* You just blew your credibility buddy *FLAME OFF* > > Egads! I can't exist on the net without credibility! Damn straight. Sorry about that (dusts off credibility & hands it back), but I had just come here from net.med, or was that net.stoll? I know, I shouldn't go anywhere but the bathroom after visiting net.med, let alone a real live techy group (as opposed to a pop group?). Apology accepted? > What I meant was that OS-9, *as an operating system* seems to have been > designed with a unified, complete and solid idea of what they wanted and how > in general it was to be implemented (though the actual software is quite > modular in form, which would not be holistic). In particular, after > watching several revisions of OS-9 come along with new features, I've been > startled with how easily the new features fit into the current call > structure of the operating system. Opening a named pipe is done through > open(), and you read and write from it with no special features like I like. I like. > sockets, etc. Forks are done by giving the name of your function and the > parameters to a OS-9 system call, and the routine is forked into a child > process -- no having to place both parent and child code into a big "if" Ever done forks from assembler on a PDP-11? It's even worse. Look at the interface some time. > statement. All these features seem to have been snuggled into the old OS > call interface with no problem a'tall (although this is less obvious at the > shell level). I admit that I was using the term in a manner one associates > with Japanese car commercials... Or net.med (seeya. I gotta go the the bathroom).
henry@utzoo.UUCP (Henry Spencer) (10/03/85)
> .... Opening a named pipe is done through open()... That's how it works in Unix too. > ... you read and write from it with no special features like sockets... Same comment. Sockets are a Berkleyism, and arguably a botch. > ... Forks are done by giving the name of your function and the > parameters to a OS-9 system call, and the routine is forked into a child > process -- no having to place both parent and child code into a big "if" > statement... This is actually a nice idea; hold on five minutes while I write a C function to do it under Unix... (Yes, there is a defect in that said function probably ought to be a standard feature rather than a local hack.) General comments: There are definitely a lot of places where Unix could be cleaned up if you started from scratch. Of course, this would break compatibility with every other Unix on Earth, a serious defect considering that portability is one of Unix's strong points. However, some of the things that look strange do make sense if you look at them closely and understand what they are used for. (For example, the fork/exec split looks odd until you try to figure out how to implement things like i/o redirection and shell pipes without it; the ability to modify the environment after the fork but before the exec is important.) Before attempting to "fix Unix's mistakes", it is wise to understand which of them aren't mistakes. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
kim@mcrware.UUCP (Kim Kempf) (10/07/85)
> > .... Opening a named pipe is done through open()... > > That's how it works in Unix too. > > > ... you read and write from it with no special features like sockets... > > Same comment. Sockets are a Berkleyism, and arguably a botch. > Ok, some of you UNIX-sheltered programmers need a lesson on advanced OS-9 programming topics. OS-9 pipes can be "named" much like disk directory files: open("/pipe/msg_socket", ...) Any process can open this pipe by name. The process need not have a common ancestor with the creating process creating the pipe. Another feature of the named pipes is that the pipe file manager makes the opened named pipes look like disk directories. For example, the command: copy *.c -w=/pipe/files copies all files (*.c) into the pipe named "files". A subsequent: dir /pipe/files will display the names of the pseudo-files waiting in the pipe. As the files are read, the pseudo files are removed from the pipe. The files are read in FIFO order from the pipe. The named pipes being described are much easier for the programmer to use. One need not set up I/O path for forking the pipe-reader, not to mention the overhead involved is performing same. This facility has many practical applications that can ease a programmer's houskeeping duties. > > ... Forks are done by giving the name of your function and the > > parameters to a OS-9 system call, and the routine is forked into a child > > process -- no having to place both parent and child code into a big "if" > > statement... > > This is actually a nice idea; hold on five minutes while I write a C > function to do it under Unix... (Yes, there is a defect in that said > function probably ought to be a standard feature rather than a local hack.) > The UNIX-style fork REQUIRES memory management to clone the data and stack area for the new process. If this were done without memory management, pointers would change causing the forked process to crash. > > General comments: There are definitely a lot of places where Unix could > be cleaned up if you started from scratch. Of course, this would break > compatibility with every other Unix on Earth, a serious defect considering > that portability is one of Unix's strong points. Not entirely. The proliferation of UNIX source code has resulted in numerous hacks that compromise portability. Just try porting between BSD 4.2 and System V. > things that look strange do make sense if you look at them closely and > understand what they are used for. (For example, the fork/exec split looks > odd until you try to figure out how to implement things like i/o redirection > and shell pipes without it; the ability to modify the environment after > the fork but before the exec is important.) Must not be too hard to do. OS-9 does it quite well. And much faster! > Before attempting to "fix Unix's mistakes", it is wise to understand > which of them aren't mistakes. ...but kludges in disguise! ---------------- Kim Kempf, Microware Systems Corporation {{cornell,decvax,ihnp4,sdcsvax,tektronix}!uw-beaver}\ {allegra,gatech!sb1,hplabs!lbl-csam,decwrl!sun,sunup} >!fluke!mcrware!kim {ssc-vax,hplsla,wavetek,physio,cae780,tikal,telematic}/
peter@graffiti.UUCP (Peter da Silva) (10/16/85)
> Ok, some of you UNIX-sheltered programmers need a lesson on advanced OS-9 > programming topics. OS-9 pipes can be "named" much like disk directory > files: > ... That's a very nice interface. I assume that /pipes is analogous to a mounted device in UNIX, but that OS/9 allows non-block devices to be mounted in the file system. As for the rest of your message: we don't need the OS/9-UNIX flames. You'll get my MMU when you pry my cold, dead, fingers off the keyboard. As for the differences in fork()-ing, I would like to comment that you're talking about the interface to fork(), as opposed to the implementation. Or does OS/9 fork just set up a process table and put the address of the routine you hand it into the child processes PC? It should be obvious why that technique isn't appropriate for a protected memory environmnent like UNIX'. It's a much better technique for a non- protected system like OS/9 or XINU, yes. But in any case... OS/9 is not the same sort of system as UNIX. It doesn't need some of UNIX features, and vice versa. They are both nice systems for personal computers on up. If you want sheer speed & efficiency, get OS/9. I prefer a secure system where programs can't clobber the O/S without trying very, very, hard. I would love to get some more information on OS/9. I have been totally unable to even see the thing run. Would you people at Microware be so kind as to let me know how to find out more about this paragon.
mouse@mcgill-vision.UUCP (der Mouse) (10/20/85)
> > > .... Opening a named pipe is done through open()... > > That's how it works in Unix too. > > > ... you read and write from it with no special features like sockets... > > Same comment. Sockets are a Berkleyism, and arguably a botch. > Ok, some of you UNIX-sheltered programmers need a lesson on advanced OS-9 > programming topics. OS-9 pipes can be "named" much like disk directory > files: > > open("/pipe/msg_socket", ...) > > Any process can open this pipe by name. The process need not have a common > ancestor with the creating process creating the pipe. Another feature of Well, under 4.2, you can get this effect with AF_UNIX sockets. The (syscall-level) interface is not as nice, but that's what library routines are for, and the UNIX philosophy is (among other things) that the kernel should contain a MINIMUM amount of code. Yes, yes, I know, tell that to Berserkeley (1Mb kernel is it now?). > ancestor with the creating process creating the pipe. Another feature of > the named pipes is that the pipe file manager makes the opened named pipes > look like disk directories. For example, the command: > copy *.c -w=/pipe/files > copies all files (*.c) into the pipe named "files". A subsequent: > dir /pipe/files > will display the names of the pseudo-files waiting in the pipe. As the files > are read, the pseudo files are removed from the pipe. The files are read in > FIFO order from the pipe. Neat, a pseudo filesystem in a pipe. Hang on while I write that for UNIX.... Just a minute now - can you access any file in the pipe randomly, seek within it, etc? Or just read them in order? > > [ .... ] > The UNIX-style fork REQUIRES memory management to clone the data and stack > area for the new process. If this were done without memory management, > pointers would change causing the forked process to crash. So tell me, how do pdp11s run UNIX? > [ ... ] > > things that look strange do make sense if you look at them closely and > > understand what they are used for. (For example, the fork/exec split looks > > odd until you try to figure out how to implement things like i/o redirection > > and shell pipes without it; the ability to modify the environment after > > the fork but before the exec is important.) > Must not be too hard to do. OS-9 does it quite well. And much faster! I always knew there was a reason vfork() existed! :-) > > Before attempting to "fix Unix's mistakes", it is wise to understand > > which of them aren't mistakes. > ...but kludges in disguise! Yes, but there ARE some nice features, not mistakes, not kludges even. Like the all-commands-are-just-programs idea (though the latest csh has let's see now, about 50 or so builtin commands; I guess we must conclude that nothing is ever quite perfect). Shall we move to net.religion.computers? Or maybe net.unix? -- der Mouse {ihnp4,decvax,akgua,etc}!utcsri!mcgill-vision!mouse philabs!micomvax!musocs!mcgill-vision!mouse Hacker: One responsible for destroying / Wizard: One responsible for recovering it afterward
kim@mcrware.UUCP (Kim Kempf) (10/27/85)
> > Ok, some of you UNIX-sheltered programmers need a lesson on advanced OS-9 > > programming topics. OS-9 pipes can be "named" much like disk directory > > files: > > ... > > That's a very nice interface. I assume that /pipes is analogous to a mounted > device in UNIX, but that OS/9 allows non-block devices to be mounted in the > file system. > As I said, UNIX-sheltered. Try to comprehend I/O devices that have no association with the disks. An "inode" is not required for OS-9 pipes or any other device, and therefore needs no disk access to open such. OS-9 does not have a mount concept (at least not yet). OS-9 has no homogenous file system. Each disk device contains its own discrete "file system". A disk directory search is not required to open a character device (or any other device). This allows OS-9 to run on systems without disks. Devices appear to the system upon access to a driver. The block/non-blockness of a device is controlled at a level above the driver, in the file manager. Four common file managers are used in OS-9 systems: RBF (random block), SBF (sequential block), SCF (sequential character) and NET (network access). > As for the rest of your message: we don't need the OS/9-UNIX flames. > You'll get my MMU when you pry my cold, dead, fingers off the keyboard. No flames intended. Just pointing out the alternative to an MMU or swapping to disk... you choose the more expensive and complicated.... > As for the differences in fork()-ing, I would like to comment that you're talking about > the interface to fork(), as opposed to the implementation. Or does OS/9 fork > just set up a process table and put the address of the routine you hand it > into the child processes PC? > No. I am talking about the implementation. The UNIX fork(2) takes no arguments. It's effect to to create a clone of the process, the only difference being the process ID. To do this memory-management is required to map the same logical address space as the parent process, or a swapping facility to place the data and stack areas of the child process in the same physical addresses as the parent. The OS-9 fork is more like a combination of the UNIX fork() and exec() calls rolled into one. > It should be obvious why that technique isn't appropriate for a protected > memory environmnent like UNIX'. It's a much better technique for a non- > protected system like OS/9 or XINU, yes. > Why not? What does memory protection have to do with the way fork works? Is UNIX memory protected without an MMU? May I remind you that memory protection is provided by hardware, not a software. UNIX will be just as easily trashed as OS-9 without the hardware memory protection facility. >But in any case... OS/9 is not the same sort of system as UNIX. It doesn't need >some of UNIX features, and vice versa. They are both nice systems for personal >computers on up. If you want sheer speed & efficiency, get OS/9. I prefer a >secure system where programs can't clobber the O/S without trying very, very, >hard. > That, again, is a function of hardware. Unless you have hardware MMU, it will be easy to clobber ANY OS. OS-9's file system is much more rugged and extensible that UNIX. "Lest ye appreciate OS-9 when thine gods of the electromotive force frown" ---------------- Kim Kempf, Microware Systems Corporation {{cornell,decvax,ihnp4,sdcsvax,tektronix}!uw-beaver}\ {allegra,gatech!sb1,hplabs!lbl-csam,decwrl!sun,sunup} >!fluke!mcrware!kim {ssc-vax,hplsla,wavetek,physio,cae780,tikal,telematic}/
jimomura@lsuc.UUCP (Jim Omura) (11/09/85)
For those of you who have wanted to learn what OS-9 is all about,
I have just seen Peter Dibble and Dale Pluckett's book the OS-9 Users
Guide in the local Radio Shack. It's selling for something like
$22.00 (Canadian). I expect you'll find out enough to decide whether
you'd like to get into it.
As a further note, some people 'here' have said that they'd like
to try running OS-9. In fact, it just occurred to me that you *can*.
There are 'ROS9's around. These are 'Remote OS-9' systems similar
in concept to RCPM's. As I understand it, they generally allow system
level access and extended 'help' systems. Don't confuse these with
other OS-9 BBS's. I used to run an OS-9 BBS called True North Database,
but I never allowed system level access. As such you only got a hint
of what the underlying system was. To find out if there's an ROS9
near you, I suggest you check out back issues of Rainbow magazine.
(We *all* read Rainbow don't we? :-). You may get a lead on an ROS9
near you through the grapevine (local BBS's). Otherwise, post a message
'here' and I'll try to dig one up.
Cheers! -- Jim O.
PS: Is it proper for me to plug the 'os.9' conference on BIX, which
I'm moderating--and posting just about the only information on?
Oh well, I just did anyway ...
:-)
--
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
Compuserve: 72205,541
MTS at WU: GKL6wb6rqn@yojna1.UUCP (Brian Lloyd) (11/13/85)
> > For those of you who have wanted to learn what OS-9 is all about, > I have just seen Peter Dibble and Dale Pluckett's book the OS-9 Users > Guide in the local Radio Shack. It's selling for something like > $22.00 (Canadian). I expect you'll find out enough to decide whether > you'd like to get into it. > > [...] > Cheers! -- Jim O. > I called Microware and ordered the full set of OS-9-68K manuals. Very interesting, albeit not light, reading. If you really want to know what the OS can do, there is no better infomation source than the Manufacturer (If they are an infomation source, am I an information sink?). Brian Lloyd, WB6RQN ...![bellcore!cp1]!yojna1!wb6rqn
henry@utzoo.UUCP (Henry Spencer) (11/15/85)
> As I said, UNIX-sheltered. Try to comprehend I/O devices that have no > association with the disks. An "inode" is not required for OS-9 pipes or > any other device, and therefore needs no disk access to open such.... How about OS-9-sheltered? Try to comprehend that Unix file systems do not have to use any particular storage technology; in particular, they do not need to be on disks. It's easy to have them in RAM, almost as easy to have them in ROM. Furthermore, Unix pipes do not have to be implemented as files at all -- that's just the way most Unixes happen to do them. On the system I'm writing this on, pipes live in a little RAM filesystem; the resulting improvement in speed is substantial. We haven't bothered bypassing the file machinery completely because we no longer have much incentive to. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
kim@mcrware.UUCP (Kim Kempf) (11/17/85)
> > As I said, UNIX-sheltered. Try to comprehend I/O devices that have no > > association with the disks. An "inode" is not required for OS-9 pipes or > > any other device, and therefore needs no disk access to open such.... > > <5140@utzoo.UUCP> Henry Spencer: > > How about OS-9-sheltered? Try to comprehend that Unix file systems do not > have to use any particular storage technology; in particular, they do not > need to be on disks. It's easy to have them in RAM, almost as easy to have > them in ROM. Furthermore, Unix pipes do not have to be implemented as files Try to comprehend an operating system that doesn't require hacking to implement the "concepts" correctly (or differently). No matter what one desires in UNIX, someone out there has probably hacked it in. When I speak of the operation of UNIX, I am relying on the common implementations, not Joe Blow Corp's hack-port to the PC Bannana Jr., Model 3B2. Common UNIX (SysV or 4.2) serial or pipe device opens require a disk access to obtain the inode for the device. True, the device describing inodes can (by hacks) be placed in rom. Try to change them while the system is running! Sure it UNIX could be changed to do it. Why not admit that OS-9 does at least one thing better than UNIX? OS-9 has enhanced many of the great attributes of UNIX. Let's address the subject at hand, rather than clinging to our treasured tidbits of UNIX trivia and history. ;-) ---------------- "...to seek out new life and new civilizations....", etc, etc. Kim Kempf, Microware Systems Corporation {{cornell,decvax,ihnp4,sdcsvax,tektronix}!uw-beaver}\ {allegra,gatech!sb1,hplabs!lbl-csam,decwrl!sun,sunup} >!fluke!mcrware!kim {ssc-vax,hplsla,wavetek,physio,cae780,tikal,telematic}/
kim@mcrware.UUCP (Kim Kempf) (11/17/85)
> <6140@utzoo.UUCP> Henry Spencer: > > How about OS-9-sheltered? Try to comprehend that Unix file systems do not > have to use any particular storage technology; in particular, they do not > need to be on disks. It's easy to have them in RAM, almost as easy to have > them in ROM. And easy to change one of those beasts? If device descriptors are to live in ROM, there must be a way of updating them unless you are resigned to a static system. Also, can they be handled from ROM, RAM or disk simultaneously? > Furthermore, Unix pipes do not have to be implemented as files > at all -- that's just the way most Unixes happen to do them. On the system > I'm writing this on, pipes live in a little RAM filesystem; the resulting > improvement in speed is substantial. We haven't bothered bypassing the > file machinery completely because we no longer have much incentive to. Or have you had as much hacking on the pipes as you can stand? I don't see any reason pipe access should be tied to the filesystem in any manner other than the "common access method". To access the file systems only slows things down. Isn't speed the major concern of pipes? I suppose on high-power hardware with CPU cycles to spare this isn't much of a concern. The fewer CPU cycles the kernel uses means more for the user programs. ---------------- Kim Kempf, Microware Systems Corporation {{cornell,decvax,ihnp4,sdcsvax,tektronix}!uw-beaver}\ {allegra,gatech!sb1,hplabs!lbl-csam,decwrl!sun,sunup} >!fluke!mcrware!kim {ssc-vax,hplsla,wavetek,physio,cae780,tikal,telematic}/
henry@utzoo.UUCP (Henry Spencer) (11/26/85)
> And easy to change one of those beasts? If device descriptors are to live in > ROM, there must be a way of updating them unless you are resigned to a static > system. If you put it in ROM, you can't change it; that's the way the technology works, guys. But it's fine for stuff you don't want to change. > Also, can they be handled from ROM, RAM or disk simultaneously? I'm not quite sure what you mean. Certainly the system on which I am writing this has one of its filesystems in RAM and the rest on disk. There would be no great problem writing a driver that mixed media within one filesystem, since nothing but the driver *cares* how the bits are stored, although using the combination effectively could get complicated. > Or have you had as much hacking on the pipes as you can stand? I don't see > any reason pipe access should be tied to the filesystem in any manner other > than the "common access method". To access the file systems only slows > things down... There are people who have implemented Unix pipes completely independently of the file system. We simply didn't think it was worth the effort. Our time is valuable; we didn't think there was enough further performance improvement to be had (given that things like system-call overhead, data copying, etc. are invariant) to be worth it. It's probably worth it if you're starting from scratch, but the overhead of going through the filesystem code is a performance nuisance rather than a performance disaster. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry