Wandering Thoughts archives


The practical people problem with instance diversity in the Fediverse

Recently I was reading Kev Quirk's Centralisation and Mastodon (via), which notes how central Mastodon.social and a few other big instances are to the overall Fediverse, making it hardly a decentralized network in practice. The article concludes with a call to action:

If you’re thinking about joining Mastodon, don’t just join the first instance you come across. Take a look at the sign up section of the Mastodon homepage. There is a list [of] alternative instances that you can join, all arranged by topic.

I think that more genuine decentralization in the Fediverse isn't a bad thing, but I also think that there are practical considerations pushing against it. To put it one way, if you're joining the Fediverse your choice of instance is a risky decision that you're mostly not interested in and are generally not well equipped to make.

Your choice of instance is risky in that if you pick badly, you'll wind up having to go through various sorts of annoyance and pain. Picking what is clearly a big and popular instance has an intuitive appeal to reduce those risks; a popular instance is probably not a bad choice. As far as actively choosing an instance goes, this is usually not what you're interested in. Most people are interested in joining the Fediverse as a whole, and one of the points of it being a decentralized network is that it isn't supposed to matter where you join. So you might as well take a low risk choice.

Finally, if you're trying to actively pick a good instance, most people have the twin problems that they don't know what they care about (or should care about) in instances, and even if they do know they have things they care about they don't know enough to how to evaluate instances. Oh, you can read an instance's policies and poke around a bit, but that may not give you clear and honest answers, and on top of that a lot of things in the Fediverse are only clear to people who are immersed in the Fediverse already. To put it one way, there are a lot of problems with instances (and problem instances) that aren't obvious and clear to outsiders.

All of this should be unsurprising, because it's all a version of the problem of forcing users to make choices in security. People mostly don't care, and even if they do care they mostly don't know enough to make good choices. This is especially the case if they're new to the Fediverse.

tech/FediverseDiversityChallenge written at 23:45:28; Add Comment

My mixed feelings about 'swap on zram' for Linux

Recently I read about how Fedora will be enabling 'swap on zram', including for upgraded machines, in a future version of Fedora. I suspect that a similar change may some day come to Ubuntu as well, because it's an attractive feature from some perspectives. My feelings are a bit more mixed.

Zram is a dynamically sized compressed block device in RAM (ie a compressed ramdisk); 'swap on zram' is using a zram device as a swap device (or as your sole swap device). This effectively turns inactive RAM pages into compressed RAM in an indirect way while pacifying the kernel's traditional desire to have some swap space. The pitch for swap on zram is very nicely summarized on the Fedora page as 'swap is useful, except when it's slow'. Being in RAM, swap on zram is very fast; it's the fastest swap device you can have, faster than SSD or even NVMe.

(This implies that how much of an advantage swap on zram is for your system depends partly on how fast your existing swap storage is. But RAM is still much faster than even NVMe.)

The drawback of swap on zram is that it is not really freeing up all of your memory to 'swap things out'; instead the estimate is that it will generally compress to about half the previous size. This drawback is the source of my mixed feelings about swap on zram for my Fedora desktops and our Ubuntu servers.

On my Fedora desktops, I generally barely use any swap space, which means that swap on zram would be harmless. If I do temporarily use a surge of swap space, being able to get the contents back fast is probably good; Linux has generally had an irritating tendency to swap out things I wanted, like bits of my window manager's processes. Both my home machine and my work machine have 32 GB of RAM, and peak swap usage over the past 120 days has been under a gigabyte, so I'm barely going to notice the memory effects. As a result I'm likely to leave swap on zram in its default enabled state when Fedora gives it to me.

Unfortunately this is not the case for our Ubuntu LTS servers. Those of our Ubuntu servers that use much swap at all tend to eventually end up with their swap space full or mostly full of completely idle data that just sits there. Keeping even a compressed version of this data in RAM is not what we want; we really want it to be swapped out of memory entirely. Swap on zram would be a loss of RAM for us on our Ubuntu servers. As a result, if and when Ubuntu enables this by default, I expect us to turn it off again.

One way to put this is that swap on zram is faster than conventional swap but not as useful and effective for clearing RAM. Which of these is more important is not absolute but depends on your situation. If you're actively swapping, then speed matters (fast swap lowers the chances of swapping yourself to death). If you're instead pushing out idle or outright dormant memory in order to make room for more productive uses of that RAM, then clearing RAM matters most.

linux/SwapOnZramMixedFeelings written at 00:02:36; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.