Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!think.com!mintaka!bloom-beacon!deccrl!news.crl.dec.com!pa.dec.com!bacchus!mwm From: mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga Subject: Re: SVR4 vs OSF/1 (Was Re: A3000UX competition) Message-ID: Date: 12 Dec 90 17:24:02 GMT References: <2346@lpami.wimsey.bc.ca> <1990Dec7.201504.11469@Neon.Stanford.EDU> <599@amix.commodore.com> <634@amix.commodore.com> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 69 In-Reply-To: ford@amix.commodore.com's message of 12 Dec 90 03:50:23 GMT In article <634@amix.commodore.com> ford@amix.commodore.com (Mike "Ford" Ditto) writes: In article mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: A user who cares about SVID will buy an SVID compatible system. A user who cares about POSIX will by a POSIX compatible system. A user who cares about m68k ABI will buy an m68k ABI compatible system. A user who cares about ${foo} woudl be stupid to reject a system because it is also ${bar} compliant, but that's what you seem to be doing. You're missing the point. You're right - users don't care about SVID. Or about POSIX, the OSF AES, VR4, or OSF1. Users care about applications. Application writers care about POSIX/OSF/etc. If they need feature X, and the standard they're using supplies it, then they can depend on it being on _every_ system that conforms to that standard. If you're afraid that someone will make a stripped-down version of some OS, that's a legitimate concern. But it's equally likely to happen to OSF/1 as SVR4. Ah, but if they don't comply with the OSF AES, then they aren't an OSF1 system. If they comply with SVID, and use a SysVR4 base, they are a System V, and are SysVR4. In other words, if my application depends on feature X that's normally found on SysVR4, but not part of the SVID, I cannot claim that it will run on any SysVR4 system. If AT&T has changed the rules for what can & can't be called SysVR4, I missed it, and apologize for the confusion. I don't know if a POSIX interface is provided. I don't remember POSIX (IEEE 1003.1) specifying threads, so I suspect you are talking about a proposed standard. If so, I'm sure it will be adopted by X/OPEN and UI/AT&T when it's in POSIX. If there is an existing POSIX standard for threads, I suspect that XPG3 and SVR4 already include it. It's a proposed standard (1003.6? 1003.9 maybe?). It's expected to pass "substantially as is", and "soon". Note that _this_ is the interface that OSF1 supports now, and will support in the future. The Mach interfaces may/may not be there for future versions of OSF1. So far, I've really only heard one real advantage of Mach or OSF/1 over SVR4, and that is the breakup of the kernel into more modular pieces, many of which can be run as user processes. This is a truly admirable accomplishment, addressing one of the big holes in Unix where the "Unix philosophy" traditionally was not addressed. If you look carefully, most of the things on the list were facilities that have been in Unix for a while, basically as you describe (though VR4 improves on them), except OSF1 adds the ability to do these things "as users processes"; which in reality means "shutting the system down." The ability to add various modules via a reboot isn't interesting or even new; I've been using "drop-in" modules since v6. AT&T has just made the splash smaller. With OSF1, these things can be done without disrupting ongoing processes. That's a difference that makes a difference. That, along with the promised multiprocessing capability, are probably the main reasons that AT&T/UI has considered Mach as a basis for future Unix implementations. Delete "promised" for OSF1. OSF1 != Mach. It's based on the Encore mutlithreaded, multiprocessing version of Mach, with changes from various other sources. BTW, one other advantage OSF1 has over SysVR4 - lower licensing fees :-).