El Thu, 19-08-2010 a las 21:57 -0400, Rodolfo D. Arce S. escribió: > If there is a distro, or many distros, is not the real problem, the > real problem is that there needs to be a simple straightforward and > automatic way to deploy a schoolserver without needing a masters in > computer science, or even a deegree at all. It has to be fast and it > has to be simple.
Yes, this is true. Basic IPv4 setup and swapping a broken network card currently require too much command line wizardry. This is probably due to lack of time to develop a nicer interface, not a sadistic design choice. Also, once you have more servers than you can count on the palm of your hand, you really need advanced management tools such as CFengine, Puppet and BCFG2 along with advanced monitoring tools. With such advanced tools come the need for advanced UNIX sysadmins to install and manage them. I don't see any practical way to sweeten this pill. > In Plan Ceibal worked fine using debian, because they have specialized > people that can do the develpment and can do the maintenance, not > because the chose this or that distro I agree, one distro is more or less equivalent to another. What really matters is how much experience you have acquired. > > 20K webcontenido > The apache default webpage, with specialized links for games, > activities and others This does not seem to be visible in the schools. If I visit http://schoolserver , I get redirected to Plone. > > 17M xs-activation > > 516M xs-activity-server > > 827M xs-rsync > I don't remember I know about these... they don't need to be backed up. > > 2.7G zope-var > Since plone works with a "selfcontained" filesystem for its webpage, > this _single_ file was going to be backed up to the datacenter as > well, i think this is the folder, but i remember that it had to go to > the backup folder anyways Isn't there a way to perform garbage collection on this file? Or do you think that school is really storing 2.7GB of data in Plone? > This problem is more related to the way the journal stores the files > and the metadata, I remember little about it, but the main problem > with backing up a laptop is no just about taking files, any single > file in the datastore doesn't get you a back up, you have to take the > whole datastore folder. > > Incremental, or differential backups could be made if the datastore > treated the files differently, I'm sorry if I hurt some > suceptibilities, but is the truth, there's no simple way to back up > _just the data_ from the journal, you back it all or nothing, because > _part of it_ is useless. Yes, but metadata consists of very tiny files compared to actual data files, which is often multimedia content. Sascha designed some kind of datastore object bundle which encapsulates data and metadata in a single archive, to be used for backups and data transfers. Even if it were already available, this new backup format wouldn't solve the fundamental problem that backups of all journals in a school amount to 260GB, though. Backing up the datastore with a simple rsync is simple and fast. Note that hardlinks are already being used to reduce the size of incremental backups as much as possible and the Sugar datastore does not modify or move around application data once it has been created. > I don't know if that improved in the newer version, but 0.82 (i think) > is the one that was used in Paraguay, is like that The datastore layout changed radically from 0.82 to 0.84. In Dextrose-1, we force an index rebuild after restoring a backup, so even a partial backup would be useful. But why would we not want to backup everything? >[...] > > Paraguay in that sense did something really cool.. install the > schoolserver _in house_, update it and send it to the field, but in > the fild had to go somebody that could make the adjustments for the > network to work, and that simple task was very difficult sometimes, > and updating the leases and content when no conection is available is > not fun either. After over one year, we're still sending out a sysadmin from Asuncion to Caacupe for every non-trivial operation that needs to be performed from the console. This would obviously not work with a nation-wide deployment. Tomorrow I'll try to interview the people of Plan Ceibal to figure out whether they managed to train field technicians even in the most remote areas or if they've got a sysadmin taskforce that gets parachuted on demand. > The plone deployment was based on a decision to give the schools a > simple CMS, not simple in deployment, but simple in using, using a > plone CMS to create content is super friendly, but in time, none of > the teachers or students got to used it (simple or not) The per-school Plone instances have been superseded by a centralized version which the education team seems to be using for uploading documents: http://biblioteca.paraguayeduca.org/ > They used this tool instead because they learned how to use it during > teachyer training, and they like it, it had an issue that once with > access you could delete your co-workers files, but they used it > anyways A wiki has the same issues, but with versioning you can easily revert any vandalism, so it could be opened even to children. > When a CMS was proposed, and later plone was accepted, i recomended > dokuwiki, but for personal reasons i have to say, i have experience > with dokuwiki, and deployment, updating, backup and other stuff is > super fast (because it doesn't use a database, uses text files and > folder schemes), but a being a wiki, is not as friendly to the newbie, > because of the special syntax and all Except for Mediawiki, all the wikis I used use plain files or a VCS as their backend. Some wikis come with WYSIWYG ajax editors, but I find it simpler not to teach users much about the wiki syntax, so they mostly write plain text. The minimalistic wikis excel in not tempting users to waste too much time on syntax and concentrate on content instead. >[...] > If i think about what deplying in rwanda, uganda or even tibet, where > the laptop is intended to go. There is no internet there, so their > experience should point us to some key features that need to be > included in the schoolserver Agreed. > I'm sorry this got so long, but there was plenty to be said.. :-) Thanks for taking the time to summarize your first-hand experience, it's much appreciated. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel