member since 26 Jul 2024 20:52
Haven’t watched the show yet but I might want to check it out. Thought I’d share this article that hit my RSS feeds. :)
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.
Self cross-posting from: 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
1000user, lets call this user “userA”.services: nginx: container_name: nginx-alt image: docker.io/library/nginx restart: unless-stopped ports: - 8181:80This 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 (sosetenforce 0does 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-idsonly 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.
Because in some respects the original ghost in the shell was saying something about these nations. The entire significance of the back end political theater is a bit meaningless if the places talked about are abstract considering it has to do with one nation faking a terrorist attack in order to perpetuate a war against another nation. This isn’t even touching how, in the world of GitS, the United States is supposed to be a tyrannical empire on the quest of taking over the entire Americas and a bit of a malicious ally to Japan. Gee, I wonder why they censored that. 🤔
The goal Science Saru had was to adapt the manga as is. The censorship of it, unfortunately, has undermined the goal. I still enjoyed it but I hope that an eventual blu ray release untainted hy Amazon restores the intended names. It really hurts the world building of the original GitS which, yes had plenty of fake names, but did try to ground those fake names as evolutions of existing nation states.
Agreed, I’m looking forward to check it out.
No volumes mounted and yes, it’s using the podman backend. Just double checked it wasn’t using the docker one.
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.
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.
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.
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.
Uh oh, looks like someone’s AI company is running out of money and needs people back on Twitter. 😭
It does, but it seems like it’s still a bit of an afterthought. But it’s getting better.
Still tho, podman is fine and I like the project as an alternative to docker.
That’s weird AF. I also hate the implication that anime is for kids. It’s not, even if GKIDS sticks to PG material (I’m not sure they do, but I’m also not sure they don’t).
I don’t think this is the intention but it’s understandable. In fact, they’re probably one of the largest distributor of “prestige” anime today, with ownership of local distribution rights to things like Evangelion.
This comes up every time I get a post from their RSS about publishing anime, so it’s probably something they should change at some point.
Rich kids. The worst type as they’re also the least likely to get meaningfully punished.
My understanding is that the battery life is pretty poor even when only streaming. 1:45 to 2 hours is the estimate I’ve heard.
This admittedly sounds pretty bad as it means you’ll likely need to be plugged in, which kind of defeats the point of a wireless headset. I imagine there’ll be some last minute attempt to eek out more battery life wins, but considering the brightness and refresh needs for VR, it might not be possible to get much more out of it.