From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sun, 27 Feb 94 20:13:05 EST Subject: Linux-Development Digest #506 Linux-Development Digest #506, Volume #1 Sun, 27 Feb 94 20:13:05 EST Contents: Re: effectiveness of cache ram? (Eric J. Schwertfeger) Connecting IPX to IP (Edward van der Jagt) Re: undefined symbols in modules (Frank Lofaro) Re: Specialix driver (Frank Lofaro) Re: BSD file system for linux ? (Matthias Urlichs) pl15h I/O-prob sdb1 "mount -t msdos -o ..." (Karl Eichwalder) Re: Specialix driver (Wayne Schlitt) Re: effectiveness of cache ram? (Steffen Neumann) Re: PLEASE use the GPL -- NOT (Kelly Murray) Re: PLEASE use the GPL -- NOT (Craig Burley) Multiple Inheritance with G++ (Jeffrey Stockett) SOLUTION: floppy: drive 0 is write protected (Johannes Stille) Re: Specialix driver (Kai Henningsen) Re: Specialix driver (Kai Henningsen) Re: [Q] Is there Shared Library for GNU Readline ? (Thomas Pfau) ---------------------------------------------------------------------------- From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: Re: effectiveness of cache ram? Date: Sat, 26 Feb 94 17:46:09 GMT In article <1994Feb26.053219.3414@bhami.wimsey.com> bhenning@bhami.wimsey.com (William Henning) writes: >In article <2khf69$8o9@jake.esu.edu> tbriggs@myhost.subdomain.domain (Tom Briggs) writes: >>I believe, from my experience, that if you are talking 386, you want >>as much cache as you can get. If you are talking 486, RAM cache is not >>really all that extravagent. I have seen 486/33 DX with 64k, 128, and 256k >>and all of them performed the same. > >The above is absolutely true for trivial benchmarks such as SI, Landmark, >etc., that fit into the 8k on-chip cache. The above is FALSE for large >programs. Agreed. >Test setup: > >VLB Intel 486DX2-66, 256k cache, 16Mb ram, WD250 mb HD, OS/2 v2.1 > >Test: > >Compilation/linking of ~100k of C source code with icc. > >With internal/external caches enabled: about 2 minutes >With internal cache enabled, external disabled: about 6 minutes >With internal and external caches disabled: about 8 minutes >With internal cache disabled, external enabled: about 3 minutes > >(Numbers from memory) > >>So, no, I would say that more memory is a better thing than more cache. > >More memory is ALLWAYS a good thing. If you swap a lot, cache efficiency >gets lost in the time spent swapping. If you are not swapping, the more >cache the better. Also agreed. I find that the external cache did make little difference when I was compiling the Linux kernel with 4 Meg of ram, but at 8 or 16Meg, it makes a profound difference (though not as much as posted above). for the latter, disabling the external cache cost about 5 minutes compile time, but only 3 minutes for the former. I never did figure that one out :-) -- Eric J. Schwertfeger, maniac@cs.unlv.edu ------------------------------ From: bivdjagt@cs.few.eur.nl (Edward van der Jagt) Subject: Connecting IPX to IP Date: Sun, 27 Feb 1994 15:07:24 GMT I've recently bought a diskless workstation/terminal, which has been setup for use with a Novell network (with a boot-prom). It is not possible to attach any drives to the terminal. The boot-prom cannot be replaced either, because no new ones are made anymore (outdated). I also have a PC running Linux (a Unix-clone) with tcp/ip and nfs support. What I want is the following: - connect the terminal by ethernet to my Unix-machine (server) - let the terminal boot DOS from an image obtained from the server (just as it would in a Novell-network) - let the terminal use programs from drives on the server (DOS-programs ofcourse) It is not necessary to have any security-checks, I just want to run programs on the terminal, coming from the (UNIX-)server. What I am now looking for, is any information or sources of programs, possibly contributing to the solution of the problem stated above. And, particularly, specifications of the IPX/IP/NetBIOS protocols. Edward bivdjagt@cs.few.eur.nl ------------------------------ From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Re: undefined symbols in modules Date: Sat, 26 Feb 94 22:24:16 GMT In article <1994Feb26.105501.5976@pe1chl.ampr.org> pe1chl@rabo.nl writes: >In <2klvfa$gtv@bigblue.oit.unc.edu> ewt@sunSITE.unc.edu (Erik Troan) writes: > >>Since my girlfriend left me for a while this afternoon, I started to play >>with module development, using modutils-0.99.15.tgz as uploaded >>to sunsite. > >>Everything was going dandy until I tried to use call get_chrfops. When >>I try to load the module, I get the message "_get_chrfops undefined", >>though it appears in /usr/src/Linux/zSystem.map. > >>ie: > >>[3] insmod drv_load.o >>_get_chrfops undefined >>[4] grep chrfops /usr/src/linux/zSystem.map >>0011e000 T _get_chrfops > >>I can call register_chrdev(), schedule(), access current, etc. with >>no problems. I tried relinking my kernel to no avail. > >>Any clues? > >>Erik > >I think you should put the symbol in kernel/ksyms.S, the list of symbols >exported to modules. > How about someone changing the modules code to not depend on a static ksyms list? If I while having a system running, want to use a module to load code that depends on functions or variables not provided for in ksyms, I have to recompile after adding it to ksyms and reboot before I can use the module. This defeats the purpose of loadable modules. ------------------------------ Crossposted-To: gnu.misc.discuss From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Re: Specialix driver Date: Sat, 26 Feb 94 22:29:43 GMT In article <1994Feb26.144315.13456@infodev.cam.ac.uk> Chris Royle writes: > >I'm disgusted by all this prevaricating that's going on. I suggest Specialix >get on and do it. > A lot of the discussion has veered from the facts of the case. IN SHORT: WHAT SPECIALIX WANTS TO DO IS LEGAL. It is only trivially different than they making GPL'd patches to the kernel, and having you do cat /some/proprientary/file > /dev/device to load the device. Would that file get infected by the GPL? Surely not. What they were suggesting was not much different. People should READ the original post. ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: BSD file system for linux ? Date: 27 Feb 1994 11:59:01 +0100 In comp.os.linux.development, article <140044@hydra.gatech.edu>, gt8134b@prism.gatech.EDU (Robert Sanders) writes: > > Maybe once 4.4-Lite comes out someone will get bored and port FFS > and the log-based filesystem to Linux. Matthias Urlichs has already > ported the BSD networking code, so it shouldn't be *that* difficult. > Unfortunately, not true. The networking code is reasonably separate from the rest of the kernel. File system stuff, on the other hand, depends on quite a few kernel internals, among them organization of inode/vnode/struct file/superblock/et al, which are somewhat different between Linux and BSD. "Get it to compile and add a few bytes of glue code", which is essentially what I did for the networking code (OK, so the interrupt handling had to be tweaked), won't be enough if you want to port the FFS. -- Forwarded for your consideration - you hold the bag for a while -- Glossary of important business terms -- Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.noris.de Schleiermacherstraße 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Click here. ------------------------------ From: karl@pertron.central.de (Karl Eichwalder) Subject: pl15h I/O-prob sdb1 "mount -t msdos -o ..." Date: Sun, 27 Feb 1994 10:27:59 GMT Configuration: 386DX33, Adaptec 1542B, Quantum LPS 240, Syquest 44MB, NE2000 clone, ET4000. pl15h, libc.so.4.4.4, ld.so.1.4. mount --version: Linux bootutils 0.99.14 (=linux-util-1.4,tar.gz). Until yesterday special mount options work w/o any prob, e.g.: # mount -t msdos -o conv=auto,uid=405,gid=50,umask=027 /dev/sdb1 /mnt/sq But now user 405 couldn't copy files from the Syquest medium (for root the same). $ cp -a /mnt/sq/a1 ~ will produce somthing like: $ ll ~/a1 -rwxr-x--- 1 karl group 416 Feb 19 10:00 00index.txt* -rwxr-x--- 1 karl group 418 Feb 19 08:30 devs.tgz* -rwxr-x--- 1 karl group 3623 Feb 5 07:48 diska1* -rwxr-x--- 1 karl group 196 Feb 15 21:04 etc.tgz* -rwxr-x--- 1 karl group 397 Feb 16 23:08 hdsetup.tgz* -rwxr-x--- 1 karl group 3012 Feb 5 07:48 idekern.log* -rwxr-x--- 1 karl group 662 Feb 5 07:48 idekern.tgz* -rwxr-x--- 1 karl group 182 Feb 5 07:48 lilo.tgz* -rwxr-x--- 1 karl group 2789 Feb 5 07:48 maketag* -rwxr-x--- 1 karl group 3861 Feb 5 07:48 scsikern.log* -rwxr-x--- 1 karl group 142 Feb 5 07:49 scsikern.tgz* -rwxr-x--- 1 karl group 102 Feb 15 01:38 sysvinit.tgz* -rwxr-x--- 1 karl group 4036 Feb 5 07:49 tagfile* -rwxr-x--- 1 karl group 4036 Feb 5 07:49 tagfile.org* -rwxr-x--- 1 karl group 876 Feb 5 07:49 tagfile.pat* The contents of the files are still missing. BTW `mount mount -t msdos /dev/sdb1 /mnt/sq' works alright. Seems the same w/ mtools: pertron:~# mcopy /mnt/sq/a1/lilo.tgz a: Copying LILO.TGZ putcluster: fread: No such file or directory mwrite: Disk full #### No !!! ->| pertron:~# mdir | Volume in drive A has no label | Directory for A:/ 00INDEX TXT 104 11-03-93 9:02a DISKA10 264 10-22-93 3:57a GCC245 TGZ 533570 11-02-93 10:45p GXX245 TGZ 787416 10-22-93 3:58a RAWRITE EXE 13052 12-15-93 10:50a | ETC TGZ 55475 2-15-94 8:04p | 6 File(s) 66048 bytes free <---------------<--<---| pertron:~# ll /mnt/sq/a1/lilo.tgz -rwxr-x--- 1 karl group 55420 Feb 5 07:48 /mnt/sq/a1/lilo.tgz* -- | Internet : keichwa@gwdg.de | : karl@pertron.central.de Karl Eichwalder | Fido : 2:2437/210.55 ------------------------------ From: wayne@backbone.uucp (Wayne Schlitt) Subject: Re: Specialix driver Date: Sun, 27 Feb 1994 18:41:12 GMT Reply-To: wayne@cse.unl.edu In article ddj+@cs.cmu.edu (Doug DeJulio) writes: > The FSF got mad and their lawyers contacted NeXTs lawers, or something > like that. In the end it was determined that since you couldn't use > those .o files without linking them to GPLed sources, they were > obviously a derivative work and so they fell under the GPL as well. > > The result: NeXT was forced to release their Objective-C compiler > under the GPL. That's why GCC includes an Objective-C compiler today. I believe that this is a distortion. FSF did contact NeXT, but did not _force_ them to release their work. The did _convince_ them that they should, but link kit technique does seem to be a legal way of distributing stuff. FSF has _never_ sued anyone. When they find out about something that is questionable, the _do_ contact the people involved for clarifications and such. To me, this seems like a reasonable thing to do. -wayne -- The Fundamental Problem with USENET is that you have at least a couple of hours, if not a day or so to think up that witty, absolutely devastating retort... The other Fundamental Problem is people don't even take a couple of minutes to think before they hit that send key... ------------------------------ From: sneumann@TechFak.Uni-Bielefeld.DE (Steffen Neumann) Subject: Re: effectiveness of cache ram? Date: Sun, 27 Feb 1994 18:29:45 GMT In article jrozes@allegro.cs.tufts.edu (J Rozes) writes: Newsgroups: comp.os.linux.development Path: news.uni-bielefeld.de!news.dfn.de!news.coli.uni-sb.de!sbusol.rz.uni-sb.de!xlink.net!howland.reston.ans.net!noc.near.net!news.tufts.edu!jrozes From: jrozes@allegro.cs.tufts.edu (J Rozes) Sender: news@news.tufts.edu (USENET News System) Organization: Tufts University Computer Science Dept. Date: Thu, 24 Feb 1994 04:16:31 GMT Lines: 10 I am looking at new system boards and have come across a few boards that support rather large (by pc standards) caches. I am wondering how a large cache (512k - 1meg) would affect linux performance. Any theories and/or experiences would be appreciated. Basically it boils down to this: is it worth it for me to sink an extra $150-200 into a big cache, or should I stick with 256k and spend the extra money on $150-200 of ram (don't know how much that buys these days)? thanks, jonathan Well, I read some of the followups talking about what / and how cache will boost performance. Of course everything depends on the board design, so I will fire up somethiung that might be ridiculous on first sight: get a board without cache! ????? (I apologize for eventually being somewhat inprecise in correct numbering...) In the german computer journal c't 1/94 (maybe 12/93 or 2/94) there was a nice article about the SHASTA Chipset by Headland. They showed some figures about the waitstaites neccessary. Of course a good designed cache might be able to do an 2-1-1-1 if there is a cache-hit. But it can slow down to something like 14-4-4-4 (Sorry, memory is lacking exact figures...) if everything goes wrong. The Shasta uses bank interleaving, like the good old NEAT boards. That means you can decrease the waitstaites compared to the standard system designs down to 4-2-2-2 in EVERY case. So due to the fact that there are more cache-misses using Linux compared to DOG/Windos that matters even more than the top speed like 2-1-1-1. (There were also figures given on locality of code dos/linux) So, first I would like someone with that magazine at hand to rewrite this article using correct facts and second hear about experiences with that chipset Steffen -- Steffen Neumann Computer science is the dangerous try sneumann@techfak.uni-bielefeld.de to overcome human intelligence ------------------------------ From: kem@prl.ufl.edu (Kelly Murray) Subject: Re: PLEASE use the GPL -- NOT Date: 27 Feb 1994 20:29:34 GMT In article , birkholz@ai.mit.edu (Matt Birkholz) writes: |> From: kem@prl.ufl.edu (Kelly Murray) |> Newsgroups: comp.os.linux.development |> Date: 23 Feb 1994 23:52:20 GMT |> References: |> |> [...] |> Maybe after everyone else has debugged it, extended it, passed it around, |> wrote scripts for it, learned to use it, wrote HOW-TO's and documention for it, |> the authors might suddenly claim their original work was really very |> valuable, and they should get compensated for it now. |> |> Duh. Then I keep my well-debugged version under the license upon which we |> already agreed and ignore them. I even keep getting new versions from the |> net as debugging and extending continue. They can't stop me; they can't |> change the conditions of the agreement after the fact. Even if they could, |> it is tantamount to breach of contract. |> |> Considering how little the GPL constrains your work, I'm surprised to see |> you grasping at straws. |> |> If you don't agree with the goals of the GPL, don't use it. Is somebody |> holding a gun to your head? |> I agree with you! I'm afraid you misunderstood my comment. The quoted material refers to NON-GPL'd licenses which include ADDITIONAL restrictions BEYOND the GPL. Thus as much as I believe the GPL is misguided, it IS better than some licensing used by some people, which is what Russ Nelson was complaining about. If there is a Gun pointed at anyone, it is the one held by the GPL lawyers that are trying to protect everyone by telling me I can't use their software in my programs. -- - Kelly Murray (kem@prl.ufl.edu) University of Florida Parallel Research Lab 96-node KSR1, 64-node nCUBE See NCX's home page or send mail to ncx@netcom.com for deals on Actix S3 Video cards: GE32+ $115, GE32iVL/2mb $219, Ultra+2mbVram $299 ------------------------------ From: burley@apple-gunkies.gnu.ai.mit.edu (Craig Burley) Subject: Re: PLEASE use the GPL -- NOT Date: 27 Feb 94 16:28:25 In article <2kqvre$mv5@snoopy.cis.ufl.edu> kem@prl.ufl.edu (Kelly Murray) writes: If there is a Gun pointed at anyone, it is the one held by the GPL lawyers that are trying to protect everyone by telling me I can't use their software in my programs. Fortunately, that gun is mythical, since GPL lawyers aren't telling you you can't use their software in your programs. In fact, GPL supporters, and the GPL itself, actually encourage you to do so. -- James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu Member of the League for Programming Freedom (LPF) lpf@uunet.uu.net ------------------------------ From: stockett@quadralay.com (Jeffrey Stockett) Crossposted-To: comp.os.linux.help,gnu.g++.help Subject: Multiple Inheritance with G++ Date: 27 Feb 1994 22:32:12 GMT Hello all, In trying to port some code that works fine under every cfront 2.x and 3.x compiler I know of, I've run into a problem with G++. In short, it seems to be whacking out on multiple inheritance. I have a class as follows: class stringstream : virtual public ios, public gstreambuf, public iostream { ... } Is anyone out there using this many levels/kind of multiple inheritance with G++? Does G++ support it correctly? We really want to port some of our applications to Linux, but as we use this class stringstream in many places, we are stuck until such time as a fix is found. Regards, -- ************************************************************************ * Jeffrey M. Stockett * Tel: (512) 346-9199 Fax: (512) 346-8990 * * Quadralay Corporation * FTP Address: ftp.quadralay.com * * stockett@quadralay.com * WWW Server: www.quadralay.com * ************************************************************************ "Software Development Tools That Work The Way You Do!" ------------------------------ Crossposted-To: comp.os.linux.help From: johannes@titan.westfalen.de (Johannes Stille) Subject: SOLUTION: floppy: drive 0 is write protected Date: Sun, 27 Feb 1994 16:50:30 GMT In article <2kg9e0$38k@europa.eng.gtefsd.com> niemidc@oasis.gtegsc.com writes: >In article 23489@unlv.edu, ftlofaro@unlv.edu (Frank Lofaro) writes: >... >>Here's an idea. >>Have the kernel not allow a filesystem to be mounted read-write if the >>media is write-protected. That way writes will fail with EROFS error >>instead of not knowing until the sync. This is useful. Also we shouldn't allow opening the disk device read-write when the disk is write protected. >Unfortunately, 'tis not so easy on floppies. People remove/insert >floppies without the system necessarily knowing about it. Thus a >read-write medium may be replaced by one that is read-only; a second >check is needed to determine whether or not the floppy is writable. This is a problem I have no solution for yet (see below). >The second gotcha is that it seems to be very difficult or impossible >to detect write-protectedness other than by actually writing to the >floppy. If I find a way to do it, I'd be glad to implement it, but >I'm not sure this is really possible (and it would be highly anti- >social to go trying to write to floppies when they are mounted, even >if it is a write of the data already there). But in this point, I can help. The floppy controller has a "get status" command which you can use to read the status register ST3 which in turn contains a Write Protected bit. >If anyone knows how to detect either floppy changes (without repeated >polling of the drive) or write protected floppies (without actually >writing to the disk), please let me know. I know there are hardware >signals from the drive that would remedy both of these problems; but >as far as I can tell these are not directly accessible via the FDC. >--- >David C. Niemi David.Niemi@oasis.gtegsc.com >------------------------------------------------------ >Now I must sit here and ponder the yonder >Herbivores ate well 'cause their food didn't never run > > I have implemented the write-protection check in the floppy_open function. So the check is made both for just opening the device file and for mounting. There are two problems left: 1. There is no check yet when the floppy is remounted. So you can mount a write protected floppy read only and then remount it read-write. I'm not sure how this is handled best. Maybe we should add a reopen pointer to the file operations for a function that is called when the access mode of the file is changed. This would only be used for remount, so it is probably overkill, but IMHO it's the most clean solution. Any comments? 2. There is no wp check at all if the floppy is changed while it is opened/mounted. Again, I don't know what one could do in this case. In theory, I think we should forcibly close all files open on the floppy and unmount it, even without updating. Or would this break a multi-volume tar? Checking for write protection is then only a minor additional problem. Anyway, I don't know how one could do this, so I did nothing about this problems. Any ideas are welcome. Additionally, I'm not sure whether EACCES is the correct error to return. Since the patches are quite short, I append them to this article. Be careful, they aren't tested very well. Make backups of your disks before you use them (or write-protect the disks :). If you find a bug in them, please mail me (especially if a process hangs in the disk access (state "D" for ps)). Johannes diff -r --unified=1 linux.14v.beta4.bak/drivers/block/floppy.c linux/drivers/block/floppy.c --- linux.14v.beta4.bak/drivers/block/floppy.c Mon Dec 27 06:23:53 1993 +++ linux/drivers/block/floppy.c Sun Feb 27 17:05:35 1994 @@ -138,3 +138,3 @@ #define ST2 (reply_buffer[2]) -#define ST3 (reply_buffer[3]) +#define ST3 (reply_buffer[0]) /* same place as ST0, but from another command */ @@ -655,3 +655,3 @@ } else { - printk("unknown error. ST[0..3] are: 0x%x 0x%x 0x%x 0x%x\n", ST0, ST1, ST2, ST3); + printk("unknown error. ST[0..2] are: 0x%x 0x%x 0x%x\n", ST0, ST1, ST2); } @@ -833,2 +833,31 @@ + +static int floppy_writeable(int drive) +{ + int r; + + cli(); + while (fdc_busy) sleep_on(&fdc_wait); + fdc_busy = 1; + sti(); + output_byte(FD_GETSTATUS); + output_byte(drive); + + r = result(); + if (r != 1) { + printk("Floppy drive %d: couldn't get status\n", drive); + fdc_busy = 0; + wake_up(&fdc_wait); + return 0; + } + + r = (ST3 & ST3_RY) && !(ST3 & ST3_FT) && !(ST3 & ST3_WP); + + fdc_busy = 0; + wake_up(&fdc_wait); + + return r; +} + + /* @@ -1284,2 +1319,7 @@ check_disk_change(inode->i_rdev); + + if (filp && (filp->f_mode & 2)) + if (!floppy_writeable(drive)) + return -EACCES; + return 0; diff -r --unified=1 linux.14v.beta4.bak/fs/super.c linux/fs/super.c --- linux.14v.beta4.bak/fs/super.c Thu Jan 27 14:05:53 1994 +++ linux/fs/super.c Sat Feb 26 22:16:02 1994 @@ -436,2 +436,3 @@ unsigned long page = 0; + struct file dummy_file; @@ -480,2 +481,6 @@ } + + memset(&dummy_file, 0, sizeof(dummy_file)); + dummy_file.f_mode = (new_flags & MS_RDONLY) ? 1 : 3; + fops = get_blkfops(MAJOR(dev)); @@ -482,3 +487,3 @@ if (fops && fops->open) { - retval = fops->open(inode,NULL); + retval = fops->open(inode, &dummy_file); if (retval) { @@ -500,3 +505,3 @@ if (retval && fops && fops->release) - fops->release(inode,NULL); + fops->release(inode, &dummy_file); iput(inode); diff -r --unified=1 linux.14v.beta4.bak/include/linux/fdreg.h linux/include/linux/fdreg.h --- linux.14v.beta4.bak/include/linux/fdreg.h Wed Dec 1 13:44:15 1993 +++ linux/include/linux/fdreg.h Sat Feb 26 18:35:40 1994 @@ -49,4 +49,7 @@ #define ST3_HA 0x04 /* Head (Address) */ +#define ST3_DS 0x08 /* drive is double sided */ #define ST3_TZ 0x10 /* Track Zero signal (1=track 0) */ +#define ST3_RY 0x20 /* Drive Ready */ #define ST3_WP 0x40 /* Write Protect */ +#define ST3_FT 0x80 /* Fault */ @@ -63,2 +66,3 @@ #define FD_PERPENDICULAR 0x12 /* perpendicular r/w mode */ +#define FD_GETSTATUS 0x04 /* read ST3 */ ------------------------------ Date: 27 Feb 1994 16:38:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Specialix driver ddj+@cs.cmu.edu wrote on 27.02.94 in : > > Let's say I run Linux, and one of it's system calls is unique to the OS > >(It could be another OS like VSTa for example). If I use that unique > >system call, would my code need to be GPLed under the GPL? I'm not exactly > >sure if Linux has unique (non-public) syscalls, but couldn't that > >potentially cause problems? > > That's my understanding, yes. So, you should be *really* careful to > make sure you just use POSIX interfaces. Then there should be no > problem. Since this only revolves on the definition of "derived work", not on the GPL as such (in fact, the GPL seems to explicitely say something quite different about what a "derived work" is), let's transport it to another copyright holder. Is every Windows program a derived work from Windows? Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v2.93 ## ------------------------------ Date: 27 Feb 1994 16:39:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Specialix driver ddj+@cs.cmu.edu wrote on 27.02.94 in : [By the way, you completely ignored the relevant part of the GPL I quoted. What about it? Does it say what it seems to say? If not, why not?] > The FSF got mad and their lawyers contacted NeXTs lawers, or something > like that. In the end it was determined that since you couldn't use > those .o files without linking them to GPLed sources, they were > obviously a derivative work and so they fell under the GPL as well. Still a different animal. The linking process produces something that's quite different from the original, so much that it no longer does what the original did. At least, as much as I can see. That's a lot different from a simple addition. Furthermore, it seems it never got to court? Then it's not useful to show what the law is ... Anyway, it's questionable if what the FSF thinks has any bearing on this discussion, as she doesn't hold the copyright in question anyway. Linus does. Moral: while using the GPL, keep the copyright to yourself. Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v2.93 ## ------------------------------ From: pfau@cnj.digex.com (Thomas Pfau) Subject: Re: [Q] Is there Shared Library for GNU Readline ? Date: 27 Feb 1994 18:18:35 -0500 sunsite.unc.edu:/pub/Linux/libs/librl-1.2.tar.gz librl.README -- tom_p | I could get a new lease on life internet: pfau@cnj.digex.net | if only I didn't need the first compuserve: 73303,1136 | and last month in advance. ------------------------------ ** 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-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@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-Development Digest ******************************