Subject: Linux-Development Digest #903
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:     Sun, 10 Jul 94 03:13:08 EDT

Linux-Development Digest #903, Volume #1         Sun, 10 Jul 94 03:13:08 EDT

Contents:
  Re: Amiga OFS/FFS support (jdrumm on BIX)
  ping doesn't work with 1.1.26 (Robert G. Smith)
  Re: Mach 64 (Aaron Burda)
  Re: VAX port, is there one? will there be one? (David Holland)
  Re: List of programs which need shadow changes (David Holland)
  Re: dual mon support in 1.0.9? (Thomas Bogendoerfer)
  vmstat for linux? (Andrew Preston Davis)
  Re: procps in recent 1.1.x kernels (a fix?) (Rob Janssen)
  Linux (1.1.24) hangs in cdrom access. (Laurent Chemla)
  Re: procps in recent 1.1.x kernels (a fix?) (todd j. derr)
  Re: Dedicated SCSI swap d (John Will)
  Re: Dedicated SCSI swap d (John Will)
  ARNET SmartPort Plus drivers (Greg Miller)
  Linux Man pages (Newman Monrose)
  Re: 1.1.26 breaks dialout serial device (Leung Danny Pui Fun)
  Re: Kernels and atdisk2 (Ian McCloghrie)
  Re: Frame grabbers and Linux: is it possible? (Michael Cain)
  Re: Linux seems to perform terribly for large directories (tpfpdt@eng.ox.ac.uk)
  Re: Linux Performance Enhance ? (Rob Janssen)
  Bug in patch 27 NFS include (Frank Lofaro)

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

From: jdrumm@BIX.com (jdrumm on BIX)
Subject: Re: Amiga OFS/FFS support
Date: 9 Jul 94 21:07:13 GMT

mark@oink.rhein.de (Bernd Markiefka) writes:

>Well, Im almost 100% sure that there is support for the Amiga FFS. I've found a
>package nearly a year ago or so at fgb1.fgb.mw.tu-muenchen.de (129.187.200.1)
>somewhere in the alpha or beta subdirectories. Sorry, I don't remember exactly
>where it was and I've not the time to look it up, but there should be other 
>servers where it exists.

>Bernd Markiefka
>mark@oink.rhein.de

As far as I know, typical PC floppy drives are physically
unable to read Amiga OFS/FFS disks..

Although having a OFS/FFS filesystem would be great
for accessing Amiga SCSI disks...


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

From: rob@bip.anatomy.upenn.edu (Robert G. Smith)
Subject: ping doesn't work with 1.1.26
Date: 9 Jul 1994 23:08:55 GMT

  I had Slackware 2.0 with its tcpip.tgz distribution installed
on several machines, using 1.1.24.  Very nice. Net stuff runs
superbly (thanks to y'all who've worked hard on this!).  

  When I updated to 1.1.26, the network stuff like ftp, rlogin, 
telnet, rsh all work fine but ping returns with "0 packets received"
when I ping any of the systems the system booted with 1.1.26.  
I've got SLIP and the 3c503 driver enabled, but no other net
card support enabled.  Same result whether ping is run on 
the 1.1.26 or 1.1.24.  The 1.1.26 systems don't respond.

  Anything different in the 25 and 26 patches that would affect
this?

Rob Smith

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

Crossposted-To: comp.os.linux.help
From: aburda@netcom.com (Aaron Burda)
Subject: Re: Mach 64
Date: Sat, 9 Jul 1994 21:26:15 GMT

jdrumm on BIX (jdrumm@BIX.com) wrote:
: pagels@cs.arizona.edu (Michael A. Pagels) writes:

: >1) Anyone using the new PCI ATI Turbo Mach 64 based card an XFree?

: >2) Will XFree_mach32 drive this card?

: >3) Any development underway to support its extensions over Mach 32?

: >Guess you can tell I'm thinking about getting a Mach 64 based
: >system.  My main work is image analysis and Mach 64 seems to
: >be the way to go.....

: >Thanks in advance for your comments!

: >Michael

: I have a Mach64, and am quite happy with it except
: for the lack of support under Linux (unless I'm
: wrong).  I use the 16 color VGA driver since I can't\
: get any of the other servers to work (apparently, the 
: Mach64 no longer has 8514doesn't do 8514).  I've been meaning to call
: ATI to get some tech info, and possibly hack around
: with the Mach32 Accel. server, but I haven't got
: around to it yet...  
        I don't suppose there are any drivers out there for Xfree
that work with the orchid kelvin 64 VLB? I just got one and unless I can
get Xfree to work with it I am going to have to go back to OS/2 or find
myself a UN*X that does support it.

           Aaron Burda
           aburda@netcom.com

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

Subject: Re: VAX port, is there one? will there be one?
From: dholland@scws9.harvard.edu (David Holland)
Date: 8 Jul 94 15:16:38


zloebl@piis10.joanneum.ac.at's message of 7 Jul 1994 07:10:25 GMT said:

 > Well having some VAXstations 3100, i am interested in an operatingsystem
 > for them (not VMS or ULTRIX)

Speaking of which, is there an alternative to Ultrix for MIPS
Decstations? Linux? NetBSD? [ Goofix 0.1? :-) ]

--
   - David A. Holland          | "The right to be heard does not automatically
     dholland@husc.harvard.edu |  include the right to be taken seriously."

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

Subject: Re: List of programs which need shadow changes
From: dholland@scws9.harvard.edu (David Holland)
Date: 8 Jul 94 15:19:50


jfh@rpp386's message of Thu, 7 Jul 1994 02:55:50 GMT said:

 > >login
 > >telnetd
 > >ftpd     { both the bsd and wu versions }
 > >pop2d
 > >pop3d    -- slackware calls/called this popd
 > >pppd
 > >xlogin
 > 
 > You also need to change rexecd, not that you will want to ever use it ...

Why not come up with a standardized library interface, fix these
programs once and for all, and use replacement dynamic libraries to
get shadow passwords, Kerberos, s/key, and/or whatever other schemes
come down the pipe?

--
   - David A. Holland          | "The right to be heard does not automatically
     dholland@husc.harvard.edu |  include the right to be taken seriously."

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

From: tsbogend@bigbug.franken.de (Thomas Bogendoerfer)
Subject: Re: dual mon support in 1.0.9?
Date: 9 Jul 1994 20:02:48 +0200

lukeh@zola.apana.org.au (Luke Howard) writes:

>Luke Howard (lukeh@zola.apana.org.au) wrote:
>: Luke Howard (lukeh@zola.apana.org.au) wrote:

>: zola kernel: gfp called nonatomically from interupt 00119556

>zSystem.map says that it's in between _do_no_page and _do_page_fault. 
>(including the interrupt mentioned in the last post)

some weeks ago I tracked that beast down. If someone wants a patch, I look
in my old patched kernel (it's a 1.1.12 kernel, I have no newer dual-mon
patches, sorry). 

Thomas.


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

From: davis@cats.ucsc.edu (Andrew Preston Davis)
Subject: vmstat for linux?
Date: 8 Jul 1994 20:23:14 GMT


      I am not sure where to continue looking..so if anyone outthere
knows where to find a vmstat or related usage type program for linux
I would be very appreciative.  If none exists and no one is working on it...
i guess I'd best get hacking :-).

  -drew
davis@cats.ucsc.edu

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: procps in recent 1.1.x kernels (a fix?)
Reply-To: pe1chl@rabo.nl
Date: Sat, 9 Jul 1994 18:55:07 GMT

In <2vlr4d$3in@usenet.srv.cis.pitt.edu> infidel+@pitt.edu (todd j. derr) writes:

>i finally decided to look into why exactly procps breaks on newer
>kernels (since the new tty code, pl13ish?)... the problem being, the tty
>names from 'ps' are all wrong, and the 'what' field in 'w' output is
>always just "-".

>anyways, armed only with ps sources, i figured i'd ask about it here
>rather than waste my time digging for what changed.  it seems that the
>7th field of the /proc/PID/stat line, the controlling tty, used to be
>just the tty minor number, but is now 1024 + minor (which is probably
>major*256 + minor, i guess).

>Anyways, just wondering if this is the case, and why.  My quick fix to
>procps was to edit the file devname.c, and add as the first line of the
>function dev_to_tty:

>  if (dev >= 1024) dev-=1024;

>it's hackish, but it works, and no sense trying to do it "the right way"
>when I don't know what "the right way" is.  feel free to do better.

In the old system, all tty devices had major number 4, and the minor
number uniquely identified a tty.  With the new tty drivers, this is
no longer the case, making way for drivers for other devices that may
be presented as a tty and use a different major number (e.g. intelligent
multiport cards).

So, it is better to split the number in 'major' and 'minor'.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: laurent@brasil.frmug.fr.net (Laurent Chemla)
Subject: Linux (1.1.24) hangs in cdrom access.
Date: 8 Jul 1994 14:37:50 GMT

Description:
From time to time, when accessing my scsi cdrom (Chinon), mostly from an nfs
mounted DOS host, but also from the console itself, the kernel just hangs
during a read access. The cdrom drive is quite slow, and I usually get
some:
        kernel: SCSI host 0 abort() timed out - reseting

in my /var/adm/messages file. It looks like sometime this timeout occurs when
the kernel is in the linux/drivers/scsi/sd.c rw_intr() routine, leading my
box into a crash.

I tried to add some debug messages from the scsi driver and got:

Jul  8 15:59:49 brasil kernel: SCSI host 0 abort() timed out - reseting
Jul  8 15:59:49 brasil kernel: Sent BUS DEVICE RESET to target 0
Jul  8 15:59:49 brasil kernel: Sending DID_RESET for target 0
Jul  8 15:59:49 brasil kernel: Sending DID_RESET for target 0
Jul  8 15:59:49 brasil kernel: aha1542_intr_handle: Unexpected interrupt
Jul  8 15:59:49 brasil kernel: tarstat=0, hastat=0 idlun=10 ccb#=5
Jul  8 15:59:49 brasil kernel: aha1542_intr_handle: Unexpected interrupt
Jul  8 15:59:49 brasil kernel: tarstat=0, hastat=0 idlun=10 ccb#=6

in /var/adm/messages.
This crash occurs regularly (i.e. almost always, but the days I got a lot of
luck) when I try to use thiis cdrom drive.

Configuration:
Linux 1.1.24 with both scsi and ide drives, 1542B ISA card.
One 500Mo IDE HD
One 1Go Micropolis SCSI HD
One Chinon SCSI CDROM.
Pentium 60 PCI.
Same symptoms when the kernel is compiled with gcc2.5.8 or when I use the
Pentium optimized 2.5.8 gcc version. Same symptoms from a very long time
ago (I dont remember when this begun, but it was around 1.0 release). Same
symptoms on my previous 486DX2/66 PC.

Kernel debug report:
        Oops: 0000
        EIP:   0010:0019120d (linux/drivers/scsi/sd.c rw_intr() routine).
        eax: 00000000   ebx: 000000c0   ecx: 00000000   edx: 3d1dd1f
        esi: 001e6dee   edi: 001e6c6e   ebp: 18000000
        ds: 0018  es: 0018  fs: 002b  gs: 002b
        Pid: 0, process nr: 0
        8a 42 01 50 8b 74 24 20 31 c0 8a 06 50 8b 7c 24 8b 47 0c

Hope this helps someone to debug :-)
 
--
Laurent Chemla : chemla@cnam.cnam.fr or laurent@brasil.frmug.fr.net
Brasil BBS  - +33 1 44 67 08 44 -  Atari France developpers support

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

From: infidel+@pitt.edu (todd j. derr)
Subject: Re: procps in recent 1.1.x kernels (a fix?)
Date: 10 Jul 1994 02:18:42 GMT

In article <CsosJw.EJ2@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:

>In the old system, all tty devices had major number 4, and the minor
>number uniquely identified a tty.  With the new tty drivers, this is
>no longer the case, making way for drivers for other devices that may
>be presented as a tty and use a different major number (e.g. intelligent
>multiport cards).
>
>So, it is better to split the number in 'major' and 'minor'.

yeah, linus suggested using MINOR(dev), which will work for now, unless
people already have tty devices with major != 4...  of course, I have no
idea what tty's with major 5 should be called anyways, so...

I really have no intention of maintaining procps, but I guess that the
'right thing to do' would eventually be to read the device info out of
/proc/devices and take it from there...

ah well...

todd.

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

Subject: Re: Dedicated SCSI swap d
From: john.will@dscmail.com (John Will)
Date: Fri,  8 Jul 94 15:49:00 -0640

T >The old Quantum ProDrive 80 was speced at 2 megabytes/second asychronous
T >and 4.0 megabytes/second synchronous.  I've seen them go faster (I once
T >caught one doing 5 megabytes/second asynchronous).  I doubt that newer
T >drives are slower.

You're talking about SCSI interface speed, I believe the conversation
was about real disk performance.  I have a Quantum 1080S that can do
a sustained 4mb/sec under ideal conditions, but it has a FAST SCSI-II
interface, so I could claim 10mb/sec if I were looking at interface 
speeds.

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

Subject: Re: Dedicated SCSI swap d
From: john.will@dscmail.com (John Will)
Date: Fri,  8 Jul 94 15:50:00 -0640

AR>My solution was to get a cheap IDE drive and use that as a swap
AR>device, which is a shame as my SCSI drive is 4 times faster both for
AR>access time and data transfer :-(

Your solution should have been to buy more memory! :-)

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

From: gmiller@metronet.com (Greg Miller)
Subject: ARNET SmartPort Plus drivers
Date: Fri, 8 Jul 1994 23:24:03 GMT


I have been talking with the engineering group at ARNET about drivers for
Linux. They indicated they have been contacted by someone (gee they never
remeber who though) about writing drivers for Linux.

I am seeking any version of these drivers in order to install one of these
boards into my Linux system. If you have, have seen (and remember where),
or know who to see about these drivers, I would be very greatful to share
this information.

Thanks in advance
GMiller@Metronet.Com

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

From: monrose@wilma.cs.nyu.edu (Newman Monrose)
Crossposted-To: comp.os.linux.misc
Subject: Linux Man pages
Date: 8 Jul 1994 20:43:03 GMT

Hi,
        I'm looking for some of the man pages for Linux. Is there
any repository site where I might find them ? My installation seems
to be missing some of them . For example, I need the man page for mprotect() on
linux to see if the directives are any different from those on 
SunOs, but I can't seem to find that manpage anywhere.

Thanks

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

From: puifunle@hkuxb.hku.hk (Leung Danny Pui Fun)
Subject: Re: 1.1.26 breaks dialout serial device
Reply-To: puifunle@hkuxa.hku.hk
Date: Sun, 10 Jul 1994 02:25:49 GMT

Rene COUGNENC (cougnenc@blaise.ibp.fr) wrote:
: 
: Serial devices seems broken in 1.1.26; some programs can't open the
: dialout device (chat, echo, cat for exemple):
: 
: renux:/home/rene/dip $ echo "foo" > /dev/modem
: /dev/modem: Appel systhme interrompu
: 
: The message is "interrupted system call"; this is when I abort with
: CNTRL-C, otherwise the open blocks forever.
: 
: Everything was fine with previous patchlevels.
:  

Got TIMEOUT immediately if I start rz (receive Zmodem) here...


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

From: imcclogh@cs.ucsd.edu (Ian McCloghrie)
Subject: Re: Kernels and atdisk2
Date: 8 Jul 94 20:53:16 GMT
Reply-To: ian@ucsd.edu

jzarin@nyx10.cs.du.edu (Jason Zarin) writes:

>The fact that linux doesn't natively support more than one controller
>has always struck me as an oversight.

There is a patch to 1.0 that will do exactly this.  You have to have
the secondary controller on A) a different port address and B) a
different IRQ, and you'll probably have to use LILO to feed the disk
cylinder/sector/track info to the kernel ('cause the BIOS only has
space for two drives), but it works just great.  I've got 3 IDE drives
in my system right now, and have had for several months.  I can say
from experience that the 1.0 patch will work with up to 1.0.6 or
1.1.19, I've not tried anything beyond that.  (There's one file it
won't patch right, but that's easy to fix by hand).  It will *not*
apply on top of a kernel with the IDE performance patches installed.
It should presumably be fairly simple to integrate the two, I just
haven't found the time to try it yet.

(And no, I don't know if/when the atdisk2 patch will be integrated
with the distribution kernel, hopefully soon)

--
____
\bi/  Ian McCloghrie      | FLUG:  FurryMUCK Linux User's Group
 \/   email: ian@ucsd.edu | Card Carrying Member, UCSD Secret Islandia Club
GCS (!)d-(--) p c++ l++(+++) u+ e- m+ s+/+ n+(-) h- f+ !g w+ t+ r y*


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

From: mcain@advtech.uswest.com (Michael Cain)
Subject: Re: Frame grabbers and Linux: is it possible?
Date: 8 Jul 1994 21:29:22 GMT

In article <9407011132.AA18843@ipvvis.unipv.it> rubini@ipvvis.UNIPV.IT (Alessandro Rubini) writes:
>We are looking to buy a frame grabber for our lab: the PC products are quite
>attractive and cheap, but we won't shoot ourselves by running windoze or such.
>We'd better have support for two concurrent cameras and for storing sequences,
>if available.
>
>So my questions:
>- Is there a driver for any of the available grabbers out there?
>- Either, are there docs about the software interface so to write the
>       driver ourselves?
>
>Please, help me bringing a linux box in the lab ;-)
>
>Thankyou in advance
>/alessandro

I'm running a Control Vision monochrome frame grabber, using an application
program running as root rather than a device driver (can't get at interrupts,
but it was quick and easy).  On a 66 Mhz '486  with XFree 2.0, a program can
read and display 15 or so small frames (about 240x180) per second.  Several
potential problems with the PC products: (1) Some vendors are unwilling to
share details at the register-like level, wanting instead to sell/give you
only precompiled libraries for DOS/Windows, (2) Many boards don't support DMA
(mine doesn't) and copying frames over the ISA bus takes up a *lot* of pro-
cessor cycles.  Local-bus grabbers are starting to up in the marketplace,
which should make it possible to deal with bigger frames...

Mike Cain
U S WEST Advanced Technologies
Boulder, CO
mcain@advtech.uswest.com

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

From: tpfpdt@eng.ox.ac.uk
Subject: Re: Linux seems to perform terribly for large directories
Date: Tue, 5 Jul 1994 09:06:12 GMT

In article <1994Jul4.125959.3740@black.ox.ac.uk> mbeattie@black.ox.ac.uk (Malcolm Beattie) writes:
>In article <1994Jul4.111107.335@dutch.eng.ox.ac.uk> tpfpdt@eng.ox.ac.uk writes:
>>In article <Cs94z0.s9@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>>>In <Cs76BL.2F2@research.canon.oz.au> luke@research.canon.oz.au (Luke Kendall)
>>writes:
>>>>[Slow ls stuff deleted]
>
>Are you really and truly sure that you're not using something like
>the colour ls or ls -F under Linux which has to stat every single
>file to find its type? Just another thought...

Good point.  Yes, ls is much faster than ls -F.  Does this mean that file
type data is not cached along with the filename?  Maybe it should be, I find
the -F flag really useful.

>
>--Malcolm
>
>-- 
>Malcolm Beattie <mbeattie@black.ox.ac.uk>
>Oxford University Computing Services
>Forthcoming change of address: will be <mbeattie@sable.ox.ac.uk> (but not yet).
>"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee



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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Linux Performance Enhance ?
Reply-To: pe1chl@rabo.nl
Date: Fri, 8 Jul 1994 17:19:35 GMT

In <2vj4pf$k20@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:

>In comp.os.linux.development, article <CsK7s3.7Ky@pe1chl.ampr.org>,
>  pe1chl@rabo.nl writes:
>> 
>> Also, it seems like the balance between program pages resident in memory
>> and pages used for disk buffers is not always optimal: when the memory
>> is tight it will not swapout infrequently used pages to make room for more
>> disk buffers.
>> 
>Just look at the code in mm/swap.c:

>static int try_to_free_page(int priority)
>{
>        int i=6;

>        while (i--) {
>                if (priority != GFP_NOBUFFER && shrink_buffers(i))
>                        return 1;
>                if (shm_swap(i))
>                        return 1;
>                if (swap_out(i))
>                        return 1;
>        }
>        return 0;
>}

>This means, essentially, that the system will always try to shrink the
>buffer space before attempting to grab a page from a program. Grr.

>Try this replacement instead:

>static int try_to_free_page(int priority)
>{
>    int i=5;
>    static int what = 0;
>                 
>    switch(what) {
>      case 0:
>        goto what_0;
>      case 1:
>        goto what_1;
>      case 2:
>        goto what_2;
>    }                                                         

>  what_0:                                               
>    if (priority != GFP_NOBUFFER && shrink_buffers(i)) {                        
>        what = 1;
>        return 1;
>    }                                                         
>  what_1:             
>    if (shm_swap(i)) {   
>        what = 2;
>        return 1;
>    }                     
>  what_2:             
>    if (swap_out(i)) {  
>        what = 0;
>        return 1;
>    }               
>    if(i-- > 0)       
>        goto what_0;    

>    return 0;                                                               
>}                                                                               

>The goto-ish code may be ugly, but jumping into a loop, or duplicating
>code, is even uglier.
>In my experience, this change is a noticeable improvement in memory usage.

Aside from the functionality of the above example (which I have not yet
tested), let me teach you a bit about C programming:

static int try_to_free_page(int priority)
{
        int i=6;
        static int what = 0;

        while (i--) {
            switch (what)
            {
            case 0:
                if (priority != GFP_NOBUFFER && shrink_buffers(i)) {
                        what = 1;
                        return 1;
                }
            case 1:
                if (shm_swap(i)) {
                        what = 2;
                        return 1;
                }
            case 2:
                if (swap_out(i)) {
                        what = 0;
                        return 1;
                }
            }
        }
        return 0;
}

At least this does the same as your code without those ugly goto's.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Bug in patch 27 NFS include
Date: Sun, 10 Jul 94 05:42:47 GMT

I think I found a bug in the patch 27.

Here is the part of the patch that looks fishy:

--- BEGIN DIFF ---
diff -u --recursive --new-file v1.1.26/linux/include/linux/nfs_fs.h linux/include/linux/nfs_fs.h
--- v1.1.26/linux/include/linux/nfs_fs.h        Tue Jun 21 14:16:25 1994
+++ linux/include/linux/nfs_fs.h        Sat Jul  9 11:53:58 1994
@@ -22,7 +22,7 @@

 #define NFS_READDIR_CACHE_SIZE         64

-#define NFS_MAX_FILE_IO_BUFFER_SIZE    (7*512)
+#define NFS_MAX_FILE_IO_BUFFER_SIZE    16834
 #define NFS_DEF_FILE_IO_BUFFER_SIZE    1024

 /*
--- END DIFF ---

Notice the 16834 above. Shouldn't that be 16384? :)


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


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