HDTenEightyP/NetNews huggingface dataset:
From: steinarb@idt.unit.no (Steinar Bang)
Subject: Minimum requirements for NFS on Mach 3.0
Organization: Norwegian Institute of Technology, Trondheim, Norway
Distribution: comp
Date: 29 Sep 92 14:30:32

Hi!

I'm looking for the minimum configuration available for running NFS
(the Network File System) with the Mach 3.0 microkernel.

Problem:
 o I am working on porting the Mach 3.0 to a i486-based hypercube
   machine.
   Each node in the hypercube has an Ethernet controller (i82596CA).
   (Each node has two SCSI-controllers as well, but getting them to
   work is the next step.)

   When booting a node I would like to get NFS up and running as
   quickly as possible, NFS-mounting the development host's file
   system on the node (for VM-paging and loading and executing Mach
   user-level programs).

My question is therefore:
 What's the minimum requirements for getting NFS up and running under
 the Mach 3.0 microkernel? The Unix Server? Or is POE good enough? BSD
 TCP/IP code? Sun RPC? 

Thanx!

- Steinar
Newsgroups: comp.os.mach
From: jdoyle@phy.umassd.edu (J.D.)
Subject: question on BSDSS4
Summary: why are bsdss4 binary objects being distributed in cmu sup ?
Organization: University of Massachusetts Dartmouth
Date: Sat, 26 Sep 1992 17:14:09 GMT

Recently, I SUPped a copy of the i386 mach3.release collection from CMU.
I noticed that the collection included
i386_mach/special/emulator.BSDSS4,vmunix.BSDSS4...

I am slightly confused. I know that CMU halted distribution of the
source code to BSDSS3,BSDSS4 when USL filed again UCB and BSDI. However,
why do the binaries continue to be made available?

Does this imply that CMU is internally pursuing development of the BNR2
based signle server module with the intention of later release
depending on the judgement of the courts?



..... Jim Doyle     (jdoyle@mdphya.phy.umassd.edu)



Newsgroups: comp.os.mach
From: c7821027@csie.nctu.edu.tw (Shih-Hao Liu)
Subject: Looking for Adaptec 1542 Driver
Organization: National Chiao Tung University
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 6 Oct 1992 06:21:12 GMT

Is anybody know where I can find the Adaptec 1542 Driver for mach 2.5?

Thanx in advance.

c7821027@csie.nctu.edu.tw       

Shih-Hao Liu

Newsgroups: comp.os.mach
From: mjerosc@erenj.bitnet (Michael Jerosch-Herold)
Subject: MacTenon
Followup-To: comp.os.mach
Organization: Exxon Research and Engineering, New Jersey
Date: Mon, 28 Sep 1992 23:48:54 GMT

Could somebody please e-mail me the address of Tenon,
who distribute Mach for the Mac?	
My e-mail address is: mjerosc@erenj.bitnet
Or please post info on net!

Thanks in advance!

Michael Herold
Newsgroups: comp.os.mach
From: sp@osf.org (Simon Patience)
Subject: Re: OSF for 386?
Organization: Open Software Foundation
Date: Tue, 29 Sep 1992 08:26:51 GMT

In article <GTHAKER.92Sep28112145@trantor.atl.ge.com>, gthaker@fergie.dnet.ge.com (Gautam H. Thaker) writes:
> In article <1992Sep23.115943.22188@osf.org> sp@osf.org (Simon Patience) writes:
> 
>    [..edited licensing terms follow...]
> 			   OSF/1 MK Distribution
> 			   ---------------------
>    Licensing Conditions
>    --------------------
>    In order to obtain the OSF/1 MK Technology Release, your organisation must 
>    satisfy the following conditions:
> 
[ ... ]
>    o Have a valid OSF/1 (TM) Release 1 source license which covers the machine on 
>      which the OSF/1 MK sources will reside. 
> 
>      Costs:
>      Without distribution rights: $25000
> 
>    In addition, you should send to James Loveluck (loveluck@gr.osf.org) the model 
>    and CPU number of the machine on which you will install OSF/1 MK sources, for 
>    validation by OSF Operations.
> 
>    Currently, there is no additional fee for the OSF/1 MK Technology Release.
> 
>      Simon Patience
> 
> This is a rather discouraging price structure. As a commercial organization
> what the above tells me is that if I want to set up a lab
> with 8 OSF/1 MK machines my cost will be (approximately):
>
> 	486-50 MHz, 16 Mb memory, 200 Mb hard drive EISA etc. $3K each
> 	$25k to be member of OSF.
>         Source licenses for my 486 machines                   $25K each.
>            _____________________________________________________________
> 	Total	                                              $249K
> 
> This seems high when one considers that hardware is only $24K of this
> total!  It seems that OSF/1 licensing is only meant for people who plan to
> get redistribution rights and then sell a lot of binaries. 

Unfortunately this is not an OSF restriction. OSF/1 contains USL licenced
code and this restriction comes from the USL licence for System V. Sorry 
but your complaints should go to USL, not us, as we don't like it either.

Simon.

-- 
  Simon Patience
  Open Software Foundation			Phone: +33-76-63-48-72
  Research Institute				FAX:   +33-76-51-05-32
  2 Avenue De Vignate				Email: sp@gr.osf.org
  38610 Gieres, France				       uunet!gr.osf.org!sp
Newsgroups: comp.os.mach
From: jkh@esel.lotus.com (Jordan K Hubbard)
Subject: Shared libraries for UX?
Organization: Lotus Ireland
Distribution: comp
Date: 5 Oct 92 14:37:56

Is anyone working on adding shared libraries to the UX server?
With all the kernel hacking expertise at CMU, it stands to
reason that someone would be interested.

Has anyone looked at how linux implements them?  I don't have a copy,
so I can't check to see whether it's done primarily in the kernel or
an ld.so kinda hack.  If it's no significantly kernel based, perhaps
some code could be borrowed from it.

1.6MB motif binaries are getting really old.

					Jordan
From: gthaker@fergie.dnet.ge.com (Gautam H. Thaker)
Newsgroups: comp.os.mach
Subject: Re: OSF for 386?
Date: 28 Sep 92 15:21:45 GMT
Organization: /home/gthaker/.organization

In article <1992Sep23.115943.22188@osf.org> sp@osf.org (Simon Patience) writes:

   [..edited licensing terms follow...]
			   OSF/1 MK Distribution
			   ---------------------
   Licensing Conditions
   --------------------

   In order to obtain the OSF/1 MK Technology Release, your organisation must 
   satisfy the following conditions:

   o Be an OSF member

     Costs:
     $25000 per year for commercial organisations,

   o Have a valid OSF/1 (TM) Release 1 source license which covers the machine on 
     which the OSF/1 MK sources will reside. 

     Costs:
     Without distribution rights: $25000

   In addition, you should send to James Loveluck (loveluck@gr.osf.org) the model 
   and CPU number of the machine on which you will install OSF/1 MK sources, for 
   validation by OSF Operations.

   Currently, there is no additional fee for the OSF/1 MK Technology Release.

     Simon Patience

This is a rather discouraging price structure. As a commercial organization
what the above tells me is that if I want to set up a lab
with 8 OSF/1 MK machines my cost will be (approximately):

	486-50 MHz, 16 Mb memory, 200 Mb hard drive EISA etc. $3K each
	$25k to be member of OSF.
        Source licenses for my 486 machines                   $25K each.
           _____________________________________________________________
	Total	                                              $249K

This seems high when one considers that hardware is only $24K of this
total!  It seems that OSF/1 licensing is only meant for people who plan to
get redistribution rights and then sell a lot of binaries. 

Gautam H. Thaker (gthaker@atl.ge.com) 609-866-6412 (fax x6397. Dialcom 8-777)
GE Adv. Tech. Lab., MS 145-2; Route 38; Moorestown, NJ 08057.  767-4396 (home)

--
Gautam H. Thaker 
Newsgroups: comp.os.mach
From: loveluck@gr.osf.org (James Loveluck)
Subject: Re: OSF for 386?
Organization: Open Software Foundation
Date: Wed, 30 Sep 1992 10:08:43 GMT

In article <1992Sep29.082651.12579@osf.org> sp@osf.org (Simon Patience)  
writes:
> In article <GTHAKER.92Sep28112145@trantor.atl.ge.com>,  
gthaker@fergie.dnet.ge.com (Gautam H. Thaker) writes:
> > In article <1992Sep23.115943.22188@osf.org> sp@osf.org (Simon  
Patience) writes:
> > 
> >    [..edited licensing terms follow...]
> > 			   OSF/1 MK Distribution
> > 			   ---------------------
> >    Licensing Conditions
> >    --------------------
> >    In order to obtain the OSF/1 MK Technology Release, your  
organisation must 
> >    satisfy the following conditions:
> > 
> [ ... ]
> >    o Have a valid OSF/1 (TM) Release 1 source license which covers the  
machine on 
> >      which the OSF/1 MK sources will reside. 
> > 
> >      Costs:
> >      Without distribution rights: $25000
> > 
> >    In addition, you should send to James Loveluck  
(loveluck@gr.osf.org) the model 
> >    and CPU number of the machine on which you will install OSF/1 MK  
sources, for 
> >    validation by OSF Operations.
> > 
> >    Currently, there is no additional fee for the OSF/1 MK Technology  
Release.
> > 
> >      Simon Patience
> > 
> > This is a rather discouraging price structure. As a commercial  
organization
> > what the above tells me is that if I want to set up a lab
> > with 8 OSF/1 MK machines my cost will be (approximately):
> >
> > 	486-50 MHz, 16 Mb memory, 200 Mb hard drive EISA etc. $3K each
> > 	$25k to be member of OSF.
> >         Source licenses for my 486 machines                   $25K  
each.
> >             
_____________________________________________________________
> > 	Total	                                              $249K
> > 
> > This seems high when one considers that hardware is only $24K of this
> > total!  It seems that OSF/1 licensing is only meant for people who  
plan to
> > get redistribution rights and then sell a lot of binaries. 
> 
> Unfortunately this is not an OSF restriction. OSF/1 contains USL  
licenced
> code and this restriction comes from the USL licence for System V. Sorry 
> but your complaints should go to USL, not us, as we don't like it  
either.
> 
> Simon.
> 
> -- 
>   Simon Patience
>   Open Software Foundation			Phone: +33-76-63-48-72
>   Research Institute				FAX:   +33-76-51-05-32
>   2 Avenue De Vignate				Email: sp@gr.osf.org
>   38610 Gieres, France				        
uunet!gr.osf.org!sp

--
---------------

It does not cost 25K$ for each CPU. This is the "Initial source license"  
fee, which covers one designated COU; addtional CPUs can be added for 3K$.
[NB These fees are for OSF/1 Release 1, and have changed foe Release 1.1;  
for up to date information you should contact OSF Direct Channels  
(direct@osf.org)]

James
Newsgroups: comp.os.mach
From: sp@osf.org (Simon Patience)
Subject: Re: Mach/OSF Working Groups
Organization: Open Software Foundation
Date: Tue, 6 Oct 1992 06:58:29 GMT

> I am interested in paricipating in Mach and OSF working groups/commitees.  Does
> anyone know how I can get started?

I will let someone from CMU answer for Mach but for OSF, first you have to
be a member. This can be done through OSF Direct Channels on 617 621
7300/8835 or by mail at

	OSF Direct Channels
	11 Cambridge Center
	Cambridge, MA 02142
	USA

They will also be able to provide you with all the information about the
various groups that are active in OSF. 

Simon.


-- 
  Simon Patience
  Open Software Foundation			Phone: +33-76-63-48-72
  Research Institute				FAX:   +33-76-51-05-32
  2 Avenue De Vignate				Email: sp@gr.osf.org
  38610 Gieres, France				       uunet!gr.osf.org!sp
From: xenidis@maccs.dcss.mcmaster.ca (Jimi X)
Newsgroups: comp.os.mach
Subject: mach on Suns (not in FAQ)
Date: 2 Oct 92 12:58:11 GMT
Organization: Department of Computer Science, McMaster University


	According to the FAQ this is not recomended (something to do with sun
themselves) but has any mody done it I would really like to see if can
be done (I neeeeeeed a real time OS for my IPC oncs in a while)


-jimi x
Newsgroups: comp.os.mach,comp.org.eff.talk,misc.int-property,comp.unix.bsd,alt.suit.att-bsdi,comp.sys.mac.advocacy
From: witr@rwwa.COM (Robert Withrow)
Subject: Re: Letter asking for help with Apple from the US VP
Reply-To: witr@rwwa.com
Organization: R.W. Withrow Associates
Distribution: usa
Date: Sat, 26 Sep 1992 16:15:13 GMT

In article <1992Sep25.212628.15982@pony.Ingres.COM>,
 jpk@Ingres.COM (Jon Krueger) writes:

| > an arguably more ``average'' person like me still believes in the
| > legal system, warts and all
| 
| Ah, show me the person who gets a parking ticket and rejoices that
| the system works!  I believe we've found him.

Are you perhaps confused about the difference between ``believes'' and
``rejoices''.

-- 
 Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM
 R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
From: gambert@screamer.csee.usf.edu (Allen Gambert)
Newsgroups: comp.os.mach
Subject: ppp between sun and mach 386
Date: 25 Sep 92 13:49:05 GMT
Reply-To: gambert@screamer.csee.usf.edu (Allen Gambert)
Organization: University of South Florida at Tampa

I compiled and ran ppp on both my sun IPC and my mach 386, theres only one
problem.  Connecting two 386's together or two suns together works fine.
Its when connecting a sun to a 386 that gives me a problem.  It seems that the
problem has to do with the little/big endian issue.  When I turn on debugging I
notice that both machines return the ip address in reversed order, that is, my 
386 prints the address as follows: 234f0105:234f0106 and the sun prints
the address as follows: 06014f23:05014f23.  

I have three questions:

 1) Has anyone succussfully gotten ppp to work between two architectures
    that use little/big endian format, and if so what is the trick?

 2) Where should I start looking in order to isolate the problem?

 3) Where in the code to I need to worry about byte swapping?


I am using the version of ppp for my sun that was done by Brad Clements;
the version that uses the streams based device driver.  My 386 is using
the same code except the device driver is if_ppp.c instead of ppp_if.c
and ppp_async.c.

Any help in solving this matter will be greatly appreciated.

Thanks,

Allen
Newsgroups: comp.os.mach
From: morse@quark.mpr.ca (Daryl Morse)
Subject: Re: OSF for 386?
Organization: MPR Teltech Ltd., Burnaby, BC, Canada.
	<GTHAKER.92Sep28112145@trantor.atl.ge.com>
	<1992Sep29.082651.12579@osf.org>
Date: 29 Sep 92 09:09:11


In article <1992Sep29.082651.12579@osf.org> sp@osf.org (Simon Patience) writes:
  In article <GTHAKER.92Sep28112145@trantor.atl.ge.com>, gthaker@fergie.dnet.ge.com (Gautam H. Thaker) writes:
> > In article <1992Sep23.115943.22188@osf.org> sp@osf.org (Simon Patience) writes:

[stuff about OSF licensing policies deleted]

> > This is a rather discouraging price structure. As a commercial organization
> > what the above tells me is that if I want to set up a lab
> > with 8 OSF/1 MK machines my cost will be (approximately):
> >
> > 	486-50 MHz, 16 Mb memory, 200 Mb hard drive EISA etc. $3K each
> > 	$25k to be member of OSF.
> >         Source licenses for my 486 machines                   $25K each.
> >            _____________________________________________________________
> > 	Total	                                              $249K
> > 
> > This seems high when one considers that hardware is only $24K of this
> > total!  It seems that OSF/1 licensing is only meant for people who plan to
> > get redistribution rights and then sell a lot of binaries. 

>   Unfortunately this is not an OSF restriction. OSF/1 contains USL licenced
>   code and this restriction comes from the USL licence for System V. Sorry 
>   but your complaints should go to USL, not us, as we don't like it either.

I recall OSF announcing its intent to produce an operating system free
of USL code. Is that still an objective? Is progress being made? When
will a USL-free version of OSF/1 be available? That would go a long
way to getting OSF/1 out into the world as it would allow OSF to make
its OS available at *reasonable* costs to both academic and commercial
institutions for research purposes, unlike the current situation.

On another note, it would be useful to know in general, at what stage
the work with OSF/1 and OSF/1 MK is at. When will OSF/1 MK be
industrial strength? I'd also be interested in knowing whether the
concerns aired by such companies as HP and IBM with regard to the
performance and robustness of OSF/1 are being addressed. I suppose
this isn't the perfect forum for such information, but comp.os.mach
seems to be as close at it gets.

Thanks.

--
Daryl Morse                     | Voice  : (604) 293-5476
MPR Teltech Ltd. 		| Fax    : (604) 293-5787
8999 Nelson Way, Burnaby, BC    | E-Mail : morse@mpr.ca
Canada, V5A 4B5                 |        : mprgate.mpr.ca!morse@uunet.uu.net
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.mach
Subject: Re: Shared libraries for the UX server - anyone working on it?
Date: 5 Oct 92 15:30:08 GMT
Distribution: comp
Organization: University of Helsinki

In article <JKH.92Oct5134415@esel.lotus.com> jkh@esel.lotus.com (Jordan K Hubbard) writes:
>The subject says it all...   Does anyone know if Linux's shared libraries
>are done in the kernel, or all with ld.so?  Perhaps some code could be
>borrowed (I don't have a copy of Linux, so I can't see for myself).

Linux's shared libraries are essentially just a simple mmap() with some
sanity-checking (executable header) at a fixed address.  Under linux
this is currently implemented as a special loadlib() system call, as we
don't yet have a complete implementation of mmap().  As soon as I get
the energy to correct some of my not-so-good mm design decisions, the
linux implementation will be written to totally use mmap(). 

>In any case, shared libraries would be a Really Good Thing.  1.6MB motif
>binaries are getting old fast.  I'm surprised with all the OS hackers
>at CMU that noone has taken up this particular torch.

I assume mach386 already has a fully implemented mmap(), so implementing
shared libraries is just a question of how to do it cleanly.  Do you
want a shared library that has a fixed address (simple, and similar to
linux or sysvr3) or do you want libraries that are position-independent
as under sysvr4 (? - I haven't actually used them, but so I understand). 
And there is the question of making libraries updateable while being
backwardly compatible. 

Under linux, only the latest libraries are supposed to be compatible
over different versions using a jump-table - earlier shared libraries
were decided at link-time.  Do you want to use jump-tables or a
linker-loader or some other solution...  The discussion can get pretty
heated :-)

		Linus
From: gthaker@fergie.dnet.ge.com (Gautam H. Thaker)
Newsgroups: comp.os.mach
Subject: NFS for 486 PC running MACH 3.0
Date: 6 Oct 92 13:17:43 GMT
Organization: GE Advanced Technology Laboratories

I received several "me too" answers for my posting about running NFS on 
Mach 3.0 on 486 PCs and the following reply from a reader who asked me
to post it to comp.os.mach. Perhaps this will help others, it does not
do me any good at all as we are a commercial company and are not in a
position to acquire Sun source license.


------------------------------------------------------------------------
> We have several 486-50 PCs with 32 Mb memory running Mach 3.0 and the
> single server Unix. Is it possible at all to run NFS on these machines?
 
Yes, I got NFS up just *yesterday* on our 486 under MACH 3.0
(MK78/UX38); My understanding: you have to be an academic site, and
you need to get a letter from Sun authorizing you to get the NFS
source and present it to CMU; this is tantamount to having a complete
Sun source license these days (I believe that there used to be some
seperate academic NFS license that Sun no longer supports).
 
The NFS utilities like mount, portmap, the rpc libraries, etc are
built from BSD 4.3 Tahoe sources, and are supped via
 
src.NFS host=x29.mach.cs.cmu.edu hostbase=/i386 base=<wherever> prefix=NFS 
 
The NFS mods to the Mach 3.0 UX server are supped via
 
mach3.unix release=NFS host=x29.mach.cs.cmu.edu hostbase=/usr2 base=<wherever>
 
Kudoes to Lori Iannamico for patiently making all this clear to me.
Lori notes that a new installation guide, i386_install.doc (or .ps) is
available via anonymous ftp from mach.cs.cmu.edu and includes new
instructions on just these points as well as X11R5.  I believe it was in
doc/unpublished, connectivity suffers at the momemt and I cannot check
the path.
 
I experienced small problems.  I had root in more than 8 groups so
that while exporting directories via NFS worked, NFS mounting on the
Mach box wouldn't work; a mod to /etc/groups and a reboot fixed that.
Also, the NFS mount seems to mangle /etc/mtab.
 
> I understand 386BSD has NFS support; could something be used from there?
 
Well, I really don't know how hard it would be getting the NFS support
into the UX server,  the rpc libraries, portmap, nfsd and biod ought
to be straight-forward ports.
 
					Randy Fischer
					fischer@foobar.eng.ufl.edu
--
Gautam H. Thaker
From: mday@jukebox.lcs.mit.edu (Mark Day)
Newsgroups: comp.object
Subject: Re: Passing functions as parameters in an OO environment
Date: 30 Sep 92 15:04:28 GMT
	<1992Sep23.104513.22660@ruby.comlab.ox.ac.uk>
	<1992Sep25.150611.24570@actrix.gen.nz>
	<TMB.92Sep28155404@arolla.idiap.ch>
Organization: MIT Laboratory for Computer Science


   tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

   [...] OOP is not the only way to program in terms of ADT's. OOP is
   one particular approach to programming in terms of ADT's, with its own
   strengths and limitations.

   What limitations, you will ask. Well, one of them is that it is
   difficult to represent a collection of related datatypes and
   operations on them simultaneously. For example, a definition of a
   "graph" may involve related "vertex" and "edge" types, and operations
   with the graph may have to operate on both "vertex" and "edge".
   However, in an OO setting, it is difficult to express the fact that
   only a "vertex" and an "edge" type that have been defined together can
   be used together. 

While I agree with the first quoted sentence, I'm not sure I
understand your justification and explanation following.  I think
you're saying that (in your example) we have a situation like this:

1. vertex is a type implemented by classes vc1 and vc2
2. edge is a type implemented by classes ec1 and ec2
3. ec1 and vc1 can be used together
4. ec2 and vc2 can be used together
5. ec1 is not compatible with vc2
6. ec2 is not compatible with vc1

If this is roughly your scenario, can you explain how you express
these constraints in some other (non-OO) framework?

   Another limitation is that the only form of deriving
   one structure from another is inheritance, which allows you to add
   members but not remove them; a lot of mathematical relationships are
   more conveniently expressed by starting out with some complicated
   mathematical object and "forgetting" some of its structure.

I don't think this is correct.  It's true that when a type S is
intended to be a subtype of type T, the only way to ensure this is to
have all the functionality of type T included in type S.  But if you
want to define an entity as inheriting from some other entity (or
collection of entities), the newly-defined entity doesn't have to be a
subtype of any of the types of the entities from which it inherits.
The net effect is that the newly-defined entity can be "like" the old
entity/entities, but "missing" some of their baggage.  

I know that in lots of OO languages the notions of subtyping and
inheritance are tangled, but they are and should be distinct.
Whatever the virtues or vices of inheritance may be, I think your
complaint here is more based on being forced to express subtype
relationships where you don't want to.

--Mark Day

mday@lcs.mit.edu
Newsgroups: comp.object