I’m curious, how well has Musl been for software compatibility? How did you resolve any that came up?

Cloudflare is known for being unreliable with how and when it enforces the ToS (especially for paying customers!). Just because they haven’t cracked down on everyone doesn’t mean they won’t arbitrarily pick out your account from thousands of others just to slap a ban on. There’s inherent risk to it

Even just basic API versioning would be sufficient. .NET offers a bunch of ways to handle breaking changes in APIs

they also have good free tiers for hosting services i think? see them come up at a lot as an alternative to oracle for hosting small svcs

MergerFS and SnapRAID could be good for you. It’s not immediate parity like with ZFS RAID (You run a regular cronjob to calculate RAID parity) but it supports mismatched drive sizes, expansion of the pool at any time, and some other features that should be good for a media server where live parity isn’t critical.

Proxmox and TrueNAS are nice because they help manage ZFS and other remote management within a nice UI but really you can just use Debian with SSH and do the same stuff. DietPi has a few nice utilities on top of Debian (DDNS manager and CLI fstab utilities, for example)but not super necessary.

Personally I use TrueNAS but I also used DietPi/Debian for years and both have benefits and it really matters what your workflow is. OMV supports everything you want too (incouding SnapRAID) but takes extra setup which put me off.

Docker or LXC containers won’t hurt your performance btw. There’s supposedly some tiny overhead but both are designed to use the basic Linux system as much as possible: they’re way faster than on WSL. For hardware acceleration it’ll be deferred to the GPU for most things and there’s lots of documentation to set it up. The best thing about docker is that every application is kept separate to eachother - updates can be done incrementally and rollbacks are possible too!

My scepticism is that this should’ve been done within the coreutils project, or at least very closely affiliated. This isn’t an area of the linux technical stack that we should tolerate being made distro-specific, especially when the licensing is controlled by a single organisation that famously picks and chooses its interpretation of “FOSS” to suit its profit margins.

On a purely technical level, GNU coreutils should very seriously consider moving to rust if only to counter alternatives before it’s too late. While these utilities work well in C (and usually stay secure thanks to the Unix philosophy limiting the project scope), FOSS projects are continuing to struggle with finding new contributors as younger devs are more likely to use modern systems languages like Go and Rust. Not to mention that any project using Rust as a marketing tool will appeal to anyone rightfully concerned about hardening their system.

fedora has been this for myself. maybe tweaking every now and then to fix whatever edge cases I’ve run into but it’s the least painful distro I’ve used so far

My setup was about 500 USD if I had to guess:

Used i5 9500 (mainly for QSV but you can use any modern CPU as long as the iGPU is relatively recent)

32GB RAM (more RAM = more cache for file IO)

4TB HDD

256GB NVME boot drive (recycled from my steamdeck)

Node 804 case.

TrueNAS SCALE for the OS.

I’d recommend to get double or even triple the drives I did, maybe 3x 2TB or 3x 1TB depending on your budget. Only because that unlocks RaidZ1/RaidZ2 which can give you better RW speed and redundancy should anything go splat, and you can’t retroactively convert your drive into a Z1/Z2 pool without manually transferring the data later which might take a looooong time for you.

I dont think my route was the cheapest: IMO youd do better going AMD even despite the poorer support for HW transcode only because the motherboards are insanely expensive and hard to find, whereas that money couldve given me a better CPU and later you can add an intel iGPU if you’re really struggling.

Jellyfin supports HW transcoding on Rockchip too, but the issue with the Pi5 specifically is that it doesn’t have a hardware media decoder so it’s actually worse than the Pi4 if you can get HW transcoding running on it.

Appflowy is a self-hostable notion replacement that’s a bit more mature than this project atm. I hope this can spur some more development away from Notion though, I’m not a fan of the always-online element

Do they not provide an md5sum? I’ve never seen anyone check an app’s integrity issuing public keys

hmm that’s concerning. we really need a roku/chromecast equivalent that isnt some proprietary mess (home assistant is finally getting into those with voice assistant units)

Roku does it well enough. not perfectly but it’s still not as shit as my Google tv

Before now I was on the sunk cost fallacy of not wanting to teach my extended family how to use Jellyfin instead of plex but after this I’m already mid-way through setting up a Jellyfin docker container on my server and I only found out an hour ago

Old capabilities that don’t even work as well as free alternatives because AMD transcoding support has been “”“experimental”“” for years.

Fuck this. What the absolute fuck lmao they just decided to kneecap their entire business model.

I was even going to get a lifetime subscription later this year when they usually put the price down. Not anymore

Hector and others were really bad losses for the Rust kernel devs but Lina? That’s catastrophic. She was a figurehead in getting apple silicon working so well on Linux that even Linus moved his development machine to an M1 Macbook.

Linus has royally fucked it with how long he sat on the side of this. Im so sorry to Lina and others who have been burned by this community.

rocketchat seems decent

Short answer: Yep, cheat softwares regularly do this too, but it’s costly and prone to being immediately patched, and it’s potentially illegal.

Anticheat systems are designed around this since a cheat client would try to do exactly that. One way for example is for the anticheat to provide a cryptographic key to the game which it uses to prove to a multiplayer server that the anticheat is functioning and untampered with. Even if you bypass anticheat locally, you still have to prove that the game client is legitimate to the server. This does happen! But kernel anticheats are much harder to access and tamper with, and in our case of using WINE are unlikely to even work from the outset.

So okay, let’s hypothetically bypass anticheat locally. We modify the game to tell the server it’s legit, and it works! A few days later the game gets patched, and suddenly our bypass is defunct. For cheat sellers this part of the cost of business but for people just trying to game on Linux there’s little money in it, and if there is it won’t ever be spent on circumventing anticheat (which also falls under some legal grey areas if not outright illegal depending on your country).

Given enough time and resources we could probably find some novel way to crack anticheat on a game as such as it becomes playable on Linux. But it’s so much easier to use that effort somewhere else or just use a Windows VM that is guaranteed to work even if slightly slower.

WINE Is Not an Emulator (that’s what the acronym actually stands for).

At a program level, WINE creates a dummy Windows directory structure, slaps files where an exe expects them, and executes the program.

EXEs (well, all programs) will use system calls to request resources (ie. files, access to hardware like GPUs, data from other processes) which Windows maps to certain areas of memory and has its own protocols for how to handle requests. Linux has its own protocols and methods that are incompatible, hence why Windows and Linux apps can’t run natively together.

Then the magic happens: WINE maps these requests to Linux requests so that the running program is none the wiser. It asks for GPU resources like a Windows app would, then gets those resources back just like a Windows app would expect. There are thousands of edge cases, hundreds of system calls, and a bunch else that complicates things but that’s how WINE (and Proton) works.

The reason this fucks up Kernel-level anticheat is that it isn’t trying to communicate via these established channels. They usually operate with full resources outside of the jurisdiction of your OS, and scan your memory bit-by-bit rather than asking the OS politely via system calls for info on other processes.

With WINE, whilst a typical application will not notice the differences they’re designed to not throw a fit if your underlying OS is configured differently, a kernel anticheat will not even recognise the system as a valid OS even if it was able to run in the first place.

The solution here is systems like EasyAC that give up the benefits of being able to analyse processes at the kernel level in favour of portability. Another potential solution (though unlikely imo) is a cross-platform kernel anticheat protocol, that all major operating systems agree to implement, similar to how operating systems will implement the TCP/IP protocol to communicate across networks regardless of underlying OS.

Now the reason "WINE"s acronym is particularly important is that if it DID emulate windows, as in what most virtual machine providers do, then anticheat would be running in an environment mapped out like a real Windows install - because it is. This is how many Linux gamers prefer to run certain titles, and something that should always be functional. It is much more annoying to maintain, However - balance how much you really wanna play the latest COD with your willingness to debug GPU passthrough shit.