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