Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!harvard!husc6!panda!genrad!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!usc-oberon!blarson From: blarson@usc-oberon.UUCP (Bob Larson) Newsgroups: net.arch,net.unix Subject: Re: Arch support for C Message-ID: <316@usc-oberon.UUCP> Date: Wed, 7-May-86 09:17:31 EDT Article-I.D.: usc-ober.316 Posted: Wed May 7 09:17:31 1986 Date-Received: Sun, 11-May-86 03:22:47 EDT References: <817@harvard.UUCP> <460@cubsvax.UUCP> Reply-To: blarson@usc-oberon.UUCP (Bob Larson) Organization: USC Computing Services, Los Angeles, CA Lines: 59 Xref: linus net.arch:2942 net.unix:7157 In article <399@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >As to the superiority of UNIX over other operating systems, there are >few who think UNIX couldn't be improved. The big question is how? >I'm sure we will be seeing a rapid evolution of UNIX and UNIX-like >operating systems as multi-tasking micros and multi-processing minis >become mandatory state of the art, rather than expensive luxuries. >Hopefully, a few of them won't be "designed by commitee", Unix >started out right (a small group trying good ideas), but evolved >into a slow memory pig. Which leads to the UNIX definition in the os9/68k users manual: "An operating system similar to os-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers." >It would be nice to see Unix modularized, so that the whole kernal >doesn't have to be re-linked just to add two lines of code to a >driver. As in os9. >It would be nice if the queuing and signalling as well as >the context switches could be cleaned up. >It would be nice to have >generic "transaction" mechanisms similar to pipes, so that work could >be shared between processes. Are os9/68k's named pipes what you are looking for? >It would be nice to have locks, so that >processes that wish to recieve input from several processors could do >so in real time. >It would be nice if "system libraries" were "sharable" >so that less copies of "printf" were taking up swap space. As in os9/68k, but I prefer how it is done in primos 19.4 and beond. (Primos uses some hardware support: fault bit on pointers.) >It would >be nice if all but the bare bones drivers could be "tasks" rather than >part of the kernal, so that only that which was needed at the moment >would sit in core. I think os9/68k has what you are asking for here. >The list goes on, but most has been hashed to death already. And much of it is unique to unix. Not all "Unix-like" operating systems are bug-for-bug compatable. >If we wish to come up with better products, we have to look at both the >best and the worst in the best and worst of systems and languages, >operating systems, and archetictures. I haven't seen a system yet >that is so good that it can't be improved, or a system so bad that >there wasn't at least one or two good features in it. I agree. -- Bob Larson Arpa: Blarson@Usc-Ecl.Arpa Uucp: ihnp4!sdcrdcf!usc-oberon!blarson