all 5 comments

sorted by: hot top controversial new old
[–] 13 points 15 hours ago (3 children)

I'd love a Steam client that didn't tie up more RAM than most of the games I play

  • source
  • hideshow 3 child comments
  • [–] 9 points 15 hours ago* (2 children)

    Yeah, I wonder if there's a way to disable the steam web browser to save RAM

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 15 hours ago

    Is there anything without a container? It tanks on SLSA and violates iso27002.

  • source
  • 18 comments in c/pcgaming@lemmy.ca view that post
    [–] 42 points 1 day ago (14 children)
  • [–] 8 points 1 day ago (6 children)

    Weird. I tried like 10 different locations, even heavily authoritarian ones, and couldn't replicate this. If you don't mind disclosing, what country are you accessing the site from?

  • source
  • parent
  • hideshow 6 child comments
  • [–] 12 points 1 day ago (5 children)
  • [–] 35 points 1 day ago (4 children)
  • [–] 11 points 10 hours ago (1 child)

    This is bigger than it sounds for distros. The 32-bit Steam client was the main reason a lot of distros kept full 32-bit library support around. Ubuntu tried to drop i386 back in 2019 and walked it back largely because of Steam.

    Older 32-bit games will still need those libraries, so multilib isn't going away tomorrow, but at least the client itself stops being the reason. And running it inside the runtime container should mean fewer "works on Arch, broken on Fedora" kinds of issues.

  • source
  • hideshow 1 child comment
  • It really is! I think last year Fedora proposed dropping 32-bit and things almost got heated between them and Bazzite because of Steam still needed it. I forget why the Flatpak version of Steam didn't suite their needs, but I remember they had very good reasons why it wouldn't be an option to switch to.

    I think with the option of running Steam on top/within of the new runtime would mean that they could drop multilib since the runtime can now provide it for the Steam Client (but dont quote me on that, the discussion i read is a little hazy).

    Im really excited for the runtime change too, as a NixOS user, theres a bunch of weird issues that pop up due to the PATH thats a pain and time consuming to troubleshoot, rebuild, and test again. Everything is ironed out for normal stuff, but some of the things with 3rd party launchers or mods are messy.

  • source
  • parent
  • [–] 8 points 20 hours ago

    Please tell me this didn't break SteamVR again...

  • source
  • 11 comments in c/linux_gaming@lemmy.world view that post
    [–] 49 points 16 hours ago (1 child)
  • [–] 22 points 17 hours ago (1 child)
  • [–] 5 points 12 hours ago (1 child)

    I've been running it as a Flatpak, I wonder if this changes anything.

  • source
  • hideshow 1 child comment
  • [–] 1 point 9 hours ago (4 children)

    Anyone know if this removes the need for the Bubblewrap container on NixOS? That causes issues with asynchronous reprojection in Steam VR meaning you have to circumvent it with a different runtime (not ideal for if they ever let me order my Steam Frame)

  • source
  • hideshow 4 child comments
  • [–] 1 point 8 hours ago (3 children)

    I don't remember having to do that on my "Steam Machine" which is a desktop running NixOS. This is most of my "VR" module:

        environment.systemPackages = with pkgs; [
          iw
        ];
    
        nixpkgs.config.allow32Bit = true;
    
        # Steam Frame dongle requires a region be set to work
        boot.extraModprobeConfig = ''
          options cfg80211 ieee80211_regdom=ES
        '';
    
        # SteamVR requires CAP_SYS_NICE, this patch allows it to have it
        # WARNING: This allows any application to create high priority contexts
        boot.kernelPatches = [
          {
            name = "amdgpu-ignore-ctx-privileges";
            patch = pkgs.fetchpatch {
              name = "cap_sys_nice_begone.patch";
              url = "https://github.com/Frogging-Family/community-patches/raw/master/linux61-tkg/cap_sys_nice_begone.mypatch";
              hash = "sha256-Y3a0+x2xvHsfLax/uwycdJf3xLxvVfkfDVqjkxNaYEo=";
            };
          }
        ];
    
        # SteamVR environment variables
        environment.sessionVariables = {
          # Force XCB platform for SteamVR under Wayland (prevents Qt Wayland issues)
          QT_QPA_PLATFORM = "xcb";
        };
    

    It's been working with my Frame perfectly.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 8 hours ago (2 children)

    Ah, you're using the kernel patch, I've been a bit worried about that due to the security risks. It would be nice to be able to use it without it. Currently I'm using WiVRn (which uses the Monado runtime, fully FOSS which is nice) with a net-blocked Quest 2. I'm still on the waitlist for the Frame so I'll be lucky if I get one by 2030 anyway :(

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 8 hours ago (1 child)

    But does the capsysnice thing has to do with it being 32 bits? I thought it was an independent issue.

    Also, good luck with the wait-list, hopefully you'll get your email soon.

  • source
  • parent
  • hideshow 1 child comment