(Illustration by Gaich Muramatsu)
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, RuneReceived on 2011-06-16 16:58:51