HDTenEightyP/NetNews huggingface dataset:
From: kfisher3@mach1.wlu.ca (kevin fisher U)
Subject: terminfo?
Summary: future linux?
Organization: Wilfrid Laurier University
Date: Sun, 24 Jan 1993 05:11:02 GMT

Hello, this is a question I guess directed mainly at the developers of
Linux:
My question is this, will Linux at some later date support the terminfo
database, or will linux continue to use termcap?


Just a little technical curiosity,


-- 
--------------------------------------------------------------------------------
Kevin Fisher  ><> 	|  "Thank you.  You can't believe everything you
kfisher3@mach1.wlu.ca   |  see and hear, can you?" - Hendrix, 'EXP'
________________________________________________________________________________
Newsgroups: comp.os.linux
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Subject: Re: Safety Belt / SLS
Organization: University of Helsinki
Date: Sat, 23 Jan 1993 15:01:59 GMT

dejesus@pluto.nwc.navy.mil (Francisco X DeJesus) writes:
>The big problem comes when people get used to having the machine/program
>ask them "are you sure?" about every little thing, then they move on to
>a new system (like Unix) which assumes that the user knows what he/she is
>doing (!).

There is an even worse problem with "are you sure?", when it is asked
every time.  For example, if the command to remove a file asks for
confirmation every time, answering yes becomes an automatic and quick
reflex and the question becomes quite useless, since it doesn't stop
anybody from removing anything.  A much better user interface design
is to allow the user to correct errors after the fact; provide
undelete in the example of removing files.

"alias rm='rm -i'", just say no.  (At least after we get undelete
working.)

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
From: ctoomey@ccvax.ucd.ie
Newsgroups: comp.os.linux
Subject: Machine for Linux/NFS question
Date: 23 Jan 93 21:57:48 GMT
Organization: University College Dublin

Hi All,

	I have a rather idealistic question which some of you
may be able to help with:

	IF you had the chance to obtain whatever 386 (gloom) based
configuration (ie. mouse, memory, video card, monitor etc) you
desired what would you go for?

	I ask because I am faced with this opportunity but am not the

	Also I seem to remember reading some stuff about NFS for Linux -
Is it possible (advisable) to mount an NFS file server under Linux?
fabled controller of the purse strings (to whom I must justify my choice)
and what I know about PCs can be written down on the back of a (virtual)
beer coupon...

	Thanks in advance

		Colm Toomey

		ctoomey@ccvax.ucd.ie

Newsgroups: comp.os.linux
From: keith@rsd0.dl.nec.com (Keith Sparacin)
Subject: Problems with SLS
Organization: NEC America
Distribution: comp
Date: Sat, 23 Jan 1993 16:19:16 GMT

I copied the SLS distribution from tsx-11 on Jan 21.  The installation
went okay, there was one warning about smail already exists.  I had
trouble building the kernel.

1) During 'make dep' in the tcp directory, it couldn't find
   netinet/in.h.  I did a find on my disk and I couldn't find it either.
2) When compiling tools/build.c it couldn't find stdio.h, string.h,
   stdlib.h, sys/types.h, sys/stat.h, sys/sysmacros.h, unistd.h,
   fcntl.h.  
3) stdio.h, stdlib.h, and sysmacros.h were not on my disk.
4) In /usr/bin the symbolic link to halt points to reboot.  reboot
   is a symblic link that points to shutdown.  shutdown does not
   exist in /usr/bin.  All this leads to halt now found.
--------------
Keith Sparacin		(keith@rsd.dl.nec.com)
From: Derek.Glidden@f42.n377.z1.fidonet.org (Derek Glidden)
Newsgroups: comp.os.linux
Subject: Linux using HPFS
Date: Mon, 18 Jan 1993 21:19:09 -0800

Apologies to the nets if this reply is belated or re-FAQing something I

haven't seen yet: 

The major problem with ANY other operating system using HPFS is that, 
from what I understand, the actual format/structure of the HPFS is still

(C) Microsoft and they're not releasing any details, except to IBM. 

Now, if someone's hacked the details out on their own, that's another 
story altogether. 


 * Origin: The Slut Club -=- (813) 689-1150 -=- USR/DS 16.8K
(1:377/42.0)
From: unrzf0@cip.rrze.uni-erlangen.de (Carl Scheuermann)
Newsgroups: comp.os.linux
Subject: Why not splitting this group?
Date: Wed, 27 Jan 1993 14:50:26 GMT
Organization: RRZE, Regionales Rechenzentrum, Universitaet Erlangen Nuernberg
NNTP-Posting-Host: rzcip06.rrze.uni-erlangen.de

Hi,

I know, there has been a lot of talking about splitting this group.
But I can't understand, why it isn't possible to find a solution to this
problem. There are so many questions on how to install the XServer. So
why not creating a group comp.os.linux.X11. Or, for the people working
with TCP/IP, making a group comp.os.linux.TCP?
Please don't kill me if I say something that has been said a lot of times.
But the current state of this group isn't bearable any more - and it WILL 
get worse.

Bye the way,
can someone tell me the difference of all the different S3 chip versions?
All the different chips I know of is 911, 928 and 801. Are there more of them?
(why does the latter one don't have such a cute Porsche modell number?)

thanx 4 your answers,

Carl
---
---------------------------------------------------------------------------
Carl H. Scheuermann
student of electric engineering sciences at the Univ. of Erlangen-Nuremberg

INTERNET: clscheue@cip.informatik.uni-erlangen.de
          unrzf0@rzsuna.rrze.uni-erlangen.de
---------------------------------------------------------------------------
------------- What in the heck is he doin'? -------------------------------
---------------------------------------------------------------------------
From: aisk@castle.ed.ac.uk (Sotirios Karagiannis)
Newsgroups: comp.os.linux
Subject: SCHEME->C or whereis USRSTACK in mem ?
Keywords: USRSTACK , SCHEME->C
Date: 23 Jan 93 16:15:12 GMT
Distribution: comp
Organization: Edinburgh University


Hello,

I am trying to port SCHEME->C  to Linux.
The point I am stuck right now is that normally, SYSV machines and suns
have USRSTACK defined in <machine/vmparams.h> or somewhere near...
I cannot find where the STACK base (or top) is for Linux, nor any
info that will lead me there...
Can some kind soul tell me where this exists or what it should be ?

Even better, if somebody already ported this beast to Linux 
(SCHEME->C) email me !
I think robots.ox.ac.uk has got some scheme code ....

Please email at :

aisk@castle.ed.ac.uk


Thanks in advance ..
Sot

.rnsig ? What the hell is this ?
Newsgroups: comp.os.linux
From: mhbrekke@iastate.edu (Monty H. Brekke)
Subject: GCC 2.3.3 installation problems
Organization: Iowa State University, Ames, IA
Date: Tue, 26 Jan 1993 02:35:51 GMT

I recently installed GCC 2.3.3 and tried to compile a new release of 
the kernel, but apparently I'm still missing some include files.
It seems to be looking for some files which were released with 2.3.2,
but I can't seem to locate them. The missing files are in a directory
similar to where gxx233.tar.Z puts its include files, except that 
they are for version 2.3.2 instead of 2.3.3. Did I do something
wrong during the installation, or do I need to get another file?
If so, where can I find it? Thanks in advance for your help.

-- 
Internet : mhbrekke@iastate.edu
From: mchapman@ariadne.eis (Michael Chapman)
Newsgroups: comp.os.linux
Subject: Tape Drive Questions
Keywords: QIC, Tape
Date: 27 Jan 93 10:53:04 GMT
Reply-To: mchapman@eis.k8.rt.bosch.de
Organization: Robert Bosch GmbH., Reutlingen, Germany.

I asked these questions to the TAPE channel but got no answers except 
for some hate mail telling me I should not be so dumb as to ask and 
serveral mails saying "hey, I want to know the answers too!!"
So can someone **PLEASE** enlighten us all and post the answers here!

What is Qic-02 Qic-36 Qic-80 and what is a colorado jumbo?

Hey! I'm really confused! Can someone please enlighten me and
other ordinary mortals what all these qic numbers are. It
would also be good to know what tape drives from what manufacturers
are what standards.

For instance the colorado jumbo 250MB drive. (Its adverised just
like that and nobody seems to be able to say what it is except that
it is QIC compatible!!!!) Is that QIC-125? 
Could I read/write QIC 80 tapes with it?  
Do I want to (for data interchange)?

What is the most interchangable tape format?

What interfaces are supported with linux up to now?

What interface has a colorado jumbo, archive xxx, everex xxx etc?

What are the chances of getting enough info from the
manufacturer to write/adapt a driver for it?

What are the chances of someone who knows nothing about
tape drivers (but a bit about unix drivers) writing a driver
for it?

What standard do people use to exchange tapes (QIC-80 QIC-125 ??)

Any constructive enlightenment would be appreciated.
I think this is of sufficient interest to post any replies
to comp.os.linux.

Thanks,

Mike



Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: Re: Safety Belt / SLS
Organization: University of Victoria, Victoria B.C. CANADA
Date: Wed, 27 Jan 93 06:23:45 GMT

In article <1993Jan27.000807.28623@newsserver.rrzn.uni-hannover.de> riepe@ifwsn4.ifw.uni-hannover.de writes:
>In article 94187@mavenry.UUCP, maven@mavenry.UUCP (Norman Hamer) writes:
>|> 
>|> Something I'd like to see in the MKFS/MKEFS program would be a "are you 
>|>really sure" thing if you try to write a linux filesystem onto a partition 
>|>which isn't marked as linux... I tried to install the 99p2 SLS release, 
>|>ended up writing a linux partition over my DOS partition (user stupidity), 
>|>had to restore from week-old backups... Ugh. While I don't have anyone but 
>|>myself to _blame_, it sure woulda been nice if it had said "this partition 
>|>is marked as DOS... use fdisk to change to type 81 before proceeding"... 
>|>
>
>The same applies to mkswap - I once wrote a swap signature into the FAT
>of my DOS partition (fortunately, I could fix it with dd).

The standard solution to this problem is not to go back and hack all
the existing utilities to add such checks and prompts.  If for no
other reason than you are saddling all those who know what they
are doing with extra overhead.

Instead, an intelligent administrative front end needs to be written,
that can do the checks for you and prompt you to your hearts content.

In the time that was spent belaboring the point, most of a decent
such shell could have been crafted.

Peter.
From: probreak@matt.ksu.ksu.edu (James Michael Chacon)
Newsgroups: comp.os.linux
Subject: Re: TRIDENT-8900 series problem with XWindows
Date: 21 Jan 1993 17:50:29 -0600
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

jlaiho@ichaos.nullnet.fi (Juha Laiho) writes:

>In article <mtrottie.38.0@emr1.emr.ca> mtrottie@emr1.emr.ca (Marc Trottier) writes:
>>So what is the problem???
>>1- Does SLS support only TRIDENT-8900C and not other from 8900 series?
>Exactly. Just as the error message you got (see above) says:
>  Only TVGA8900C (note the capital C) chip is supported. No other revisions.
>  The technical facts of why this is so escape my memory, but I'm sure
>  someone else can tell.

>>2- Or is my Video Card BIOS too old? If yes, is it upgradable?
>Linux doesn't use any BIOSes after boot-up. As far as I know.

>..Wolf

Just thought I would add that the driver's are only for revision 0x13 of the
8900C Chipset. There is another ROM revision that has a lower number that
the server won't recognize. You can force it to trident by adding
Chipset tvga
into Xconfig.

The video cards are programmed by direct fiddling with the registers on the 
card, so the ROM revision makes a difference, as to what the card will do.
Anything before the 8900C mapped things differently from what I was told,
and it was decided never to support them.

James
Newsgroups: comp.os.linux
From: tgc@world.std.com (Terry Carlin)
Subject: Re: HELP: Trouble installing LINUX on older HD
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3
Date: Tue, 26 Jan 1993 13:27:32 GMT

S_FAEHNLE@rzmain.rz.uni-ulm.de (Faehnle Thomas) writes:
: Hi LINUX-users!
: 
: I got a *BIG* problem installing LINUX on an older 40 Meg MFM harddisk.
: On this HD some tracks are damaged---no problem, I thought, just specify
: them when formatting the disk with the BIOS utility. But when I want to
: install LINUX it ignores the bad-track-marks and so it's gonna hiccup
: every time he wants to write on a bad track (no wonder). I think You can
: imagine that this is extremely annoying....
: 
: So this is my question: Does anyone of You ( <-- experienced LINUX-users )
: 			know how to mark bad tracks on a HD under LINUX ???
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.)

: Any answer would be a great help!
: 
: Many thanks from a forward-looking LINUX newcomer.
: Bye, Thomas.
-- 
Terry Carlin
tgc@world.std.com
Newsgroups: comp.os.linux
From: jwinstea@fenris.claremont.edu (Jim Winstead Jr.)
Subject: Filesystem Naming
Organization: Harvey Mudd College, WIBSTR
	<garyt.727635377@lgc.com>
Date: 21 Jan 93 19:35:15 GMT

In article <garyt.727635377@lgc.com> garyt@lgc.com (Gary Thompson) writes:

   Rick Miller <rick@ee.uwm.edu> writes:

   >qx@shire.math.columbia.edu (Qi Xia) writes:
   >[...]
   >>BTW: due to the name conflict to "log file system", the name of lfs
   >>is going to be changed. Johnson (johnsonm@stolaf.edu) suggests xiafs 
   >>(pronounced as sheaves) and I come out xfs. suggestion wanted.

   >I *like* that idea.  "xfs" has a nice 'sound' to it.

   It does, but there is already an "xfs".  There's a paper in the latest
   issue of the X Resource which describes it.  Here is the abstract...

	[abstract deleted]

   Sounds like a "/proc" filesystem for X.  I haven't seen it, but it
   sounds cool and since it's already called "xfs", maybe another
   name should be chosen (I kindof like "yafs" :-)

It does sound pretty cool (the proc-like fs for X, that is).

But, this brings up a point I've been meaning to make for a while....

Why do file system names have to contain 'fs'?  Right now, none of the
other filesystems do - proc, msdos, minix, ext, xenix, iso9600.  I
don't see why restricting yourself to a letter + fs is the slightest
bit desireable.

Thus, I would think a log file system would be referred to as 'log',
the new 'xfs' as 'xia', a future 'official Linux file system' as
'linux'.  The only real exceptions I would see to this are where the
'fs' is traditionally part of the name, like Berkeley FFS (which could
just as easily be called 'fast'), or the above-mentioned xfs (which
could just as easily be called just 'X'), or NFS (which could just as
easily be called 'net').

What's the obsession with limiting ourselves to a letter plus 'fs'?
Be creative!
--
loveritablessencentipedependentalism+      Jim Winstead Jr. (CSci '95)
andaterrificklengtherealityearguessy|      Harvey Mudd College, WIBSTR
mpathybridgenerationiceremonymphysic|   jwinstea@jarthur.Claremont.EDU
alendareadvertisexpresshothoughthend+ or jwinstea@fenris.Claremont.EDU
Newsgroups: comp.os.linux
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Subject: Re: TextSearch under Linux
Organization: University of Helsinki
Date: Mon, 25 Jan 1993 10:44:35 GMT

jjsf@gmv.es (Julio Sanchez) writes:
>find . -exec grep foobar {} /dev/null \;

find . -print | xargs grep foobar

Fewer processes, somewhat more efficient (in my experience), easier to
use in most cases.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
Newsgroups: comp.os.linux
From: bogstad@blaze.cs.jhu.edu (Bill Bogstad)
Subject: Re: Linux file systems
Organization: Johns Hopkins Computer Science Department, Baltimore, MD
Date: Fri, 22 Jan 1993 05:21:02 GMT

In article <93021.073006NU013809@NDSUVM1.BITNET> Greg Wettstein <NU013809@NDSUVM1.BITNET> writes:
>[asks for a filesystem "clean" flag indicating the system was 
> shutdown normally the last time this filesystem was used.]
>...
>I would suspect that an ioctl or a kernel call would have to be implemented
>which when called would mark all mounted filesystems that had this
>attribute as clean.  The reboot/halt/shutdown suites could be modified to
>sync the kernel, then mark the filesystems and then either halt or reboot.

	I think the "umount()" system call should do this.  Shutdown already
umounts() all mounted filesystems so this will work with everything except
the root filesystem.  Personally, I'm not sure it is such a bad idea to
force a check of the root filesystem anyway.  So being unable to use this
"trick" with the root filesystem might not be such a bad thing.

				Bill Bogstad
From: sct@dcs.ed.ac.uk (Stephen Tweedie)
Newsgroups: comp.os.linux
Subject: Re: Missing stuff: pstat, tset, NIS?
Date: 23 Jan 93 16:23:04 GMT
Organization: University of Edinburgh Dept. of Computer Science, Scotland

In article <1993Jan21.124216.13521@aston.ac.uk>, evansmp@uhura.aston.ac.uk (Mark Evans) writes:
> : >In article <lma.727207214@dayton.Stanford.EDU>, lma@dayton.Stanford.EDU (Larry Augustin) writes:
> : >
> : >Pstat?  Nope.  Anyway, the kernel structures have been changing too
> : >rapidly to make such a beast easy to maintain...

> The current idea appears to be to impliment examination of any
> kernel data structures by using the /proc filesystem.  The format of
> this is likely to be more stable (once all the bits have been put
> in) than diging arround in /dev/kmen i.e. no recompiling
> tools/rebuilding databases whenever the kernel is changed!

/dev/kmem or some form of explicit system support (via syscalls or
/proc) is needed to allow programs access to internal data structures,
but for human browsing of kernel space, there is another way...

The dead easy way of looking through the kernel: if you are running a
kernel with all of the object files still kicking around in the
correct places, then you can use GDB to look at the kernel while it is
running!  (Although obviously you can't change actually change
anything.  That would be just TOO dirty.)

The program file to run GDB on will usually be
/usr/src/linux/tools/system.  But the clever bit is that GDB will
allow you to debug a program on a core dump file, and linux is cunning
enough to be able to present the running kernel image to GDB as a
core-dump image!

The trick is to create a /dev/core character device with major/minor
1,6 (ie. mknod /dev/core c 1 6).  Then
	gdb /usr/src/linux/tools/system /dev/core
and you're away!

I understand that the procedure is especially useful if you have
compiled tools/system with the -g flag, but I have only tried it out
on a non-debugging kernel.  However, it works wonderfully.

By the way, it is a good idea to be pretty careful about the
permissions you set on /dev/core if you are at all worried about
security...

Oh, and another point.  If you get a kernel panic, it is a great idea
to run GDB on tools/system and "disassemble 0x<offending-pc>" (where
offending-pc is the program counter reported in the kernel panic
message.  GDB will automatically work out the enclosing function
(well, at least narrowing down to the surrounding global symbols if
the kernel is compiled without -g), so you have a good chance of
locating fairly precisely the offending code.  This can make tracking
down kernel bugs a LOT easier.

Cheers,
 Stephen Tweedie.
---
Stephen Tweedie <sct@uk.ac.ed.dcs>   (Internet: <sct@dcs.ed.ac.uk>)
Department of Computer Science, Edinburgh University, Scotland.
Newsgroups: comp.os.linux
From: frank@algol.bsa.de (Frank Huemme)
Subject: partition size
Organization: BSA
Date: Tue, 26 Jan 93 07:28:17 GMT
X-Newsreader: TIN [version 1.1 PL8]


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 ?

	Frank
-- 
Frank Huemme	email: frank@algol.bsa.de
BSA - Bizerba Software und Automationssysteme       4630 Bochum,Geisental 12
Newsgroups: comp.os.linux
From: cloos@theory.TC.Cornell.EDU (James H. Cloos Jr.)
Subject: Re: NON-FAQ - date: CST instead of GMT?
Organization: Cornell Theory Center
	<vera.727838687@fanaraaken.Stanford.EDU>
Distribution: na
Date: Sun, 24 Jan 1993 06:59:39 GMT

ASK> This question was asked recently, but was left
ASK> unanswered/misunderstood:

ASK> I am having problems with date returning my time in CST vs GMT.
ASK> For example, if the correct time is 23:00 CST: I would try
ASK> typing: date -s "23:00 CST" and then date outputs: Sun Jan 24
ASK> 05:00:00 GMT 1993, the time correctly specified as GMT, but I
ASK> can't get date to output "23:00 CST".  Is there a way to do this,
ASK> or do I just have to live with seeing either the time in GMT or
ASK> the local time specified as GMT?

JSV> I fixed this by creating a link from /usr/lib/zoneinfo/localtime
JSV> to the appropriate timezone file (in my case
JSV> /usr/lib/zoneinfo/US/Pacific)

Additionally, if for any reasone you do not want to do that/cannot do
that, setting the TZ environmental variable will also do the trick.

If TZ=CST6CDT, for instance, you would be at GMT-6, except during US
daylight time, when you would be at GMT-5.  Linking
/usr/lib/zoneinfo/localtime to /usr/lib/zoneinfo/US/Central will do
the same thing.  I recomend using a symbolic link, though, so that the
setting is obvious.  It is often good to also link posixrules to
localtime w/in /usr/lib/zoneinfo, so that any POSIX compliant software
that needs to know the local timezone will work.

P.S.	What is the difference between US/Pacific and US/Pacific-new?
	Is it a difference in the daylight savings period?

-JimC
-- 
James H. Cloos, Jr.	include <std/qotd>
Cloos@TC.Cornell.EDU	include <std/disclaimers.h>
Cloos@Batcomputer.UUCP 	Snail:  POBox 1111, Amherst, NY 14226-1111
Cloos@CrnlThry.BITNET 	Phone:  +1 716 673-1250 (voice only, for now)
From: dmw@teal.csn.org (Dave Warner)
Newsgroups: comp.os.linux
Subject: c++2.3.3 prob. w Regex.o
Summary: Udefined symbols w. c++2.3.3/libg++
Keywords: c++2.3.3 Regex
Date: 24 Jan 93 16:39:56 GMT
Organization: Colorado SuperNet, Inc.


I'm confused about c++2.3.3 compiling.  Compiling a c++ application
(octave, a mathcad clone) WITHOUT -g I had to add -lc to the
ld command to find c[in|out|err] and iostream -- I remember
reading postings about iostream being in libc so that's why
-lc is necessary.  Right?  Is this the way 'its supposed to be'?

Anyway, adding -lc got rid of many, many error messages so no
big deal, I guess. Just curious.

An error I haven't been able to fumble around and fix, however,
is the following:
     /usr/lib/libg++.a(Regex.o): Undefined symbol
     re_compile_pattern(const char *, int, re_pattern_buffer *)
     referenced from text segment
The same error also for : re_compile_fastmap, re_search_2,
and re_match_2.

nm /usr/lib/libc.*a | grep re_compile_pattern shows:
     00006150 T _re_compile_pattern     <-- libc.a
     60025d6c A _re_compile_pattern     <-- libc.ca
     60000aa0 A _re_compile_pattern     <-- libc.sa

If these ARE in libc why are they not found?  I tried loading with
-static, -nojump and neither made any difference.  What am I missing
here?

Thanks for any help, enlightened ones
dave
-- 

| Dave Warner            | e-mail: dmw@csn.org |
| 151 Sky Trail Road     | USWest: 443-9589    |
| Boulder, CO 80302      |    FAX: 443-6791    |
From: daniel@cassidy.EuroPARC.Xerox.COM (Ian Daniel)
Newsgroups: comp.os.linux
Subject: Linux and ^Z (elm)
Date: 26 Jan 93 13:16:08 GMT
Organization: Xerox PARC

I'm trying to port a mail reader to linux. Mostly it compiled with few changes,
but if I try suspending it with ^Z it just frantically tries to re-start. I know
I need to write a signal handler, but I'd like to look at the src for elm to see
how the person who ported elm coped with this if at all possible.

Could someone point me in the direction of the src.

Thanks,

--Ian
Newsgroups: comp.os.linux.announce,comp.os.linux,news.groups