est.social on üks paljudest sõltumatutest Mastodoni serveritest, mida saab fediversumis osalemiseks kasutada.
est.social on mõeldud Eestis üldkasutatavaks Mastodoni serveriks. est.social is meant to be a general use Mastodon server for Estonia.

Administraator:

Serveri statistika:

88
aktiivsed kasutajad

#snac2

0 postitusega0 osalejaga0 postitust täna
Vastatud lõimes

So, basically the platform you stopped to use increased the incoming traffic and even makes the half of the "Mastodon" traffic in the last days? Doesn't this show how important this source is and how much potential there still is?

Next, I'm wondering why "Mastodon" is defined as "Mastodon". #Mastodon is one of multiple solutions in the #Fediverse and I'm more than pretty sure that many people are not using Mastodon, rather than #snac / #snac2, #GoToSocial,... It's like setting "Internet Explorer" as a synonym for browsers.

@mho @heiseonline

Vastatud lõimes

@LateNightLinux

While I outsource the VM management to several VPS hosts, once I have the VPS, I self-host my mail, calendar, website, finances/ledger, and RSS (different methods for myself and my sweetheart), with plans to add my own ActivityPub server (likely #snac2), #NextCloud, and photo-hosting.

I currently outsource our family photo-album to a site I detest¹ so it's one of the first ones I plan to migrate to my VPS once I find the opportunity.

I also trust @stefano to host my ActivityPub presence in the interim.

¹ Site5 *used* to be a fantastic shared-hosting service, until EIG bought them out, fired all the competent tech staff, and overprovisioned hosts. Avoid any EIG property like the plague.

Publishing a photo of approximately 4MB from my snac instance (at home with 20 Mbit/sec uplink) meant overwhelming everything.
This happened because, for every remote instance, Nginx was requesting the multimedia file from snac. However, due to saturated connections, it took several seconds, leading to thread exhaustion in snac.
I resolved this issue by caching the multimedia files myself using Nginx, which significantly improved performance.

This matter will be covered in a subsequent (simple) blog post.

#snac#snac2#nginx

Dear friends of the BSD Cafe,

As 2024 comes to an end, it’s time to reflect on what we’ve built together during the first full year of life for BSD Cafe. Launched on 20 July 2023, this project has grown far beyond what I could have imagined. While I haven’t tracked full uptime data, I can confidently say that the downtime was less than 30 minutes overall - even though the main VM hosting our services moved multiple times (including a switch from a Proxmox hypervisor to bhyve on FreeBSD, for the sake of alignment with our mission). In a world filled with over-engineered HA systems, we’ve outperformed many “big-name” cloud providers. Not bad for a community project, right?

For me, this has been an incredible journey. The users here are not just participants - they’re collaborators, and their positivity has been inspiring. The content shared and created at BSD Cafe has been valuable not only to the BSD community but beyond. What truly sets BSD Cafe apart is the openness for dialogue and exchange. Whether it’s social media posts, Matrix discussions, repositories in our brew, or RSS feeds, people seem to genuinely appreciate what we create and the conversations we foster.

BSD Cafe is a journey - one that grows, evolves, and continues. Our goal isn’t endless growth (we’re a community, not a business) but rather to maintain a welcoming, inclusive space where everyone feels a sense of positivity and belonging. For me, opening any service with “bsd.cafe” in the domain brings joy and pride. That’s the spirit I’ve tried to convey, and I hope it resonates with all of you, whether you’re active BSD Cafe users or friends of the community.

Promoting self-hosting and #OwnYourData has, as a side effect, inspired some users to “go solo” with their own setups. But even then, they remain part of BSD Cafe - in spirit, in purpose, and in connection.

Here’s a look at what we’ve achieved together this year:

- mastodon.bsd.cafe: 370 total users
Active in the past month: 207
Active in the past six months: 286
- snac.bsd.cafe: 14 total users
Active in the past month: 7
- blendit.bsd.cafe: 61 registered users
- matrix.bsd.cafe: 23 users
- brew.bsd.cafe: 29 users - 80 repositories
- freshrss.bsd.cafe: 25 users
- miniflux.bsd.cafe: 11 users
- press.bsd.cafe: 9 users
- myip.bsd.cafe: Constantly used by various users
- wiki.bsd.cafe: Could use a bit more love and content, but it fulfills its role as a functional homepage.
- tube.bsd.cafe: Still in testing - Peertube 7.0 update is on the way.

For detailed stats from our reverse proxy and general router (excluding media services, which generate most traffic but are handled via caching reverse proxies), you can check here - updated hourly: netstats.bsd.cafe

The journey of BSD Cafe continues, and I look forward to seeing where 2025 will take us. Together, we’ve built something special - something driven by passion, shared purpose, and a little bit of the BSD magic that makes all of this possible.

Here’s to a new year full of joy, serenity, and connection. Thank you for being part of this adventure.

Wishing you all a fantastic 2025 - and THANK YOU!
Stefano

netstats.bsd.cafeBSD Cafe Network Traffic Statistics

A small compendium of the Fediverse platforms I use/know well.

In the past few days, I revisited some of my old Fediverse instances since some friends asked me to help them set up a new one. I also took the chance to perform maintenance on some leftover instances. Here's my experience:

Akkoma: My oldest instance still running, opened in 2022. It was offline for a few months (3/4). I updated everything to the latest version and restarted it. I’m not sure why, but it’s extremely slow, with a heavy load on Postgres and many queries just to open the main page. I like Akkoma - I'll investigate further.

GoToSocial: I updated a friend's instance - GoToSocial itself was up-to-date, but the underlying system wasn’t. I noticed that once it exceeds 2000 followings, it becomes a bit slow. The database is PostgreSQL, but that's not the issue. The GoToSocial process becomes somewhat heavy on the VPS. Still, it's very usable and a software with great potential, in my opinion. The Mastodon API is implemented quite well and works with the major software.

Mitra: It seems well-built. The person had around 1000 followers and followings on a Mastodon account, which they moved from a large instance. No speed issues, though sending a message makes the server “heavy” for a bit, but it’s temporary. The Mastodon API is partially implemented, but the software is advancing quickly, and I find its native interface quite pleasant.

Snac2: I've always had a soft spot for Snac2. The lack of a database and some design choices make it an excellent solution for small instances. For example, sending posts to all known instances increases visibility and interaction. Its basic, JavaScript-free interface is very clear, though it might not be the best for those used to Mastodon. But the Mastodon API is improving version by version, and I think the developer is doing an excellent job. It struggles a bit with larger numbers, but that's due to the underlying file system, not the software itself. If "move" support (both in and out) were added, I would recommend it to anyone starting self-hosting for single-user or small community instances because "move" is one of the options that gives the most freedom in Fediverse software.

Mastodon: My “old” personal instance was stuck at version 4.1.x and had been offline for a few months. I updated the FreeBSD Jail and upgraded Mastodon to 4.2.12 and then to 4.3.0-beta1. No issues. I also helped a friend (who had an old Pleroma-based instance they barely used) migrate. This user has around 5000 followers and followings - Mastodon is running on FreeBSD on a VPS (arm64) for just over 3 euros a month, with no significant issues (apart from media storage, but that's not Mastodon’s fault). Mastodon is sometimes said to be heavy, and that's partly true, but its modularity ensures that even in cases of overload, queues may slow down, but navigation and the local timeline remain reasonably fast. I think this is a good thing for any larger-scale use of an instance.

In short, I think things are moving in the right direction, and the software is evolving nicely. Well done, devs!