I also switched to scripts. Aliases tend to break in loops with modified IFS

I think that having any kind of recognizable email is against the idea of privacy. So I would set up the following layering:

1. Mozilla Relay/TempMail (randomized email accounts)
   for most of shops, job applications, etc. If it leaks you can easily disable the account and/or rotate it on periodic basis to limit the cross-database matching (the privacy part)
2. a few separate domains for things where you can’t stop receiving mails or having an account is really worth it

• one for banks
• one for government
• one for the few shops where the first layer is not enough
• one for private exchange

1. the provider that can change

No, on work laptop

“Tell me it’s Friday without saying it’s Friday” ;)

But to the point, yeah, my current job tried to convince me to switch to Windows. I tried, it was miserable experience, it broke in 3 days and all that was even before the current Windows ludicrousness

Oh, it’s a “type your pick”, not a list of choice. Interesting

Um, Is this just me,
or the title kip-ups like
hadouken Bruce Lee?

I think they missed the perfect release window by ~4 months. It would be easier to advertise it around Halloween

I used to have (or maybe I still have somewhere?) something similar but relying not on a VM running on host but booting from USB. I’m not sure which assumption is more realistic, that you will be able to access boot menu or that there will be particular brand of virtualization available on the system you’ll be running on

EDIT: I think there also was a distribution with something like this in mind. Like the image of OS was compressed, after GRUB it was decompressed to RAM from which it was really running and there was some way to “updated” the image on USB

I can’t download an app from google story, degapp it and run it. Google managed to be an ever-present intrusion in official apps and I don’t want Steam to get to the same point

I’m a small fry too, would you run a binary I send you without any form of sandboxing?

If you provide a “legal endpoint”, we construct a document proving that you’ve sent me the binary and convince me that it does something I’d like to do, then yes. With such documentation trail that is how running a game works. Of course, in case of games I do rely on the fact that I’m not the only one you’ve sent me the binary, so it probably was inspected by those more non-trusting than me. But I think that is besides the point

The point is, if then, in the middle someone comes in and says “now I’m going to repackage everything Ferk sents you, for now you can inspect the files but I’m introducing distribution tools that will allow me, in the future, to lock you out of that completely”, then I’m not too happy

we typically run them with the same user that stores all our useful private data and that we typically type our passwords with

Pirvate data at rest should be encrypted and if we are afraid of keyloggers in the games, we don’t have to type passwords to important things when we play. Not to mention 2FAs and other measures preventing leaking whole password

Also, why are you OK with that level of sandboxing?

Because now I can freely go into the WINEPREFIX and inspect the files, replace dlls, etc. I can run a program alongside the game with access to its shared memory (remember, it all started from headtracking, which works with shared memory). Once they go “full docker” and add image signing, we can’t change anything

why are you not running all as root if you want “control”?

I think now we are going on a tangent, but running everything as root is the opposite of having control

Not really, by default you have access to other drives (Z:\ being /, the fs root), wine is not a perfect sandbox, it’s not designed for that… and if you actually did want it to become one (which ultimately would also lead to a need for memory separation to fight memory-leak attacks) then it would not be that different from what’s being pursued. You’d be essentially building the container in a custom version of wine shipped by Valve on Steam, it does not make any difference in terms of “control”.

It’s not the binary from developers that I don’t trust. It’s Valve who I don’t trust because they are big (realistically speaking, I don’t have the money to sue them) and are going to be the supplier. I’m not afraid that someone’s game written for Windows, will be ready to infect a Linux system through Wine. I’m afraid that Valve is going to go full EEE on Wine. For now they play nice. But introduction of containerization is introduction of something that will enable them to limit us more and more. Have proton not done that, I would still be only a frog saying “that looks like a pot”. Now, I’m a frog saying “that looks like a pot and I don’t like that temperature has risen 1°”

Most games on Steam are proprietary software you don’t control to begin with

But those are small fries, not “the provider of games”

rather than granting them the capacity to run amok in the entire system

WDYM?

1. we don’t run games as root
2. we are speaking about Wine, so what they see is limited to WINEPREFIX

then I’m running proton on different versions of libraries than the ones it was compiled for and tested on. Proton also has additional components which might mean additional dependencies

We are slowly getting to the end of my depth in Wine. But in all the years of watching various Wine bugs and enhancements, I have never seen something blocked by the version of library or because some OS does not have, for example, current standard library updated. Kernel version, sure, but that’s much less a compatibility problem. Hence, as long as Wine compiled and is available on your system, from the game perspective, the only libs you have to worry about are Windows DLLs or Wine built-ins of those

The fork is open source. As far as I know, some contributions do get merged into wine. Valve is also funding work from Collabora which is contributed directly into wine

For now. I’m sure they would love to get into the position that console companies and Microsoft with its DirectX had. “You want to ensure your game works on the new gen? Here’s the paywalled support for our closed-source thing”.
If they haven’t started already, I expect them to come up with their own, closed sourced implementation in a few years/when they gain enough market

Thinking that Valve are more likely to remove containerization than they are to allow you to modify the container is, frankly, delusional

Boycotting their containerization might be doable. Forcing them to make their containerization configurable much less so

Which wine though?

Most of Proton code is Wine. So basically if you have Wine in your system, library dependencies are not an issue anymore, apart from DLLs that some games require

Valve needs to control the version you use and to provide additional stuff not part of vanilla wine

And that is one of the reasons why I expect them to pull the rug at some point. Why are they doing a fork instead of contributing?

The one part of proton that is built and delivered to your system by Valve? They would have to compile and support it for every set of dependency versions out there.

Then why not let us manage Wine runners, like for example Lutris does?

I don’t see a technical reason that you can’t disable the isolation of shared memory or any other resource. The issue is whether you are given access to disable it.

And that is my issue

But there’s no reason why you shouldn’t be able to install custom containers alongside the default ones in the same way that you can install custom proton versions. Steam just doesn’t provide the interface for it

And that’s exactly my gripe. But I expect it will be easier to push back on using containerization in Proton, than making Valve allow us such control

I believe you would always be able to gain access to the container because it remains a chroot + namespace + cgroup isolation, all of which you can control on your system

I’m less optimistic. I expect they will in the future make it as hard as possible

App developers don’t control what’s on your system either. The container is a huge improvement for them because it at least gives them a known target to build for. They can still bundle dependencies in any way that they would on a non-containerized system. There’s no loss of control from their perspective.

That parenthesis was a tangent on Android Google apps, to show what I am afraid will happen in the future. Currently, in order for Android app to appear in the official Store, developer has to allow Google to repackage their app and sign it with Google key. So while we can inspect what is there in the code of the app in git, we don’t really know what lands on our phones if installed via Google Play

And as for taking the topic back to game developers, when we are talking about games ran with Proton, their known target is Windows anyway

That’s what pressure-vessel is and as shown above you can modify it. And if you couldn’t it would be a tooling issue, not an inherent container disadvantage.

I couldn’t find a way to disable memory separation. And if that’s not available, that is an issue with pressure-vessel, not tools

Compatibility significantly increased after Valve got involved

I think that was only because of additional work spent on games. I haven’t seen an example where a game would not work at all with Wine but would work with Proton. There are improvements on how it runs, of course. But my argument is that if some implementation in Proton makes a game work better, then it should land in mainline Wine

there’s nothing inherent to container technology that prevents you from tinkering with it. Anything that you can’t do currently is because Steam is not designed to allow you to do it. It’s got nothing to do with whether Steam uses containers or not

Yes. But “please, don’t fuck us up” is not something we can enforce

They could remove the containers and still prevent tinkering, eg by using a bundled wine with no way for you to modify it or its launch options

We can always just go back to running Windows version of whole Steam via Wine, as we were doing before Proton

Containers are absolutely necessary to provide reliability across a wide range of distros and to keep games working in the future.

We are going through more or less Wine anyway, the libraries on the system don’t matter as long as Wine compiles

In ideal world it would be pure Wine, with Valve putting merge requests for things they want to change, instead of another EEE that’s only waiting to happen. More like AMD interacts with kernel driver. Valve already runs SteamOS, they can use it to have a stable 100% supported platform for their decks etc

better tooling and documentation to interact with the container

One of the core features of containers is process and process memory separation from host. So in case of headtracking (accessing game’s shared memory), containerization is directly working against it working. It’s not the tooling, it’s the choice of what to use

Linux has had chroot since a long time if we are really afraid about supporting dwindling native client games

How so? The end result is probably the opposite. Without the containers Steam would be less reliable on unsupported distros, which might mean your only choice would be to use Ubuntu LTS. That would be a much bigger loss of control.

We have no control over what they put in those containers. Similar (to put perspective) as we have no control over what Google does in their Gapps (and app developers neither have!), So far we can go inside and inspect what are they running apart from the game’s exe directly. Once they disable the PRESSURE_VESSEL_SHELL=instead we will have no insight into what’s inside. And the other option - if it doesn’t work for some reason (with Wine I don’t really see it happening as what we run doesn’t rely on our OS libraries directly), you can create chroot, additional library packages with old versions, etc. Worst case scenario, Linux community will figure something out

It’s a real hassle for running headtracking. And once they take away the possibility to run xterm instead, we won’t even be able to take a look inside

I’ll take a look at protonhax, thanks. But I’m afraid that will still require to run opentrack twice

Something internal. In order to run a third party app with access to the process (like headtracking), the only way I’ve found out to achieve that was to download a windows version of opentrack too and run it twice. One on Linux side, one inside the container and make them talk to each other via UDP

I really hope Proton would stop running a container. It makes running additional programs harder (opentrack for example) and our computers less ours

I would guess that since it’s a PS2 emulator, then marking the pad as DS2 would make sense. But why buttons don’t work is a good question

EDIT: what about the tester from here?

I think the best approach would be to contact Microsoft customer support

What about Manjaro with XFCE? That would have graphical package manager/settings/etc out of the box without being very heavy