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!husc6!rutgers!labrea!aurora!ames!oliveb!sun!gorodish!guy
From: guy%gorod...@Sun.COM (Guy Harris)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Mach, the new standard?
Message-ID: <26310@sun.uucp>
Date: Sat, 22-Aug-87 18:55:36 EDT
Article-I.D.: sun.26310
Posted: Sat Aug 22 18:55:36 1987
Date-Received: Sun, 23-Aug-87 14:49:21 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA>
<292@nuchat.UUCP>
Sender: n...@sun.uucp
Lines: 43
Keywords: Mach
> 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
g...@sun.com
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!amdcad!phil
From: p...@amdcad.AMD.COM (Phil Ngai)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Who owns Unix(tm)? (was: Re: Mach, the new standard?)
Message-ID: <18019@amdcad.AMD.COM>
Date: Sun, 23-Aug-87 14:50:40 EDT
Article-I.D.: amdcad.18019
Posted: Sun Aug 23 14:50:40 1987
Date-Received: Sun, 23-Aug-87 23:48:06 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP>
Reply-To: p...@amdcad.UUCP (Phil Ngai)
Organization: Advanced Micro Devices
Lines: 26
Keywords: Gross overbearing ripoff!
In article <2...@xanth.UUCP> k...@xanth.UUCP (Kent Paul Dolan) writes:
>the gall of AT&T
>claiming to "own" Unix(tm) really gets to me. At the time Unix was
>developed, WITH SUBSCRIBER FUNDS, AT&T was a regulated monopoly,
>specifically prohibited from being in the computer business.
They were not in the computer business but they needed computers as
tools. Thus it seems reasonable for them to work on computers FOR
INTERNAL USE.
As to the ownership of the Unix (brand) operating system, I imagine
they'd argue that the profits from licensing Unix products helps them
keep their line charges lower than they would be otherwise so the
subscribers ARE deriving benefit from the product they helped fund.
Another tack would be to say it was funded by the stockholders, not
the subscribers.
Operating a business on a cost plus guaranteed profit basis, as most
regulated monopolies are, is a bad method anyway, and leads to
confusion such as we have here, as well as inefficiencies.
--
I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl#Kb#K
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!ames!sdcsvax!ucsdhub!
hp-sdd!hplabs!pyramid!prls!mips!mash
From: m...@mips.UUCP (John Mashey)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Who owns Unix(tm)? (was: Re: Mach, the new standard?)
Message-ID: <617@winchester.UUCP>
Date: Sun, 23-Aug-87 23:49:29 EDT
Article-I.D.: winchest.617
Posted: Sun Aug 23 23:49:29 1987
Date-Received: Tue, 25-Aug-87 06:45:15 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP>
Reply-To: m...@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 43
Keywords: Gross overbearing ripoff!
In article <2...@xanth.UUCP> k...@xanth.UUCP (Kent Paul Dolan) writes:
>
>...Among a long list of other phone injustices (like paying operator
>rates for pay phone calls now handled by robots...), the gall of AT&T
>claiming to "own" Unix(tm) really gets to me. At the time Unix was
>developed, WITH SUBSCRIBER FUNDS, AT&T was a regulated monopoly,
>specifically prohibited from being in the computer business. Suddenly
>divesture happens, and this magig product springs forth full grown
>from Zeus' forehead. Riiiight! Seems to me, right off hand, that an
>awfully good case could be made that the customers, NOT Ma Bell, own
>Unix. Considering the AT&T customer base, that is pretty much the
>mortal equivalent of public domain.
Before the net gets used up on this one [incidentally enriching AT&T],
let's squelch this one quick with some facts. (Not defense of AT&T
licensing practices, just some facts):
1) AT&T is, and always has been a private company. Contrary to
occasional popular belief, or people who take "The President's Analyst"
too seriously, it is NOT the government, which sometimes has
rules about the required availability of software developed at govt expense.
2) It is rather unlikely that "an awfully good case" can be made that
the customers own UNIX, just as it's unlikely that the customers
own every single piece of technology ever developed at AT&T.
(There have been various rules regarding patent licensing of patents
during certain times, but none of these ever implied that UNIX be
owned by the customers).
3) "equivalent of public domain" is just as an unlikely: AT&T does those
things necessary to prevent it from becoming so, at least from V7 onward.
4) prohibitions from being in the computer business, regulated monopoly,
etc, simply are irrelevant: they don't mean the customers own it.
Also, people's emotional reactions to AT&T are also irrelevant.
I am not a lawyer. With UNIX licensing, I've had numerous close
encounters of all kinds, from inside and outside, over a lot of years.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR m...@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
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!husc6!think!ames!lll-tis!ptsfa!ihnp4!homxb!houdi!marty1
From: mar...@houdi.UUCP (M.BRILLIANT)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Who owns Unix(tm)?...
Message-ID: <1272@houdi.UUCP>
Date: Mon, 24-Aug-87 10:36:07 EDT
Article-I.D.: houdi.1272
Posted: Mon Aug 24 10:36:07 1987
Date-Received: Tue, 25-Aug-87 04:01:19 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA>
<2232@xanth.UUCP>
Organization: AT&T Bell Laboratories, Holmdel
Lines: 35
Keywords: stockholder ownership private enterprise
Summary: "Regulated monopoly" != "Public ownership"
In article <2...@xanth.UUCP>, k...@xanth.UUCP writes:
[ long list of references ]
> ....
> .... the gall of AT&T
> claiming to "own" Unix(tm) really gets to me. At the time Unix was
> developed, WITH SUBSCRIBER FUNDS, AT&T was a regulated monopoly,
> specifically prohibited from being in the computer business.... an
> awfully good case could be made that the customers, NOT Ma Bell, own
> Unix. Considering the AT&T customer base, that is pretty much the
> mortal equivalent of public domain.
There have been some replies to this, but I want to get down to basics.
Regulated monopoly is a special arrangement between a private
enterprise and the public. Its purpose is to gain the efficiencies of
a single supplier, without allowing the supplier to restrict output and
charge monopoly prices, and without establishing a government
enterprise. A private enterprise is granted an exclusive franchise and
regulated so that it can not charge monopoly prices.
A private enterprise operating as a regulated monopoly is not a public
enterprise, but an alternative to public enterprise. It is is owned by
stockholders who are financially responsible for its mistakes and
entitled to the rewards of its successes. It is managed by its own
officers under the direction of a board appointed by its stockholders.
Its operations are restricted only by the terms of its agreements with
the governments and agencies that regulate it. Any inference that its
assets are owned by anyone but its stockholders is purely imaginary.
Disclaimer: I usually omit disclaimers, but that's the nicest thing I
ever said publicly about my employer, and my employer may disagree.
M. B. Brilliant Marty
AT&T-BL HO 3D-520 (201)-949-1858
Holmdel, NJ 07733 ihnp4!houdi!marty1
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: Who owns Unix(tm)? (was: Re: Mach, the new standard?)
Message-ID: <8508@utzoo.UUCP>
Date: Sat, 29-Aug-87 02:22:40 EDT
Article-I.D.: utzoo.8508
Posted: Sat Aug 29 02:22:40 1987
Date-Received: Sat, 29-Aug-87 02:22:40 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA>
Organization: U of Toronto Zoology
Lines: 15
Keywords: Gross overbearing ripoff!
> ... Seems to me, right off hand, that an
> awfully good case could be made that the customers, NOT Ma Bell, own
> Unix...
It is quite possible that AT&T's regulated-monopoly status is the only
reason why Unix ever made it to the outside world! Or don't you believe
that having Unix all to oneself would be a competitive advantage? Under
the old rules, AT&T was required to license useful technology to the rest
of the world on reasonable terms. Not any more. I'm told there was a
lot of internal debate before the release of System III, mostly along the
lines of "do we really want to license our spiffiest software technology
to our competitors?!?". Quit complaining, it could be a lot worse.
--
"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
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!utgpu!water!watmath!clyde!rutgers!ames!xanth!kent
From: k...@xanth.UUCP
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Who owns Unix(tm)?...
Message-ID: <2303@xanth.UUCP>
Date: Sun, 30-Aug-87 00:13:38 EDT
Article-I.D.: xanth.2303
Posted: Sun Aug 30 00:13:38 1987
Date-Received: Sun, 30-Aug-87 18:43:50 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA>
<2232@xanth.UUCP> <1272@houdi.UUCP>
Reply-To: k...@xanth.UUCP (Kent Paul Dolan)
Organization: Old Dominion University, Norfolk Va.
Lines: 81
Keywords: stockholder ownership private enterprise
Summary: Once again (kill if uninterested)
In article <1...@houdi.UUCP> mar...@houdi.UUCP (M.BRILLIANT) writes:
>In article <2...@xanth.UUCP>, k...@xanth.UUCP writes:
>[ long list of references ]
>> ....
>> .... the gall of AT&T
>> claiming to "own" Unix(tm) really gets to me. At the time Unix was
>> developed, WITH SUBSCRIBER FUNDS, AT&T was a regulated monopoly,
>> specifically prohibited from being in the computer business.... an
>> awfully good case could be made that the customers, NOT Ma Bell, own
>> Unix. Considering the AT&T customer base, that is pretty much the
>> mortal equivalent of public domain.
>
>[...]
>Regulated monopoly is a special arrangement between a private
>enterprise and the public. Its purpose is to gain the efficiencies of
>a single supplier, without allowing the supplier to restrict output and
>charge monopoly prices, and without establishing a government
>enterprise. A private enterprise is granted an exclusive franchise and
>regulated so that it can not charge monopoly prices.
OK, and we the people included in the regulations for AT&T,
"you are in the phone business, not the computer business".
>
>A private enterprise operating as a regulated monopoly is not a public
>enterprise, but an alternative to public enterprise. It is is owned by
>stockholders who are financially responsible for its mistakes and
>entitled to the rewards of its successes.
As even a casual glance at the record would show, this may
be true on paper, but has no relation whatever to fact. In
fact, no matter how poorly managed, regulated monopolies
have historically been guaranteed a specific level of return
on investment, typically in the region of 15%.
> It is managed by its own
>officers under the direction of a board appointed by its stockholders.
>Its operations are restricted only by the terms of its agreements with
>the governments and agencies that regulate it. Any inference that its
>assets are owned by anyone but its stockholders is purely imaginary.
Again, the case here is rather special. AT&T developed UNIX
"for internal use only", using monies derived from customer
billings, at a time when they were forbidden by law to engage
in the development of computer hardware or software for sale.
Fine. They distributed UNIX to non-commercial users at cost
of media, and got gobs of debugging and upgrade help. Again,
all accomplished at phone company customer expense. Now,
comes divestiture, and _instantly_, a company which had been
involved, by law, in no development of hardware or software
for sale has a $30,000 product on the market. Sure looks fishy
to me. ;-)
My point (I _must_ have one, right?) is that that product is
still just fine for AT&T internal use, and any value it has
in that regard is perfectly legitimate. However, the added
commercial value derives from development work during a time
when commercial software development work by AT&T was _illegal_,
and, by normal rules of law, should not accrue to AT&T. Taking
a look at who might be the next most likely beneficiary of this
added value, the customers who, all unknowingly, bought and
paid for it, sure look like the prime candidates. Since that is
essentially the entire US populace, plus or minus a few
phone-phobics, that is pretty much the equivalent of public domain.
>Disclaimer: I usually omit disclaimers, but that's the nicest thing I
>ever said publicly about my employer, and my employer may disagree.
I'm sure they appreciate the support, considering how badly they
have ripped off their customer base in this case, and how rich
it is making them to own UNIX.
>
>M. B. Brilliant Marty
>AT&T-BL HO 3D-520 (201)-949-1858
>Holmdel, NJ 07733 ihnp4!houdi!marty1
Not having an employer besides me, I guess one way or another I have to
be responsible for what I say. Miracles never cease.
Kent, the man from xanth.
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: Who owns Unix(tm)?...
Message-ID: <8525@utzoo.UUCP>
Date: Mon, 31-Aug-87 14:26:43 EDT
Article-I.D.: utzoo.8525
Posted: Mon Aug 31 14:26:43 1987
Date-Received: Mon, 31-Aug-87 14:26:43 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA>
Organization: U of Toronto Zoology
Lines: 32
Keywords: stockholder ownership private enterprise
> ...comes divestiture, and _instantly_, a company which had been
> involved, by law, in no development of hardware or software
> for sale has a $30,000 product on the market...
You have the history slightly wrong, Kent. Unix was available to commercial
outfits at scandalous prices well before divestiture, on the same theory as
for educational users: "we developed this for our own use, since you want
it you can have it, as is, don't call us if it breaks". What started with
divestiture was the marketing effort.
> My point (I _must_ have one, right?) is that that product is
> still just fine for AT&T internal use, and any value it has
> in that regard is perfectly legitimate. However, the added
> commercial value derives from development work during a time
> when commercial software development work by AT&T was _illegal_,
> and, by normal rules of law, should not accrue to AT&T...
The same can be said of almost any AT&T asset, however. The real question
underlying all this is whether AT&T, the company, should inherit some of
the assets of the Bell System, the defunct regulated monopoly. Many of
those assets are of great value to a company which can market them freely,
instead of being bound by the restrictions of regulation. Most of them
were created using the Bell System's monopoly-derived money, many at a
time when using them to compete in the open market would have brought the
wrath of the government down on Bell instantly. Without those assets,
AT&T would largely cease to exist. Think of it as the price we pay for
the continued existence of Bell Labs.
(Cripes, I never thought I'd find myself defending AT&T...!)
--
"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!husc6!necntc!necis!encore!adamm
From: ad...@encore.UUCP (Adam S. Moskowitz)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <1883@encore.UUCP>
Date: Mon, 31-Aug-87 18:08:36 EDT
Article-I.D.: encore.1883
Posted: Mon Aug 31 18:08:36 1987
Date-Received: Fri, 4-Sep-87 07:30:36 EDT
References: <8520@utzoo.UUCP>
Organization: Encore Computer Corp., Marlboro, MA
Lines: 25
In article <8...@utzoo.UUCP>, he...@utzoo.UUCP (Henry Spencer) says:
>> ... 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.
It's not only less charitable, it's dumb. Having met Richard and dealt with
him technically (although not a lot), I'd bet he *could* write a small
program. I know I can. [insert "war story" about growing up on an 8K
machine here] The point being this: trying to squeeze complex programs into
small spaces is a waste of effort. It often results in programs that either
a) have some (often unusable) limits (file name sizes, # of files, &c.), or
b) are hard to read/maintain, because too much thought had to go into trying
to fit the damn thing into a small space, and not enough effort was left to
making the program functional/maintainable. I'm not saying you can't write
a program that does everything including wash the dishes, has no limits, is
easy to maintain, and fits in 640K (or whatever), but why add the size limit?
Why kill yourself to deal with what many people feel is a bad hardware design?
--
Adam S. Moskowitz ...!{decvax,ihnp4,linus,necntc,talcott}!encore!adamm
"Gonna die with a smile if it kills me!" -- Jon Gailerfut
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!sdcsvax!nosc!humu!uhmanoa!
aloha1!islenet!richard
From: rich...@islenet.UUCP
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <3470@islenet.UUCP>
Date: Tue, 1-Sep-87 00:14:18 EDT
Article-I.D.: islenet.3470
Posted: Tue Sep 1 00:14:18 1987
Date-Received: Thu, 3-Sep-87 02:22:50 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA>
<8520@utzoo.UUCP>
Reply-To: rich...@islenet.UUCP (Richard Foulk)
Organization: Islenet Inc., Honolulu
Lines: 25
In article <8...@utzoo.UUCP> he...@utzoo.UUCP (Henry Spencer) 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.
>
> 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.
>
Leave it to someone who's been using small, out-dated equipment for
years now to be so publicly unkind.
How seemingly intelligent people can find the need to belittle
others publicly, without provocation, is a mystery.
But to attack someone who writes software and distributes it free of
charge, to attack them because they don't cater to your particular
obsolete machinery is amazingly selfish and stupid.
--
Richard Foulk ...{dual,vortex,ihnp4}!islenet!richard
Honolulu, Hawaii
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!orville.nas.nasa.gov!fouts
From: fo...@orville.nas.nasa.gov.UUCP
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Small is Beautiful (was Re: Free Software Foundation)
Message-ID: <2640@ames.arpa>
Date: Tue, 1-Sep-87 13:56:35 EDT
Article-I.D.: ames.2640
Posted: Tue Sep 1 13:56:35 1987
Date-Received: Wed, 2-Sep-87 07:22:50 EDT
References: <8520@utzoo.UUCP> <1883@encore.UUCP>
Sender: use...@ames.arpa
Reply-To: fo...@orville.nas.nasa.gov.UUCP (Marty Fouts)
Lines: 29
In article <1...@encore.UUCP> ad...@encore.UUCP (Adam S. Moskowitz) writes:
> . . ., but why add the size limit?
>Why kill yourself to deal with what many people feel is a bad hardware design?
I do much of my work on a Cray 2. It has 2 gigabytes of REAL memory.
I still try to write small programs. (Some are even under a gigabyte
;-) Seriously, small is something that a reasonable amount of effort
should be put into achieving. Like most programming credos, it should
be practiced in moderation, rather excess. When you can do it without
destroying maintainability, you can accomplish:
1) Faster code. By taking the time to come up with a compact
algorithm, you can usually find one faster than you were
going to use in the first place.
2) Easier to understand code. This is only true if you try for
moderation, but less code, if it is well thought out, means
less to understand when trying to comprehend the program.
3) More useful code. The more people who can use your code, the
better off you are.
You can carry the less is more credo to far and get unmaintainable
code. You can take memory is cheap to far and get unusable code. As
always in engineering, truth lies in the middle ground, near the
swamp.
Marty
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!mnetor!uunet!seismo!mimsy!chris
From: ch...@mimsy.UUCP (Chris Torek)
Newsgroups: comp.arch,comp.unix.wizards
Subject: Re: `small is beautiful'
Message-ID: <8426@mimsy.UUCP>
Date: Sat, 5-Sep-87 13:11:08 EDT
Article-I.D.: mimsy.8426
Posted: Sat Sep 5 13:11:08 1987
Date-Received: Sun, 6-Sep-87 08:12:54 EDT
References: <8520@utzoo.UUCP> <1883@encore.UUCP> <677@stracs.cs.strath.ac.uk>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 20
On the other hand, these editors, compilers, and other utilities
that fit in a small space do not get away without paying something
for it: Most of them (as was just observed in re benchmarks) use
temporary files and so do quite a bit of I/O. Last night Fred
Blonder wrote an anagram unscrambling program. It is quite small,
40K even with all the runtime goo allocated by the 4.3BSD C library.
It gets away with this by rescanning the dictionary when it recurses
(it will tell you that an `umbrella' can be `all umber' and owned
by `earl blum'). It would go much faster if he read in the entire
dictionary once, and made up its histogram information and kept it
in core. (On the other hand, it would also go faster if it copied
the dictionary to histogram form in a file. Well, what do you
expect from a 30 minute hack?)
The point is that `small' is usually just one end of a long space/time
tradeoff line. (But remember that an infinite amount of memory takes
an infinite amount of time to access :-) .)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
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)
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: <8579@utzoo.UUCP>
Date: Mon, 14-Sep-87 21:39:06 EDT
Article-I.D.: utzoo.8579
Posted: Mon Sep 14 21:39:06 1987
Date-Received: Mon, 14-Sep-87 21:39:06 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM>
Organization: U of Toronto Zoology
Lines: 23
> Leave it to someone who's been using small, out-dated equipment for
> years now to be so publicly unkind.
Actually, I'm about to start using much larger and more modern equipment.
This does not diminish my distaste for software that seems to be written
on the assumption that 4MB memory boards cost a nickel apiece.
To pick a non-GNU example, graphing the size of the ls(1) command versus
time is an interesting exercise, not to be recommended if you are susceptible
to nausea and vomiting. To pick an example that is ready at hand, the Sun
3.2 ls(1) is four times the size of the V7 ls(1). It's not four times as
good; the improvement in functionality might charitably be put at 25%.
This sort of gratuitous bloat is endemic in post-PDP11 software. While I
do not claim that 16-bit address spaces are anything but a pain -- I have
much more experience with this than most of my readers! -- they do tend
to teach respect for resource consumption. I will not be sorry to leave
the PDP11 behind, but it won't be trivial to make our glorious new 32-bit
machine support as many users -- doing the same things! -- as our lousy
little 11/44, despite much more memory and a much faster CPU.
--
"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
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: <8584@utzoo.UUCP>
Date: Tue, 15-Sep-87 13:46:00 EDT
Article-I.D.: utzoo.8584
Posted: Tue Sep 15 13:46:00 1987
Date-Received: Tue, 15-Sep-87 13:46:00 EDT
References: <8520@utzoo.UUCP>, <1883@encore.UUCP>
Organization: U of Toronto Zoology
Lines: 13
> > 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.
>
> It's not only less charitable, it's dumb. Having met Richard and dealt with
> him technically (although not a lot), I'd bet he *could* write a small
> program...
Actually, having said as much in private mail, I might as well say it in
public: Stallman *is* quite competent -- I may question his judgement but
not his ability -- and certainly could write a small program to save his life.
--
"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