On 3/11/07, Mike C. Fletcher <<a href="mailto:mcfletch@vrplumber.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mcfletch@vrplumber.com</a>> wrote:<div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <a href="http://en.wikipedia.org/wiki/UnionFS" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"></a> I'm not enough a sysadmin to know whether the approach is a good one. I'd rather not have to maintain a central server with hundreds of users (I'm not a sysadmin by trade, after all), but maybe that's no biggie for some people.</blockquote><div> First of all, let me describe the scenario I was thinking about, and the problems I am trying to avoid.  Then I'll proceed to this morning's ideas for solutions. Assume we are out making a presentation, introducing OLPC to folks who have maybe read some articles about it, maybe not.  We are hoping to recruit them as developers.  We have an hour or so.  We have asked them to bring their laptops for some hands on experience. We don't have time for any complicated installation, and they have a random assortment of hardware, and operating systems.  Most of them have environments that are difficult, if not nearly impossible to work with.  We can't expect them to pre-install anything before they come to the session. Ian, who started this thread, has suggested a live cd (or dvd).  The problem I see here is that all the live cds I have used, have two layers.  The  read only information only on the cd/dvd.  And a ramdisk or unionfs in memory.  When the system is rebooted all the user's work disappears, unless the user remembered to copy it to a remote server on the network. Mike's project would require them to have 10 gig or so of free space.  I know he said 8 gig, but we want to have room for growth, etc.  I certainly would not want to be resizing their partitions to make room to install Mike's stuff.  The danger of trashing the user's system, and alienating the folks we are trying to recruit is just to great.  It would be too much toexpect them to have a giant usb drive, or enough suitable free hard drive space for this approach. Devil Linux inspires an approach.  See:     <a href="http://www.devil-linux.org/home/index.php">http://www.devil-linux.org/home/index.php</a> It boots from cd, either a vanilla distribution cd, or one that may have some local customizations. It then probes the local hardware, it could even probe the local network, looking for a readable filesystem containing a suitable configuration file.  Typically the configuration is put on a usb drive.  They really like usb drives with a write protect switch, so they can have an easily configurable system with no writable memory that can compromised by an attacker. We want a writable filesystem where we can allocate a directory for each user to store their own persistent code and data.  It could be on a local hard drive, or on a network server we bring to the session.  If it does not find a suitable filesystem with a proper configuration file, it could prompt for the hostname or ip number of a more remote system.  We would not need anything more complex that a vanilla installation of a network filesystem, containing a single configuration file. I would be wary of attempting to store information on a local NTFS filesystem.  Last I heard they were readable, but writing was not reliable.  Although I have heard rumors of a linux ntfs-ng driver that can reliably write to a ntfs filesystem, I have not actually seen one. I would not be offended I some youngster, with more energy, and knowledge about what I am talking about, grabbed this idea and ran with it. I'd prefer to see something like this available sooner, rather than later (if I implement it). We also need presentation materials for introducing OLPC to beginners.  I really enjoyed Ivan's keynote at PyCon.  And maybe there is already suitable material somewhere on <a href="http://laptop.org">laptop.org</a>, that I have not yet found, if not lets start another thread on this topic. </div>-- </div> Drew Einhorn