From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Newsgroups: comp.os.linux
Subject: (none)
Date: 15 Aug 92 03:24:52 GMT
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Organization: The Internet

|From Linux-Activists Fri Aug 14 22:45:24 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 23:16 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
	 id AA03646; Fri, 14 Aug 92 22:55:39 EDT
Received: by bloom-picayune (5.57/25-eef)
	id AA23505; Fri, 14 Aug 92 22:45:57 -0400
Message-Id: <9208150245.AA23505@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 22:45:24 EDT
Subject:  Linux-Activists Digest #651
Content-Type: text
Content-Length: 38592

Linux-Activists Digest #651, Volume #2           Fri, 14 Aug 92 22:45:24 EDT

Contents:
  (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)

----------------------------------------------------------------------------

From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Subject: (none)
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date: Sat, 15 Aug 1992 02:42:46 GMT

|From Linux-Activists Fri Aug 14 22:15:13 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 22:34 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
         id AA01537; Fri, 14 Aug 92 22:27:29 EDT
Received: by bloom-picayune (5.57/25-eef)
        id AA22473; Fri, 14 Aug 92 22:15:20 -0400
Message-Id: <9208150215.AA22473@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 22:15:13 EDT
Subject:  Linux-Activists Digest #647
Content-Type: text
Content-Length: 36814

Linux-Activists Digest #647, Volume #2           Fri, 14 Aug 92 22:15:13 EDT

Contents:
  (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)

============================================================================

From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Subject: (none)
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date: Sat, 15 Aug 1992 02:03:30 GMT

|From Linux-Activists Fri Aug 14 21:30:14 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 21:55 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
         id AA29603; Fri, 14 Aug 92 21:43:58 EDT
Received: by bloom-picayune (5.57/25-eef)
        id AA21176; Fri, 14 Aug 92 21:30:31 -0400
Message-Id: <9208150130.AA21176@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 21:30:14 EDT
Subject:  Linux-Activists Digest #643
Content-Type: text
Content-Length: 35036

Linux-Activists Digest #643, Volume #2           Fri, 14 Aug 92 21:30:14 EDT

Contents:
  (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)

============================================================================

From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Subject: (none)
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date: Sat, 15 Aug 1992 01:26:54 GMT

|From Linux-Activists Fri Aug 14 21:00:17 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 21:18 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
         id AA28466; Fri, 14 Aug 92 21:14:04 EDT
Received: by bloom-picayune (5.57/25-eef)
        id AA20204; Fri, 14 Aug 92 21:00:30 -0400
Message-Id: <9208150100.AA20204@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 21:00:17 EDT
Subject:  Linux-Activists Digest #640
Content-Type: text
Content-Length: 33258

Linux-Activists Digest #640, Volume #2           Fri, 14 Aug 92 21:00:17 EDT

Contents:
  (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)

============================================================================

From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Subject: (none)
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date: Sat, 15 Aug 1992 00:56:56 GMT

|From Linux-Activists Fri Aug 14 20:15:20 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 20:48 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
         id AA27064; Fri, 14 Aug 92 20:37:53 EDT
Received: by bloom-picayune (5.57/25-eef)
        id AA18981; Fri, 14 Aug 92 20:15:36 -0400
Message-Id: <9208150015.AA18981@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 20:15:20 EDT
Subject:  Linux-Activists Digest #637
Content-Type: text
Content-Length: 31480

Linux-Activists Digest #637, Volume #2           Fri, 14 Aug 92 20:15:20 EDT

Contents:
  (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)

============================================================================

From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Subject: (none)
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date: Sat, 15 Aug 1992 00:06:22 GMT

|From Linux-Activists Fri Aug 14 19:00:10 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 19:58 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
         id AA23792; Fri, 14 Aug 92 19:13:30 EDT
Received: by bloom-picayune (5.57/25-eef)
        id AA16951; Fri, 14 Aug 92 19:00:18 -0400
Message-Id: <9208142300.AA16951@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 19:00:10 EDT
Subject:  Linux-Activists Digest #633
Content-Type: text
Content-Length: 29702

Linux-Activists Digest #633, Volume #2           Fri, 14 Aug 92 19:00:10 EDT

Contents:
  Re: The Third Degree (Kevin Cummings)
  64Mb on HD limit? (Christopher Aaron Ekberg)
  Re: Installing Linux w/o destroying existing partitions (Steve Sheldon)
  Re: Modem dial-in procedures needed (Steve M. Robbins)
  (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)

============================================================================

From: cummings@hammer.Prime.COM (Kevin Cummings)
Subject: Re: The Third Degree
Date: Fri, 14 Aug 1992 21:13:54 GMT

In article <pz91Ht-g*8@atlantis.psu.edu>, bairstow@copland.psu.edu (Steven Bairstow) writes:
| My Linux partition just bit the dust, so I'm going to ask for some 
| information before I re-partititon it. (I want usr and swap partitions 
| instead of one big one this time.) Anyway I want responses from anybody 
| who knows about any of this, even if it's just a "yep." Without further 
| ado here are the questions....
| 
|       - Has anyone noticed free inodes being left around? I think 
|         halt/shutdown is doing it. (This is what I was trying to figure 
|         out when it crashed.)
|       - What is the current status of long filenames? Is it a patch?
|         How reliable is it?
|       - Do any of the current disk sets handle SCSI disks well? How about 
|         the partitioning programs?
|       - How big are the X11 binaries plus whatever special stuff is needed 
|         to write X-programs? 
|       - Has anyone ever considered an X driver for plain VGA? Why or why 
|         not make one?
|       - Is anyone interested in a patch that would add a timeout default 
|         to the "Press <RETURN> to see SVGA modes or any other key to 
|         continue." message?

YES INDEED.  I haven't had the time to work on this stuff lately, but a timeout
would definately be useful.  (Especially one with a configurable default, but then
again I haven't looked at 0.97 or 0.97pl1, shame on me).

=================================================================
Kevin J. Cummings                       PrimeService
20 Briarwood Road                       A Computervision Company
Framingham, Mass.                       500 Old Connecticut Path
                                        Framingham, Mass.
Work:  cummings@primerd.Prime.COM
Home:  cummings@kjc386.framingham.ma.us

Std. Disclaimer: "Mr. McKittrick, after careful consideration,
                  I've come to the conclusion that your new
                  defense system SUCKS..."   --  War Games
=================================================================

==============================

From: ce12+@andrew.cmu.edu (Christopher Aaron Ekberg)
Subject: 64Mb on HD limit?
Date: 14 Aug 92 13:15:42 GMT

Hello,

I read someplace that there is (was?) a limit of 64Mb hard disk space
for Linux.  If I didn't just dream that, is that still true for 0.97?  

Thanks,
-Chris

==============================

From: sheldon@iastate.edu (Steve Sheldon)
Subject: Re: Installing Linux w/o destroying existing partitions
Date: Fri, 14 Aug 1992 21:14:39 GMT

In <1992Aug14.193838.16110@nas.nasa.gov> chiu@wk211.nas.nasa.gov (Ing-Tsau Chiu) writes:

|Wonder if there's any way to install Linux w/o destroying existing
|partitions.  (Sorry if this is an faq.)
|--
|--
|Ing-Tsau Chiu                       chiu@nas.nasa.gov

 Sure on floppy disks, silly! :-)

 There is some explanation of this in 'install.notes' written by
I Reid.  Actually it's an appendix towards the end written by
Drew Eckhardt.

 I personally wouldn't recommend it, even though I think I understand
what he's doing.

 Basically it seems to me that it's much more work than it is worth.
I did a complete backup of my harddisk of about 60 Megs of data to
floppy disks(720K no less! as I have hundreds of these), using
CP Backup 6.0.  It takes about 1/2 hour to backup, another 1/2 to
reinstall.
 If you've got more than 100 Megs, definately buy a cheap tape
backup for around $200.

 Basically, it just doesn't seem worth the possible frustration, and
you're going to have to backup the partition anyway.

 Any comments?

-- 
Steve Sheldon         sheldon@iastate.edu
Iowa Cooperative Soil Survey Resource Unit
2142 Agronomy, Iowa State University  (515) 294-5429


==============================

From: steve@Nyongwa.CAM.ORG (Steve M. Robbins)
Subject: Re: Modem dial-in procedures needed
Date: 13 Aug 92 22:16:48 GMT

In article <1992Aug13.052324.8490@athena.mit.edu> chchen@stat.fsu.edu writes:
|I've seen several discussions about modem dial-in for Linux system. I
|got two unsolved questions here:

|1. Is it necessary to get getty_ps program to allow modem dial-in?

No.  Not if you just want to dial in.  Getty_ps is required if you want to also
be able to dial out on the same line (uucp, kermit...).  To my knowledge there
are no other uugetty programs that work.  [uugetty being the version of getty
(included in getty_ps) that uses lockfiles to negotiate with uucp et al. for 
the line]


|2. If I just want to use the getty from MCC-INTERIM or root image (.96 or
|   .97), what steps should I follow?
[..]
|                (2) Without changing the /etc/initab, give the command
|                          echo atq1e0s0=2v1x4 >/dev/ttys1
|                          (no device busy this time)
|                    and then
|                         getty 2400 /dev/ttys1 &
|
|                    This seemed to work but after my friend logout,
|                    his screen went messy (he is also running Linux)

I think this is the way to do it.  But with the getty line in inittab, I
don't think you need to run getty by hand.  You might have to kill off the
old getty and let init restart it, though.  [since atq1 turns off the command 
responses, sending v1x4 is superfluous, isn't it?]

The best way would probably be to put the initializing string (i.e. 'echo
atq1.. >/dev/ttys1) into /etc/rc, so the modem will be set up before init
ever tries running getty on it.

The messy screen is your friend's problem, probably to do with getting noise
after disconnecting.

|                    Also, how to choose terminal type with this
|                    apporach?

The terminal type will be set by init to whatever is on the inittab line.  If
you need to change it after logging in, just do TERM=whatever from BASH's
command line, or login script.

-- 
Steve Robbins  --  steve@nyongwa.cam.org
I asked Hank Williams "how lonely does it get?"
Hank Williams hasn't answered yet.

==============================

From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Subject: (none)
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date: Fri, 14 Aug 1992 22:54:47 GMT

|From Linux-Activists Fri Aug 14 10:00:24 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 18:46 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
         id AA00964; Fri, 14 Aug 92 10:12:33 EDT
Received: by bloom-picayune (5.57/25-eef)
        id AA00427; Fri, 14 Aug 92 10:00:33 -0400
Message-Id: <9208141400.AA00427@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 10:00:24 EDT
Subject:  Linux-Activists Digest #629
Content-Type: text
Content-Length: 21613

Linux-Activists Digest #629, Volume #2           Fri, 14 Aug 92 10:00:24 EDT

Contents:
  Re: XView, olvwm, and OLIT (Scott Dunn)
  Re: Linux logo (Joost Helberg)
  Re: Troubles compiling lilo v3 (Joost Helberg)
  tlA: reggae's Incoming dir must be chmod ugo+x... (Tero Laakkonen)
  Re: loadable device drivers (Joost Helberg)
  Dial-in and kill -HUP 1 (Ching-Hsiang Chen)
  Re: Schedules (Mark Komarinski)
  Where can I get linux-logo.gif or GhostScript(for Linux)? (Rick Miller)
  Re: Stabilizing Linux (Juhana Kouhia)
  X11 and the joys of modes (Julien Maisonneuve)
  Re: Stabilizing Linux (william E Davidsen)
  How safe is Mtools? (Robert W. Bingler)
  Re: Buffer corruption problems. (Scott A. Taylor)
  Re: Stabilizing linux (william E Davidsen)

============================================================================

From: scottd@cs.hw.ac.uk (Scott Dunn)
Subject: Re: XView, olvwm, and OLIT
Date: 13 Aug 92 14:21:41 GMT

I am also looking for xview.  I do have the source and when gcc2.2.2d is
released I am going to attempt to make it.  Assuming, that is, that noone
has already done it.

When will gcc2.2.2d be released?

Also, gwm, where can I find it?
And when I do find it, how do I compile the lisp files?  
Having looked at it at uni, it seemed rather slow, but that was 
probably largely down to the fact that all the lisp files were
not compiled.

Scott.

==============================

From: jhelberg@nl.oracle.com (Joost Helberg)
Subject: Re: Linux logo
Date: 14 Aug 92 08:59:30 GMT

X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

welshm@snail.rtp.dg.com (Matt Welsh) writes:
: I got the newest version (EPS) of the linux logo direct from
: the artist, and my previewers (Ghostview and GS) both barf on
: it, with the errors:
: 
: Error: /undefined in !
Right, I notified James.

10 minutes of hacking however solves your problem too!

--
   Joost Helberg                                Rijnzathe 6
   jhelberg@oracle.nl                           NL-3454 PV De Meern
   jhelberg@nl.oracle.com                       The Netherlands

   Oracle Europe BV                             Product Line Development        
   Phone: +31 3406 94211                        Fax:   +31 3406 65609

==============================

From: jhelberg@nl.oracle.com (Joost Helberg)
Subject: Re: Troubles compiling lilo v3
Date: 14 Aug 92 09:05:35 GMT

X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

newbie@dylan.camb.inmet.com (Chris Newbold) writes:
: The problems: Both /usr/src/linux/include/linux/types.h and /usr/include/sys
: /types.h get included. I tried to fix this by linking /usr/include/sys
: to /usr/src/linux/include/linux. This seems like a hack, but I don't really
: know. Didn't reall help.
Added #define _LINUX_TYPES_H to /usr/include/sys/types.h
and   #define _SYS_TYPES_H   to /usr/include/linux/types.h

That makes them mutualy exclusive.



--
   Joost Helberg                                Rijnzathe 6
   jhelberg@oracle.nl                           NL-3454 PV De Meern
   jhelberg@nl.oracle.com                       The Netherlands

   Oracle Europe BV                             Product Line Development        
   Phone: +31 3406 94211                        Fax:   +31 3406 65609

==============================

From: laakkone@klaava.Helsinki.FI (Tero Laakkonen)
Subject: tlA: reggae's Incoming dir must be chmod ugo+x...
Date: 14 Aug 92 10:25:32 GMT

... so that people can cd into it.

-tero.

==============================

From: jhelberg@nl.oracle.com (Joost Helberg)
Subject: Re: loadable device drivers
Date: 14 Aug 92 10:49:47 GMT

X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes:
: In article <2659@nlsun1.oracle.nl> jhelberg@nl.oracle.com (Joost Helberg) writes:

[deleted]
: > The kernel must be mapped when implementing loadable device drivers (to
: > get page-faults) so the kernel doesn't need contiguous memory --> less
: > problems allocating memory.
: 
: Page-faults are deadly for most parts of the kernel. Unless the interrupt
: handling is changed in radical ways (see below), you don't want interrupt
: handlers and code that's called by them to reside in paged memory. (Besides
: the obvious case of device drivers that may be possibly invoked when
: handling a page fault.)
: 
: Using the paging hardware to map kernel pages is a good idea, though.
: 
: > - The kernel will never use more core than necessary. Only text/data really
: >  used will be in core (that is using LRU algorithms). 
: 
: Yes, but you need interrupt queues and an interrupt scheduler to be able
: to accept interrupts from devices that can send more than one interrupt
: per interaction (i.e. SIOs) even if you have to fault in the driver first.
: Might be hairy to implement, although it looks like a very elegant
: solution for most interrupt problems.
: 
: You also need a way to lock certain kernel areas in physical memory.
: (MM, at least one FS, scheduler, hd driver, some other kernel data
: structures, drivers for devices that expect a low interrupt latency, etc.)
:  

You're right about all this; my idea came from the time I developed
streams drivers and streams drivers only. These can very easy be made
pageable in the sense that streams-modules/drivers get scheduled by the
scheduler as if they are user-processes. You can swap them if you want!

[deleted]

I think it is not a good idea to implement any driver as a loadable driver,
but with a new driver-interface (like STREAMS is) it is easy to implement,
without too much problems.

One could even implement a seperate driver-space (analog to user-space, with
its own mmu-tables) for each streams-driver instance, bus-errors etc. result
in core dumps in stead of terminal-dumbs!

I think (before STREAMS are implemented) that we should invest in defining
a configurable driver-interface for Linux, discussion in mailing-list 
'configuration' at niksula.hut.fi or on the news.

Any comment?

--
   Joost Helberg                                Rijnzathe 6
   jhelberg@oracle.nl                           NL-3454 PV De Meern
   jhelberg@nl.oracle.com                       The Netherlands

   Oracle Europe BV                             Product Line Development        
   Phone: +31 3406 94211                        Fax:   +31 3406 65609

==============================

From: Ching-Hsiang Chen <chchen@stat.fsu.edu>
Subject: Dial-in and kill -HUP 1
Reply-To: chchen@stat.fsu.edu
Date: Fri, 14 Aug 1992 11:46:59 GMT


 Thanks to those who were so kind to help me in modem dial-in
problem. Since the getty_ps program needs M4 to compile the
manual pages and I am so lazy, I adopt the original getty
approach. I created the following 4 files to make things easy.
To allow remote dial-in, I just give the command 'dialin' and
to restore the modem and/or to allow dial-out, I use 'dialout'.
One small problem is that the 'init' and 'kill' from MCC-INTERIM
0.96 root disk can not work together to allow 'kill -HUP 1'
to kill the spawned getty. I need to retype 'kill -HUP 1'
several times or to kill the process by its job ID in order
to make it disapper under 'ps gu'. Any idea?

Steve Chen              chchen@stat.fsu.edu

   file name 'dialin' (put in /root/bin )
=========================== cut here =================
#! /bin/sh
cp /etc/inittab1 /etc/inittab
echo ate0s0=2 >> /dev/ttys1
kill -HUP 1
=========================== cut here =================

   file name 'dialout' (put in /root/bin )

=========================== cut here =================
#! /bin/sh
cp /etc/inittab0 /etc/inittab
echo ate1s0=0 >> /dev/ttys1
kill -HUP 1
=========================== cut here =================

    file name 'inittab0'  (put in /etc)

=========================== cut here =================
tty1:console:/bin/getty 9600 tty1
tty2:console:/bin/getty 9600 tty2
tty3:console:/bin/getty 9600 tty3
tty4:console:/bin/getty 9600 tty4
=========================== cut here =================

    file name 'inittab1'  (put in /etc)

=========================== cut here =================
tty1:console:/bin/getty 9600 tty1
tty2:console:/bin/getty 9600 tty2
tty3:console:/bin/getty 9600 tty3
tty4:console:/bin/getty 9600 tty4
ttys1:vt100:/bin/getty 2400 ttys1

==============================

From: Mark Komarinski <komarimf@craft.camp.clarkson.edu>
Subject: Re: Schedules
Reply-To: komarimf@craft.camp.clarkson.edu
Date: Fri, 14 Aug 1992 12:30:19 GMT

On Aug 13,  2:35am, Rick Sladkey wrote:
| A rule that I picked up from somewhere is quite useful in such situations.
| 
|         "Bump up to the next unit of measurement and muliply by two."
| 
| So when you hear a schedule like:               Expect:
| 
|         1 hour                                  2 days
| 
|         2 days                                  4 weeks
| 
|         1 month                                 2 years
| 
| Sad, but often true.

So how long is Real Soon Now? :) (That is about when SLIP will come to 
Clarkson...grr..)

-Mark

-- 
- Mark Komarinski - komarimf@craft.camp.clarkson.edu
[MIME mail welcome]
The only candidate worth voting for is Bill the Cat.  He might not
do good, but that's never been a requirement.

==============================

From: rick@ee.ee.uwm.edu (Rick Miller)
Subject: Where can I get linux-logo.gif or GhostScript(for Linux)?
Date: Fri, 14 Aug 1992 12:22:26 GMT

I'd love to see the Linux Logo... but I get "Permission Denied"
when I try to "get linux-logo.gif" from tsx-11:/incoming.

Where and how can I get this file???

I don't have a PostScript printer, so GhostScript will probably come
in handy in the future as well... where can I get it for Linux (or DOS)?

Rick Miller   <rick@ee.uwm.edu> | <rick@discus.mil.wi.us>

==============================

From: jk87377@cc.tut.fi (Juhana Kouhia)
Subject: Re: Stabilizing Linux
Date: 14 Aug 92 12:21:04 GMT



Well, I have no much experiences in software system engineering and I
don't know about the heart of Linux, but I suggest:

1. All common sources for the various different Linuxes are checked
to a master version.

2. Those features which are in one Linux only is directly copied to
master version; if this is not possible to do directly, people
rewrite them.

3. Those features which overlaps in Linuxes is added to master version
either by switches or choosing best one or writing a compromise.


About 1: I don't know what different program parts (modules)
there are and how they communicates together.
It could help to organize if those parts (or program modules) are
listen down -- at least if I have to organize Linux again, I would
like to write a list (or program tree) about what is there.
Then it could be easier to check where programs overlaps
and helps to design more modular system.


By these differences I don't mean different versions of GNU emacs or
zoo or such  :-)


Actually, does somebody know what features are different in the
different Linux releases (MCC, etc.)?
We could list only those in the first place.


As I said I'm not experienced software developer, so no flames,
instead an educating critisms, which I have allready read from this
group, are welcome.


Juhana Kouhia

==============================

From: julien@incal.inria.fr (Julien Maisonneuve)
Subject: X11 and the joys of modes
Date: 14 Aug 92 12:01:24 GMT

OK, I grabbed X11 a bit late, but I just received a new video board (pvga based)
to replace my trident.

My problem is that I can't get my monitor to sync properly using the modes I
found in Xconfig and vga.dbase. Horizontally, things look right, but vertically,
I get flying superimposed pictures (Color is OK though :-). I can see xclock
jumping a bit (two superimposed pictures) but can't do any better.
The (numerous) changes I could make in the mode settings didn't do much, and the
mode I made using the video.tutorial doesn't seem to handle things better than
the others (not much worse either). Despite the tutorial, I figured out what the
mode values meant, but I can't find the proper values.

The clocks.exe reports only four clocks for my vga (something like 25 29 65 36)
and X11 does NOT find the same at all when I leave the clocks line out (reports 8
lower values, max is at 40). I try to use 65 (large values intuitively suggest
better resolution...).

My SVGA board & monitor can do a neat 1024x768x256 non interlaced picture under
DOS. Isn't it possible to write a DOS program that reads the vga registers in a
given mode (this very one) and tell the appropriate video timings ? That would
help a great deal the poor X11 installers with uncommon hardware.

That kind of help message seems to have disappeared from c.o.l, so most people
have likely solved the problem: I couldn't, someone please HELP !!!

Usual praises & kudos about Linux and X11...
-- 
  _________                    Julien.Maisonneuve@inria.fr  julien@sor.inria.fr
      /                 _ _ _                     ...!uunet!inria!corto!julien
     /     /)          ' ) ) )                    INRIA :  33 (1) 39 63 52 08
  __/_    // o _  __    / / / _   o _   _   __   __   _      _     _
 / / (_(_(/_(_(<_/) )  / ' (_(_(_(_/_)_(_)_/) )_/) )_(<_(_(_( \_)-(<_
(_/

==============================

From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Subject: Re: Stabilizing Linux
Date: 14 Aug 92 13:22:32 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)

In article <1992Aug13.195406.23296@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
| In article <1992Aug13.133313.15221@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
| >In article <1992Aug12.173012.17552@colorado.edu>, drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes:
| >
| >And the person trying to install on a new machine can't rebuild the
| >kernel, so s/he needs another working system to get going. Bleh.
| >Relocation at load time might take 1-2 sec of cpu. Big deal. Without
| >loadable device drivers you must have a working system to generate a new
| >kernel.
| 
| Most Unices distribute the distribution kernel as a generic kernel,
| ie one with support for all device drivers compiled in.  It gets a little
| bloated, but if you can boot it, you can run anything.

  Sounds to me like you think the Linux kernel as distributed contains
all the devices anyone would ever want to use, so there's no need for
being able to support new devices.

  It also sounds like you're trying to say that you think it's too
hard, and you personally don't need it, so you want to convince
everyone it's a bad idea.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.

==============================

From: rwb@Turing.ORG (Robert W. Bingler)
Subject: How safe is Mtools?
Date: Fri, 14 Aug 1992 12:50:03 GMT

Hey,
        Can anyone tell me just how safe it is to use mtools on my 130 meg
dos partition?  I don't want to have to go the expensense of messing it
up.  I have been hesitant in the past, so I just use a floppy.  It would
make things much easier if there is no real chance of damage being done.

Thanks,
Rob

+--------------------------+----------------------+--------------------------+
|   o    \ /  <o>    o     |  Robert Bingler      |  .sig Virus Disenfector  |
| _/|-'   |    |   _/|-'   |->rwb@turing.org      |                          |
|  / \,  /o\  / \   / \,   |  dwb4h@virginia.edu  |  To envoke type:         |
| `                `       |                      |  rm .sig                 |
+--------------------------+----------------------+--------------------------+

==============================

From: scott@natinst.com (Scott A. Taylor)
Subject: Re: Buffer corruption problems.
Date: Fri, 14 Aug 1992 13:31:32 GMT

In article <CORYWEST.92Aug13180939@rio-grande.rice.edu> corywest@rice.edu (Cory West) writes:
|In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> 
|burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
|
|>  ...I believe there is a bug in Linux that has the following behavior:
|>
|>  -  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
|>     so that what your app ends up with is some _other_ 1024KB chunk
|>     (apparently from the same file)
|>
|>  -  occurs only during very heavy disk access, such as megabytes accessed
|>     continually
|>
|>  -  is intermittent, but happens enough to reproduce fairly easily
|[Etc...]
|
|       I have noticed some abnormalities, but I have been writing them
|off to a disk block in the process of going bad.  Here's what I have
|noticed:
|
|       - Under heavy and prolonged disk I/O (in this example, while compiling
|gdb from scratch) there seem to be problems with the buffer cache.  After 
|compiling for a while, gcc will choke with a TON of strange errors and die.
|However, if I just restart make, the compiler will continue successfully
|with the file that it had just died on, but it will die a little later 
|down the line (after some more intensive I/O) under the same circumstances.
|After a couple of tries, I can usually get through the entire make.
|
|       - I am running on MFM drives on a 486-33 with 4 Megs RAM (gcc 2.2.2d and
|gcc 2.2.2 and Linux 0.97 PL1), so while compiling large things, my disks never 
|stop to breath, especially if I am trying to do something else while the compile 
|is running.
|
|       - The errors always include the same file (which is why I thought
|perhaps that that particular file was living on a disk block that was going
|belly up.  I plan to rename that file to .deadblock and putting a new copy
|of the file in the directory to test this theory).  I am also going to run some
|more large compiles to see if I can reproduce this error elsewhere in the 
|system.
|
|       I don't know what it is yet, and I'm not sure if it's anything, but
|I'll see what I can reproduce and hopefully we can determine if this is an
|OS bug or a hardware bug and whether or not it has anything to do at all with
|the above problem.
|
|       Anyone else out there having problems?
|
|
|
|                                       Cory West
|                                       corywest@rice.edu

I am running 0.96c pl2 with the latest SCSI drivers from woz.headrest.colorado.
edu, and I have not had any problems like this, even under heavy load (i.e.
building a new kernel in one VC while compiling groff, GNU file utils, text
utils, etc. in another).  I have 8 megs of RAM and an UltraStor 14F w/ 213 MB 
Maxtor disk in a 386-25 with no cache. I do not have swapping enabled.  Maybe 
this problem is paging- or cache-related?

I have used (and abused ;-) ) linux pretty heavily in the past, and it has
been solid as a rock (Thanks Linus and everyone else involved!).
-- 
Scott Taylor            |
(512) 795-6837          | "Well, I wanted to work with gymnasts." -David Byrne
scott@natinst.com       |
** NI pays me to write their code, not their opinions, and that's what I do **

==============================

From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Subject: Re: Stabilizing linux
Date: 14 Aug 92 13:32:17 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)

In article <1992Aug13.200750.1247@athena.mit.edu>, komarimf@craft.camp.clarkson.edu (Mark Komarinski) writes:

| Why not have both?  Whipping up some on-line manuals that can be printed
| or viewed should not be that much trouble, and everyone will benefit in the
| end.

  I think you should be the one to do it, then. I've written 40-50 page
user manuals, and many programs of that size, and I can tell you that a
quality manual takes about 2x longer, per page, than code. That insuring
that the notation is consistent end to end, the style is uniform (chatty
or dry, but consistent), that every fact is correct, exceptions are
noted (this works with 0.96a and 0.96b, but not later versions), and
that there are clear examples for all sections which a user could
possibly misunderstand.

  My recent experience with asking for the location of docs rather than
useful hints was revealing; on two questions I got a total of 31 answers
(Linux people are the nicest on the net!), but I got 30 "I don't have
docs, but this worked for me," and one "thaere's a doc on tsx... but
it's not very clear, this is what I think it means." So I now have a few
more lines of notes in my KWS notes file, but no new docs.

  This could really be a huge job, you've been warned.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.

==============================


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux) via:

    Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi                                pub/OS/Linux
    tsx-11.mit.edu                              pub/linux
    tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

End of Linux-Activists Digest
******************************

==============================


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux) via:

    Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi                                pub/OS/Linux
    tsx-11.mit.edu                              pub/linux
    tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

End of Linux-Activists Digest
******************************

==============================


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux) via:

    Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi                                pub/OS/Linux
    tsx-11.mit.edu                              pub/linux
    tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

End of Linux-Activists Digest
******************************

==============================


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux) via:

    Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi                                pub/OS/Linux
    tsx-11.mit.edu                              pub/linux
    tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

End of Linux-Activists Digest
******************************

==============================


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux) via:

    Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi                                pub/OS/Linux
    tsx-11.mit.edu                              pub/linux
    tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

End of Linux-Activists Digest
******************************

==============================


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux) via:

    Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi                                pub/OS/Linux
    tsx-11.mit.edu                              pub/linux
    tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

End of Linux-Activists Digest
******************************

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux) via:

    Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    tupac-amaru.informatik.rwth-aachen.de	pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

End of Linux-Activists Digest
******************************
Newsgroups: comp.os.linux