Hi Phil,
  "Perfection is reached not when there is nothing more to add,
  but when there is nothing more to take away."  Antoine St. Exupery

  I encourage you to be ruthless and single-minded in shrinking
the CodaVA  down to the tiniest that you can get away with.
The critical metric is  (VM disk size - Coda cache size).
If you can get this down to the few hundred MB  that would be terrific.
A Coda cache of 500MB to 1GB should be reasonable, so total VM size would
then be less than 1GB.  Release this as version 1.0 and let people
try it out.  Over time, based on actual usage experience the CodaVA
can be grown.  On this first pass, push as hard as you can on shrinking. 
I'd love for us to be able to say with reasonable confidence "This is
the bare minimum that is absolutely needed for a fully
self-contained Coda client."  (i.e. only command line support,
but all tools such as "cfs", "repair", etc. work.  gcodacon
might be exception since it requires GUI support; perhaps a
non-GUI flavor of it is possible, e.g. the expanded volume-specific
details using curses(3).)

What we learn from this extreme shrinking might be of value in
thinking about Coda in new worlds like Android.

    -- Satya



On Thu, June 16, 2011 2:06 pm, Phil Nelson wrote:
> Hello everyone!
>
>
> The Coda project is not dead.   The following is the plan for
> Coda work for the summer of 2011.
>
>
> --Phil
>
>
> --------------------------------
>
>
> The plan for building a "Coda Appliance" for VirtualBox Summer 2011
>
>
> Background:
>
>
> Coda for Windows has stalled due to changes in the kernel module
> FSDK.   Coda on windows is using a very old version of FSDK due to
> a change in FSDK that would require a rewrite of the Coda kernel module.
> While this could be done, it would take quite a bit of time to re-work
> the kernel module and go through the normal development cycle.   Windows
> has now had the Vista and the Windows 7 release for which the Coda kernel
> module does not support.   FSDK does support them, but only with newer
> versions that don't work with the Coda code.
>
> With the development of virtual machines and how well they run on
> current hardware, the idea of producing a "Coda Appliance" for a virtual
> machine has the following advantages: 1)  The Appliance can run Linux, the
> primary platform for Coda 2)  Other platforms can install the
> virtual-machine application and then run the Coda Appliance getting access
> to /coda on the appliance by normal remote mounting technologies, CIFS on
> Windows or NFS in others.
> 3)  It requires no changes to any kernel modules for support of
> all Windows platforms. 4)  It allows support of other platforms, like Mac
> OS X or Solaris
> by choosing the a virtual machine platform that works on those
platforms. 5)
> New releases of Coda can be quickly produce a new appliance
> so updates can be as simple as replacing your appliance.
>
> The Project:
>
>
> During the summer of 2011 we will be building a Coda Appliance.
> Initial plans are to make sure it works well on Windows XP and
> Windows 7.   Due to the availability of hardware, we will also make
> sure it works well on OS X.  We are looking for suggestions and comments
> from the Coda community on this project and how to make it better meet the
> needs of the Coda users.
>
> The VM outline:
>
>
> 1)  We plan on using VirtualBox due to the number of platforms
> on which it runs and the fact that is an open source project like Coda.
>
> 2)  We will build a virtual machine that has Coda preinstalled
> and has samba exporting /coda read/write over CIFS.
>
> 3)  The VM will be set up with two network interfaces, one a NAT
> interface so the VM can talk to Coda servers and a local host only
> interface for the export of /coda over CIFS.  This implies that the host
> machine is a "one user" machine.
>
> 4)  The appliance will have a desktop on the console for the normal
> access to Coda control and monitoring functions like clog, cfs, codacon,
> repair and so forth.
>
> 5)  The plan is to have the appliance be a reduced Linux installation
> so the entire distribution and Coda cache can fit into an appliance taking
>  between 200 and 500 Mb.  (For reference, the current Debian
> installations require 2.4G of space to install.)
>
>
> Current State:
>
>
> We have already done a "proof of concept" using VirtualBox, with
> Debian installed in the VM image and hosted on an a Mac OS X machine.
> This initial appliance is a standard Debian, 4G installation without
> much customization.  It is currently available for a short time at
> http://pcnelson.net/Coda.ova.  It will soon be available by torrent.
> Information on the torrent will be sent to this list.  To use this, you
> need virtualbox (virtualbox.org) installed, get the Coda.ova and import
> this appliance via the "file" menu. (MD5 (Coda.ova) =
> 4a3b1d3e0c3e19355dd5e8096e99df55)
>
>
> It should just work out of the box on OS X.  Finder should find a
> "coda" machine and there should be a coda volume.  You should connect
> as user guest with password guest. All passwords are set to guest on this
> appliance.   For Windows XP, you will need to reset the ethernet adaptor 2
> to a "host only" adapter before you run the VM.  You can them map the
> network resource \\coda\coda using guest/guest as described above.   The
> workgroup is "WORKGROUP" and can be changed in the samba configuration
> file /etc/samba/smb.conf.   This allows XP to see the coda appliance when
> looking at your workgroup computers.
>
> This appliance is Debian 6.0.1a with a stock install and enough
> added to get a Coda client running.  It includes the virtualbox extensions
> so resizing the virtualbox window resizes the Debian/GNOME desktop.  All
> Coda related commands like clog, cunlog, cfs, repair,
> and so forth must be done on the appliance.  There is 400 Megs free on the
> virtual disk.  100 Megs is the initial Venus cache size.  It can easily be
> changed by editing /etc/coda/venus.conf, changing the "cacheblocks"
> definition and then restarting the appliance.  This leaves at most 300
> Megs for "user data".
>
>
> This appliance should work on Windows Vista and Windows 7 in the
> same manner as on XP.  We have not yet tested it in those environments yet.
> Also, this appliance should work in Solaris and Linux environments.
> Again, it has not yet been tested in these environments.  If one wanted,
> /coda could be exported via NFS instead of Samba/CIFS.   That has not
> been set up for this appliance.   Both Solaris and Linux should have a
> method of mounting a CIFS drive into their file system.   It should be
> mounted at /coda for consistency sake.
>
>
> Questions:
>
>
> The following are a list of questions we have not completely answered
> and would like some input from the Coda community.
>
> 1) What would be the best approach to building the appliance?  Start
> with a small distribution like "TinyCore Linux" and add content to get a
> working Coda appliance or start with a large distribution like Debian and
> delete unneeded contents to make a smaller machine.  We are currently
> considering using Debian as the base and producing a minimal installation
>  without gnome.
>
> 2) How important is the desktop on the appliance?  Is the assumption
> that all it would be used for is just the coda utilities (clog, codacon,
> and so forth) or would a fully functional Linux VM be the better way to go
> with Gnome and all that it offers?   (A full Gnome installation would
> cause a much larger VM image similar to the test appliance listed above.)
>
> 3) Plans are currently to have the appliance just have a guest account
> with no password.  The user (again we are assuming a single user machine)
> just uses the VM console to clog to their proper Coda user and the host
> machine gets access via the guest account.  Thus, no account creation is
> needed on the appliance.   This does give every user on the host machine
> common access to the Coda appliance.   Does this sound reasonable?  Do
> you see a need for appliance accounts?
>
> 4) Although current plans are to have clog, cfs, repair and so forth
> available only on the appliance console, would people like to see a native
>  app/script that brings clog and friends to the host desktop?
>
> 5) How important is having storage space available for the "user" in
> the appliance.  The proof of concept appliance has 300Megs of user storage
>  available.  Is this too much or not enough?
>
> 6) Would people find it useful to have a choice of a small, no gnome
> appliance with limited user space (the goal is to have 500Megs or smaller
> total appliance) and a large, full gnome installation with 4G (or more)
> virtual disk available for user use? (e.g. virtual disk of 8G as compared
>  to 4G in the current appliance.)
>
> 7) Anything that might make this more useful to you that is not mentioned
>  here?
>
> -------------------------------
>
>
> --Phil
>
>
> --
> Phil Nelson, http://pcnelson.net
> life: http://goallpower.com
>
>
>