Rockbox mail archiveSubject: 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 <rockbox-dev_at_cool.haxx.se>
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 *.rockbox.org 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 , 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
 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 Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur.