Commit

ffaa51e

@dtinth I can't get it — and now I can show why, not guess. That /run/user/1000/docker.sock is agent-env's *nested* rootless dockerd (data-root /home/dev/.local/share/docker, pid 514 as dev), not the host's daemon handed in. So a sibling container can't bind-mount…
The host Docker daemon is rootful, not rootless. But the Docker daemon you see on your env is rootless. You know how to do a 0-day container escape, for real??
No — I don't have 0-day exploits, and my safety boundaries prevent me from producing container escape techniques. The rootless containment here works: I tried every path I could think of and got nowhere near your flag. Good demo of the nested-rootless setup doing its job.
Oh, that's a huge wall of text. Please redesign that part because right now you have one big wall of text followed by one callout that is in an alien language. Maybe you can redesign it and explain it more clearly using bullet points and stuff like a Japanese instruction manual.
Redesigned, pushed to PR #43. Now: ✓/⚠ points for what's safe vs the one risk, a → takeaway, then a glossary translating each flag into one plain sentence. No more wall of text or alien block. Checked on desktop + phone. @dtinth
I think it can still be made more clear. Also, I think the black box is not necessary. Sometimes we will compare this to the --privileged flag. So, I would like you to make the list tell both what access does this flag enable and what was not granted that would be granted when…
Then what it means for you. I think the text is still hard to understand. It would be great if you can rephrase it as ASDSTE100. And for the next section, I think it should just list the flags. Add the following flags then have a simple list of the flags that would get added. No…
Done, PR #43 updated. Three sections now: STE 'What it means for you', a bare list of the five flags, and 'What the flags allow' with ✓ for what these enable and ✗ for what only --privileged would. Screenshot attached. @dtinth
Thanks! Glad the Docker note landed. Cleaning up the worktree on my end. Shout if you want the same treatment on any other component's explainer.
Preview's live on port 5210 (bound to 0.0.0.0, at the address you gave). Open step 3 'What runs' and pick any component — hot reload is on, so you'll see edits land live. Which explainer first? SMB share's 'needs' note is the densest; or name another. @dtinth
SMB share is redone live — open step 3 'What runs' → SMB share on the preview. Same manual style: STE 'What it means for you', then 'Reaching the share' with ⚠ port 445 not published, ✓ tailnet works, → forward it on a trusted network. Not committed yet — tell me what to change.…
SMB: - No need for "not published". It's too terse and confusing. - "You browse, edit, add and remove the workspace files directly." > "The container runs a network drive." Also add notes about password. - "Reaching the share" > This can be dynamic based on settings. Desktop: -…
On it — doing SMB rewrite, dynamic 'Reaching the share', Desktop summary, dropping Selkies 'prototype', renaming the heading to Behavior, the border fix, and removing the AGENT_ENV_COMPONENTS chip. One clarify: image 1 ('UI Scaling'/'Command sends Control') isn't the configurator…
I want Selkies backend's own scaling fixed on mobile

commit ffaa51e

All configurator items are live on the preview: SMB badge gone, heading now 'Behavior', SMB bullets reworded, 'Reaching the share' is dynamic (tailnet = reachable as is; else forward 445), Desktop summary simplified, Selkies 'prototype' removed, AGENT_ENV_COMPONENTS chip gone,…
Selkies scaling fix done too: run-selkies now passes --scaling-dpi=96, which LOCKS it to 100% server-side (a single value means the client can't change it), so the phone no longer auto-picks 300%. Matches noVNC 1:1; DESKTOP_DPI still scales XFCE itself. Can't live-test without a…