> Interesting post. They do get a lot of things right, but I tend to prefer a full OSS stack, so jellyfin instead of plex, and btrfs instead of ZFS. Liking the

> Interesting post. They do get a lot of things right, but I tend to prefer a full OSS stack, so jellyfin instead of plex, and btrfs instead of ZFS. Liking the view on Jellyfin over Plex. I'm a relatively long time Plex user (switched over from XBMC (now Kodi) to Plex in ~2011), but also immensely dissatisfied with the direction they've taken, focusing on growth to satisfy PE backers over the needs of the user base that enabled them to even qualify for any PE money. It looks to me that their focus is increasingly on "collecting analytics" on their users behaviours (logging everything they watch) and providing ad-supported streaming services, instead of trying to provide the best self hosted media streaming service (as it was when I started using Plex). > One data point about btrfs, FWIW: I've been using it since 2016, the only "issue" I had is that it forced a failing drive into read-only, while other filesystems didn't detect the upcoming failure, thank checksuming for this. One more data point about BTRFS, is that it doesn't support parity-stripe based redundancy models (raid5/6, raidz{1..n}, etc), which makes it less interesting for a lot of people. Another note about ZFS is that it doesn't allow for growing of parity-stripe based volumes (although there's a tweet referenced in TFA that notes there should be a pull request with that feature expected soon). This can make it very expensive for people who don't have the funds to buy disks in groups of 6 at a time (my personal preference for a raidz2 zpool)