Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!psuvax1!rutgers!cbmvax!amix!ford From: ford@amix.commodore.com (Mike "Ford" Ditto) Newsgroups: comp.sys.amiga Subject: Re: SVR4 vs OSF/1 (Was Re: A3000UX competition) Message-ID: <634@amix.commodore.com> Date: 12 Dec 90 03:50:23 GMT References: <2346@lpami.wimsey.bc.ca> <1990Dec7.201504.11469@Neon.Stanford.EDU> <599@amix.commodore.com> Reply-To: ford@amix.commodore.com (Mike "Ford" Ditto) Organization: Commodore-Amiga Unix Development Lines: 162 In article 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