Hi Phil,

I'm going to answer your questions but first let me add a few initial comments:
1. This is exactly how I'm accessing coda on my Windows machine
(through an SMB mount of venus) so I can say the approach works rather
well.
2. For "honesty"'s sake (and don't take this offensively!) don't mix
this with a port for Windows. Saying running coda on a VM brings coda
to Windows is like saying I have MS Office on Linux because I have a
VM with Windows XP :)
3. My experience with VMs (and I have some but I'm sure there are
people in this list who have a lot more) is that they come with a
rather heavy cost of CPU compared to the "native" thing. I'm not sure
if you can get a stripped down Linux which is so lightweight that
won't be noticeable. I don't talk about RAM because it can work well
with a relatively low amount of RAM. But CPU overhead is definitely
noticeable.
4. You may run into problems managing disk space. Virtual hard drives,
AFAIK, can grow but they don't shrink easily (you have to defrag, shut
the VM down and compress which takes a long time). Which means your VM
will take the maximum size of the venus cache and you can't get that
back. This may be relevant or not depending on how much cache you need
but I have around 100Gb :)

Neither of these comments mean it won't work. They just mean the use
case scenarios should be clear :) What kind of usage are you aiming
at?

Now, about your questions... please prefix all my answers with IMHO :)

> with a small distribution like "TinyCore Linux" and add content to get
> a working Coda appliance or start with a large distribution like Debian
> considering using Debian as the base and producing a minimal installation
> without gnome.

TinyCore Linux. A standard debian server install -- without X -- takes
around 2Gb IIRC. Well, maybe less, I had to install a few extra things
last time I did it :) but definitely over 1Gb.

> 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
> would cause a much larger VM image similar to the test appliance listed
> above.)

Don't add a UI. Coda can't be controlled graphically and you're just
wasting disk space, CPU & RAM. You can just login into the VM (or SSH
into the VM if you configure network correctly).

> just uses the VM console to clog to their proper Coda user and the
> see a need for appliance accounts?

Well, this is tricky (but you figured that out already I guess). But I
guess other solutions are more complicated... and your use case
scenario seems to be as a Workstation. Otherwise you wouldn't be
discussing Windows XP/Vista/7, right? And I imagine most workstations
nowadays are single user...

> available only on the appliance console, would people like to see a native
> app/script that brings clog and friends to the host desktop?

It would definitely simplify usage. As long as people have cygwin, I
guess a simple bash script (based on SSH) would do that easily. If you
like you can try, errr, powershell? DOS? :)


Put a large virtual drive with a default cache size configured in
venus.conf. There is not much to loose. If the user wants a larger
virtual drive they can just increase the size in venus.conf. If they
want a smaller size, they just decrease it in venus.conf (as long as
they haven't filled the cache yet). What is there to win if you limit
the size of the virtual drive?

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

8G? Why not 64G? Or 200G? Am I missing something here? I always create
my VMs with *at least* 64Gb maximum HD space...

Also, why the need for a desktop system. You're building a *coda*
appliance, not a *linux* applicance, right?

> here?

Setting up network in the VM can be challenging. When moving the VM
from one machine to another, VirtualBox changes stuff in the virtual
NIC and the OS interprets that as a different NIC. That can change the
network interface from, for example, eth0 to eth1 and totally messes
up networking because you then have to edit /etc/network/interfaces
and restart networking.

I guess you could build a shell script to correct this but you gotta
do some testing...

Paulo