HDTenEightyP/NetNews huggingface dataset:
From: pmacdona@sanjuan (Peter MacDonald)
Subject: Re: SLS: how do we know we've caught up ?
Organization: University of Victoria, Victoria B.C. CANADA
Date: Fri, 22 Jan 93 03:51:03 GMT

In article <1993Jan20.235409.201@victrola.sea.wa.us> vince@victrola.sea.wa.us (Vince Skahan) writes:
>Linux, and SLS, are moving targets.  That's probably 'A Good Thing' but it
>certainly is getting more and more frustrating.
>
>It's struck me with all the changes in SLS over the months and especially
>recently that there's a need for a way to let us know which version of SLS
>we have installed...that way, if we have questions, the first thing to 
>mention after the kernel version would be the version of the package we're
>having trouble with. 
>
>For example, did I get the latest menus.tpz ?  Or am I one version behind
>with a bug (that's fixed in the current version) lurking to get me ?  Or am
>I several versions behind ?
>
>Maybe a flat file stashed somewhere under /install is needed that has all the

Actually, currently there really isn't a "version" of SLS.  Instead, each
package can be updated without notice.

What was just added to SLS is that, everytime you install a disk, it
updates a file in /install/disks/diskXN with the package name, and
the size in bytes of the package.  Thus you can always tell if the
package you installed is the same size as some other one.  And thus,
with 99.9% certainty, you should be able to tell if you have the
same package.

Now this by itself is of marginal value, but I plan on implementing a
(bash) script that will drive an automatic updating scheme based upon
this information.  Thus the "version" of SLS will be the sum of all
these sizes.  ie, it can determine the current version, and update
accordingly.

This scheme is not bullet proof, but exacts nearly zero overhead, and
in practice should be quite reliable.  And, most important of all, doesn't
exact any extra administrative overhead.  It also has the advantage that
you can always find which disk a package is on by doing:

	fgrep pkg.tpz /install/disks/disk*

Peter
Newsgroups: comp.os.linux
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Subject: Re: ?? Why no out/in in assembler ??
Organization: University of Helsinki
Date: Tue, 26 Jan 1993 11:39:24 GMT

In article <C1Fno4.IBI@helios.physics.utoronto.ca> grindley@helios.physics.utoronto.ca (Robin Grindley) writes:
>
>Sorry, i should have been a little clearer. I realize that user tasks will
>run at different privileges and IOPL's. Any normal code should not be allowed
>to do what i want. But if one wants to debug a system one has to have access
>to tools that can bypass normal security. My question is, IF i do setup
>a task to run as root and i make sure i have the correct IOPL, the assembler
>does not even have the capability to generate these instructions (they are
>not in its "dictionary"). 

gas *does* support inb/outb quite happily: that's how the linux kernel
uses them, and your problems are with something else.  You are either
using the incorrect syntax (gas syntax is NOT the braindead intel syntax
that DOS people have gotten used to), or you are doing something wrong
in gcc if you are trying to get the IO instructions compiled using the
__asm__ statements. 

In the linux sources, I define the inline functions inb()/outb() for
these kinds of things, but they are neither part of gas nor of gcc -
they are part of the linux sources, and may not work for you unless you
use them the way they were meant to be used.  Specifically, they are
defined as inline functions, which means that you have to either give
the -finline-functions option to gcc to get them compiled in at all, or
have to use optimizations (linux uses -O6 just because I can always hope
that it will mean something for some future gcc..).  If you are seeing
unresolved _inb references at the linker stage, this is probably the
reason: the inb/outb functions aren't in the standard library, and
certainly should not be added to it either. 

I'd suggest printing out the gcc documentations (yes, it's 300+ pages),
and look for a file called 'gas-doc.tar.Z' (at least available on
nic.funet.fi) which contains a small manual for the GNU assembler.  The
gas manual isn't very good, though (unless it has been updated in the
last few years). 

		Linus
From: tdubois@hellcat.ecn.uoknor.edu (Thomas Dubois)
Newsgroups: comp.os.linux
Subject: SLS Problems :(
Summary: Won't get past boot disk.
Keywords: SLS
Date: 27 Jan 93 19:44:56 GMT
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA


Please don't flame me for this but here goes.

I ftp the SLS distribution of 0.99pl2 on 1-26-93.
I tested the disks on an AT&T 386 at school and they
worked fine. When I got it home I booted from the a1
disk and got this:

Loading...........................................................................

And there it hangs forever.

Hardware:
- 386-25 DTK motherboard w/4MB Ram
- DTK bios

Any help would be appreciated. Thanks in advance.


Tom DuBois
tdubois@mailhost.ecn.uoknor.edu
[Sig Here]
From: jsteele@netcom.com (John Steele)
Newsgroups: comp.os.linux
Subject: Re: HELP: Trouble installing LINUX on older HD
Date: 26 Jan 93 20:13:41 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In <C1Gqpx.4A7@world.std.com> tgc@world.std.com (Terry Carlin) writes:

[stuff about how Faehnle Thomas' MFM bad track problems deleted]

>Use:  mkfs -c /dev/whaterver howbig

>The -c option will cause mkfs to check for and map out bad blocks.
>This probably should be a FAQ. ( I just search it.)

This "definitely" should be a FAQ.  This is about the 50th time I've seen
postings about this very same problem.  Also SLS (Thanks Peter!) doesn't
have the man pages for mkfs/fsck to explain the switches to either...

>Terry Carlin
>tgc@world.std.com
-- 
#include <disclaimer.h>			/* route all flames to /dev/null  */
/**************************************************************************/
/*   Systems Analyst      | John Steele     email: jsteele@netcom.com     */
/* Video Business Systems |                                               */
/*   1-800-255-3088       |    Most people spell COBOLSUX incorrectly...  */
/**************************************************************************/
Newsgroups: comp.os.linux
From: mdw@theory.TC.Cornell.EDU (Matt Welsh)
Subject: Re: partition size
Organization: Linux
Date: Tue, 26 Jan 1993 20:47:34 GMT

In article <93.026.082817@algol.bsa.de> frank@algol.bsa.de (Frank Huemme) writes:
>Hello,
>yesterday i installed SLS 99.2 . I want to give linux 200 Meg, but not
>as 64+64+64+8 Meg. Whats to do, to use only one or maybe two partions ?

Yet another FAQ. Use the extended filesystem. 

mdw
-- 
Matt Welsh, mdw@tc.cornell.edu 
  "Donuts. Is there anything they can't do?" 
Newsgroups: comp.os.linux
From: Benjamin@zds-oem.zds.com
Subject: trouble compiling .99.3 HELP!
Organization: Zenith Data Systems, OEM Systems Engineering
Date: Thu, 21 Jan 1993 14:34:55 GMT


I was trying to get PS to work with my .98.5 version but The SLS
I installed did not include a tools/system dir so I could not run
ps -U   anyway I thought maybe that was created when the kernal was
compiled and I wanted to get .99.3 anyway.  
So I got the 99.3 source from Wuarchive and set about compiling it.
when trying to run "make dep" it ran into trouble here is what it said:
for i in chr_drv blk_drv FPU-emu; do (cd $i && make dep); done
chr_drv: no such file or directory
blk_drv: no such file or directory
FPU-emu: no such file or directory
make[2]: *** [dep] Error 1
make[1]: *** [dep] Error 1
make: *** [dep] Error 1

But I thought it was not important (heh heh, foolish user)
when I ran MAKE ALL it worked fine until it went into net/tcp
then it could not find include/cdefs.h  
I am using gcc version 2.2.2d (if that matters)
Can someone help me out?  Do I just need cdefs.h? (could you uuencode it
to me?)
 
THanks for all the help!
Adam B. (linux wanna-be)
Benjamin@zds-oem.zds.com

Newsgroups: comp.os.linux
From: btenison@eng.auburn.edu (Bruce Tenison)
Subject: Re: Serial I/O in 99pl3-4
Reply-To: btenison@eng.auburn.edu
Organization: Auburn University Engineering
Date: Mon, 25 Jan 1993 23:02:45 GMT

Well, it seems that I had enabled the Autoconfigure IRQ, and this was what was
causing me problems!  Anyway, Thanks to all the people who responded so quickly!!

---
R. Bruce Tenison					btenison@eng.auburn.edu
Department of Electrical Engineering			(205) 844-1800
200 Broun Hall						(205) 826-7689 
Auburn University, AL 36849
From: pdcawley@cix.compulink.co.uk (Piers Cawley)
Newsgroups: comp.os.linux
Subject: Looking for vgalib based .dvi
Date: 28 Jan 93 07:42:00 GMT
Reply-To: pdcawley@cix.compulink.co.uk


A while back someone posted a message looking for a non X11 based
.dvi file viewer, and, AFAIK nobody answered.

Do I take this to mean that the only way to avoid using X to look at
dvi files is to get hold of EmTeX for MeSsy-DOS and use it's dvi
previewers. Somebody tell me this ain't so. Please.

BTW, I know I could use something like dvi2tty, but, IMHO looking at
at TeX file in glorious monospacing tends to defeat the object.

-----
Piers
From: kf8nh@kf8nh.wariat.org (Brandon S. Allbery)
Newsgroups: comp.os.linux
Subject: Re: Filesystems for people providing packets
Date: Tue, 26 Jan 93 12:21:15 EST
Distribution: world
Organization: Brandon S. Allbery's Personal System

root@umibox.hanse.de (Bernd Meyer) writes:
> while names like "page-up-window" match the request "page-up-window.h" when
> used on that fs, it is a nightmare for everybody using a fs with long names 
> to rename all the files with truncated names.

Why do you need to rename files with short names?  You don't want to do that
anyway:  if you do, you have to edit patch files to change the names of
files to match your personal longnames mapping.

> I would strongly suggest that you use efs or maybe xfs, because the problem
> is not given the other way round - a long filename untarred into a minix-fs
> will be shortened and still matched.

Until it unpacks both "page_up_window.c" and "page_up_window.h" into the
same directory, at which point the longnames-fs snobs are happy and the
minix-fs types get the royal shaft.  And since the minix FS is still the
standard one, this is not a good idea at all.

>   is not meant as criticism, but as a suggestion. And
>   yes, I did rename everything several times, but I
>   just think it isn't necessary that hundreds if not
>   thousands of people do this...

I doubt "thousands" of people run xiafs/extfs instead of minix fs.

++Brandon

--
He's BAAAACK! Brandon S. Allbery                       kf8nh@kf8nh.wariat.org
Help stamp out OSF/Motif in our lifetime!
From: tytso@athena.mit.edu (Theodore Ts'o)
Newsgroups: comp.os.linux
Subject: Announcement of new patches to the serial patches!
Date: 28 Jan 1993 17:00:34 -0500
Organization: The Internet
Distribution: world
Reply-To: tytso@athena.mit.edu (Theodore Ts'o)
NNTP-Posting-Host: senator-bedfellow.mit.edu

A set of new patches to the serial driver (versus 0.99pl4) can be found
on tsx-11, in /pub/linux/ALPHA/serial; here's the README file from that
directory:

The file serpatches in this directory contain patches against Linux
0.99pl4 to significantly improve the serial driver.

New features summary:

	* Fully supports use of the bottom half "software interrupt"
		(no new functionality add, but increases the
		efficiency of the code.)

	* Improved the AUTO_IRQ code; it should hopefully be more
		resistant to false IRQ assignments (espcially from the
		printer IRQ, IRQ 7); I'd also be interested to know if 
		it has a better chance of detecting internal modem
		cards with Rockwell Chipsets.

	* The /dev/ttys?? devices are now completely POSIX complaint,
		so that	if carrier detect is missing, an open of the device
		will block until carrier detect goes high.  The O_NONBLOCK
		flag to the open() system call will cause this blocking
		behavior to be skipped.

	* A new set of devices, which I will call /dev/cua?? (following
		the SunOS convention) are now supported.  They have the
		same minor number as their /dev/ttys?? counterparts, but
		their major number is 5, instead of 4.

		These devices never block waiting for carrier detect;
		and they also have the property that once open, any
		attempt to open the corresponding /dev/ttys?? line
		will block until the use of the /dev/cua?? device is
		finished.

		If the corresponding /dev/ttys?? line is in use when
		the user attempts to open the /dev/cua?? line, the
		error EBUSY will be returned.

		This allows a getty to open and block waiting for
		carrier detect on the /dev/ttys?? line, while
		simultaneously allowing users to use that same line to
		dialout by accessing it via the /dev/cua?? device.

Note that while the Kernel support for the last two features are there,
the application support is not necessarily present.  For example, the
getty distributed with SLS uses the O_NONBLOCK flag when it opens its
serial line.  This means that it will never block waiting for the
carrier detect, and so it unnecessarily ties up the modem.  

Similarily, although the kermit program distributed with SLS claims to
be compiled with the POSIX option, it does not seem to work opening the
/dev/ttys??  line, even though it is supposed to.  Of course, it works
fine using the /dev/cua?? devices, so it doesn't matter quite so much.
I would like to talk to the person who ported the kermit on the SLS
distribution, to see if he modified it to make it work on Linux, or
whether he used a straight POSIX configuration.

If there are any bugs or comments, please send them to me
(tytso@mit.edu).  Thanks!

					- Ted, 1/28/93


Newsgroups: comp.os.linux
From: sens@FASECON.ECON.NYU.EDU (Sunando Sen)
Subject: Re: compression programs
Organization: New York University
Date: Wed, 13 Jan 1993 07:51:11 GMT

In article <1993Jan11.063052.11030@sol.UVic.CA>
pmacdona@sanjuan (Peter MacDonald) writes:

>Also, a while back someone posted a shell script that drove
>cpio to do multivolume backups, with compression (it was
>a long time ago).  Does anyone have such a beast? 

Do you have something in mind like the following:

 Create archive -->	find / -depth -print | cpio -o -O /dev/fd1
 Extract archive -->	cpio -i -I /dev/fd1
 List archive -->	cpio -it -I /dev/fd1

Or something more complicated?

Regards,

Sunando Sen
sens@fasecon.econ.nyu.edu
Newsgroups: comp.os.linux,comp.windows.x.i386unix
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: Updated tables for Xconfig???
Organization: AT&T
Date: Fri, 22 Jan 1993 23:11:15 GMT

In article <C19oDH.Equ@shyguy.lonestar.org> bmyers@shyguy.lonestar.org (bob myers) writes:
> I'd like to know if anyone has taken the time to maintain/update
> the database for possible entries for SVGA cards and/or monitors.
> 
> I'm still having problems with trying to get my Laser 386sx monitor
> (does 1024x768 in interlace mode) running properly with either 800x600
> or 1024x768i.  I've tried some of the programs that people have sent
> me, but can't seem to lock into the proper values.  Even the settings
> that I get with either clock.exe or blowing away the CLOCK line in
> Xconfig for my STB Ergo Powergraph 1024x768 card differ from the
> values contained in the database found in /usr/lib/X11/etc/modeDB.txt 
> (i believe?) file.
> 
> With the repeated number of requests from all others concering
> various brands of graphics cards/monitors, I'd think that it
> would be rather beneficial to maintain an updated list and include
> it in the Linux/X11 distribuitions...
> 
> thanks
> 
> 
> 
> -- 
> -----------------------------------------------------------------
> Bob Myers                        | You gotta watch out for those
> Shyguy's AT&T SVR4 Unix/Uniboard | shy guys....you never know 
> Email:bmyers@shyguy.lonestar.org | what they're thinking..:)

Try looking in /usr/X386/lib/X11/etc/modeDB.txt.  That's the current database
as of the release of X that you're running.  A new version will be issued
with XFree86 1.2 in a couple of weeks.  There are fewer than a dozen new
entries in it since 1.1 was released in October.  If people don't send
me entries, they don't go into the database.

--
David Wexelblat <dwex@mtgzfs3.att.com>  (908) 957-5871
AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ  07748

"The meaning of life?  That's simple.  Try to be happy, try not to hurt
 other people, and hope to fall in love."  -- Mallory Keaton
Newsgroups: comp.os.linux
From: ctne_ltd@uhura.cc.rochester.edu (Chris Newbold)
Subject: Re: Linux .99pl4
Organization: University of Rochester - Rochester, New York
Date: Tue, 26 Jan 93 03:43:54 GMT

0.99-pl4, EISA 486/33 16MB ram, DTC3290 SCSI host (aha1542 compat.)
Fujitsu & Quantum disks, Sony CD-ROM and Wangtek tape. 2 serial
and 2 parallel.

No troubles what so ever.

-Chris

-- 
>>>> Chris Newbold <<<< * "If you fool around with a thing for very long you *
University of Rochester	*  		  will screw it up."		     *
Disclaimer: "All warranties expire upon payment of invoice."                
ctne_ltd@uhura.cc.rochester.edu * uhura.cc.rochester.edu!ctne_ltd@uunet
From: STDN%MARIST.bitnet@YaleVM.YCC.Yale.Edu (Dan Newcombe)
Newsgroups: comp.os.linux
Subject: Producing code that can run OS independantly
Date: 22 Jan 1993 18:26:46 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

What would be the proper steps for producing code that could
be run off of a floppy (dd to the floppy) that would be independant
of and OS?  I know that I would have to write a bootstrap loader
and all that *fun* stuff, but what would I have to do to assemble
and link it?  And how well would I be able to incorporate C functions
into this code eventually?
I know under DOS :( I'd have to write the assembler code, assemble it,
link it, then run it through EXE2BIN, then write it to the floppy.

What would be the proper steps on Linux?  Thanks..

  =Dan

Dan Newcombe
stdn@vm.marist.edu                        kk4d@maristb.marist.edu
dnewcomb@cybernet.cse.fau.edu             And others...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- Real programmers like vending machine popcorn.  Coders pop it in the
  microwave oven.  Real programmers use the heat given off by the cpu.
  They can tell what job is running just by listening to the rate of popping.
From: probreak@matt.ksu.ksu.edu (James Michael Chacon)
Newsgroups: comp.os.linux
Subject: Re: /usr/include/linux directory and manual page directories???
Date: 21 Jan 1993 17:58:49 -0600
Organization: Kansas State University
Distribution: na
NNTP-Posting-Host: matt.ksu.ksu.edu

sno@ais.org (Stephen Opal) writes:

>>>   My question is, where can I find these header files... or are they 
>>>necessary, or should I create a linux directory with all the neccessary files
>>>but have them all empty, or should I remove those lines from all the necessary
>>>header files????/
>>
>>READ THE F****** FAQ! then get the kernel sources, that were they lie.
>>

>Is there some way to get the includes *WITHOUT* getting an 800 K file
>of kernal sources?  Is there an important reason why the #includes can't
>be a separate package?

>-- 
>Stephen N. Opal     sno@umcc.ais.org

Nope, but there is an important reason for this. Suppose you get the include
files for 0.99.2 now, and then decide to upgrade to 1.0 later on.
If you have to put the kernel source in the same place, it will automatically
update the include files in /usr/include/[asm,linux]. Otherwise you stand
the chance of having older include files there and running into problems
later on.

Just install the kernel sources, and then if you don't want to compile it
delete everything but the include files. But, leave them in /usr/src/linux/
include/[asm,linux] and link them into /usr/include like the FAQ says.

If they got released as a separate package, people would be to tempted to just
update the include files once, and put them directly in /usr/include. Then
you run into problems later on.

James
From: brand@addvax.llnl.gov (Hal R. Brand, LLnL, 510-422-6312)
Newsgroups: comp.os.linux
Subject: [Q] Anyone supporting X8514Linux server??
Keywords: X11 X8514 server
Date: 22 Jan 93 05:48:00 GMT

Organization: Lawrence Livermore National Laboratory
News-Software: VAX/VMS VNEWS 1.41    

					Hal R. Brand
					LLNL
					brand@addvax.llnl.gov
Newsgroups: comp.os.linux
From: bogstad@blaze.cs.jhu.edu (Bill Bogstad)
Subject: Re: Printcap / SLIP
Organization: Johns Hopkins Computer Science Department, Baltimore, MD
Date: Mon, 25 Jan 1993 19:33:44 GMT

In article <C1F7oI.G7E@rice.edu> adam@owlnet.rice.edu (Adam Justin Thornton) writes:
>Two questions:

>b) If KA9Q doesn't work with kernels > .97, then is there any way
>to do IP over the modem?  How do I tell TCP/IP that I'm using a
>serial line and not an ethernet card?

	If you recompile the sources, the KA9Q for Linux package works with
99.2 doing SLIP/CSLIP over a modem line.  (I just upgraded to 99.4 and
haven't tested it yet.)  I believe that I might have had to make some very
minor changes to the sources to get them to compile under 99.2; but I don't
recall any real difficulties.

				Bill Bogstad
Newsgroups: comp.os.linux
From: ngoh@rintintin.Colorado.EDU (NGO HIEN D)
Subject: Looking for good ethernet cards/suggestions?
Organization: University of Colorado, Boulder
Date: Thu, 28 Jan 1993 15:54:49 GMT

I am looking for a source for ethernet boards in the US.  Just
wondering if anyone has a line on a reputable dealers with good
prices.  I plan to set up a mini-network to start and add cards as
needed.  Any suggestions as to pros/cons of particular
boards/designs/manufacturers are graciously welcomed.  I will post a
summary of responses.

Thanks in advance,


+--------------------------------------------------------------------------+
| Hien D. Ngo                                        ngoh@rtt.colorado.edu |
| Computer Science Undergraduate                                           |
| University of Colorado at Boulder                                        |
\--------------------------------------------------------------------------/
From: kf8nh@kf8nh.wariat.org (Brandon S. Allbery)
Newsgroups: comp.os.linux
Subject: Re: HELP! Linux doesn't seem to like MSDOS floppies
Date: Thu, 28 Jan 93 12:26:52 EST
Distribution: world
Organization: Brandon S. Allbery's Personal System

mce159@mcs.salford.ac.uk (GI    PERKINS) writes:
> told to ignore, then some cryptic numbers about the MSDOS disk. The script
> then immediatly requests disk 'a4' without any copying of files from the 
> 'a3' disk!?!?
> 	Whats happening? Why isn't the MSDOS floppy being mounted?

Someone please relay this to the tsx-11 mirror maintainers (I don't even
know who-all they are!):

Several of the sites mirroring the SLS distribution appear to have missed
the most recent updates.  Please, please, please update your mirrors now!
SLS install has been fixed, but at the moment the only way you can be sure
of getting a working one is to get it from tsx-11.

++Brandon

--
He's BAAAACK! Brandon S. Allbery                       kf8nh@kf8nh.wariat.org
Help stamp out OSF/Motif in our lifetime!
Newsgroups: comp.os.linux