gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/01/70)
In article <14150@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >BSD UNIX more properly required a 32V Unix license (but that's a nit). >You'd better get a System V license because it will be required >for future releases, I hear. SVR2.0 or later. SVR3 not required for 4BSD in the forseeable future, due to unacceptable impact of the new SVID compliance clause. That's really too bad, because SVR3 has lots of good stuff in it that would be useful in 4BSD. One used to be able to upgrade an AT&T UNIX source license by paying just the $$ difference between the initial licensing fees. Usually that sufficed to upgrade all licensed systems at a single site. There was also a special one-time deal to upgrade SVR1 to SVR2 for $1K total. I'm pretty sure the latter deal expired long ago, and I'm not on top of the current license upgrade options (call (800)828-UNIX for that). (By the way, I'm not an official spokesman for any organization.)
bwong@ihwpt.ATT.COM (bruce wong) (01/01/70)
In article <3753@zen.berkeley.edu> schung@cory.Berkeley.EDU.UUCP (Stephen) writes: >In article <2001@ihwpt.ATT.COM> bwong@ihwpt.UUCP (55238-bruce wong) writes: >> V System, the new standard? > > Arch! > > How about: 4.x BSD, the new standard? Note that's ``V System'' not ``System V''. Note also that unlike 4.x BSD it's from Stanford. -- Bruce F. Wong ihnp4!ihwpt!bwong ATT Bell Laboratories Naperville-Wheaton Rd 312-979-6887 Naperville, Ill 60566 6C-31#R
stubbs@ncr-sd.SanDiego.NCR.COM (Jan Stubbs) (08/04/87)
I just read a Gardner Group industry report which claims the operating system of the future to watch is Mach, the Carnegie Mellon University Unix offshoot. This article claimed that I/O intensive work was a factor of 10 faster on Mach than vanilla Unix. Can anyone verify or explain this? If any reader has a system running Mach, please respond directly to me. How about an IOCALL time, someone? The article said the source tapes are free. Where can I get one? Jan Stubbs ....sdcsvax!ncr-sd!stubbs 619 485-3052 NCR Corporation E&M San Diego Advanced Development 16550 W. Bernardo Drive MS4010 San Diego, CA. 92127
edw@ius1.cs.cmu.edu (Eddie Wyatt) (08/05/87)
In article <1665@ncr-sd.SanDiego.NCR.COM>, stubbs@ncr-sd.SanDiego.NCR.COM (Jan Stubbs) writes: > > Can anyone verify or explain this? If any reader has a system running > Mach, please respond directly to me. How about an IOCALL time, someone? > The article said the source tapes are free. Where can I get one? > > Jan Stubbs ....sdcsvax!ncr-sd!stubbs > 619 485-3052 > NCR Corporation > E&M San Diego Advanced Development > 16550 W. Bernardo Drive MS4010 > San Diego, CA. 92127 Give me a full mailing path or an Arpanet address. Eddie Wyatt -- Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu
edw@ius1.cs.cmu.edu (Eddie Wyatt) (08/06/87)
In article <1665@ncr-sd.SanDiego.NCR.COM>, stubbs@ncr-sd.SanDiego.NCR.COM (Jan Stubbs) writes: > Can anyone verify or explain this? If any reader has a system running > Mach, please respond directly to me. How about an IOCALL time, someone? > The article said the source tapes are free. Where can I get one? > > Jan Stubbs ....sdcsvax!ncr-sd!stubbs > 619 485-3052 > NCR Corporation > E&M San Diego Advanced Development > 16550 W. Bernardo Drive MS4010 > San Diego, CA. 92127 The reason I didn't mail to you directly is because "ncr-sd.SanDiego.NCR.COM" is not in our host name tables and the mailer failed to send to your optional address when I went through the local gateway to UUCP. Well, I've gotten literally 20 or so requests about MACH so I think its worth posting this. The person to contact here at CMU about MACH distribution is Debra Lynn. e-mail address: lynn@spice.cs.cmu.edu A little information ==================== MACH is 4.3BSD compatible and binary compatible on Vaxen. If I get permission I will post the intro to the reference manual. As for the IOCALL benchmark, I haven't ran it so I can't give anyone any numbers. if someone posts it again I'll run it on a Micro Vax and a Vax 8800. -- Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu
henry@utzoo.UUCP (Henry Spencer) (08/06/87)
> ... This article claimed that I/O intensive work was > a factor of 10 faster on Mach than vanilla Unix. > > Can anyone verify or explain this? ... It's probably true, mostly because the Mach people have done a better job on integrating virtual memory and I/O. However, the advantage is strictly temporary, since several Unix vendors are already doing the same. -- Support sustained spaceflight: fight | Henry Spencer @ U of Toronto Zoology the soi-disant "Planetary Society"! | {allegra,ihnp4,decvax,utai}!utzoo!henry
gwu@vlsi.cs.cmu.edu (George Wu) (08/07/87)
I benched Mach on the MicroVax and RT using Jan Stubbs' iocall. The
results are below.
MicroVAXII 4.3BSD+NFS (wisconsin) 63.8
MicroVaxII Mach4.3 61.7 (*)
MicroVax II Ultrix/32-m V1.2 53.4
IBM PC/RT 170MHz ? 60
IBM PC/RT 4.2A (4.2BSD) 42.8
IBM PC/RT (???) Mach 56.1
* Actually, I noticed this was already in Jan's last post of iocall results. I
ran it myself and got something close to it.
This doesn't look all that terribly impressive as far as the RT goes, but
I'm not sure what the clock rate is. As for the MicroVax II, it looks slightly
better than 4.3 with NFS (we use RFS), but worse than standard Ultrix. All in
all, I'm don't think Mach is anything to get excited about, at least not on an
RT or MicroVax.
Not being one heavily involved with Mach, not even as a user, I'm only
slightly familiar with it. Are there any other advantages of Mach over Unix
and other operating systems? What about for multi-processors.
Georgeedw@ius1.cs.cmu.edu (Eddie Wyatt) (08/07/87)
The benchmarked results of Jan Stubbs' iocall on a Vax 8800 running MACH.
0.4u 11.0s 0:12 91% 0+0k 2+9io 0pf+0w
0.3u 10.3s 0:11 91% 0+0k 2+9io 0pf+0w
(two successive runs - to get some idea of the variation)
Some added notes on Mach. Mach supports multiply threads, shared memory
(at the page level) and a fast ipc. I do believe it is planned or does
support the memory mapping of files - but don't quote me on that.
--
Eddie Wyatt
e-mail: edw@ius1.cs.cmu.edumason@Pescadero.ARPA (Tony Mason) (08/08/87)
I've spent much of the last five weeks working with Mach here, both reading the internals stuff, and trying to get it running. Internally and design-wise, MACH is clean, efficient and quite elegant. It was specifically designed to work with networks, either as true networks of workstations (microVAX or Sun, etc.) or as "networks" of processors (multi-processor machines.) As for installing it, that has been a painful experience. First, we just installed a new VAX 8350 (2 cpu's.) We have Ultrix 2.0 running on it (now) but plan to migrate to MACH at some point, as Ultrix has problems of it's own. The 8350 is a BI based machine, and we have no attached UNIBUS. Because DEC has refused to let loose of a technical manual on the BI ethernet board (and/or the Ultrix 2.0 driver source) CMU has been unable to write a driver for it. Thus, we could run MACH, but not talk to anyone. That pretty well defeats our purpose, so right now we are struggling with DEC to get a manual to the BI board. So, next I moved onto a microVAX. Not your typical microVAX. It has two ra81's and a tk50. None of those little drives here! Ah, but alas, Stanford is a big place, and there has been a lot of hacking on the source code to 4.3. So what we have is not Vanilla 4.3. I can boot the MACH kernel to single user mode, but ls core dumps (illegal system calls - all that NFS code installed in there.) Once I recompiled ls with a non-NFS libc.a, I found out our disk structure had been tampered with. MACH trashes the super-block (not MACH's fault - this is just because of local mods.) After tracking down the *original* 4.3 code from Berkeley, I am now in the process of rebuilding EVERYTHING - 4.3, MACH and my disks. To sum up, MACH looks like a very promising operating system. It maintains full 4.3 compatibility but extends the original UNIX simplicity into this far more complex jungle of machines we have today. However, if you don't have a vanilla 4.3 system running on the machine you want to install it on AND you don't have a configuration supported by CMU, expect to put in some serious sweat. Note that this isn't all CMU's fault. In fact, none of it is really. They have been helpful every time we've dealt with them. The problem lies with uncooperative hardware companies and local "improvements." I hope this helps someone out there. Tony Mason Distributed Systems Group Stanford University mason@pescadero.stanfannalina
rfr@spice.cs.cmu.edu (Rick Rashid) (08/10/87)
A number of people sent me mail asking me to post an "official" CMU response to the recent messages about Mach on unix-wizards. So.... Information about Mach can be obtained by either sending computer mail to mach@wb1.cs.cmu.edu or by sending US mail to Richard Rashid, Dept. of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213. We are distributing Mach free of any charge for either commercial or academic use. Anyone wishing to receive either VAX or RT PC tapes should request a license agreement when contacting us at the above addresses. The VAX tape is structured as an add-on to a generic Berkeley 4.3 environment. The RT PC tape is a full system with all necessary software intended as a strict replacement for anything you may have run on your RT. Proof of a 4.3 license is required before we can send a tape. Please keep in mind that our distribution is primarily intended for systems people who want to keep abreast of our work or port Mach to their own environments. We do not yet provide an "end-user" distribution and have very limited resources to help with problems. In addition to the VAX and RT versions of Mach, we run Mach on SUNs, 16 CPU Encore MultiMaxes and on a 26 CPU Sequent Balance here at CMU. As time goes on we intend to increase the number of machines we include in our tape distribution and move away from the notion of an "add-on" tape to a complete distribution tape for each machine type. (The "add-on" philosophy was the root of the Stanford problem that Tony Mason mentioned since they had did not have a 4.3 system to add onto.) With regard to the various netnews messages about Mach posted recently, interested people should check out the Summer USENIX proceedings. There are two articles in it which center on the thread and shared memory/mapped file mechanisms Mach provides. There will also be a paper on Mach VM and multiprocessor support in the October ACM Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS II) and a paper on Mach's external paging facilities in the November Symposium on Operating System Principles (SOSP 11). As for benchmarks, the I/O benchmark discussed earlier is really just a read/write system call performance tester since it does virtually no disk I/O. Small differences in system call costs such as those which may be imposed by tests for remote file systems will influence the numbers more readily than I/O related system issues. The papers I mentioned above go into the issue of Mach performance vs actual I/O costs in some detail. Just as a point of comparison, I measured the iocall program on a SUN 160 with a local disk under Mach and SunOS 3.2. Both support remote file systems and pay some penalty for that support. The results were: SunOS: 1.7 user 37.2 system :39 elapsed Mach: 1.7 user 35.4 system :38 elapsed The cost of compiling the program (i.e. cc -O iocall.c -o iocall) was: SunOS: 1.1 user 1.3 system :08 elapsed 34% 104+44 io Mach: 1.1 user 0.9 system :03 elapsed 55% 13+35 io There were no other active users in either test case. There is no magic to the Mach numbers. If you performed the test immediately after bootup, you would probably get numbers closer to those of SUN 3.2 both for I/O and for elapsed time. The difference in Mach is that it does a much better job of using the physical memory of the machine to cache disk data and can save on I/O operations when data has been previous referenced (such as the text and initialized data of the compiler). This is particularly useful when the amount of physical memory is large, the CPU is fast and the I/O devices are (relatively) slow. In addition to improving I/O performance, Mach integrates VM and IPC to allow large (even gigabyte) messages to be sent between processes using VM techniques. As was mentioned in a previous netnews note, various companies have picked up on the kind of VM-I/O integration found in Mach. Rob Gingell gave a good presentation on the work SUN is doing in this area at USENIX. His paper can also be found in the summer USENIX proceedings. -Rick
hedrick@topaz.rutgers.edu (Charles Hedrick) (08/11/87)
We'd be interested in trying Mach on a Sun. However last time we looked into it, we found that NFS was not supported, and that the external file system hooks weren't done yet, so even if we implemented NFS ourselves we would probably just have to replace it shortly. In order to be able to use it on a Sun, we're going to need support for NFS and for normal Sun software, including Suntools, NeWS, and X. I'm willing to do some work, but don't have a lot of time to spend on the project. I'd appreciate hearing when the Sun version has gotten to a point where we should look at it again.
steve@nuchat.UUCP (Steve Nuchia) (08/20/87)
In article <1257@spice.cs.cmu.edu>, rfr@spice.cs.cmu.edu (Rick Rashid) writes: > Proof of a 4.3 license is required before we can send a tape. Please keep Which in turn requires proof of an AT&T v7 liscense, right? Will we ever again have an operating system that doesn't represent a royalty stream for ma bell? I realise that Mach is a research tool and not CMU's gift to the industry, but would it not have been possible to have avoided stepping into the same pile of problems that Berkeley did? Haven't the liscensing problems with 4.x proven the wisdom of starting from scratch? From what I've seen of bell's code it is a net liability anyway. Seriously, if a consious choice was made I'd very much like to know what benefits were seen to basing Mach on licensed code. Steve Nuchia {{soma,academ}!uhnix1,sun!housun}!nuchat!steve
phil@amdcad.AMD.COM (Phil Ngai) (08/22/87)
In article <292@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: <In article <1257@spice.cs.cmu.edu<, rfr@spice.cs.cmu.edu (Rick Rashid) writes: << Proof of a 4.3 license is required before we can send a tape. Please keep < <Which in turn requires proof of an AT&T v7 liscense, right? Will <we ever again have an operating system that doesn't represent a <royalty stream for ma bell? This is one of the reasons the Free Software Foundation was set up. Why don't you donate some money (tax deductable) to them if you really feel strongly about it? -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com
ron@topaz.rutgers.edu (Ron Natalie) (08/23/87)
First off. BSD UNIX more properly required a 32V Unix license (but that's a nit). You'd better get a System V license because it will be required for future releases, I hear. Second. Despite all the improvement, all the changes, made to the Berkeley code, a large portion of the code is still AT&T propietary. Much of this is arcane stuff that would be hard to reproduce properly even if one was concerned. Perhaps you should call Richard Stallman? By the way, there have been a number of non-AT&T UNIX-clones out. Mark Wilson's Coherent and Whitesmiths' IDRIS come to mind. -Ron
guy%gorodish@Sun.COM (Guy Harris) (08/23/87)
> Summary: Sigh. maybe mach won't save the world. Save the world from what? Having to pay AT&T a license fee? That wasn't the intent of MACH. Even if you replace *every single line* of the kernel with non-AT&T code, you would *still* have to replace the Bourne shell, the compilers, the utilities, etc., etc., etc.. > Which in turn requires proof of an AT&T v7 liscense, right? Will > we ever again have an operating system that doesn't represent a > royalty stream for ma bell? There are plenty of operating systems that don't require this: OS/360 and its successors, VMS, MS-DOS, etc., etc., etc.. There are even OSes that claim UNIX compatibility that don't require a license, such as Coherent. > I realise that Mach is a research tool and not CMU's gift to the > industry, but would it not have been possible to have avoided > stepping into the same pile of problems that Berkeley did? In a word, no. Where would they have gotten "/bin/sh", "/bin/mail", YACC, LEX, "grep", etc., etc., etc. from? Free versions of or replacements for some of these do exist, but, as you point out, avoiding AT&T licensing fees was NOT a goal of MACH. It simply wouldn't have been worth the effort to get those versions, write versions of the tools that *don't* have free replacements, and worry about the distribution restrictions of some of those tools (I don't think the GNU software is public domain; it is free, but they place restrictions on its redistibution in order to keep it freely available). > Haven't the liscensing problems with 4.x proven the wisdom of starting from > scratch? No. They merely prove that there are licensing problems with *not* starting from scratch; they don't prove that these problems outweigh the problems of starting from scratch. > From what I've seen of bell's code it is a net liability anyway. That's a pretty broad statement; how much of that code have you seen? Some of it is good, some of it is bad, some of it is in-between, and some of it is a mixture of these. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
jay@splut.UUCP (Jay Maynard) (08/24/87)
In article <18012@amdcad.AMD.COM>, phil@amdcad.AMD.COM (Phil Ngai) writes: > In article <292@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: > <Which in turn requires proof of an AT&T v7 liscense, right? Will > <we ever again have an operating system that doesn't represent a > <royalty stream for ma bell? > > This is one of the reasons the Free Software Foundation was set up. > Why don't you donate some money (tax deductable) to them if you really > feel strongly about it? I'll support the Free Software Foundation when they give up their processor bigotry and decide to support the machine architecture that I use (PC/AT). Until then, why should I waste my money? (Disclaimer: Last I heard on the subject, the position was "Intel? Not until hell freezes over!" If that's incorrect, I'd be happy to hear it.) -- Jay Maynard, K5ZC...>splut!< | uucp: hoptoad!academ!uhnix1!nuchat!splut!jay "Don't ask ME about Unix... | (or sun!housun!nuchat) CI$: 71036,1603 I speak SNA!" | internet: beats me GEnie: JAYMAYNARD The opinions herein are shared by neither of my cats, much less anyone else.
lalonde@nicmad.UUCP (John Lalonde) (08/24/87)
>>BSD UNIX more properly required a 32V Unix license >SVR2.0 or later. SVR3 not required for 4BSD in the forseeable future, >One used to be able to upgrade an AT&T UNIX source license by paying >just the $$ difference between the initial licensing fees. Usually >that sufficed to upgrade all licensed systems at a single site. There >was also a special one-time deal to upgrade SVR1 to SVR2 for $1K total. For those organizations that are still holding out with a 32V license for 4.x bsd releases the current source license upgrade fee to SVR3.0 is $24K. That price is from AT&T Software Licensing as of last week. An additional piece of info is that AT&T will not let you upgrade your 32V source license to some past AT&T source license level greater than 32V but less than SVR3.0; e.g. SVR2.1. All source license upgrades must be to the SVR3.0 level. This means that even if Berkeley says that you only need SVR2.1.1 source license compliance for the next bsd release, you will have to pay for a source license upgrade to SVR3.0 if you currently have a 32V source license. -- John LaLonde Systems Engineering Group Nicolet Instrument Corporation uucp: {ihnp4,seismo,decvax,harvard}!uwvax!astroatc!nicmad!lalonde
rich@oxtrap.UUCP (08/25/87)
In article <26310@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >> From what I've seen of bell's code it is a net liability anyway. > >That's a pretty broad statement; how much of that code have you seen? Some of >it is good, some of it is bad, some of it is in-between, and some of it is a >mixture of these. Many of us seem to forget that coding styles have changed radically since UNIX left the pdp11. Taken out of context, and line at a time, most "mature" code will look sloppy to our modern tastes. xoxorich.
ast@cs.vu.nl (Andy Tanenbaum) (08/25/87)
In article <292@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: > Will we ever again have an operating system that doesn't represent a >royalty stream for ma bell? Someday there may be a system from FSF. While waiting for its arrival you might try MINIX, which runs on the 8088/286/386 line, and has been ported to the NS 32000 machines. The port to the 68000 (Atari) is now in beta testing. See comp.os.minix to find out what is going on in the MINIX world. Andy Tanenbaum (ast@cs.vu.nl)
phil@amdcad.AMD.COM (Phil Ngai) (08/26/87)
In article <83@splut.UUCP> jay@splut.UUCP (Jay Maynard) writes:
<I'll support the Free Software Foundation when they give up their processor
<bigotry and decide to support the machine architecture that I use (PC/AT).
<Until then, why should I waste my money?
<
<(Disclaimer: Last I heard on the subject, the position was "Intel? Not until
<hell freezes over!" If that's incorrect, I'd be happy to hear it.)
Last night, RMS said he didn't think there'd be any problems
supporting the 386. So your statement might better be amended to "64K
segments? Not until hell freezes over!"
Course, that doesn't help you unless you upgrade to a PS/2-80 or other
386 type of PC.
--
I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.comhenry@utzoo.UUCP (Henry Spencer) (08/29/87)
> Many of us seem to forget that coding styles have changed radically > since UNIX left the pdp11... Mostly for the worse! "Don't worry about it, of course ints are always 32 bits. After all, all the world's a VAX." -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
mechjgh@tness1.UUCP (09/01/87)
>I'll support the Free Software Foundation when they give up their processor >bigotry and decide to support the machine architecture that I use (PC/AT). >(Disclaimer: Last I heard on the subject, the position was "Intel? Not until >hell freezes over!" Not to beat this dead horse... but I just ran across an old interview between RMS and Byte Magazine (in the standard emacs distribution): ******************* BYTE: Can you say something about what types of machines and environments GNU EMACS in particular has been made to run under? It's now running on VAXes; has it migrated in any form to personal computers? ........ Stallman: .........................Of course, I am not designing the software to run on the kinds of computers that are prevalent today. I knew when I started this project it was going to take a few years. I therefore decided that I didn't want to make a worse system by taking on the additional challenge of making it run in the currently constrained environment. So instead I decided I'm going to write it in the way that seems the most natural and best. I am confident that in a couple of years machines of sufficient size will be prevalent. ******************* I suppose there IS a method to the madness. Smiling Richard ?
gew@dnlunx.UUCP (Weijers G.A.H.) (09/10/87)
In article <484@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > While waiting for its arrival > you might try MINIX, which runs on the 8088/286/386 line, and has been > ported to the NS 32000 machines. The port to the 68000 (Atari) is now > in beta testing. See comp.os.minix to find out what is going on in the > MINIX world. When it's finished, where could one obtain MINIX for the Atari? By the way, I'm quite curious how the fork() call is implemented (the Atari lacks address translation). -- | Ge' Weijers | Disclaimer: the views expressed | | PTT Dr. Neher Laboratories | are usually entirely my own, | | Leidschendam, the Netherlands | not my employers'. |
bwong@ihwpt.ATT.COM (bruce wong) (09/14/87)
Nobody has mentioned this yet so I will. How about: V System, the new standard? -- Bruce F. Wong ihnp4!ihwpt!bwong ATT Bell Laboratories Naperville-Wheaton Rd 312-979-6887 Naperville, Ill 60566 6C-314
peter@sugar.UUCP (09/14/87)
> When it's finished, where could one obtain MINIX for the Atari? > By the way, I'm quite curious how the fork() call is implemented > (the Atari lacks address translation). In user mode the GLUE chip adds an offset to all adresses. It's not the best memory management hardware ever, but it's enough to make MINIX possible. Even if it didn't have it, though, you could still do it. Just teach the compiler to generate register-indirect branches and data access. It works for OS/9. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)
schung@cory.Berkeley.EDU (Stephen the Greatest) (09/15/87)
In article <2001@ihwpt.ATT.COM> bwong@ihwpt.UUCP (55238-bruce wong) writes: >Nobody has mentioned this yet so I will. How about: > > V System, the new standard? Arch! How about: 4.x BSD, the new standard? - Stephen