Subject: Linux-Development Digest #156
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Mon, 11 Oct 93 10:13:15 EDT

Linux-Development Digest #156, Volume #1         Mon, 11 Oct 93 10:13:15 EDT

Contents:
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development") (David Barr)
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development") (Matt Welsh)
  Re: RFD: Removal of group "comp.os.linux.development" (Daniel Quinlan)
  Pascal Compiler... Found! (STEVEN J. KANGAS)
  Quick opinion about current thread (Yves LACHANCE)
  [Q]Anyone working on Cyrix 486DLC cache coherency probs ? (Darren Gilchrist)
  Xview + Xrolo + Calentool   HELP (Odie)
  RE: Floppy Tapes (Gareth Bult)
  Re: CMS Jumbo (QIC 40/80) Driver Status (Patrick Sweeney)
  adjtime() for Linux:  now real system call (Harald Koenig)

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

From: barr@pop.psu.edu (David Barr)
Crossposted-To: news.groups
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development")
Date: 11 Oct 1993 01:55:05 GMT

In article <29a9g0$olg@samba.oit.unc.edu>,
Matt Welsh <mdw@sunSITE.unc.edu> wrote:
>In article <1993Oct10.204642.6749@rzrbyte.fay.ar.us>,
>Tim Peoples <tep@rzrbyte.fay.ar.us> wrote:
>>
>>   This is an official Request for Discussion for the removal of
>>the group "comp.os.linux.development".  When and if this discussion
>>deems it necessary, a vote will be called on this matter.
>
>Idiot. People voted highly in favor of this group not 4 months ago.

Matt, that's a really stupid argument.  Just because some group of N
people voted for a group (riding the bandwagon of several other good
groups), doesn't mean it was a good idea.  Even if it WAS a good idea
(which it probably was), that STILL doesn't justify calling someone an
idiot because he honestly feels the group no longer serves a purpose.

The simple solution is to make it moderated.  It should have been
that way in the first place, but hindsight is 20-20.

--Dave
-- 
System Administrator, Penn State Population Research Institute
"No man is good enough to govern another man without that other's consent"
- Abraham Lincoln

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

From: mdw@sunSITE.unc.edu (Matt Welsh)
Crossposted-To: news.groups
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development")
Date: 11 Oct 1993 03:40:12 GMT

In article <29aedp$pj7@soc2.pop.psu.edu>, David Barr <barr@pop.psu.edu> wrote:
>In article <29a9g0$olg@samba.oit.unc.edu>,
>Matt Welsh <mdw@sunSITE.unc.edu> wrote:
>>Idiot. People voted highly in favor of this group not 4 months ago.
>
>Matt, that's a really stupid argument.  Just because some group of N
>people voted for a group (riding the bandwagon of several other good
>groups), doesn't mean it was a good idea.  

Four months after its creation? You have to give any newsgroup a fair chance. 

In any case, perhaps calling Mr. Peoples an idiot was a bit too much.
All right, it was completely uncalled for, and I apologize.

I feel very strongly, however, that Mr. Peoples is in no way justified
in calling for the removal of a newsgroup which many people, including
myself, worked very hard to create. 

I find this group very useful; I am saddened that a group of non-Linux 
developers has decided that they don't. Well, I personally don't find 
rec.skating very useful. Should I call for its deletion? 

I am also saddened that a group of Linux developers has decided to make
this group the sandbox for deciding guruhood. Either way, you've got it
wrong. This still doesn't mean that the group is bogus. Every group has
its good times and its bad times. A bad wind blowing through c.o.l.d is
no reason to call for the deletion of a group; and especially not from
someone like Mr. Peoples. 

It would be a very different issue if Mr. Peoples had clout within the
Linux development community. I don't have any right to, say, call for
the deletion of soc.religion.islam, do I? I know nothing about Islam, and
don't have any kind of foothold in the s.r.i community. Yet, it seems
that the entire newsgroup is full of flame wars and rivaling groups. 
Looks rather bad off to me. Still, I don't call for the deletion of the
group. Why?

It's called net etiquette. If Linus Torvalds or someone else called for the 
deletion of c.o.l.d, I would still disagree but would probably not follow 
up to the posting as I did. However, I don't think that Mr. Peoples is in 
any position to make policy decisions regarding the Linux development 
community to which he has no relation.

Do you?

mdw
-- 
Send submissions for comp.os.linux.announce to: linux-announce@tc.cornell.edu

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

From: quinlan@pleiades.cs.bucknell.edu (Daniel Quinlan)
Crossposted-To: news.groups
Subject: Re: RFD: Removal of group "comp.os.linux.development"
Date: 11 Oct 1993 00:51:09 GMT
Reply-To: quinlan@spectrum.cs.bucknell.edu


>>>>>  Tim Peoples writes:

[all "Declaration of Independance fluff" has been deleted]

>    This is an official Request for Discussion for the removal of
> the group "comp.os.linux.development".  When and if this discussion
> deems it necessary, a vote will be called on this matter.

"official", that is a very pretentious word that you use there.  I'm
glad that you represent the majority of the Linux community.

> the USENET newsgroup "comp.os.linux.development" (c.o.l.d) was
> brought into being for the open (and unmoderated) discussion of
> software and system development issues as applied to the Linux
> operating system; and

True.

> it is the convention on USENET newsgroups that a major part of any
> open discussion is the broad distribution of "questions" as they
> pertain to the agreed upon subject matter of any given newsgroup

True.

> a small yet vocal group of active readers of c.o.l.d have ever so
> rightiously taken it upon themselves to be the self appointed
> guardians of content for messages posted to c.o.l.d; and

Some of us seem more righteous than the rest.  Eh?

> this group of readers has made public announcement that the
>      asking of questions will not be tolerated on the group c.o.l.d; and

Questions that belong on comp.os.linux.help by your very own admission:

"for the open (and unmoderated) discussion of software and system
 development issues as applied to the Linux operating system"

Would that not indicate that all discussion of other issues belongs
elsewhere?  Do you think that questions answered in the FAQ belong in
a development group?  My - what novice developers we must have!

>      there is no need for a USENET newsgroup in which questions are
>      not tolerated;

*laugh*

>      I propose that the newsgroup "comp.os.linux.development" be
>      removed from the USENET system.

You propose a silly solution, probably as a method to vent your silly
idea that anyone can post whatever they want without whereever they
want.  I presume that you are not serious in your suggestion of
removal, but merely wish to draw an enormouse amount of attention to
your cause, as it were.  A pretty childish ploy in any case.

--
Daniel Quinlan  <quinlan@spectrum.cs.bucknell.edu>

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

From: sjkangas@major.cs.mtu.edu (STEVEN J. KANGAS)
Subject: Pascal Compiler... Found!
Date: 11 Oct 1993 06:23:21 GMT

        Well, I found it.  Juki at Helsinki University of Technology is 
working on a GNU pascal compiler.  It can be found at kampi.hut.fi in
jvt/gnu-pascal.  I've been trying to port it to Linux but I'm not quite
there yet.  The only problem is that it requires the source and object
files for GCC-2.4.5 :*(  That's about 17 meg when built!  The pascal 
compiler uses the language independent files from GCC, so I assume it
will be included with the GCC distribution when it's finished.  Or at least
I hope it will.  I wrote a letter to Juki asking for some help in porting
it to Linux.  When I've done it, I'll post here. 



--
Steve Kangas
sjkangas@major.cs.mtu.edu


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

From: yveslach@binkley.cs.mcgill.ca (Yves LACHANCE)
Subject: Quick opinion about current thread
Date: 11 Oct 1993 05:36:40 GMT

Remember:       One should appreciate the work of others when the only price
                one has to pay for it is to follow the guidelines they set.

A short note, to avoid wasting worldwide bandwidth, over a thread that has
already wasted too much of it.

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

From: root@falcon.DIALix.oz.au (Darren Gilchrist)
Subject: [Q]Anyone working on Cyrix 486DLC cache coherency probs ?
Date: Fri, 8 Oct 1993 04:46:10 GMT

Howdy,

Background :
============

The Cyrix 486DLC chip is a 386 pin-compatible (486sx) processor. Unfortunately
there is a problem with the lack of cache enabling under Linux (by default it
is turned off, and under DOS you have to run a setup program to enable it)

Therefore under Linux, I get no substantial performance increase using this
processor :-(

The second problem is the lack of cache coherency (if it were enabled :-))
Because the 386 had no internal cache, there are no cache coherency lines
such as FLUSH# etc which would be normally become activated after (for example)
a DMA transfer on a true 486 (Oh no I hear you all say...)

My Question :
=============

Has anyone thought about a patch to the kernel for this processor yet ? If not
I'll volunteer to do so when I have a bit of time free.

As a quick ratification of my proposed kernel changes

If I shove the 486DLC detection code (Developed for SysV r4+ by Ti Kan - most 
likely req modification) into boot.S and enable caching (minus 640-1M limit?) 
and patch the enable_dma() code in include/asm/dma.h to disable caching during 
dma transfer will it work :-) Or more to the point, is that where it should go ?

Problems : (Will a coherency problem occur after a DMA transfer ???)

Code Segments are Read-Only, so no problem of a transfer affecting code, but
will the coherency be violated on Text segments, or will the jump to and from
the kernel (ala during a system call to read/write from a DMA device) be enough
for the processor to do it's own flush and read.

If not :

It seems that (floppy) DMA is enabled after the transfer count has been set
but of course it becomes synchronous from there, and seems to be no way
of reenabling the cache until the invocation of disable_dma() which will only
occur on a subsequent read/write request from/to this devices...

The other problem is the scsi device WD7000 code enables dma transfer at init
time if the channel is available and leaves it in this state...

Any ideas on how to determine whether DMA transfer has completed, with minimal
modification to the blk_drv code ? 

Disclaimer :
============

Being somewhat new to this level of programming (heck we've all got to start
somewhere :-)) please excuse my lame questions. I'll try adding the cache code
in the next couple of days and see if the kernel "holds" up. However if the
kernel gurus (Help Linus!!!) have a better knowledge of this, please give me
a yell...

Thanks in advance,
Darren...
-- 
/-------------------------------+--------------------------------\
| Darren Gilchrist              |           o      __|   (I Can't|
| 2nd Year Computing Science    |       o/         vv`\    draw) |
| Edith Cowan University        |       +              |         |
| Perth, Western Australia      |      /\              |         |
|-------------------------------+--------------------------------|
| root,darren,darreng@falcon.DIALix.oz.au -- darreng@DIALix.oz.au| 
\----------------------------------------------------------------/

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

From: cosc19v2@menudo.uh.edu (Odie)
Crossposted-To: comp.os.linux.help
Subject: Xview + Xrolo + Calentool   HELP
Date: 11 Oct 1993 04:54:42 -0500


Hi,
I would like to run Xrolo and Calentool, without installing all the
things in Xview distribution package.  As far as I know, I only need
xview's libraries.

Could someone tell me where I can get the *minimum* xview package
for running xrolo and calentool ?
I have only limited disk space and I really don't need to  use all the 
fantastic things in the packages.

I tried lib.tar in the xview distribution, which gave me "X:0 server not
connected" error when I ran xrolo.
I think that I need to run "Install" script to automate the procedure
which requires gcc (oops I don't have space to install gcc at this moment).

I think that it would be a good idea to have xview run time package
for running xview binaries.
Current xview distribution is too big !  (Is it only for Xview programmers ?)



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

From: gareth@gblinux.demon.co.uk (Gareth Bult)
Subject: RE: Floppy Tapes
Date: Sun, 10 Oct 1993 22:45:03 GMT

On Sun, 10 Oct 93 12:58:39 EDT;                                             
----Steve Traugott (stevegt@TerraLuna.Org) said:                            
                                                                            
>Does anyone know the current status of any QIC-40 or QIC-80 driver         
>for Linux?  (Such as for the Colorado Memory Systems Jumbo tape            
>drives.)                                                                   
                                                                            
I'm working on a driver based on the ftape/MACH driver that's knocking      
around. I'm using a CMS Jumbo/250.                                          
                                                                            
Status: been going 2 days.                                                  
        have very basic access from kernel.                                 
        ff,rew,read_id (position), scan sector,read sector,write sector     
                                                                            
        Try me again in a week or so...                                     
                                                                            
Gareth.                                                                     
PS. If you've an electronic copy for the spec. you mentioned, how about     
mailing it to me. I'm working from MACH code/comments at the moment.        

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

From: sweeney@$TIN_DOMAIN (Patrick Sweeney)
Subject: Re: CMS Jumbo (QIC 40/80) Driver Status
Date: Mon, 11 Oct 93 12:18:55 GMT

Steve Traugott (stevegt@TerraLuna.Org) wrote:
>Does anyone know the current status of any QIC-40 or QIC-80 driver
>for Linux?  (Such as for the Colorado Memory Systems Jumbo tape
>drives.)

There is currently a driver written by Bas Laarhoven on tsx-11.mit.edu
[18.172.1.2]. The driver is in /pub/linux/ALPHA/QIC-80/ftape-0.9.6.tar.gz.
I dont have a Colorado drive but supposedly it works. I do have an Archive
drive and it seems to work fine for it. You might also want to join the
QIC-80 tape mailing list. To join any of the mailing lists, send mail to
linux-activists-request@niksula.hut.fi. It will auto reply with help
on using the mail-server.

--
- pat
pjs@kodak.com


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

From: koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig)
Subject: adjtime() for Linux:  now real system call
Date: 11 Oct 93 13:40:06 GMT


here is my first version of an adjtime() system call.
note that there is conditional code in 
linux/include/linux/sys.h and linux/include/linux/unistd.h
which has to be changed in th final version (when Linus will 
aprove those calls).

i changed parameters to tickadj() to get direct access to the
kernel variables for debugging purposes. i think for general use
the first and second parameter would be sufficient 
(and implementation independand).


is there any problem using 64 bit interger division (libgcc.a)
or floating point code in the kernel (i can't test this code on
an 386 without fpu)? if not, I'd remove the non-DIV64 code.


Harald

===============================================================================
begin 644 adjtime.tgz
M'XL(`+Q^N"P``^T;^U/;1K._VG_%)OV:6+:,]?`#[#@=`J3A*R09#&GZI1F-
MD&6C(DL:28:0E/_]V[T[/2U>29.T,]R`+=WM[NWK]O8>-J=_QL["[NR;I_;,
M<>T?OD)1%:7?[<(/0$4I?6-1-16@U^WUU*ZB*P-6T1_\`,K78*9<EE%LA@`_
MA+X?7P=W4_N_M)BN.P23.T&]+A[2FC6K7K,L:&\?[DP.H?T;0D/[E0;ME]".
MH.TG<#GX[RW0?;E3$8;KI`;\"GW@^!_T>E>.?[VG#]CX[RL]O3?0:?SK?>U^
M_'^+\N,4P[YG`PUPHU[_T?$L=SFUX4ET$7681YP\K=>C.%Q:,<2.=8J.8@1F
M:"[@4QU@Z47.W+.GX/K>G'\04+]KJ'+RI(U6`),6P_*77CRJ7XZP:\')UJN7
MSW=_,;;V7FW]:O2[:;UA[.T^.]@\^-TP<FRZCK?\T%EZ3A1/&:L&,FYAG-(:
MCA?+PJUER_>B&%(Q%O:9Z4)3]NQS>:72=Z?2**73972$Y'>E4Z]!&26OP:8<
M%#!+;9P1,LH,=<!,E#=0/'5\$KE0Y3K'Q;JY'?M!S%23:/*9KD%#W=M[\D37
MI+3V.=4VIO[RV+6E!L)(4KU^YCM36)B.1UH`,YQ;,E@G.&":^'SV[KU4)R\H
MB8Y\RX""C?)->=F8U"0>0?`>(1XK]$;=(+\RF,;,->=C!=TH?9K:Q\LYP=41
M\OP$TQ7D&*''7,@&XX\8DQ^:PW@X?2A)#\8[KYY+S%>1F7,GMDZ`4*0Z#SZ?
MZDD68IF1#8_-QS!,^E9'R)49^S-"0++2"(Y#VSP=E7!BPHEOPJEQX"D!,T%:
MK:P-;6`NW1BP+0A1![/&PV5DSME,S"98>->>OH=WT#;3.?<]T'NJ6WC_A_<0
MNT.?RXK]P8D;JI1P?%FG?_Q``ZS%9T9D6S`&LJW4B!F4:%CF6QIQ.P&1FJK=
M9X!HO8R">!%89""TY`P:7)'PUU_P@.LGL820H?&(/.$1=W2J3X1W31PSB:!#
M:OE)7>O/4$(YZ[B5ZQ;Y:G/&+D7?#[+.BWT+?65]RR^/]O;81XD+:QF&MI=I
M>'@K+J"54V\KI]",1V!#8"T)E:BS_+NV"B(B)5<N-9*$S(NDU(7%0$)VIK8;
MFXG-$W%3(?G'HR#3>B;Q3U,0RE9F]*EJLY4*$C]@0A=X$WXGIR$D#Z-*!12U
M@]'F6@2MB*`10LIM(B)Y:&5O;0I?T&$Q;06I.0:MV]3[BC*"3A.FH3.+(;!#
MF)H7&'\`+>5[TPB:G;)R4'PEL3ZC)3BZ%&['1IN"E9?U'VUOZLS^^=EPDO]9
MKD^J6PM,C)!M[6_MX_KUGZ[JFB[RO\%`4;N8_V&->I__?8O2;#:!YU#H]#-G
MON9X:W[HS&N'2QLF=@#:.JB#H=X;=A50-S;T>KO=+F/4?L/$[A5.\]`'M3\D
M^`$';A8+O6-V+ZL#8*]$BU[7`9_:.(*.?=^%QWO.PHEA82_\\`)B'W/&<Z2[
M_^QQDASN;[XUL`*\%&5R$<7V`M[`[NNM%&SR^^0-OL-%"G:$4W![T5WO`YL;
M9GX(^-*.`MMR9HY%J0?V_=&,'<S:LNX(X:+>RA'I=^$8><3IVV5Y#[`!]+B<
MO;*NF_0/KT-_3LG/L>.9*!9VO3#CB#57:4G;D/4>UQ)`K0F3K<DN1,L@\$.<
MD"X"3'VF3G2*Z9$9V#)L;8?^0F*@F4ZLR`$"2O!2]I[M_6IL[[PQ)MO(X(,\
M.%&[&OPPITH&OK5]\&K_:OB#,OS<]NP0]5S&V'IQP#%^81@U[AJZ(NO]Q#6^
MLPY2#K^A#JK\8J#(@W[B%S-'N)<@[WL7R,Z1KFX*KG!R.\.9;:4K#N.E<N\[
M<;1<.-=C[6]MY_SY.:;?$1MUW(G)8`-5'@P2@WU;YA)]7\]D%NZ2#4\1[4Z6
M/(!AW-*'NC+L:N5HER#4)F;,83=`TX9Z?XASV]7!3DV#'9HT7$![AA'-=Z,.
M9PL^/L.)I1,X\_G%6B3>/DY6VWS$Q[_01IW$0]),C`JJ88[('EDC;>;5_M/@
M&CDZV)'@C1U&&,K@X^X"5Q-?S`*+UTRB9%!^-8G`_48R55EM8R"KBIZ8;?M@
M]\W.P:16&Y_:H6>[G6/WU)B&9\GWF@FBP3H)68/XQH8_B+\:.,=6U*$/)O7^
MYN&+C-KSUT=M>['LX'1PLF:B"O9VGU%GN)3OT'+>1(S)T;/MW1P+L%C`+,)U
M1@Q.8#'RZ*;'7&6_[AR\W-E[L8WPX\XR"CM1:'6X$XMM`69((:2PY/<6$ABG
MXG5N65]%[&SXBQK1CDZS=E+,>S`/596AOCY4]7(DJ,"M398>"PHJ9DG=H3(8
M*NO7!`5=EU5]/9<#444WM87](49QV5X(4C=PM9'L1C78BJ/4OO!QJ7%AN-.8
M-V.B(K:,RGMIK3)JL@Y'O)6V9.'(VL1ZID6*[M"@P.!Z>&)C)F2&-HA!1QQ&
M$)]@@#QW7!>.;1S="_\,LT.LBGQ,D]@Y`\.>HJ(QM\/ACM'\C(_IB)904>QX
M\[6U:LWA]*=F\Q^QB?^N/Y?YLQT[U$/(7^?%5^P*D_TX?7'9FR"#[[.L=>F9
M"YL_.G[@\J>S$].;+P-1/74%P-EBO9]0.3>=N"MX.3<#?S:3$R8=;^8+U,#B
M#[/HPA./D3,/[7@9>C*.#:K`?-*S4ZFF/FW"94PAMSD6,P>X'/&Q(.QO&%;@
M+B/Z9TM4YFN#'B;<O<37[E584B$B7S%Z'H"<'S1R?I00%A\B#^`&(UP5A))-
M[,^,0PEZ.11M7)^?Z#B=Z_U\*,**KIJX1[;[_O*`F[164S6MW)*ICYKU&X)0
M`55HD_!6VH1RJ:U7"D*Y8&6'H><+G7>:\/;M6VB#,?,IN-C3B*+,,1'$&EEL
M&S/JQ[CPM_RE.V7-O&*-MGTR"XG9BV*\Q>V2TRYF?QJNB_MEN^21"M;8&/:4
M:ZTQ&/3EP7JZ[.-;4#2D<+G@>"[IA>W(3WT:F*0V?S8U+QKELX?XC)9!G^IM
MJ!4/7CS_G(!(6356(0Y@BO[JZ.M]PR`8RW7XG%)#Q;(XP#%@85[`TIO:X8P6
MYZB8DQA.;)P*&,LU?QD?&T%#^:`H,B@?NKHT(@HN[2[A!&$+*IN3S=>$P=8.
M*/MZ5TD<[XMEOXV$U_AHK>)H2VBOWZ49L28\L`+NS$=!R<W^=&8SQX[Z7;GR
M6.PJ(BE^^9RL1<,J,4KK3D9IW=DHB)$*#.-,%H:T6$8Q#9O(I-G=0?:GM`?B
M='#V%LC)CK7C\5Z["N\OM,TIZXYUC-@<,(_T5P$+GCR!]43><QM.D2T(0O_8
M/'9<)[X`?Y83VXEPS7!N7D2P?[3U`G#]QU(2#]2?1!^T=\[[>0*-O<U#A&H#
M^^ZHBB))!%-#.822;1>SG$^L$OM'CJU3MG$44#1BAYED`0Q$&(>602)(3MLF
M:5M3.#76.PK78%7P"%3JK].LU7+:;HU!G,^-$G+%UD;I7.#GU%7H*"K9<Q^5
M)+DLVI3HI$XK-82!#9QQ<;ID6M<UX7-)5-[>?8.4S3/3<<UCU\X&4$4+RE3L
MJY'O+54\*J'-74!B!Y+0X;:01K#BA9Q*%6JSL3H.I9*6?DY>AZF&\KT5N^J,
MX<7_1CG1MPX1X_"5,=G9FC0^2#4`+@^*\D%Z^I2=EZY"'PEP@BZR*%$M3L`*
M*WM[G`:;Y=#A*N2^07G-C#X"),>[;57J<`&ENPF#BGGQOYLD$BB-#^VB<4OD
MI2:28NSD).Y@7::V=&9'N>.S]M/T:)&VY^-E8+!-UE:1\51!W+T%GCB%+/);
M!,W\=GOGV=$OAL%41#0^08V^TIF'3R&J;&FRI8]6FR)5CC0Y2IKX9QI@GHQ5
M.G_D8_3IF+M:6Y<XF#A9.FT\W!K"3WTZ>J//Y+_P@O]_>`_9>*8S,T913AG#
M226374YXD@13ECZV,)!8VMA2\4L=I[,)":./(VR,M'&$C9$ZSE%*@T9JGEKB
MGY1H>7Z\LM_-1^P520=+W+Y53E&57ZTCZKJ2+A]O\+2RGV5,L\["T+;HG``P
M\"]RTX[C,8`05SHVO$->58F?#E#4$;*4777%427:"JNU(!OJ:GZHY\80'][$
M6L$P28XC.A1DLWD<):2G--Z//DL?E+BM]WKR>E]+MP3_34I5;E!JLJHCK5:X
M^G?1>:5C;Z`--G*G:AL]7,8I&YE5Q%V&]M/EPHQ.L2OV]0@FQN[!;V^/?GG%
MF.$+:&@D=P,N>;"\+E%F,SWKIES2:Q[837*%HA*.!8W<5+.Y_=_#W?T=8W-[
M>_=P]\V.4=T\>;VSLPW*FJ("6_AA@A<%N.*#90"8GTUM%P,*HUU]\RFKK[K[
ME`AN1@M<?)R:Z'?E7;/RTH,NE*Q<#B-5(AE*("%9KOKAB+V68$\-=FNJE5WF
M8+<,Y-R=#FHK1M<TF*=KXNM6)-7+D"M0KUF'L*E.7+2)<,2%#:8R*L*'VCNO
M=P[V2[`HGR14`5P1Z(EG=DB;!R8N#!IO=@YVG_]N'.QL;K,[9*A/YR.N])AR
MI9'`)%(,.^DS[36GW$OVR72:W%3"SG#M:,PB@^0K)630E-B=H&0X2J*[E(((
M++>DL$Q),"I5=U8:%:FJU*ZHY8DJ>6FSTA8I<9ZULM%@^1XJ-H99Z"]XJ&2H
M;#LD=\6EE1F'//4VQOGM8/=P1^;7_!+K\(!Q!^M@\K/,Z9&+F]ZKD6%%LT!7
MM5+;7$,DI=(N4^6WUZZEO<R(7^9U4W`C3.D*3I%I+3%Q`;Q5<B&,5':[/\J"
M:A;O6+@KT&J-"Z,_S<0RB":W>=GDB8W1W'GK,Y-329;G_&J?LM9K800D@D^4
MG]OL8<BUAIY7B+A2P=",S'B,$VE"4$V:Q5?5%;9B"]:E5^%:A35IQA$R.,1_
M"0%878=1:_)K85=TE!LA/!@(-V0,9%/;%;>;5T/ME?>;5T%71^GEZ,KY)#EI
MN>U\(@/?$H`K[M<V@R)FL>UK3TCLX]1(]90^5BKJ7S5]!7<,D4$A1@9?&B2+
M<8LFFVQ^>*>\Q\!6,1\%/+2E@"VE.GA>2UR]+7'UCL2UVW*N?0;GVFTYUZ[F
MO&HCJ7H**5(4D*6II"H+J+ZT6H"^PY75^\G\YLD\N%L:&A3RT.#.B>AU4V"%
M\V:ADXV-<L99Y<L\YZP:XC?15S^+OGHK^MIG\:_=FG_ML_@OCO7$(#<D]44*
M8FP7O"#3*CP8T[Y"KB)+;RHQM#)&+B'2;I/<I*G6ER]V_H;E3FZPL<V1;[WN
M^\>HX4XKASNO'?)(I45"OJESU=21+0K8YEIQ<9!;6SS7M8QFSJ7S:3KMJ[02
M7H#2]`3E\L;L^]H--H18/8RG0\/D.)XN;K)K$GU0>\.N-E2Z5QW'<[3R@7SW
MVKOJO;[<5[-=-7I-[ZJ+8X"B+SB>$QN\1P,!K--WJJ)UW^=_"F=&IX9X9M`Q
MWX_;?;E[:!QN3GZ]Z0K7K0Z<Z>=R3.F)Q<;IOA>IFO9`!ZK2V]M+#]T:6G=O
M#_V+7(4]J/Q8"LT`<IZ4]D6D1BL27)&FCY7RO;,KT(3,_/>#19C\=FKV^\+B
M02>;C=G1[H_E;1)S.J4O'/KP$`UF5[J(WN_+^D#+G$0?Z+*^GKI)+;>F"A/#
M-^.`Q7BJBNF\M,6XJU7X2)._!3>Y!3M8+LU0_-@:,K>@2%&X?U">6-KM[*28
M1>\J5#:-U9)-[=S5`'CZE,Z,^4$8/\>$%+#5RAF4=J1-U\)X:D[%:1#QWWBS
M;^SC&(!'&"WF4?NI3;_3B"0*G`T]K;4BB?_NK9;;UR9M4A_?^R<U]^6^W)?[
:<E_NRWVY+_?EOMR7^_*/+/\'>FQ*J@!0``#N
`
end

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