ZFS uses the RAM intensively for caching operations. Way more than traditional filesystems. The recommended cache size is 2 GB plus 1 GB per terabyte of capacity. For my server, that would be three quarters of the RAM dedicated entirely to the filesystem.

Read my comment again, it has the answer. Most VPN services do not provide end-to-end tunnelling. If the exit node is located outside Russia, then what enters the Russian internet will be simple HTTPS traffic.

Been running it from Russia where stock WireGuard stopped working mid-2025.

Sounds like the issue is ISPs within Russia blocking outgoing Wireguard traffic from customers.

If the traffic exits the tunnel without hitting a Russian ISP (e.g. a Mullvad exit node in Sweden that routes the unencrypted traffic to the destination), you won’t be affected. If the exit node is behind a Russian ISP, it might get filtered by DPI depending on which direction is subject to the filter.

It’s problematic, but possible: https://jamesguthrie.ch/blog/multi-tailnet-unlocking-access-to-multiple-tailscale-networks/

If the other person has a Tailscale account, it sounds like the most expedient method is to simply invite them to the tailnet as a non-admin user with strict access control.

You could share a node with an outside user, but I don’t know how much the quarantine would affect its functionality. You could also use Funnel to expose the node to the internet (essentially like a reverse proxy), but there are obvious vital security considerations with that approach.

The treekie in me wants BookData.

(edit) This made me remember The Measure Of A Man and now I’m fucking depressed. They had such high hopes for the future.

Fuck, I’m an idiot. I really shouldn’t be giving advice when I’m sleep-deprived like this. I completely forgot that when I used RDP, I did it through an SSH tunnel.

Removed.

deleted by creator

1. LLMs are not a vital resource like food or electricity. Refusing to participate will at worst be an inconvenience.

2. Software can coexist. One application won’t kill another just because its developers can put out more code per hour. If it were otherwise, Linux wouldn’t exist.

I can’t fix the problem, therefore I’ll be part of the problem.

Three important factors:

• Gigabit ethernet
• SATA-attached storage
• My family not knowing what the fuck USB 3.0 is, and why blue USB is better than black USB.

Mine is using a network share to transfer files faster than any USB device we have at home.

To delegate the responsibility of securing login data to a company better equipped to deal with it (in theory at least). You can also use an external OIDC provider.

Tailscale. Create an account, put the client on the LAN device, put the client on the remote device, log in on both, you’re done. It bypasses NAT, CGNAT, and the firewall through some UDP black magic fuckery. As long as the router allows outgoing connections, it will work.

If the factory resets cause the router to lose connection to the ISP, though, then nothing will work.

Tailscale Funnel will let you expose a host to everyone on the internet. You’ll need the Tailscale client running on either the Jellyfin host or a reverse proxy pointing to it. Tailscale itself will act as a reverse proxy with TLS encryption, plus a DNS server.

Exposing a service to the internet will always present some risk. You should definitely run your LXCs as unprivileged, unless needed otherwise, to mitigate the potential damage if an attacker escapes the container, or put the services in full virtual machines.

external access

Do you want the Jellyfin server to be accessible from only within your tailnet, or anywhere from the internet?

If you have IPv4 addresses, I guarantee you’re behind at least one NAT gateway. What you need is a Tailscale subnet router, or something equivalent from another service.

In the most basic configuration, the Tailscale client facilitates communication (by using some UDP black magic fuckery) between one host it is running on and another host it is running on that are both connected to the same tailnet (the virtual network between Tailscale hosts). For this purpose, it uses addresses from the 100.64.0.0/10 “shared address space” subnet. These addresses will only be reachable from within your tailnet.

If you want an entire subnet (e.g. your LAN) to be accessible within your tailnet, you need to set up a subnet router. This involves configuring the Tailscale client on a device within the target subnet to advertise routes (tailscale set --advertise-routes=192.168.1.0/24), allowing the host to advertise routes in the admin page (Machines -> … -> Edit routes), and configuring the Tailscale client on external hosts to accept advertised routes (tailscale set --accept-routes).

If you want your servers to be accessible from anywhere on the internet, you’ll need Tailscale Funnel. I don’t use it personally, but it seems to work. Make sure you understand the risks and challenges involved with exposing a service to the public if you want to choose this route.

Rolling release doesn’t mean that no testing is done. All updated packages are tested by maintainers before being released into the official repository. A rolling release simply means that there are no individually marked OS versions and you always get the latest packages.

In contrast, take Debian for example. It uses a point release system with major named versions (e.g. Debian 13 “Trixie”), minor point releases (e.g. 13.1), and security and bugfix patches between those. New feature updates are released only between point releases, and breaking changes are only introduced between major versions. This allows the maintainers to practice a greater amount of care in testing that the packages work well together, but also means that new features are always held back to some extent. This does not happen in a rolling release system. All upstream changes are pulled, tested, and released, regardless of whether a breaking change is introduced.

By its nature, a rolling release distribution will require a greater amount of maintenance. If a package update requires manual intervention, it will be published on archlinux.org. For as long as I’ve been a Linux user, I’ve only seen one package update that made systems temporarily unbootable, and I was saved from that by being a Manjaro user at the time.

But, to answer the question, I usually update my home and work PCs (both Arch) about once every week or two, or as required by a new software or important security update.

It’s less about the concept of a game-centric headset and more about the brands that sell themselves as “We Are Gamers” with angular shapes and RGB out the ass. Steelseries, Razer, Alienware, Aorus, ROG… I’ve had many bad experiences both personally and professionally. The only one I didn’t end up regretting was Logitech G. The G502 mouse is a beast.

I used to own a HyperX Cloud Flight. It’s the best wireless headset I’ve ever tried. It comes with a USB dongle, no Bluetooth. Worked out of the box on Arch. I bought mine before HP infested HyperX, but my sister uses a post-buyout one and she says it’s perfect.

Pros:

• Audio quality is great for fun (games and films), decent for music and critical listening. The frequency response has a common V shape, but the bass doesn’t blow out the top ends (eat a dick, Raycon).
• Eight-hour battery life, can be used while charge cable is connected.
• Aux input that bypasses the internal DAC.
• Signal can penetrate several solid brick walls.
• Comfortable even on my melon head.
• Mic is detachable. Quality is as good as an Aussie wanker can expect.

Cons:

• Micro-USB charger port.
• Volume control is a click wheel that sends volume up/down keystrokes to the PC. I had to remove it from mine because it wore out and would “bounce” and send several keystrokes every time I touched it.
• The earpads are covered in shitty leatherette that will fall off in a few months.

In general, avoid anything “Gamer”. You’re paying for the brand, not the quality. Even the cheapest “audiophile” headphones are better.

Wireless headsets will always be limited by their internal DAC. Another option is to get a decent wired headset and a dedicated wireless DAC. I currently use a modded Beyerdynamic DT770 and an AKG K-240, and if I need them to be wireless, I clip a Fiio BTR5 to the headstrap and connect it with a short cable.