HDTenEightyP/NetNews huggingface dataset:
From: michaelv@iastate.edu (Michael L. VanLoon)
Subject: Re: 386BSD + LINIX + GNU + X11R5 on CDROM - let us know what you want!
Organization: Iowa State University, Ames IA
Distribution: comp
Date: Mon, 21 Dec 1992 21:26:38 GMT

In <jcargill.723416044@cs.wisc.edu> jcargill@oka.cs.wisc.edu (Jon Cargille) writes:

>jkh@whisker.lotus.ie (Jordan K. Hubbard) writes:

>>I am working in association with Hypermedia Concepts, Inc. to produce
>>a CDROM for release in the late-January/mid-February timeframe.
>>My initial plan is to provide one CD with the following contents:

>>386BSD (0.1) + patchkit	+ ???	(unpacked)
>>Linux 0.95(?) + ???		(unpacked)
>>X11R5 (PL17) + XFree86 1.1	(unpacked)
>>X11R5 contrib			(compressed tar)
>>GNU sources			(compressed tar)
>>Various miscellaneous utilities (compressed tar)

[etc....]

>My reason for this is that I think a *really* cheap 386bsd
>distribution would be a real boon to the 386bsd community.  (The same
>goes for Linux, though I'm not as familiar with that community) 
>If cds are cheap, more people will buy cdrom drives, and we can ship
>new distributions even cheaper.

>>Also note that while several other CD's have been/are being offered
>>for 386BSD and Linux, I'm not doing this CD in an effort to compete
>>with them.  My main focus in producing a CD that offers good value for
>>money (packed full) and is very aggressively priced so that students
>>and other traditionally penniless interest groups can get in on the
>>UNIX revolution [grin] as cheaply as possible.  

I've noticed everytime this project is mentioned, it's mentioned as a
join 386BSD/Linux disc.  While this may be necessary to get the extra
market share to make it really inexpensive, I simply have no desire to
have any Linux code sitting around, and never will.

If it were feasable, I think the space on the disc would be much
better spent if we could come up with seperate CD-ROMS for 386BSD and
Linux.  This would allow us to put more on each ROM besides the base
operating system, and not have a bunch of stuff filling up the disc
that many of us will never touch.  Just my thoughts on the matter...

-- 
------------------------------------------------------------------------------
  Michael L. VanLoon                           Project Vincent Systems Staff
  michaelv@iastate.edu              Iowa State University Computation Center
------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386bsd] Will 7000-FASST2 driver make it for 0.2?
Organization: Weber State University  (Ogden, UT)
Distribution: comp
Date: Fri, 1 Jan 93 22:39:22 GMT

In article <SPERBER.93Jan1162725@annecy.peanuts.informatik.uni-tuebingen.de> sperber@annecy.peanuts.informatik.uni-tuebingen.de (Michael Sperber) writes:
>I vaguely recall that someone is working on a 7000 driver for 386BSD.
>Is there any chance that it will be released in the near future?  Will
>it be part of 386BSD 0.2?

I have a WD7000-FASST2/WD7000-ASC driver that I have written under Julians
SCSI system.  If you also have a WD7000 series card, then you know that the
wd driver probe routine finds the card, incorrectly identifying it as a
standard non-SCSI drive.  For the purposes of driver coexistance, this is
unacceptable; however, I haven't been able to get the wd probe routine to
*NOT* recognize the card without also trashing it's ability to recognize
several of the RLL controllers in the machines I have access to.  I had
intended to wait until this problem was resolved to release the driver.

The current activities re USL may greatly impact my ability to contribute
to 386BSD at all; I have already self-censored *major* work I have done with
the file system, networking, and device driver interfaces because I felt it
was too close to work in progress for my employer.  My WD7000 driver and
the necessary kernel changes to support it will probably fall victim to
non-competition.

If anyone else is doing work on a WD7000 driver, I encourage you to continue;
I will be working on an updated FAQ, issues dealing with internationalization,
and several other things I find of personal interest in the potentially
limited time I have left to play around.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: marelli@ghost.dsi.unimi.it (Paolo Marelli)
Subject: 386bsd and AT&T SVR4 compatibility
Organization: Computer Science Dep. - Milan University
Date: Tue, 22 Dec 1992 12:18:31 GMT


 I'm very interested in obtain some information about
 compatibility between 386bsd an AT&T SVR4 or similar
 unix version like Consensys.

 Do the excutables use the same format ?

 Any suggestion welcome .

 Thanks in advance,

         Paolo Marelli
         marelli@colos3.usr.dsi.unimi.it

Newsgroups: comp.unix.bsd
From: vikki@e40-008-11.MIT.EDU (Vikki King)
Subject: Re: [386BSD] NE/2000 and packet filter
Organization: Massachvsetts Institvte of Technology
X-Newsreader: Tin 1.1 PL4
Date: Thu, 31 Dec 1992 12:40:32 GMT

Hi!

	I was trying to get the BPF working (compiled) too.
When it got to doing the programming stuff in the kernel files, I got lost.
Is there any chance that the changes that you've made might be able to help
me get BPF working with my 3C503/386BSD?  The thing that I needed most was
to get the rarpd that is a part of the BPF.  Thanks!!


-John
jackson@a1.mec.mass.edu or vikki@athena.mit.edu
Newsgroups: comp.unix.bsd
From: rivers@ponds.uucp (Thomas David Rivers)
Subject: Re: XFree86 problem in XDrawSegments
Date: Wed, 30 Dec 1992 14:03:52 GMT

In article <1992Dec30.063602.8978@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>In article <1992Dec30.013451.13074@ponds.uucp> rivers@ponds.uucp (Thomas David Rivers) writes:
>>
>> In trying to get cbzone up and running in 386bsd; I discovered the 
>> following problem.
>>
>> I'm using XFree86 version 1.1 as available on agate.
>>
>> After the game starts up (opens the display and does some drawing) it
>> will bomb out with the following message:
>>
>>XIO:  fatal IO error 14 (Bad address) on X server ":0.0"
>>      after 400 requests (399 known processed) with 17 events remaining.
>>
>>
>>  A breakpoint in _XDefaultIOError() reveals the following traceback:
>>
>>    _XDefaultIOError()
>>    _XIOError()
>>    _XSend()
>>    _XDrawSegments()
>>    multiline()              <----- cbzone function
>>    drawhorizone()           <----- cbzone function
>>    main()()                 <----- cbzone function
>>
>> It would appear that something is wrong in XDrawSegments....
>>
>> Has anyone else run into this?
>
>I have run into a similar problem (resulting in "BadMatch" errors) on an
>AT&T X terminal.  The problem traced back to a modification of the GC
>occurring before a draw, but not being forced to take effect (basically,
>an event queueing problem).  Using an XSync( Display, False); prior to
>the draw fixed the problem.
>
>
>					Terry Lambert
>					terry@icarus.weber.edu
>					terry_lambert@novell.com
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.
>-- 
>-------------------------------------------------------------------------------
>                                        "I have an 8 user poetic license" - me
> Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
>-------------------------------------------------------------------------------



 Well, I was anxious and since that sounded plausible, I tried it out.

 Unfortunately, it didn't seem to change the situation.  I'm beginning
 to wonder if this is simply a R5 problem - except that I build it
 regularly at work with my own R5 X libraries for the IBM 370 (really, honest.)

 To be specific; I placed an XSync( d, False )  [D is a global Display
 pointer] before the only call to XDrawSegments.  But, sadly enough,
 I still get the same error and same traceback.  

       - Dave Rivers -
       (rivers@ponds.uucp)

p.s. If anyone who has space and is building XFree86 would like to
     take a crack at this, I can mail you the sources, or you can
     find them in the X distribution.
 
 
Newsgroups: comp.unix.bsd
From: alm@netcom.com (Andrew Moore)
Subject: Re: [386BSD] 'tip' and 'su' problems
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Tue, 22 Dec 1992 07:22:03 GMT

In article <1992Dec21.161140.12080@panther.mot.com> asu@server2.panther.mot.com (Russell Trotter) writes:
>Hello,
>
>  I just recently installed 386bsd for the first time.  I also
>installed all 58 patches (except #47) of Lambert's patchkit.  I
>also read his FAQ.  I get the usual "all ports busy" message when
>I try to run tip.  The FAQ said just recompile and that

Chris Demetriou tells me there is now another "FAQ" on agate,
386BSD.BUGLIST.  This covers pretty much everything not covered in
Terry's FAQ - including, if it's not covered, how to set permissions for
tip.

One point that  may not be covered is  serial (com) port  naming.
After applying Terry's patchkit, what used to be com1 is now called
com0 and what used to be com2 is now com1.  This should be reflected in
the /sys/i386/conf/SYSTEM-NAME config file, as well as in /etc/ttys,
/etc/remote and Xconfig (if you run X).  And don't forget to create
/dev/com0.

Here are the permissions on my system:
crw-rw-r--    1 uucp     wheel      8,   0 Dec 21 22:14 /dev/com0
crw-rw-r--    1 uucp     wheel      8,   1 Nov  7 04:15 /dev/com1
crw-rw-r--    1 uucp     wheel      8,   2 Jul  5 21:35 /dev/com2
drwxr-xr-x    2 uucp     wheel         512 Dec 21 22:18 /var/spool/lock
-rw-r--r--    1 uucp     wheel       58941 Dec 21 22:18 /var/log/aculog
-Andrew Moore <alm@netcom.com>
From: mhiroshi@tansei.cc.u-tokyo.ac.jp (H. Murakami)
Newsgroups: comp.unix.bsd
Subject: [386bsd]  NMI messages on the console and log.
Date: 28 Dec 92 16:20:29 GMT
Organization: Hokkaido Univ. However I am subject to tansei for JUNET.


I have been noticed that sometimes the console message
including the word "NMI" appeared.

Following is the file "/var/log/messages" grep-ed by the keyword "NMI":

Please tell me what is wrong with my machine or 386BSD0.1 with many patches.

How I can know what is the syndorome a0 or b0 for the port 61.

---------------------------------------------------------
Nov 22 01:53:03 ps486 /386bsd: NMI port 61 a0, port 70 ff
Nov 22 21:43:05 ps486 /386bsd: NMI port 61 b0, port 70 ff
Nov 23 15:36:55 ps486 /386bsd: NMI port 61 a0, port 70 ff
Nov 25 22:44:36 ps486 /386bsd: NMI port 61 b0, port 70 ff
Nov 25 22:57:03 ps486 /386bsd: NMI port 61 b0, port 70 ff
Nov 26 06:12:47 ps486 /386bsd: NMI port 61 a0, port 70 ff
Nov 26 21:43:29 ps486 /386bsd: NMI port 61 a0, port 70 ff
Nov 27 06:17:17 ps486 /386bsd: NMI port 61 b0, port 70 ff
Nov 27 09:39:34 ps486 /386bsd: NMI port 61 b0, port 70 ff
Nov 27 18:37:38 ps486 /386bsd: NMI port 61 b0, port 70 ff
Nov 28 03:36:34 ps486 /386bsd: NMI port 61 b0, port 70 ff
Nov 30 07:03:32 ps486 /386bsd: NMI port 61 a0, port 70 ff
Dec  4 01:57:48 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec  6 16:17:20 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec  6 22:52:33 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec  6 08:50:48 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec  8 07:20:31 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec  9 12:57:57 ps486 /386bsd: NMI port 61 a0, port 70 ff
Dec 11 06:16:31 ps486 /386bsd: NMI port 61 a0, port 70 ff
Dec 13 06:47:39 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec 14 15:17:22 ps486 /386bsd: NMI port 61 a0, port 70 ff
Dec 16 20:59:27 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec 16 23:02:10 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec 18 22:19:04 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec 19 06:18:56 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec 20 09:18:33 ps486 /386bsd: NMI port 61 a0, port 70 ff
Dec 21 04:44:20 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec 22 05:53:24 ps486 /386bsd: NMI port 61 b0, port 70 ff
Dec 23 19:41:55 ps486 /386bsd: NMI port 61 a0, port 70 ff
Dec 26 18:44:26 ps486 /386bsd: NMI port 61 a0, port 70 ff
Dec 27 13:15:35 ps486 /386bsd: NMI port 61 a0, port 70 ff
---------------------------------------------------------

Thank you.
	Hiroshi Murakami
	mhiroshi@tansei.cc.u-tokyo.ac.jp

Xref: sparky comp.unix.bsd:10552 comp.os.linux:21408
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: Weber State University  (Ogden, UT)
Date: Wed, 30 Dec 92 06:31:29 GMT

In article <1992Dec30.010715.2731@nobeltech.se> ppan@nobeltech.se (Per Andersson) writes:
>In article <1992Dec28.065540.24637@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>>I would also like to see this (although I believe the 32 bit standard in
>>question is Unicode-32).
>>
>>I wonder at the transcribability of such things as Ancient Egyptian
>>Heiroglyphics, where it seems the art work is intimately involved with the
>>meaning; I can't argue, however, that Aramaeic and other dead written
>>languages should probably be represented.  This was the justification for
>>moving to 32 bits suggested in the Unicode Volume II.  One wonders at the
>>amount of memory necessary to store such a font.
>
>Why, oh, why do we have to have another new unicode, invented by some 
>stubborn US companies, when the whole world at last has agreed on
>ISO-10646 ? Not Invented Here ?

I believe you are probably unfamiliar with the ISO-10646 draft standard,
which is a superset of the Unicode (Unicode-16) standard; otherwise, it is
unlikely that you would be confused as to whether or not it were "another
new unicode, invented by some stubborn US companies".  Your attribution of
ISO work to a few US companies is flattering to those of us in the US,
but incorrect, as ISO stands for "International Standards Organization"
and does not consist solely of representatives of US companies.

The discussion of a Unicode-32 standard has already taken place, and is
already stated to be a superset of the Unicode-16 standard, per its
mention in Volume II of the published Unicode standard.  It is likely
(but by no means a foregone conclusion) that the Unicode-32 will either
be a superset of or codify vast portions of the ISO-10646 draft standard.

I doubt that "stubborn US companies" have large markets in Ancient
Egyptian Heiroglyphics or Aramaeic which they so unwilling to give up
as to attempt to cram a new standard down your throat.  8-0.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
From: steve2@genesis.nred.ma.us (Steve Gerakines)
Newsgroups: comp.unix.bsd
Subject: [386bsd] startup fixed
Date: 22 Dec 92 22:31:16 GMT
Organization: Genesis Public Access Minix  +1 508 664 0149

Thanks to all who sent me messages for getting my system up and booting
on the hard disk.  I'm using an UltraStor 24F controller in ISA mode,
and a Maxtor 535SY drive.

After finally getting the system to boot off the hard disk, I found that
the system would only start up in standalone, no matter what I did.  For
the benefit of anyone else who runs into this problem, here's what I found.

The boostrap (bootwd) forces standalone mode if one of two conditions
occur:  the disklabel's magic number isn't found, or a labeled partition
doesn't match up with the cylinder boundary the bootstrap physically
loaded from.

Turns out I ran into the second case.  The initial bootstrap (wdboot)
was retreiving an incorrect "off" value (current cylinder offset - the
cylinder the boostrap ended up at after loading) from the controller.

To quickly remedy this, I whipped out the handy dandy diskeditor for the
zillionth time and made the following patches to the first boot sector:

00DB: EC 31 C9  becomes  B0 F4 90
00E1: E4 84 EC  becomes  B0 00 90
                            ^^
                            ||
In this case, my 386BSD "A" partition starts at cylinder 244, so I plugged
in $F400.  

Seems to me it probably would have been a little safer, especially at
do or die boot time, to go after the BIOS for this information instead
of asking the controller directly.

Hope this saves at least one person some needless aggravation.  :-)

- Steve
--
Steve Gerakines           |
steve2@genesis.nred.ma.us |  "I have a three user 386BSD TV license." - me
+1 (508)664-0149          |
Newsgroups: comp.unix.bsd
From: randy@dsndata.dsndata.com (Randy Terbush)
Subject: Re: gcc-2.3.2 and kernel build
Organization: Design Data
Date: Tue, 29 Dec 1992 19:09:43 GMT

>>>>> "Charles" == Charles Hannum <mycroft@hal.gnu.ai.mit.edu> writes:

> I am tripping over many problems created by running fixincludes, and
> using the resulting include files.  What experiences are others
> having?  'fixincludes' used gnu 'sed' on my system since I have
> found some problems with the supplied 'sed'.

  Charles> The installation notes state that you should only run
  Charles> `fixincludes' if you don't already have ANSI-compliant
  Charles> include files.

Doing compiles without the "fixed" include files produces many ANSI
compliance errors.  'sed' failed to make proper changes in many files,
and this is also causing problems.  The 'fixincludes' script finds
that MOST of the include files are NOT ANSI compliant.

I am just beginning to discover what works and doesn't on 386bsd, and
I may still be missing something.  Any suggestions are appreciated.

Randy Terbush ------------------------------------- Design Data, Inc.
UUCP: netcomsv!dsndata!randy ---------------------- 1033 'O' st. Suite 324
INET: randyt@oto.unl.edu -------------------------- Lincoln, NE  68508
--------------------------------------------------- 402-476-8278
From: reink@hpuamsa.neth.hp.com (Reinier Kleipool)
Date: Mon, 21 Dec 1992 10:55:50 GMT
Subject: Re: [386bsd] Kernel build dies, unref symbol _version
Organization: HP-Sales Office-The Netherlands
Newsgroups: comp.unix.bsd

/ hpuamsa:comp.unix.bsd / levinson@halcyon.com (Don Levinson) /  6:07 pm  Dec 19, 1992 /
I am trying to build a new kernel using the code in the src01 distribution
the only change was that I added the files for the DEPCA driver
I have not added the patchkit or anything else. after executing
config, make depend, I execute make and all goes well until it says
"loading 386bsd"
"init_main.o: something about an unreferenced symbol _version"
is there a standard fix for this?

-- 
-------------------------------------------------------------------------------
 Don Levinson	  levinson@halcyon.com	| 	Fatigue Technology Inc.
 "Stupid answers for stupid questions"	| 	100 Andover Park West
    ph:206-246-2010 fax:206-244-9886	| 	Seattle, WA 98188
----------

Hello,

  Nice of you to mention that you did not add the patchkit.....

because this is patch number ONE (patch00001).

in other words the patch to make all other patches work!


Reinier Kleipool.
  /\
-(  )-/##---------------------------------------------------------------------
  }{/   ##    One has to look out  -- Overschie ------------------------------
.====.        for engineers- they  -- Reinier Kleipool  ----------------------
| [] |   begin with sewing machi-  -- Mail -----------------------------------
|    |   nes and  end up with the  -- X400: C=nl A=400net P=hp O=hp S=Kleipool
|    |   atomic bomb.....          -- desk: Reinier Kleipool/ hpitcb/75     --
| [] |              Marcel Pagnol  -- unix: reink@hpuamsa.heth.hp.cm        --
------------------------------------------------------------------------------
From: vikki@e40-008-10.MIT.EDU (Vikki King)
Subject: Re: Amancio & Thomas (alphabetically listed)
Organization: Massachvsetts Institvte of Technology
X-Newsreader: Tin 1.1 PL4
Date: Fri, 25 Dec 1992 09:30:08 GMT

Hi!

	I just want to tell the whole net that me (and I would think a lot
of other people) are *extremely* glad/happy/lucky to have all of you who
put so much of your valuable time into writing/porting software for us who
are not programming whizzes to use.  I know differences between people are
a fact of life, but every bit of free software helps someone and to lose
anyone from the contributing side of the equation bums me out.  Thanks to
everyone who puts their time into making free software and (with no
selfishness intended) I hope that differences of opinions don't take any of
you away from us.

-John
jackson@a1.mec.mass.edu or vikki@athena.mit.edu


Newsgroups: comp.unix.bsd,comp.os.linux,comp.unix.pc-clone.32bit
From: hasty@netcom.com (Amancio Hasty Jr)
Subject: Re: ET4000/W32 and VESA VL-Bus
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Tue, 29 Dec 1992 22:42:41 GMT

In article <1992Dec29.191833.1401@Informatik.TU-Muenchen.DE> roell@informatik.tu-muenchen.de (Thomas Roell) writes:
>
>Then S3 has with the 801 a pretty good DRAM design. I would now post
>some 928 results, if I would be allowed to, but I can tell you that
>the difference to the 801 is QUITE BIG.

Any performance figures for the 928 that you have are welcome :-)

They do a good DRAM design according to S3 they simulate a VRAM in the
8c801/8c805 design. I don't know the specifics of their design and I doubt
that they are going to make it public.



>
>>Can you be kind to post your Utra Pro benchmark results?
>
Thank you

>Will be intresting. Have another benchmark number for people who like
>really hot boards ... This is the Nth Engine/250, a VRAM based board
>with a 82C481 on it... Maybe the 928 will be faster ;-)

My expectation is that is going be faster than 120k xstones :-)


Who is the chip manufacturer for  the 82c481 and do you have the phone number
for the board manufacturer of the "Nth Engine/250"?

This is the current performance for XS3 :-)
486/50Mhz 256K cache 8MB at 1024x768 45Mhz interlace 

TOTAL    130035 lineStones
TOTAL     64423 fillStones
TOTAL     46916 blitStones
TOTAL   3159992 arcStones
TOTAL    149875 textStones
TOTAL    122156 complexStones
TOTAL     89403 xStones

When Jon gets back he will run a series of xbench runs at various refresh rates
and at 1024x768. I can't because I am stuck with a low resolution monitor.

All I want to say is that at $199 the Actix GraphicEngine32 DRAM card is not
a bad card at all. Also, as much as I want to get my hands on a 928 it was
delayed two months and I still have to get hold of one to see how it works.
I have the databook and I am all set to got at it.

Amancio Hasty

-- 
Amancio Hasty           |  
Home: (415) 495-3046    |  ftp-site depository of all my work:
e-mail hasty@netcom.com	|  sunvis.rtpnc.epa.gov:/pub/386bsd/incoming
Newsgroups: comp.unix.bsd
From: migi@furka.enet.dec.com (Miguel Mena)
Subject: [386bsd] looking for logitech bms driver 
Reply-To: migi@furka.enet.dec.com
Organization: Digital Equipment Corporation, Zurich, Switzerland
Date: Thu, 31 Dec 1992 08:30:55 GMT


--

hi there

I'm looking for the logitech busmouse driver for 386bsd. I've read
in an article, that it should be in agate, but I can't find it there.

thanx for your help

miguel

------------------------------------------------------------------------------
  Miguel Mena                     |  Internet: migi@furka.enet.dec.com
  UNIX & X11 Support              |     X.400: C=ch,A=arcom,P=digital,
  Digital Equipment Corporation   |            S=Mena,G=Miguel
  Zurich, Switzerland             |
------------------------------------------------------------------------------