keeperofdakeys

I'd say the biggest difference is Plex had years to get polish and mature. (After you turn off all the annoying features ...). So Jellyfin is missing little things, or has apparent bugs (especially on android tv). For example no way to remove a series from Continue Watching, or quickly reload metadata for one series.

Nearly all ISPs these days are deploying IPv6 for their mobile networks and core service networks, especially in less developed markets^1. The reason is simple, a cost justification. What doesn't exist is a cost justification for Enterprises to deploy IPv6, and for ISPs to deploy Residential / Corporate Internet IPv6.

IMO with the right market conditions, IPv6 could spread really fast within 6-24 months. For example, most cloud providers are now charging for IPv4 addresses when IPv6 is free. Small changes like that push in the right direction.

^1 https://www.theregister.com/2025/08/04/asia_in_brief/

> I've been using Duplicati to sync a lot of data to S3's cheapest tape-based long term storage tier.

There are actually a lot of cheaper S3-compatible services out there, (like Backblaze B2, or Cloudflare R2). They pricing may work out to just backup to these directly. Certainly gives you far more control than Backblaze Backup.

Reminds me of the story of Polywater. https://en.wikipedia.org/wiki/Polywater

Stripe do this in a cool way. Their REST API is version based on date, and each time they change it they add a stackable compatibility layer. So your decade old code will still work.

https://stripe.com/blog/api-versioning

Ceph overheads aren't that large for a small cluster, but they grow as you add more hosts, drives, and more storage. Probably the main gotcha is that you're (ideally) writing your data three times on different machines, which is going to lead to a large overhead compared with local storage.

Most resource requirements for Ceph assume you're going for a decently sized cluster, not something homelab sized.

Arguably, "comma as a separator" is close enough to comma's usage in (many) written languages that it makes it easier for less technical users to interact with CSV.

A bit out of context, but it reminded me of this funny moment. The only winning move is not to play.

https://www.youtube.com/watch?app=desktop&t=10&v=xOCurBYI_gY

(Background: Someone training an algorithm to win NES games based on memory state)

https://www.openssh.com/legacy.html - Legacy algorithms in OpenSSH, which explains a little what they do. Then there is also your Identity key that you authenticate yourself with, which is placed in the servers authorized_keys.

Usually smooth. But if you're running a production workload definitely do your prep work. Working and tested backups, upgrade one node at a time and test, read release notes, wait for a week after major releases, etc. If you don't have a second node I highly recommend it, Proxmox can do ZFS replication for fast live migrations without shared storage.

Unfortunately clustered storage is just a hard problem, and there is a lack of good implementations. OCFS2 and GFS2 exist, but IIRC there are challenges for using them for VM storage, especially for snapshots. Proxmox 9 added a new feature to use multiple QCOW2 files as a volume chain, which may improve this, but for now that's only used for LVM. (Making Proxmox 9 much more viable on a shared iSCSI/FC LUN).

If your requirements are flexible Proxmox does have one nice alternative though - local ZFS + scheduled replication. This feature performs ZFS snapshots + ZFS send every few minutes, giving you snapshots on your other nodes. This snapshot can be used for manual HA, auto HA, and even for fast live migration. Not great for databases, but a decent alternative for homelab and small business.

> IP does indeed have broadcast/multicast capabilities that cause the sender's egress traffic to remain independent of the number of recipients rather than being equal to the sum of recipients' ingress traffic, right?

Yes multicast, however you can't do multicast over the internet. In practise the technology is mainly used in production and enterprise scenarios (broadcast, signage, hotels, stadiums, etc).

Instead big streaming platforms like netflix or twich use CDN boxes installed locally at major ISPs. Also with so much hardware acceleration on modern NICs these days, it's surprisingly easy to handle Gbits of throughput for audio/video streaming.

> Podman has a daemon mode ...

Can you provide any documentation about that?

You can mitigate this by including PCRs that sign the kernel and initrd, however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros.

Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.

> There has to be a better way.

Probably Clevis and Tang, network disk decryption that can only decrypt if most of your servers are online. https://github.com/latchset/clevis https://github.com/latchset/tang

Or network decryption (SSH into initrd). https://github.com/gsauthof/dracut-sshd

Depending on what's in the rocket, just leaving it to decay in the environment would likely lead to contamination. Especially if you have any Hypergolic fuels lying around (explode on contact, and extremely harmful to humans / the environment). So you either pay to scrap it, or pay to clean up the site in X years.

Because ZFS has one of the most robust RAID systems in an opensource filesystem, and is incredibly mature.

And to be fair, almost every file system will have degraded performance and increased fragmentation above 80/90% full, so this should be considered universal advice.

There is also a legitimate question of how wide spread the issues are with the ZFS encryption feature. The fact this hasn't picked up much steam implies its not a common issue.

What would a NACK add? TCP can already send an ACK for the last successful sequence number, telling the sender to retransmit packets after that sequence number. Due to latency and large window sizes, it's far more efficient to just resend all the data than NACK individual packets.

Any linux process can run with elevated privileges (ie: as root) by setting a specific permission bit - https://en.wikipedia.org/wiki/Setuid. This is used for many things like ping and sudo.

Instead Run0 is using systemd to elevate privileges.

There is a lot that could be said, but suffice to say you can have both sudo and Run0 installed. So even if a Distro ships Run0 by default, you can always manually install sudo.

Either put machinery in your schema migration tool to create indexes as a separate step, so they are easy to re-apply. This makes keeping indexes in sync between production and staging a lot easier. Or you can use "CREATE TABLE_B (LIKE TABLE_A WITH INDEXES);".

And maybe it wasn't removed by their choice. Below is a video of someone who had all their Spotify music removed with no recourse, due to a claim the were buying streams. No recourse.

https://www.youtube.com/watch?v=kVY7-Ti77UQ

> The painful clunkiness of self-checkout was gone.

It could be worse. Imagine a smart gate that refuses to open for wheelchair users, or claims the child in your arms is an unpaid item - something that is getting rolled out in many Australian supermarkets.

The funny thing is that rust used to have things like garbage collection. For the kind of language Rust wanted to be, removing them was a good change. But there could always be a world where it kept them.

https://pcwalton.github.io/_posts/2013-06-02-removing-garbag...

I'd recommend learning how to instrument and measure the performance of your code. I find most performance issues are (mostly) situations you didn't and couldn't anticipate. So instead of preventing them, learning to investigate and fix them is key. (Shout out to Brendan and his Linux Performance page https://www.brendangregg.com/linuxperf.html).

Second there is an important engineering lesson to learn. Often there are many performance issues, with only a few acting as serious bottlenecks. Additionally sometimes the solutions to performance issues add complexity, but as an engineer you want to avoid complexity. Engineering effort is usually limited, so there is always a question of whether a performance issue needs to be fixed now or left till later.

Here is a quick example to illustrate my point. pgAdmin is a webui program to interact with PostgreSQL databases, allowing you to remotely run queries. Part of its operations fetches information about columns in a result set, in one version this code ran one query per column sequentially. So c columns, each a synchronous query to the server - almost instant on a local database with a small number of columns. However with 400 columns, and a 40ms internet link, it ended up taking at least 400*40=16 seconds to complete. In 99% of cases this code works just fine, but in a few less obvious scenarios its runtime balloons.

Another example; what happens if all the daily scheduled jobs run at the same time? https://github.com/go-acme/lego/issues/1656

The ".local" domain specifically is a bad choice as many platforms use MDNS instead of DNS for looking up those names. Leading to issues resolving names on some client devices. It's also very common due to Microsoft suggesting it as best practise in the early days of AD.

RAID1 is about mirroring disks, BTRFS RAID1 mirrors block groups. Plus traditionally a RAID1 of 3 disks will mirror the same data on all disks, which is different to how the RAID1 mode on BTRFS acts. So the name leads to misunderstandings since it doesn't act like RAID1 at all.

It'd be way easier to talk about if it had a unique name, and you could say "It's like RAID1".

Despite all that I do like the mode, and use it in a few places.

The BTRFS raid1 feature is very badly named, its best called two-copy. Skipping some details, two copies of data are written to the two drives with the most free space. So you can have multiple mismatched drives.

However you get no striping, and data is only read from one drive, so performance is limited to that of one drive for reads and writes. Plus with mismatched drives, smaller drives go unused unless you write enough data.

A mirror resilver is a relatively linear and sequential rewrite, so its very fast. Raidz resilvers require lots of random reads and writes across all the drives, and requires waiting for all drives to read data before it can be written to the replaced drive - "herding cats" sounds appropriate here.

The easiest approach is to make a new subvolume, and move one file at a time. (Normal mv is copy + remove which doesn't quite work here, so you'd probably want something using find -type f and xargs with mv).

- Provide a maintenance period beyond what CentOS Stream provides.

- Potentially hold back CentOS Stream updates to stay more in sync with RHEL. If RHEL is on X.Y, CentOS Stream is technically on X.(Y+1) - Alma wants to be X.Y compatible.

- Provide ABI compatibility with RHEL which CentOS Stream may not provide.