Files
2024-02-19 00:23:35 -05:00

537 lines
24 KiB
Plaintext

From: Digestifier <Linux-Activists-Request@news-digests.mit.edu>
To: Linux-Activists@news-digests.mit.edu
Reply-To: Linux-Activists@news-digests.mit.edu
Date: Thu, 26 Mar 92 16:00:12 EST
Subject: Linux-Activists Digest #162
Linux-Activists Digest #162, Volume #1 Thu, 26 Mar 92 16:00:12 EST
Contents:
How do I adjust HD-Timeout? (Bernd Ebach)
comp.os.linux (Chuck Boyer)
I'm impressed! (Joseph Knapka)
(none) (GSTD@VTVM2.CC.VT.EDU)
Re: Naming /dev/tty* (Jeff Hollingsworth)
Re: Linux-Activists Digest #159 (Scott Beckstead)
Re: Linux in the spirit of the GNU General Public Liscense? (Craig Burley)
Re: Free BSD release: future of Minix/Linux? (Charles M. Hamilton)
fwrite bug (Greg Lee)
Re: INSTALLATION (FILETRANSFER) tar (picone@ucbeh.san.uc.edu)
Re: Naming /dev/tty* (Kevin Cummings)
Re: More and more questions. :) (Charles Hedrick)
----------------------------------------------------------------------------
From: s_ebach@wega.rz.uni-ulm.de (Bernd Ebach)
Subject: How do I adjust HD-Timeout?
Date: 26 Mar 92 16:29:12 GMT
Hello LINUXer,
I'm no kernel-guru, but I have a serious kernel-problem.
I run Linux on my NoteBook, which has hardwired spindown
of the HD after some period of time. When spinning-up
again the kernel timeouts and system hangs. I had no
problems with version 0.11 so I think it must be possible
to adjust the timeout so that it doesn't timeout that
fast. (Spinning up takes about 1.5-2 seconds).
Since I'm no kernel-guru (as stated before) I dont't
no where in the kernel-source the timout-values might
be distributed.
Someone knows where to search 4 those?
BTW: reCompiling the source and building a bootable
disk is NOT the problem.
TschauTschau
Bernd
--
-----------------------------------------------
Bernd Ebach, try s_ebach@rzmain.rz.uni-ulm.de
-----------------------------------------------
------------------------------
From: boyer@sumax.seattleu.edu (Chuck Boyer)
Subject: comp.os.linux
Date: 26 Mar 92 16:58:05 GMT
I have x2 Western Digital IDE hard drives, hard drive #2 (drive1 by
unix terminology standards) I 'had' /dev/hdb1 33M, /dev/hdb2 8M
last night. (DOS 5.0 fdisk'd and formatted under DOS). (I had played
around with DOS, edpart.exe, with it's 32Mb limits, pfdisk, actually
feeding it with 'g 782 4 27' the correct parameters for my disks'
parameters..., but couldn't get it to work with Linux mkfs until I
did the partitions from within DOS 5.0...ugh!!!).
Everything was fine until I used mtools (athos.rutgers.edu) to mcopy
2gcclib.tar.Z (large, 1.4M file) over to a subdirectory on my
Linux partition (33M /dev/hdb1) and halfway through it gave an
error of no more disk space left. I issued a 'df' right away and
found that it reported the mounted root partition only had 8M
and it was 'all' used up... heh. I immediately backed up onto floppies
everything and got out to DOS. Partitions were still reported okay...
Anyway, I repartitioned my hard drive to 1) less than 32M (29M),
2) 2Mb, 3) 8Mb for the swap space..... I hope to have no other
problems with things being larger than 32Mb as half of the programs
available that people are suggesting to use don't recognize them,
and to avoid extended partitions.....
Wish me luck.
boyer@sumax.seattleu.edu
------------------------------
From: knapka@athena.cs.uga.edu (Joseph Knapka)
Subject: I'm impressed!
Date: 26 Mar 92 17:12:31 GMT
Good day, all..
I've been trying to get Linux up on my 486 to the point that I could
run the fairly demanding genetic-algorithm jobs I'm working on for my
thesis. I ditched Coherent because its small-model compiler couldn't
handle the sizes of the data structures involved. So today I *finally*
got everything working (reasonably) well, and managed to compile the
GA --- and boy, was it worth it! Same machine, same exact code --- but
compiled under linux with gcc-1.40, it runs *at least* three times
faster, even with a fairly intense kermit session on another pty! WOW!
Joseph
------------------------------
From: GSTD@VTVM2.CC.VT.EDU
Subject: (none)
Reply-To: GSTD@VTVM2.CC.VT.EDU
Date: Thu, 26 Mar 1992 17:54:47 GMT
:programming guide for the Linux environment
personally, i like "The Unix Programming Environment" by Kernighan
and Pike (1984).
------------------------------
From: hollings@cs.wisc.edu (Jeff Hollingsworth)
Subject: Re: Naming /dev/tty*
Date: Thu, 26 Mar 1992 17:12:50 GMT
In article <lhajr!_@lynx.unm.edu>, techs@triton.unm.edu (Erik Fichtner) writes:
|> In article <31332@darkstar.ucsc.edu> hermit@ucscb.UCSC.EDU writes:
|> >
|> >I'm personally in favor of the SCO XENIX (/UNIX?) standard of naming
|> >console screens as tty01, tty02,..., tty12; direct-connect terminals as
|> >tty1a, tty1b, tty2a; serial-connect terminals as tty1A, tty1B, tty2A
|> >(where the number represents the physical card and the letter represents
|> >the port on that card. For normal 2-ports-per-serial-card, this means
|> >that COM1 and COM2 are tty1a and tty1b, and COM3 and COM4 are tty2a and
|> >tty2b. For a multi-port serial card this means that you have tty1a
|> >through tty1h.); pseudo-terminals are ttyp0-ttypf, ttyq0-ttyqf, etc.
|> >--
|>
|> Well, from my experiences with various flavors of Unix, i've grown to
|> like my own naming scheme. (Everyone's gotta have their own). I use these
|> whenever I build device names.
|> tty01, tty02,...,ttyXX for consoles, local terminals, and the like.
|> (I.E. Anything thats directly connected to the system)
|> ttyM01, ttyM02, ...ttyMXX for modems, remote terminals, etc, and so forth.
|> ttyP01, ttyP02,...ttyPXX for psuedo-terminals (or pty01, pty02...)
|> ttyL01, ttyL02,...ttyLXX for printers and other ouput devices.
|>
|> I'm odd.. I don't want the device name to tell me what it refers to in the
|> hardware; I only need to know that during installation. I want the device
|> names to tell me what the device is DOING for me.
|>
|>
I like having it both ways. I set up the ttys by card and line similar to
/dev/ttya1.., but then create a hard link by function (e.g. /dev/modem,
/dev/printer, /dev/x10, /dev/mouse). This way applications can use things
like /dev/mouse and find it where is currently located, and I can also find all
of the devices in order for testing/debugging. The power of UNIX is the
filesystem, use it!
===============================================================================
Jeff Hollingsworth Work: (608) 262-6617
Internet: hollings@cs.wisc.edu Home: (608) 256-4839
X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>
Home: hollings@warthog.madison.wi.us
------------------------------
From: harvard!ames!amdcad!yarc!scott@EDDIE.MIT.EDU (Scott Beckstead)
Subject: Re: Linux-Activists Digest #159
Reply-To: harvard!ames!amdcad!yarc!scott@EDDIE.MIT.EDU (Scott Beckstead)
Date: Thu, 26 Mar 1992 18:21:41 GMT
I have asked our hardware engineers about the DTK problem and it seems that
power distribution on the board is less than optimal. At higher clock rates
or with a number of add-on cards installed or both the 5 volts on the mother
board is closr to 3 or 4 volts. Some systems and cards can handle this but
most can't. So a good work around is to not have very many add-on cards.
heat also makes the problem worse so if your case is badly ventilated you
will see the problem more. Hope that this helps the cause [.
Scott
------------------------------
From: burley@wombat.gnu.ai.mit.edu (Craig Burley)
Subject: Re: Linux in the spirit of the GNU General Public Liscense?
Date: 26 Mar 92 18:29:28 GMT
In article <24192.9203251845@thor.cf.ac.uk> spedpr@thor.cf.ac.uk (Paul Richards) writes:
I think the harsh words of those who are against your aims are due to
their reluctance to spend all their extra hours working on Linux, while
you get rich and they stay poor. Remember, many of those working on
linux are doing so because they can't afford to spend money on software
i.e. they are NOT rich.
Yes, and please nobody go off and make any money making Linux usable
for non-hackers, because doing so will make Linux so popular that those of
us who wish to remain poor hackers with expertise on Linux internals won't
be tempted to service the growing base of Linux users. And doing so will
result in funding for making improvements to Linux that we'd all rather spend
our valuable but un-paid time doing ourselves.
Really, this whole thing is silly. Someone setting up a company to distribute
and service Linux is _not_ doing so "on the backs of other people's labor",
that's entirely the _point_ of the GPL.
Put another way, after spending over 2.5 years doing _volunteer_ work creating
a free (GPL-protected) Fortran compiler (it's nearly ready for alpha -- I
just need a machine!), I have _no_ problem with companies like Cygnus coming
along and making money off distributing and servicing it. In fact, without
such companies, I could pretty much write off any expectation of my Fortran
compiler becoming widely accepted and widely used, and hence allowing me to,
if I choose, service and enhance it myself for a fee, or giving me good reason
to do so for free. Without Cygnus and the kind of company the original
poster described, things like GNU software and Linux simply _cannot_
penetrate certain markets and companies due to their own rules about not
using software that doesn't have committed, paid-for support in some form.
And when people are literally standing around wanting to give you money so
you can support _free_ software for them -- software you already pretty much
understand, want to learn better, and _want_ to support anyway -- it's
hard (and perhaps silly) to say no unless you feel you have better things to
do with your life.
Finally, because most or all of the software involved is GPL-protected, we
can _all_ share in the benefits of such companies. It is better to have
someone support Linux for a fee, meaning we'll have access to all their
improvements in the versions of Linux they release to their supported
customers, than to have others support _either_ a PD UNIX (where they make
proprietary changes) or a proprietary UNIX (where we never see the source
code in the first place).
Put another way, when a customer wants to spend $100,000 in a year to
improve _some_ version of UNIX so it does things the customer needs (like
run X, perhaps, or run page-layout software we might all like having), that
customer has several choices:
1. License a proprietary UNIX w/source, hire talent to do the work.
2. Grab a PD UNIX w/source, hire talent to do the work.
3. Grab a GPL-protected UNIX w/source, hire talent to do the work.
Now, options 1 and 2, however they're done, are likely to result in the
wonderful improvements _not_ benefitting the rest of us, because source code
for the improvements won't be released.
Option 3 results in _all_ of us having access to the source code for the
improvements (unless the customer hires someone to do the work as for-hire
work and never distributes the results or derivatives of the results -- not
the case when companies like Cygnus do the work).
So option 3 is the best option given the existence of such a customer.
Now, do you _really_ want to bad-mouth anyone willing to start up a business
that covers option 3? Because as long as you do, and as long as such
behavior prevents people from supporting Linux for a fee, customers with
lots of money will _have_ to choose options 1 or 2 -- and we'll see no
benefit from that.
And, in particular, "poor hackers" who know the internals of Linux will have
a much harder time getting contract or full-time work supporting customers
who have chosen options 1 and 2 than those who have chosen option 3, or
snarfed copies of the results of some other customer who paid for option 3,
or whatever.
Welcome to the world of Free Software (as in GPL-protected). There's lots of
money to be made. There's lots of room for volunteer work (as I've done so
far). But, unlike most previous models for software licensing or public
domain, this model allows the greatest exercise of revenue production with
the lowest-permissible impact on the volunteer work.
So, there's no reason to resent or be upset about people profitting off your
work on Linux in one way or another. That can't really hurt you, except
insofar as it represents competition if _you're_ trying to profit off your
own work. And it sure can help you, as I've described above.
Right now I _wish_ there was some organization like the one proposed that
supported Linux for paying customers. Then I'd have more hope of either
getting the machine configuration I want to buy to run Linux or getting
support for doing the necessary work voluntarily (like access to scopes or
whatever is needed to write drivers, or access to possibly expensive
technical documents describing device interfaces). Instead, without Cygnus
supporting Linux and without some other company supporting it, I have to
assume that, since I have (or will have after I buy the machine) virtually
no spending money, I'll have to creep through building drivers and suchlike
myself, something I'm only vaguely looking forward to right now.
And, if you're interested in my experiences with GNU Fortran, in the 2.5
years I've been working on it, far-and-away the _best_ support I've received
on the project has been from Cygnus Support -- definitely not the FSF.
(Remember this is Fortran. Hardly anybody in the free-software world cares
about Fortran at the moment, though that will change.) If it wasn't for my
taking a contract to have access to a UNIX workstation for a while and for
Cygnus either getting me some money or giving me a few weeks access to one
of their machines (including free parking in Cambridge during that time),
my compiler would be over six months away from alpha test, instead of ready
for internal testing (for which I still need a machine).
So let's _encourage_ those who want to start for-profit service organizations
for Linux. The worst that can happen is _they_ lose _their_ shirts! And
as long as they have any half-baked business sense, we won't even have to
hassle them to fund our work -- _they'll_ come to _us_ to make improvements,
especially the long-term ones, to ensure continued interest in (and demand
for) _their_ services from customers.
--
James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
------------------------------
From: chamil@mcs213i.cs.umr.edu (Charles M. Hamilton)
Crossposted-To: comp.os.minix
Subject: Re: Free BSD release: future of Minix/Linux?
Date: 19 Mar 92 07:36:11 GMT
In article <1992Mar18.030152.14554@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>
>Now that a fully bootable, free BSD Unix for '386 and '486 boxespis
>available from agate.berkeley.edu (pub/386BSD), how will Minix and
>Linux fare? I am stuck with Minix, because I use a 68000-based
>machine, but I wonder whether many Intel users will stay with Minix or
>Linux?
>
>
>David
I personally plan on sticking with linux and NOT going to the
free release of 386BSD. Why? Well, my machine now only
has 4 megs of RAM, which seems to be fine for linux, but I
suspect would crowd BSD. Ipalso currently only have 80 megs
of disk space, 40 of which I devote to linux and 40 to DOS.
(I would throw DOS out completely, but I have too much invested
in software for it to diiregard it completely). 40 megs
should be sufficient, approaching comfortable, for linux.
If you tell 386BSD unix you only have 40 megs available for
it, it will just laugh at you. Also, DOS and 386BSD cannot
co-exist on the same machine (yet).
Just wanted to get my $0.02 worth in. Keep up the good work
Linus, I'll stay with you!
-- Charles M. Hamilton
-- University of Missouri - Rolla
-- Computer Science
-- chamil@cs.umr.edu
-- (lifesucks@umr.everyday)
------------------------------
From: lee@uhunix.uhcc.Hawaii.Edu (Greg Lee)
Subject: fwrite bug
Date: 26 Mar 92 18:17:18 GMT
The program below should create a file with the single
byte 255, but instead the file created is of length 0.
gcc 2.0, library: lib92.03.25
==========test.c============
#include <stdio.h>
main()
{ FILE *fd;
char buf[80];
fd = fopen("dummy", "w");
buf[0] = 255;
fwrite(buf, 1, 1, fd);
fclose(fd);
}
--
Greg Lee <lee@uhunix.uhcc.hawaii.edu>
------------------------------
From: picone@ucbeh.san.uc.edu
Subject: Re: INSTALLATION (FILETRANSFER) tar
Date: 26 Mar 92 15:27:52 EST
In article <1992Mar24.132916@hammer.Prime.COM>, cummings@hammer.Prime.COM (Kevin Cummings) writes:
> In article <1992Mar23.212455.19686@athena.mit.edu>, "23-MAR-1992 22:24:24.81" <nmp08@rz.uni-kiel.dbp.de> writes:
>> writing an image of an file (ie. kermit.z) with rawrite under dos5:
>> rawrite
>> source: kermit.z
>> destination: a
>> booting Linux:
>> mount /dev/PS0 /mnt
>> -> mount: error 16
>>
> Step one, uncompress kermit.tar.Z into kermit.tar. If you are
Not necessary, tar can read compressed files directly with the z option
>
> Step two, use rawrite.exe to write out kermit.tar to the floppy disk.
>
> Step three, under LINUX, attach to the directory you want to untar
> the file into.
>
> Step four, "tar xf /dev/PS0". This will extract all entries from
tar zxf /dev/PS0
or
tar zxvf /dev/PS0
--
Humberto Ortiz-Zuazaga
zuazaga@ucunux.san.uc.edu - My _other_ account is on the Internet.
------------------------------
From: cummings@hammer.Prime.COM (Kevin Cummings)
Subject: Re: Naming /dev/tty*
Date: Thu, 26 Mar 1992 20:05:24 GMT
In article <31332@darkstar.ucsc.edu>, hermit@cats.ucsc.edu (William R. Ward) writes:
>
> I'm personally in favor of the SCO XENIX (/UNIX?) standard of naming
> console screens as tty01, tty02,..., tty12; direct-connect terminals as
> tty1a, tty1b, tty2a; serial-connect terminals as tty1A, tty1B, tty2A
> (where the number represents the physical card and the letter represents
> the port on that card. For normal 2-ports-per-serial-card, this means
> that COM1 and COM2 are tty1a and tty1b, and COM3 and COM4 are tty2a and
> tty2b. For a multi-port serial card this means that you have tty1a
> through tty1h.); pseudo-terminals are ttyp0-ttypf, ttyq0-ttyqf, etc.
Actually this bring up even more questions about serial ports and addressability.
Under DOS, the BIOS checks for serial cards at 3F8, 2F8, 3E8, and 2E8.
Unless your BIOS is really old, or your machine is a PS/2 machine.
The really old BIOSes only check for 3F8 and 2F8, and the PS/2 machines
look at 3F8, 2F8, and 6 addresses in the 38xx range. The first four
addresses that respond during POST are stored in segment 40 starting
at location 0. If your machine only has 2 serial ports at addresses
2F8 and 3E8, then DOS will recognize COM2 as COM1, and COM3 as COM2.
Confused yet?
Under UNIX, device names usually reflect a name which designates
a particular controller or device driver, and a number of device
numbers and/or sub numbers which correspond to the major and minor
device numbers given to mknod.
If the serial ports at 3F8, 2E8, 2F8, and 3E8 are all accessable using
a singular device driver, then they should all have the same
device subname, and be differentiated via numbers/letters.
There should also probably be a 1-to-1 coorespondance between a
particular IO address, and a device name. In that way, the device drivers
are easier to maintain (tables of addresses).
If the serial ports from a "smart-board" are not useable from the
standard serial device driver, then they should use a different
device base name (which probably requires it's own device driver,
rather than hacking the standard one). This will all become painfuly
obvious when device drivers are able to be selected during a kernal
rebuild.
This will all help to separate the "PC" serial devices from the "PS/2"
serial devices from the "other" serial devices.
The only arguments left will then be what base names to use, whether to
use letters or numbers, and whether to start numbering from 0 or 1 B^).
=================================================================
Kevin J. Cummings Prime Computer Inc.
20 Briarwood Road 500 Old Connecticut Path
Framingham, Mass. Framingham, Mass.
InterNet: cummings@primerd.Prime.COM
UUCP: uunet!primerd.Prime.COM!cummings
Std. Disclaimer: "Mr. McKittrick, after careful consideration,
I've come to the conclusion that your new
defense system SUCKS..." -- War Games
=================================================================
------------------------------
From: hedrick@dartagnan.rutgers.edu (Charles Hedrick)
Subject: Re: More and more questions. :)
Date: 26 Mar 92 19:40:25 GMT
dminer@mcs213e.cs.umr.edu (Dan Miner) writes:
> Questions:
>7) Can ka9q use a modem? I know it is TCP/IP but what is needed
> to run this puppy? :)
Yes, it can use a modem. In fact that's the only mode I've actually
tested. However at least as I've built it, it can't dial. I use
kermit to connect to a system at Rutgers, log in, and start SLIP.
Once the line is running SLIP, I exit from kermit and start KA9Q.
This is certainly not optimal. Ideally there'd be something like the
kermit script language to dial and login for you, so that novice users
could use it without having to know kermit as well. But this is not
shrink-wrapped software... The big practical problem is finding a
machine connected to your campus or company network that can run SLIP.
KA9Q isn't enough to put you on a network -- there's got to be
something at the other end that is willing to talk SLIP and forward
packets onto a network. (It's sort of hard to have a network with
just one machine.) If the modems on your campus are connected to
terminal servers rather than directly to computers, there's a good
chance the terminal servers can be configured to do SLIP. We use
Cisco terminal servers, which do this, but I believe several other
kinds do as well. Even if the modems are connected directly to
computers, there are implementations of SLIP for Unix and I think VMS.
(Don't ask me where though, because I don't know.) However setting
things up at your campus or corporation is going to require
cooperation on the part of your systems staff: if you're using a
terminal server, they'll have to configure SLIP and enable it; if your
modems are directly on computers, they'll have to install the SLIP
software, which must be installed in the kernel. (I think it can be
done without having kernel source.)
------------------------------
** 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 alt.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.95a released on March 17, 1992
End of Linux-Activists Digest
******************************