chip@ateng.ateng.com (Chip Salzenberg) (01/10/89)
According to smryan@garth.UUCP (s m ryan): >Think of all the wonderful things Unix offers that NOS/VE doesn't: >- only two segments, static+heap and stack. >- no shared codes except libraries staticly assigned to segments. >- no unified command processing. >- no concept of subsystem which permit a layerring of commands. >- no segment=file concept so all disc io gets an extra transfer through > system buffers between the user space and discs. >- no ability for file and system security. "No ability for file and system security" indeed. I think the real bigotry here is quite obvious. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
bga@raspail.UUCP (Bruce Albrecht) (01/11/89)
In article <1989Jan9.114312.26821@ateng.ateng.com>, chip@ateng.ateng.com (Chip Salzenberg) writes: > "No ability for file and system security" indeed. > > I think the real bigotry here is quite obvious. Actually, Unix's file security is quite crude. Because it doesn't have access control lists for files, the only way to permit a file to specific users is to create new groups (if one is allowed) that include only those users. Last time I checked, it didn't have guardian procedures, either. I find it ironic that I have to explain in detail to Unix zealots why the group mechanism is inferior to the access control list mechanism for file permission. Unix has a lot of nice features, but file permissions isn't one of them.
peter@ficc.uu.net (Peter da Silva) (01/12/89)
I'm a UNIX Zealot, and I lust after access control lists... BUT... I don't see any conflict there. UNIX is just a programming model. There's no reason you can't have an operating system that supports those 30 or so core system calls... and can thus run UNIX software... that has any file security you want. I don't care what the thing looks like underneath, so long as I can run my UNIX programs and never have to parse weird file names (like PROJECTS*PETER.ALARMS/FOR(-1) or _DRA0:[USERS.PETER]ALARMS.FOR;32 or SY0:[310,320]ALARMS.FOR;2). And I really need a version of the bourne shell, for scripts, though I guess REXX would do in a pinch. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
stevee@ism780c.isc.com (Steve Ellingson) (01/13/89)
In article <2693@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I'm a UNIX Zealot, and I lust after access control lists... BUT... > >I don't see any conflict there. UNIX is just a programming model. There's no >reason you can't have an operating system that supports those 30 or so >core system calls... and can thus run UNIX software... that has any file >security you want. I don't care what the thing looks like underneath, so >long as I can run my UNIX programs and never have to parse weird file >names (like PROJECTS*PETER.ALARMS/FOR(-1) or _DRA0:[USERS.PETER]ALARMS.FOR;32 >or SY0:[310,320]ALARMS.FOR;2). > >And I really need a version of the bourne shell, for scripts, though I >guess REXX would do in a pinch. >-- >Peter da Silva, Xenix Support, Ferranti International Controls Corporation. >Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' >Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` >Opinions may not represent the policies of FICC or the Xenix Support group. You can probably satisfy your lusts with an Apollo. You get UNIX (both Sys V and BSD, along with a proprietary shell/ environment called Aegis), ACLs, and a pretty nice distributed file system. Of course, underneath the hood, it ain't UNIX... Steve ---------------------------- Steve Ellingson Interactive Systems stevee@ism780c.isc.com
dave@sea375.UUCP (David A. Wilson) (01/13/89)
From article <1135@raspail.UUCP>, by bga@raspail.UUCP (Bruce Albrecht): > > Actually, Unix's file security is quite crude. Because it doesn't have access > control lists for files, the only way to permit a file to specific users is > to create new groups (if one is allowed) that include only those users. Access control list are nice for some cases, but I have found them to be easily abused. For example, some systems allow wildcard specifications of usernames. I found a system in which many ACLs contained usernames like 'W*', 'WI*', 'TEST*', etc. It turned out that the system manager was too lazy to type in the 10 users with names starting in 'W' who were allowed to access certain files. Guess what happens when 1 year later a user is added to the system with a username that start with 'W'! Now you have to find and correct all the ACLs on the system. I think group ownership and group membership are far more managable than ACLs. Of course if you use group designators in ACLs things are much easier, but then the difference between ACLs and unix style permissions are much less distinct. Multiple-group membership ala 4.[23] BSD Unix is very powerful, but, unfortunately, the old one-user-one-group scheme of non-BSD Unix derivatives makes ACLs look more neccessary. :-( I still have not seen any convincing argument for ACLs being more secure than Unix permission bits. It's all in how you use them, and in how well the system software enforces access rights. > Last > time I checked, it didn't have guardian procedures, either. What's are guardian procedures? ------------------------ -- David A. Wilson uw-beaver!tikal!slab!sea375!dave
bga@raspail.UUCP (Bruce Albrecht) (01/16/89)
In article <229@sea375.UUCP>, dave@sea375.UUCP (David A. Wilson) writes: > Access control list are nice for some cases, but I have found them to be > easily abused. For example, some systems allow wildcard specifications of > usernames. [Example of misuse of wildcards deleted] > Now you have to find and correct all the ACLs on the system. > I think group ownership and group membership are far more managable than ACLs. If group membership allowed wildcards, you'd have the same problem of abuse. If group creation/modification is a privileged operation, the use of group permissions by a non-privileged user is worthless. Although the systems I have used with ACLs have not provided utilities to manage ACLs, it would have been easy to write a program or procedure to copy one file's ACL to another file, had I needed to do so often. > I still have not seen any convincing argument for ACLs being more secure > than Unix permission bits. It's all in how you use them, and in how well > the system software enforces access rights. Here's something you can't do with Unix group permissions: grant different access rights to different users. With CDC's NOS/VE, the following permissions are possible: read, execute, shorten, modify, append. I can create a log file that has append permission for everyone, read and append for one set of people, and read/write (shorten modify apppend) for a second set of people. > > Last > time I checked, it didn't have guardian procedures, either. > What's are guardian procedures? A procedure that is invoked whenever you open a file, that intercepts all I/O to perform filtering or security verification. It's not needed by a file that is only accessible via a program with setuid/setgid set. If, for example, you had a database with some sensitive data, you could still make it available for general access, if you had a guardian procedure return spaces for all sensitive fields for users not authorized to see them, and only allow some users to modify a subset of the fields, if any.
peter@ficc.uu.net (Peter da Silva) (01/16/89)
In article <1143@raspail.UUCP>, bga@raspail.UUCP (Bruce Albrecht) writes: > > > Last > time I checked, it didn't have guardian procedures, either. > > What's are guardian procedures? > A procedure that is invoked whenever you open a file, that intercepts all > I/O to perform filtering or security verification. A more transparent version of the beloved UNIX tradition of guarding files by only letting particular programs access them. The guardian, then, is the equivalent of setuid programs. By the way, see the winter '88 Usenix proceedings for "watchdogs", an implementation of guardians under UNIX. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (01/17/89)
bga@raspail.UUCP (Bruce Albrecht) writes: > > > Last time I checked, it didn't have guardian procedures, either. > > What are guardian procedures? > A procedure that is invoked whenever you open a file, that intercepts all > I/O to perform filtering or security verification. See: Bershad, Brian N., and C. Brian Pinkerton, "Watchdogs - Extending the UNIX File System," _Computing_Systems_, Vol 1, No 2, Spring 1988, University of California Press. --Karl
dhesi@bsu-cs.UUCP (Rahul Dhesi) (01/17/89)
In article <1143@raspail.UUCP> bga@raspail.UUCP (Bruce Albrecht) writes: >Here's something you can't do with Unix group permissions: grant different >access rights to different users. But consider the set-user-id bit. It sacrifices convenience but gives you the awesome power to allow users with middle initials of i, j, k, and l to read the contents of file x on Tuesdays, but only if their process id is a perfect square. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
aperez@cvbnet2.UUCP (Arturo Perez Ext.) (01/26/89)
From article <1135@raspail.UUCP>, by bga@raspail.UUCP (Bruce Albrecht): > In article <1989Jan9.114312.26821@ateng.ateng.com>, chip@ateng.ateng.com (Chip Salzenberg) writes: >> "No ability for file and system security" indeed. >> >> I think the real bigotry here is quite obvious. > > Actually, Unix's file security is quite crude. Because it doesn't have access > control lists for files, the only way to permit a file to specific users is > to create new groups (if one is allowed) that include only those users. Last > time I checked, it didn't have guardian procedures, either. I find it ironic > that I have to explain in detail to Unix zealots why the group mechanism is > inferior to the access control list mechanism for file permission. Unix has > a lot of nice features, but file permissions isn't one of them. This may be true. But most of the file security niceties your talking about haven't made it into most other OS either. For example, last time I looked VMS and IBM VM do not have guardian procedures. And VMS has had access control lists only within the last couple of revs. You may validly claim that Unix is not up to date in these respects but please bear in mind that only recently has IBM/VM gotten multitasking, about 10-15 years after Unix was originally written with that feature. About the only operating system which had all these features together was multics but it is going the way of the dinosaurs :-( Finally, an editorial. Why do people complain about Unix bigotry via USENET, which is an almost exclusively Unix controlled resource? This isn't the first time I've seen it. I believe it indicates masochism on the part of the poster :-)
mlewis@unocss.UUCP (Marcus S. Lewis) (02/03/89)
In article <476@cvbnet2.UUCP>, aperez@cvbnet2.UUCP (Arturo Perez Ext.) writes: [much deleted about acls and such] > About the only operating system which had all these features together > was multics but it is going the way of the dinosaurs :-( I have worked with Data General computers for the last 5 years, and I take exception to the statement that only multics has had ACL's and real protections etc. AOS/VS has been around since 1979 with the advent of the MV series of processors, and is a natural (virtual) extension of AOS, which is substantially older. ACL's are part of the file structure, and indeed are a large part of an average file's overhead information. I can select Owner, Write, Append, Read, or Execute access on a file by file basis, and I have yet to exceed the capacity of the file system for handling complex ACL's. We disable access to the computer every night by changing the ACL on the users' login directories, but since we go by first name for usernames, we can't use wildcards, so the entire programming staff (12 of us) are listed individually on the access control list for the User Directory Directory. If I log in as OP, there are many things I can't do without becoming Superuser (a privilege, not a user). The superuser privilege does completely bypass the ACL structure (as indicated by timing tests). This does create a hole in the security of the system, but AOS/VS is certified secure to some high level (details, details...) My point? VMS, Multics, and Unix, while popular, are not the only usable operating systems around. DG has been making systems that are fast, reliable, and secure for a long time. And they are fun to use, most of the time. Non-standard disclaimer: I don't work for DG, but I'm available.... Marc Lewis
pace@spectra.COM (William B. Pace) (02/05/89)
In article <653@unocss.UUCP>, mlewis@unocss.UUCP (Marcus S. Lewis) writes: > In article <476@cvbnet2.UUCP>, aperez@cvbnet2.UUCP (Arturo Perez Ext.) writes: > [much deleted about acls and such] > > About the only operating system which had all these features together > > was multics but it is going the way of the dinosaurs :-( > > I have worked with Data General computers for the last 5 years, and I take > exception to the statement that only multics has had ACL's and real protections > etc. AOS/VS has been around since 1979 with the advent of the MV series of > processors, and is a natural (virtual) extension of AOS, which is substantially > older. [ ...stuff deleted ] AOS was first introduced circa 1975 along with the Eclipse line of computers. The Eclipse itself was a natural (non-virtual) extension of the Nova series and you could see that AOS inherited much of it's philosophy from the RDOS/DOS operating systems that went with the old Novas. The AOS ACL's do work quite well. You can specify pattern matching characters for classes of usernames. For instance, if all accounts in a certain project started (or ended) in the same string (a technique common to many OS's) then you can match the whole class of names. Mr. Lewis stated later in his post that they use the individual's name as the account name. This makes it harder since you have to explicitly specify each account but this is a relatively small detail. The bad part about ACL's was that you had to re-specify the ENTIRE access control list whenever you wanted to delete/change/add an entry (if you used the default CLI). This detail was an unfortunate oversight but I guess you can't have everything. (Do they still do it this way?) Control Data's NOS also had similar access control (with a PERMIT command) but with a real nice extra. Whenever a user accessed a file, the access was logged by account, number of accesses, date of last access and type of access. Even if you PERMITted the file to the world, you could still get a list of the specific users that accessed the file. On another front, I was at USENIX this past week and heard some fascinating papers on the addition of threads (aka lightweight processes) to Unix. I'm fascinated because RDOS had this way back in 1968! AOS and AOS/VS both continued the feature which was one of the most FUN parts of these opsystems. The same features/problems that they were describing at the conference were settled years ago by DG, or at least were well understood. I guess none of the crew that implemented the DG stuff are listening in on the Unix world. It would be nice if they were to get involved in the process of defining threads. AOS(/VS) made a distinction between processes (same as Unix processes) and tasks (same as threads) and I have always liked their definitions. Most of the Unix world equates a process to a task since Unix supports only one task per process. There is a rich set of inter-task control and communications primitives, most of which could be handled within the process context without a switch to the kernal so they are very efficient. The problems that needed to be solved were the same. Need to do a non-blocking read? Start a task. > Non-standard disclaimer: I don't work for DG, but I'm available.... > Marc Lewis I DID work for DG about five years ago (when they were hiring all of the ex-IBM types into upper management and were predicting $1B/year sales the next year - yea, right) but don't think that biases me: I've done extensive work in NOS, VMS, MVS, VM/CMS, many others that I've since forgotten, and of course Unix. Of all of these, AOS and AOS/VS are my hands-down favorites. If Unix were AOS, I'd be a happy man. Unfortunately, there is a limited job market for practioners of the AOS(/VS) art so I had to make the difficult decision to leave it. Sigh. Those who think that Unix is a 'clean' OS have never looked at AOS code. THAT's a clean system. Unix, bless it's tin soul, is NOT a clean OS, despite what Unix boosters want to say. Don't get me wrong, next to AOS, Unix is my favorite - but that doesn't blind me to it's faults. (Flames by mail please). Bill Pace pace@spectra.com Disclaimer: I don't disclaim a damn thing!
darin@nova.laic.uucp (Darin Johnson) (02/08/89)
In article <117@spectra.COM> pace@spectra.COM (William B. Pace) writes: >In article <653@unocss.UUCP>, mlewis@unocss.UUCP (Marcus S. Lewis) writes: > >On another front, I was at USENIX this past week and heard some fascinating >papers on the addition of threads (aka lightweight processes) to Unix. I'm >fascinated because RDOS had this way back in 1968! This reminds me of someone I talked to a few weeks back, who commented "Isn't it nice that Sun went and invented shared libraries?" Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) Can you "Spot the Looney"?
aperez@cvbnet2.UUCP (Arturo Perez Ext.) (02/08/89)
From article <117@spectra.COM>, by pace@spectra.COM (William B. Pace): > Those who think that Unix is a 'clean' OS have never looked at AOS code. > THAT's a clean system. Unix, bless it's tin soul, is NOT a clean OS, despite > what Unix boosters want to say. Don't get me wrong, next to AOS, Unix is my > favorite - but that doesn't blind me to it's faults. (Flames by mail please). My curiosity is peaked by this statement. I'm willing to bow to your greater expertise since I've only seen 4 or 5 OS's up close enough to tell whether or not I liked them (as a metric of quality :-). What I'm curious about is what version of Unix you've been working with. Not meaning to start any Unix wars here but from what I've seen, the SysV version is very clean while BSD has too many inconsistencies to make me feel comfortable. For example, in System V to adjust the controlling terminal's behavior I use 1 structure and one ioctl(), and it's even fairly easy to remember the sorts of operations you can do. With BSD you need 5-7 different structures with as many ioctl()s and you can never keep straight what you can and cannot do. The upshot is: in SysV I can maintain a clear idea of what's going on, what operations I can comfortably control and so forth, while BSD has so many gotchas that you forget whether you're coming or going. Another operating system that is also difficult to envision is VMS. I don't know of anyone who can deal with that machine without at least 10 manuals while SysV you can get along with just one once you get the hang of it. So, with this idea of "clean" in mind, what makes AOS so much "cleaner" than Unix? Arturo Perez
seanf@sco.COM (Sean Fagan) (02/10/89)
In article <440@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: >This reminds me of someone I talked to a few weeks back, who commented >"Isn't it nice that Sun went and invented shared libraries?" That's just silly. We all *know* that it was AT&T that invented shared libraries! -- Sean Eric Fagan | "What the caterpillar calls the end of the world, seanf@sco.UUCP | the master calls a butterfly." -- Richard Bach (408) 458-1422 | Any opinions expressed are my own, not my employers'.
todd@stiatl.UUCP (Todd Merriman) (02/12/89)
In article <2253@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >In article <440@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: >>This reminds me of someone I talked to a few weeks back, who commented >>"Isn't it nice that Sun went and invented shared libraries?" > >That's just silly. >We all *know* that it was AT&T that invented shared libraries! > Excuse me, but I believe DEC made shareable libraries part of VMS long before AT&T or SUN made them part of Unix. ...!gatech!stiatl!todd Todd Merriman 404-377-8638 Atlanta, GA
frk@frksyv.UUCP (Frank Korzeniewski) (02/12/89)
In article <3095@stiatl.UUCP> todd@stiatl.UUCP (Todd Merriman) writes: |In article <2253@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: |>In article <440@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: |>>This reminds me of someone I talked to a few weeks back, who commented |>>"Isn't it nice that Sun went and invented shared libraries?" |>That's just silly. |>We all *know* that it was AT&T that invented shared libraries! |Excuse me, but I believe DEC made shareable libraries part of |VMS long before AT&T or SUN made them part of Unix. Way back around 1973-74 I implemented shared libraries on a swapping system on a pdp11/45. Even then the concept of shared libraries was old. Frank -- ______________________________________________________________________________ || Frank Korzeniewski, Consulting Suite 137 || || Phone: (415) 799-1819 1564-A Fitzgerald Drive || || UUCP: uunet!frksyv!frk Pinole, CA 94564 ||
campbell@redsox.UUCP (Larry Campbell) (02/13/89)
In article <3095@stiatl.UUCP> todd@stiatl.UUCP (Todd Merriman) writes: }Excuse me, but I believe DEC made shareable libraries part of }VMS long before AT&T or SUN made them part of Unix. Sigh. Sigh again. Multics, designed in the mid-1960s and first running, I would guess, around 1968, had shareable libraries. No one should claim to know anything about operating systems until they've read the Multics literature. "If I have seen farther than others, it is because I stand on the shoulders of giants." -Newton (or was it Gauss?) "In computer science, we stand on each others toes." -author unknown -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
guy@auspex.UUCP (Guy Harris) (02/13/89)
>Excuse me, but I believe DEC made shareable libraries part of >VMS long before AT&T or SUN made them part of Unix. *SIGH* yes, and Multics had them long before VMS or UNIX or any of a number of other OSes did. That's the whole point of many of the remarks here; there apparently exist some people who think AT&T or Sun invented shared libraries (or any of 100 other features) - apparently, they have no sense of history and think OS history started with UNIX (see the subject line...).
esler@bucsb.UUCP (Kevin Esler) (02/13/89)
In article <3095@stiatl.UUCP> todd@stiatl.UUCP (Todd Merriman) writes: >Excuse me, but I believe DEC made shareable libraries part of >VMS long before AT&T or SUN made them part of Unix. ...and Multics had shareable libraries when VMS was still an itch in someone's overalls.
jv@mhres.mh.nl (Johan Vromans) (02/14/89)
> In article <2253@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >>In article <440@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: >>>This reminds me of someone I talked to a few weeks back, who commented >>>"Isn't it nice that Sun went and invented shared libraries?" >> >>That's just silly. >>We all *know* that it was AT&T that invented shared libraries! >> > Excuse me, but I believe DEC made shareable libraries part of > VMS long before AT&T or SUN made them part of Unix. And long before that, I didn't even know that there were non-sharable libraries. One of the astonishing facts I had to learn when I started working with Dec/AT&T/Sun etc. was that the code of library routines whas copied and linked to your program. What a waste! -- Johan Vromans jv@mh.nl via european backbone (mcvax) Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv Gouda - The Netherlands phone: +31 1820 62944
mh@wlbr.EATON.COM (Mike Hoegeman) (02/15/89)
In article <2352@bucsb.UUCP> esler@bucsb.bu.edu (Kevin Esler) writes: >In article <3095@stiatl.UUCP> todd@stiatl.UUCP (Todd Merriman) writes: >>Excuse me, but I believe DEC made shareable libraries part of >>VMS long before AT&T or SUN made them part of Unix. > >...and Multics had shareable libraries when VMS was still an itch in >someone's overalls. the original posting was tongue-in-cheek, sarcasm, humor,.... get it? give the guy a break.
karl@ficc.uu.net (karl lehenbauer) (02/15/89)
From article <117@spectra.COM>, by pace@spectra.COM (William B. Pace): > Those who think that Unix is a 'clean' OS have never looked at AOS code. > THAT's a clean system. Unix, bless it's tin soul, is NOT a clean OS, despite > what Unix boosters want to say. ... OK, it's great and squeaky clean (I guess). Does it run on an incredibly wide range of incompatible hardware from a gamut of different manafacturers, as Unix (bless its tin soul) does? Although the various Unix bashers each have their own ideas of what's better, none of them provide the vendor and architecture independence of Unix. If you run AOS, VMS, NOS, CMS, TSO, Multics, MS-DOS, OS/2, etc, *you are locked in* to a vendor and a product line. If you have a lot of money and don't care to pay a high premium for hardware and software, that's fine. Even the U.S. government (cf. $5 billion AFCAC Unix deal, GAO endorsement, AFIPS Unix standard, etc) no longer has these sentiments. What will VMS proponents tell prospective buyers now that it costs several hundred thousand dollars for a VMS-capable machine having the equivalent computational performance of a Unix-based DECstation 3100? NOS as an alternative to Unix? Ha. Consider that NOS only runs on expensive mainframes. Consider also that CDC's highest performance machines, the ETA series, are available with Unix System V. Can't you get a native Unix for the Cray, now, too? The writing is on the wall, gentlepeople. You can sit in your corner with technology that's incompatible from what almost everyone else has, and maybe do wonderful things. Your technology may even be superior in some ways. But you take a big hit in that there aren't a lot of other people generating software for your machine -- you'll have to do a lot of it yourselves, meaning a lot of stuff you'd like won't get written, plus economies of scale may be such that a database package costs $100K instead of $1K. Savvy customers, especially those burned by the high cost of converting software from one incompatible software and hardware architecture to another are find, are going to Unix in droves, and while everyone has their pet peeves about Unix (including me), I think it is a reasonable platform for future development and do not see any architecture-independent operating system capable of challenging it at this time. -- -- uunet!ficc!karl "An expression of deep worry and concern failed to -- karl@ficc.uu.net cross either of Zaphod's faces." -- Hitchiker's Guide
seanf@sco.COM (Sean Fagan) (02/16/89)
[in various articles, people write lots of things about:] >|In article <2253@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >|>In article <440@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: >|>>This reminds me of someone I talked to a few weeks back, who commented >|>>"Isn't it nice that Sun went and invented shared libraries?" >|>That's just silly. >|>We all *know* that it was AT&T that invented shared libraries! I was making *sarcasm*! I'm sorry I forgot the '8-)' (I really did forget)! I *know* that Multics, at least, had shared libraries decades ago! I was making a nice, semi-humourous counterpoint to the sun one, ok? Sheesh. Some people obviously can't tell sarcasm just from the speed I type these things in 8-). -- Sean Eric Fagan | "What the caterpillar calls the end of the world, seanf@sco.UUCP | the master calls a butterfly." -- Richard Bach (408) 458-1422 | Any opinions expressed are my own, not my employers'.
sean@geac.UUCP (Sean Phelan) (02/16/89)
Frank Korzeniewski writes : > >Way back around 1973-74 I implemented shared libraries on a swapping system >on a pdp11/45. Even then the concept of shared libraries was old. > >Frank > Indeed. Libraries have existed almost as long as data has been recorded - a Babylonian temple has been found with a number of rooms filled with clay tablets, suggesting an archive or library. This dates from the 3rd millennium BC. SHARED libraries certainly existed in classical Rome. Cicero speaks of visiting the library of Lucullus to borrow a book, and finding his friend, Cato, surrounded by books of the Stoic philosophy. Lucullus was a statesman and general, who had acquired the library as part of his war booty. Julius Caesar planned a public library, but died before it was built. However a public library was built a few years later by Asinius Pollio. Describing Pollio's work, Pliny made an observation which I think Richard Stallman might appreciate today - "ingenia hominum rem publicam"..... "He made men's talents a public possesion" Unix(tm) libraries hardly keep up this fine tradition. -- Sean Phelan Geac Computer Corporation, Markham, Ontario sean@geac {uunet!mnetor,yunexus,unicus,utgpu}!geac!sean
mlewis@unocss.UUCP (Marcus S. Lewis) (02/16/89)
In article <3101@ficc.uu.net>, karl@ficc.uu.net (karl lehenbauer) writes: > From article <117@spectra.COM>, by pace@spectra.COM (William B. Pace): > > Those who think that Unix is a 'clean' OS have never looked at AOS code. > > THAT's a clean system. Unix, bless it's tin soul, is NOT a clean OS, despite > > what Unix boosters want to say. ... > > OK, it's great and squeaky clean (I guess). Does it run on an incredibly wide > range of incompatible hardware from a gamut of different manafacturers, as > Unix (bless its tin soul) does? > > Although the various Unix bashers each have their own ideas of what's better, > none of them provide the vendor and architecture independence of Unix. Well, excuuuuuuse ME! I have had better luck moving software to AOS/VS without modifications than I have to our "Unix" machine. So let's talk about "compatibility", shall we? Unix certinly isn't, yet. Shall we discuss computer system security? Unix certainly isn't a secure system. Shall we talk about something else? Neither I nor Mr. Pace bad-mouthed Unix onthe net. In person, well, that's another issue. Please, let us agree to disagree. My personal opinion is that the "best" operating system depends a lot on the machine and the application. AOS/VS does some things that Unix can't do, Unix, likewise is better at some things. Unix has a LONG way to go before it is as mature and reliable a product as AOS/VS. Data General stands a good chance of pushing in that direction, by the way. As somebody else pointed out, AOS/VS can run Unix as a guest operating system. Can Unix tolerate AOS/VS? The Eclipse/MV systems can run several variants of Unix, and the AOS/VS C compiler thinks it is a SYSV compiler, except when it thinks it's a BSD compiler. I would be willing to discuss the relative merits of various OS'es, by e-mail preferably, and you can bash AOS/VS and I can bash Unix and that would be marvelous. OK? Marc Lewis
raveling@vaxb.isi.edu (Paul Raveling) (02/17/89)
In article <3101@ficc.uu.net> karl@ficc.uu.net (karl lehenbauer) writes: > >Although the various Unix bashers each have their own ideas of what's better, >none of them provide the vendor and architecture independence of Unix. That doesn't mean it can't be done -- it just means that it's hard to find anyone who's willing to buck the marketing risk of developing a new system that might have to run a race against the "standard UNIX" bandwagon, no matter how much better another system may promise to be. MACH is probably the best bet at present, thanks to a layer to allow BSD compatibility. I only regret that this seems to be the only viable competitor -- computing could benefit by having more candidates for a better "standard" operating system. >The writing is on the wall, gentlepeople. You can sit in your corner with >technology that's incompatible from what almost everyone else has, and >maybe do wonderful things. Your technology may even be superior in some >ways. Darn right. Living in a "standard" UNIX architecture has presented our project with software engineering obstacles that we haven't surmounted. Our last conclusion was that in essence we'd need to build an OS kernel over UNIX in order to meet our needs. That's the hard way -- it would be easier to build the kernel under UNIX, as in MACH, but that wouldn't be "standard". ---------------- Paul Raveling Raveling@isi.edu
woods@gpu.utcs.toronto.edu (Greg Woods) (02/20/89)
In article <7541@venera.isi.edu> raveling@isi.edu (Paul Raveling) writes: > Darn right. Living in a "standard" UNIX architecture has > presented our project with software engineering obstacles > that we haven't surmounted. Our last conclusion was that > in essence we'd need to build an OS kernel over UNIX in > order to meet our needs. That's the hard way -- it would > be easier to build the kernel under UNIX, as in MACH, but > that wouldn't be "standard". I am, and I'm sure many others on this side of the Unix fence are, curious as to what you are attempting to build. I have a bit of difficulty imagining any application that requires more support than what is available in the various modern versions of Unix (unless, of course, you are trying to emulate something designed with a different philosophy in mind, in which case I suggest a re-design). -- Greg Woods. {utgpu,lsuc!gate,ontmoh}!woods, woods@{gpu.utcs.Toronto.EDU,utorgpu.BITNET} 1-416-443-1734 [h], 1-416-595-5425 [w] LOCATION: Toronto, Ontario, Canada
raveling@vaxb.isi.edu (Paul Raveling) (02/22/89)
In article <1989Feb19.143026.428@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: > >I am, and I'm sure many others on this side of the Unix fence are, >curious as to what you are attempting to build. We were working on multi-modal user interfaces that used a combined model- and rule-based approach to plan presentations and interaction modes. A paper presented at AAAI last year dealt with AI aspects of the system; we presented a brief talk at the X Conference in January that scratched the surface of the software engineering issues. The best reference to that would be the videotape of the conference that the X Consortium will release. BTW, I have to say "were working on" because the project's funding hit a snag in Washington. Maybe it'll come back, but for now the project has been suspended. > ... I have a bit of >difficulty imagining any application that requires more support than >what is available in the various modern versions of Unix ... Others in this field have encountered the same problems and are using variants of the same solutions. I became more aware of this at the ACM SIGGRAPH User Interfaces Conference last October, where a surprising percentage of speakers reported that LWP's were a key part of their solution. The MACH people at CMU have also done work on assigning objects to processes to facilitate object oriented programming. In our case, we had experience with more appropriate architectures for building software with cooperating processes from both real time and general purpose work that we did in the '70's. ---------------- Paul Raveling Raveling@isi.edu