Re: Copy of Openmokast Case Extension Back Files?

[dmitry]

Hi Alexander, 

I would be interested to have it too. 
Did you manage to find that archive? 

Dmitry 

On Sun, 15 Oct 2017 21:37:18 +0100
"Alexander .S.T. Ross"  wrote:

> http://openmokast.org/files/cad/Openmokast_ProE.zip is dead and nor is
> the zip on the internet archive, only the webpage.
> 
> I would be interested in having a copy of the files to make this case
> extension :). Anyone got a copy?
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: The future of openmoko.org hosting

[dmitry]

Hi Harald, 

Which way that was eventually solved? 

If it is not solved yet, I theoretically have some resources to host
major (probably all, except of email services) part of that. 

let me know, 
thanks! 

Dmitry 

On Sun, 15 Oct 2017 10:59:34 +0200
Harald Welte  wrote:

> 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
> 

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community