Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ll-xn!ames!scubed!ncr-sd!stubbs
From: stu...@ncr-sd.SanDiego.NCR.COM (Jan Stubbs)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Mach, the new standard?
Message-ID: <1665@ncr-sd.SanDiego.NCR.COM>
Date: Tue, 4-Aug-87 13:32:39 EDT
Article-I.D.: ncr-sd.1665
Posted: Tue Aug 4 13:32:39 1987
Date-Received: Thu, 6-Aug-87 02:44:30 EDT
Reply-To: stu...@ncr-sd.SanDiego.NCR.COM (0000-Jan Stubbs)
Organization: NCR Corporation, Rancho Bernardo
Lines: 15
Keywords: Mach
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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Mach, the new standard?
Message-ID: <8381@utzoo.UUCP>
Date: Thu, 6-Aug-87 14:02:28 EDT
Article-I.D.: utzoo.8381
Posted: Thu Aug 6 14:02:28 1987
Date-Received: Thu, 6-Aug-87 14:02:28 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM>
Organization: U of Toronto Zoology
Lines: 11
Keywords: Mach
> ... 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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!pt!spice.cs.cmu.edu!rfr
From: r...@spice.cs.cmu.edu (Rick Rashid)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Mach, the new standard?
Message-ID: <1257@spice.cs.cmu.edu>
Date: Mon, 10-Aug-87 15:36:21 EDT
Article-I.D.: spice.1257
Posted: Mon Aug 10 15:36:21 1987
Date-Received: Wed, 12-Aug-87 01:45:58 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA>
Organization: Carnegie-Mellon University, CS/RI
Lines: 76
Keywords: Mach
Summary: How to get Mach information
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
m...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!lll-lcc!ptsfa!hoptoad!academ!uhnix1!nuchat!steve
From: st...@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Mach, the new standard?
Message-ID: <292@nuchat.UUCP>
Date: Thu, 20-Aug-87 02:01:56 EDT
Article-I.D.: nuchat.292
Posted: Thu Aug 20 02:01:56 1987
Date-Received: Sun, 23-Aug-87 10:43:08 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <1257@spice.cs.cmu.edu>
Organization: Public Access - Houston, Tx
Lines: 19
Keywords: Mach
Summary: Sigh. maybe mach won't save the world.
In article <1...@spice.cs.cmu.edu>, r...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!amdcad!phil
From: p...@amdcad.AMD.COM (Phil Ngai)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Mach, the new standard?
Message-ID: <18012@amdcad.AMD.COM>
Date: Sat, 22-Aug-87 15:15:52 EDT
Article-I.D.: amdcad.18012
Posted: Sat Aug 22 15:15:52 1987
Date-Received: Sun, 23-Aug-87 13:15:29 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <1257@spice.cs.cmu.edu> <292@nuchat.UUCP>
Reply-To: p...@amdcad.UUCP (Phil Ngai)
Organization: Advanced Micro Devices
Lines: 16
Keywords: Mach
In article <2...@nuchat.UUCP> st...@nuchat.UUCP (Steve Nuchia) writes:
<In article <1...@spice.cs.cmu.edu<, r...@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!p...@decwrl.dec.com
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!lll-tis!ptsfa!hoptoad!academ!uhnix1!sugar!splut!jay
From: j...@splut.UUCP (Jay Maynard)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Mach, the new standard?
Message-ID: <83@splut.UUCP>
Date: Mon, 24-Aug-87 06:18:14 EDT
Article-I.D.: splut.83
Posted: Mon Aug 24 06:18:14 1987
Date-Received: Fri, 28-Aug-87 01:43:05 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <18012@amdcad.AMD.COM>
Organization: Confederate Microsystems, League City, TX
Lines: 22
Keywords: Mach
Summary: I'll support the FSF when...
In article <18...@amdcad.AMD.COM>, p...@amdcad.AMD.COM (Phil Ngai) writes:
> In article <2...@nuchat.UUCP> st...@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.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!aplcen!osiris!mjr
From: m...@osiris.UUCP (Marcus J. Ranum)
Newsgroups: comp.unix.wizards
Subject: MACH - who will/does own it ?
Message-ID: <1361@osiris.UUCP>
Date: Tue, 25-Aug-87 08:42:59 EDT
Article-I.D.: osiris.1361
Posted: Tue Aug 25 08:42:59 1987
Date-Received: Wed, 26-Aug-87 06:06:03 EDT
Organization: The Bavarian Illuminati, Inc.
Lines: 14
Keywords: DARPA grant - again...
Since MACH is being developed at CMU under a DARPA grant, who
owns it - the taxpayers or CMU ? I'm just curious as to whether CMU is
planning on making it easily and freely available, or are they going
into the software licensing business like UCB ?
Anyone out there know what the plans are ?
--mjr();
--
If they think you're crude, go technical; if they think you're technical,
go crude. I'm a very technical boy. So I get as crude as possible. These
days, though, you have to be pretty technical before you can even aspire
to crudeness... -Johnny Mnemonic
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!botter!star!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Mach, the new standard?
Message-ID: <484@ast.cs.vu.nl>
Date: Tue, 25-Aug-87 08:48:43 EDT
Article-I.D.: ast.484
Posted: Tue Aug 25 08:48:43 1987
Date-Received: Wed, 26-Aug-87 06:03:17 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <1257@spice.cs.cmu.edu> <292@nuchat.UUCP>
Reply-To: a...@cs.vu.nl ()
Organization: VU Informatica, Amsterdam
Lines: 11
Keywords: Mach
In article <2...@nuchat.UUCP> st...@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 (a...@cs.vu.nl)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!PT!spice.cs.cmu.edu!rfr
From: r...@spice.cs.cmu.edu (Rick Rashid)
Newsgroups: comp.unix.wizards
Subject: Re: MACH - who will/does own it ?
Message-ID: <1262@spice.cs.cmu.edu>
Date: Wed, 26-Aug-87 16:59:25 EDT
Article-I.D.: spice.1262
Posted: Wed Aug 26 16:59:25 1987
Date-Received: Sat, 29-Aug-87 09:10:38 EDT
References: <1361@osiris.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 23
Keywords: DARPA grant - again...
Summary: Mach licensing
CMU is distributing Mach under a license, but there is no charge, royalty,
or fee of any kind associated with the license. In fact, we are sending
people documents and tapes at our own expense and losing significant
amounts of money. The quid pro quo of the license is that we expect
those who sign it to return to CMU modifications to our software so we
can freely redistribute those improvements to others.
Obviously, as I mentioned before, we require proof of a Berkeley license
so the system is not "free" unless you have already paid for that license.
CMU generated code, however, is free of charge. We hope to eventually
package the distribution such that CMU kernel and user code would be
separate from Berkeley derived code and distributable without the
Berkeley license requirement.
Obviously we would have
liked to have had the luxury of avoiding use of licensed software in our
work, but the reality is that we are a research organization with limited
resources. We felt that it was more important for us to advance the
state of the art than to reproduce it in an unlicensed form. We welcome
contributions by others such as FSF that enhance our software without
adding more complicated licensing requirements or fees.
-Rick
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!hplabsz!kempf
From: ke...@hplabsz.HPL.HP.COM (Jim Kempf)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <738@hplabsz.HPL.HP.COM>
Date: Thu, 27-Aug-87 11:16:22 EDT
Article-I.D.: hplabsz.738
Posted: Thu Aug 27 11:16:22 1987
Date-Received: Sat, 29-Aug-87 10:00:00 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <83@splut.UUCP>
Organization: Hewlett-Packard Laboratories
Lines: 21
In article <8...@splut.UUCP>, j...@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?
>
I don't think it's a matter of bigotry. FSF has exactly three employees-
Stallman, one full time programmer and a secretary. They are looking to
hire a part time programmer this fall. With that kind of staff, it's
astounding that Stallman gets as much done as he does, and that it is
of any quality at all. Additionally, Stallman prefers using machines
with larger address spaces because they're easier to program. This
is understandable, since it allows him to concentrate his time on
things other than trying to reduce the size of things to fit in 640K.
I, too, would like to see FSF's software on the PC/AT and PC/XT, but
I think its unreasonable to expect FSF to do it.
Jim Kempf ke...@hplabs.hp.com
Usual Disclaimer
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!bu-cs!tower
From: to...@bu-cs.BU.EDU (Leonard H. Tower Jr.)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <12381@bu-cs.BU.EDU>
Date: Fri, 28-Aug-87 15:25:06 EDT
Article-I.D.: bu-cs.12381
Posted: Fri Aug 28 15:25:06 1987
Date-Received: Sun, 30-Aug-87 01:52:02 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <83@splut.UUCP> <738@hplabsz.HPL.HP.COM>
Reply-To: to...@prep.ai.mit.edu (Leonard H. Tower Jr.)
Followup-To: comp.os.misc
Organization: Distributed Systems Group, Boston University, 111 Cummington Street, Boston, MA 02215, USA +1 (617) 353-2780
Lines: 42
Summary: Let's get the facts straight.
Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739
I have directed followups to comp.os.misc.
I'm now a GNU volunteer, and did spent a year being paid to work on
GNU (the salary came from a private foundation [not FSF]). I've been
a director (aka corporate officer) of the Free Software Foundation
since it's beginning.
In article <7...@hplabsz.HPL.HP.COM> ke...@hplabsz.HPL.HP.COM (Jim Kempf)
writes:
> FSF has exactly three employees-
> Stallman, one full time programmer and a secretary.
Lot's of mis-information here. RMS has NOT been and is NOT currently
an employee of the Free Software Foundation. He earns his livelihood
as a consultant. FSF does NOT employ a secretary. FSF is employing a
full time programmer and a part time shipping clerk.
> With that kind of staff, it's
> astounding that Stallman gets as much done as he does, and that it is
> of any quality at all.
RMS is quite productive. He has also had help from many hackers and
quality programmers, who have volunteered their efforts.
> Additionally, Stallman prefers using machines
> with larger address spaces because they're easier to program. This
> is understandable, since it allows him to concentrate his time on
> things other than trying to reduce the size of things to fit in 640K.
That's an approximation of RMS' feeling on the matter. I advise
interested people to read the GNU Manifesto. It was published in the
March 1985 issue of Dr. Dobb's Journal. It and answers to questions
about the project GNU can also be obtained from:
<g...@prep.ai.mit.edu> aka <..!ucbvax!prep.ai.mit.edu!gnu>
enjoy -len
--
Len Tower, Distributed Systems Group, Boston University,
111 Cummington Street, Boston, MA 02215, USA +1 (617) 353-2780
Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739
UUCP: {}!harvard!bu-cs!tower INTERNET: to...@bu-cs.bu.edu
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <8520@utzoo.UUCP>
Date: Sat, 29-Aug-87 21:50:06 EDT
Article-I.D.: utzoo.8520
Posted: Sat Aug 29 21:50:06 1987
Date-Received: Sat, 29-Aug-87 21:50:06 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA>
Organization: U of Toronto Zoology
Lines: 10
> ... Additionally, Stallman prefers using machines
> with larger address spaces because they're easier to program. This
> is understandable, since it allows him to concentrate his time on
> things other than trying to reduce the size of things to fit in 640K.
A less charitable view of this is that Stallman couldn't write a small
program to save his life. Unfortunately, this is a common maladay nowadays.
--
"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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!botter!star!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <486@ast.cs.vu.nl>
Date: Wed, 2-Sep-87 04:46:19 EDT
Article-I.D.: ast.486
Posted: Wed Sep 2 04:46:19 1987
Date-Received: Sat, 5-Sep-87 09:41:48 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <83@splut.UUCP> <738@hplabsz.HPL.HP.COM>
Reply-To: a...@cs.vu.nl ()
Organization: VU Informatica, Amsterdam
Lines: 10
In article <7...@hplabsz.HPL.HP.COM> ke...@hplabsz.HPL.HP.COM (Jim Kempf) writes:
> Additionally, Stallman prefers using machines
>with larger address spaces because they're easier to program. This
>is understandable, since it allows him to concentrate his time on
>things other than trying to reduce the size of things to fit in 640K.
640K? Why would he need 640K? MINIX runs quite well on a 512K AT
with one 1.2M floppy disk. Who needs 640K?
Andy Tanenbaum (a...@cs.vu.nl)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!lll-lcc!ptsfa!hoptoad!academ!uhnix1!sugar!peter
From: pe...@sugar.UUCP
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <692@sugar.UUCP>
Date: Fri, 11-Sep-87 08:15:30 EDT
Article-I.D.: sugar.692
Posted: Fri Sep 11 08:15:30 1987
Date-Received: Sun, 13-Sep-87 07:45:23 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <3728a4c0.ccb2@apollo.uucp>
Organization: Sugar Land UNIX - Houston, TX
Lines: 25
Summary: UNIX didn't start out BSD-compatible either.
> I assume you left off the ":)" by accident. If GNU is supposed to be
> BSD 4.3 compatable it is a significantly more ambitious effort than
> MINIX. MINIX is a decent, small system for teaching. GNU is supposed
> to be suitable for research or commercial development.
Are you implying that Version 7 wasn't suitable for research or commercial
development? Remember... UNIX didn't start out as BSD 4.3 either. Thank
the gods (Thompson & Ritchie). BSD would never have run on the machines
available in the early and mid seventies, just as GNU won't run on the
personal computers available today.
> I have been looking for an inexpensive, Unix-based system for my
> personal use. MINIX isn't powerful enough to be useful to me, even
> for hobby hacking. Hopefully GNU will be.
MINIX probably needs a better message passing mechanism, to avoid some of
the delays, and a bit of disk I/O optimisation. Otherwise it's quite a
usable system if you don't have anything better. Personally I prefer
AmigaDOS, but it's not designed to go anywhere... and MINIX is.
I will venture to predict that by the time GNU is out MINIX will be big
enough to satisfy you.
--
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter
-- 'U` <-- Public domain wolf.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!sdcsvax!ucsdhub!jack!man!sdeggo!dave
From: d...@sdeggo.UUCP
Newsgroups: comp.arch,comp.unix.wizards,comp.os.minix
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <87@sdeggo.UUCP>
Date: Sat, 12-Sep-87 18:38:24 EDT
Article-I.D.: sdeggo.87
Posted: Sat Sep 12 18:38:24 1987
Date-Received: Sun, 13-Sep-87 10:01:37 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <692@sugar.UUCP>
Organization: Lazy Programmer's Society of San Diego
Lines: 40
In article <6...@sugar.UUCP>, pe...@sugar.UUCP (Peter da Silva) writes:
(there was more up here about GNU being better than Minix for software
development)
> Are you implying that Version 7 wasn't suitable for research or commercial
> development? Remember... UNIX didn't start out as BSD 4.3 either. Thank
> the gods (Thompson & Ritchie). BSD would never have run on the machines
> available in the early and mid seventies, just as GNU won't run on the
> personal computers available today.
It's not a case of wasn't; it was. It isn't today (at least not a PDP-11
based version), and neither is Minix in its present, IBM PC form. Minix
is an impressive effort, and I give Dr. Tanenbaum his due, but I would
hate to have to develop a large software package (has anyone ported "hack"
yet?) under it. It's kind of like all the people who have taken Pascal
(designed as a _teaching_ language, to be hand compiled by an instructor!)
and wanted to try and develop real software in it. It's possible, but it
ain't pleasant.
BSD 4.3 would run just fine on an 80386 and it does run just fine on 68000's
and 68020, so there is no reason that GNU wouldn't. "Personal computers
available today" are available based on those chips, and that is where the
market is heading.
Wtih some work, (as Peter pointed out in his article, but I already threw
away that part :-( ) Minix could be changed to be BSD compatible. The first
task, though is to port it to a 68000 (with a good memory manager) or an
80386 and get around the 64K task size limit. The rest could be added in
slowly.
This might beat GNU out the door, but I'm not sure of the status of the GNU
project. Why are so many people so anxious to beat on it? Someone's doing
you a favor and all you can do is bitch about how "it's not here, it's too
big, it doesn't do what I want it to do, my machine can't run it..."? Cripes,
don't look a gift horse in the mouth. Especially one that nobody's really
seen yet.
--
David L. Smith
{sdcsvax!sdamos,ihnp4!jack!man, hp-sdd!crash}!sdeggo!dave
sdeggo!d...@sdamos.ucsd.edu
"How can you tell when our network president is lying? His lips move."
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!botter!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.minix
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <1613@botter.cs.vu.nl>
Date: Mon, 14-Sep-87 10:46:26 EDT
Article-I.D.: botter.1613
Posted: Mon Sep 14 10:46:26 1987
Date-Received: Tue, 15-Sep-87 02:26:24 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <692@sugar.UUCP> <87@sdeggo.UUCP>
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 28
In article <8...@sdeggo.UUCP> d...@sdeggo.UUCP (David L. Smith) writes:
>With some work, ... Minix could be changed to be BSD compatible. The first
>task, though is to port it to a 68000 (with a good memory manager) or an
>80386 and get around the 64K task size limit. The rest could be added in
>slowly.
As has been pointed out already, MINIX has already been ported to the 68000,
albeit without an MMU. That (Atari) version is now in beta testing. The
Atari version does not have a 64K limit.
Actually, I think that if anyone is going to do that much work, a much better
idea is to modify MINIX to make if conform to the POSIX standard, which is the
UNIX of the future.
Here is a suggestion/request in that direction. Will someone who is familiar
with POSIX draw up a list of POSIX system calls, noting for each one whether
1. it is identical to the corresponding MINIX call
2. it is different from the corresponding MINIX call
3. it is not present in MINIX at all
Similarly, for each program and library routine in POSIX, a similar list would
be useful. That way people who want to get together and make MINIX more "real
world", could at least have a specific list of what needs to be done, and the
target would be something that will eventually be an International Standard,
rather than 4.3, which is not likely to survive once an International Standard
has been established for UNIX systems.
Andy Tanenbaum (a...@cs.vu.nl)