Subject: Linux-Activists Digest #227
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Mon, 13 Sep 93 20:13:19 EDT

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 ([email-masked])
  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: [email-masked] (A Wizard of Earth C)
Subject: Re: shared libraries (was BSD UNIX)
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.

>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
                                        [email-masked]
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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

From: [email-masked] (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: [email-masked]
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: [email-masked] (John V. Jaskolski)
Subject: 525 Meg Tandberg Tape Drives NICE PRICE
Date: 13 Sep 93 17:22:58
Reply-To: [email-masked]

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

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

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

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

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

Crossposted-To: comp.os.linux.help
From: [email-masked] (Alexander Otterbein)
Subject: Re: ext2_new_block: unable to locate free bit
Date: Mon, 13 Sep 1993 23:33:35 GMT

In article <[email-masked]> [email-masked] (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
-> [email-masked]
-> [email-masked]
-> FIDO : 2:248/158.5

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

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

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

-- 
-Anthony

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

From: [email-masked] (Brandon S. Allbery)
Subject: Re: Bootdisk made by SLS install hangs during boot
Date: Mon, 13 Sep 1993 23:34:50 GMT

In article <[email-masked]> [email-masked] (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         [email-masked]          [email-masked]
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  [email-masked]

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

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

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

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

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