Hacker News Reader

I run Steam under a different user account (and X server). It takes care of the junky home directory problem. However, the main reason is because I don't trust all the random game developers.

I use separate debian nspawn containers for this kind of crap.

It doesn't bother me to turn on multilib support in a rootfs I only boot in a container just to run steam client and its games. Though I do have to reboot into a kernel w/32-bit support first which can be annoying.

> Though I do have to reboot into a kernel w/32-bit support first which can be annoying.

Isn't that in by default on pretty much everything? I'm not aware of any distro shipping an x86 kernel with 32-bit support disabled, anyways. Are you intentionally building your own kernels and removing 32-bit compatibility? Seems like an easier thing to fix than having to reboot every time.... (Unless I've misremembered and that is a default, in which case please correct me because that throws it the other way)

I build my own monolithic kernels, and only enable the features and drivers I use.

My host is all 64-bit userland, it's just exceptions like Steam stuff that need 32-bit support (even the Steamworks/Steampipe developer side is annoying like this). So I boot into that kernel when doing those things, and keep those userspaces in separate containers which also get "booted" when needed.

1) You complain of messiness on ArchLinux? Clearly you are not the target for ArchLinux and would be more suited to an easy to use distro, instead of one of the hardest to use.

I don't think Arch is messy. Difficult to use, certainly, but architecturally it's far more clean than Ubuntu.

Why not just Flatpak Steam?

To me it feels weird to use binaries from outside the repos, period. On Windows double clicking an exe file feels natural. On Linux "chmod +x something && ./something" is icky.

That's a good point! Maybe that's the source of it. I've gotten used to it for a couple of statically compiled long-lived binaries (games), but other than that even software I compile myself gets packaged before I install it.

You can run GPU accelerated apps in a container. You just need to install the same video driver and expose the x11 socket and card device. The app could still be evil and screen scrape or key log but at least it has no access to your filesystem and when the container is off it is truly off (assuming reasonable container security). There are several tutorials out there for at least browsers.

You forgot sudo. IIRC Windows Steam asks for Admin rights.

You are correct, it does.

Uhm, sudo on a proprietary binary outside the repo? ...Yeah no thanks.

What difference does it make really. Running a program on linux as a regular user can access all of your files, record your screen, keylog you, grab your passwords from your browser, do basically anything. Run it with sudo and what more can it do? Mess up your grub config? If a malicious program was run as a regular user it could basically ruin everything you care about unless you happen to be sharing a computer with multiple people but even then it could just wait until you run something with sudo and keylog your password.

How could a unprivileged program keylog my sudo typings? (I am running Wayland)

What CPU are you running? Spectre mitigations enabled? Hyper Threading?

Greater issues with possible persistence, control over daemons and sockets, access to lots of files I don't let regular users have access to, etc.

Plus the other half which is the whole proprietary binary side of things. IMO, lack of transparency invites more bad behavior.

Multiplayer Windows games in general ship anti-cheating software implemented as kernel modules that are more invasive than even draconian DRM.

I've played several multiplayer games for Windows and I've only seen Fortnite do this.

Many "serious" multiplayer games will feature this. I mean VAC, EasyAntiCheat, BattlEye. They all have a kernel module component.

Not necessarily. [0]

Also, it is actually quite trivial bypassing UAC prompt in Windows. It simply gives a false sense of security.

Something as simple as SilentCleanup [1] still works to this day. This will bypass UAC with little effort.

Even worse, following that, it is also trivial to get NT AUTHORITY\SYSTEM using Windows Management Instrumentation Event Subscription. [2]

I've done it as an exercise in Go out of all languages and it ended up fully undetected both on disk and during runtime.

So Windows simply provides a false sense of security. After all Microsoft themselves said [3]:

  One important thing to know is that UAC
  is not a security boundary. UAC helps people
  be more secure, but it is not a cure all.
  UAC helps most by being the prompt before
  software is installed.

[0] https://amonitoring.ru/article/steam_vuln_3/

[1] https://enigma0x3.net/2016/07/22/bypassing-uac-on-windows-10...

[2] https://attack.mitre.org/techniques/T1084/

[3] https://blogs.msdn.microsoft.com/e7/2009/02/05/update-on-uac...

> On Windows double clicking an exe file feels natural.

Isn't that just because the system is less structured in general, so you've been beaten into submission?

After spending years on Linux pretty much everything on Windows feels like it's potentially spewing ick all over the place (registry, arbitrary folders, etc, not to mention the lack of reproducibility)!

This is how I feel when I use Linux!

Windows is moving towards apps living only in their own little containers, nice little isolated folders that they can't write outside of, with the exception of their reserved folder in AppData.

In contrast, *nix bunches executables up en-masse into a handful of folders.

It likely comes down largely to what you are used to.

It's an issue of familiarity. I still feel that everything installed by distros' package manager or via "make install" is spewing ick all over /etc, /usr, /var, and God knows where. On Windows, almost everything only ever sticks to a) its installation folder, and b) the registry.

Truth is, Windows is a mess when installing stuff also. Beside installation folder and registry, there is also user's AppData folder, \ProgramData in system drive, and then installers tend to leave some MSIs in \Windows\Installer, all the libraries in System32 and sometimes, they also place stuff in Program Files\Common files.

The best at isolation has historically been macis, and then again you have plenty of packages installing to /Library, kernel extensions, uninstallers being placed in Applications/Utilities, MS updater being placed in /System and so on