I play over SSH (via a modified version of PuTTY) and I have a custom script and executable that locks the DF account to the game using Screen. That way I can always resume the game, wherever I am, as long as I have Internet access.
Personally, I want to do this to my own console once I get it up and running, but still limit its access to the internet. Just so I can play anywhere in the house. I love novel things like being able to do that.
But why disable access
to the internet? Shouldn't it be enough to block access
from the internet? As long as you don't install any services, nothing will be listening for incoming connections. Even if you set up an SSH server (which I'd offer as an optional feature to users) it can be configured in such a way that it only accepts connections from certain IP-addresses (I know that this isn't secure - but in addition one has to have login credentials - what in the case of your project probably means private-/public key authentication). If that's not enough, you can still set up a software firewall using nftables (or iptables if you prefer), the package filtering function of the Linux kernel. The reason I'd suggest to stay connected to the internet is the possibility to access the Wiki. There are several text based browsers, and it might not be the worst idea to have one of them running on another terminal.
What linux distro will this be based on? (and all other highly techy questions)
I will need to get back in touch with Urist McProgrammer on his progress. We've mostly been discussing the features needed, and his status on implementing them. We are close to the prototype stage 1 (hardware only), and oddly, I haven't asked him about which distro he is using yet, lol.
If I may suggest: Use something minimalistic. Although I've never user used it, Arch would come to my mind. It's rolling release, so no reason to bother with distribution lifetime. Also, it uses systemd. Many might see this as a downside, and it might indeed be from a technical standpoint, but from a user's standpoint it's extremely convenient, as managing services (as in: making the system boot into dwarf fortress and shut down when dwarf fortress exits) has never been easier - except maybe with the much less flexible BSD-style Init.
Linux is happy to boot off cheap USB drives, once it's booted you can run from ram
The original idea was to do exactly this. People would update their system by just updating their portable USB stick and everything would be easy. But that doesn't really feel much like a console
In reality, the reason we are not opting to do this is that hard drive access has a generally minimal impact on the gaming experience, and it is WAY cheaper to buy a decent little SSD than lots and lots of RAM for those big, long historically significant worlds.
Don't forget that dwarf fortress is just 32bit. This means, that it'll anyhow be limited by the address range. On a 32bit Linux system, dwarf fortress won't get more than about 3 GB of RAM, while on a 64bit Linux system it should get just short of 4 GB maximum (
source). This means that you'll probably want a 64bit Linux kernel. This will waste some HDD space for the additional 32bit libraries required by dwarf fortress, and use a bit more RAM than a 32bit Linux system, but the additional 1 GB might make a difference on large worlds. A further consequence of this is, that you'll probably want to have 8 GB of RAM available, as dual channel mode is kind of a must for dwarf fortress, meaning you'll either want to mount 2x2GB, what will require swapping if df gets close to using all possible 4 GB of RAM (or without swap, it'll crash), or 2x4GB. While this means you'd have easily enough free RAM for a small ramdisk containing the root filesystem, I don't see much use for it in your particular case, as all storage access to the root filesystem will happen during boot (if the system is configured in that way at least), at which point a ramdisk would have to be loaded from permanent storage as well... One might argue that the ramdisk images are typically compressed and therefore might require less storage I/O, but compression is also available at the filesystem level, for instance with btrfs.
Long story short, I don't think a ramdisk is a good idea in that use case, even when using a slow storage medium.
Anyhow, I'd like to bring up something else: The KMS terminal. What is the reason you don't want to use PRINT_MODE:TEXT?
And, semi-related: Why doesn't dwarf fortress allow to draw to the KMS terminal framebuffer? Other SDL based applications (openttd, dosbox, ur-quan masters,...) can output graphics without an X11 server just fine.