The author is pretty active on Mastodon. I've been meaning to play their game for a while.

I strongly recommend that users set up separate partitions for home and root.

This is a very good idea (and my personal practice). It allows you to replace the OS without touching your personal files. Only reason I didn't suggest it is it looked like available space was already very limited.

but I think btrfs does everything and is easier to set up for a new user?

It is certainly possible to use Btrfs subvolumes instead of a separate partition, but many Linux distro GUI installers do not have robust support for this and will prevent you from using the same partition for different mountpoints (they typically don't understand or provide a way to set the btrfs-specific subvol= mount option). On a manual distribution like Arch or Gentoo this isn't a problem at all, but I've had to get creative when using GUI installers for Debian and Solus. Fedora's GUI installer "supports" it, but last time I did it, it triggered another bug in the process later on based on a similar assumption.

It is easy enough to do post-install (turning /home into a subvolume and adding it to fstab), but you will still have a hard time later on replacing only the OS, which is the main point of setting things up like this.

Windows is basically incapable of mounting any UNIX filesystem, so I can't see that ever happening.

Yes, but if the NFTS was mounted by Linux when it hibernated, suddenly this becomes a possibility.

I think exFAT would be a step down from NTFS. NTFS is a journaling filesystem which makes it a lot more robust against data corruption than exFAT. It also has a number of more advanced features (for a 30 year old filesystem) like symlinks, transparent compression, and sparse files. NTFS is also less prone to fragmentation than the FAT family of filesystems. On the other hand, exFAT doesn't eliminate any of the potential compatibility problems (like the potential to create a file named "C:"). The only thing exFAT has going for it is that Microsoft has actually published a specification for it, but in practice NTFS has been reverse-engineered enough to have multiple reliable third-party implementations.

If you need Windows and Linux to access the same filesystem, NTFS is the least bad option (the best option is probably setting up a NAS for this amount of data). Another option is to install third-party ext2/3/4 or btrfs drivers on Windows, but last time I looked into this, they weren't very robust.

https://git-send-email.io/

I haven't checked recently, but VLC was stuck on an old version of ffmpeg for a long time.

If you're dual-booting, there are some potential problems. The biggest danger comes from hibernation. Hibernating one OS and then booting the other OS and modifying the files (even incidentally just by mounting the filesystem), and then loading the hibernated OS will cause very bad things to happen. To the best of my knowledge, the Linux NTFS drivers refuses to operate on a filesystem which appears to be hibernated, but I do not know if the inverse is true.

Without knowing the exact text of the warning you're getting, I'm assuming it is a "this is not officially supported, don't blame us and don't send us bug reports" sort of deal. From what I gather, the most likely cause of problems is the potential for creating files with illegal names on the NTFS filesystem (filenames containing a ':' for instance). There is an unofficial guide on the Proton wiki about running Windows games in Proton which are stored on a shared NTFS partition which covers the relevant potential issues.

If the main risk is games not running correctly, I wouldn't lose any sleep.

This setup is not ideal, but neither is having 10TB of games turned into 20TB of games so you can duplicate them on separate filesystems. A compromise of some sort is required. In the longer run, I would aim to replace one of these NTFS filesystems with a Linux filesystem and install games there that you don't play on Windows any more.

NTFS drives aren't a good idea under Linux, but my 4 NTFS drives are this full.

NTFS works fine on Linux. You can't install Linux on an NTFS filesystem because NTFS doesn't support UNIX permissions, but you can mount these filesystems read-write to any arbitrary sub-directory and use them as you please.

The tricky thing is, if you have no more drives, you will need to shrink one of these NTFS filesystems to make room for a Linux-compatible filesystem (ext4, btrfs, xfs, etc) to actually install a Linux distro. Microsoft has a minimal amount of info here, but I don't have a Windows machine at my disposal to test this. Shrinking an NTFS partition should also be possible via gparted (which is available in LiveCD/LiveUSB form). Either way, it is a potentially dangerous operation. On a nearly-full filesystem it will be very slow, and if the power goes out or something in the middle of the process, .

I usually allocate 400GB for a Linux rootfs, but 200GB should be comfortable if you aren't installing a million packages.

Watch this space: https://itch.io/jam/queercomgames2026

The original Boom was (only ever) published for DOS. Active development ended in 1999. The thing which makes it notable is that it was the first 3rd-party source port to add new map design features (quite a number of them, too). You almost certainly don't want to use Boom today unless you are in a true retro-computing mood and are prepared to bust out DosBox or a PC emulator (the requirements are essentially identical to running the vanilla Doom binaries).

The good news is that Boom came out and stabilized so early that it effectively became a defacto standard. Many, many custom levels are developed with Boom-compatibility as a target (even today), and nearly all modern source ports support these maps (with the deliberate exception of Chocolate Doom).

There is also a lineage of ports which descend from Boom, like DSDA-Doom by way of PrBoom+, or even the official engine which ships with "Doom + Doom II." Even modern ports which can't trace their heritage back to Boom will typically include snippets of code from it for one reason or another.

I believe it is minor custodial things like adding a couple UI sprites and maybe updating copyright notices. Won't change gameplay at all, but it will be rejected by most servers in multiplayer ports due to the checksum mismatch.

Chocolate-doom for "pure" vanilla experience, including all limits and bugs (a bit rough, but a very well maintained port. Beautiful clean C codebase, especially compared to some other source ports, but even compared to the original id Software LinuxDoom source).

DSDA-Doom for true vanilla gameplay (as deemed by the speedrunning community) with lots of modern accoutrements. Broadest demo playback compatibility and mod support sans ZDoom (highly recommended, my first choice for anything).

UZDoom for mods which require it (there are many good ones, despite it playing a bit differently).