torrie@Neon.Stanford.EDU (Evan James Torrie) (12/08/90)
mwm@fenris.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >Besides IBM, HP, Hitachi and Groupe Bull have all committed to >shipping OSF1 based products. Nixdorf, Encore, Intel & Intergraph have >also announced OSF1 products. (gee, all but the last three are OSF >founders, and OSF1 is heavily based on the Encore Mach product...) >Also, watch out for ANDF. If it delivers on it's promises, it'll trump >ABI, and make shrink-wrap software for OSF platforms easier than >shrink-wrap softare for MSDOS platforms. This brings to mind another interesting discussion, namely the technical superiority of OSF/1 to SVR4. *** Putting flame suit on *** In my humble opinion, you can characterise the two opposing Unix versions as follows: 1. SVR4 - a conglomeration and accumulation of every hacky thing done to Unix since its inception. 2. OSF/1 - throwing out all the hacky stuff and instead choosing the technically superior solution to every problem. Just take a look at the things that OSF have chosen, vs what SVR4 will have... for example, the multiprocessor Mach kernel, the HP/Apollo networking stuff (vs what many people call "brain-damaged" NFS), the Application Neutral Distribution Format, etc. It seems ironic to me that Amiga users (known for rejecting old existing standards, and instead taking the superior solution) are touting the greatness of SVR4 (as opposed to Mach, for example, which forms the basis of OSF/1)... *** Taking flame suit off *** -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Today's maxim: All socialists are failed capitalists
mwm@fenris.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (12/08/90)
In article <1990Dec7.201504.11469@Neon.Stanford.EDU> torrie@Neon.Stanford.EDU (Evan James Torrie) writes:
Just take a look at the things that OSF have chosen, vs what SVR4
will have... for example, the multiprocessor Mach kernel, the
HP/Apollo networking stuff (vs what many people call "brain-damaged"
NFS), the Application Neutral Distribution Format, etc.
Actually, most of the spiffyness in OSF1 (that's the way it's spelled
on OSFs literature) isn't from Mach, it's from somewhere else. For
instance, the multi-threaded kernel is from Encore (based on Mach,
though). It uses Posix threads instead of the Mach version. The
dynamic loader is from OSF. Ditto for the user-mode stream modules and
(I think) the user-mode memory managers.
Of course, Mach makes all this possible in a reasonable manner. I
don't even want to think of trying to do most of this in a
conventional Unix kernel.
It seems ironic to me that Amiga users (known for rejecting old
existing standards, and instead taking the superior solution) are
touting the greatness of SVR4 (as opposed to Mach, for example, which
forms the basis of OSF/1)...
It's even more ironic when you consider a list of really nice features
of AmigaDOS: shared libraries; user-mode mountable (and dismountable)
device drivers; the ability for applications to put hooks in the input
stream; a message passing kernel. Lightweight tasks in a shared
address space; runtime reconfiguration of just about everything.
OSF1 has all those things. VR4 may have one, but it's not required to
meet the SVID. If the NeXT moves to OSF1, it'll also have all those
things.
Of course, it'll _still_ look like Unix. But you can't have it all.
<mike
--ford@amix.commodore.com (Mike "Ford" Ditto) (12/09/90)
In article <MWM.90Dec7185555@fenris.relay.pa.dec.com> mwm@fenris.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >It's even more ironic when you consider a list of really nice features >of AmigaDOS: [ ... ] user-mode mountable (and dismountable) >device drivers; I'll have to disagree there. AmigaDOS does NOT have user-mode device drivers. AmigaDOS does not have user-mode anything. In AmigaDOS, every byte of code that ever runs runs in the equivalent of kernel mode, with access to every bit of physical memory and every hardware register. This is exactly the sort of thing that Mach avoids, making Mach superior to "traditional" Unix kernels and AmigaDOS in its entirety. >OSF1 has all those things. VR4 may have one, but it's not required to >meet the SVID. What does that mean? That OS features aren't important unless they're in the SVID? I don't think any real user gives a flying fart about the SVID. Besides, SVR4 has all of "those things" that you mentioned (I'm stretching a bit on "application-controlled hooks in the input stream", which sounds like a window-system function, not an O.S. one). -=] Mike [=-
ckp@grebyn.com (Checkpoint Technologies) (12/11/90)
In article <599@amix.commodore.com> ford@amix.commodore.com (Mike "Ford" Ditto) writes: >In article <MWM.90Dec7185555@fenris.relay.pa.dec.com> mwm@fenris.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >>of AmigaDOS: [ ... ] user-mode mountable (and dismountable) >>device drivers; > >I'll have to disagree there. AmigaDOS does NOT have user-mode device >drivers. AmigaDOS does not have user-mode anything. In AmigaDOS, >every byte of code that ever runs runs in the equivalent of kernel >mode, with access to every bit of physical memory and every hardware >register. [ rest deleted ] Others will disagree with you. IO is done by Exec "tasks" (or ADOS "processes"), which run with the PSW set to "user mode", not "supervisor mode". However, I have to essentially agree. IO space is addressable while in "user mode", and the only other thing the supervisor mode can do, disable interrupts, can be done easily in user mode by poking the Paula INTENA register (indeed, this is the system-defined way to control interrupt delivery). -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (12/11/90)
In article <599@amix.commodore.com> ford@amix.commodore.com (Mike "Ford" Ditto) writes: >OSF1 has all those things. VR4 may have one, but it's not required to >meet the SVID. What does that mean? That OS features aren't important unless they're in the SVID? I don't think any real user gives a flying fart about the SVID. Actually, it means that you can't depend on an OS feature (in SVR4) unless it's in the SVID. After all, someone may not implement it. Besides, SVR4 has all of "those things" that you mentioned (I'm stretching a bit on "application-controlled hooks in the input stream", which sounds like a window-system function, not an O.S. one). Nope, it's not a window-system function, though it can be used for that. It can also be used to add protocol layers to a network connection. Streams gives you the ability to take a data filtering module and add it to any open connection that support streams. OSF1 lets you do that for modules that weren't compiled into the kernel. As for SVR4 having all those things, that'd sure surprise me. let's see: user-mountable & dismountable file systems: the ability to take a device driver off of tape, put it on disk, then mount it and use it. Notice that the system didn't reboot while this was going on. You can take the driver out if you decide you don't want it, or want to install a different version for testing. And SVR4 has a message passing kernel? They threw out the monolithic monitor that's been the heart of AT&T (and BSD) Unix for the last 20 years? Posix threads - that's now part of the SVID, so I can depend on them being on every SVR4 system? The ability to reconfigure disk devices, the virtual memory manager (even adding new ones), adding new file system, adding the ability to load a new type of object file - all while the system is running, without rebooting it - that's all in SVR4? And they still call it "System V"???? <mike --
ford@amix.commodore.com (Mike "Ford" Ditto) (12/12/90)
In article <MWM.90Dec10175353@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >Actually, it means that you can't depend on an OS feature (in SVR4) >unless it's in the SVID. After all, someone may not implement it. Someone may not implement all of Mach or OSF/1, too. In fact, someone could make a Mach system that didn't meet the SVID! Ooohhh! Horrors! You don't care, you say? Ah, that's my point. Nobody cares about the SVID. Not me, not Next, not AT&T, not OSF, not IEEE. If *you* care about the SVID, then make that one of *your* purchasing requirements. I think you're a bit confused on the difference between System V and the SVID. The SVID had two purposes: 1) An application writer can depend on the specified source-level and command-level capabilities, knowing that the application will then run on any "System V compatible" system. 2) An OS vendor, selling any operating system, whether Unix- derived, OSF/1, VMS, or whatever, can claim to be "System V compatible" by meeting the specifications of the SVID. These purposes apply to any operating system - SysV, Mach, whatever. You seem to be arguing that SysV systems are limited by the SVID. Your right, but in the wrong direction: the SVID is a *lower* limit. OSF/1 does not promise to implement everything in the SVID; SysV does. This is independent of any other promises they make, like POSIX, etc. 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. The time when some people cared about SVID was before there were *real* standards like POSIX. I have heard that AT&T has no plans to create any more SVID editions: nobody cares. POSIX, X/OPEN, XPG/3 are more legitimate standards, and for the most part are supersets of the SVID. The old SVID still exists, and people can still make OS's that are SVID-compliant for those of you who care, but the real world has moved on. 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. If someone takes some major essential subsystem out of an OS, such as BSD compatibility or POSIX compliance, I say no one will buy such a thing, and therefore there is no need to discuss it in this thread, where we're trying (I think) to compare industry-standard open systems. What users care about are: "Will my program that I wrote on {4.2BSD,SVR3} two years ago compile and run correctly?" "Will this ANSI C POSIX-compatibile program I got off the net compile and run correctly?" "Will this application I bought at the computer store work?" What programmers care about are: "Can I write code to the {POSIX,FIPS,foobar,...} standard and do my debugging and testing on the system, knowing that my software will almost certainly work on other platforms meeting the same standard?" "Does it have the neato frobnitz feature that will let me access such-and-such resource in a convenient and efficient way?" None of these things are affected by SVID, unless SVID is the standard you choose to write code for. > "application-controlled hooks in the input > stream", which sounds like a window-system function, not an O.S. one). [ ... ] > It can also be used to add protocol layers to a network >connection. Streams gives you the ability to take a data filtering >module and add it to any open connection that support streams. OSF1 >lets you do that for modules that weren't compiled into the kernel. I'll address the not-compiled-into-the-kernel issue in a moment, but I think you also meant to point out that these modules can run in user mode contexts. That is a feature which impresses me and is a significant advantage of OSF/1. But otherwise, SVR4 seems to have the same capability here. >As for SVR4 having all those things, that'd sure surprise me. >let's see: > >user-mountable & dismountable file systems: the ability to take a >device driver off of tape, put it on disk, then mount it and use it. I have extensively used SysV systems with dynamically loadable device drivers, and this feature is invaluable for development and testing of a device driver by its author. As for end users, when they install a hardware device, they reboot the system anyway. For software-only device drivers, ideally, they wouldn't need to be part of the kernel at all. Here again, Mach / OSF/1 have some good capabilities that help this situation. Dynamically loaded kernel modules are quite convenient, though; enough so that we've thought pretty seriously about adding the capability to Amiga Unix. >And SVR4 has a message passing kernel? They threw out the monolithic >monitor that's been the heart of AT&T (and BSD) Unix for the last 20 >years? It's not quite all gone. But the obviously message-oriented parts are now message (streams) based, such as tty, network, and multiplexing/protocol drivers. The only part I know of that's missing compared to Mach is message-based paging drivers. Of course, if you have to look at or work on internal OS code, the Mach design has aesthetic benefits there from its more modular structure. >Posix threads - that's now part of the SVID, so I can depend on them >being on every SVR4 system? The SVID doesn't really apply to SVR4, so your question doesn't make much sense. As for threads, they're in there. Lightweight context switching calls are available to implement kernel-supported threads within one process at a level somewhere between Mach's -lco_threads and -lthreads. 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. >The ability to reconfigure disk devices, the virtual memory manager >(even adding new ones), adding new file system, adding the ability to >load a new type of object file - all while the system is running, >without rebooting it - that's all in SVR4? Aside from the multiple VM managers (a nice feature of Mach that SVR4 lacks), those features are all accomplished by kernel reconfiguration in SVR4. They can be added in a modular way, and invoked by booting a new kernel. Along with some other configurable subsystems, like the per-process-selectable scheduling classes. Yes, it would be nice if this could be done without booting. >And they still call it "System V"???? Well, here, we call it: System V "It's in there" Release 4. 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. 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. -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ditto@amix.commodore.com - The Unix Programmer's Manual, uunet!cbmvax!ditto 2nd Edition, June, 1972. ford@kenobi.commodore.com
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (12/13/90)
In article <634@amix.commodore.com> ford@amix.commodore.com (Mike "Ford" Ditto) writes: In article <MWM.90Dec10175353@raven.relay.pa.dec.com> 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 :-). <mike --
ford@amix.commodore.com (Mike "Ford" Ditto) (12/13/90)
In article <MWM.90Dec12112402@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > 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. That's not quite true. Users do want to run applications, and application compatibility these days is specified by those sorts of standards. The ones you mentioned are mostly relevant to source compatibility (the day when people no longer expect Unix software to come with source will be a sad one IMHO), but corresponding binary standards also exist and will be important to users. And even with binary standards, POSIX, etc. still define the behavior of the system calls, system files, shell-level commands, etc. > 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. Exactly, and when comparing SVR4, note what standards it provides (POSIX, X/OPEN, BSD, etc.). And all the SVR4-specific capabilities (and the older SysV functionality) are provided *in addition* to those. > 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. That's where you're misinformed. The latest version of the SVID describes SVR2 and SVR3 - it's only useful for application writers who want to run on all SysV systems, and don't need the facilities of the more modern standards. I don't think there will be very many such applications. SVR4 has its own documentation and specifications, called the System V Release 4 {programmer's,user's,administrator's} reference manuals. You can buy these *today* at B. Dalton's or any book store with a good computer section. If you don't want to do that, take my word for it: it's a superset of POSIX, X/OPEN XPG3, and the SVID. And it applies to all SVR4 systems. > If AT&T > has changed the rules for what can & can't be called SysVR4, I missed > it, and apologize for the confusion. I think the "rules" for SVR4 have always been as I describe above. No apology necessary, I just hope everyone has this under contol now. -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ditto@amix.commodore.com - The Unix Programmer's Manual, uunet!cbmvax!ditto 2nd Edition, June, 1972. ford@kenobi.commodore.com