Tech Insider					   Technology and Trends


			   USENET Archives


Electronic mail:			      WorldWideWeb:
   tech-insider@outlook.com		         http://tech-insider.org/

Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: RE: not using shared libs on root disk.
Nntp-Posting-Host: sanjuan.uvic.ca
Organization: University of Victoria, Victoria, BC, CANADA
Date: Tue, 16 Jun 92 07:28:09 GMT

Saying "Don't use shared libs on the root disk because then you will be 
relying on one file" kinda misses the point.   Linux already depends on
certain key files.  What would you do if sh/bash were deleted (keep in mind
Linux demand pages from the executable).  How about the /dev directory.  Or
shoelace/Image.   Really, any of these will cause a system failure, as can
an fs corruption.

None of this prevents booting from the shared lib root floppy and 
cp /lib/lib* /hd??/lib.

As an ounce of prevention, you should chmod ugo-w /lib/lib*.

I do wish people would stop railing against the use of shared libs.  Shared
libs are a good idea.  They help keep hd reqs down, and reduce network
bandwidth for postings.  We can also link small images like login, etc
with -N, to eliminate the headers.  And images should be posted as .a's.

Examples of bad ideas, however, are alternate shells and editors, like ash
and joe.   God, one of the things I hate about SUN/OS is the two shells,
csh and sh (quick now, which is it, for i or foreach). 

By all means, use whatever shell etc you want on your system.  But lets
at least keep the distribution simple.

Of course, I am one of those individuals who beleive it is silly to use
MGR when X is around :-)

Peter.
pmacdona@tadpole.bcsc.gov.bc.ca

Path: sparky!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!
menudo.uh.edu!lobster!nuchat!kevin
From: ke...@nuchat.sccsi.com (Kevin Brown)
Newsgroups: comp.os.linux
Subject: Re: not using shared libs on root disk.
Message-ID: <1992Jun16.201947.5922@nuchat.sccsi.com>
Date: 16 Jun 92 20:19:47 GMT
References: <1992Jun16.072809.3964@sol.UVic.CA>
Organization: Teenage Mutant Ninja NiceGuys(tm)
Lines: 86

In article <1992Jun16....@sol.UVic.CA> pmacdona@sanjuan (Peter MacDonald) writes:
>Saying "Don't use shared libs on the root disk because then you will be 
>relying on one file" kinda misses the point.   Linux already depends on
>certain key files.  What would you do if sh/bash were deleted (keep in mind
>Linux demand pages from the executable).  How about the /dev directory.  Or
>shoelace/Image.   Really, any of these will cause a system failure, as can
>an fs corruption.

This is true, of course, but my opinion is that the root disk, since it will
be used for crash recovery, should be as robust as possible.  There are
obviously certain things that you simply can't get around, like the
requirement for a shell and certain /dev entries.  We have little choice but
to rely on these things, and if they break, we're in big trouble.

This cannot be said for shared libraries.  Shared libraries are not a 
*necessity*.  They are a luxury that yield some very nice benefits, but
we can live without them (and *have*).

>None of this prevents booting from the shared lib root floppy and 
>cp /lib/lib* /hd??/lib.
>
>As an ounce of prevention, you should chmod ugo-w /lib/lib*.

Or better yet, if we *must* use shared libraries on the root floppy, they
should come with write disabled.  The lib directory should probably be set
the same way so that they can't accidentally be removed (don't know if
rm is smart enough to verify such an rm if you're root and try to rm from
a non-writeable directory).

>I do wish people would stop railing against the use of shared libs.  Shared
>libs are a good idea.  They help keep hd reqs down, and reduce network
>bandwidth for postings.  We can also link small images like login, etc
>with -N, to eliminate the headers.  And images should be posted as .a's.
>
>Examples of bad ideas, however, are alternate shells and editors, like ash
>and joe.   God, one of the things I hate about SUN/OS is the two shells,
>csh and sh (quick now, which is it, for i or foreach). 

Quite true.  The reason I suggested something like joe or ed for the editor
on the root disk is that both are quite small, but sufficient for most
recovery purposes.  They represent a much better functionality/space tradeoff
than some of the other editors.

For instance, if most people wanted to use GNU Emacs, do you think it would
be a good idea to include it on the root disk?  I don't.  It would take up
*way* too much space for what you get.

Multiple shells are a bad idea, of course.  If the default shell dies,
there's little you can do to recover, unless you have multiple logins
each with a different default shell (this may be desirable, but again
it's a functionality/space tradeoff).  So which shell do you include?
The one that provides the greatest functionality for the amount of
space that it takes, of course.  My opinion is that ash wins this one.
Bash loses because it has far more features than are needed for basic
installation purposes.  Csh loses because it doesn't have enough in the
way of programmability to make shell scripts reasonably easy to write
(in comparison with ash), and job control is unnecessary because we
have virtual consoles.  Command history and editing are nice, but are
unnecessary because the primary use that the shell on the root disk will
be put to is crash recovery and installation, neither of which are
(hopefully :-) done very often.  Once you've got the system installed,
you can select whichever shell you like the most.

Oh, yeah: the login suite is also unnecessary for the root disk, since
a shell can be put on each virtual console.  Just have init respawn them.
You *might* want su, though.

>By all means, use whatever shell etc you want on your system.  But lets
>at least keep the distribution simple.

Right.  See above.

>Of course, I am one of those individuals who beleive it is silly to use
>MGR when X is around :-)

Or vice-versa.  :-)

>Peter.
>pmac...@tadpole.bcsc.gov.bc.ca


-- 
				Kevin Brown

			    ke...@nuchat.sccsi.com
			    ke...@taronga.taronga.com

Path: sparky!uunet!decwrl!mcnc!borg!cs.unc.edu!faith
From: fa...@cs.unc.edu (Rik Faith)
Newsgroups: comp.os.linux
Subject: Re: not using shared libs on root disk.
Message-ID: <13104@borg.cs.unc.edu>
Date: 17 Jun 92 18:31:54 GMT
References: <1992Jun16.072809.3964@sol.UVic.CA> 
<1992Jun16.201947.5922@nuchat.sccsi.com>
Sender: ne...@cs.unc.edu
Lines: 48

In article <1992Jun16....@nuchat.sccsi.com>, ke...@nuchat.sccsi.com 
(Kevin Brown) writes:
|> So which shell do you include?
|> The one that provides the greatest functionality for the amount of
|> space that it takes, of course.  My opinion is that ash wins this one.

ash loses because it is not Bourne shell compatible.  Many people are wasting
a lot of time with Linux because they are trying to run /bin/sh scripts with
ash.  ash fails, and usually doesn't say why.  These scripts are standard
Bourne shell script which work reliably with normal unix Bourne shells.  I
think that we should totally abandon ash for Linux.

|> Bash loses because it has far more features than are needed for basic
|> installation purposes.

Bash will run Bourne shell scripts.  Features like file name completion can
make installation much smoother.  Unless, of course, you want installation
to be as painful as possible.

|> Csh loses because it doesn't have enough in the
|> way of programmability to make shell scripts reasonably easy to write
|> (in comparison with ash), and job control is unnecessary because we
|> have virtual consoles.

Give me a break.  I can write a csh script to do anything that a sh script
can do.  But this isn't important, and I don't want to start a flame war
over it.  In point of fact, ash *cannot* run many standard Bourne shell
scripts that bash can.

Job control may not be necessary for installation, but people are
used to the "job control" paradigm from other unix systems.  Virtual consoles
just aren't the same.

|> Command history and editing are nice, but are
|> unnecessary because the primary use that the shell on the root disk will
|> be put to is crash recovery and installation, neither of which are
|> (hopefully :-) done very often.

When I hose my system, the last thing that I want to use is a shell that
does *not* have filename completion, command line editing, or history.
I want installation and recovery to be as comfortable as possible.  I want
a shell that can reliably run Bourne scripts.

[Now, can you guess which shell I use every day for the vast majority of
my work?  Hint: it's *not* bash. . .].

-- 
Rik Faith: fa...@cs.unc.edu

Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!
linac!att!ucbvax!bloom-beacon!bloom-picayune.mit.edu!daemon
From: ty...@ATHENA.MIT.EDU (Theodore Ts'o)
Newsgroups: comp.os.linux
Subject: Re: not using shared libs on root disk.
Message-ID: <1992Jun18.043125.15343@athena.mit.edu>
Date: 18 Jun 92 04:31:25 GMT
Sender: dae...@athena.mit.edu (Mr Background)
Reply-To: ty...@athena.mit.edu
Organization: The Internet
Lines: 38

Sigh.  bash is a Korn shell look-a-like, which means (among other
things) that it's backwards compatible towards the Bourne shell.  This
makes it pretty standard.  I don't understand why you call it "baroque";
it's not.  A lot of people using the Korn shell or bash everyday, and
rely on its features quite a lot.

And it shouldn't take up that much space if we used shared libraries.
Aside from the repeated *assertions* that this will make the system
somehow less stable, there's no good reasons why not to use the shared
library on the root disk.

This is particularily true on the MCC release, where the bootdisk
contains a RAM disk image, which is loaded at boot time and which is
used as the root filesystem --- in that case, if a user is stupid enough
to nuke the shared library, then he can just reboot and get a fresh RAM
disk image.

However, even for the "standard" bootdisk/rootdisk image, I believe
shared libraries to be perfectly acceptable.  It is true that if a user
deletes the shared library, he's completely screwed himself.  But the
same is true if he deletes the shell itself, or any other number of
programs.  

I simply don't understand the rationale of trying to minimize 
the number of "critical programs" on a root image on a floppy.  This is
Unix, for crying out loud!  A user who is dumb enough or careless enough
to screw up a shared library is probably also dumb enough to
accidentally copy something into /dev/floppy0, or something equally
catastrophic.  

If you want a nice, safe system where you can't hurt yourself easily
(the kindergarden scissors approach), I suggest you try switch to
Macintosh, and program in Pascal instead of C.  It's not fair to ask
everybody to wear straightjackets just because a few people might be
careless or ignorant and make a mistake --- especially since the mistake
can be easily fixed by reloading the floppy from the rootimage.  Sheesh.

							- Ted

			   USENET Archives


Notice
******

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or 
research.


Electronic mail:			      WorldWideWeb:
   tech-insider@outlook.com		         http://tech-insider.org/