• 11 Posts
  • 827 Comments
Joined 3 years ago
cake
Cake day: July 7th, 2023

help-circle
  • What might simplify your thinking about this is called “Semantic Versioning”.

    You have a big codebase of all kinds of features, but at a certain time you want to release it to be able to differentiate between a point in time and release number so you can tell when a regression happens and address it.

    Proton is released by version to be able to see this exact thing. They keep all the old versions available for users because they know that not every single point release will work for all games, and there will be regressions.

    This allows users to be able to identify a stable working version of Proton for a specific game, and stick to it. If you try to upgrade for a newer release for some reason and find a problem, you can always go back to the previous working version and know for certain it will work without issues.

    For your specific scenario, just check ProtonDB for games and see if people have posted tweaks and config combos for a specific game. Great resource for this exact reason.



  • It starts with the hardware first. You started well with tuning your CPU/MEM frequency settings, but that matters less if you’re running giant PSUs (or redundant), more drives than you need, and a huge number of peripherals.

    Get a cheap outlet monitor to see what your power draw is and track it at the wall. I just got these cheap Emporia ones. I’m sure there’s more reputable ones out there.

    Don’t go crazy with your networking solution if you don’t need them. PoE switches draw tons of power even when idle, and a 24-port switch is a huge draw if you’re only using 3 of them.

    Consider getting a power efficient NAS box for backend storage, and low power Minipc for frontend serving instead of using a power hungry machine for all your network apps.

    You can dive deeper into any angle thing, but these are the basics.















  • They do no such thing.

    The first link explains the protocol.

    The second explains WHY one would refer to client and server with regards to Wireguard.

    My point ties both together to explain why people would use client and server with regards to the protocol itself, and a common configuration where this would be necessary for clarification. Ties both of them together, and makes my point from my original comment, which also refers to OP’s comment.

    I’m not digging you, just illustrating a correction so you’re not running around misinformed.

    It wasn’t clear where OP was trying to make a point, just that the same host would be running running Wireguard for some reason, which one would assume means virtualization of some sort, meaning the host machine is the primary hub/server.



  • Uhhhh…that is…not how you do that. Especially if you’re describing routing out from a container to an edge device and back into your host machine instead of using bridged network or another virtual router on the host.

    Like if you absolutely had to have a segmented network between hosts a la datacenter/cloud, you’d still create a virtual fabric or SDLAN/WAN to connect them, and that’s like going WAY out of your way.

    Wireguard for this purpose makes even less sense.