GitLab has been working on support for ActivityPub/ForgeFed federation as well, currently only implemented for releases though.

Mercurial does have a few things going for it, though for most use-cases it’s behind Git in almost all metrics.

I really do like the fact that it keeps a commit number counter, it’s a lot easier to know if “commit 405572” is newer than “commit 405488” after all, instead of Git’s “commit ea43f56” vs “commit ab446f1”. (Though Git does have the describe format, which helps somewhat in this regard. E.g. “0.95b-4204-g1e97859fb” being the 4204th commit after tag 0.95b)

It’s somewhat amusing how Itanium managed to completely miss the mark, and just how short its heyday was.

It’s also somewhat amusing that I’m still today helping host a pair of HPE Itanium blades - and two two-node DEC Alpha servers - for OpenVMS development.

Go has a heavy focus on simplicity and ease-of-use by hiding away complexity through abstractions, something that makes it an excellent language for getting to the minimum-viable-product point. Which I definitely applaud it for, it can be a true joy to code an initial implementation in it.

The issue with hiding complexity like such is when you reach the limit of the provided abstractions, something that will inevitably happen when your project reaches a certain size. For many languages (like C/C++, Ruby, Python, etc) there’s an option to - at that point - skip the abstractions and instead code directly against the underlying layers, but Go doesn’t actually have that option.
One result of this is that many enterprise-sized Go projects have had to - in pure desperation - hire the people who designed Go in the first place, just to get the necessary expertice to be able to continue development.

Here’s one example in the form of a blog - with some examples of where hidden complexity can cause issues in the longer term; https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride

Go really does do well in the zero-to-hero case, that’s for certain. Unfortunately it doesn’t fare nearly as well in terms of ease when it comes to continued development.

If you’re going to post release notes for random selfhostable projects on GitHub, could you at least add the GitHub About text for the project - or the synopsis from the readme - into the post.

I’ve been looking at the rewrite of Owncloud, but unfortunately I really do need either SMB or SFTP for one of the most critical storage mounts in my setup.
I don’t particularly feel like giving Owncloud a win either, they’ve not been behaving in a particularly friendly manner for the community, and their track record with open core isn’t particularly good, so I really don’t want to end up with a decent product that then steadily mutilates itself to try and squeeze money out of me.

The Owncloud team actually had a stand at FOSDEM a couple of years back, right across from the Nextcloud team, and they really didn’t give me much confidence in the project after chatting with them. I’ve since heard that they’re apparently not going to be allowed to return again either, due to how poorly they handled it.

I’ve been hoping to find a non-PHP alternative to Nextcloud for a while, but unfortunately I’ve yet to find one which supports my base requirements for the file storage.

Due to some quirks with my setup, my backing storage consists of a mix of local folders, S3 buckets, SMB/SFTP mounts (with user credential login), and even an external WebDav server.
Nextcloud does manage such a thing phenomenally, while all the alternatives I’ve tested (including a Radicale backed by rclone mounts) tend to fall completely to pieces as soon as more than one storage backend ends up getting involved, especially when some of said backends need to be accessed with user-specific credentials.

To be fair, having to interact with MS Teams with any part of your body is painful.

Been using the KeyDB fork for ages anyway, mainly because it supports running in a multi-master / active-active setup, so it scales and clusters without the ridiculousness that is HA Redis.

Haven’t really used any proper JMAP clients - since the setup is broken anyway, so mainly just curl.

You could also just run IMAP/JMAP/SMTP as separate components, I can’t see any place in the Stalwart documentation - or in the Docker image itself - where monolith is the only option.

I haven’t tested the setup myself yet, but me and another root are planning on testing a setup of Stalwart to replace a semi-broken IMAP/JMAP setup for a computer club, keeping the SMTP as is.

Probably not what you’re looking for, but I’m going to note that Turris make some great OpenWRT routers.
Currently running theTurris Omnia, and using both Wireguard and Yggdrasil through it.

I’ve been personally using KDEs Itinerary app, but it might not be what you’re looking for

It’s basically just a copy of the main leaderboard, but the scores are given based on the size of the group.

My favourite advent calendar.
Got a private leaderboard with the other sysadmins from work - as well as a few people from our application/development team.

It’s great to hear that they’re not just giving up. And it’s also definitely good to hear that they’re not sticking with PHP either, that language is a true bane to modern hosting - and especially Kubernetes.

I’ll remain cautiously optimistic that they’ll be able to stay relevant, and not go hard in again on cutting away core functionality in the name of enterprise offerings - what caused the NextCloud split in the first place.

Has anything actually happened in ownClouds development?

The last I saw of them was FOSDEM a few years back, where NextCloud were handing out whitepapers and showing off their new Hub, chat, VoIP stack, group sharing system, and more. And ownCloud were sat somewhat opposite with two people and a screen showing a screenshot of a default ownCloud install, along with a big sign hanging from the ceiling saying “Join the winning team.”

Lots of people instantly think of security when they look at WiFi-connected IoT devices, but oftentimes they never think of the WiFi signal itself - what with all the added communication noise and send time limitations of having lots of small devices.
Especially with regular consumer equipment, it doesn’t actually require that many devices to fully saturate a regular home router or AP.

If you’re taking part in transmitting a torrent over Yggdrasil, then people you’ve peered with in the swarm will definitely see your Yggdrasil IP - which is based off of the encryption key you generate (and you can change whenever you wish) for the connection to the mesh.
Regarding obfuscation of what you’re accessing inside something like the bittorrent DHT, that could likely be done with multiple Yggdrasil connections and torrent clients - so each address only associates with one torrent, it’s just not a core feature of the network itself.

The Yggdrasil network really isn’t meant to provide perfect internal anonymity between two directly communicating peers, it’s instead built to be an easy-to-use, end-to-end encrypted, mesh network - with great performance.
It’s there to protect the content and target of your communications from anyone beside you and said target, without adversely affecting the delivery of said content. Not to protect you from your communication target, though it can do a passable job at that too.

My main use of Yggdrasil has actually been as an easily setup alternative route into NATed systems, seeing as I can easily hit 600Mbit and get below 15ms of latency over it, which I quite often use to run VNC or SSH (and SCP/rsync) over. And since the mesh can be established as long as you can reach a node, it becomes ridiculously easy to get a functional link over it.
Transmitting DC++ traffic without my ISP being able to detect any of that is just a bonus.