From: Digestifier 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: 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: 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: <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 ******************************