HDTenEightyP/NetNews huggingface dataset:
From: gtoal@pizzabox.demon.co.uk (Graham Toal)
Subject: Re: AT&T/USL CD-ROM Review Process
Organization: Cuddlehogs Anonymous
Distribution: usa
Date: Thu, 24 Dec 1992 02:41:06 GMT

In article <1992Dec23.141020.27004@rwwa.COM> witr@rwwa.com writes:
:What we need is a sanatarium for infected programmers.  They also need to be
:re-trained, say to become telephone disinfectors or IRS inspectors.  Perhaps 
:this will be part of Billy's new health and economics plans?

Actually I was thinking the other day it might be time to start a
retirement home for aged hackers, complete with internet access for
the time when we're beyond getting out of bed.  There aren't a lot of
pleasures left in life when you're 90 and can't change your own underpants,
and I doubt that geriatric homes run by the local council will be in a
hurry to provide net access for a bunch of old codgers, even in the next
century.

How depressing.  33 years old and worrying about retirement homes :-(

G
Newsgroups: comp.unix.bsd,alt.suit.att-bsdi,misc.legal.computing,misc.int-property
From: styri@hal.nta.no (Haakon Styri)
Subject: Re: AT&T/USL CD-ROM Review Process
Reply-To: styri@nta.no
Organization: Norwegian Telecom Research
Date: Tue, 22 Dec 92 10:12:17 GMT

In article <1992Dec15.223317.158@nntp.hut.fi>, jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
> In article <1992Dec14.165913.6896@fcom.cc.utah.edu>, terry@cs (A Wizard of Earth C) writes:
> > Second, Linux is arguably more like SVR3 (and by extension SVR4) than
> > 386BSD; this, I believe, puts it in more danger of censure.  The thing
> > that has protected Linux so far is its international (non-US) origin.
> > This is not something USL has to worry about forever, it's simply an
> > inconvenience to prosecution, not a barrier.  If a judgement were given
> > regarding copyright infringement by Linux against USL's materials, it
> > wouldn't matter that the judgement occurred in the US; Linus' government
> > would be forced by the Berne convention to uphold the judgement.
> 
> Is this really so?  I don't think so, but what do I know.  First, I
> think Berne is much more limited than the current trend of the U.S.
> application of copyright laws to just about anything.  Second, as
> Linux's country of origin is Finland I think it would be the Finnish
> laws that would apply, not U.S.

You're right that the Berne convention is more restricted than current US
legislation. Anyway, the Berne convention only gives a set of rules that
should be _interpreted_ using the Finnish legislation. If something cannot
be copyrighted in Finland the Berne convention will not help.

Another point is that things may change due to the GATT agreement.

---
Haakon Styri
Newsgroups: comp.unix.bsd
From: dfox@quack.sac.ca.us (David Fox)
Subject: [386BSD] Floating point exceptions with Cyrix - followup
Keywords: cyrix ndp
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: 25 Dec 1992 17:32:50 UTC

Hi again.

I received some nice help via email to my latest problem with ps not
running with -aux anymore after I put in a Cyrix NDP recently (it 
died with Floating Point exception.)  I found the patch in Terry's
patchkit (patch 36), applied it, and rebuilt ps.  I also rebuilt
libutil.a, as was suggested by Andrew Moore (alm@netcom.com).  He
also suggested I needed to remake some mk_db something or other
(there's a 'database' file that gets built during booting(?) some-
where in the filesystem.  I've seen it before, but don't remember now
the path for it.  I am at a loss to understand how to rebuild this
file, should I need to.

BTW, ps -aux works now.
--
David Fox
dfox@quack.sac.ca.us
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386bsd] Kernel build dies, unref symbol _version
Organization: Weber State University  (Ogden, UT)
Date: Sat, 26 Dec 92 23:51:16 GMT

In article <17701@umd5.umd.edu> mark@roissy.umd.edu (Mark Sienkiewicz) writes:
>In article <BznK64.AGL@NeoSoft.com> karl@NeoSoft.com (Karl Lehenbauer) writes:
>>>"init_main.o: something about an unreferenced symbol _version"
>>>is there a standard fix for this?
>>
>>Yeah, ATFP.  Add The Fine Patchkit.  This problem is fixed by patch #1.
>>
>
>If you look in the ls-lR file from agate.berkeley.edu (which appears
>to be the primary ftp site for 386bsd), you will find a directory
>that looks like this:
>
>	pub/386BSD/386bsd-0.1/patches:
>	total 0
>
>Hmmmm... doesn't look promising...  BUT if you look long enough, you may
>also find
>
>	pub/386BSD/386bsd-0.1/unofficial/terry/beta.patch.kit:
>	total 372
>	-rw-r--r--  1 cgd          2172 Oct  5 11:33 README.1ST.Beta-1
>	-rw-r--r--  1 cgd          8569 Oct  5 11:33 README.Beta-1
>	-rw-r--r--  1 cgd        358400 Oct  5 11:33 patchkit-0.1.tar.Beta-1
>
>Which _appears_ to be the patchkit that everybody is talking about.  Can
>anyone confirm or deny that "unofficial/terry/beta.patch.kit" is the
>"official" patch kit?

This is the one -- although, it's not "official" (ie: sanctioned and
supported by Bill and Lynne Jolitz).

This is the one everyone is talking about, unless you have been following
the discussion about the next patchkit release; the next one isn't available
yet.


					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: dawes@physics.su.OZ.AU (David Dawes)
Subject: Re: 386BSD HELP!inst XFfree86 on Diamond SpeedStart 24
Organization: School of Physics, University of Sydney, Australia
Date: Sun, 27 Dec 1992 23:59:00 GMT

In article <1992Dec23.125537.1@cua.edu> 48ganelin@cua.edu writes:
>
>     I have the problem with installation XFree86 in 386BSD.
>I have Diamond SpeedStar 24. (in specification list  DSS + SIERRA
>HIcolor, label in the chip -- Diamond SpeedStar 24, BTW is it the
>same) 
>    There is a note in README  file that this board does  support
>XFree86. Does it mean I can't run XFree in any case, even at
>least black and white or some kind of generic VGA.

The mono server will work in "generic" mode.

>#Try2.
>#load to MS DOS 
># clock.exe ET4000
>#   21 25 61 65 21 25 61 65
           ^^ ^^

Because the SS24 uses a programmable clock synth, these values will not always
be the same.  They will be set to whatever the last DOS graphics program
set them too (but they get reset on a cold boot).  Some people use
the SS24 with XFree86 by first booting DOS and running a graphics program
to set the clock, then booting Unix.

>#
>xclk -h 61 800
># get some number put them to the Config file
>xdm -nodaemon
># the same result as above. Blinking for about one minutes and 
># then the same screen. I decided to play with the modeDB numbers
># but never get permanent picture

To find out why the server is failing, take a look at xdm's error file
/usr/X386/lib/X11/xdm/xdm-errors.  In this case it's probably
because of mode/clock mismatches.  You should initially leave out the
Clocks line in Xconfig, and look at the error log to see what clocks
the server detects.

David
--
------------------------------------------------------------------------------
 David Dawes (dawes@physics.su.oz.au)    DoD#210      | Phone: +61 2 692 2639
 School of Physics, University of Sydney, Australia   | Fax:   +61 2 660 2903
------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd,comp.os.linux,comp.unix.pc-clone.32bit
From: curt@hoptoad.uucp (Curt Mayer)
Newsgroups: comp.unix.bsd
Subject: Re: Shitty NE2000 NFS performance problem fixed right (source code)
Date: 22 Dec 92 00:46:40 GMT
Organization: foobie bletch

In article <BzM1HL.9JC@ibmpcug.co.uk> adrian@rachel.ibmpcug.co.uk (Adrian Hall) writes:
>Since I use the NE-2000 in rachel, I was rather gratified to see someone
>addressing the problems in the NFS performance (and no doubt other areas)
>of the driver.
>
>	However, the file /sys/i386/isa/ic/ds3890.h seems to be lacking
>the vital support for the identifier DSCM_SENDP. Now I have no idea what
>value to give to this identifier.
>
>	Perhaps the author of this worthy driver could post or e-mail a
>copy of his ds3890.h file, or wherever he defines this identifier to the
>net, or simply tell us what it is meant to be.
>
>	Adrian


oops. please add the following lime to /sys/i386/isa/ic/ds8390.h:

#define  DSCM_SENDP      0x18           /*      Send Packet             */

sorry.
	curt

p.s. there is another, even better, version soon to come out.

-- 
	curt mayer
        curt@toad.com
        415-387-0217 home
From: mike@starburst.umd.edu (Michael F. Santangelo)
Newsgroups: comp.unix.bsd
Subject: Re: S3 question - Amancio, are you there?
Date: 28 Dec 1992 03:13:46 GMT
Organization: University of Maryland, Chesapeake Biological Laboratory
NNTP-Posting-Host: starburst.umd.edu

hasty@netcom.com (Amancio Hasty Jr) writes:

...stuff deleted...

>The January issue of Byte magazine voted the Actix's GraphicEngine32 (801)
>as one of the best overall graphic accelarated cards for window applications.
>At least on Byte's tests the 801 was faster than the ATI Ultra Pro (mach 32).
>And, I really doubt that the tests were executed at low clock frequencies.
>However, the article did not state the dot clock frequency which the tests 
>were executed at.  The other faster cards were based on the 34020 and cost
>more than $1400.

The BYTE article says on p. 206 that they used 1024x768 resolution, 72Hz at
256 colors with all the cards in that test that could support it.

--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael F. Santangelo                 + Internet: mike@cbl.umd.edu      [work]
Computer & Network Systems Head       +           mike@kavishar.umd.edu [home]
Univ MD: CEES / CBL (Solomons Island) + BITNET:   MIKE@UMUC  [fwd to mike@cbl]
Xref: sparky comp.unix.bsd:10518 comp.os.linux:21305
From: carlton@scws8.harvard.edu (david carlton)
Newsgroups: comp.unix.bsd,comp.os.linux
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 21 Dec 92 21:30:13 GMT
 <1992Dec18.235809.15484@midway.uchicago.edu> <agp22+#@rpi.edu> <1gvpt0INN8s0@hrd769.brooks.af.mil>
Organization: Citizens for Boysenberry Jam
In-reply-to: news@hrd769.brooks.af.mil's message of 19 Dec 1992 12:33:04 -0600

In article <1gvpt0INN8s0@hrd769.brooks.af.mil>, news@hrd769.brooks.af.mil (InterNet News) writes:

> So, I have a suggestion.  Change someone.  If you think
> internationalization is a snap, try it.  Get convinced that it is
> hard to retrofit, but relatively simple to design for and proceed
> from there.

I don't believe you.  I could believe that doing it badly (well enough
to handle most European languages, say) is easy, but I think doing it
well takes a lot of work.  You have to deal with different character
sets, ways of text entry, direction of text, mixing scripts,
connection rules, and so forth; some of these are not difficult
problems, perhaps, but a lot of them are.  For example, if you want to
type something in the Nagari script, hardly an uncommon script, you
will either have to have an overly complicated and artificial method
of entering text (bad - this puts unnecessary burden on the user),
read ahead in the input stream before figuring out what to put on the
screen (crummy for interactive input), or deal with the fact that what
you have put on the screen is going to change even when the user keeps
on typing without deleting (bad, because it makes the characters on
the screen jump around a lot.)  Doing any sort of decent solution will
take a lot of extra coding, require a lot of research to figure out
what the problems are and what sort of solution people prefer, require
care not to lead to bloated programs (if you care), and is not what I
would call "relatively simple".

Perhaps I'm missing something, though - would you care to share with
us your methods for designing for internationalization?

david carlton
carlton@husc.harvard.edu

        Learning Sanskrit would be more amusing.
                          - Johnny Inkslinger, in _Paul Bunyan_
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: XFree86 problem in XDrawSegments
Organization: Weber State University  (Ogden, UT)
Date: Wed, 30 Dec 92 06:36:02 GMT

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
-------------------------------------------------------------------------------
From: reink@hpuamsa.neth.hp.com (Reinier Kleipool)
Date: Thu, 24 Dec 1992 14:51:02 GMT
Subject: Re: BSD for Apollo DN3000
Organization: HP-Sales Office-The Netherlands
Newsgroups: comp.unix.bsd

Hello,

   a couple of messages ago :

Subject: Re: BSD on HP3500s?
Organization: Kernel Hackers 'r' Us

In article <21250002@hpuamsa.neth.hp.com> reink@hpuamsa.neth.hp.com (Reinier Kleipool) writes:
>  I suppose you mean with HP3500 an Apollo domain 3500 workstation.
>I dont't think this will be a trivial task, as the 3500 works with an
>68030. So you should do a complete port of the os to that processor.
>I don't know if anybody is doing that. Porting the os starts with a
>port of a C compiler to the 'new' archtecture. Mabe you can use the
>existing Domain C compiler to port the gnu C compiler. But this is
>only the start of an os port.....

Actually, i was working on a port of 4.4 to the DN3500/DN4500,
but for lack of time, never got too far...

I actually found that it wasn't too hard to set up a reasonable development
environment under Domain/OS (10.1 at that time, i think...),
w/ the stuff off of the tape which Keith Bostic gave me...
(which doesn't exist any more, but you couldn't have anyway... 8-)

the gnu c compiler, as disted in net/2 (and probably 386bsd) 
has full 680x0 support -- for the hp300.  just modify a few things,
and set it up to give you one or two unique symbols,
and you win.

>  You should also write new device drivers for ithe domain peripheral
>controllers. This is not a simple task. Unless you intend to become 
>the Willaim Jolitz of the 68000 community!

arguable... 8-)  the ethernet board in the DN[34]500 machines are
the 3COM 3c501 or 3c503, i think, so that shouldn't be too hard;
just occasional byte swapping on 16 bit I/O.

the disk controllers are standard PC controllers...  one type is OMTI i
think, and the other type is the WD7000...

the video boards are a helluvalot nicer than PC video boards; they're
actually flat framebuffers!!! (of course, they've no character mode,
so that's a bit of a problem...  also the color displays are planar not
chunky...)

you could support token ring, but that may or may not be worthwhile
depending on the hardware you have at your disposal...

the way i started off was trying to merge the locore, etc. of the hp300 port
with the devices of the early work on the i386...

There's also been a Mach port to the DN3000, which was somewhat useful,
for info about booting, etc.

i'd be glad to answer questions... 8-)

chris
--
Chris G. Demetriou                                    cgd@cs.berkeley.edu

"Sometimes it is better to have twenty million instructions by
        Friday than twenty million instructions per second." -- Wes Clark
Newsgroups: comp.unix.bsd
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: [386bsd] xfig
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Fri, 25 Dec 1992 08:00:17 GMT
Keywords: xfig slowness

In article <1992Dec22.221238.29730@ennews.eas.asu.edu> berry@enuxha.eas.asu.edu (Joel R. Berry) writes:
>Is the 386bsd system
>that much slower at running applications?  

No, it should not be.  We had a problem not too long ago where one of our
motherboards was not going into turbo.  You might obtain the dhrystone
benchmarks or equivalent and run them on your various machines.  The
results should be fairly close between the different OSes.

Another thing is memory.  If you don't have enough, your system will crawl.
12 meg minimum for X IMHO.
-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
"In a minute, I'll burp up your droid."
Newsgroups: comp.unix.bsd
From: juenger@gmd.de (Georg Juenger)
Subject: Prob with recompiling kernel (undef. symbols)
Organization: GMD, Sankt Augustin, Germany
Date: Mon, 21 Dec 1992 10:09:11 GMT

At first, I'd like to thank everyone having contributed to 386bsd.

My problem however:

I installed 386bsd 0.1 successfully on my machine (486SX, 200 Mb IDE, 8 Mb Ram)
unpacked the binaries (bin01) and sources (src01) and added Terry's patchkit
except patches 26, 47 and 55.
After that I wanted to recompile the kernel with the lp-driver (Sashegyui/En-
gel/Lambert) and used the "idiots" guide. 
"make newvers" and "make depend" of step (5) went ok, but the "make" was inter-
rupted and followed by this message (abbreviated):
cc - ( flaggs omitted) vers.c
loading 386bsd
machdep.o: undefined symbol (us) _upxinit referenced from text segment (rfts)
trap.o: <us> _npxdua <rfts>   
vm_machdep.o: <us> _upxproc <rfts>
wd.o: <us> _wddrives <rfts> blabla (further _wdntab, _wdxfer, _rwdbuf could not
be resolved)
Error Code 1 / Stop

What is wrong with that? Any help would be great. Thanks in advance.
 ----------
Georg Juenger, I8
  German National Research Center for Computer Science (GMD)
  P.O. Box 13 16, D-W-5205 Sankt Augustin 1, Germany
  email: georg.juenger@gmd.de, phone: (++49 2241) 14-3143
From: DS1437@acspr1.acs.brockport.edu
Newsgroups: comp.unix.bsd
Subject: RE: Font Problems with Xfree86
Date: 30 Dec 1992 16:01:37 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

R>From: rich@Rice.edu (& Murphey)
R>Subject: Re: Xfree86 Font directory problem?
R>>>>>> In article <9212300215.AA00524@deepthought.cs.utexas.edu>, DS1437@acspr1.acs.brockport.edu writes:
R>D> NNTP-Posting-Host: cs.utexas.edu
R>
R>D>     I am having problems getting Xfree86 running, it seems to initiaize
R>D> the screen fine , but then switches back to text, and hangs the console
R>D> port (still can telnet in). I found out that there is an error that
R>D> the server is reporting but never showing, I can only get this error on
R>D> a system that is telneted in, it is:
R>
R>D> failed to set default font path '/usr/X386/lib/X11/fonts/misc/,/usr/X386
R>D> /lib/X11/fonts/75dpi/'
R>D> Fatal server error:
R>D> could not open default font 'fixed'
R>
R>The XFree86 1.1 server checks the font path  more thoroughly if you
R>set it in your Xconfig than if you use the default.  Try setting it:
R>
R>FontPath "/usr/X386/lib/X11/fonts/misc/,/usr/X386/lib/X11/fonts/75dpi/"
R>
R>and see if that helps.  We are working on improving this for the next
R>release.  Rich

    I think thats where the server was getting the name for the font
directories. Sorry I was going to include my Xconfig file in the message
too, but I forgot. Here it is --

#########################################################################
RGBPath                "/usr/X386/lib/X11/rgb"
FontPath         "/usr/X386/lib/X11/fonts/misc/,/usr/X386/lib/X11/fonts/75dpi/"
Keyboard
  AutoRepeat 500 5
  Xleds      1 2 3
  ServerNumLock
  DontZap
microsoft        "/dev/com1"
 BaudRate        9600
  SampleRate     150
  Emulate3Buttons
vga256
  Virtual        640 480
  ViewPort      0 0
  Modes          "640x480"

ModeDB
###############################################################################
# Monitor:              Gateway 2000 Crystal Scan NI (Mag Computronics 1448)
# Contributor:          Thomas Naughton [naughton@chinet.chi.il.us]
# Last Edit Date:       10/17/91
#
# name        clock   horizontal timing     vertical timing      flags
 "640x480"     25      640  672  768  800    480  490  492  525
 "800x600"     50      800  864  970 1056    600  608  615  633
 "1152x900i"   68     1152 1172 1288 1368    900  909  933  937  Interlace
# Refresh rate = 57.44Hz ; Horizontal Frequency = 47.79KHz

****************************************************************************
Name: Donald L. Schleede                      Snail-Mail:
Call: KB2LZF (kb2lzf@wb2wxq.ny.na.usa)          Dept. Earth Sciences
E-mail Addresses:                               SUNY Brockport
 ds1437@acspr1.acs.brockport.edu                Brockport, NY 14420
 dschleede@unidata.ucar.edu                   Twisted Pair:
 root@kb2lzf.UUCP                               (716) 395-5718
Planet: Earth
****************************************************************************

Newsgroups: comp.unix.bsd
From: vdlinden@fwi.uva.nl (Frank van der Linden)
Subject: Re: gcc 2.x and kernel building
Organization: FWI, University of Amsterdam
Date: Fri, 1 Jan 1993 20:27:48 GMT


 It turns out I missed an error in math_emulate.c which causes gcc 2.3.3
to abort the kernel compilation.
Patch below assumes that the patchkit is installed.

Onno van der Linden          c/o           vdlinden@fwi.uva.nl

*** /usr/src/sys.386bsd/i386/i386/math_emulate.c.orig	Sun Nov 22 14:00:34 1992
--- /usr/src/sys.386bsd/i386/i386/math_emulate.c	Thu Dec 31 19:35:55 1992
***************
*** 620,624 ****
  		return (char *) offset;
  	}
! 	tmp = & (long)REG(rm);
  	switch (mod) {
  		case 0: offset = 0; break;
--- 620,624 ----
  		return (char *) offset;
  	}
! 	tmp = (long *) &REG(rm);
  	switch (mod) {
  		case 0: offset = 0; break;
-- 
  Frank van der Linden.                        Internet : vdlinden@fwi.uva.nl
* WARNING ---- The author of this message has once seen some AT&T Unix source *
* code, so now this message is probably copyrighted by them! You have been    *
* reading this entirely at your own risk..                                    *
Newsgroups: comp.unix.bsd