That’s horrible. Do they really think that will cause people to have kids? And if there is an increase in unplanned pregnancies as a result, do they really think that’s the best environment for the child and parents?

It strikes me that they are just grabbing for whatever lever they can to try and “fix” their demographic problem, without understanding the underlying factors, and ultimately it will be women who get caught in the crossfire.

Ok, no pressure anyway! Thanks for looking into it :)

I’m not sure if your RSS reader is getting the content through some special way. The feed itself only has the first two paragraphs:

<item>
  <title>The Linux kernel is just a program</title>
  <link>https://serversfor.dev/linux-inside-out/the-linux-kernel-is-just-a-program/</link>
  <guid isPermaLink="true">https://serversfor.dev/linux-inside-out/the-linux-kernel-is-just-a-program/</guid>
  <description>Most books and courses introduce Linux through shell commands, leaving the kernel as a mysterious black box doing magic behind the scenes. In this post, we will run some experiments to demystify it: the Linux kernel is just a binary that you can build and run.</description>
  <pubDate>Mon, 01 Dec 2025 00:00:00 GMT</pubDate>
</item>

It’s a very good explanation. I like that it is short and hands on. For me, it is pitched at the right level and the practical style keeps it very grounded.

what you’d add or change for future posts in the series

I wouldn’t change anything to do with the content! Speaking personally, I’m a fan of full text RSS feeds, so I’d love one on this blog if that’s an option :)

I say XMPP below as that’s what I’m most familiar with, but you can replace it with Matrix or any other open federated network :)

would it theoretically be possible to just replicate Discord’s UI and UX and build it on top of the Matrix or XMPP protocol instead of starting from scratch?

It’s complicated. I agree that copying the UX of the proprietary apps to provide a familiar experience would help get some adoption. That way we don’t have to convince someone to switch network and user experience at the same time.

If we had an XMPP-based Discord clone, WhatsApp clone, Telegram clone etc., all interoperating with XMPP under the hood, I think it would be much easier to go to each friend and get them to switch to the clone of the service they like the most. And, everyone could still talk to each other no matter what UI they were using.

I think the reason why Conversations is so successful, compared to other clients, is that it started essentially as a clone of Hangouts.

but if developers and users agreed to focus on a stack

There’s the problem, though. Developers are never going to agree on a single solution :)

There are limited numbers of developers really familiar with the nuts and bolts of XMPP, and they are already swamped maintaining the existing software.

I think this can be solved though by separating the UI from the backend as much as possible. If experienced XMPP devs work on libraries, and experienced UI devs work on replicating proprietary UIs, someone can then wire whatever frontend and backend together that they want.

I think this can get you 80% of the way there. The last 20% will be challenging though, as you won’t be able to replicate the UX exactly: the experience you want to provide will clash with the way the existing network already works.

So, in some ways, it’s cleaner to just provide a completely different experience and say “this is what XMPP is”.

What I’m not sure about, is how important that last 20% is. On one hand, a user might like that the app seems to function like one they’re used to. But then, I can see them having less patience and saying “this is broken” in the areas it doesn’t work like they expect. I feel they are likely to be less forgiving about the bits that aren’t the same, if everything else is a replica. And, they won’t understand the nuance that it’s more difficult to have a consistent experience across different clients and servers, they will just say “this app is broken and I’m going back to the proprietary one”.

Meanwhile, the status quo, where we say “you have to switch networks and also learn how XMPP differs from everything else at the same time” has its own problems, because people just do not feel comfortable changing so many things at once. So long story short, it’s tricky :)

Repology might kinda help for your use case. It lets you search for software that is packaged on many different “families” of distributions. You can also filter by category.

Admittedly it does kinda depends on your definition of popularity. But it’s good at answering these questions:

• Is this widely regarded as free software?
• Has it been around for a while?
• Is it useful enough to have been packaged in many places?

I run a prosody server and have a couple of users who run Monal, and notifications work reliably for us!

I made sure to follow the considerations for server admins and it’s been ok.

Regarding the push service: unless you deploy your own version of the app, it’s not possible to self-host your own push service. The flow looks like this:

XMPP server -> Monal pushserver -> Apple pushserver -> Device

Apple only allows the developer of the app to send notifications to their push server. They enforce this by giving the app developer a key specific to their app.

The linkage between XMPP server and Monal pushserver gets set up by Monal: when it connects to the XMPP server, it instructs it to send messages while it is offline to the Monal pushserver.

Idempotence / self-healing: the system should be built in such a way that it tries to reach the correct end state, even if the current state is wrong. For instance, every time our system gets an update, it will re-evaluate the calculation from first principles, instead of doing a diff based on what was there before. This prevents bad data from snowballing and becoming a catastrophe.

Giving yourself knobs to twiddle in production: at work we have ways of triggering functionality in the system on request. Basically calling a method directly on the running process. This is so, so useful in prod issues, especially when combined with the above. We can basically tell the system “reprocess this action/command/message” at any time and it will do it again from first principles.

Debugging: I always first try and find a way to replicate it quickly. Then, I try and simplify it one tiny step at a time until it’s small enough I can understand in one go. I never combine multiple steps per re-run and always verify whether the bug is there or not at every single stage. This can be quite a slow approach but it also means I am always making progress towards finding the answer, instead of coming up with theories which are often wrong, and getting lost in the process.

I write my CV in Markdown (just headers and bullet points), and then use pandoc to generate a pdf. Very easy and straightforward!

This has landed me interviews although not hired (I think that’s down to me, not the format of my CV 😅)

pandoc \
--variable title-meta:"ambitiousslab - CV" \
--variable author-meta:"ambitiousslab <ambitiousslab@example.org>" \
--variable lang:"en-GB" \
--variable geometry:margin=1cm \
--variable colorlinks:true \
--variable pagestyle=empty \
cv.md \
-o ambitiousslab-cv.pdf

My next laptop will probably be a Thinkpad T480 from Minifree. But I reckon it will be a while before this one breaks in an irreparable way.

CAD + ML is certainly difficult, maybe that needs a dedicated machine you only use for that? But that will increase costs overall. I’m also not sure how to find PC parts that I know won’t need dedicated firmware. So that part is definitely more tricky, I’m sorry I can’t be more help here :(

As for Matrix and XMPP, I started off with Matrix and found it pretty good for bridging lots of different networks together. But, over time, I came to prefer XMPP for a few reasons:

• Ultimately, I just don’t trust Element, and they do so much of the work. They complain that people are dependent on them and don’t give back, but they were the ones that created this dynamic in the first place. They are a single actor who own the dominant server, clients, and flagship instance, and can really push around the ecosystem in a way that works for them.
• XMPP is more community oriented, no one person can push through changes either at client, server, or server operator level. XMPP is based around extensions and there is an expectation that not every client or server implements every extension. That brings the con of inconsistent experiences, but at the same time, it is much more resilient over the long term (Matrix is now having to deal with the same fragmentation problems that XMPP started experiencing, and building solutions for, 20 years ago).
• XMPP’s network is less centralised, there’s not a mega-server like matrix.org with a lot of power. When matrix.org goes down (which happens semi-regularly), there is a big impact. If a single XMPP server goes down, it doesn’t cause nearly as big a problem. And, there aren’t those mega-instances with scaling problems, so the servers don’t go down as frequently anyway.
• XMPP evolves more slowly and gracefully IMO, as it is already more established (might be a con depending on your worldview). I run debian stable and an update across the Matrix network broke images on my Matrix client. That just doesn’t happen on XMPP, you can lag behind the leading edge for a couple of years and things don’t break even as the network evolves.
• I find XMPP easier to self-host - again subjective, but I could just install prosody via Debian’s archives, and once it was set up, I didn’t have to touch it. I update it with the rest of my server every 2 years, and I don’t fall behind the rest of the network or miss out on much in the meantime. Meanwhile, I have to pay much more attention to my matrix server, I get the software from upstream and not from my distribution, and there are more regular changes that I have to pay attention to.

As for advantages of Matrix:

• They have a flagship client that is available everywhere and has a decent and consistent UX. That name recognition makes it easier to get people to sign up. The XMPP community have done a lot of work to make signups work easily in a decentralised way, and projects like Snikket aim to solve that name recognition and consistency problem, but it is not 100% perfect yet.
• Bridge software to proprietary networks is more actively maintained in Matrix. There is work going on to improve this in XMPP, but I think many in the XMPP community moved focus from bridging to making the first-party experience better.

Many of the pros and cons are based on values (e.g. living on the leading edge vs using something more mature, preferring community based solutions vs commercial ones etc.), so I totally understand and support people who use Matrix instead. Ultimately, both ecosystems can cooperate, learn from each other and are millions of times better than the proprietary networks. That said, above is why I came to prefer XMPP.

I’ve had similar feelings before. You’re not the only one to struggle with this. You are pushing against the grain and doing something, aligned with your values, that 99% of people don’t know about.

What helped for me is separating what I can control from what I can’t. Everything on my device, that I personally choose to use, is under my control. So that is all free software, downloaded from system repositories, because I care about that. Meanwhile, everything I can’t control, I just gradually try to improve over time.

Here are the things I feel I can’t easily control:

I bought a laptop many years ago without free firmware for wifi, bluetooth, microcode etc. I like using devices as long as I can. Ok, no worries, lets just replace it with a Thinkpad next time.

My employer requires me to use Zoom, and some proprietary VNC client on my own device (on top of a load of proprietary software that I run on their devices). I don’t really have a choice here, unless I quit my job. So, I give in the short term, but do what I can to minimize the damage, running it in a dedicated VM. For the long term, I try and keep an eye on FOSS job boards and also network with people in the FOSS world (I’m quite bad at this, but trying to get better).

Likewise, some of my friends haven’t switched over to XMPP, which is my network of choice. Eventually, the people closest to me did, but many did not. So, I bridge those who haven’t into XMPP (via Matrix, for now, but looking to remove it eventually), and decided that I don’t want anyone “new” to contact me through the proprietary networks (I haven’t set up “enforcement” for this, an autoresponder probably, but this is the plan). The good news is that the proprietary networks always screw up eventually. When they do, your friends will get pissed off for their own reasons, and that is your chance to offer them the alternative. I never push, but let people know that I use XMPP. Some become genuinely interested, others you have to wait until they get screwed over by the proprietary networks.

Now bear in mind I am more interested in software freedom than security. So your priorities might be different. But the short story is: don’t beat yourself up over this. It’s a journey and you are pushing against the rest of society. What I do is just try and improve my setup, whatever that means to me, gradually over time.

For services only I depend on, I have production-only. Since I can only inflict damage on myself, and can often work around problems.

For the XMPP server my friends and family also depend on, I have a dedicated nonprod VPS. My services are driven by ansible playbooks, so I’ll tweak the playbook with whatever change I want to make works in nonprod, before running the same playbook against prod.

Whenever there’s a new Debian Stable release, I’ll rebuild the servers completely, to try and prevent “drift” between the nonprod and prod versions (not that I change things often enough for this to become a big problem). This is also the big test of my backups, which so far haven’t been needed in a “real” emergency 🤞

Yep

I can highly recommend Mythic Beasts (UK).

There is no upsell or variable pricing and they make money by charging a flat rate on top of the cost from their supplier. See this blog post for more info

I agree, it’s a great UI in terms of speed and no JS, but it’s not super intuitive and not helped by the way it’s been split into modules.

Basically, each subdomain (git.sr.ht, todo.sr.ht etc) doesn’t link to the others - the only one that links everywhere is the root “sr.ht”. You can think of sr.ht as a “hub” that links to the others. So - to take an example:

• You can open “tickets” (todo.sr.ht) from https://sr.ht/~delthas/senpai/
• But - if you click on “source” (git.sr.ht), the references to the other pages anymore (including back to the hub)

So, in your case, if you replace git.sr.ht with just sr.ht in the URL, it should take you back to the “hub” for that project. Then, if the tickets feature is enabled, you should see a link to “tickets” there.

The frontends provide other benefits on top of just privacy - e.g. invidious lets you watch youtube videos without javascript, download videos directly on some instances, etc.

Monal comes close.

I’ve had good fortune converting some family and friends to use XMPP.

People always mention fragmentation, and while there is some truth to it, it can be massively minimised by choosing blessed clients and servers for them to use.

In my case, I run my own server, and thoroughly test the clients (especially the onboarding flow) that I expect them to use, so that any question they have, I can help them out with quickly. Since we’re all on identically configured servers, it minimises one whole class of incompatibilities.

There is still unfortunately a bit of a usability gap compared to Signal - particularly on the iOS clients. But they have come a long way and are consistently improving.