Four days ago, I woke up, as I usually expect to after going to sleep and I turned on my really fucking awesome Archlinux gaming rig, hit the desktop and decide, hmmmm… I haven’t updated in a while(a week), let’s pacman -Syyuu and get up to speed. Well, I got up to speed and my favorite game, the best game of all time, Team Fortress 2
##FAILED TO LOAD! 🚒 🔥
In the imminent crisis-state that I had found myself in, I did what any filthy scout-main Archlinux user would do, I googled the problem and put the word arch in quotation marks.
The first five results yielded ancient bullshit useful to someone five years ago, probably. The next ten, redditors complaining about old tat. Then I did what any old wine veteran would do. I shut steam down and started it in the terminal so I could monitor its raging bitch-fit in real time.
Team Fortress 2 failed to load because of lib32-libtcmalloc.so. Arch had updated it to a future version not yet even coded, and steam wasn’t having it. The answer was on protondb all along! So, some fella says
The native version of tcmalloc introduced a bug on TF2 that it randomly crashes the game. You need to install lib32-gperftools (name of the Arch AUR package, other distros should have similar names) and add LD_PRELOAD=/usr/lib32/libtcmalloc.so %command% to your launch options to override the library.
et voila, I’m torturing 25/7 2fort.
Now, I know what you’re thinking, who in their right mind would suggest Archlinux for a beginner? See, that’s where I already caught you because this bug trickles all the way down to Garuda and Manjaro users too since they have the same libraries (and that fancy SteamOS that’s floating around).
So while I love Linux and software freedom, I find suffering Linux on someone might be more suited to a person that actually wants it, and not to work through it to get to what they actually wanted to do.
I wanted to play Team Fortress 2, and I was rather irate about the last thing on my steam account that shouldn’t work, not working all over me. This system has been a saint for six months, but when it’s a devil, boy, is it.
Anyway, KDE is better than gnome! Thanks for reading!
@BlinkerFluid My Arch automatically makes a btrfs snapshot before and after every time pacman is used, and creates a separate GRUB entry for them… so I update and install stuff fearlessly, knowing that if something breaks, at worst I will just have to reboot to go back to a working system. With snapper-gui I can delete old snapshots easily.
I think there should be an Arch distro that comes preconfigured with this.
Tell me of this dark magic, wizard.
Snapper. On it.
That’s one thing I loved about switching to OpenSUSE from Arch. I used ext4 on Arch, and was considering reinstalling to get BTRFS set up, but OpenSUSE Tumbleweed supports it in the installer so I tried it out, and the rest is history.
I’ve been on Tumbleweed for a few years now and haven’t looked back. Arch is great though, and if I ever find a reason to leave OpenSUSE, I’ll probably go back to Arch.
@sugar_in_your_tea @BlinkerFluid I love btrfs for the system partition but I’m a bit afraid of using it for my data, I use zfs for that instead. In both cases I use zstd compression and it works like a charm.
Ext4 doesn’t support snapshots, however snapper supported it for a while with a kernel patch. There’s also timeshift which uses hard links and rsync in ext4 to provide a similar functionality, with no special kernel support. It also can use btrfs but I prefer snapper for that because of snap-pac and snap-pac-grub.
I also ran out of system storage so I added another device to the same btrfs and it works like a charm.
I would use zfs but I don’t believe there’s much benefit over btrfs for a single drive. If there is, lemme know.
Also, ram requirements, only reason it’s not in use on my nas. More ram for activities. I backup with rsync.
@BlinkerFluid The benefit is peace of mind because I lost data with btrfs more than once (one with power loss, one with accidentally disconnected media while writing). Although recently I had another mishap that made me realize that maybe the log has to be cleared before I try any other recovery method. I got the partition back just by clearing the log. Btrfs refuses to mount with a corrupted log. Theoretically it doesn’t need journaling because all operations are atomic, so I don’t really know what the log is for.
You can also just use pre/post transaction hooks.
@BlinkerFluid snapper, snap-pac and snap-pac-grub
I just make normal backups before I update
Personally I think Timeshift is better. (and switching from Snapper to Timeshift is not that trivial)