lance@unigold.UUCP (Lance Ellinghouse) (12/03/90)
From what I hear SCO is not going to use V4 code because of the changes needed. That I understand and can agree with them. As for OSF/1 in the future... I can see SCO going with Mach very easily! Mach is a very interesting system because of the way it is designed. It is not really UNIX at all. It is a memory manager and IPC manager (basicly) and a Task manager. The overall design of Mach allows you to make it into ANYTHING you wish! If you want to run DOS on it, you can (what a waste though)... What I could see SCO doing is creating seperate environments that run under Mach that are Xenix and UNIX emulators. CMU already has BSD running on it and they can even run Mach native code with BSD 4.3 code with any other code you want sitting right next to it running all in parallel! (or serial if you only have one processor). So what you would have is a Xenix Environment, UNIX V3.2 environment, and maybe even UNIX V4.0 in the future. This would actually make it EASIER for them since they would actually break up the now HUGE UNIX kernel that they have into small seperate environments all working under the same scheduler! Thus if you never use Xenix programs, you don't NEED to have the Xenix system in memory at all! Same for the DOS emulation! I may be crazy, but I think if they go with OSF/1 and Mach (which is what it SEEMS like they are moving towards) you will see a MUCH faster and better system than anyone has seen sofar! You could even have the C2/B1/B2/D security services as modules that you could CHOOSE from. If you want C2, you have it. If ytou want B1 you have it. Their code would not change very much since it would all be done OUTSIDE the actual Mach kernel but inside the UNIX/Xenix/DOS emulators!! +-------------------------------------------+ |Lance Ellinghouse | |E-mail: lance@unigold.uucp | | lance@unigold.sr.com | | hermix!unigold!lance@anes.ucla.edu | +-------------------------------------------+
karl@ficc.ferranti.com (Karl Lehenbauer) (12/06/90)
In article <35@unigold.UUCP> lance@unigold.UUCP (Lance Ellinghouse) writes: >What I could see SCO doing is creating seperate environments >that run under Mach that are Xenix and UNIX emulators. Since even V.3 has Xenix 286 and 386 binary compatibility, what's the point? V.4 even has BSD compatibility -- you later mention running a BSD emulator too. Mach can do all the things you're gushing over partly because it doesn't do any more than those things. You seem to want to use it as sort of an operating system switcher, which it could do. IBM did something similar called VM. It provides simulated hardware to run multiple operating systems rather than the set of software services Mach provides. Something of a performance hit there. They used to have something like it on the RT, I think it was called the virtual resource manager. A friend of mine got paid good contract wages to take it *out* of AIX -- too slow. The utility of Mach in my opinion, and Mach is not the only such software being worked on, is that it provides a uniform interprocess communication method for the three current types of multiprocessors: tightly coupled processors with some private memory and some shared memory, tightly coupled processors where all memory is shared, and loosely coupled (networked) systems, also that it offers a model for new or seriously modified operating systems that increases concurrency and decreases, er, monolithicity. But whether it's there or not, except in broad terms, is invisible to the end-user. >...run Mach native code with BSD 4.3 code with any other >code you want sitting right next to it... >...have a Xenix Environment, UNIX V3.2 environment, and maybe >even UNIX V4.0... >You could even have the C2/B1/B2/D security services as modules >that you could CHOOSE from. If you want C2, you have it. ... Sorry, I think you're being naive with this stuff. You seem to be treating all this as SMOP, Simply a Matter of Programming, which to some degree it is, but you might consider that it's more like SMAGDOP, Simply a Matter Of A Great Deal of Programming, and somebody's gonna have to want to pay for it. This stuff isn't easy -- it's really, really hard. >I may be crazy, but I think if they go with OSF/1 and >Mach (which is what it SEEMS like they are moving towards) >you will see a MUCH faster and better system than anyone >has seen sofar! Prove it. Or at least give us more to go on than your feelings. -- -- uunet!sugar!ficc!karl (wk), "Any excuse will serve a tyrant." -- Aesop uunet!sugar!karl (hm)
sef@kithrup.COM (Sean Eric Fagan) (12/06/90)
In article <T.-7497@xds12.ferranti.com> karl@ficc.ferranti.com (Karl Lehenbauer) writes: >In article <35@unigold.UUCP> lance@unigold.UUCP (Lance Ellinghouse) writes: >Since even V.3 has Xenix 286 and 386 binary compatibility, what's the point? >V.4 even has BSD compatibility -- you later mention running a BSD emulator too. *Size*. Mach is a *lot* smaller than 3.2 (stock, ISC, ESIX, SCO, whatever). Yes, if you throw in the unix emulator, the system will increase in size. But: you can make the unix emulator a part of the user space, not the kernel. You can upgrade your unix emulator a lot more easily than you could upgrade your current unix kernel (I hope 8-)). Joe Blow could have a strict SysV environment, while A. R. User could have a strict BSD environment (meanwhile, everyone else would be running a SysVr4-ish environment). And the stuff being used is all that's paged in. Device drivers in Mach can be paged. You have the option of multiprocessing in Mach (supposedly; I know that, a while ago, there were problems with this, and I don't know if they've been fixed. If SCO were to go to Mach, that would undoubtedly be one of the things fixed [probably by Corollary, though, I guess]). Theoretically, one could come up with an OS/2 server (why one would want to is beyond me, but one knows that there are some pretty strange people out there), which you cannot do under unix (well, you could, but it's not easy, and the penalties involved would probably be too much). Etc. SysVr4 needs 8Mb to install. I doubt it's going to be terribly happy in anything less than about 6Mb. A version of Mach 3.0, with both SysV and BSD emulators, would probably fit in that space a *lot* better. (Mainly because the Mach memory manager seems to be better than the SysVr4 one.) >IBM did something similar called VM. It >provides simulated hardware to run multiple operating systems rather than >the set of software services Mach provides. Something of a performance hit >there. Yes. VM is a bit much. Although you can simulate OS's under Mach, you do so by writing an emulator, something that will deal with the traps of the application and do whatever necessary to support them. You cannot just fork off another copy of /vmunix (pun intended 8-)). I.e., the OS simulation is from an application point of view, not an OS point of view. Your comments about this stuff not necessarily being easy are (probably) correct. But, then, dealing with a monolithic kernel such as SysVr4 isn't easy, either. The former at least offers the advantage of starting from scratch, rather than adding on (and on and on and on and on...). -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/09/90)
In article <T.-7497@xds12.ferranti.com> karl@ficc.ferranti.com (Karl Lehenbauer) writes: | >I may be crazy, but I think if they go with OSF/1 and | >Mach (which is what it SEEMS like they are moving towards) | >you will see a MUCH faster and better system than anyone | >has seen sofar! | | Prove it. Or at least give us more to go on than your feelings. Well, let's see, from my uptime command: ==> 9:49pm up 152 days, 21:09, 2 users, load average: 0.09, 0.08, 0.34 And from the sysstat: oops, can't mail curses output. Anyway, system time is 6.8%. And from vmstat I note that system time peaks at about 30%, but 12-15 is typical. Why am I telling you this? Because you simply can't get a "MUCH faster" system when the overhead is that low. You could get more by faster i/o (I spend more time wait i/o than in kernel mode), but on a typical system there is that much overhead to improve. You could get a smaller kernel, but then the i/o buffers are bigger than the kernel code in a tuned system, even with the V.4 kernel. There are advantages to mach, but with typical kernel CPU and size, given $42/MB memory, I'm not about to switch because I can save one, two, or even three MB of memory, or cut my kernel CPU, paging, or whatever, in half. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
guy@auspex.auspex.com (Guy Harris) (12/11/90)
>As for OSF/1 in the future... >I can see SCO going with Mach very easily! >Mach is a very interesting system because of the way >it is designed. It is not really UNIX at all. It is a >memory manager and IPC manager (basicly) and a Task >manager. You might want to change the "OSF/1" to "OSF/2"; as far as I know, OSF/1, or at least the first release of it, will be based on a version of Mach that does *not* move the part of the UNIX environment traditionally implemented in the kernel out into libraries and servers, but has it still in the kernel.
shore@mtxinu.COM (Melinda Shore) (12/11/90)
In article <4751@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: |>As for OSF/1 in the future... |>I can see SCO going with Mach very easily! |>Mach is a very interesting system because of the way |>it is designed. It is not really UNIX at all. It is a |>memory manager and IPC manager (basicly) and a Task |>manager. |You might want to change the "OSF/1" to "OSF/2"; as far as I know, |OSF/1, or at least the first release of it, will be based on a version |of Mach that does *not* move the part of the UNIX environment |traditionally implemented in the kernel out into libraries and servers, |but has it still in the kernel. This is correct. OSF/1 is a significantly enhanced Mach 2.5 kernel. 2.5 was built into the side of 4.3 BSD, and while it is threaded internally, it is still a monolithic system that provides both Mach and Unix system services inside the kernel. Work is proceeding on OSF/2, but there's no announced release date and member design meetings are still being held. -- Hardware brevis, software longa Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore