From: Digestifier To: Linux-Activists@senator-bedfellow.mit.edu Reply-To: Linux-Activists@senator-bedfellow.mit.edu Date: Mon, 13 Sep 93 20:13:19 EDT Subject: Linux-Activists Digest #227 Linux-Activists Digest #227, Volume #6 Mon, 13 Sep 93 20:13:19 EDT Contents: Re: shared libraries (was BSD UNIX) (A Wizard of Earth C) Adaptec 2742 SCSI Controller (Martin Rathmayer) 525 Meg Tandberg Tape Drives NICE PRICE (John V. Jaskolski) Diamond Viper Compatibility (Raymond H. Kraft) close (probstmj@cnsvax.uwec.edu) M-Script (Mark Morley) Re: ext2_new_block: unable to locate free bit (Alexander Otterbein) Re: How to emulate 3-button mouse with X (Haidong Anthony Ye) Re: Bootdisk made by SLS install hangs during boot (Brandon S. Allbery) [Q] PAS-16,SCSI,dos,unix (Geoff Newton) ---------------------------------------------------------------------------- Crossposted-To: comp.unix.bsd,comp.os.386bsd.misc From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: shared libraries (was BSD UNIX) 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. >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. > >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. 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. 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. I think a lot of the problem could be alleviated by copy-on-dirty and force-copy-on-text-busy to get the swap backing store into the swap area and off the file (getting rid of the antiquated "ETXTBUSY" we bought off on when we ate the MACH VM system whole). A subsequent LRU garbage collection in swap would buy us the pre-relocation benefits of the Utah system by allowing copy-on-write from a prerelocated image -- the "old" swap image being used to get the relocated GOT and read-only and non-dirty pages without recourse to the image. This would imply a need for a unification of the vnode LRUing similar to the SVR4 implementation to let us force-flush a swap image of a vnode when the vnode itself was flushed (this assumes that swap might not be the limiting resource). A secondary benefit is that the currently broken NFS model (how do we return ETXTBUSY when the file is executing on a client instead of locally?) will be 'magically' resolved. A tertiary benefit to the swap-store changes is that we will be able to get a real system dump without reserving a dump partition other than swap. It isn't necessary to buy off on the whole ball of wax to get most of the benefits. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ From: rathmaye@email.tuwien.ac.at (Martin Rathmayer) Subject: Adaptec 2742 SCSI Controller Date: 13 Sep 1993 21:15:13 GMT Does the new Adaptec 2742 SCSI Controller work under Linux ? Has somebody experience with it ? Martin -- MARTIN G. RATHMAYER Email: rathmayer@edvz.tuwien.ac.at Member of Communications Group Phone: (++43-1 58801-5834) Computing Services FAX: (++43-1 587 42 11) Technical University of Vienna, Wiedner Hauptstr. 8-10, A-1040 Vienna / AUSTRIA ------------------------------ From: jasko@park.bu.edu (John V. Jaskolski) Subject: 525 Meg Tandberg Tape Drives NICE PRICE Date: 13 Sep 93 17:22:58 Reply-To: jasko@cns.bu.edu Numerous people have read posts on comp.os.linux from individuals who have purchased the 525 Meg tape drives from me. Since the original post is no longer there, I have received lots of inquiries regarding these drives, what the price was, and whether or not I could get any more. I found out today that I can get more. The following is the original post. *ORIGINAL POST FOLLOWS:************************************** I have a few 525 Meg (compressed) Tandberg tape drives that I will give out on a first come first serve basis. These drives go for $790.00 brand new. I will give these drives away to anyone who wants one for $235.00. Just think, now you can backup your entire system affordably and you can sleep easily at night knowing that if you crash you *WON'T* burn. These are IBM versions of the Tandberg SCSI tape drives. They were manufactured by Tandberg for IBM. As a result, they have been manufactured to IBM specs which means that they are very high quality. The drives will hold 525 Meg *COMPRESSED* on a DC6250 tape (250 Meg uncompressed). They are internal 5 1/4" half height drives. They are vastly superior to and 3 times faster than the Colorado Jumbo 250. They will work with *ANY* SCSI controller. The drivers (i.e., ASPI managers) come with your SCSI controller. These Tandbergs will also come with FREE Tape ARchive (TAR) Backup software with which to perform backups in DOS. This Backup Software can backup your entire system at 2:00 AM. It is so easy to use and self explanatory that docs are virtually unnecessary (which is good because these *DO NOT* come with docs). Each tape drive comes with complete installation instructions (written by me) and each comes with usage instructions. The drives are not *BRAND NEW*. They are slightly used floor models. They are 100% guaranteed for 30 days. If you get one and you don't like the way it matches your wallpaper simply return it for you money back *NO QUESTIONS ASKED*! S&H is $10.00. I can take Visa or MasterCard for these. My home phone number is (617) 246-3634. You can call me *ANYTIME* up until 2:00 AM seven days a week. The best time to reach me is after 5:30 PM. These drives work perfectly with OS/2, Windows NT, Linux, BSD, and other Unices for the PC. If you are going to pay by MasterCard or Visa call me *ANYTIME* at my home: (617) 246-3634. If nobody is home you can leave your name and a number that you can be reached at (and what time you want me to call back) and I will call you back ASAP. If you are going to pay with a check or money order: In order to acquire a Tandberg make your payment or money order for $245.00 ($235.00 + $10.00 S&H) payable to: Dr. John V. Jaskolski send it to: Dr. John V. Jaskolski Suite #307 95 Audubon Rd. Wakefield, MA. 01880 E-MAIL me confirming exactly what you want and in what quantity and indicate how much money you sent in your payment. Sincerely, Dr. John V. Jaskolski jasko@park.bu.edu P.S. E-mail me if you have any questions. Also, if you are at all interested let me know now or when you try later they will almost surely be gone. The following is a summary description: #Make/Model: IBM/Tandberg TDC3600 (internal), IBM originally shipped this # model with their RS/6000 line of workstations. #Max Capacity: 525 Meg with Software compression #Interface: SCSI, internal 64K buffer #Rec. format: write - (DC6250/525Mb, DC6150/300Mb) w/ compression # write - (DC6250/250Mb, DC6150/150Mb) w/o compression # read - QIC-150, QIC-120, QIC-24 (DC6250/6150/600A) #Form factor: 5 1/4", half-height #Transfer rate: 6Mb/min #Documentation: n/a and unnecessary, but the drive has a sticker # describing the jumpers #Accessories: Tape ARchive (TAR) Backup Software for DOS # #Compatibility: this is a standard SCSI tape drive and should work with any # decently written SCSI software. Compatibility has been # successfully tested with the following hardware/software # configurations: OS/2 (2.0 and 2.1 beta), SUN 3/50, 3/60 # 1542B/SYTOS+ (DOS and OS2, using Archive 2150S, Wangtek 5150ES # and Tandberg 3660 drivers that come with SYTOS+), # 1542B/NOVABACK (DOS and OS2), 1542B/ASPITAR (MSDOS port of # GNUTAR), Future Domain 850/1660/SYTOS, Always IN2000/NOVABACK # Amiga (BTN driver), Quaterback, Mac (Fastback, Retrospect) # XENIX, BSD386/FD, Apple IIGS using a CV Tech Ramfast card 3.0m # or better his SCSI card does image backup only but image and # file backups can be done with GS TAPE software (by Tim Gramms) -- ------------------------------ From: ray@spacely (Raymond H. Kraft) Subject: Diamond Viper Compatibility Date: Mon, 13 Sep 1993 15:10:33 GMT The most recent hardward compatibility list says that the Diamond Stealth video card is currently not supported by Linux. Does anyone know if the same goes for the Diamond Viper video card? Thanks in advance for any information. -- _/_/_/_/ _/ _/ _/ Ray Kraft _/ _/ _/ _/ _/ _/ Boeing Defense & Space Group _/_/_/_/ _/_/_/_/ _/_/ Seattle, Washington _/ _/ _/ _/ _/ Email: ray@rosie.boeing.com _/ _/ _/ _/ _/ ------------------------------ From: probstmj@cnsvax.uwec.edu Subject: close Date: 13 Sep 93 16:40:10 -0600 I've heard lots of laughing about the desire to run Windoze programs under Linux, but hear me out for a second. I'd love to dump MS-DOS and move to LINUX. I'd get a brand new 340-meg hard drive to go with my 250, get 8 additional megs of ram, and have a blast. However, there are three programs I have which make this goal impossible. There are some programs which just aren't available and are not practical to develop personally. 1. Finale Music Composition 3.0. This program is the finest musical notation program available for the IBM today. Unfortunately, it runs under Windoze. I just can't get along without it. I'd be glad to set aside another partition for DOS and Windoze, but it would be lots cooler to get along without it. 2. Cakewalk 3.0 for DOS. This program is a MIDI sequencer. It would be possible to create a similar program for UNIX without too much trouble, but it would take lots more time than I have. 3. MS Word. This is actually not necessary, because there are equivalents for UNIX and there must be X-windows word processors of similar quality. However, what I've seen so far doesn't have quite the flexibility. I guess I could get along without this program, especially because nobody on this newsgroup is going to cry if Microsoft's corporate headquarters blow up tomorrow unexpectedly. Okay, I admit that most of you would just give me the snide remark "If you need the program get out the C compiler and create it yourself for X-windows", but these programs are the result of thousands of man-hours of programming. Finale in particular is both indespensible and impossible to recreate. So although it is possible to create a DOS partition and do DOS work under it, there is a certain coolness to being able to run another operating system's stuff under UNIX. I know there are some commerical UNIXes that do this, though I don't know how reliable they are. If I could just find some musical notation program of similar quality for UNIX or run the one I have under UNIX, I would be very happy. Linux still kicks serious butt, though . .. ------------------------------ Crossposted-To: comp.os.linux.misc Subject: M-Script From: morley@suncad.camosun.bc.ca (Mark Morley) Date: 13 Sep 93 12:59:28 PDT Hello all, Some of you (very few of you, actually) are aware that I was writing some BBS software for Unix (Linux, to be specific). Here's an update: I started over. What I've done now is to create a new programming language called M-Script. It is an interpreted language but it is tightly written and very fast. It looks similar to dBase or BASIC. Anyway, M-Script is designed for writing BBS's and other on-line systems (MUD's etc). It has many built-in functions that deal with ANSI colors/graphics, file browsing, hyper text screens, menus, data entry, blah, blah, blah. Of particular interest to many of you may be its built-in Internet apps like finger, telnet, FTP, etc. I'm now re-writing my BBS in M-Script. It's going a _LOT_ faster now - even though I'm basically creating a new programming language _and_ a BBS written in that language at the same time. Loads'o'fun. Really. I mean it. If you want to see what M-Script can do, telnet to buckyball.camosun.bc.ca (134.87.16.6) and log in as 'guest' (password is also 'guest'). Note that I've currently limited the guest account to a maximum of 3 simultaneous logins, so if it won't let you in try again in a few minutes. ************************************************************************* NOTE: What you will see on buckyball is a mostly useless mock BBS. It exists primarily for me to test M-Script and BBS concepts. It changes from day to day. If you're really lucky you'll catch it just as I'm making changes and it'll dump out on you. Help screens are there but are incomplete, etc. There is _very_ little that you can actually do. Don't assume this is what my real BBS will look like. This is just a SAMPLER. If you don't like the mock BBS don't freak out. With M-Script it could have any interface you want: command line, menu, hot-keys, RIP, GTP, etc. ************************************************************************* People who are interested in M-Script can drop me a note. I'll be looking for a half dozen or so beta testers in the next week or so. M-Script ain't gonna be free, but beta testers will get a free copy. If you want to be a beta tester, tell me why and how you plan to make use of M-Script. When I've finished writing the prliminary programmers' reference I'll send a binary of the M-Script interpreter (for Linux or SunOS - your choice) and the reference to at most 10 testers who I feel are _really_ gonna put it through its paces. Mark morley@camosun.bc.ca ------------------------------ Crossposted-To: comp.os.linux.help From: prale@prale.rhoen.sub.org (Alexander Otterbein) Subject: Re: ext2_new_block: unable to locate free bit Date: Mon, 13 Sep 1993 23:33:35 GMT In article lmulcah@lookout.mtt.it.uswc.uswest.com (Larry "Bob" Mulcahy) writes: >Lately I'm having big problems with the ext2fs. 10-20 times a day my >system coughs up the message > > ext2_new_block: Unable to locate free bit in block group 115 > I'm having the same problem. The only difference is that the group at my system is 12 instead of 115. >generally as it's receiving news via uucp. I can run a full e2fsck >(-afv or -acfv) right after getting several of these errors and it >detects nothing wrong. > It happens if I have less than 2 MByte free on my root-partition. I think it is something like fragmentation ... Could that be possible ? Ciao... Alex. -- Alexander Otterbein, Lindenweg 20, 36137 Grossenlueder-Mues -> prale@prale.rhoen.sub.org -> otti@bht-box.zer.de -> FIDO : 2:248/158.5 ------------------------------ From: hy4796@cesn9.cen.uiuc.edu (Haidong Anthony Ye) Crossposted-To: comp.os.linux.help Subject: Re: How to emulate 3-button mouse with X Date: 13 Sep 1993 23:33:27 GMT Reply-To: hy4796@coewl.cen.uiuc.edu In <2729hu$ed0@TAMUTS.TAMU.EDU> cfeng@cs.tamu.edu (Chao Feng) writes: >I have Z-Nix (Microsoft Compatible) mouse with 2 buttons. In X of SLS 1.03, >I have problem to paste high lighted text. In normal X using 3-button >mouse, you can use the middle button to paste. But how to emulate this >using the 2 button mouse? I saw that there is a field in Xconfig called >"Emulate3Buttons", but nothing happened when I enabled it. Did you try pressing the two buttons simultaneously? That's normally how two button mouse emulate three button ones. >Any idea? >Chao >cfeng@cs.tamu.edu -- -Anthony ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Bootdisk made by SLS install hangs during boot Date: Mon, 13 Sep 1993 23:34:50 GMT In article <747936572.AA07470@psybbs.durham.nc.us> Derek.Bischoff%f1.n3641.z1@psybbs.durham.nc.us (Derek Bischoff) writes: > CK> and then we sit and wait forever...... > Hmmmm. sounds like a IRQ or IO conflict to me. > Have you removed the card to see if that is the conflict? Uh, Derek, many of us are showing that symptom, or others (I got a hang for about a minute and a half which then turned into a kernel panic). I don't *have* a sound card... And it's hard to recompile 0.99.12 from an 0.99.9 system (needs new gcc, which needs new libs, which need new kernel...), and even harder to recompile from a DOS system. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: gjn@cs.uq.oz.au (Geoff Newton) Crossposted-To: comp.sys.ibm.pc.soundcard,comp.os.386bsd.questions,aus.computers.linux,aus.computers,aus.computers.ibm-pc Subject: [Q] PAS-16,SCSI,dos,unix Date: 13 Sep 93 23:51:12 GMT Reply-To: gjn@cs.uq.oz.au Hi fellow netters, I am looking at getting a soundcard/cd-rom for my pc. I am also looking at supporting SCSI. I run dos and 386bsd on the same pc with 245 and 520 meg IDE drives. I was looking at a PAS-16 with SCSI interface. Has anybody succeeded in plugging SCSI disks and/or tape units into the SCSI interface ? I presume that the SCSI is SCSI-1. If I later buy a dedicated SCSI card, such as an adaptec 1542 or whatever, is it possible to disable the SCSI on the sound card (or even use both SCSI sources) ? Has anyone on 386bsd (or linux) had any experience with this sort of card? Is the SCSI fast enough (throughput) for usable disks, I seem to recall reading that it was only 8-bit. How bad does performance suffer if the sound card is not playing "sounds" ? What about if it is ? Any other suggestions for soundcards/cd-roms. I liked the PAS-16, cause it supported SCSI and the cdrom looked like it was a decent one. But crumbs, for $1700 (aus) for the kit, it would wanta be. Any help appreciated, gjn Geoff Newton gjn@cs.uq.oz.au ------------------------------ ** 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 ******************************