HDTenEightyP/NetNews huggingface dataset:
From: awb@ed.ac.uk (Alan W Black)
Newsgroups: comp.unix.bsd
Subject: CDROM for 386bsd (Re: ftp software inc, their address is...)
Date: 12 Nov 92 10:19:26 GMT
Organization: Dept of AI, Edinburgh University, UK

In article <2X13TB1w165w@student.business.uwo.ca> mark@student.business.uwo.ca (Mark Bramwell CS STAFF) writes:
> For those of you who wanted to know where I got the CD-rom with
> 386bsd on it,
> here is the address of the company....
>
> ftp software, inc.
> 2 High street, North Andover, MA
> 01845-2620
>
> Main phone:  508-685-4000
> fax: 508-794-4488
> sales: 508-685-3300

> the cd-rom was handed out at the NetWorld Conference in Dallas, Texas.

I believe that this cd-rom is actually the one sold by Infomagic.  It
contains the 386bsd (0.1) distribution (packed srcs and bin) as well
as most of the GNU stuff, X11R5 (to fix8), BSD Net2, the RFCs, a fair
amount of MSDOS freeware and some mac stuff (it's dated August 92---it
has GNU stuff from early Auguest). Infomagic's address is

   Infomagic
   PO Box 338
   Pennington
   New Jersey  08534-0338
   USA
   tel: 609-683-5501

It costs 75$ plus shipping (10$ overseas)---is it cheaper from FTP ?.
I phoned in an order to Infomagic and received it 4 days later (which
isn't bad considering how far I am away from New Jersey).

Although this CD does mean I don't need to keep so many floppy disks
around I'd still like to see a cdrom with 386bsd *unpacked* on it, so
I don't need to keep the srcs on-line (or as I do now unpack on
demand).

My ideal CD would contain unpacked versions (and maybe packed as well)
of
    386bsd  (both binaries and sources)
    GNU stuff
    TeX
    X11R5 and maybe some contrib stuff 
    XFree86 bins (and patched X11R5 server ??)

Of course with Linux binaries and sources on the CD the potential
customers would increase.

The main problem I see with such a CDROM is that because of the
ISO9660 format, filename length (and format) is restricted.  Short
names are not really acceptable as a change in name would invalidate
most of the srcs (changing Makefiles isn't practical etc).  You can
ignore the filename limits (as Sun does on their demo cdrom) and still
have things working but it wouldn't then work under DOS, which isn't
much of a problem as long as the boot images were accessible under
MSDOS.

Also because the 386bsd sources are set up to put compiled files
in obj/ which is a symbolic link, a read only file system with the
sources on is quite practical.  However as ISO9660 doesn't support
symbolic links some extension would need to be used.

I suppose the whole question comes down to whether there are enough
people out there that would be willing to buy a CDROM set up for
(almost exclusive) use on 386bsd (and Linux).  I suppose
eventually this will be the case but I'll just have to wait for
the time being.

Alan

Alan W Black                          2 Buccleuch Place, Edinburgh, UK
Centre for Cognitive Science          tel: (+44) -31 650 4627
University of Edinburgh               email: awb@ed.ac.uk
From: meikel@marie.physik.tu-berlin.de (Michael Feig)
Newsgroups: comp.unix.bsd
Subject: keycap problems
Date: 9 Nov 1992 22:06:09 GMT
Organization: ZRZ/TU-Berlin
NNTP-Posting-Host: marie.physik.tu-berlin.de
Keywords: keycap

I installed the recent version of keycap onto our BSD machine by 
patching the kernel according to the given diff-Files and supplemental
source files. Everything works fine as long as I don't start X-Windows 
(XFree 1.2) using the compiled X386 which is part of the keycap-0.1.1
distribution. Within X-Windows the mouse works only in horizontal 
direction and the mapping of the keyboard is totally out of order 
(pressing the 'a', 's', 'd' keys causes numbers to appear, shift right
produces some special character like '=' or '+' - I forgot what it
actually was). Some time later (~30 seconds) the whole BSD-machine
hangs and has to be rebooted.

Just to make things clear: X-Windows worked absolutely all right without any 
problems  before installing keycap.

As a try to solve the problem, I used the supplied kernel instead of the
one  I have build  from the sources after applying all necessary patches,
but I discovered that doesn't contain the patch for reserved ports with
NFS which is essential for us, because we have to mount part of the
BSD system from a Sun via NFS.

Has anyone experienced similar problems or has anyone an idea how
I can get things going the way they are supposed to work ?

Thanks for your help, Michael.

--
 Michael Feig                 INTERNET: meikel@marie.physik.tu-berlin.de
 Department of Physics                  meikel@cs.tu-berlin.de
 Technical University of Berlin
From: spedpr@thor.cf.ac.uk (Paul Richards)
Newsgroups: comp.unix.bsd
Subject: Re: swapspace and anonymous ftp
Date: 6 Nov 92 11:53:16 GMT
Organization: University of Wales College at Cardiff
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway

In article <1992Nov5.170125.17260@di.unipi.it> mau@ipifidpt.difi.unipi.it (Maurizio Davini) writes:
|Hi all,
|I would like to know how to set up an anonymous ftp on my 486box running
|386bsd and how to add aditional swap spaces....
|( I have received a "virtual memory exausted" compiling xvgr
|even if I set limit memoryuse unlimited )
|
|                                     Thank you very much
|                                          Maurizio

I tried to mail but I got a domain unknown error.

I've compiled xvgr on ref.tfs.com. The binary will be in my home
directory, /usr/home/paul. I hope you've got a lot of memory because
it's big and with 8Mb my system is strained when running this.

Did you get the rand48 routines from somwhere. I found a copy using
archie but I'm not sure whether it's in the public domain. If it is I'd
like to add it to the mathlib. Incidentally, which math library did you
use, the bsd one is missing too many routines, I used the gnu mathlib.

This is another example of duplicated work. This is why I think a
projects list would be useful.



-- 
  Paul Richards at Cardiff university, UK.

  spedpr@uk.ac.cf.thor	Internet: spedpr@thor.cf.ac.uk
  UUCP:     spedpr@cf-thor.UUCP or ...!uunet!mcsun!uknet!cf!thor!spedpr
+++
Newsgroups: comp.unix.bsd
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: CDROM for 386bsd (Re: ftp software inc, their address is...)
Organization: Naval Research Laboratory
Date: Fri, 13 Nov 1992 19:31:47 GMT

In article <1992Nov13.073252.9757@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>The most important is to optimise the utilisation of the CDROM. Being a 
>read only memory system, the McIntosh FS is better in being an extent based,
>but it is too far away form 386bsd.
>	Maybe a slightly modified bsd FFS, can be used, with a few options:
>
>i) large block sizes, e.g. 32kbyte so that we can put 320k without any
>indirect inode pointers. Larger than this will cause too much fragmentation,
>because a fragment size of 1k will not be able to fill in the gaps.
>	This method is attractive because there is no modification to 386bsd
>FFS,
>
>ii) Change it slightly to use extent based FS. I've no idea how difficult it
>will be.

	I can think of *no* good reason to avoid using ISO9660.  There are no
performance drawbacks, and if you use the Rock Ridge extensions you can even
have normal unix filenames, modes, uid/gid, block and character devices and
deep directories, all within the ISO9660 standard.  The linux filesystem
already supports the Rock Ridge extensions (I don't know about 386bsd).  All of
the files on ISO9660 are already contiguous so you do not have to worry about
indirect inode pointers and other such things.

-Eric
-- 
Eric Youngdale
Newsgroups: comp.unix.bsd
From: nbladt@autelca.ascom.ch (Norbert Bladt)
Subject: Re: [386BSD] xv cannot display gif/jpeg correctly
Organization: Ascom Autelca AG, Guemligen, Switzerland
Date: Mon, 9 Nov 1992 07:25:01 GMT

pederiva@cobolt.enet.dec.com (Pascal Pederiva) writes:


> Hi,

> I am using the binary XFree86 from agate and various versions of xv ( bin &
> src ). As I haven't got a SuperVGA card yet, I am stuck with B/W 800x600.
This is the virtual 800x600 mode, right. Physical 640x480 resolution.
If you are referring to a different mode, ignore the rest of the reply.

> However, when I start 'xv' , it's title picture looks a little strange :
Yup.

> Longwords byte ordering is the wrong way round as well as the bit ordering
> within the single bytes. That way you get vertical stripes divided into
> four smaller stripes.
The xv dialog boxes, etc. were OK for me.
> Loaded pictures look just the same way.
Yup.

> Has anybody observed the same problem already ? Ist it me who's doing
> something wrong ?
Yes. I did observe the same problem. The Mono Xserver works fine, except for
"xv" (and maybe a lot of other clients which I didn't compile and test).
The problem went away immediately, as soon as I changed to the colour Xserver
(X386), though. Now, two sources (at least) of this problem come to mind:
	1. xv is not suited for monochrome servers (which I doubt, because
	   I have it running on a monchrome SUN - the same code that is)
	2. the Xmono server has problems with certain types of clients which
	   is more likely. Although I could run the "xdl" tool just fine
	   with the mono server.

[text about working X clients, etc. deleted - NB.]

So, it's not (just) you that did something wrong (except if you changed the code
for xv - I am using version 2.21). It is more likely that the are problems in
the mono Xserver.

You should buy a 100 US$ SuperVGA board :-)

Norbert.
-- 
Norbert Bladt, Ascom Autelca AG, Worbstr. 201, CH-3073 Guemligen, Switzerland
Phone: +41 31 999 65 52			FAX: +41 31 999 65 44
Mail: nbladt@autelca.ascom.ch   UUCP: ..!uunet!mcsun!chsun!hslrswi!aut!nbladt
Newsgroups: comp.unix.bsd
From: gary@sci34hub.sci.com (Gary Heston)
Subject: Re: Gargantuan problems with oddball SCSI adapter
Reply-To: gary@sci34hub.sci.com (Gary Heston)
Organization: SCI Systems, Inc., Huntsville, Al.
Date: Fri, 6 Nov 1992 16:29:50 GMT

In article <1992Nov1.085738.8127@ariel.ec.usf.edu> stephens@ultrix.csc.usf.edu. (Daniel Stephens (CSC)) writes:
  [ ... ]
>	The problem is simple, BSD refuses to acknowledge my SCSI
>adapter.  Bloody well skips over it without a second thought. [ ... ]

You fail to mention what manufacturer and model your card is, and
whether or not you checked for it in the list of supported hardware.

If it's not in the supported hardware list, you aren't going to get
386bsd up anytime soon....

-- 
Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
The Chairman of the Board and the CFO speak for SCI. I'm neither.
"...I looked out my window, and saw Kyle Pettys' car upside down, then I
thought 'One of us is in real trouble'." Davey Allison, re: a 150MPH crash 
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386BSD] Unable to exec #!/bin/sh scripts
Organization: University of Utah Computer Center
Distribution: comp
Date: Wed, 11 Nov 92 02:34:20 GMT

In article <INKARI.92Nov10021140@lk-hp-12.hut.fi>, inkari@snakemail.hut.fi (Juha Inkari) writes:
|> 
|> Shell scripts are not executed right on my 386BSD systems.  Exec()
|> results in cannot execute error and if I try to execute a script from
|> C-Shell, the shell tryes to interpret the commands resulting in syntax
|> errors etc. Whats the matter and how to fix it ?

1)	Install the patch in the patchkit that fixes this, and rebuild the
	kernel (it modifies kern_exec.c).
2)	Use ":" instead of "#!/bin/sh" as the first line.  This works in the
	default exec() call.


					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: jkh@esel.lotus.com (Jordan K Hubbard)
Subject: Re: GNUCC 2.3.1 Available  [AND WHAT YOU NEED TO DO TO MAKE IT WORK]
Organization: Lotus Ireland
Date: Thu, 5 Nov 1992 09:04:46 GMT

	Anyone try it yet?  I think I'll give it a try...

Yes.

You'll need to do the following things, though:

1. Deal with enough ansi'isms to gag a buzzard.  This means changing
   the various includes of <ansi.h> to <machine/ansi.h> (or link ansi.h
   in you /usr/include, whatever your preferences).  You'll also need
   to #undef _ANSI_H in <stdio.h> or you won't pick up the size_t and
   wchar_t types, for some reason.  This one is strange and I'm looking
   into it - someone is defining _ANSI_H.

   It also means hacking things to make sure that ptrdiff_t gets defined
   and va_list gets declared as the GCC internal type properly - I'm being
   deliberately vague on all this because I don't much like the way I've
   gotten this to happen at the moment (hack hack) and I'm looking at some way
   of neatening it up to where it follows some ANSI standard or other,
   just as soon as I figure out what that is.  There are enough existing
   examples o go on that any reasonably competent person should be able to
   figure out what to do.

2. More seriously, you need to make sure that the assembler comment character
   is '#', not '/', and that APP_ON and NO_APP [sic] are set to "#APP" and
   "#NO_APP", respectively.  These are NOT defined correctly in i386unx.h
   so you'll need to redefine them in i386bsd.h.  Symptoms of your not having
   done this will be "Garbage character .. blah" messages from the assembler
   while you're compiling stuff from libgcc2.c.

   You'll also need to turn YES_UNDERSCORES on since the gas assembler
   prepends underscores.  Symptoms of not doing that will be gazillions of
   undefined symbols when you try to link your first stage1 cpp.


3. For some reason, the new enquire.c doesn't compile with the gcc 2.x
   anymore and you'll need to compile it with the old compiler (1.39) if
   you want to be able to get further.  There's some floating point expression
   in there that's 'out of range' and I have yet to find out why - the tagged
   expression looks reasonable enough (and I've tried different values for
   DBL_MIN and DBL_MAX but they're not the culprits this time).  I don't know
   a whole lot about floating point, I'm afraid, so I'm not really the one
   to fix this properly.  I think floating point handling under 386BSD is
   sort of generally buggered anyway, so I'm not sure putting much effort
   into just the compiler is going to net you much.

After doing all this, you should have a bootstrappable gcc 2.3.1.  I'm
going to try compiling all of XFree86 1.1 with it tonite - I'll report
back on how it works (or doesn't).

					Jordan
			PCS Computer Systeme GmbH, Munich, West Germany
	UUCP:		pyramid!pcsbst!gj gj@meepmeep.pcs.com
	EUNET:		unido!pcsbst!gj
Newsgroups: comp.unix.bsd,comp.unix.solaris
From: kzin@terminus.gatech.edu (John Rudd)
Subject: Any truth to BSDI doing a port to Sparc?
Summary: Will BSDI do a BSD/Sparc?
Keywords: BSDI, BSD, Sparc
Organization: Georgia Tech College of Computing
Date: Thu, 12 Nov 1992 02:42:20 GMT


I was just curious if there was any truth to the claim that
I've heard about BSDI doing a port of BSD to the Sparc line,
so that BSD lovers can avoid Solaris 2?  If so, when?

It also occured to me today that some company might make a lot
of money by picking up the rights to SunOS 4/Solaris 1.  They
could continue to support it, and evolve it.  And if they added
some sort of binary compatability to Solaris 2 applications,
they could probably keep a very good customer base.  From what I
hear, a lot of people inside SunSoft think it was a mistake to
switch to SVR4..and it seems that a lot of the customers feel
the same way.

I know that if I had access to a continued SunOS 4 product, and
knew that one way or another, applications vendors would still 
support it (either by the OS supporting Solaris applications, or
by the vendors supporting this continued product), I'd prolly buy
it.  Same goes for a pure BSD4.3 or 4.4 product.  (though, honestly,
I do prefer SunOS...it felt like a good mix to me..mostly BSD with
some useful extensions)

I think BSDI might find a good market in doing a version of BSD
that supports the features of SunOS 4, with the ability to support
Solaris 2 applications (sort of like the way BSD/386 is planned to
support SCO applications).  Such a product for the new Sparc products
(that Sun will not ship with Solaris 1) could probably go a long way.
John Rudd  --  kzin@cc.gatech.edu         ex- kzin@ucscb.ucsc.edu
All opinions expressed here are my own, and no one elses.
--If Happy Fun Ball begins to smoke, leave the area immediately,
  seek shelter, and cover your head.  Do NOT Taunt Happy Fun Ball.
Newsgroups: comp.unix.bsd
From: ecoleman@qualcom.qualcomm.com (Eamonn Coleman)
Subject: xterm hangs!
Organization: Qualcomm, Inc., San Diego, CA
Date: Wed, 28 Oct 1992 06:38:00 GMT

I'm starting to feel bad asking all the questions and giving none 
of the answers but I have yet another problem that'd I'd like 
assistance with. When I fire up XFree86 I get a couple of minutes
use after which the keyboard either hangs completely or at best 
behaves erratically. By erratically I mean that it freezes for a 
few seconds and then responds or it will only respond to the enter
key etc. etc. There is only a problem with keyboard input - all 
output to the xterm is fine and I can cut and paste with the mouse.
The window manager stays alive through all this. The problem is 
unlikey to be hardware related since the problem only occurs when
I run X. I have used twm and olwm with the same results. I have 
used the binary distribution of XFree86 and also recompiled it 
from scratch. Same results! 

If anyone can shine some light on this situation for me I'd 
appreciate it: this is all that's stopping me from having a 
working system :(

Thanks, Eamonn.
-- 
Eamonn Coleman                            Qualcomm Incorporated
eamonn@qualcomm.com                       10555 Sorrento Valley Road
Tel. (619) 597-5280                       San Diego, CA 92121-1617   
Newsgroups: comp.unix.bsd
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: bonnie i/o test results
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Sun, 8 Nov 1992 15:26:11 GMT

Chris G. Demetriou (cgd@eden.CS.Berkeley.EDU) wrote:
: 
: LOOK, I'M SURE I'M NOT THE ONLY ONE WHO'S SICK OF SEEING BENCHMARKS WITH
: ABSOLUTELY NO TECHNICAL MERIT.

No benchmark is perfect but at least we have figures. I'm fed up of people 
who only say but do not produce any figure. Those who say the most does not
mean that they are right.
: 
: PLEASE, before posting any more benchmarks:
: 	(1) learn about disk architecture.
: 		If you knew anything about it, you'd know
: 		that seek time is *disk* dependent, not
: 		controller dependent.
I recommend you read more about controller architecture. John Bass article
is a starter.
: 
: 	(2) run the benchmarks on "equivalent" hardware.
: 		for instance, Maxtor 200M IDE vs. Maxtor 200M SCSI
: 		(i'd to the SCSI benchmark for you, but the only
: 		Maxtor 200M SCSI I have kicked off a few months ago...)
: 
Only if you are into stupid wasteful theoretical study. If you want to maximse,
you worth, just test on what is available, for your particular application.

I did not state any conclusion for various reasons. It takes too long.
bonnie is better in giving you the microprocessor load. It helps to have
fast microporcessors, as in the case of Julian.

The only easy conclusion is that Julian i/o system is not as good as our
i/o 486/33 system, although it is an EISA SCSI system.
	I'm not sure about the reasons but I suspect it is due to the
fragmentation. 

486/33 Maxtor 200M IDE
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
           16   363 66.8   353  6.2   221 10.3   440 90.0   486  9.3  28.1  5.2

This 1Mbyte test is actually testing the efficiency of your buffer cache. I'm
not sure how large the buffer cache is in 386bsd.
	Linux integrated buffer/user space cache design is a big win here
but nobody has come up with any figure.
	Some e-mail me in saying that he can get 5Mbyte/second. It is faster
than any workstation that I've tested. However I do not trust it so much
until he posts the complete test details.

              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
            1   504 94.6   332  6.5   182  7.8   346 67.6   441  9.5 107.8 17.4



--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Newsgroups: comp.unix.bsd
From: junki@lut.fi (Juha Nurmela)
Subject: Re: [386BSD] XFree memory requirements, swap space
Date: Sat, 14 Nov 1992 01:47:27 GMT
Distribution: comp
Organization: Lappeenranta University of Technology, Finland
Followup-To: comp.unix.bsd

Hi !

Is there any magical reason why one should use
just the wd?>b< partition for swap ?
I initially made the wd0b to be 17 MB, and then wanted to
have some more... wd0g was 32 MB, saying "swap on wd0g" in config
worked (for my astonishment swdevt was right !) and I seem to
have more swap to fill with xv :).
So, is there a problem lurking somewhere ?



-- 
         juha nurmela, Adr. 54430 Hujakkala, Finland. Tel. 953 78022
                  eiku: skinnarilank. 28d10, Tel. 953 26292
From: ujlh@pool.info.sunyit.edu (James Henrickson)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] Problems with a SMC Elite16 (WD8013EPC)
Date: 5 Nov 92 21:34:33 GMT
Organization: State University of New York -- Institute of Technology

In article <Bx5Moy.K92@unx.sas.com> sastdr@torpid.unx.sas.com (Thomas David Rivers) writes:
>
>  I'd like to point out that a fixed NE2000 driver is available (I can
> mail interested parties) that corrected my NE2000 performance
> problems.  I've been seeing much better transfer rates on my local
> net with the new driver.
>
>  I didn't write the driver; just a satisfied customer.
>
>        - Dave Rivers -
>        (rivers@ponds.uucp (home))
>	(sastdr@unx.sas.com (work))
>-- 
>UPDATE ALL INFORMATION AND POD INTO COSMOS - Federal Express

Where is it?  I haven't had any problems but I won't turn down
a chance at better performance. :-)
-- 
Jim H.
*
* James L. Henrickson  |  "I don't need a signature, I need a job!"
* ujlh@sunyit.edu      |  BSCS, December 1992
Newsgroups: comp.unix.bsd,alt.folklore.computers
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Wanted: Info on USL/BSDI suit & Net/2 history
Organization: Australian Defence Force Academy, Canberra, Australia
Date: Fri, 6 Nov 1992 04:36:57 GMT

I've been asked to present a seminar locally on the USL/BSDI lawsuit, and I'm
after more information about the current progress of the case, and the
history of the Net/2 tape. If anybody can help with the following, I'd be
very much obliged.

	+ Current state of the lawsuit.

	+ Any blurb/propaganda disseminated by USL/BSDI/BSD Regents.

	+ Release dates of Net/1 and Net/2 (esp. if you have Usenet
	  announcements), and what each tape contains wrt 4.3-Tahoe
	  and 4.3-Reno.

	+ Anything else that you think might be of interest.

I already have

	+ The last 3-4 months of comp.unix.bsd postings :-)

	+ The few files describing the suit from
	  (??) wuarchive:vendors/bsdi	(something like that).

Please email anything to wkt@csadfa.cs.adfa.oz.au. I'll summarise to the
net, and will also make my seminar available when I've written it.

Many thanks in advance!!!

	Warren


Newsgroups: comp.unix.bsd