Dear community, Given that we've just head the 10 year anniversary of shipping the Neo1973, this also marks about the ~ 8th-9th year of inactivity in the project.
Ever since Openmoko, Inc. closed down, I've been personally covering the hosting fees for the (single, consolidated) openmoko.org machine. I did that in order to keep the legacy/history alive, for those who might be interested in it. While it was/is "only" EUR 50 per moth, it adds up. Over the at leaset 8 years, that's at least EUR 4800. I was happy to contribute that. However, I don't want to continue this kind of financial obligation for another ten years or even any indefinite term. Please note that the actual burden of system administration is contribute by volunteer work from Paul Wise, which is of course much appreciated! So the question is in general, how to proceed here. One could a) try to put funding on some more shoulders than just me, and continue with that one hosted machine as-is b) get rid of the existing server, by the following strategy: * web: convert the dynamically-generated media-wiki, trac, svnweb, gitweb, etc. pages into static renderings that can be served from a static web server. This could be done by something like a recursive wget through a http cache. This would remove the need to run trac, mediawiki and apache mod_svn, mysql, ... - and drastically reduce the CPU and Memory requirements. In the end, it would be a bunch of static HTML pages rendered by nginx or lighttpd somewhere on a virtual server or shared server. * lisst: migrate the single remaining active (community@lists.openmoko.org) to another mailman instance, such as lists.osmocom.org. We could configure mailman to retain the list-id and simply point the MX to the osmocom.org server, i.e. do this without any impact on the list address or users mail filtering rules. * e-mail: discontinue e-mail services at openmoko.org (except e-mail forwarding). To my knowledge, only Joerg Reisenweber is using this service today - and to be fair, I would kindly suggest to use a different imap-capable home for his e-mail after about a decade of using the Openmoko legacy. Sorry :) * svn: discontinue svn service and simply have * caches of the rendered html pages (for old hyperlinks to work), * a git conversion of the old svn tree. for svn.openmoko.org, I have done this and published it at https://github.com/openmoko/openmoko-svn * git: discontinue git service and simply have * caches of the rendered gitweb html pages (for old hyperlinks to work), and * the mirror at github.com, which I just created: https://github.com/openoko Yes, I'm fully aware that github.com is a proprietary service, and they can at any time take those repositories down and/or stop the free service. I'm not suggesting anyone use this for active development projects. But just to have a historic archive of code around that hasn't changed for 9 years, I think it's ok. Running a git server with a kernel tree inside requires quite a bit of resources, and running gitweb or cgit with all the crawlers out there can be a major CPU/RAM/IO hog. If we can avoid this, we basically eliminate the need for a separate machine for openmoko.org * USB VID/PID repository: This is so far kept in the Mediawiki, but I don't see a reason why this couldn't simply convert to just being a static CSV file that's on a http server, or a small, simple git repository with that CSV file inside. Any comments/ideas/suggestions/complants? I'm all-in for moving towards 'b'. Next to the fact of basically reducing our hosting requirements to zero, it also has the advantage that we don't have to worry about keeping trac,mediawiki,etc. installations secure and updated. Also, when moving to major new versions, there's always the risk of some issues with migrating the old data, some wiki rendering errors, etc. - conserving the generated output saves us from all of that. If we go for 'b', this would include us releasing SQL dumps of the trac, mediawiki, svn, etc. databases (probably clearing any passwords / password hashes), so that the raw information can be restored by anyone who has an interest to it. Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community