Hello Phil,

Thanks for the good news!

Actually I am no fan of virtualization. It is most of all being used to
work around problems that should not have been created in the first hand
- like this license issue. A sane OS should provide a easily usable API
for new filesystems, Windows apparently does not.

Nevertheless I am extremely glad that this widely popular workaround
can be applied for Coda's sake. :)

On Thu, Jun 16, 2011 at 11:06:01AM -0700, Phil Nelson wrote:
>     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.

Frankly I feel that writing a FUSE-based client would be a relatively
low hanging fruit, while probably having smaller footprint and better
performance. Nevertheless, it will be very nice to have the appliance
as an alternative.

I am concerned that the virtues of Coda like support for multiple users
on the same machine will be sacrificed. Ignoring/disallowing multiuser
setups opens a can of worms and cripples certain usage cases. It may
unfortunately also contribute to user confusion.

>     5)  New releases of Coda can be quickly produce a new appliance
>         so updates can be as simple as replacing your appliance.

[Notwithstanding, I can not help noticing that an update of a client
"without virtualization" is actually no harder (or even easier as it
does not depend on the availability of the virtualizer). Aeteys installer
takes seconds for update or installation.]

>      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.)

For the record, Aetey's installer for Linux is about 2MB as an archive
and takes about 5MB on disk not counting the RVM and the cache. It is
totally self-contained, does not use any other binaries or libraries.
It even provides most of the utilities necessary for Linux start due to
a quite complete busybox being included. This means that the size of the
appliance will be just marginally bigger than its Coda cache (several
megabyte including the kernel and startup scripts). An appliance with
much less than 10 MB download size should be feasible.

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

Great!

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

I would do like "Linux from scratch". There is no need for hardware
detection so the kernel can be extremely stripped and the startups scripts
trivial. A statically linked to uclibc samba would be sufficient and 
a suitable Coda client is already available, see above.

>     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

Hmm why are you willing to take care of something so big and so
controversial? Gnome is not necessary for Coda, then why?

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

If the Coda users share the same Coda client instance (venus and the
cache) they must be authenticated against the Linux system running the
client as different entities/uids, this is a prerequisite for the correct
functioning of the Linux client, period. Otherwise the client can not
distinguish between users' credentials nor files cached by the users.

In my eyes it is up to the site administrator how to maintain the
synchronized account system, for both Windows and Linux. This can not
be prepared "in advance" in the appliance. It is perfectly possible by
willing sites but
 it would be an administration problem and a nightmare to update.

The only administration-free and sane approach is actually to allow
a single user per appliance. This is _not_ compatible with multiuser
access that's why the appliance hardly can replace a regular client
on multiuser machines.

As a private appliance, it should not have any login process but directly
start a menu for Coda-related operations, probably a clog-wrapper dialog
before offering the rest. As a next step a GUI would cost extra megabytes
but it should not be Gnome, just a stripped X-server and a single toolkit
used by the GUI.

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

As long as there are suitable APIs to pass data back and forth between
the host and the guest, then of course. I wouldn't though spend time
on this (but rather on a FUSE client :)

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

What do you mean by "user storage" - which data is supposed to be stored
there? There should be some place for the client logs, for reparations
and alike in the appliance. This might mean as much as (several times?) a
"biggest file" size but it is not a "user storage" if I understand your
question correctly.

Anyway, with a modern "sparse" virtual disk it is a mostly
no-issue. Allocate a large virtual disk and let the user choose the
cache size.

>     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.)

It looks like going in the business of providing "virtual Linux
experience" to Windows and Mac. It is a noble goal but different from
providing file system access, I would rather not.

It is a very good news that Coda comes nearer the different platforms.
An appliance does not have to be a definite solution to be really useful!

Thanks Phil.

Regards,
Rune