liliumstar

Arch on desktop/laptop because I'm very comfortable with it, and I can set it up the way I like.

Debian on servers because it's stable and nearly everything has a package available, or at least instructions for building.

Same as OP, but I'm not likely to change them out. I've tried a lot of distros over the years and this is what works best for me.

Someone send this to Stallman, so he can later download, print and view it at his pleasure.

I run such games on Linux now, mostly with wine/proton. There is some risk, sure, but I'd largely say that system is still secure. If something comes by and wipes out the system, I have snapshots of anything important, including root and home. If those are gone, I have versioned backups offsite and maybe offline. I don't expect to receive any malware targeting my somewhat esoteric software choices from windows games, so I feel okay logging into a secure sevice, for example, but I may have to adjust this in the future.

With regards to smartphones, I think there are so many holes that it's not much more secure, if any, than a paranoid desktop setup. From time to time I have installed random APKs and had extreme anxiety each time. I am massively more paranoid about my phone as I don't have real control over what's running on it. Hoping for more competitive open source solutions in the future.

Generally speaking, opening non-executable files is fine. There are and have been specific exploits which allow arbitrary code execution, but it's dependent on the application/library loading them. The bigger danger is files disguised as other things. This is especially bad on Windows as it likes to hide that information from users, or just execute random embedded vbscripts, or whatever. Also see the recent whatsapp mimetype bug/exploit. Certain things pose more of a risk than others. PDFs (thanks adobe) can embed arbitrary javascript which is meant to be executed. Same as web pages, of course, but browsers have a lot more attention to sandboxing.

Edit: I don't really run cracked software anymore, but I have VMs ready to go if need be. Would recommend others do the same.

Air is actually good, but they don't have a lot of fast servers. You are naturally limited by the server you choose and peering.

MakeMKV is non-free proprietary software. It just happens to be free while in beta, which it has been forever. There's not a lot of great free software solutions that do the same thing, in fact it's the main (or only) way people extract 4k BDs with the FEL intact.

There is not, but I will add one.

You could get started with Qt, specifically the legacy widgets. There are bindings for Python available (pyside or pyqt) if you don't want to learn C++ or another language right away. You can also port your GUI definitions to other languages at a later date.

I know you said consumer GPU, but I run a used Tesla P40. It has 24 GB of vram. The price has gone up since I got it a couple years ago, there might be better options in the same price category. Still, it's going to be cheaper than a modern full fat consumer gpu, with a reasonable performance hit.

My use case is text generation, chat kind of things. In most cases, the inference is more than fast enough, but it can get slow when swapping out large context lengths.

Mostly I run quantized 8-20B models with the sweet spot being around 12. For specialized use cases outside of general language, you can run more compact models. The general output is quite good, and I would have never had thought it was possible 10 years ago.

ETA: I paid about $200 USD for the P40 a couple years ago, plus the price for a fan and 3d printed shroud.

I would do FDE yeah. My current laptop setup is with systemd-boot and a special initramfs that allows me to unlock it with a yubikey, with fallback to password. Fair warning, this exact configuration is not particularly easy to setup.

There are also modules which enable early network connectivity along with a SSH server, meaning you login and unlock it remotely. I have not tried this.

Debian does not frequently require rebooting under normal circumstances. Kernel updates are not that frequent, and you can usually put it off for a bit if you don't want to deal with it.

I tried to replicate this in KDE (wayland).

pynput has no effect on wayland, which I figured. I then enabled ibus wayland to type unicode points with ctrl+shift+u, but everything came out as expected. So I think it is related to the xorg backend of pynput.

Yup, I think it'd work fine, especially if you want the ability to easily inspect individual items.

Any of the popular python yaml libraries will be more than sufficient. With a bit of work, you can marshal the input (when reading files back) into python (data)classes, making it easy to work with.