Probably because they pack a ton of files into a handful of compressed archives, which means the full archive needs to redownload when a single file is changed. Does Steam not have a delta patching system to handle this? They already compress downloads so it’s not like a delta patch framework would cost extra CPU in comparison, and the bandwidth savings would be immense. Seems like low hanging fruit to me?
A couple nits to pick: BTRFS doesn’t use/need journaling because of its CoW nature - data on the disk is always correct because it doesn’t write data back over the same block it came from. Only once data is written successfully will the pointer be moved to the newly-written block. Also, instantaneous copies from BTRFS are actually due to reflinking instead of CoW (XFS can also do reflinking despite not being CoW, and ZFS didn’t have this feature until OpenZFS 2.2 which just released).
I agree with the ZFS bit and I’m firmly in the BTRFS/ZFS > Ext4/XFS/etc camp unless you have a specific performance usecase. The ability to scrub checksums of data is so invaluable in my opinion, not to mention all the other killer features. People have been running Ext4 systems for decades pretending that if Ext4 does not see the bitrot, the bitrot does not exist. (then BTRFS picks up a bad checksum and people scold it for being a bad filesystem)
You should submit some issues for those sites with these steps - maybe they’ll add them to the list. The addon supports 453 sites at the moment by my count, so I’m sure they’d love for you to tell them about more sites that haven’t been bypassed yet.
Do you have any examples? I have never seen a paywall while using this. They have a list of supported sites, though I’m not sure if all of them are guaranteed to work 24/7 or if they need frequent updates.
The link I posted is for Firefox. The Chrome version is here, and it looks like it should continue working with MV3. (Obviously, the better solution is to stop using Chrom*. Mozilla is modifying Manifest V3 so adblockers/etc will continue to work in a post-MV3 world).
Note that in this benchmark, bcachefs had a debug variable turned on that allegedly severely hampered performance. Bcachefs has released an update to disable this variable but Phoronix hasn’t redone benchmarks yet. I wouldn’t put much value into any bcachefs-related comparisons from this current benchmark.
Arch is bleeding edge and frequently has minor bugs as a result. This is probably fine for power users and people who want to learn Linux but I wouldn’t give an Arch distro to someone who isn’t techy. They also likely won’t appreciate the frequent updates to applications that they depend on to actually do work.
(I used Arch for almost five years and think it’s one of the best distros)
It’s simple and solid enough to give to people who don’t know what they’re doing, and its Debian/Ubuntu base makes it flexible enough to not slow down power users who want to start modifying it. Other distros that might fit this bill keep shooting themselves in the foot and going off in weird directions, while Linux Mint has been a reputable no-BS distro for a very long time. It’s a workhorse distro without any gimmicks and that’s the point.
I’ll add that if you want to archive games forever, storing repacks is a good idea because of their extreme compression. From what I’ve observed, Fitgirl trends towards heavier compression while DODI trends towards faster install times.
KaOsKrew is another respected repacking group that you can trust.
Yeah. What repackers do is they source the game, source all the updates, source the DLC, and source the cracks, then put it all together, make sure it works, compress it into an installer, and distribute it. As an end-user you run the installer to decompress the game and then click play. Repackers don’t actually do any of the cracking themselves, they just put it all in one package and make it easy. The installer will run CPU-heavy while it decompresses their heavy compression so don’t be alarmed by that.
Aside from philosophical issues my experience with Flatpak has been excellent. There’s some theming steps you need to do to make them feel like regular apps, which I feel is clunky design. No Flatpak-induced instability from what I can tell. Setting up directory permissions is sometimes slightly annoying but Flatseal makes it trivial, and most Flatpak permissions are set up properly out of the box these days.
I haven’t noticed any start-time delays when launching Flatpaks as opposed to regular apps - I don’t know if they’ve fixed that or if my system is just too powerful. The only app that I’ve personally noticed is weird is VSCodium, which has trouble escalating to admin permissions when you’re trying to edit privileged files. I still use the regular version for that reason.
That gets my normal GTK theme properly. I found a little more discussion on this here. Nothing very actionable but I did also confirm that my xdg-desktop-portal-gtk is running. It seems like this is supposed to be working, but I have a mostly stock Debian 12.1 KDE install and something seems to be wrong somewhere in the chain. I’ve also tried multiple GTK Flatpaks with the same results.
Edit: Also, I have both my themes folder exposed and the theme installed as a Flatpak via the linked script.
I do have xdg-desktop-portal-gtk on Debian Stable, which is currently at 1.14.1-1. I’ll look around to see if there’s more documentation on this method, because I would prefer to not use the debug variables if possible.
Edit: I launched with GTK_DEBUG=interactive and I can see the theme inside the Flatpak gets set to Adwaita-empty instead of my actual theme, which does get properly returned via gsettings get org.gnome.desktop.interface gtk-theme
Right, I understand it’s not supposed to be used in “proper” usage, but it does work for all my GTK apps and the gsettings method does not work for me. Unless I’m supposed to store it somewhere else because I’m on KDE.
I wasn’t able to get the gsettings method to work (I’m on Wayland KDE), and that article doesn’t say anything about theming QT Flatpaks. Also, after “installing” my GTK theme as a flatpak via the method described, it still wasn’t available to my GTK Flatpaks via the GTK_THEME method. The steps in the itsfoss.com article do work, though there’s been a lot of squabbles about the “proper” way to expose themes to Flatpaks. Regardless, this all goes back to my point that theming Flatpak is clunky and should be much smoother.