No

Any OS with no password is insecure. Hands down.

Linux/Unix has a permissions structure that works at the filesystem level, to be really brief about it.

Files are owned by users. Users can be part of groups to represent a larger number of users for simple organization.

Regular users can only touch files they own, or are owned by a group they are in. Root has master permissions to anything.

As a regular user, your home directory is owned by you. Anything you create is owned by you. All programs executed by you require that you have permissions to those things. Therefore if you’re just bouncing on the system and doing things, you can only harm the files that you own.

Your account having a password prevents access to this account. Though it’s a regular user, anyone with that password can harm your files.

The Root password allows anyone to execute or delete any files on the system. Anyone with this password can get to any file on the system, so you never let anyone know this password.

Your assumption that SSH somehow has different passwords is incorrect. You make a user on a machine and you don’t prevent SSH access…then they can SSH in, but they’re still a regular user.

They aren’t going to make their own desktop. That’s just not gonna happen. They’ll use KDE as before, and that’s just the facts. I’m not saying they will make anything other than a VR-style compositor to select standard 2D virtual desktops. That’s simple and effective, and doesn’t require building a whole new thing.

This should sidestep that and timeout pretty quickly: https://jshtab.github.io/guide/gvfs-autmount/

Not sure you’re getting it…

SteamOS runs KDE desktop. Frame will also have KDE Desktop, be use it’s just running the ARM build of the same SteamOS that will be on all of these devices.

Making a VR-reaey compositor display for this is fairly simple after this point, you just need to hook all the sensors into camera movement for the screen, and that screen can show many composite views…like the desktop, or a media screen, or the Steam Library.

It’s a basic function of VDD. It will definitely be in there.

Try going into your BIOS settings and disabling IOMMU for the USB and Chipset settings. Boot and see if it works then.

Your North and South (if you have one )bridge chip?

Open your machine and look at these ports.

Are they directly connected to the motherboard, or on the front of a case extended by a cable?

It’s not “trouble” if you’re already familiar with Linux. It’s not the way I would go as a user of 20+ years, but it’s not just for desktop use.

If you’re looking to build a platform for something, it’s perfect. Look at why Valve switched to use to for SteamOS. You have an underlying framework of a stable system, and you just create automation to slap it all together into the base layer of all the things you want without having to worry about specific things breaking the stack you’re building on top of it.

It’s like a blank page instead of a notebook with line guides.

It helps make more sense if you think of everything you’ve got to build on it already existing in a git repo. Merge > Build > Release. Makes perfect sense, and you save yourself creating an entire distro to maintain from scratch.

99% of all Windows games running Proton, and most perform better than on Windows, depending othe game.

For the specific games you mentioned, they all have Platinum rating in Proton, meaning flawless. You can see here in ProtonDB.

I’m not sure what your experience was in the past, but I write tons of Proton patches for games, and the only ones I’ve seen that don’t play well are the pre-DirectX9 games, which can’t plan on Windows XP or later anyway. Proton will soon be able to play these games without issue thanks to some Vulkan patches coming up.

That’s slightly different. That is mapping controllers to already existing inputs for a game, which steam-input already does.

Mapping all the sensors of a VR headset for motion and tracking is an entirely different thing, though kinda similar in some sense.

They’ve already said they’ll be using FEX: https://www.pcgamer.com/hardware/vr-hardware/steamos-launching-for-arm-fex-translation-layer/

Well it’s not going to suddenly be all VR’d up or anything 🤣

Part of the reason I would imaging they implementing a new kind of steam-input layer for VR is for things like a theater mode and desktop. I could see them making some sort of a simple hook for view controls in games for your exact scenario, but that would be heavily dependent on the game having something like free look already be possible, and then the developers just write a quick patch of a couple lines to hook the steam-vr-input hook into their code, and BAM.

It wouldn’t need to. They would just need to include a virtual desktop manager or interface to render the usual compositor in a VR sort of way. That’s why I put it in the list. Same thing that would make a theater mode would also allow a desktop to render in a space on a VR compositor.

Desktop is a built-in feature of SteamOS. They’d have to actually work to remove that by default. No reason for it not to be there.

You don’t read much, eh? Valve has confirmed it, people have seen it, and multiple artists and devs have confirmed working on the finishing touches in the past year.

They released Alyx with the Valve Index, which also confirmed to be a drop-in VR engine for the Half-Life games. Valve likes releasing their IP games as surprises, and no better way to sell out millions of units than releasing HL3 along with this new hardware.

Seems like a pretty safe bet.

I’ll drop what I said about this in another thread:

I think you probably need to understand the underpinnings of what Valve accomplished over the past few years to understand why the Frame is useful.

Essentially, it’s a Deck strapped to your face. Same OS, same everything, just different hardware platform.

Valve spent the time to revamp SteamOS in order to make it more portable to various devices, which are now launching. Couple that with their efforts on Proton, and you have an entire ecosystem with very little in the way of preventing people from adopting these devices with their ease of use.

Steam Deck was just sort of the appetizer and test launch to gauge interest and build a fully functional hardware development and support vertical in the company, and it was wildly successful. I guarantee (if they can get the price right) that the Frame will sell WAY more units than the awful Vision Pro. I honestly think people might adopt this over buying another version of the Deck if it’s comfortable.

Some things I expect to happen with the Frame launch:

• A more expanded integration of Desktop features. If Valve doesn’t do it, the community will.
• Virtual screen management
• Theater mode for viewing media
• Virtualized VR input (like steam-input but VR)
• Pairing capabilities for multiplayer
• Half-Life 3 release (not joking)

Depending on how this all was built and configured while Tailscale was running, you may need to take some steps to “undo” some things, like re-mounting your network mounts with the proper IPs (auto discovery may have messed things up).

What are the errors you’re getting?

Now it looks correct. If you have a Gigabit capable switch/router, and 100Mbps seems wrong, you should check your negotiated link speed on your Ethernet interface with something like ethtool [your_interface] | grep Speed

100Mbps is obviously low if you have a Gigabit router. Either way, you should have your jellyfin setup working without issue now.

TLDW: “Everyone ignore my personal and political positions on everything, I’m giving you free code…”

We don’t need another Reiser incident, shitbag.

Go fuck yourself, David.