499 lines
21 KiB
Plaintext
499 lines
21 KiB
Plaintext
From: Digestifier <Linux-Activists-Request@senator-bedfellow.mit.edu>
|
|
To: Linux-Activists@senator-bedfellow.mit.edu
|
|
Reply-To: Linux-Activists@senator-bedfellow.mit.edu
|
|
Date: Thu, 16 Sep 93 19:13:08 EDT
|
|
Subject: Linux-Activists Digest #236
|
|
|
|
Linux-Activists Digest #236, Volume #6 Thu, 16 Sep 93 19:13:08 EDT
|
|
|
|
Contents:
|
|
Linux or BSD (bhiksha@tifrvax.tifr.res.in)
|
|
New 383 Meg Refridgerator for sale
|
|
DTC 3280AS SCSI card HELP!!! (David Shoemaker)
|
|
How do I get rid of LILO ? (The Unstoppable Drew)
|
|
Re: Easy way to use complex numbers in C++ (i.e. like Fortran)
|
|
re: New 383 Meg Refridgerator
|
|
revise HD from /dev/fdX (MING HE)
|
|
Re: Linux and MS Windows 3.1 (yuck) swap space. (Henrik Lund)
|
|
Making a filesystem larger than 64mb? (Morten Krog)
|
|
Re: E-MAIL (sea@waena.edu)
|
|
How do I get rid of LILO ? *Gone* (The Unstoppable Drew)
|
|
Help, term problem with SLS-1.03 (pingnan shi)
|
|
Re: shared libraries (was BSD UNIX) (Doug Orr)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: bhiksha@tifrvax.tifr.res.in
|
|
Subject: Linux or BSD
|
|
Date: Fri, 17 Sep 1993 03:42:12 GMT
|
|
|
|
Hi,
|
|
|
|
I have a PC 486 with 16MB RAM, WD80?? ethernet card and 2x260MB IDE drives.
|
|
I wish to load UNIX on it. My requirements are:
|
|
|
|
1) TCP/IP. I wish to be able to connect to the Local Area Network, and thru
|
|
a bridge on the net to a WAN.
|
|
2) NFS. I should be able to mount the local disk(s) on other m/cs on the LAN
|
|
and remote mount disks on the other m/cs.
|
|
3) I also need to maintain a dos partition, since i have a lot of important
|
|
stuff on the dos.
|
|
4) Standard C and Fortran compilers, if possible (gcc?)
|
|
|
|
Given the conditions, can anyone tell me the relative merits and
|
|
de-merits of Linux/386BSD. I understand that Linux is much easier to install
|
|
than *BSD and occupies much less disk-space and that the OS is also smaller.
|
|
On the other hand, *BSD is supposed to have a better networking...
|
|
What is /proc?
|
|
How robust are the filesystems? Also, given the tendency of the
|
|
IDE drives to occasionally develop bad sectors, how do the systems handle it?
|
|
How much communication is possible between dos/unix partitions?
|
|
|
|
Please reply to bhiksha@tifrvax.tifr.res.in
|
|
or bhiksha@tifrvax.bitnet
|
|
|
|
thanks
|
|
bhiksha
|
|
|
|
------------------------------
|
|
|
|
Date: Thu, 16 Sep 1993 20:03:46 CDT
|
|
From: <K111114@ALIJKU11.BITNET>
|
|
Subject: New 383 Meg Refridgerator for sale
|
|
|
|
I wont post this frequently to this group, but I have a
|
|
-brandnew- 383Meg Refridgerator for sale. Only 124967.00 $$ and
|
|
the deal is yours! Call me in the nighthours, call me at the day.
|
|
My address is: tohuvabohuland (easy reachable from every place on earh)
|
|
|
|
The first who calls me, gets this *BRANDNEW* refridgerator! Sorry about the
|
|
others who are not living next to my door.
|
|
|
|
|
|
------------------------------
|
|
|
|
From: i-bds@microsoft.com (David Shoemaker)
|
|
Subject: DTC 3280AS SCSI card HELP!!!
|
|
Date: 16 Sep 93 16:25:22 GMT
|
|
|
|
I am trying to get Linux up, I have a DTC 3280AS SCSI card, works fine under
|
|
dos/os2/windows/SCO Unix. The SLS kernal does not recognize it. Is there a
|
|
driver available? If not can some one give me some clues on how to use the
|
|
SCO drivers or build my own.
|
|
|
|
Very greatfull to all help.
|
|
|
|
David
|
|
|
|
PS The DTC 3283 (?) I have been told is recognized as an Adaptec but it
|
|
looks like the 3280 is different.
|
|
|
|
DFS
|
|
Lost in my own Mind.
|
|
|
|
|
|
------------------------------
|
|
|
|
From: aem@tomokato.analog.com (The Unstoppable Drew)
|
|
Subject: How do I get rid of LILO ?
|
|
Reply-To: andrew.marold@analog.com
|
|
Date: Thu, 16 Sep 1993 17:37:21 GMT
|
|
|
|
I needed to reclaim the disk space that I allocated to Linux
|
|
on my pc at work so I repartioned & reformatted both my hard drives.
|
|
However, when I reboot, LILO still pops up and will try to boot the
|
|
nonexistant Linux partions (lose lose). How can I get rid of this ?
|
|
Please email, I don't keep up with c.o.l. anymore. Thanks !!
|
|
--
|
|
+-----------------------------+--------------------------------+
|
|
| Andrew E. Marold | Analog Devices |
|
|
| Software Engineer | DSP Software Tools Group |
|
|
| andrew.marold@analog.com | Norwood, MA 02062 USA |
|
|
| PGP 2.0 public key available |
|
|
+-----------------------------+--------------------------------+
|
|
"Mile after mile, stone after stone, you turn to speak but you're alone.
|
|
Million miles from home, you're on your own." --Pink Floyd--
|
|
|
|
|
|
------------------------------
|
|
|
|
From: pramod@radon.ece.uiuc.edu ()
|
|
Subject: Re: Easy way to use complex numbers in C++ (i.e. like Fortran)
|
|
Date: 16 Sep 93 14:52:41 GMT
|
|
|
|
Sorry, disregard previous post, it was intended for comp.lang.c++ not
|
|
this newsgroup.
|
|
|
|
|
|
Pramod
|
|
|
|
--
|
|
Pramod John, Dept. of ECE at UIUC
|
|
email: pramod@uiuc.edu
|
|
"Blessed are the peacemakers"- Jesus Christ
|
|
|
|
------------------------------
|
|
|
|
Date: Thu, 16 Sep 1993 22:10:45 CDT
|
|
From: <K111114@ALIJKU11.BITNET>
|
|
Subject: re: New 383 Meg Refridgerator
|
|
|
|
I apologize to Dr. John Jaskolsky (sorry that I don't spell the name right)
|
|
for my previous article: He does indeed trade with poeple living in Europe,
|
|
too. Eventually I am going to trade with him.
|
|
|
|
/Herp
|
|
|
|
------------------------------
|
|
|
|
From: cs921022@ariel.yorku.ca (MING HE)
|
|
Subject: revise HD from /dev/fdX
|
|
Date: Thu, 16 Sep 1993 20:15:38 GMT
|
|
|
|
If I, eventuallly, did something wrong on the filesystem and I can't
|
|
boot from HD, can I change the HD from FD a1? Something like erased
|
|
/bin/sh, /etc/getty, or forgot root password.
|
|
|
|
I tyied mounting HD form a1 but failed.
|
|
|
|
/ming
|
|
|
|
|
|
------------------------------
|
|
|
|
From: lund@diku.dk (Henrik Lund)
|
|
Subject: Re: Linux and MS Windows 3.1 (yuck) swap space.
|
|
Date: Wed, 15 Sep 1993 13:47:46 GMT
|
|
|
|
broman@schroeder.nosc.mil (Vincent Broman) writes:
|
|
|
|
>cbeauch@xenon asked:
|
|
>> I have a 12Mb Linux swap partition - is this possible to be used as both a
|
|
>> Linux and a Windows swapfile?
|
|
|
|
>If you use the partition under Linux as a swap _partition_, then each
|
|
>time you boot DOS to run MS-Windows, you'll have to format the partition
|
|
>and recreate the MS-Windows swap file by hand (thru menus and mouse clicks).
|
|
>If someone knows what bytes are expected to be present in the swap file
|
|
>when MS-Windows starts up, then one could easily write a DOS program
|
|
>to create it. Then we get a batch file like...
|
|
|
|
> format d:
|
|
> mymkswap d:\
|
|
> win
|
|
|
|
>I have tried to mount a dos file system under Linux and use a large file
|
|
>in that file system (whether the MS-Windows swap file or another)
|
|
>as a Linux swap _file_, but without success. After the mkswap run,
|
|
>the swapon program complains that it cannot find the right swap signature
|
|
>in the file. Anyone know why? Something to do with CRLF != LF?
|
|
|
|
>Vincent Broman, code 572 Bayside Phone: +1 619 553 1641
|
|
>Naval Command Control and Ocean Surveillance Center, RDT&E Div.
|
|
>San Diego, CA 92152-6147, USA Email: broman@nosc.mil
|
|
|
|
This question has been asked before (in the FAQ ?).
|
|
|
|
It goes something like this (haven't tried it, can't remember all of it).
|
|
|
|
From dos/windows set up the swap partition and leave.
|
|
From Linux gzip the partition. (I think like dd if=/dev/disk37 | gzip file)
|
|
|
|
Then you can include mkswap,swapon in a file run at boottime.
|
|
|
|
When you wan't to use windows just swapoff, gunzip, reboot.
|
|
|
|
This comes with NO WARRANTY , it's the best I can do for yo all.
|
|
|
|
Cheers Henrik Lund lund@diku.dk
|
|
|
|
|
|
------------------------------
|
|
|
|
From: harpoon@diku.dk (Morten Krog)
|
|
Subject: Making a filesystem larger than 64mb?
|
|
Date: Thu, 16 Sep 1993 10:41:36 GMT
|
|
|
|
Hi,
|
|
|
|
|
|
How do I use mke2fs to create a filesystem larger than 64mb. I want to have
|
|
a partition on my harddisk (size 75mb) installed with Linux, but I cannot
|
|
format the partition. As I read the doc, mkfs is unable to do this but
|
|
mke2fs should be able. I don't have mkefs so don't suggest that I use that.
|
|
PLEASE help. Any help will be appriciated.
|
|
|
|
Morten
|
|
|
|
|
|
------------------------------
|
|
|
|
From: sea@waena.edu
|
|
Subject: Re: E-MAIL
|
|
Date: Thu, 16 Sep 1993 06:57:15 GMT
|
|
|
|
Eric David (eric.david@alkiex.com) wrote:
|
|
: Hi I'm new to unix E-MAIL. Would someone explain how the LINUX system
|
|
: works and how to get to other systems,boards or computer. Thanx, Eric
|
|
|
|
No problem.. and then I will explain the difference between relativism anf
|
|
field theory!
|
|
|
|
Linix works like unix, which is an evolving byproduct of some of the greatest
|
|
minds of the last 30 years. E-mail (as unix knmows it) is a by-product of
|
|
unix, the military, world governments, and aliens.
|
|
|
|
To set e-mail up on unix you need to do a few things:
|
|
1) get a good book like "Managing uucp & Usenet, by O'reilly & assoc"
|
|
2) get an account on a carrier or internet service, like uunet or
|
|
portal (@408-973-9111)
|
|
3) Carefully examine and modify at least the following files:
|
|
/usr/lib/uucp/Devices,Permissions,Systems,Dialers
|
|
/usr/local/lib/smail/config,paths
|
|
/usr/local/lib/news/mailname,sys,organization
|
|
any doc pertaining to elm (mail reader) or tin (newsreader)
|
|
the serialFAQ (available at ftp sites)
|
|
/usr/local/lib/news/crontab.sample
|
|
/etc/domain
|
|
plus others I can't remember right now, but start here.
|
|
|
|
good luck.
|
|
|
|
|
|
------------------------------
|
|
|
|
From: aem@tomokato.analog.com (The Unstoppable Drew)
|
|
Subject: How do I get rid of LILO ? *Gone*
|
|
Reply-To: andrew.marold@analog.com
|
|
Date: Thu, 16 Sep 1993 20:53:34 GMT
|
|
|
|
Thanks to Jack Goral for the answer on getting rid of LILO.
|
|
The solution ? fdisk /mbr from dos.
|
|
--
|
|
+-----------------------------+--------------------------------+
|
|
| Andrew E. Marold | Analog Devices |
|
|
| Software Engineer | DSP Software Tools Group |
|
|
| andrew.marold@analog.com | Norwood, MA 02062 USA |
|
|
| PGP 2.0 public key available |
|
|
+-----------------------------+--------------------------------+
|
|
"Mile after mile, stone after stone, you turn to speak but you're alone.
|
|
Million miles from home, you're on your own." --Pink Floyd--
|
|
|
|
|
|
------------------------------
|
|
|
|
From: pings@ee.ubc.ca (pingnan shi)
|
|
Subject: Help, term problem with SLS-1.03
|
|
Date: 16 Sep 1993 22:23:29 GMT
|
|
Reply-To: pings@ee.ubc.ca
|
|
|
|
|
|
I have just installed SLS-1.03. I tried to use term which comes with the
|
|
package to run remote X window programs. I did what I did with the previous
|
|
SLS version. I run kermit first and login in to the remote machine and
|
|
run term there. And then I switched back to kermit and did
|
|
!term <> /dev/ttyS1 &
|
|
!trsh
|
|
At this point, I got the error message:
|
|
Connect: Invalid argument
|
|
and term hanged there.
|
|
|
|
The above procedure worked for SLS-1.02 and term-1.05. The term package came
|
|
with SlS-1.03 is version 1.07. Anyone had similar problem? Please help!
|
|
|
|
+------------------------------------------------------------+
|
|
| Pingnan Shi (pings@ee.ubc.ca) _______ _______ __|__ |
|
|
| /___. \ | / ___|___ |
|
|
| Dept. of Electrical Engineering /| | ---|--- |_\_/_| |
|
|
| Univ. of British Columbia / | | | |--|--| |
|
|
| Vancouver, BC, Canada. V6T 1W5 |___| | | | .| |
|
|
+------------------------------------------------------------+
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.unix.bsd,comp.os.386bsd.misc
|
|
From: dbo%eroica.cs.utah.edu@cs.utah.edu (Doug Orr)
|
|
Subject: Re: shared libraries (was BSD UNIX)
|
|
Date: 16 Sep 93 16:14:42
|
|
|
|
|
|
Hi,
|
|
|
|
I noticed this and had a couple of comments
|
|
|
|
Subject: Re: shared libraries (was BSD UNIX)
|
|
Message-ID: <1993Sep13.203442.21808@fcom.cc.utah.edu>
|
|
Sender: news@fcom.cc.utah.edu
|
|
Organization: Weber State University, Ogden, UT
|
|
References: <CCu0s1.29o@ssesco.com> <1993Sep7.162843.19294@fcom.cc.utah.edu> <33833@dog.ee.lbl.gov>
|
|
Date: Mon, 13 Sep 93 20:34:42 GMT
|
|
|
|
In article <33833@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
|
|
[ ... Static vs. Dynamic link tradeoffs ... ]
|
|
>This makes the Utah approach (as described at the last USENIX) all the
|
|
>more interesting. In this case, `executing' a binary invokes the
|
|
>linker, which can choose either to run a cached `pre-linked' version or
|
|
>to construct a new one. As Terry notes, most applications are run much
|
|
>more often than they need re-linking (the shared libraries do not
|
|
>change often). Hence, the same cached `post-fixup' version can be
|
|
>reused (saving time) and shared (saving space). In effect, this is
|
|
>the happy medium between `pure static' and `pure dynamic': resolved
|
|
>on demand, then static until something forces a change.
|
|
|
|
I thought that the numbers presented in the paper were, shall we say,
|
|
optimistic, especially with regards to the relative frequency of cache
|
|
hits. There is also the problem of converting the usage back to vanilla
|
|
(or not so vanilla) C from the C++ required in their implementation.
|
|
|
|
I'm always in favor of optimism, but I'm not sure I understand your
|
|
comment. If you're referring to the on-disk cache of prelinked
|
|
executables (the use of the word "cache" may have been unfortunate),
|
|
that's largely an (undefined) policy issue. You can set it up in
|
|
whatever way works best for you. If, for example, installing a
|
|
program (meta-object) *requires* generation of a cached copy (fully
|
|
linked executable), there will be a very good chance you'll have a
|
|
copy when you need one. Similarly, the policy can dictate that only
|
|
one cached copy be maintained for a given set of
|
|
executables/libraries, or whatever, to avoid proliferation when in
|
|
development mode.
|
|
|
|
The requirement that a cached copy be generated at install time
|
|
imposes on the installer the cost of the final program link... not
|
|
particularly worse than when doing normal edit/compile/debug with make
|
|
and ld.
|
|
|
|
Pushing this off on policy is something of a copout, given that I have
|
|
never gen'd up a policy expressly for edit/compile/debug. You can
|
|
certainly come up with boundary cases where a given policies won't
|
|
work too well. But, I do think it's feasible to serve the needs of
|
|
edit/compile/debug.
|
|
|
|
I don't understand the C/C++ comment. OMOS is written in C++, but
|
|
will work on any sort of a collection of executables. Various test
|
|
programs cited included alpha-one (several hundred thousand lines of C
|
|
code), ls, and xmh... we know what they're written in. What am I missing?
|
|
|
|
>Note that if this is done `right', the cached post-fixup binaries do
|
|
>not need to contain the shared libraries. Rather, the dynamic linker
|
|
>chooses an address for each shared library for each binary, and
|
|
>attempts to keep this address constant per library. If/when this
|
|
>attempt fails, this falls back to the equivalent of `pure dynamic'
|
|
>linking; when it succeeds, it works much like `pure static' linking.
|
|
>The only thing that the choice of per-library address `constants'
|
|
>affects is the ratio of successful `static-like' links to failed
|
|
>`dynamic-like' links.
|
|
|
|
For what it's worth, we do this "right".
|
|
|
|
>
|
|
>Assigning addresses to libraries would be the task of a program similar
|
|
>to SunOS's `ldconfig'. A library that lacks a preselected address
|
|
>would simply have one chosen dynamically. This would take more space,
|
|
>to cache `preloaded' binaries and (at their preselected addresses)
|
|
>libraries, but only those that are in fact used and/or only those that
|
|
>meet some policy. Again, the fallback is, in essence, `pure dynamic'
|
|
>linking; all else is merely optimization.
|
|
|
|
The idea of attempting to place the tables at a known location in all
|
|
binaries was the real interesting idea -- that way the post-fixup pages
|
|
can be shared. The problem with assigned addresses remains, however...
|
|
you still eat an address range for the library per version of the
|
|
library. I don't think the work at the UofU went through very many
|
|
generations of libraries, and so this problem didn't become evident.
|
|
The dynamic fallback simply resolves the packing problem. Admittedly,
|
|
this will alleviate the space issues somewhat, but with the excessively
|
|
frequent revisions to libraries for systems undergoing active developement
|
|
(like NetBSD/FreeBSD), this either implies a release authority with more
|
|
frequent releases or a plethora of incompatable library images.
|
|
|
|
Different versions can live at the same addresses (given that the
|
|
average application won't access two versions of the same library,
|
|
what with being unable to name things and all). The constraint system
|
|
picks out a version that is compatible with the constraints given.
|
|
The intent here was that OMOS would be the addressing authority, a
|
|
given meta-object could provide a "hint" as to where it might be most
|
|
desirably located, then OMOS would use a constraint system to resolve
|
|
that desire with realities of what executables it has available, etc.
|
|
|
|
I think it is just as possible to get around the problems with fixed GOT
|
|
locations; note that global data referenced by the libraries, unless it
|
|
is const data, must be pushed into the process at initial symbol resoloution
|
|
time, even if the link is delayed (as it is in the Utah system). This
|
|
means that data reference must be through the relocation table as well,
|
|
and thus pushing the table out of the image will not be successful if
|
|
there is external and internal symbol references taking place... this,
|
|
in a nutshell, was the main impediment to using Pete's modification of
|
|
Joerg's fixed address libraries to produce workable X (or termcap)
|
|
libraries.
|
|
|
|
Data is (are?) a real pain in the ass. In a copy-on-write world, what
|
|
we do is push the global data up to the highest level used. Stdio
|
|
data is linked in with libc, for example. Applications are bound,
|
|
directly referencing "up". This works as long as your libraries are
|
|
basically structured like a class with single inheritance. If they
|
|
are structured more like a multiple inheritance heriarchy or there are
|
|
circular library references, you're screwed. Happily, this is not
|
|
often the case. Also, if you want to do data interposition (not
|
|
unreasonable), you need an indirection that's fixed up at load time.
|
|
As long as we stick to our desired policy of not modifying compilers,
|
|
this will be hard to come by, so you're screwed there as well. Since
|
|
you can insert levels of indirection, procedural interposition is
|
|
possible, although mildly painful.
|
|
|
|
We're looking at single address space systems, and data becomes even
|
|
more of a pain, when COW is removed. But, we have plans there, as
|
|
well.
|
|
|
|
I think the basic justification for the Utah code comes from the ability
|
|
to launch or relaunch an application rather quickly; this is not the
|
|
highest item on my list of needs, and paying the per application fixup
|
|
penalty up front at exec time for the first instance of an application
|
|
is acceptable, especially as a trade-off to incurring additional run-time
|
|
overhead.
|
|
|
|
Good analysis. A form of the libraries we didn't talk about as much
|
|
involves generation and exportation of an executable image which is
|
|
linked with what amounts to a set of stubs that dynamically load the
|
|
target library at run time. It amounts to the same sort of setup as
|
|
the Sun shared libraries.
|
|
|
|
The benefits of this approach include the fact that there is a
|
|
tangible amount of code available to the debugger (OMOS' other mode
|
|
where it maintains maximum anal/retentive control of all code requires
|
|
debugger changes to get at symbol tables), and for the user to touch,
|
|
cp, tar, or whatever. The version of the library that is mapped in
|
|
can flex around at run time. You pay more per access of a given
|
|
routine, but if you're in edit/compile/debug, who cares.
|
|
|
|
I didn't do that support, so I don't remember what we do about shared
|
|
variables... you can certainly ask OMOS where they are and reference
|
|
them that way. I don't know if we do anything nicer. I don't know if
|
|
that addresses your concerns, but it's something else that's
|
|
available.
|
|
|
|
-Doug
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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.99pl9 released on April 23, 1993
|
|
|
|
End of Linux-Activists Digest
|
|
******************************
|