Copy of Openmokast Case Extension Back Files?

[Alexander .S.T. Ross]

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

The future of openmoko.org hosting

[Harald Welte]

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

10 Years Openmoko Neo1973 anniversary dinner

[Harald Welte]

Dear Openmoko community,

about one week ago, on October 7, a group of former Openmoko team
members got together to in Taipei to celebrate the tenth anniversary of
the release of the Openmoko Neo1973 (GTA-01).

In terms of attendance, the following people were able to make it:
* Sean Moss-Pultz
* Milosch Meriac
* Nyeng-Yu 'Tony' Tu
* Jim 'jserv' Huang'
* Jollen Chen
* Wolfgang Spraul
* Holger Freyther
* Guillaume 'charlie' Chereau
* Jouston Huang
* Harald 'laforge' Welte

It was great to meet.  Would have been even better to meet more of the
many people involved in both Openmoko the company as well as Openmoko
the FOSS project.  But sure, for the westerners involved in the project,
the trip to Taiwan is simply too far.  And of course many people have other
priorities or schedule, and/or might not hold Openmoko in as fond
memories as I did.

You can find a group picture in Milocsh's tweet at
https://twitter.com/FoolsDelight/status/916723871641780224

Regards,
Harald

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