dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Haxx will stop hosting most Rockbox services after 2020

Re: Haxx will stop hosting most Rockbox services after 2020

From: Solomon Peachy via rockbox-dev <>
Date: Sat, 8 Feb 2020 09:25:33 -0500

On Sat, Feb 08, 2020 at 12:38:14AM +0100, Daniel Stenberg via rockbox-dev wrote:
> As mentioned in the subject, the Haxx team (me, Björn, Linus and Kjell) will
> stop hosting most Rockbox related services on January 1st 2021. It should
> give everyone plenty of time to find new places and alternatives for
> everything that needs to survive.

That's a remarkably generous timeframe, thank you!

(On top of many, many years of generous hosting services, thank you again!)


(I started this conversation on IRC, but wanted to elaborate more here)

The problem I see with some of those proposals is that it mixes both
hosting migration and retooling, and the current level of user and
developer interest doesn't seem to support a major retooling effort.

It seems to me that the main problem with the existing infrastructure is
a lack of general maintainance, and IMO it would take less overall work
to actively maintain what we have than to completely retool. The fact
that things still work as well as they do is a testament to how well
they were put together, especially the build system.

Migrating the existing infrastructure as-is to systems that current
developers can maintain is IMO the best path forward. After the hosting
crisis is mitigated, then we can turn our attention to making whatever
incremental (or major!) changes we see fit, but on a more relaxed

I'm also not keen on retooling around proprietary services like github.
I think being able to self-host is extremely important.

So. If we're to migrate stuff off of the haxx infrastructure, we need
to know more:

 * Is the existing * stuff self-contained on a single
   dedicated server/VM, or are the services spread out onto multiple hosts?
   (If it's all self-contained, then migrating as-is will be a lot easier)
   (if it's not, then we'll need to know what the service dependencies are,
    eg php, database(s), and so forth)
 * What is the typical server resource load? (CPU, RAM, disk)
 * What is the typical bandwidth usage? (ideally on a per-service basis;
   I imagine serving the builds, followed by git & builder infrastructure,
   are the biggest users)

I already self-host my entire digital presence [1], so depending on the
answers to the above questions, I should be able to host all of the
haxx-hosted rockbox services with only an incremental level of effort.

I think DNS and _at_rockbox email/lists should probably move too, but those
can probably be the last to go -- This way HAXX never has to be bothered
about anything rockbox ever again. :)

Anyway, thought I'd help keep the conversation going. The level of
effort needed for various actions really depend on the details involved,
and I think the more information we have, the better a plan we can come
up with.

[1] DNS, email & mailing lists, web (plus php and python), wikis,
    databases, git repos (gitolite + cgit), flyspray, xmpp, a rockbox
    builder, shell access, and more. This server is 12c Opteron, 32GB
    of ram, and about 5TB free RAID disk space, piggbacking on an uncapped
    fiber feed that routinely exceeds 500Mbps uplink bandwidth.)

    At home I have a lot more compute resources, with a private jenkins
    instance for my other F/OSS work, multiple VMs, and another rockbox
    builder... but with a very crappy 2Mbps uplink. I have a third site
    with a slightly crappier uplink that I was intending to set up with
    additional CI builders, but need to swap the server out first.

 - Solomon
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Received on 2020-02-08

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy