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 at 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 <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)