There are plenty of sites that use more than one parameters. It’s true that a lot of sites now use the history API instead of url parameters but you can still find plenty, and you have no garante about the parameters order. Any site with a search page that have a few options will probably use url parameters instead of the history API. It’s easier to parse and will end up being shorter most of the time.

Well for youtube it’s quite easy, there are only 4 useful parameters that I can think of, the video id v, the playlist id list and index if it’s a playlist and the time t if you’re sending a specific time in the video. Everything else can be removed. Here’s what uBlock Origin with the AdGuard URL Tracking filter list:

! Youtube
$removeparam=embeds_referring_euri,domain=youtubekids.com|youtube-nocookie.com|youtube.com
$removeparam=embeds_referring_origin,domain=youtubekids.com|youtube-nocookie.com|youtube.com
$removeparam=source_ve_path,domain=youtubekids.com|youtube-nocookie.com|youtube.com
||youtube.com^$removeparam=pp

There is no logic as to which parameters is useful and which is used for tracking. But there are databases.

Here is the one for the CleanURLs extension and here is the one for the AdGuard URL Tracking filter list (which I recommend everyone should enable in uBlock Origin).

It’s better to avoid re-encoding as it lose quality.

Isn’t immutability related to the root filesystem being read-only? I can write on my root filesystem, even if it’s mostly links to the store I can replace those links.

Yes, or use flakes which gives you a lockfile pinning everything. But this is related to reproducibility, not immutability.

I’ve had NixOS absolutely refuse to run some compiler toolchain I depended upon that should’ve been dead simple on other distros, I’m really hesitant to try anything that tries to be too different anymore.

Yes, some toolchain expect you to run pre-compiled dynamically linked binaries. These won’t work on NixOS, you need to either find a way to install the binary from nix and force the toolchain to use it or run patchelf on it somehow.

Well that was an approximation to keep it simple and disprove the given example. There are other directories in the root filesystem that are in the path by default, or used in some other critical way (like /etc). Even if they are links to directories in the nix store you can replace the link.

These seems to be related to flatpak, not immutability.

What things?

To be honest I don’t know these very well. I only use NixOS. My understanding is that in an immutable distribution the root filesystem is read-only. Granted in NixOS the nix store is immutable and most things in the root filesystem are just links to the nix store, but the root filesystem itself is not read-only.

I’m on NixOS right now and just dropped a Chewy in my /bin, only had to sudo touch /bin/chewy.

if it’s being read from, it can be written to.

Why would being able to read imply being able to write?

Having an extra step or two in the way doesn’t make it “extremely secure”.

Well it can greatly improve security by preventing a compromised app to achieve persistence.

The store is immutable but the system itself definitely isn’t.

I wouldn’t call NixOS immutable.

Fuzzy finding really shine for this use case, no need for a mouse.

You can destroy it all the same with cp or cat.

The quote is not about installing security patches but implementing them. Terrible paper.

I don’t think this is of interest, this is an article in a student journal, written by one person which seems to be a student too. The quote is weak and cherry-picked.

A quote from the same paper:

Security measures in Linux are slim to none as it is a free OS to download.

I don’t see what you can do at the protocol level to improve availability, you still need people storing the file and acting as peers. Some trackers try to improve that by incentivizing long term seeding.