Subject: Linux-Activists Digest #236
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 16 Sep 93 19:13:08 EDT

Linux-Activists Digest #236, Volume #6           Thu, 16 Sep 93 19:13:08 EDT

Contents:
  Linux or BSD ([email-masked])
  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 ([email-masked])
  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: [email-masked]
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 [email-masked]
or      [email-masked]

thanks
bhiksha

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

Date: Thu, 16 Sep 1993 20:03:46 CDT
From: <[email-masked]>
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: [email-masked] (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: [email-masked] (The Unstoppable Drew)
Subject: How do I get rid of LILO ?
Reply-To: [email-masked]
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 |
| [email-masked]    |       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: [email-masked] ()
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: [email-masked]
"Blessed are the peacemakers"- Jesus Christ

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

Date: Thu, 16 Sep 1993 22:10:45 CDT
From: <[email-masked]>
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: [email-masked] (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: [email-masked] (Henrik Lund)
Subject: Re: Linux and MS Windows 3.1 (yuck) swap space.
Date: Wed, 15 Sep 1993 13:47:46 GMT

[email-masked] (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: [email-masked]

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 [email-masked]

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

From: [email-masked] (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: [email-masked]
Subject: Re: E-MAIL
Date: Thu, 16 Sep 1993 06:57:15 GMT

Eric David ([email-masked]) 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: [email-masked] (The Unstoppable Drew)
Subject: How do I get rid of LILO ?  *Gone*
Reply-To: [email-masked]
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 |
| [email-masked]    |       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: [email-masked] (pingnan shi)
Subject: Help, term problem with SLS-1.03
Date: 16 Sep 1993 22:23:29 GMT
Reply-To: [email-masked]

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 ([email-masked])  _______  _______   __|__   |
|                                   /___.   \ | /   ___|___  |
|  Dept. of Electrical Engineering /|   |  ---|---  |_\_/_|  |
|  Univ. of British Columbia      / |   |     |     |--|--|  |
|  Vancouver, BC, Canada. V6T 1W5   |___|     |     |  | .|  |
+------------------------------------------------------------+

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

Crossposted-To: comp.unix.bsd,comp.os.386bsd.misc
From: [email-masked] (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: <[email-masked]>
        Sender: [email-masked]
        Organization: Weber State University, Ogden, UT
        References: <[email-masked]> <[email-masked]> <[email-masked]>
        Date: Mon, 13 Sep 93 20:34:42 GMT
        
        In article <[email-masked]> [email-masked] (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: [email-masked]

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

    Internet: [email-masked]

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
******************************