From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 20 Nov 93 07:13:38 EST Subject: Linux-Development Digest #240 Linux-Development Digest #240, Volume #1 Sat, 20 Nov 93 07:13:38 EST Contents: Re: Don't use Motif for free sw: it now requires runtime royalties! (Joe Moss) Re: corewar (Lou Williams) daemon() and in_systm.h (Dennis Lou) Re: Don't use Motif for free sw: it now requires runtime royalties! (Steve Davis) Re: olvwm for linux? (Dr Eberhard W Lisse) Re: Thought... (Harald T. Alvestrand) Using Linux to create SCO binaries? (David Wright) [Q] bdevsw/cdevsw -- where? (Jan Kasprzak) Re: Don't use Motif for free sw: it now requires runtime royalties! (Peter Galbavy) Keyboard timing out in pl13r (Steve Tinney) looking for lost clock ticks & interrupts, sti/cli profiling (Harald Koenig) ---------------------------------------------------------------------------- Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: joe@morton.rain.com (Joe Moss) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Fri, 19 Nov 1993 21:13:46 GMT ehhchi@maroon.tc.umn.edu (Ed H. Chi) writes: >I vote tk/tcl to be the toolkit of the choice. If you have never looked >at tk/tcl, it is the time NOW. Agreed. >O'Reilly will be coming out with a tc/tkl Book in the early '94 (it is >written by a professor at Brekeley whose name has escaped me.) I have >seen a draft of the book, and this book is *good*. John Ousterhout's book will be published by Addison-Wesley - not O'Reilly -- Joe V. Moss | joe@morton.rain.com Morton & Associates | joem@m2xenix.psg.com 7478 S.W. Coho Ct. | - or - Tualatin, OR 97062-9277 | uunet!m2xenix!morton!joe ------------------------------ From: nsyslaw@riogrande.acs.ncsu.edu (Lou Williams) Subject: Re: corewar Date: Fri, 19 Nov 1993 19:41:32 GMT Roland Kwee (rkwee@ursula.ee.pdx.edu) wrote: : >bonne@cs.utwente.nl (Bonne van Dijk) writes: : >Christophe Dorchies (christophe.dorchies@cld9.com) wrote: : >>salut : >> je m'interesse de tres pres au COREWAR ces prg qui luttent . . . : >Ek groetnis fan dizze kant, kinne jo ek frysk skruiwe, dat kin ik better : >l\^eze as dit taaltsje. No kin ik wol ingelsk, do ek?? : >Free translation: : >Greetings from this side, can you write Frisian (Language from the : >NorthWest part of the Netherlands). It's easier to read that (for me that is : >:) ). Now I know some english, U2? : It looks like Bonne doesn't like messages posted in French. Does it say : somewhere that everybody has to use English on the Internet? : Please let the Internet be for EVERYBODY and let people write in the : language they prefer without making fun out of them if it isn't English. : In real life most agree (at least with their mouth) that we should not : discriminate on race, gender, etc. Let us in the Hi-Tech world be ahead : of real life and also abolish non-productive discrimination : on language. : Although many poke fun out of ``veteran'' computer languages like : Cobol and Fortran, they have their place among the ``modern'' : languages like C. And nobody really tries to force all the others : to use the ``best'' language, whether Lisp, C++ or ...(?). : The circumstance that Bonne reads Frisian easier than French is fine. : I am also from Holland (living in the US), but find French easier. : More to the point is that somebody posting in French should not expect : many replies from the United States. : Okay, with my blood pressure back to normal, I wish the many : French-speaking Linux-fellows happy computing. : --Roland Kwee RolandKwee@ACM.org How's this: -... ..- - .. -.. --- -. - -.- -. --- .-- .- -. -.-- --- ..-. - .... --- ... . ..-. .- -. --. ..- .- --. . ... .-.-.- Sorry, couldn't resist! -- Lou Williams (nsyslaw@acs.ncsu.edu) | Amatuer Radio: KE4ARM Unix Systems Programmer | Phone: (919) 515-2794 NCSU Administrative Computing Services | FAX: (919) 515-3787 -- Ack! Thpppppffffffft!!!! -Bill The Cat. ------------------------------ From: dlou@sdcc3.ucsd.edu (Dennis Lou) Crossposted-To: comp.os.linux.help Subject: daemon() and in_systm.h Date: 19 Nov 93 09:11:56 GMT I am trying to recompile dip 3.2.2a as well as 3.3.4a and am having problems. I first tried to recompile 3.2.2a and got it to compile but not link. Seems that there's a call to daemon in p_slip.c that it can't find. I couldn't find daemon() in the manpages nor in any of the std include files. Could someone please tell me where this function is (i.e. what library and what include file). Well anyway, after giving up on 3.2.2a I got 3.3.4a and tried to compile that. It seem that ipdump.c is trying to #include Looking in /usr/include/netinet I found a file called in_system.h so I edited ipdump.c After that, I found that /usr/include/in_system.h contains only one line and it tries to #include and that file is non-existant! What gives? I'm using Slackware 1.0.5 Thanks in advance. -- Dennis Lou || "But Yossarian, what if everyone thought that way?" dlou@ucsd.edu || "Then I'd be crazy to think any other way!" [backbone]!ucsd!dlou |+==================================================== dlou@ucsd.BITNET |Steve Jobs and Steve Wozniak went to my high school. ------------------------------ From: strat@cbs.ksu.ksu.edu (Steve Davis) Crossposted-To: comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: 19 Nov 1993 04:44:29 -0600 mjr@syl.dl.nec.com (Matt Ranney) writes: >rick@digibd.digibd.com (Rick Richardson) writes: >>Statically linked Motif binaries are simply too large to be of much value. >Tell that to the thousands of people who run the static binary of >NCSA's Mosaic for X on their Suns. I run a static binary of NCSA's Mosaic on suns. strat@cbs:~> size `which Mosaic` text data bss dec hex 1826816 172032 167280 2166128 210d70 And this is with a number of optional packages commented out of the makefile. If Rick couldn't say it, I certainly can: Statically linked Motif binaries are simply too large ... -- Steve Davis (strat@cis.ksu.edu) Kansas State University "The faults in bad software can be so subtle as to be practically theological" -- Bruce Sterling ------------------------------ From: el@lisse.NA (Dr Eberhard W Lisse) Subject: Re: olvwm for linux? Date: Thu, 18 Nov 1993 20:29:26 GMT clark@ist.flinders.edu.au (Steven R Clark) writes: >In article 30i@news.ysu.edu, ai539@yfn.ysu.edu (Kent Fox) writes: >> >>Has anyone recompiled olvwm for a modern linux kernel/gcc/XFree86? >>I'm having problems in slave.c ... and can't seem to trackdown >>getrlimit() or RLIMIT_NOFILE. Any help would be appreciated. >My effort bombed out before that, still tracking down the problem. If you get the >thing to compile, perhaps you could put it on sunsite (some hints in a text file on >how you got it to compile might be a good idea too - I'd be interested anyway) The complete open windows distribution (Xview and olwm) comes with SLS 1.0.3 and so presumably also with the new one (xfree 2.0). It is complete and works very well. el -- Dr. Eberhard W. Lisse \ / Windhoek Central Hospital \ * | Department of Obstetrics and Gynaecology Private Bag 13215 \ / 61 203 2106/7 (Bleeper) 61 224014 (home) Windhoek, Namibia ;____/ ------------------------------ From: hta@uninett.no (Harald T. Alvestrand) Subject: Re: Thought... Date: 19 Nov 1993 12:44:00 GMT In article <1993Nov17.170336.6746@infodev.cam.ac.uk>, rrw1000@cl.cam.ac.uk (Richard Watts) writes: |> |> .. this kind of thing requires real-time guaranteed network and OS |> performance. Fine - there are OSs and networks that will do this, and very |> nice they are too. Funny you should say that while I am listening to the mbone broadcast on my SUN (another non-realtime OS). Most UNIX variants on most CPUs have power enough to do this with no real problems. I haven't niced up my applications, so the sound drops out for a few tenths of a second every time I start heavy disk activity, but otherwise, it works nicely. This is a sidetrack - but is anyone working on multicast support for Linux? -- Harald Tveit Alvestrand Harald.T.Alvestrand@uninett.no G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no +47 73 59 70 94 My son's name is Torbjørn. The letter between "j" and "r" is o with a slash. ------------------------------ From: dmw@prism1.prism1.com (David Wright) Subject: Using Linux to create SCO binaries? Date: 19 Nov 93 14:44:42 GMT Does anyone know of a way to use Linux as a cross-development platform for SCO development? I do not expect to RUN the binaries on the Linux box (although I look forward to that happening), I just want to be able to compile software on my Linux box and ship it over to my SCO box. I have the SCO development system, but they do not include the libraries/headers needed for network-aware programs (even if you have their TCP/IP & NFS packages, which I do, you still need to cough up another ~$1000 for the "network development" package), and so I can't compile things like "term", "MudOS", "Amanda" (a cool networking backup program), etc. What I would like to do is to use the Linux machine to create COFF-format binaries that are statically linked with the apropriate network libraries and then copy them back across to the SCO machine. I know that the GCC compiler can be set up to do cross-compiles, so I guess what I am asking is if this is possible/feasable to do what I want... Dave -- ____________________________________________________________________________ | /\ / | Prism Computer Applications | David Wright | | -/--\-- | 14650 Detroit Ave, Suite LL40 | dmw@Prism1.COM | | /____\ | Lakewood, OH 44107 USA | 216-228-1400 | ------------------------------ From: kas@varda.ics.muni.cs (Jan Kasprzak) Subject: [Q] bdevsw/cdevsw -- where? Date: 17 Nov 1993 16:35:15 GMT Hello, kernel hackers! [Sorry, if this is a FAQ] How is possible to write a new device driver for my kernel? Drivers must usually provide a few functions (e.g. for driver named `foo' there are foo_init(), foo_open, foo_close(), foo_ioctl(), foo_read(), foo_write(), and for block devices also foo_strategy(). These adresses of these functions are usually located in block/char device tables named bdevsw/cdevsw. I have fgrep-ed the whole kernel sources, but cannot found these tables. So how it is in Linux? And where can I get a free major number for my device? A time ago I worked on {386|Net}BSD, and I must say that kernel-configuration process and new-device-writing is _much_ easier than on Linux :-(. But Linux is faster, smaller and have shared memory. So at present I'm running Linux. Yenya -- Jan "Yenya" Kasprzak \ while (*p++ = *q++) ; Student of Comp. Sc. \ Dennis Ritchie kas@erebor.ics.muni.cz \----------------------------------------- kas@muni.cz \ MS-DOS ?! No, thank you... (Brno, Czech Rep., Europe) \ I have Linux - free clone of UNIX! -- Jan "Yenya" Kasprzak \ while (*p++ = *q++) ; Student of Comp. Sc. \ Dennis Ritchie kas@erebor.ics.muni.cz \----------------------------------------- kas@muni.cz \ MS-DOS ?! No, thank you... (Brno, Czech Rep., Europe) \ I have Linux - free clone of UNIX! ------------------------------ From: peter@micromuse.co.uk (Peter Galbavy) Crossposted-To: comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: 19 Nov 1993 14:17:53 GMT Reply-To: peter@micromuse.co.uk In article <1993Nov18.024738.24465@Synopsys.Com>, jbuck@synopsys.com (Joe Buck) writes: + One piece of good news is that OSF has made the spec public, meaning + that they've given the green light to anyone who wants to clone it + (no risk of look-and-feel lawsuits). If it really turns out that the + whole world is going in Motif's direction, perhaps it's time for a + Motif cloning project. There is one "about" to start I think... look over in the comp.os.linux.devlopment group (one of the cross posted groups here) There is an article "Motif Project Status" Message-ID: <2cckp5$4lf@charm.magnus.acs.ohio-state.edu> about whats happening. Lets all go for it :-) Or mail "dohm@magnus.acs.ohio-state.edu (Peter J Dohm)" I guess. -- Peter Galbavy work: peter@micromuse.co.uk +44 81 875 9500 home: peter@wonderland.org =========================================================================== "Bad planning on your part does not constitue an emergency on mine." - Please attribute this quote. Thanx. ------------------------------ From: sjt@enlil.museum.upenn.edu (Steve Tinney) Subject: Keyboard timing out in pl13r Date: 19 Nov 1993 14:37:21 GMT After leaving pl13r for several hours it has twice (out of two times) locked up the keyboard requiring power off/power on to clear it. I don't know what the cutoff point is for this, but after a normal screen-saver timeout the keyboard is still functional. The afternoon lockup occurred at least within 4 hours; this morning's within 8. This is with a garden variety AT-clone, 486/66, Phoenix bios. I'm back to pl13 now. Steve ------------------------------ From: koenig@ceres.tat.physik.uni-tuebingen.de (Harald Koenig) Subject: looking for lost clock ticks & interrupts, sti/cli profiling Date: 19 Nov 93 15:07:11 GMT Hi, I'm looking for lost clock ticks and timer interrupts in Linux. I tried just to trap all sti() and cli() calls, register a time stamp and source file position and check in sli() whether interrupts are blocked longer than say 2 or 5 ms (see my patches below). But unfortunately sometimes the interrupt enable flag isn't set or cleared via sti() or cli() but through loading the flags register or through interrupts, traps, etc. So far, I trapped sti(), cli(), iret() and restore_flags() in system.h and before switch_to(next) in sched.c. While I write this I'm thinking about patching save_flags too. So I can check if the interrupt enable flag is cleared (e.g. by a hardware interrupt) which has not been detected before. Is there a generic way to find ALL (or at least most) of the implicit sti() and cli()'s ? Where is the global interrupt handler/dispatcher (does such a beast exist in Linux or how can i trap all hardware (and software?) interrupts which do an implicit cli() ? Or do I have to call cli__debug() in each interrupt handler on my own ? Is there a way to find DMA (and busmaster dma? VLB busmaster dma?) and check them since DMA will lock the bus, right? So far, this seems to work fine but last night I got no clock step (no lost timer interrupts, this happens only once every few days, so i've to wait and see). I'm running and testing a radio clock receiver (like CHU in USA using xntp-3.3 and own clock drivers). from time to time there is a gap (jump) in the time of 20ms (two clock ticks missing). it's always a 20ms gap on my system (486/dx2-66, bt445 vlb-scsi) but i heared from another PC with an IDE disc (don't know 386/486) which has up to 80ms gaps (EIGHT clock ticks missing!). on a more general view, i'm interested in detecting worst case interrupt latency and other paramters relevant to a real time os (yes, i know that Linux is NO real time os, but this doesn't imply that it's not worth knowing such data). below, there are two separate pathes for 0.99pl13r: the first one is the complete debug code, but it is not initialized at boot time (cli_sti_init=0) since I had problems with my first experiments (awfully buggy code) when I trapped the first cli/sti s at boot time. i don't know if this is necessary any more. the second patch is a ugly late night hack to start, query and modify the time-out (in usec) above which a interrupt lock period is printed using printk so you can log them all using syslogk. since i just added some tty ioctl's for time stamping data on the serial ports for radio clock support (coming RSN I hope) I used this way to change cli_sti_init and cli_sti_max_t to. the small program will run with patch 2: =============================================================================== #include #include +main(int argc, char *argv[]) { int i=5000,t=open("/dev/tty",0); if (ioctl(t,CIOGETEV3-2,&i)) {perror("CIOGETEV3-2");exit(1);} printf("old cli_sti_max_t = %d [usec]\n",i); if (argc>1) { i = atoi(argv[1]); if (ioctl(t,CIOGETEV3-1,&i) {perror("CIOGETEV3-1");exit(1);} if (ioctl(t,CIOGETEV3-2,&i) {perror("CIOGETEV3-2");exit(1);} printf("new cli_sti_max_t = %d [usec]\n",i); } exit(0); } =============================================================================== any comments, hints, better solutions ? Is there a better way doing this? Thanks, Harald =============================================================================== --- /soft/linux/include/asm/system.h Tue Jul 20 03:35:31 1993 +++ linux/include/asm/system.h Thu Nov 18 23:39:32 1993 @@ -18,8 +18,23 @@ "mov %%ax,%%gs" \ : /* no outputs */ :"i" (USER_DS), "i" (USER_CS):"ax") +#define DEBUG_CLI_STI +#ifdef DEBUG_CLI_STI +extern void sti__debug(char * filename, int line); +extern void cli__debug(char * filename, int line); +#define sti() {\ + sti__debug(__FILE__,__LINE__);\ + __asm__ __volatile__ ("sti": : :"memory");\ + } +#define cli() {\ + __asm__ __volatile__ ("cli": : :"memory");\ + cli__debug(__FILE__,__LINE__);\ + } +#else #define sti() __asm__ __volatile__ ("sti": : :"memory") #define cli() __asm__ __volatile__ ("cli": : :"memory") +#endif /* DEBUG_CLI_STI */ + #define nop() __asm__ __volatile__ ("nop") /* @@ -47,10 +62,26 @@ #define save_flags(x) \ __asm__ __volatile__("pushfl ; popl %0":"=r" (x): /* no input */ :"memory") +#ifdef DEBUG_CLI_STI +#define restore_flags(x) { \ + if ((x)&1<<9) { /* interrupt enable flag */ \ + sti__debug(__FILE__ "/rf",__LINE__); \ + __asm__ __volatile__("pushl %0 ; popfl": /* no output */ :"r" (x):"memory"); \ + } \ + else { \ + __asm__ __volatile__("pushl %0 ; popfl": /* no output */ :"r" (x):"memory"); \ + cli__debug(__FILE__ "/rf",__LINE__); \ + } \ +} +#define iret() { \ + sti__debug(__FILE__ "/iret",__LINE__); \ + __asm__ __volatile__ ("iret": : :"memory");\ + } +#else #define restore_flags(x) \ __asm__ __volatile__("pushl %0 ; popfl": /* no output */ :"r" (x):"memory") - #define iret() __asm__ __volatile__ ("iret": : :"memory") +#endif /* DEBUG_CLI_STI */ #define _set_gate(gate_addr,type,dpl,addr) \ __asm__ __volatile__ ("movw %%dx,%%ax\n\t" \ --- /soft/linux/init/main.c Sat Oct 30 19:34:59 1993 +++ linux/init/main.c Thu Nov 18 23:09:28 1993 @@ -488,3 +488,67 @@ } _exit(0); } + +#ifdef DEBUG_CLI_STI +extern void do_gettimeofday(struct timeval *tv); + +static char *sti_filename="STI_INIT"; +static int sti_line=0; +static struct timeval sti_time={0,0}; + +static char *cli_filename="CLI_INIT"; +static int cli_line=0; +static struct timeval cli_time={0,0}; + +int cli_sti_init=0; +int volatile debug_cli_sti=0; +int volatile cli_sti_max_t=1000; /* 1000us == 1ms */ +static volatile int last_cli=0; +static volatile int last_sti=1; + +void cli__debug(char * filename, int line) +{ + if (!cli_sti_init || debug_cli_sti || last_cli) return; + debug_cli_sti=1; + last_cli=1; + last_sti=0; + do_gettimeofday(&cli_time); + if (filename && *filename) + cli_filename = filename; + else /* this can't happen, can it? */ + cli_filename = "Error in cli__debug call"; + cli_line = line; + debug_cli_sti=0; +} + +void sti__debug(char * filename, int line) +{ + long t; + if (!cli_sti_init || debug_cli_sti || last_sti) return; + + debug_cli_sti = 1; + last_sti=1; + last_cli=0; + do_gettimeofday(&sti_time); + if (filename && *filename) + sti_filename = filename; + else /* this can't happen, can it? */ + sti_filename = "Error in sti__debug call"; + sti_line = line; + + t = (sti_time.tv_sec -cli_time.tv_sec)*1000000 + + (sti_time.tv_usec-cli_time.tv_usec); + + if (t>cli_sti_max_t) { + printk("cli(%d) %s:%d -> %s:%d %d.%06d -> %d.%06d\n" + ,t + ,cli_filename,cli_line + ,sti_filename,sti_line + ,cli_time.tv_sec,cli_time.tv_usec + ,sti_time.tv_sec,sti_time.tv_usec + ); + + } + debug_cli_sti=0; +} +#endif /* DEBUG_CLI_STI */ --- /soft/linux/kernel/sched.c Tue Nov 9 10:19:00 1993 +++ linux/kernel/sched.c Fri Nov 19 08:49:00 1993 @@ -237,6 +237,9 @@ for_each_task(p) p->counter = (p->counter >> 1) + p->priority; } +#ifdef DEBUG_CLI_STI + sti__debug(__FILE__ "/cs",__LINE__); +#endif switch_to(next); /* Now maybe reload the debug registers */ if(current->debugreg[7]){ =============================================================================== --- /soft/linux/include/linux/tty.h Wed Oct 27 14:51:40 1993 +++ linux/include/linux/tty.h Wed Nov 17 23:47:17 1993 @@ -6,6 +6,7 @@ */ #include +#include #include @@ -243,6 +244,9 @@ struct tty_queue secondary; struct wait_queue * except_q; void *disc_data; + struct ppsclockev ppsclockev; + struct ppsclockev ppsclockev2; /* for testing only */ + struct ppsclockev ppsclockev3; /* for testing only */ }; struct tty_ldisc { --- /soft/linux/drivers/char/tty_ioctl.c Mon Oct 18 13:20:50 1993 +++ linux/drivers/char/tty_ioctl.c Thu Nov 18 23:01:35 1993 @@ -382,6 +382,29 @@ return 0; } +static int get_ppsclockev(struct tty_struct * tty, + struct ppsclockev * to_pps, + struct ppsclockev * from_pps) +{ + int i; + char * tmp; + + if (!to_pps) + return -EINVAL; + i = verify_area(VERIFY_WRITE, to_pps, sizeof (*to_pps)); + if (i) + return i; + tmp = (char *) to_pps; +#if 1 + for (i = 0; i < sizeof (*to_pps) ; i++,tmp++) + put_fs_byte(((char *) from_pps)[i], tmp); +#else + for (i = 0; i < sizeof (*to_pps) ; i++,tmp++) + put_fs_byte(((char *) &tty->ppsclockev)[i], tmp); +#endif + return 0; +} + /* Set the discipline of a tty line. */ static int tty_set_ldisc(struct tty_struct *tty, int ldisc) { @@ -636,6 +659,35 @@ return 0; tty->ioctl(tty, file, cmd, arg); return 0; + case CIOGETEV: + get_ppsclockev(tty,(struct ppsclockev *) arg,&tty->ppsclockev); + return 0; + case CIOGETEV2: /* for testing only */ + get_ppsclockev(tty,(struct ppsclockev *) arg,&tty->ppsclockev2); + return 0; + case CIOGETEV3: /* for testing only */ + get_ppsclockev(tty,(struct ppsclockev *) arg,&tty->ppsclockev3); + return 0; +#ifdef DEBUG_CLI_STI + case CIOGETEV3-1: + { extern int cli_sti_max_t, cli_sti_init; + retval = verify_area(VERIFY_READ, (void *) arg,4); + if (retval) + return retval; + cli_sti_init=1; + cli_sti_max_t = get_fs_long((unsigned long *) arg); + return 0; + } + case CIOGETEV3-2: + { extern int cli_sti_max_t, cli_sti_init; + retval = verify_area(VERIFY_WRITE, (void *) arg,4); + if (retval) + return retval; + cli_sti_init=1; + put_fs_long(cli_sti_max_t,(unsigned long *) arg); + return 0; + } +#endif /* DEBUG_CLI_STI */ default: if (tty->ioctl) { retval = (tty->ioctl)(tty, file, cmd, arg); =============================================================================== -- Harald Koenig, Inst.f.Theoret.Astrophysik (koenig@tat.physik.uni-tuebingen.de) All SCSI disks will from now on be required to send an email notice 24 hours prior to complete hardware failure! ------------------------------ ** 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 ******************************