• 0 Posts
  • 44 Comments
Joined 2 years ago
cake
Cake day: November 10th, 2023

help-circle




  • Your biggest issue is going to be dealing with multiple partitions, unless you can find another boot disk, because your disk is pretty full. I would strongly recommend getting a second disk, unless you are willing to delete a lot of (presumably) game executables.

    It is also a good idea to have a relatively smaller Linux partition, and point your Steam library and other documents to a separate data partition. My 1TB nvme has 150MB EFI FAT32 partition, a 100GB ext4 root partition (Linux is installed here), and the remaining ~900GB as my ext4 data partition. This way, if you choose to install a different Linux, or blow away your root partition, you can relink your Steam/Music/Video Libraries and local AI models, and get up and running again very quickly.

    Outside of the disk, my top recommendation is to archive your active steam games, so you can restore them into Linux without fully re-downloading later. Additionally, unless your games are in Steam Cloud, you will also have a bit of a time restoring save files to the new OS, as the file paths will be different than you are used to on Windows.

    My second recommendation is to ensure secure boot is disabled in your BIOS; there are currently known issues with driver signing with the NVIDIA driver.

    Finally, assuming you’re on a Ubuntu-based distro like Mint, ensure you install Steam from the .deb or apt package, not the flatpak. On Mint, “Install Steam” is available right in the start menu.










  • For encryption, the client and server need to share their private keys.

    This is incorrect, for asymmetric (public-private) encryption. You never, ever share the private key, hence the name.

    The private key is only used on your system for local decryption (someone sent a message encrypted with your public key) or for digital signature (you sign a document with your private key, which can be validated by anyone with your public key).

    For the server, they are signing their handshake request with a certificate issued by a known certificate authority (aka, CA, a trusted third party). This prevents a man-in-the-middle attack, as long as you trust the CA.

    The current gap is in inconsistent implementation of Organization Validation/Extended Validation (OV/EV), where an issuer will first validate that domains are legitimate for a registered business. This is to help prevent phishing domains, who will be operating with TLS, but on a near-name match domain (www.app1e.com or www.apple.zip instead of www.apple.com). Even this isn’t perfect, as business names are typically only unique within the country/province/state that issues the business license, or needed to be enforced by trademark, so at the end of the day, you still need to put some trust in the CA.