HDTenEightyP/NetNews huggingface dataset:
From: tracy@bluenote.b23b.ingr.com (Robert Tracy)
Subject: Re: Another Logo
Reply-To: tracyre@infonode.ingr.com
Organization: DAZIX, An Intergraph Company
Date: Sat, 15 Aug 1992 16:10:29 GMT

In article <713818950snx@crynwr.com>, nelson@crynwr.com (Russell Nelson) writes:
|> Here's another Linux logo.  It looks something like this:
|> 
|> |
|> |
|> |    \ /
|> |-----X
|>      / \
|> 
|> %! hand-coded PS

Oh I'm sorry.  I'm afraid that AT&T already holds exclusive rights to
the letters "L" and "X".  I think there are a few Sanskrit characters
which are still in the public domain. :))

Seriously, I like it.  It's simple, and elegant, and I think it's an
ideal symbol for Linux.

-- 
------------------------------------------------------------------------------
Bob Tracy                    |
DAZIX, An Intergraph Company |      "Do not speak for other people.
Huntsville, Alabama          |       Speak for yourself."
tracyre@infonode.ingr.com    |                         H.D. Thoreau
205/730-8588                 |
------------------------------------------------------------------------------
Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: Re: Xenix (tm) emulation for Linux almost works : -)
Organization: University of Victoria, Victoria B.C. CANADA
Date: Thu, 20 Aug 92 22:21:53 GMT

In article <1992Aug20.193300.264@novell.com> usenet@novell.com (The Netnews Manager) writes:
>I just grabbed the SLS package and installed it last night... very impressive.
...
>
>Another question.  I'm not too clear as to where the SLS (0.96c I think)
>fits in with 0.97 (shared libs, X vs gcc.2.2.2d, etc).  I'd really like to
>contribute to Linux but I'm fairly new to unix so I want to get to the point
>where I can build the kernel and update to the latest and greatest before I
>get started on a project.  Thanks in advance!
>

SLS is a cross section of Linux frozen at about .96c.  It looks like SLS
will not move to .97, because Linus announced .98 will have > 64 Meg memory
per process, which means a new GCC will have be be release, X11 whith its 
shared libs will have to be rebuilt, etc, etc.  In other words, .97 may
be very short lived.  But that isn't to bad, considering it isn't to
much more featureful than .96c.  But don't expect SLS .98 for quite 
some time (2 months?).  It takes a long time to compile all the pieces,
and I would like to crystalize the file permissions and locations
to widely acceptable values.  

>Dave
>dvogt@novell.com
>
>
>Generic Disclaimer :  I speak only for myself


pmacdona@sanjuan.uvic.ca

Newsgroups: comp.os.linux
From: d88-jwn@blofeld.nada.kth.se (Johan W}hlin)
Subject: Re: The Third Degree
Organization: Royal Institute of Technology, NADA
Date: Thu, 13 Aug 1992 12:49:39 GMT

bairstow@copland.psu.edu (Steven Bairstow) writes:
: ...
: 	- Has anyone noticed free inodes being left around? I think 
: 	  halt/shutdown is doing it. (This is what I was trying to figure 
: 	  out when it crashed.)
Yes I've been having this problem at least with reboot

: ...
: 			Steve
/Johan
From: jelson@poincare.cs.jhu.edu (Jeremy Elson)
Newsgroups: comp.os.linux
Subject: Re: Linux history...
Date: 12 Aug 92 20:00:09 GMT
Organization: Johns Hopkins Computer Science Department, Baltimore, MD

In article <1992Aug12.061013.16206@cheshire.oxy.edu> rafetmad@cheshire.oxy.edu (David Giller) writes:
>eric@tantalus.dell.com (Eric Youngdale) wrote:
>>	Speaking of which...  Did all of you see Bloom County (a comic in the
>>newspapers) a week ago last Sunday?
[...]
>A couple of years ago, something happened, something so horrible that
>I was never able to pick up a comic section since.
>
>Bloom County went out of circulation.
>
>Are you trying to tell me it's BACK???

Nope, Bloom County was discontinued by its author, and he started "Outland",
a once-a-week comic strip found in the Sunday paper which is based on many
of the same characters as Bloom County was based on.  The Bill Gates parody
(quite funny, actually) was an Outland strip.

-je


-- 
Jeremy Elson
jelson@server.cs.jhu.edu (Internet) / jelson@jhuvms (Bitnet)
From: nichols@ttd.teradyne.com
Newsgroups: comp.os.linux
Subject: Re: shared libs - can everyone be happy with this?
Date: 21 Aug 92 21:24:26 GMT
Organization: Teradyne Inc., Telecommunications Division

In article <LILJEBER.92Aug17203359@klaava.Helsinki.FI>, liljeber@klaava.Helsinki.FI (Mika Pekka Liljeberg) writes:
>> 
>> No, it wouldn't be shareable.  When a process writes to a shared page,
>> it gets its very own copy of it which is no longer shared.  There is a
>> term for this that you probably already know, but others may not.  It's
>> called Copy-On-Write.
> 
> I'll admit right away that I'm no expert, but it seems to me that William is
> right. The page _could_ still be shared, since all the processes using the
> page would be using the same libs. Of course, some kernel support would be
> needed: The page fault handler would have to check, if the referenced address
> is in library space and if so, fix the reference to point to the correct
> place in the library and clear the dirty-bit for that page instead of doing
> a Copy On Write. This would also work for static data references, as long as
> the data structures didn't change too profoundly.
> 
> Would this break demand loading, then? I think not. A text page could still
> be freed and reloaded on demand. Any library references on it would simply
> get relinked, when the path of execution intercepted them.

What happens if the 'linker fixup' code just happens to span a text page?
Since it's extremely unlikely that the link code is only one byte long, I
could forsee a problem if only part of it is paged back in ( *BOOM* ).  Try
to find that one with your debugger! :-)

Rick
From: eric@tantalus.dell.com (Eric Youngdale)
Newsgroups: comp.os.linux
Subject: Re: Buffer corruption problems.
Date: 13 Aug 92 22:43:20 GMT
Organization: Naval Research Laboratory

In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
>...I believe there is a bug in Linux that has the following behavior:
>
>-  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
>   so that what your app ends up with is some _other_ 1024KB chunk
>   (apparently from the same file)
>
>-  occurs only during very heavy disk access, such as megabytes accessed
>   continually

	You did not specify how many processes were doing the heavy disk
access.  If it is just one, then the problem could be localized to certain
areas, if you need more than one, then the problem probably lies somewhere
else. 

	That being said, this sounds like a race to me.  I started to browse
the kernel sources, and I did spot one thing.  This is a bit of a stab in the
dark, but it would appear as if this is a bug which *might* be responsible for
the error you are seeing.  Try the following, and see what happens.  I make no
warranty, and I have not tried this.  You might even want to wait for it to be
blessed by Linus.

	It appears as if interrupts are re-enabled before we lock the
request queue entry by setting the device id field.  My guess is that this bug
will only raise it's ugly head if there is more than one process trying to read
the disk.

-Eric

In linux/kernel/blk_drv/ll_rw_blk.c (make_request):
Old:
	found:	sti();
	/* fill up the request-info, and add it to the queue */
		req->dev = bh->b_dev;
		req->cmd = rw;
	
New:

	found:
	/* fill up the request-info, and add it to the queue */
		req->dev = bh->b_dev;
		sti();
		req->cmd = rw;
--
Eric Youngdale
eric@tantalus.nrl.navy.mil
From: dingbat@diku.dk (Niels Skov Olsen)
Newsgroups: comp.os.linux
Subject: Re: DOS FS deleting large files?
Keywords: dos
Date: 22 Aug 92 10:07:08 GMT
Organization: Department of Computer Science, U of Copenhagen

trussell@cwis.unomaha.edu (Tim Russell) writes:


>    Thanks to Theodore T'so for confirming my semi-suspicion that zcat/compress
>was the problem.  Apparently some (older?) versions treat ^C as an error
>condition and delete their input.

What versions would have problems? I have RCS installed and

	ident `which zcat`

returns 

	$Header: compress.c,v 4.0 85/07/30 12:50:00 joe Release $

Niels
Newsgroups: comp.os.linux
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
Newsgroups: comp.os.linux
Subject: Re: Can't fdformat
Date: 16 Aug 92 15:14:00 GMT
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH

In article <1992Aug16.061146.8868@pool.info.sunyit.edu> ujlh@pool.info.sunyit.edu (James Henrickson) writes:
> All I know is I have "fd0" and "fd1" and that they are autodetecting.
> Autodetecting doesn't always work.  What do I do?

Auto-detecting works for reading and writing common disk formats. It doesn't
work for certain less common formats (360kB disks in 720kB drives, etc.)
and when low-level formatting disks.

> What is setfdparms?

setfdprm is a program that loads arbitrary disk parameters for an auto-
detecting floppy device. You can use it to access unusual formats and to
define the format before low-level formatting a disk (with fdformat).

setfdprm is on tsx-11.mit.edu, /pub/linux/sources/sbin/setfdprm.tar.Z

> Was this "phasing-out" of device names made public or was it a secret
> plot against experienced Linux users?

Yup, but don't tell anybody ;-)  The problem with the naming scheme
traditionally used for fixed-format floppy devices (at0, PS1, etc.)
is, that it's not very intuitive and that it doesn't scale well.

Modern packages (i.e. MCC-interim) therefore use a new scheme that has
been discussed on the standards mailing list.

The fixed-format floppy devices won't go away (although I think that
a few releases of the rootimage don't create special files in /dev
for them, because the discussion on the standards list was (is?) still
in progress), but their names will change.

Of course, it's okay to continue using the old names. You just have to
be prepared to see occasional references to the new names and to
translate them to that what you have.

- Werner
-- 
   _________________________________________________________________________
  / Werner Almesberger, ETH Zuerich, CH      almesber@nessie.cs.id.ethz.ch /
 / IFW A44  Tel. +41 1 254 7213                 almesberger@rzvax.ethz.ch /
/_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/
Newsgroups: comp.os.linux
From: wreck@fmsrl7.srl.ford.com (R. Cage)
Subject: FAQ request
Organization: Ford Motor Company Scientific Research Labs, Dearborn, MI
Date: Mon, 17 Aug 1992 21:22:17 GMT

Would someone please re-post the FAQ, even if it is slightly dated?
Thanks.
From: zhao@unixg.ubc.ca (Jiansheng Zhao)
Subject: Tseng Lab ET 400 card and X11: How to change resolution?
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Thu, 13 Aug 1992 04:12:20 GMT

Hi, there,
After reading news in this group regarding running x11 under linux, I finally
tried my luck.
Now x11 is happilly running, thanks to all of you who posted
suggesitons and answered questions for us x11 newbies.
The onely problem I have is that no matter what change I make in Xconfig.
I can get only one resolution. Judging from its small fonts, I guess 
it is 1024x768, althouhg I don't have this resolution in Xconfig.
Also, clock.exe gives me only four numbers: 25.2, 28.3, 32.7 and 36.1., is this
normal for Tseng Lab card? The horizontal and vertical timings in 
Xconfig seem not to
affect the resolution, any clue?
-- 
Jiansheng Zhao
Dept. Chem. Eng, Univ. of B. C., Canada. V6T 1Z4
zhao@unixg.ubc.ca
From: rohrer@fncrd6.fnal.gov (Keith Rohrer)
Newsgroups: comp.os.linux
Subject: Re: HELP! -- Internal Compiler Error
Summary: I got that with cpp
Keywords: gcc error internal cpp also
Date: 18 Aug 92 14:02:09 GMT
Followup-To: rohrer@fncrd0.fnal.gov
Organization: Fermilab

In article <1992Aug18.001710.10722@sol.UVic.CA> pmacdona@sanjuan (Peter MacDonald) writes:
>In article <l90346INN8sa@ozona.cs.utexas.edu> jefftep@cs.utexas.edu (Jeffrey Grills) writes:
>>In article <1992Aug17.153437.25068@cs.tu-berlin.de> mackpei@cs.tu-berlin.de (Xue-Jun Pei) writes:
>>>I got the following error while trying to recompile 0.96c with GCC
>>>2.2.2:
[deleted]
>>>gcc: Internal compiler error: program cc1 got fatal signal 11
>>>make: *** [init/main.o] Error 1
>>>Sorry for it has been mentioned before, I couldn't find it.
>>>Any help would be appreciated!
>Seems I am seeing the same problem, since I have started using
>2.2.2d.
>Peter.

I was having that sort of problem myself, though I think it might have
admitted to being the cpp getting the signal; anyway, something in gcc
gets "fatal signal 11", so I gcc -E'd the file, same thing.
So I looked and discovered that between the MCC 0.96 base distribution
and the then-current MCC gcc disks, I had two different (diff: binariy files
cpp and /lib/cpp differ) copies of cpp, so I moved one to cpp~, symlinked,
and everything worked fine.  I don't know why it started breaking, or what
two cpp's were doing, but that fixed it.  See if that's your problem too.

	Keith
(rohrer@fncrd0.fnal.gov)
-- 
Disclaimer: None of Grinnell College, URA, Fermilab, and any other affiliated
persons or orginizations have licensed my ideas or opinions, and thus are
not entitled to any which may appear above.
 
Newsgroups: comp.os.linux
From: wolff@zen.et.tudelft.nl (Rogier Wolff)
Subject: Re: Jumptable Performance (Was: Re: shared libs - can everyone be happy with this?)
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Fri, 21 Aug 1992 08:18:23 GMT

davidsen@ariel.crd.GE.COM (william E Davidsen) writes:

>  If more instructions and bigger size really improved performance we'd
>all leave -O off our compiles, right. Therefore it's an interesting
>little puzzle.
>-- 
>bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
>    I admit that when I was in school I wrote COBOL. But I didn't compile.

That's what optimizing is all about: The only difference between GCC codee
for 486 and 386 is that in the 486 code some extra NOPs are added.

This will make the branch targets align on 16 byte boundaries, which will
improve cache performance.

						Roger
-- 
If the opposite of "pro" is "con", what is the opposite of "progress"? 
(stolen from  kadokev@iitvax.iit.edu, who got it from brydon@asl.sinet.slb.com)
EMail:  wolff@duteca.et.tudelft.nl   ** Tel  +31-15-783644 or +31-15-142371
Newsgroups: comp.os.linux
From: pundsack@sun15.vlsi.uwaterloo.ca (Mark Pundsack)
Subject: SCSI status? (Multiple partitions, tape drive)
Organization: University of Waterloo
Date: Fri, 21 Aug 1992 18:33:14 GMT

I've been out of the group lately and I was wondering what the status of
the SCSI support was.  I hadn't seen anything posted about it.

Does the SCSI support allow more than 4 hard drive partitions?
Is there any tape drive support yet?  or is that waiting for general tape
drive support?  The 0.96 release used to recognize my tape drive, but
I couldn't do anything with it.

An email response would be fine.

Thanks,
Mark Pundsack
-- 
/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~~~~Interests~~~~~~\
| Mark Pundsack:  pundsack@vlsi.waterloo.edu                 Man-Machine     |
| Disclaimer:  Come on, you didn't believe me did you?    AI,NN,NLP,robotics |
| P.S. Anyone looking for a co-op student?                   Pen-computing   |
From: eric@tantalus.dell.com (Eric Youngdale)
Newsgroups: comp.os.linux
Subject: Re: Shared Libraries Considered Harmful
Date: 14 Aug 92 02:31:35 GMT
Organization: Naval Research Laboratory

In article <1992Aug13.205728.25720@serval.net.wsu.edu> hlu@phys1.physics.wsu.edu (Hongjiu Lu) writes:
>I am not sure if you can run gdb on binaries linked with the shared libs.
>Since gcc 2.2.2, if you compile foo with -g, libg.a will be used instead
>of libc.a.

	You can run gdb on executables linked to the shared libs.  There are
a couple of limitations, however.  If a program crashes within one of the
routines in the shared library, you do not get a meaningful backtrace.
As long as program control is in your program and not the shared library
you can debug fairly normally.

	I also found that if I attach a running program that was linked to the
sharable library, that control would often be in the sharable library, and thus
I could not get a meaningful backtrace.  It is possible to set breakpoints and
then let it run until it hits the breakpoint, and then you can debug fairly
normally. 

	Obviously, if you are trying to debug a library routine you ought not
link to the sharable library.

-Eric
--
Eric Youngdale
eric@tantalus.nrl.navy.mil
From: hazen@budoe.bu.edu (Eric Hazen)
Newsgroups: comp.os.linux
Subject: Re: Logo in hand-hacked PostScript
Date: 19 Aug 92 13:51:47 GMT
Organization: Boston University Physics Department
In-reply-to: jbm@cyclone.sbi.com's message of 14 Aug 92 07:17:22 GMT


I just downloaded the "original" logo from tsx-11
(.../postscript/linux-logo.ps) and printed it out on our QMS color laser
printer, and it looks great!
The "hand-hacked" version from jbm is a lot smaller, but it's missing
the nice gradient on the blue background.

--

+----------------------------------------------------------------------+
|  Eric Hazen   hazen@buphy.bu.edu              Phone: 617/353-4117    |
|  Boston University Physics Dept                 Fax: 617/353-9393    |
|                                                                      |
|                    "O give me commentators plain,                    |
|              Who with no deep researches vex the brain" - Crabbe     |
+----------------------------------------------------------------------+
Newsgroups: comp.os.linux
From: scott@natinst.com (Scott A. Taylor)
Subject: Re: EISA and the abounding unix clones
Summary: /dev/hda isn't your SCSI disk
Organization: National Instruments, Austin, TX
Date: Wed, 12 Aug 1992 21:06:35 GMT

In article <1992Aug12.201620.16694@newshost.unh.edu> pss1@kepler.unh.edu (Paul S Secinaro) writes:
>In article <1992Aug12.192445.20894@cbnewsc.cb.att.com> chapin@cbnewsc.cb.att.com ( Tom Chapin ) writes:
>>
>>Do any of these abounding clones speak EISA yet?  Will they?
>>
>
>Well, all I know is that Linux didn't like my 486/33 EISA system with
>DTC 3290HD SCSI controller, which is supposed to be Adaptec 1542
>compatible.  It seemed to detect the controller and read the partition
>table properly when the bootimage was coming up, but then efdisk
>failed with an error when it tried to open /dev/hda.  I don't know if
>this is a general problem with EISA or just my controller.
>
Neither.  The first SCSI disk is accessed as /dev/sda (major number 8, minor
number 0), the second is /dev/sdb, etc.; /dev/hda refers to the first drive
on an AT-style interface (MFM, RLL, IDE).  If /dev/sda doesn't exist on the
root disk (I haven't seen a root disk since 0.95 ;-) ), make it with mknod.
"mknod /dev/sda b 8 0" should do it. Incidentally, if you got that far I
would guess that linux DOES run on *your* EISA machine.
>Paul
>
>-- 
>Niven's Law #14:   There exist minds that think as well as you do, but
>                   differently.
>Niven's Corollary: The gene-tampered turkey you're talking to isn't
>                   necessarily one of them.
-- 
Scott Taylor            |
(512) 795-6837          | "Well, I wanted to work with gymnasts." -David Byrne
scott@natinst.com       |
** NI pays me to write their code, not their opinions, and that's what I do **
From: eric@tantalus.dell.com (Eric Youngdale)
Newsgroups: comp.os.linux
Subject: Re: Stabilizing Linux
Date: 12 Aug 92 14:33:47 GMT
Organization: Naval Research Laboratory

In article <1992Aug12.124749.17219@engr.uark.edu> tep@engr.uark.edu writes:
>dje@sspiff.ampr.ab.ca (Doug Evans) writes:
>
>>davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
>>For example, I can buy a whole suite of manuals on SVR4/386 from Prentice Hall
>>for about $300. Yes yes, that's pretty steep, but what are the realistic
>>alternatives?
>>
>>Suppose Linux was heading to where SVR4/386 already is: most of our manuals
>>would already be written for us. And we would rarely have to cope with Linux
>
>Plagiarism.

	No, you miss the point.  I think that the idea was that we could simply
tell people to go down to their local technical bookstore, and tell them to buy
the SVR4/386 manual set.  The users manual might be OK, but we need to remember
that we are using mostly GNU replacements, and this means that there are
additional switches and features which would not be in the SVR4 manuals.
The system administrators manual for SVR4 is useless as far as linux is
concerned. 

	There is a linux manpage project that someone is coordinating.  I do
not know the status of it, but perhaps someone involved would care to fill us
in on the status.  I would be interested in seeing a list of which utilities
they have man pages for.

	This could be the beginning of a linux manual.  My feeling is that
a collection of man pages is a very poor substitute for a real manual, but
the main advantage is that there is very little writing required to get
something publishable.

--
Eric Youngdale
eric@tantalus.nrl.navy.mil
Newsgroups: comp.os.linux
From: enewton@uucp (Eric Newton x2092)
Subject: Re: InterViews
Reply-To: uunet.uu.net!srg!enewton
Organization: means "in a rut"
Date: 12 Aug 92 15:59:32

   I've just completed porting InterViews to Linux and it appears to work.
   So who else is interested?  You'll need 24Mb of swap + physical memory
   to compile the brute.  It's actually quite interesting watching 16Mb
   of available memory slowly being removed.

You only need that much memory to compile one file.  If you don't need
tiff support, you don't have to compile that file, and you don't need
so much space.

   It is quite slow, however my video card is only an ET3000 and I'd be
   interested to find out how it runs with a quicker video card.
   The speed could also be due to my 386-33.

The problem is that the coordinate space of InterViews is stored in
floats.  If you don't have an FPU, then InterViews is slow.  I have
rewritten the Coord typedef to be a class definition that implements
fixed point numbers in a 32 bit integer.  This has really made things
faster.  I will probably do the same thing for colors, since they are
also defined as floats.

   All I have to do now is work out how to create shared libraries.
   Considering the Interviews library is 1.4Mb and the Unidraw library is
   1.7Mb I wouldn't particularly like to have to statically link the
   programs if it is avoidable.

This would be nice if you run several version of the programs at once,
otherwise it isn't any worse than any other X windows programs.

Remember to mail to: 	uunet.uu.net!srg!enewton    "The more you complain,
<or>			enewton@oswego.oswego.edu    the longer God lets you
<or>			newton@access.digex.com      live."
	
--
Remember to mail to: 	uunet.uu.net!srg!enewton    "The more you complain,
<or>			enewton@oswego.oswego.edu    the longer God lets you
<or>			newton@cme.nist.gov          live."
Newsgroups: comp.os.linux