HDTenEightyP/NetNews huggingface dataset:
From: jliddle@rs6000.cmp.ilstu.edu (Jean Liddle)
Subject: Re: Kernel FP Math bug?
Date: Sun, 10 Jan 1993 18:14:16 GMT
Organization: Illinois State University

In article <ALSAGGAF.93Jan9183512@e40-008-4.mit.edu> alsaggaf@athena.mit.edu (M. Saggaf) writes:
>
>Declare argv as *argv[] as it should be declared and the 'problem'
>disappears. argv is not a pointer to a character, it's an array of
>such pointers. The above program would bomb even on a Cray.
>

*Sigh*

I should check the code I test more carefully before posting followups,
rather than cutting and pasting between xterms, testing, and posting in 
such a frenzy.  That one should have screamed at me the moment I read the
first article.  Oh well.

The reason I was eager to narrow down the possibilities is that I have other
programs I have downloaded (e.g. rocks, which comes with xsaver) that
dump core with floating point errors as well.  Guess I'll have to get off
my lazy *ss and actually hack the code some ... :-).

Ah well, the price one pays for running the best OS for i386+'s ...

Jean.
-- 
Jean Liddle                                 
Computer Science, Illinois State University  
e-mail:  jliddle@ilstu.edu                  
--------------------------------------------
From: KK4D%MARIST.bitnet@YaleVM.YCC.Yale.Edu (me)
Newsgroups: comp.os.linux
Subject: Segmentation fault???  Just what is it?
Date: 6 Jan 1993 20:03:55 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

I compiled mpeg_play and it worked fine, at about 300+K, so I recompiled
and relinked it with the shared libraries, 160ishK, but when I try to
run it I get a segmentation fault. I've seen this before.  Pardon my
ignorance, but what is it and why?  I have been able to compile and
run other progs. with the shared libraries.

  -Dan
From: alfie@dcs.warwick.ac.uk (Nick Holloway)
Newsgroups: comp.os.linux
Subject: Re: /proc inquiry
Date: 6 Jan 93 12:33:33 GMT
Organization: Department of Computer Science, Warwick University, England

In <1993Jan5.183447.27930@walter.cray.com> roberts@decsun3.cray.com writes:
> which works fine, I can "cd /proc" and see directories for each process.
> However, when I go into any of these, the links point nowhere:
> 
> 	cwd -> ---
> 	exe -> ---
> 	root -> ---

I was impressed with the /proc directory when I installed Linux on two
friends machines (*), but was a little disappointed by what readlink()
returns for these things.  I did realise that you actually had to open
them to get the info.

However, this is not very useful at the shell level.  At first I thought
that the actual file name would be useful, but then realised that this
is a) overhead, b) not necessarily possible (0 or many links), c) not
necessarily wanted.

But, as an alternative, how about the mount point and inode?  This could
lead to simple programs to find out which processes are preventing a
filesystem being unmounted, and would be more aesthetically pleasing.
It could mean a /proc based 'lsof'.

	cwd -> /users,922

As an alternative, it could just be the "dev,ino" pair.  This would
mean looking up what the mount point for a particular device was, but
quite possible.

	cwd -> 1617,9992

This has the advantage of being easy to parse (I might have a mount
point called "/awkward,directory" :-)

A quick random thought -- how does /proc deal with inet socket
connections?

--
Nick Holloway |  `O O'  | alfie@dcs.warwick.ac.uk, alfie@warwick.UUCP,
[aka `Alfie'] | // ^ \\ | ..!uunet!mcsun!uknet!warwick!alfie
----
(*) I'm so impressed with what I have heard and seen of Linux, I shall
    be purchasing a machine in the near future, and installing it.  Then
    hopefully I can contribute with code, rather than just ideas.
From: gary@minster.york.ac.uk
Newsgroups: comp.os.linux
Subject: re recompiled kernel crashes...
Date: 5 Jan 93 14:39:10 GMT
Organization: Department of Computer Science, University of York, England

I had the same problem and spent many hours recompiling the
kernel before it eventually went away. I think I fixed by
turning off the /proc file system when in make config.

The ps problem is easily fixed by altering ps's database
with (I think) ps -U somefileorother towards the end of the
kernel build process.

cheers...
Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: Re: 386 BSD
Organization: University of Victoria, Victoria B.C. CANADA
Date: Wed, 6 Jan 93 20:43:04 GMT

In article <1993Jan6.175208.11119@sfu.ca> rchen@fraser.sfu.ca (Robert Chen) writes:
>In article <1993Jan6.085905.25749@klaava.Helsinki.FI> lukka@klaava.Helsinki.FI (Tuomas J Lukka) writes:
>>In article <C0F8L6.AB4@ux1.cso.uiuc.edu> Jeff-Randall@uiuc.edu (Jeff Randall) writes:
...
>>No, not yet. They're in the works, by a mailing list on ref.tfs.com,
>>386bsd-sharedlibs. The implementation is going to be rather high-tech
>>(non-kludged). The current linux shared libraries do their job but
>
>Non-kludged?  I doubt that those on the GCC channel would agree with
>your implication about the *working* linux shared library implementation.

Not to perpetuate a flame war, but let me point out something.  Every
so often, the current Linux shared libs are bashed by the puritans
because it is not plug and play for the library builders to
generate the shared libs (and also that they sit at a fixed
address).  

Assuming that the fixed location is not a major hardship at this point,
(what, only 1.5 Gig per process, outrageous), the fact that library
builders have to work harder than an elegant solution would require,
shoudn't be an issue: lib builders are only a small fraction of the
user base, lets say 5%.  Is an elegant solution that penalizes 95% of
the users, with say a 30% penalty, to save 5% of the users some work,
a good idea?

I do not wish to dispute the above figures.  I am rather just
stepping back and looking at the bigger picture.  If an elegant
and practical solution is demonstrated, I will be the first to
jump on the bandwagon.  But being set back a month to collect
and recompile all of the system again won't make me to happy
either.  Hopefully, the new and old schemes (if a new one appears)
will coexist, at least for a while.

Peter
Newsgroups: comp.os.linux
From: joel@wam.umd.edu (Joel M. Hoffman)
Subject: Hypenation problems under LaTeX.
Organization: University of Maryland, College Park
Date: Mon, 4 Jan 1993 18:09:32 GMT

I just LaTeX'd and printed an 80-page document that I'd previously
prepared with emTeX.  But the Linux version has problems with
hyphenation.  It gave me the following:

	prayer-s
	letter-s
	s-pace
	a-mong

(The last one might be right, but I didn't get it with emTeX.)

I used the same hyphen.tex and plain.tex both times.  What's going on?
Might this be the odd result of a bug in one of the string library
functions? 

I'm still running 0.96 with lib92.04.06.

Please help!

-Joel
Organisation: European Space Operation Centre (E.S.O.C)
Date: Friday, 8 Jan 1993 16:13:24 CET
From: BARRY TITMARSH <BTITMARS@ESOC.BITNET>
Newsgroups: comp.os.linux
Subject: X-Tree for UNIX

Hi, We have all heard of Xtree gold etc for DOS, I have seen on this
group some time ago, some one spoke about a UNIX version that was free
I mailed him and asked about it but never had a reply.
Does any one know of a Nice X-windows Util that will allow files to be
broused played with in much the same way as you can with 'XtreeGold'
can for MESY-DOS
Idears Please.
Thanks Barry,
Newsgroups: comp.os.linux
From: ppc1@cec2.wustl.edu (Peter Pui Tak Chiu)
Subject: LATEX
Organization: Washington University, St. Louis MO
Date: Mon, 4 Jan 1993 18:36:43 GMT

hi everyone,

is there a version of LATEX for Linux?

thanks

peter

Newsgroups: comp.os.linux
From: cs911212@ariel.yorku.ca (RICK DILORENZO)
Subject: Linux Networking FAQ?
Originator: cs911212@g04.ariel.yorku.ca
Organization: York University, Toronto, Canada
Distribution: york
Date: Tue, 5 Jan 1993 22:20:28 GMT



  Is there a new / current Linux Networking FAQ somewhere?
The most recent one I have was from Nov 16th, but it said that it
would be updated every 2 weeks.  Couldn't find any new ones though.
The one from Nov 16th is a bit outdated, doesn't have anything
about NE2000 drivers at all.  Plus it's a couple of releases
out of date or so.
From: futzi@uni-paderborn.de (Michael Kutzner)
Newsgroups: comp.os.linux
Subject: Re: Can't login using libc.so.4.2
Date: 6 Jan 93 12:37:32
Organization: Uni Paderborn FB 17 Informatik GERMANY
NNTP-Posting-Host: sven.uni-paderborn.de
In-reply-to: mbo@dde.dk's message of 5 Jan 93 12:06:29 GMT

>>>>> Ueber Can't login using libc.so.4.2 sagte Morten Bonde:

Morten> Hi there

Morten> I tried to install libc.so.4.2 today.

Morten> After typing "ln -fs /lib/libc.so.4.2 /lib/libc.so.4" , I switched
Morten> to another virtual terminal and tried to log in. No Way !!

Morten> All I get is:

Morten> Undefinde C library functions.
Morten> 1. ulimit (Use getrlimit/setrlimit instead).
Morten> 2. light C shared image (Use the real one instead).

I've had the same problem.  You must recompile the shadow password package
(sources/usr.bin/shadow...) with this line in config.h:

#undef HAVE_ULIMIT     /* Define if your UNIX supports ulimit()        */
^^^^^^
It runs nice now.

Greetings, futzi

***************************************************************************
** --------------------------------------------------------------------- **
**  Michael Kutzner    **  X-Betreuung   **  <futzi@uni-paderborn.de>    **
**                                           <xgurus@uni-paderborn.de>   **
** --------------------------------------------------------------------- **
***************************************************************************
From: jstump@auntbea.austin.ibm.com (John E. Stump)
Newsgroups: comp.os.linux
Subject: Re: ST01/02 and Syquest 5110
Date: 10 Jan 93 15:18:59 GMT
Organization: IBM AWD Austin, TX

In article <1993Jan9.183152.1@cc.curtin.edu.au> smackinla@cc.curtin.edu.au (Pat Mackinlay) writes:
>
>>>I've a Problem with the Syquest 5110 (88MB) and the Seagate St01/02
>>>Controller. I managed Linux (99p2) to detect +0the drive and to fdisk it. I
>>>tried some Head/Cylinder/Sector values and it seemed to work. I was also
>>>able to mkfs the disk, but when I tried to copy data to the mounted disk,
>>>the system is rebooting.
>
>> This has been a problem for quite a while now. Unfortunately, I'm too
>> ignorant of SCSI workings, so all I can do is whine about it. Would
>> somebody PLEASE look into this problem? (Note: I can READ syquest DOS
>> filesystems just fine. I imagine I could read minix file systems as
>> well, except I can't write to it. It's just writes to blow it up.)
>> 
>> If it helps, I am running a 486DX. Eckehard, do you too?
>
>Ok. This bit about you having a 486 may be the problem. Can anyone else 
>using a 486 and the Seagate card let me know if you have a working 
>combination? ie: let me know if it has failed, or if it hasn't failed for 
>you.
>
>Do either of you guys have any other SCSI devices attached to your card, or 
>is it only being used for the SyQuest?
>
>Pat -- Have a day!

My SCSI card is used only for the Syquest. I have an IDE controller for
my hard disk.

(I do have RAM caching and shadowing turned off, and the proper jumper
is set on the board.)

john

-- 
John Stump (jstump@netftp.austin.ibm.com)
Newsgroups: comp.os.linux
From: jmaclean@fox.nstn.ns.ca (James MacLean)
Subject: Prob: SLS99pl2, UUCICO gives RLOGIN message ?
Summary: UUCICO is giving RLOGIN message during execution
Keywords: UUCICO
Organization: Department of Education, Nova Scotia, Canada
Date: Tue, 5 Jan 1993 13:51:26 GMT

	I'm using SLS99pl2 with extreme satisfaction. Even the bugs are 
providing me with free education on the internals of Linux. What I can't seem
to fix, though is a problem using UUCICO.
	If I log on as ROOT, and start UUCICO, I can do it all....
	If I log on as UUCP, or any other user, and start UUCICO,(UUCICO is 
the default shell for UUCP on my system), I get this far :
 ^Ssoftland=here
 ^SjeshomeRLOGIN
and then UUCICO stops. I checked all permissions according to the INSTALL
script I found for the MAILPAK, but no go.
	What might I be overlooking?

THNXS in advance

JES
James MacLean
Department of Education
N.S., CAN.
From: sergei@upenn5.hep.upenn.edu (Sergei Borodin)
Newsgroups: comp.os.linux
Subject: Re: SLS update: 'a' - 'c'
Keywords: SLS update
Date: 13 Jan 93 00:34:50 GMT
Organization: University of Pennsylvania

In article <1993Jan12.063625.21833@klaava.Helsinki.FI> sanjuan!pmacdona@sol.UVic.CA (Peter MacDonald) writes:
>The new release of SLS is now available.  It contains a massive
>upgrade to series 'a', 'b', and 'c'.  The compiler and libs
>have been updated, and more stuff added.  There are many 
>improvements, but see RELEASE for details.

>X11 will not be upgraded until 1.2 is out (hopefully with
>jump tables).

  Probably it's my stupidity (but I couldn't find the answer 
  in FAQ) but last time I upgraded from 0.95 to 0.98 
  I needed to buid everything from 'mkfs'. I'm sure there is
  a way around and I'm missing something.

  I realise that perhaps I need to do 'uninstall' a package,
  but should I boot from floppy?

>Peter
>pmacdona@sanjuan.uvic.ca
>------------------------------------------------------

 S.B.

Newsgroups: comp.os.linux
From: Chris.Wells@purplet.demon.co.uk (Chris Wells)
Subject: NEW TCPIP PROGRAMS
Organization: FidoNet node 2:252/305 - The Purple Tentacle, Reading
Date: Thu, 7 Jan 1993 21:04:00 +0000

Firstly, I would like to thank the people who mailed me about fingerd.
Great! It works. (For those who also had problems, finger is hard wired into 
the path. Do a strings fingerd to find out exactly where).

I noticed that the NEW (ie of December 2x 1992) tcpip binaries include ftpd. 
I also noticed that the SHADOW password support is not there. Is this know, 
or is it up to the user to recompile from the source?

Thirdly, I am still having problems with talk/talkd/ntalkd. Can anyone send 
me their system files (named.local, reversefile, etc etc), to help.
UUENCODED tar format would be bast, I guess.

Fourthy, we are using ICETCP to communicate with our unix hosts at work. 
When telnetting to my machine, the screen locks up after doing an "ls". This 
has been confirmed on two PCs. It does not happen from hosts, nor from the 
PCs to the other 5 unix boxes (one AIX, two HP/UX, two SCO).

Lastly, my DOSEMULATOR does not work (it violates memory protection). This 
is with the 0.98.5, 0.98.6, 0.99, 0.99.1 and 0.99.2 Kernels. Any ideas 
anyone.

I would be glad if you can answer any of these questions.

Again, please reply to :

cjw1@ukc.ac.uk (Internet)
cjw1@uk.ac.ukc (Janet).

or to this newsgroup.

MANY MANY thanks,


Chris
-----  
 
Newsgroups: comp.os.linux
From: jhallen@world.std.com (Joseph H Allen)
Subject: Re: DOS emulation
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 4 Jan 1993 06:26:14 GMT

In article <memo.837633@cix.compulink.co.uk> jburtona@cix.compulink.co.uk writes:
>DOS emulation

>Rather than running a copy of MSDOS in an virual 8086, wouldn't it be 
>nice to have a free dos-like operating system that was capable of
>running DOS programs?

I was seriously considering doing this once.  The difficulty of the problem
depends on the level of compatibility you wish to achieve:

	To implement documented DOS & BIOS calls:

		You need the translate the I/O calls into the proper linux
		calls, you need to make the EXE file loader along with the
		PSP management junk.  Also you have to implement the MS-DOS
		heap stuff.

		All this would be tedious, but easy.  Unfortunately only a
		few programs (like compilers) would work.

	To implement undocumented DOS stuff:

		A lot of programs make use of undocumented DOS calls which
		give access to some of MS-DOS's internal structures.  Most
		of this is for disk utilities, so you probably don't
		have to implement all of it.  Luckily, finding information
		on the undocumented stuff is not too hard.  I have a
		collection of books and magazine articles which explain most
		things.

		This stuff is necessary for getting TSRs and other process
		control stuff to work.

	To implement hardware:

		This is a mess.  You really have to give DOS programs direct
		access to video memory and registers.  Also you have to
		somehow simulate a lot of other hardware: most importantly
		the timers and the keyboard.  Many dos programs directly
		access the hardware for this stuff.  If you want any dos
		program to be able to use the serial ports, you have to
		simulate those also.

		I know VP-IX just gives direct access to the hardware, but
		then you might as well just run real MS-DOS (which VP-IX
		does).

	More problems:

		You probably have to implement extended memory routines for
		many programs to be useful.  Lotus 123, for example, really
		needs this.

		You probably also have to be able to run some DOS device
		drivers.

		Also many programs use DOS extenders to get access to 386
		features...

So it ends up being quite a bit of work.  The ultimate in compatibility
would be to get Windows to run in your MS-DOS, but it might actually be
easier to simulate the Windows API then to simulate MS-DOS and run real
Windows in it.

Rewriting a stand-alone version of MS-DOS is probably less difficult than
making a hack for linux.  At least then you don't have to worry about the
hardware compatibility.

See part II...
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Newsgroups: comp.os.linux
From: nigel@gamble.uucp (Nigel Gamble)
Subject: Re: real time
Organization: Nigel Gamble, Consultant
Date: Tue, 5 Jan 1993 12:53:54 GMT

In <1993Jan4.191229.22825@news.stolaf.edu> johnsonm@lars.acc-admin.stolaf.edu (Michael K. Johnson) writes:
>Well, actually, for some "real-time" applications, linux makes a lot
>of sense, essentially because it has very low overhead in general.

Unfortunately, although a real time operating system needs to have very
low overhead, having very low overhead does not mean that you have a
real time operating system.  With the current version of Linux (as with
any other traditionally designed UN*X operating system) there is no
way to *guarantee* fast, *deterministic* response times.

>However, it would not take a "fundamental design change in how the
>kernel works" to make linux a /good/ RTOS.

I think you're wrong here, for the reasons I outlined in a previous posting.
But if you (or anyone else) is seriously thinking of `Linux-RT', I'll
volunteer to help.

However, I now believe that the best way to implement a real time
POSIX compliant OS is to start with a real time microkernel, not with
a non real time monolithic kernel.  This allows many of the subsystems
that cause problems for a real time UN*X kernel, such as the file
system, to be implemented in user space where they can do less damage
to deterministic response times.  Of course, there is still the problem
of ensuring that all device drivers conform to the rules for ensuring
determinism.  This is difficult enough for a commercial implementation;
Linux device drivers are being contributed by many different people
who would all have to understand how their code impacts the real time
nature of the OS.
-- 
Nigel Gamble                                    gamble!nigel@uunet.UU.NET
Ft. Lauderdale, FL                              uunet!gamble!nigel
Newsgroups: comp.os.linux
From: ashtray@yoyo.cc.monash.edu.au (John Newnham)
Subject: [BUG?] Why does gdb affect the behaviour of many errors?
Organization: you have got to be kidding!
Date: Tue, 5 Jan 1993 05:11:10 GMT

Subject says it all.  I noticed that Rick, among others, seems to accept
this with equanimity.  But surely an error should (generally, races excluded)
occur wether the process is running under a debugger or normally?
One example I had recently was that mail was writing to string constants
(tsk, tsk), and therefore seg-faulting.  But I could not replicate the error
with gdb, so I was left with inspecting the code and guessing (or reading the
manual and realising that -Wall does not imply -Wwrite-strings. *sigh).

Comments?  Is this behaviour of gdb linux-specific, or should I be posting in
a different GNUsgroup?

ashtray@yoyo.cc.monash.edu.au
-- 
Vogt's commentary on the theory of Morphic Resonance:
  There is no god!  The universe just got into bad habits. (Marcus Voght)
Newsgroups: comp.os.linux
From: papresco@cantor.math.uwaterloo.ca (Paul Prescod)
Subject: Rawritten disk isn't being read
Organization: University of Waterloo
Date: Sat, 9 Jan 1993 15:55:17 GMT

I've read a bunch of INSTALL, README, FAQ, and META-FAQ files and
haven't heard of anybody else with this problem yet:  If it is a common
one, and I'm ignoring the correct source for the answer, I apologize.
It's a lot to assimilate, and I might have missed something.

I am using SLS, and the a1 disk I've RAWRITEd isn't booting.  I've
tried swapping my drive cables and using a real 1.2MB disk, instead of
1.44, but it doesn't seem to make much difference.  I'm using rawrite
v1.2, I think, and the interesting thing about it is that it seems to
have been written for 360k disks (from the manual).  If this has
changed, someone should update the manual.

All the computer does is read the disk, and write what looks to be
addresses in two places on the screen, over top of my BIOS boot
messages.  Every once in a while it pauses for a second and says Loa.
and then goes back to to spinning through reams of addresses.
Newsgroups: comp.os.linux
Subject: Re: Using a QIC-40 with Linux?
From: fmg@alpha.smi.med.pitt.edu (Filip Gieszczykiewicz)
Date: 11 Jan 93 02:46:02 GMT
Followup-To: comp.os.linux
Organization: Medical Informatics, Pittsburgh, PA USA
Summary: a fix?

In Article <73046@cup.portal.com> thus spoke JEFF SCOTT MARCUS:
>Does anyone know how I can use my 1/4 inch QIC-40 Tape drive in
>Linux? Specificallya a (DMA) Colorado Memory jumbo 120??

	Greetings. Yes and no (as far as I know). The millions
	of tape drives out there like the Colorado 120 need very
	well timed control (you have to physicly toggle control
	lines !!) and do not work under Linux because they can't
	be made to work reliably. Such is life.

********

	Ok, BUT if they work under MS-DOG then why not write a
	dependable driver that works under single-user mode
	of Linux? No amount of pleading from users will prevent
	me from logging them out if I can save not having to
	back up to floppy disks [evil grin] especially if I can't
	afford SCSI...

	But, the reason for my post is such, I'm not sure if anyone
	reads sci.virtual-worlds but a guy there, by the name of
	Jim Brain (yes, that's his name :-), is near the release of
	a small box that will interface the Nintendo Power Glove
	to the PC. It is built around a micro and elliminates
	the need for precise timing needed for reading the Power
	Glove (which is impossible if the same PC is doing 3D
	animation at the same time!!)

	So, how hard would it be to isolate the tape drives in
	question from the timings (or lack of) of the PC? The
	device above runs for under $100 (I know, I'm ordering one)
	and is assembled by a company (read the FAQ in that group).
	I would GLADLY pay $100 for a device that would allow me to
	backup stuff to tape even of a 386sx/16 running X and compiling
	the kernel.... ;-)

	This sure beats backing up 200MB to floppies (now folks have
	a good reason for NOT doing it :-) and also beats shelling
	out > $500 for a SCSI system....

	So, any takers? I'll settle for a schematic (I'm handy with
	a WW gun ;-)

	Take care.
-- 
+---------------------------------------------------------------------------+
| Filip "I'll buy a vowel" Gieszczykiewicz. | Best e-mail "fmgst+@pitt.edu" |
| All ideas are mine but they can be yours for only $0.99 so respond NOW!!! | 
| I live for my EE major, winsurfing, programming, SCA, and assorted dreams |
Newsgroups: comp.os.linux