Conclusion below, but full read is highly recommended:

#The Frame

The Steam Frame is not for everyone; I’d argue VR isn’t generally. But despite taking far longer than it should have to materialize and costing more than I’d like, the Steam Frame is one of the most exciting pieces of hardware I’ve seen in the space in years, one that gave me that same feeling of optimism that the Index did so years ago. The Frame builds on the work done by its competitors in the years since the Index and solves so many friction points I’d had to actually engaging with VR as a medium at all. It is a device that is doing massive amounts of hard work to unify several different use cases into a single open platform, and, despite its individual parts being less novel, that unity is game changing. It is hardware whose importance may ultimately eclipse its remit, one with potentially massive consequences for PC gaming, but on its own terms it hits the sweet spot that I've yearned for so much from a successor. I only pray we do not have to wait another seven years for more.

 

Let's say I have the domain name domain.blip with a registrar and have the ability to modify the DNS records to my liking. And let's also say I have a few computers on Tailscale with multiple family members participating.

Currently, I have HTTPS support on tailscale via a reverse proxy (nginx proxy man) where I have to update the records every 3 months using tailscale cert. This works, but it has drawbacks. For one, subdomain resolution isn't trivial without connecting all computers to a DNS server like pihole or equivalent. Additionally, all users need to remember the somewhat arbitrary tailscale network name and path to the service. With multiple services working in tandem on the same server, this can mean breaking the abstraction of the network. Lastly, there's the simple hassle of updating the self-signed certs every 3 months compared to, say, let's encrypt which can automate the process.

This is where domain.blip comes to mind. Let's say I wanted a gitea to be available at gitea.domain.blip but, importantly, I want this to be available only for local network users (on the tailscale) and to simply resolve to a generic 404 for non-tailscale users.

Is this possible to do while using a service like Let's Encrypt to automate the SSL ticket creation? Obviously the reverse proxy on the home server would have to handle the other hostname itself, but it should be possible to resolve to a website hosted on a non-public IP address right?

Thanks for anyone who has insights here. I'm also just interested to hear people's experience running a similar setup, even if we're talking about wireguard instead of tailscale.

[–] [S] 1 point 1 day ago

Having checked it out a bit, I'm still waiting for something a bit more substantial here.

Granted, MK is MK, but I do feel like there's something missing with MKW that isn't covered by just adding the SMK courses. Additionally, I think green shells should be bouncing more and not less. As it factors in right now, green shells are basically a non factor for first place on second lap scenarios (which, granted, are rare in this game considering most of the players will want to play Knockout Mode.)

Lastly, I feel like Knockout needs some level design adjustments. The in-between sections still feel a bit too vanilla right now.

Overall I'm glad they're making some progress in fixing some of the games issues, and time trial improvements are good as well, so I'm eager to see if and when they'll make some proper DLC to fix the rest of the issues.

  • source
  • submitted 5 days ago* (last edited 5 days ago) by [M] to c/karting@lemmy.zip
     

    Listen, I failed to post about this news two days ago. I've had a busy week this week. 😆

    I haven't actually played the update yet and might take the time to check it out this weekend -- I'm a little bit hesitant on resubscribing to Nintendo Online until at least The Duskbloods is coming out.

    Change for version 1.9.0 courtesy of Nintendo Life:

    General
    
        Propeller Rally and Turnip Rally have been added to Knockout Tour.
            You can select these if you have played one of the rallies in Knockout Tour.
        The following courses have been added to VS Race, Time Trials, and races in Online Play and Wireless Play.
            Courses you can choose from Mario Circuit
                SNES Mario Circuit 1
                SNES Mario Circuit 2
                SNES Mario Circuit 3
            Courses you can choose from Ghost Valley
                SNES Ghost Valley 1
                SNES Ghost Valley 2
                SNES Ghost Valley 3
            Courses you can choose from Choco Mountain
                SNES Choco Island 1
                SNES Choco Island 2
            Course you can choose from Sky-High Sundae
                SNES Vanilla Lake 1
            Course you can choose from Koopa Beach
                SNES Koopa Beach 1
            Notes: Item panels will appear on these courses instead of item boxes. Item boxes will appear on the race that leads to Mario Circuit.
        The time for each lap is now displayed in Time Trials.
        The color of the time difference between the player and ghost data in Time Trials has been changed.
            When the player time is faster than the ghost, the color is red.
            When the player time is slower than the ghost, the color is blue.
        A filter was added to the frame that appears when using Photo Mode on the pause menu.
        You can now use the Y Button to switch the camera to the player’s perspective while spectating or playing in races, Knockout Tour, or Battle mode.
        You can now use the R Button to view participants’ real-time rankings when spectating during races or Knockout Tour.
        You can now switch to Spectator Mode when playing in a room in Online Play or LAN Play.
            This mode only allows players to watch the game without participating.
            Press the Y Button from the pause menu after joining a room to switch to Spectator Mode.
        Up to 26 players can now join a room in Online Play or LAN Play.
            Up to 24 people can join the game.
            When there are 24 participants, no one else can join the room until a participant switches to Spectator Mode.
        The amount of rate fluctuation in races now varies according to the length of the course.
        The method for calculating rates when the score is the same in Battle has changed.
        Adjusted slipperiness when covered in Blooper ink.
        Decreased the number of times that Green Shells, Coin Shells, fireballs, ice balls and Boomerangs bounce off walls.
        Reduced the amount of time it takes to return to normal after getting crushed by a Thwomp.
        Increased the amount of time you won’t take damage from Boo after it takes an item from you.
        Adjusted the probability of obtaining items from item boxes in races and Knockout Tour.
        Auto-Use Item can now be used even when set to Custom Items.
        Made it possible to see the following items your rivals may be holding:
            Coin, ? Block, Kamek, Blooper, Feather, Fire Flower, Ice Flower, Boomerang, Hammer.
        You can no longer wall ride around the edge of the road in Ghost Valley.
        Buoys have been added to the race leading from Acorn Heights and Dry Bones Burnout to Boo Cinema.
    
    Fixed Issues
    
        Fixed an issue where swinging the controller while jumping at the end of a rail could cause you to jump higher than usual.
            Time Trials ghosts affected by this issue may be removed from View Rankings without prior notice.
        Fixed an issue where, after a crash, a player might become trapped after being pushed by a car driving down the road.
        Fixed an issue in Free Roam where opening the map just before entering a pipe could make the controls inoperable.
        Fixed an issue where a Spiny Shell would ride along the rail in reverse direction.
        Fixed an issue where, after going off-track on certain courses, the player would sometimes respawn significantly further ahead.
        Fixed an issue in Bowser's Castle where a player could get stuck on the lava waterfall while moving through it as a Bullet Bill.
        Fixed an issue where players would pass through walls when using the Feather in Dandelion Depths.
        Fixed an issue in Crown City where the finish line tape would disappear after crossing the finish line.
        Fixed an issue where the final ranking could be wrong when using a Feather to take a shortcut on Mario Circuit.
        Fixed an issue where driving along the outer edge of a corner on Wario Stadium could cause the player to go off-course.
        Several other issues have been addressed to improve the gameplay experience.
    

    So this will instead serve as a discussion thread. If you've checked it out, let me know your thoughts.

    [–] [S] 1 point 1 week ago* (last edited 1 week ago) (6 children)

    OK now this would make some sense but would definitely be a bit of a show stopper for me. I'll give it a try though.

    Edit: Unfortunately this didn't solve the issue. I thought it did for a minute, but it was the browser cache I think auto-filling the correct result.

  • source
  • parent
  • context
  • [–] [S] 1 point 1 week ago (1 child)

    I think I have uids set up, but I'm not positive they're set up correctly.

    Here's an example of /etc/subuid for example, with it a bit anonymised for my specific user setup:

    core:524288:65536
    syncthing:589824:65536
    userA:655360:65536
    userB:720896:65536
    userC:786432:65536
    

    Syncthing in this case isn't running any podman containers, all sharing is done bare-metal. userA is working, but userB and userC do look like they're configured "correctly" at first glance. podman system info seems to be outputting the results above

      idMappings:
        gidmap:
        - container_id: 0
          host_id: 1101
          size: 1
        - container_id: 1
          host_id: 786432
          size: 65536
        uidmap:
        - container_id: 0
          host_id: 1101
          size: 1
        - container_id: 1
          host_id: 786432
          size: 65536
    

    Note: The user in question here is uid 1101, another new user I created for testing purposes.

  • source
  • parent
  • context
  • [–] [S] 3 points 1 week ago

    I mean, I might be wrong, but this only changes the mapping right? In the case that user broke containment, I would assume that they would have the user id of the user that's running the process?

    Granted this is all in theory so I'm not sure exactly -- that might be a perfectly reasonable way to do it.

  • source
  • parent
  • context
  • [–] [S] 1 point 1 week ago (1 child)

    As far as I understand, it should as it's embedded inside the actual image file and not mounted.

    I'm having other strange behaviour on non-1000 uid accounts. For example, running docker.io/library/httpd using the podman examples page on an account that isn't userid 1000 will create an issue where it complains that libgcc_0 isn't installed. This works flawlessly on the uid 1000 user.

    It does make me think that something needs to be configured for non-uid 1000 users on podman. This is not replicable on arch linux on my raspberry pi, fwiw.

  • source
  • parent
  • context
  •  

    Self cross-posting from: https://lemmy.zip/post/70909658

    Intention to have slightly better visibility from the self-hosted crowd and I'm interested in more general feedback on this too.

    Hey everyone! I'm trying to find a solution to a really confusing problem...

    I have the following simple nginx docker compose configuration on my Fedora home server that I can run without issue on my uid 1000 user, lets call this user "userA".

    services:
      nginx:
        container_name: nginx-alt
        image: docker.io/library/nginx
        restart: unless-stopped
        ports:
          - 8181:80
    

    This exposes internal port 80 as 8181 and can be accessed in a lan in the expected matter.

    However, for security reasons, I want to actually host this service eventually on a completely different user with less permissions. Let's call this user "userB" who has a very limited scope of the file system. This is to prevent potential escaping of the rootless container causing major file system havoc (i.e. reduce the scope of the user to a very limited network of containers.)

    The problem is really simple: For some reason, when userB runs this service (uid 1001), the nginx service suddenly complains about privileges. As a result, I get a "Forbidden 403" error when hosting. Turning off selinux has no affect (so setenforce 0 does nothing, meaning I can rule out secure linux interruption.)

    The errors look like the following:

    nginx-alt  | 2026/09/04 20:03:34 [error] 25#25: *1 "/usr/share/nginx/html/index.html" is forbidden (13: Permission denied), client: xx.xx.x.x, server: localhost, request: "GET / HTTP/1.1", host: "xxx.xxx.xxx.xxx:8181"
    nginx-alt  | 10.89.0.2 - - [04/Sep/2026:20:03:34 +0000] "GET / HTTP/1.1" 403 153 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:155.0) Gecko/20100101 Firefox/155.0" "-"
    

    For what it's worth, both users should be relatively vanilla and all ports are appropriately exported. There shouldn't be anything, for example, that is making userA run as "privileged" over the other users and podman should be running rootless in both containers.

    I did see a note on the nginx image about running in rootless that I might try, but it doesn't solve my bigger issue here which is the lack of consistency between the two users. Additionally, userns_mode: keep-ids only caused the container to fail to boot for other reason entirely.

    There must be something fundamentally wrong with my configuration of my system. Has anyone had any experience running two podman containers on two different users simultaneously that can provide feedback?

    Obviously, I'm not trying to run just an nginx server, but I found this to be the easiest configuration to reproduce.

     

    Hey everyone! I'm trying to find a solution to a really confusing problem...

    I have the following simple nginx docker compose configuration on my Fedora home server that I can run without issue on my uid 1000 user, lets call this user "userA".

    services:
      nginx:
        container_name: nginx-alt
        image: docker.io/library/nginx
        restart: unless-stopped
        ports:
          - 8181:80
    

    This exposes internal port 80 as 8181 and can be accessed in a lan in the expected matter.

    However, for security reasons, I want to actually host this service eventually on a completely different user with less permissions. Let's call this user "userB" who has a very limited scope of the file system. This is to prevent potential escaping of the rootless container causing major file system havoc (i.e. reduce the scope of the user to a very limited network of containers.)

    The problem is really simple: For some reason, when userB runs this service (uid 1001), the nginx service suddenly complains about privileges. As a result, I get a "Forbidden 403" error when hosting. Turning off selinux has no affect (so setenforce 0 does nothing, meaning I can rule out secure linux interruption.)

    The errors look like the following:

    nginx-alt  | 2026/09/04 20:03:34 [error] 25#25: *1 "/usr/share/nginx/html/index.html" is forbidden (13: Permission denied), client: xx.xx.x.x, server: localhost, request: "GET / HTTP/1.1", host: "xxx.xxx.xxx.xxx:8181"
    nginx-alt  | 10.89.0.2 - - [04/Sep/2026:20:03:34 +0000] "GET / HTTP/1.1" 403 153 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:155.0) Gecko/20100101 Firefox/155.0" "-"
    

    For what it's worth, both users should be relatively vanilla and all ports are appropriately exported. There shouldn't be anything, for example, that is making userA run as "privileged" over the other users and podman should be running rootless in both containers.

    I did see a note on the nginx image about running in rootless that I might try, but it doesn't solve my bigger issue here which is the lack of consistency between the two users. Additionally, userns_mode: keep-ids only caused the container to fail to boot for other reason entirely.

    There must be something fundamentally wrong with my configuration of my system. Has anyone had any experience running two podman containers on two different users simultaneously that can provide feedback?

    Obviously, I'm not trying to run just an nginx server, but I found this to be the easiest configuration to reproduce.

    view more: next ›