Subject: Linux-Misc Digest #283
From: Digestifier <Linux-Misc-Request@senator-bedfellow.MIT.EDU>
To: Linux-Misc@senator-bedfellow.MIT.EDU
Reply-To: Linux-Misc@senator-bedfellow.MIT.EDU
Date:     Sat, 18 Jun 94 11:13:09 EDT

Linux-Misc Digest #283, Volume #2                Sat, 18 Jun 94 11:13:09 EDT

Contents:
  Re: ST-01 SCSI & Tape Backup (Ken Firestone)
  Re: unix version of dos prog XCOPY? (Lars Wirzenius)
  Re: Limit memory to low 16MB ? (Heiko Herold)
  Re: S3 palette restore problem exiting X server (Terry Gliedt)
  Re: Linux ver 1.0 on an IBM Valuepoint computer? (BAdelsman)
  Re: future of Unixware (Terry Lambert)
  Re: Latest in PC WEEK (May 30 Editorial) (Bjorn Ekwall)
  Yggdrasil CD-ROM question (Mr. Steve Wilkinson)
  Backspace problems in color_xterm (Keith Nelson)
  Re: Latest in PC WEEK (May 30 Editorial) (Tim Smith)

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

From: kenf@clark.net (Ken Firestone)
Subject: Re: ST-01 SCSI & Tape Backup
Date: 18 Jun 1994 13:08:00 GMT

Jim Trocki (trockij@Cyanamid.COM) wrote:
:   Has anyone gotten the Seagate ST-01 SCSI controller to work with
: a SCSI tape drive, such as the Archive 2150S? I have an ST-01 lying
: around, and I'm looking to buy an Archive 2150S tape backup to
: attach to it, and I would like to know if anyone has had success with
: such a configuration.

: Jim Trocki
 
I have yet to get the ST-01 to work period. If anyone can give me some
clues on how to get it working with Linux I would be interested. It
would save me the trouble of tearing the machine apart and putting a
new controller in.

--

============================================================================
Ken Firestone, N3JBU     | If you look at things right, its best not to know 
kenf@clark.net           | who you really are. Because anything that happens 
                         | to anybody who doesn't know who he really is 
                         | actually happens to somebody else. So it makes no 
                         | difference at all. -- Nelson Algren.  
============================================================================

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

From: wirzeniu@cc.Helsinki.FI (Lars Wirzenius)
Subject: Re: unix version of dos prog XCOPY?
Date: 18 Jun 1994 11:47:16 +0300

dcflood@u.washington.edu (David Flood) writes:
> Ok, which part of Slackware has the man pages for cp? man can't find it
> on my machine.

man.tgz (currently on disk ap1, I think) is what you're looking for.

Also try ``cp --help''.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
My name is Ozymandias, king of kings/Look on my works, ye Mighty, and despair!

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

From: hman@arianna.dei.unipd.it (Heiko Herold)
Subject: Re: Limit memory to low 16MB ?
Date: 18 Jun 1994 13:07:05 GMT

In article <1994Jun17.214453.16797@kf8nh.wariat.org>,
Brandon S. Allbery <bsa@kf8nh.wariat.org> wrote:
>In article <2tsp0c$40v@crl.crl.com>, bogdan@crl.com (Bogdan Urma) says:
[..]
>
>If you don't need it, don't use it; it means exactly what it says (any memory
>beyond 16MB will be completely ignored).
>

What about swap ? 
Does that limit the amount of ram or ram+swap ?

Heiko
-- 
\________________/ hman@[paola][chiara][maya].dei.unipd.it \________________/
 DON'T PANIC - The Hitch Hiker's Guide to the Galaxy            {itself}
 PANIC - The Hitch Hiker's Guide to the Galaxy MK II        {Mostly Harmless}
      (perceiving the Whole Sort of General Mish Mash)       [Douglas Adams]

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

From: tpg@trillian.mr.net (Terry Gliedt)
Subject: Re: S3 palette restore problem exiting X server
Date: 18 Jun 1994 13:31:42 GMT
Reply-To: tpg@mr.net

In article <2tt9tb$401@louie.cc.utexas.edu>, andro@louie.cc.utexas.edu writes:
|> Keywords: 
|> Cc: 
|> I saw this problem mentioned here recently -- Upon exiting XFree,,
|> with some S3 boards [mine is a Taiwanese 928 VLB] the palette
|> is not restored correctly, giving me invisible text.
|> 
|> Someone mentioned some Xconfig settings for saving and restoring
|> the palette, but I missed them.  There was a post following claiming
|> the problem was solved by "nomemaccess", so I just went with that.
|> 
|> No such luck for me.  Anyone have the palette save/restore settings
|> for Xconfig?

I run a little shell called runx - which does the following:

#!/bin/csh -f
#       Save fonts for tty, invoke X and then restore the fonts
#/usr/bin/restorefont -w /tmp/fontdata >& /dev/null
if ($#argv == 0) then
  /usr/bin/X11/startx >& /dev/null
else
  /usr/bin/X11/startx
endif
#/usr/bin/restorefont -r /tmp/fontdata >& /dev/null
#       We did not save fonts - just restore'em
#       Get font14 sunsite.unc.edu:/pub/Linux/libs/graphics/svgalib111.tgz
/usr/bin/restorefont -r /usr/local/bin/font14 


-- 

===================================================================
Software Toolsmiths      Terry Gliedt   (507) 356-4710   tpg@mr.net

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

From: badelsman@aol.com (BAdelsman)
Subject: Re: Linux ver 1.0 on an IBM Valuepoint computer?
Date: 18 Jun 1994 09:51:04 -0400


Yes, it works.  If your using the Slackware distribution, you'll need
to specify the hard disk geometry at the 'boot:' prompt and then
modify lilo.conf later on to get lilo to boot automatically from the
hard disk.

Drop me a note if you need details.

-Bruce

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

From: terry@cs.weber.edu (Terry Lambert)
Crossposted-To: comp.unix.unixware,comp.os.linux
Subject: Re: future of Unixware
Date: 18 Jun 1994 07:36:54 GMT

In article <CrCE00.IKo@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes:
>In article <2tbs2u$fu2@u.cc.utah.edu> terry@cs.weber.edu (Terry Lambert) writes:
>>Generally, when 16 port cards are needed on a BSD system, Boca 16-port
>>cards (model number BB2016) are the choice.  Unfortunately, you are at
>>6 IRQs consumed with 96 ports.
>
>As I understand it, wouldn't this setup have *significantly* more hosts
>system load than the current crop of intelligent serial cards?

Well, yes, that's what all the intelligent port venders who want to sell
cards but don't want to provide programming information are saying.  8-).

>>The major advantage to smart cards would be bus-master DMA into clist
>>structs -- the drivers involved would be nearly idenitcal to those
>>in Xenix.
>
>Um, haven't most R4 drivers dispensed with clists in favour of Streams?
>Does this provide a performance boost, or just easier programming?

Just easier programming.  Streams has some real bears concerning
propagation latency that a simple sliding window throughput test
simply won't show, since it will average one latency over the set of
all packets sent.

>>Larger numbers of ports are generally attached using annex hardware, at
>>about $30 per port where it it starts to be cost effective.
>
>I'm not familiar with the term "annex" hardware.

It's a popular type of terminal server.  CRL, NetCOM, and other large
Internet connectivity sellers use them.

>>There is nearly no better soloution for a massive number of ports
>>(like 256) than putting them on the other end of an ethernet;
>>eventually you simply run out of IRQs.
>
>That limitation applies *only* to Linux, since it doesn't have support
>for the commecial cards. Most of the brands I've worked with don't use
>IRQs at all. In fact, some vendors whose drivers once required a spare
>IRQ now produce updated drivers which don't need it anymore (Corollary,
>for one).

The limitation applies to all free UNIX clones.  It also applies to any
small embedded systems shop that sells source.

There are two approaches to the IRQ-per-board problem; the first is to
DMA the information in and have the kernel polling a status status area
that you DMA in later than the data.  This is nasty by definition, but
it can be acceptable for a sufficiently large number of ports, where the
polling overhead per port averages to less than the interrupt overhead
per port.  The second is to cascase the interrupts by using an interrupt
for the first board and providing a register on the board that say "later
board has data" (or just examining all boards) and using an inter-board
jumper to use the first board to send the IRQ; you could daisy chain all
the boards to a single interrupt, and with a bus extender, the number is
limited by the number of card you can use before the poll delay becomes
too large in trying to find the interrupting board.

BTW, BOCA now has a 64 port board.


                                        Terry Lambert
                                        terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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

From: bj0rn@blox.se (Bjorn Ekwall)
Subject: Re: Latest in PC WEEK (May 30 Editorial)
Date: 18 Jun 94 00:44:55 GMT

Tim Smith (tzs@u.washington.edu) wrote:
 > In article <1143@blox.se>, Bjorn Ekwall <bj0rn@blox.se> wrote:
 > >The kernel is GPL-ed. All code that is linked to it is therefore also GPL-ed.
 > >The only interface to the kernel that is non-"GPL-virus-infected" is the
 > >syscall API, as this is explicitly extempt from the GPL.

 > Maybe it works that way in your country, but that's not the way it works
 > over here (United States).  Interfaces are irrelevant.

 > >All "official" interpretations of the GPL, as seen in the numerous
 > >discussions in gnu.misc.discuss, are _very_ clear about this.

 > It doesn't matter what the GPL says.  GPL is a contract.  It therefore
 > can only bind those who are a party to that contract.  If I write some
 > code of my own, and I do not use any GPL'ed code in producing my code
 > (other than uses that would not be covered by copyright), GPL is totally
 > irrelevant to my code.  This is basic contract law.  I can distribute my
 > code under my license terms.

This is an important topic that I feel we have to discuss further.
I know that "logical" is not always the equivalent of "legal",
but I hope it is possible to achieve an interpretation of the GPL
that will satisfy both the "logical" and the "legal" aspects...
I have marked some parts of my arguments below with '*', as being
potentially more debatable than the rest.

There are several separate aspects for different categories of "users":
(Glossary: enhanced kernel = original kernel linked with a module.)

-  What can "I" as the copyright holder of "my" code, e.g. a loadable module,
   legally do with the module, the original kernel and the "enhanced" kernel?

-  What can "I" as the _user_ of someone else's code legally do with
   a loadable module, the original kernel and the "enhanced" kernel?

The basic premise is that an original Linux kernel can only be used, modified
and distributed according to the GPL, which is, as you correctly say,
a contract, that allows my use as long as I follow the clauses in the GPL.
One clause of the GPL is a "shrink-wrap" clause, that says (GPL version 1):
* [
*  5. By copying, distributing or modifying the Program (or any work based
* on the Program) you indicate your acceptance of this license to do so,
* and all its terms and conditions.
* ]
The _effects_ of the GPL won't be noticeable until I try to distribute
a GPL-ed program, since really only the redistribution rights are
of any concern for me in the GPL. What anyone does with a program
in the privacy of ones own "environment" doesn't really matter,
since any "infringements" can't be detected.

* Now, I propose that the "enhanced" kernel is a _derivative_ work of the
* original kernel, and thus _also_ falls under the clauses in the GPL.
This is a reading of the GPL that I think is a reasonable interpretation,
independent of if you agree with the goals of the GPL or not.

If I distribute a whole kernel, "enhanced" or not, as a single binary,
or in parts, in the form of object files, is of no consequence, since I am
distributing a kernel in both cases. The only way I can legally do this
is by abiding to the GPL, i.e. in one way or another supply the source
to the recipient, and granting the recipient the same rights that I have
according to the GPL.

The crucial questions are:
- When does the module effectively fall under the GPL?
- Can anyone (re-)distribute _any_ part of the kernel binary-only?
(Nitpicking time: my definition is that distributions are made
by the copyright holder, anyone else does re-distributions.)

As the copyright holder of a piece of code I am of course free to do
whatever I want with it, as long as I have good title to it... or can I?
* My interpretation of the GPL, on the other hand, tells me that I
* am _not_ allowed to distribute my code as a module for a GPL-ed
* program (i.e. a kernel), _unless_ I distribute it according to the GPL!

If I am _not_ the copyright holder of a module (or part of the kernel),
what am I re-distributing if I redistribute the module?
Am I shipping a random collection of bytes or am I shipping a part of a kernel?
* A kernel, or a part of a kernel, can only be redistributed according to
* the GPL.
Which license "wins", if the module license differs from the GPL?
Has the original distributor "broken" the GPL by distributing the module,
if it could be seen as a part of a kernel (i.e. enhanced kernel)?

The difference between a loadable module and a "traditional" module
is that the loadable module has some _additional_ lines of code.
* If I (re-)distribute a "traditional" module, I am really distributing a
* part of an "enhanced" kernel, and this is legal only if I distribute
* the module according to the GPL.
The interesting question is now: do the _additional_ lines, that were
added to the module in order to make it loadable, remove the "GPL-ness"
of the original module, or shouldn't the loadable module be seen as a
derivative work of the non-loadable (and thus GPL-ed) module?

* Another way to put it is that a module is _definitely_ a part of the
* (enhanced) kernel when it is linked to the kernel. This makes me think
* that the module was a part of a kernel even _before_ it was linked/loaded.
* The intent, and only practical use, of a module is to link it to a kernel.
* Thus, the module probably becomes a part of a kernel as soon as it is coded,
* almost certainly when it is (re-)distributed, and definitely when it is used.
* Therefore one could conclude that a loadable module can only be legally
* distributed according to the GPL. I.e. the module has to be GPL-ed.


If this was a simple problem, we would have solved it a long time ago...

Bjorn Ekwall == bj0rn@blox.se

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

From: wally@perot.mtsu.edu (Mr. Steve Wilkinson)
Crossposted-To: comp.os.linux.help,comp.os.linux.development
Subject: Yggdrasil CD-ROM question
Date: 18 Jun 1994 14:55:49 GMT

I have an NEC3xi with a SoundBlaster 16 SCSI-II!  Yggdrasil CD-ROM does
not mount the CD.  
        q1) Is someone working on supporting this card?
                if( answer_to_q1==YES) when will an alpha or beta be avaliable 
                        and how can I get a copy?
        if(answer_to_q1==NO) 
          q2)  What other SoundBlaster cards will both Yggdrasil Linux
                CD-ROM and NEC3xi work with?
          q3)  Is someone going to add support for the SCSI-II
                SoundBlaster 16 card?
          q4)  Does anyone have specifications for SCSI-II interface for
                SoundBlaster 16?  If not where can we get them?  May be myself 
                and a friend would like to write a driver for it?  Remember we
                are poor and can't pay the $70 developer fee that CreativeLabs 
                is asking for!

Thanks in advance,
Steve Wilkinson (wally@knuth.mtsu.edu)
(known for being a planets nerd!  yes he even likes the Cyborgs!)

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

From: keith@pleiades.newcastle.edu.au (Keith Nelson)
Subject: Backspace problems in color_xterm
Date: Sat, 18 Jun 1994 02:04:48 GMT

   When i start color_xterm from open looks olvwm menus, 
the backspace and delete keys come out as a line feed.
It works fine if i start the color_xterm from another
xterm. How would the menu choice :

"Color Xterm (7x14 font)"               exec /usr/bin/X11/color_xterm -sb -sl 500 -j -ls -fn 7x14

in olvwm menu differ from the command

$ color_xterm -sb -sl 500 -j -ls -fn 7x14 &

to make such a thing happen ?

Any help much appreciated.

Keith.

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

From: tzs@u.washington.edu (Tim Smith)
Subject: Re: Latest in PC WEEK (May 30 Editorial)
Date: 18 Jun 1994 14:55:35 GMT

In article <1145@blox.se>, Bjorn Ekwall <bj0rn@blox.se> wrote:
>* Now, I propose that the "enhanced" kernel is a _derivative_ work of the
>* original kernel, and thus _also_ falls under the clauses in the GPL.

[The following is in terms of U.S. law]

Correct.  It's a derivative work of both the original kernel and any
other things that have been linked in.  It's important to note that the
reason it is a derivative work is because copyright law says that it is,
not because of anything in the GPL.  The relevenace of the GPL here is
that since the original kernel was GPL'ed, things that are derivative
works of the original kernel must be GPL'ed.

>If I distribute a whole kernel, "enhanced" or not, as a single binary,
>or in parts, in the form of object files, is of no consequence, since I am
>distributing a kernel in both cases. The only way I can legally do this
>is by abiding to the GPL, i.e. in one way or another supply the source
>to the recipient, and granting the recipient the same rights that I have
>according to the GPL.

Corrent, but not because you are distributing a kernel.  You need to
abide by the GPL becuase you are distributing a derivative work of
copyrighted GPL'ed source, and it is the GPL that gives you permission
to do so.

>The crucial questions are:
>- When does the module effectively fall under the GPL?

There's no such thing as "effectively" falling under GPL.  Either it does
or it does not.  The answer is simple: when the copyright holder places
it under GPL.

>As the copyright holder of a piece of code I am of course free to do
>whatever I want with it, as long as I have good title to it... or can I?
>* My interpretation of the GPL, on the other hand, tells me that I
>* am _not_ allowed to distribute my code as a module for a GPL-ed
>* program (i.e. a kernel), _unless_ I distribute it according to the GPL!

You are overlooking the fact that GPL is a contract.  You are not a party
to that contract, and so cannot be bound by its terms.  Let's consider for
a moment how GPL becomes binding on someone.  It becomes binding on them
when they do something that GPL allows that they would not otherwise be
allowed to do.  For example, if I distribute copies of some GPL'ed code
that I do not own the copyright to, then I've got two choices: (1) follow
the terms of GPL, or (2) be guilty of a copyright violation.

(Note: this is quite different from the usual "shrinkwrap" license that
comes with commercial software.  They usual "shrinkwrap" tries to stop
you from doing things that you would otherwise be allowed to do, such
as make backups, and tries to claim that you accept the license by
doing things that you would be normally allowed to do, such as open
the package and run the program.  This is what makes such licenses
very unlikely to be legally binding.  GPL, on the other hand, authorizes
you to do things that you could not normally do--modify and distribute
the software--and so is in much firmer ground legally than the usual
shrinkwrap.)

If you write a module that is not a derivative work of someone else's
copyrighted code, and then distribute that module under whatever terms
you want, you are not doing anything that violates anyone else's copyright.
You are simply exercising your rights as copyright holder.  That cannot
serve as the basis for you acceptance of a contract unless you explicitly
say that it will.

>If I am _not_ the copyright holder of a module (or part of the kernel),
>what am I re-distributing if I redistribute the module?
>Am I shipping a random collection of bytes or am I shipping a part of a kernel?
>* A kernel, or a part of a kernel, can only be redistributed according to
>* the GPL.

It's not relevant that it is a kernel.  What is relevant is that you
obtain permission from the copyright holders for all the code that you
are distributing.  This means that you need the permission of the
holder of the copyright on the module, and of the holders of the
copyright on everything that the module is a derivative work of.

For example, if I write a Linux driver, being careful to not make it
a derivative work of the kernel (which I can do unless someone can
claim a copyright on the names and calling sequences of kernel
routines, which I doubt, because of section 102(b) of the Copyright
Act of 1976, which says "In no case does copyright protection for an
original work of authorship extend to any idea, procedure, process, system,
method of operation, concept, principle, or discovery, regardless of the
form in which it is described, explained, illustrated, or embodied in such
work."), and I make my driver public domain, you can distrinute it in
any form you wish, because your doing so does not violate anyone's
copyrights, and so you don't need any license to authorize your actions.

>Which license "wins", if the module license differs from the GPL?

For distribution of the module alone, the module license is all that
matters (assuming, as always, that the module's author was careful
to keep GPL'ed code out of the module).  For redistribution of the
module combined with the original kernel to form an enhanced kernel,
bot licenses apply.  The person who wants to distribute the enhanced
kernel has to comply with the license of every piece of code that is
being distributed.  If the module license and the GPL are incompatible,
then it is quite possible that the enhanced kernel cannot be distributed
at all.

>Has the original distributor "broken" the GPL by distributing the module,
>if it could be seen as a part of a kernel (i.e. enhanced kernel)?

The original distributor can only break the GPL if the original distributor
has doen something to make GPL applicable to them, e.g., done something to
GPL'ed code that would not otherwise be allowed.

>The difference between a loadable module and a "traditional" module
>is that the loadable module has some _additional_ lines of code.
>* If I (re-)distribute a "traditional" module, I am really distributing a
>* part of an "enhanced" kernel, and this is legal only if I distribute
>* the module according to the GPL.

Copyright law doesn't care what you are "really" distributing.  It cares
what you actually distributing.  You are distributing a hunk of code, and
the relevant copyright question is whether or not you are the sole
copyright holder on what you are actually distributing or if there are
works yours is a derivative work of.

Now, there is one way that you might be found to be in violation of the
kernel copyright by distributing something that is not a derivative
work.  That is if your distribution can be seen as "contributory
infringement".  The key to contributory infringement is that you work
has to be such that the people you distribute too basically have no
use for it other than to use it to infringe someone's copyright.
(The idea here is that the person whose copyright is being infringed
by the end users should not have to sue hundreds or thousands or
millions of end users one at a time to stop the infringement--they
should be able to go after those who are enabling the infringement).

Contributory infringement seems to require some very blatant behavior.
An example would be a store that rents pre-recorded tapes and also
sells blank tape and has a tape duplication system available for
customer use and operation.  (Yes, someone actually tried this).

This is where the question of what GPL requires of recipients of GPL'ed
software comes in.  If I take some GPL'ed software, and link it with some
non-GPL'ed software, for use on my own machine, have I violated GPL?
I seem to recall that the FSF has said "no" when asked this.  If that
is the case, then it is very unlikely that one who distributes a
module for use in GPL'ed code will be found to a be a contributory
infringer, because there will be a substantial non-infringing use of the
module--that being the use of the module by people who do not want to
redistribute the kernels they build.

--Tim Smith

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


** 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-Misc-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.misc) via:

    Internet: Linux-Misc@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
    sunsite.unc.edu				pub/Linux

End of Linux-Misc Digest
******************************
