OCaml.org: recapping 2022 and queries on the Fediverse

Energy Usage

I punted on this in my recap as I hadn’t had a chance to catch up with @patricoferris about it, but since it’s a very important topic let’s start talking about it incrementally now instead of waiting for that!

In the redesign for the new site, we explicitly removed third-party trackers and took advantage of the spare screen space (usually reserved for a privacy policy, now no longer needed) and put in a OCaml.org carbon footprint statement as a placeholder until we obtained more specific data.

Later in 2022, @patricoferris investigated how we could do better in terms of power monitoring, and is developing a suite of OCaml tools that will hopefully be useful to the wider community as well:

  • Variorium collects hardware-level power counter information, for accurate monitoring
  • Carbon Intensity is a tool to integrate with country-level APIs for where energy is primarily coming from, in the absence of more specific information from the datacentre provider.
  • Clarke combines all this into a convenient Prometheus monitoring, for centralised analysis.

These are all still unreleased, and I’ve opened a tracking issue about the deployment of these into the ocaml.org cluster. If anyone would like to help out (particularly around finding more accurate APIs for carbon intensity) then feel free to open issues/PRs on those various repositories.

Some services, such as restoring inbox.ocaml.org are a little blocked on this topic as I’m reluctant to provision more long running virtual machines without thinking through more efficient alternatives that can consolidate services (e.g. have just one SMTP endpoint instead of multiple). My apologies to @xavierleroy and @nojb for the delay, as they have both done a bunch of work towards restoring it already, and I’ll do my best to catch up this month.

Privacy

The only digital communications mechanism that we’re using that features end-to-end encryption is Matrix. That implies that, as a general rule, that most of the alternatives such as Slack, IRC, Discord and Mastodon, do allow their respective admins to read your messages. Discourse (the software powering this forum) has explicit support for admins to monitor private messages for online safety reasons, although to my knowledge this facility has never needed to be used for this deployment.

If you want a reasonably usable mechanism for private messages, then Matrix is the way to go, including for encrypted group channels, and all the other services are one security breach away from going public.

As for the discussion about openness, I’m personally not really a believer in being radically transparent when doing open-source work. I find it really difficult to focus on a topic when in the public eye, and instead prefer to work on it with my immediate collaborators and then have an open discussion about it. What I really miss is the ability to promote information that results from the private discussions into a more open forum – all these recaps and newsletters are entirely written from scratch, and the inefficiency means that it’s a huge amount of effort to get right. It’s easy to put the time in with full papers since there is a reward structure (for academics, anyway) in place via the conference circuit, but less so for other mediums. A project I’m going to return to sometime this year is Bushel, where I’ve been prototyping a communications format suitable for iterative promotion and integration with data scrapers.

Source mirroring

To be clear, there’s no special ‘maintainer bit’ or survey required to give your feedback – a maintainer is just someone who puts the time in to help out with a particular area. For example, we got brilliantly helpful external feedback for the opam archive migration here just a few days ago.

I do like SourceHut a lot, but we’d ideally self-host it, and that’s quite a bit of work due to its microservice architecture. It should be possible to strip down the services (remove the autobuilders and bug trackers) for a read-only mirror, and so a good way to contribute would be assemble a Docker compose file with such an installation and demonstrate how it might work with a sample set of Git repositories to mirror. If you (or anyone else reading this) wants to have a go, feel free to create an issue on Issues · ocaml/infrastructure · GitHub with your prototype.

8 Likes