HDTenEightyP/NetNews huggingface dataset:
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: C_A_D=0
Date: 27 Jul 92 18:53:53 GMT
Organization: University of Helsinki

In article <1992Jul27.180447.28246@ifi.uio.no> janl@ifi.uio.no (Jan Nicolai Langfeldt) writes:
>
>I have mucked about with the kernel lately (0.96cpl2). When I set the
>C_A_D varaible to 0 (to avoid reboot on pressing C-A-D) (and compile,
>reboot :-). After login in and executing sync I press C-A-D and the
>system locks, completely... Anyone with similar experiences?

Setting 'C_A_D = 0' results in init being sent a SIGINT instead of a
instant reboot when ctrl-alt-del is pressed.  If you have the old init
that doesn't handle a SIGINT, you get a very dead system: init dies, and
everything essentially locks. 

There are two possible solutions to this:

(a) get one of the newer init packages that handle SIGINT gracefully,
    and do a clean shutdown.

(b) apply this "patch" (or wait for my next release):

	in linux/kernel/sys.c, ctrl_alt_del():

! 		if (task[1])
			send_sig(SIGINT,task[1],1);

	should be:

! 		if (task[1] && task[1].sigaction[SIGINT-1].sa_handler)
			send_sig(SIGINT,task[1],1);

The patch essentially checks that a signal handler is present before
sending the SIGINT. That way old init packages won't be surprised.

		Linus

PS.  I'll probably make patch3 to 0.96c available sometime later this
week: the main new feature is a dynamic buffer-cache.  The original
patches were by oreilly, but have been almost totally rewritten by me. 
The IRQ code has also been edited and is hopefully stable now.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.os.linux
Subject: Re: Shoelace delay and console mode hacks
Date: 22 Jul 92 14:02:58 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <y830NB3w165w@ssg.com>, unixsys@ssg.com (Rick Emerson) writes:

| >   I thank you for the useful info, but... DOS? To quote my youngest,
| > "Yuckie-poo!" I am going home tonight and try a quick port of bpe to
| > linux. If it works I'll upload it tomorrow. People sholdn't have to go
| > into DOS to do things like this, it corrodes the bits!
| > 
| >   It's my binary editor of choice, hopefully it will port easily.
| 
| Go for it!  Michael's hack was a response to a lack of tools.  Add the tools
| and make us all a little better.  <grin>

  Uploaded to tsx-11 this am, but some of the other tools I was hoping
to do didn't look promising. See other post if you care.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.
Newsgroups: comp.os.linux
From: butler@cs.tulane.edu (Larry Butler)
Subject: ICP and linux
Keywords: ICP
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Date: Sun, 26 Jul 1992 22:58:08 GMT
Nntp-Posting-Host-[nntpd-452]: rex

Hi,
  I am interested in learning more about UNIX ICP. I've read about
interprocess communication in 4.3BSD (which is what is used here at school).
I would like to see ICP in action. Could anyone direct me to some source code
that could show me an real example of how it is used and where it is useful.
Thanks,
Larry
From: sundaram@cps.msu.edu (Divya Sundaram)
Newsgroups: comp.os.linux
Subject: How much space is needed for installing Linux
Date: 28 Jul 92 21:15:36 GMT
Distribution: usa
Organization: Michigan State University, College of Engineering
Originator: sundaram@indian.cps.msu.edu


Hi Linuxers,
I was reading the FAQ and I came upon the section where it talks about how 
much disk space is neede for installing Linux. It seems that about 40MB is
needed - but the answer is not quite clear. There is some mention that X takes
up 150MB! 

Once and for all please help me answer this question:
	suppose I wanted to install linux, with gcc and g++ etc and 
	a few (not all) utilities and a fully functional X-windows system
	then how much disk space (in an uncompressed format) should I set 
	aside. 

Any advice and infor is much appreciated.
thanks
Divya
(sundaram@cps.msu.edu)
Newsgroups: comp.os.linux
From: scott@natinst.com (Scott A. Taylor)
Subject: Re: Help needed with Linux Installation
Keywords: scsi, ultrastor
Organization: National Instruments, Austin, TX
Date: Fri, 24 Jul 1992 21:12:46 GMT

In article <1992Jul24.200628.21296@watson.ibm.com> kyw@watson.ibm.com (Ko-Yang Wang) writes:
>Hi,
>I was trying to install Linux but can't get pass the first stage: partitioning
>the hard disk.
>I tried both pfdisk in the sc.tamu.edu distribution and pdisk in the
>mcc-intrerim distribution.
>
>I have the following hardware:
>	Gateway 2000 486DX2/50 EISA with ultrastor 24F SCSI controller and
>	Maxtor 340 SCSI hard disk. 16 MB of memory, ATI Graphic Ultra,
>	Irwin 250 tape with no controller.
>
>I first partition my hard disk to have one 40 MB DOS primary partition.
>(I don't have prior PC or DOS experience). I load the backup and everything
>worked correctly.
>
>I then proceed to install Linux.
>After booting from the floppy, one of the message I got was 
>***	0 hardisk, 0 tape found.

This message from the SCSI driver indicates that Linux is not recognizing your
hard disk (unlikely for reasons explained below) or your controller.  You
should have gotten a message indicating which controllers are present and 
which drivers are in use. For example, the UltraStor *14F* driver responds
with something like "Ultrastor 14F driver version 1.0 alpha by David Gentzel".
Some informational messages follow, and then the kernel displays "Detected
X disks, Y tapes total".  If X == 0, you've got a problem (assuming there is
at least one disk attached, of course).

>In the tamu 0.96c+ version, I use pfdisk to do the partition. I did
> ..... more stuff deleted ....

I imagine that the problem is that the UltraStor 24F is not supported, only
the 14F is (although allegedly the 14F is the EISA version of the 24F).  If
you can run your 24F in 14F emulation mode, give it a try.

By the way, the FAQ does contain a list of supported SCSI controllers, and the
24F is not one of those on the list.

Scott Taylor
scott@natinst.com
-- 
-----------------------------------------------------------------
Scott Taylor             | "Speak for NI? I'm not even sure I can
(512) 795-6837           | adequately speak for myself!!!"
scott@natinst.com        |
From: hlu@phys1.physics.wsu.edu (Hongjiu Lu)
Newsgroups: comp.os.linux
Subject: Re: ksh for Linux & olwm for X (do they exist?)
Date: 28 Jul 92 19:47:10 GMT
Organization: Washington State University

In article <1992Jul28.144104.21938@crd.ge.com>, davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
|> In article <1992Jul28.043659.6215@news.columbia.edu>, jml12@cunixa.cc.columbia.edu (Jonathan M Lennox) writes:
|> 
|> |   Bash ought to be a superset of ksh--is there something in ksh that's
|> | missing in bash?  Or do you just feel that bash is too bloated?
|> 
|>   No, bash is not a superset of ksh, although many features are similar.
|> Neither the user interface or the programming interface are identical or
|> a subset. I'm constantly trying to use ksh stuff on bash and finding out
|> that it isn't there or works a little differently.
|> 
|>   That's not a criticism of bash, just a factualy note. Bash is a nice
|> enough shell, but it does things in its own way.
|> 
|>   If I get the chance after the Olympics are over I may try to compile
|> real ksh on linux. As long as I do it on a work machine it's covered by
|> the site license, so I can legally do that, although I can't share the
|> binary.
|> -- 

Have you tried zsh?

-- 
H.J.
Gcc/libc maintainer for Linux.
Newsgroups: comp.os.linux
From: ral45184@uxa.cso.uiuc.edu (sPiNdRy )
Subject: QIC-36 tape drive with an Emulex QIC-36-> SCSI board
Organization: University of Illinois at Urbana
Date: Mon, 27 Jul 1992 20:47:03 GMT


    is this a usable idea?  will this work?  Or will drivers have to be
  written anyhow?

      - ral45184@uxa.cso.uiuc.edu

Newsgroups: comp.os.linux
From: Epstein@DOCKMASTER.NCSC.MIL
Subject: Cannot mount root with 0.96c patch level 2
Reply-To: Epstein@DOCKMASTER.NCSC.MIL
Organization: The Internet
Date: Wed, 22 Jul 1992 02:59:03 GMT

Currently running 0.96c patch level 1 with gcc-2.2.2 --- no problems
patch 2 patched cleanly.  using Torvald's /usr/src/linux/include ...
--- compiles okay yes I did a make clean; make dep; make disk

Booting 0.96c patch level 2 get "magic match failed" "Kernel panic:
Unable to mount root"

QUESTION:  In digest482, Torvalds discusses new mount(2) and magic
number.

Was there some code I HAD to change besides patch 2 to get a new magic
number on / (root) partition of HD.  This partition was made with
rootimage 0.96 mkfs.  Again, 0.96c patch level 1 runs fine from this /
(root) which is a minix file system.

It becoming very unclear what are discussions (re Torvalds of 14 Jul 92)
and what are patches.

I will stick with 0.96c patch level 1 for a few days before take out
magic number check.

John
Newsgroups: comp.os.linux
From: doogie@garfield.catt.ncsu.edu (Jeff House)
Subject: VGA1024 card w/512K
Organization: Computer and Technologies Theme Program, NCSU, Raleigh
Date: Fri, 24 Jul 1992 08:50:13 GMT



I have the above card and was wondering if anyone knows how I would set
it up to support X?  I'm probably out to lunch with this question, I
realize...

I have an NEC Multisync II Monitor, and the back of the Card's manual
says:
Horizontal	Vertical
35.5 kHz	87 Hz		1024x768
35.0 kHz	56 Hz		 800x600
31.5 kHz	60 Hz		 640x480
31.5 kHz	70 Hz		 640x400


This is all it says, and says nothing about the chip it uses, etc.

I have downloaded X386.modeDB.Z and extracted the entry for NEC
Multisync II and placed it at the end of my Xconfig file, removing the
default one (it didn't work either).  Maybe X386 can't use the card that
I have?

I've changed much and rebooted many timeO$GGs, or I wouldn't be asking
this so-  Could someone help me?  ;)

Thanks a zillion!!!!

-Doogie
Newsgroups: comp.os.linux
From: tyrone@cbnewsi.cb.att.com (tyrone.shiu)
Subject: re: re: New to Linux, need help.
Organization: AT&T
Date: Fri, 31 Jul 1992 12:41:59 GMT

Thanks to those who response to my request, especially to A.V. LeBlanc for his
question by question answer. 

+--------------------------------+
| Tyrone Shiu                    |
| Phone: 908-548-7852            |
| Email: tyrone@cbnewsi.att.com  |
+--------------------------------+

P.S.
A.V. LeBlanc: I can't seem to send you mail using LeBlanc@mcc.ac.uk.
It quite saying host unknown. 
Newsgroups: comp.os.linux
From: pshuang@athena.mit.edu (Ping-Shun Huang)
Subject: Re: Why ZIP/UNZIP slower than DOS version?
Organization: Massachusetts Institute of Technology
Date: Fri, 31 Jul 1992 06:48:46 GMT

In article <1992Jul31.050921.19572@athena.mit.edu> Ching-Hsiang Chen <chchen@stat.fsu.edu> writes:

 > I am using the zip/unzip binaries from tsx-11(or banjo?). The zipping
 > /unzipping speed is far slower than the pkzip/pkunzip DOS version,
 > especially for large files (>= 100k). Anyone has the same problem?

I assume that the binaries you are using are results of the recent port
to Linux of the code from the Info-ZIP project. Two reasons they seem
slower than PKZIP/PKUNZIP 1.1 for DOS are: (a) PKZIP/PKUNZIP are coded
in assembler (probably with reasonable care toward optimization by
PKWare, Inc.) whereas Info-ZIP source code is portable C and not
hand-optimized for any particular platform; (b) Info-ZIP's recent
releases by default use a compression algorithm whimsically named
deflation (as opposed to PKZIP 1.1, which uses implosion)... PKZIP 2.0
will be using deflation as well, and my experience (playing around with
PKZIP 1.93 alpha) is that deflation tends to be a bit slower than
implosion anyway (but gives ratios in the ballpark of ARJ). Whether this
(performance hit) is true in the general case or will be true for PKZIP
2.0 release, I don't know, but that the two archivers are using
different algorithms is a good reason for their performance to differ.

--
Ping Huang (INTERNET: pshuang@athena.mit.edu), probably speaking for himself
From: weiler@chinook.cis.ohio-state.edu (Jerry Weiler)
Newsgroups: comp.os.linux
Subject: Re: XV and Linux Question
Date: 23 Jul 92 17:24:05 GMT
Organization: NAIVE - New And Improved Virtual Environment
Originator: weiler@chinook.cis.ohio-state.edu

In article <14ltk8INNbh2@matt.ksu.ksu.edu> probreak@matt.ksu.ksu.edu (James Michael Chacon) writes:
   Are you using the binary from banjo? I have a feeling the binary was compiled
   with the soft math library, to accomodate everyone and that is the problem
   I pulled down the original sources from gatekeeper.dec.com and have
   a version compiled for the 486/33 on a system just like yours. My version
   has no problem on any function in it, including Color editing. If there is
   enough intrest, I will post it to banjo when the new X and GCC come out.
   If you or anyone else wants, you can just email me and I will send you my
   notes if you just want to compile it yourself.

If he's using the most recent one on banjo (put up about a month ago
by me), then it was compiled and put up as a .a file, so it isn't
linked to any math library. It was compiled with gcc 2.2.2 under linux
0.96b, though. (whatever the highest patchlevel 96b got to, I think)

I have no problem with any of the buttons, either (even in the color
edit), even since I've upgraded to linux 0.96c patchlevel 2

There are notes on the few mods I did to get it to compile in the
README.

- Jerry Weiler
From: bibhas@pico.engr.mun.ca (Bibhas Bhattacharya)
Subject: Graphics library and mouse support in GCC ?
Keywords: Graphics GCC
Organization: Memorial University of Newfoundland
Date: Tue, 28 Jul 1992 01:31:47 GMT

I will be very much interested to know the graphics library and mouse
support with GCC. What could be the equivalent of the QUICK C interrupt
caller function int86() and others.
Any info is most welcome.
Thanks...
Bibhas.
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Termios question: Semantics of VMIN/VTIME on Linux/SunOS ?
Date: 21 Jul 92 18:39:46 GMT
Organization: University of Helsinki

In article <arumble.711729320@extro.ucc.su.OZ.AU> arumble@extro.ucc.su.OZ.AU (Anthony Rumble) writes:
>torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>
>>The way linux does this is (a) wait for at least one character (VMIN > 0
>>and VTIME > 0), (b) read as many characters as possible, with a timeout
>>of max 0.10 seconds between any of the first 5 characters.  Thus the
>>read can return:
>
>Errm.. Question.. Can you think of a possible USE of this?
>It dosen't seem quite logical to do it this way, it would be
>much more usefull to return on either 5 chars OR timeout regardless
>on the first character.. 

Ours is not to wonder why...  Frankly, the above is what the SunOS
man-pages seem to say, and as that's the only info I have on the
subject, that's how linux does things.  SunOS seems to be pretty close
to posix, and following the man-pages has so far worked pretty well.  I
don't know the reasons for the POSIX behaviour, and the man-pages might
be wrong (and I might even have misunderstood), but I'd rather be
conforming to weird standards than have problems porting programs later
on when they expect that behaviour. 

As I already mentioned, I'm very open to changing the behaviour: but I
need to have actual "chapter and verse" from the posix standard before I
start changing things.  The current behaviour works with a lot of
programs, and conforms to the only docs I have, so I really need some
strong arguments to change it. 

The VMIN/VTIME arguments are currently understood by linux as (note:
this info is only used when not in canonical mode):

VTIME = 0 VMIN = 0
	Instant return, reading as many characters as possible from the
	terminal.

VTIME = 0 VMIN > 0
	No timeout, and we return once VMIN characters have been read. 
	We still might return before that in case of signals etc, and if
	there are more characters available, they will be read.

VTIME > 0 VMIN = 0
	This is a simple timeout-read: we wait VTIME*0.1 seconds or
	until at least one character has arrived.  The read will not
	take more than VTIME*0.1 sec, not counting scheduling etc
	overhead. 

VTIME > 0 VMIN > 0
	VTIME*0.1 seconds is an inter-character timer that is started
	after the first character is received, and restarted at each new
	character until VMIN characters have been received.  The read()
	returns at least one character (again not counting signals), as
	the timer comes into play only /between/ characters. 

All the above have an upper limit of the given buffer-size: none have a
true lower limit (as they can return less than VMIN characters).  VMIN
isn't meant to be used for packet-sized communication: it's just used to
help decide when/how to accept timeouts.  Can somebody please confirm if
the above is actually the correct behaviour?

		Linus
Newsgroups: comp.os.linux
From: bjl@loki.pttrnl.nl (Ben Lippolt)
Subject: Re: Extended File System
Reply-To: B.J.Lippolt@research.ptt.nl
Organization: PTT Research
Date: Tue, 21 Jul 1992 19:25:19 GMT

joef@extro.ucc.su.OZ.AU () writes:
>  How about this as a suggestion:

> /dev/hda1 = 20 meg
> /dev/hda2 = 60 meg
> /dev/hda3 = 20 meg
> /dev/hda4 = 20 meg 

>   And set them up this way:

> /dev/hda1 mounted on /
> /dev/hda2 mounted on /usr
> /dev/hda3 mounted on /lib
> /dev/hda4 mounted as swap

Looks a little strange to me, this setup. Why do want a '/' of 20Mb?
And what on earth do you keep in your '/lib'???

My suggestion would be:
/              4 Mb (contains only '/etc' '/lib', '/dev' and your kernel)
/var           6 Mb (contains tmp and spool directories)
/usr          60 Mb 
swap          10 Mb (You won't need 20 Mb, would be unbearable slow anyway)
/home         40 Mb

The reason why it is (IMO) better to keep your root file system small 
and to have a seperate '/var' is "more robustness".  You won't modify
that file system often (the occasional update of the kernel (only twice
a week :-) ) and a few files in /etc), so the chances that you blow it
are smaller. The same holds for '/usr'. If you have a seperate '/var',
that will be the file system with a lot of the frequently updated files.
This setup would enable you almost to mount '/usr' read-only (except for
updates of your programs). 
BTW. This is not something I have invented. It is basically the way SunOS
is set up.


Ben Lippolt.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.os.linux
Subject: Re: LINUX DISK AVAILBLE IN CANADA
Keywords: linux disks available
Date: 27 Jul 92 14:47:56 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <jen.712077777@unixg.ubc.ca>, jen@unixg.ubc.ca (Zhen Yu) writes:

| It seems someone is filling the vacuum for those who want free-unix but have
| no ftp access.
| Comments, anyone?

  I thought of doing this, but decided that someone would probably
complain about profiteering or some such. Getting the stuff onto disk in
the first place is enough hassle to keep people from doing it, so I
think it would be good for linux in general, but people are too
political to make it practical. And someone would probably say that you
have to include the source with the binary rather than make it
available, which drives the price up by the cost of more disks...

  I've had people asking where they can get disks and hardcopy
installation instructions, so there are people out there willing to pay
for convenience.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.
Newsgroups: comp.os.linux
From: callison@uokmax.ecn.uoknor.edu (James P. Callison)
Subject: Re: Newbie Linuxer & misc. Qs (LONG!)
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA
Date: Fri, 31 Jul 1992 09:14:32 GMT

In article <5446@mccuts.uts.mcc.ac.uk> LeBlanc@mcc.ac.uk (A. V. Le Blanc) writes:
>In article <1992Jul26.220519.18078@sura.net> vargish@sura.net (Nick Vargish) writes:
>>4. Mtools sometimes can't initialize my floppies, and sometimes can't
>>   even see them (depending on what random numbers I'm using in
>>   /etc/mtools).
>
>You should have
>     A /dev/fd0 12 0 0 0
>     B /dev/fd1 12 0 0 0
>for the floppy entries in /etc/mtools.

Hmmm. I just left it as
	A /dev/PS0
and did
	ln /dev/fd0 /dev/PS0
and it works just fine for me.

				James

James P. Callison       Microcomputer Coordinator        OU Law Library 
Callison@aardvark.ucs.uoknor.edu   /\        Callison@uokmax.ecn.uoknor
	constellation!biglaw!callison@mailhost.ecn.uoknor.edu
DISCLAIMER: I'm not an engineer, but I play one at work...
	Lawyers get you out'n the kind of trouble you'd never get in 
		if there was no lawyers. -- Cowboy logic
Newsgroups: comp.os.linux
From: unixsys@ssg.com (Rick Emerson)
Subject: Re: LINUX DISK AVAILBLE IN CANADA
Organization: System Support Group
Date: Mon, 27 Jul 1992 03:36:32 GMT

jen@unixg.ubc.ca (Zhen Yu) writes:

> 
> I came across an ad in August issue of Computer Paper (a 100-page, nation-wid
> distributed, free, monthly paper. Circulation in Canada: 185,000). It reads:
> 
> [Ad omitted]
> 
> It seems someone is filling the vacuum for those who want free-unix but have
> no ftp access.
> Comments, anyone?

Yes.  Try accessing ftpmail@decwrl.dec.com for files.  A request addressed
to ftpmail-request@... will get the correct command syntax.  This is not the
best way to go for huge files as uuencoded files come back in 50KB chunks
but if it's this or nothing...

Rick


| Richard B. Emerson     | Replies may be sent to:                         |
| System Support Group   |         unixsys@ssg.com  -or-  rick@ssg.com     |
| Post Office Box 180    |-------------------------------------------------+
| Lansdale, PA 19446 USA |     "If I knew what I was doing,                |
| Voice: 215.855.1607    |      I wouldn't do it." - Me                    |
Newsgroups: comp.os.linux
From: jliddle@rs6000.cmp.ilstu.edu (Jean Liddle)
Subject: Re: Let's all stop to think for a moment....
Date: Thu, 23 Jul 1992 16:51:15 GMT
Organization: Illinois State University

In article <1992Jul23.052209.19339@athena.mit.edu> jgifford@attmail.com writes:
>Just think, we have a FREE unix that is as usable as Coherent, and in many
>installations, doing nearly as good as a sparcstation.

I would say better than Coherent.  We survived the Crashme Test, and we have X!

>We have a wonderful c compiler(c++ too...)
>We have a GREAT X
>we have a lot, for just a years work.

Here here!

>(Now, does anyone think it will run on the alpha?  I hear it reaches as much as
>200MHz!  I think that with the right PALcode, it might even work!...???)

One of the beauties of linux is that, in the long run, we are not tied down
to intel any more.  While portint the OS itself would be a chore (I understand
much of the code is very i386 specific), linux as a standard os (with standard
sys calls, etc.) could probably be made to run just about anywhere.  If it
should become the operating system of choice in the future, we will probably
be much freeer to pick and chose the hardware of our choice (motorola, alpha?)

just some idle thoughts,

Jean.
-- 
Jean Liddle                                 | == Bill Clinton for President ==
Computer Science, Illinois State University | 
e-mail:  jliddle@ilstu.edu                  | - Carol Mosley Braun for Senat -
Newsgroups: comp.os.linux