I had been working for only a few months at my first job and it was the first time I could buy a desktop PC without very tight budget constraints. So I thought I’d look for a more midrange GPU for once. I wasn’t convinced it would be worth it but I said fuck it what’s the point of working and making money if I’m scared to spend it on something I want? So I bought an AMD Radeon 5700XT for ~400€ sometime around Christmas 2019. If you’ve been following PC hardware prices in the COVID era you know I’m extremely happy with my decision.

How is this any less meaningful than any other use case? Is downloading a distro to play video games ok? To shitpost on social media? To watch clickbait videos on youtube? Why is this in particular a bad use of resources?

How many months should he have waited for an authoritative response?

Well, Marcan should wait as long as feels right to him. As I said previously, I’m pretty sure he was already pissed off about previous R4L issues and he didn’t quit because of this alone. I want to be clear that I’m commenting solely on the expectation of a swifter response from leadership in the original email thread and not on Marcan’s decision to step down, which I can’t be the judge of.

So, I expect people in places of power to take their time when they respond publicly to issues like this, for various reasons. Eg:

• they might try to resolve things in private first (seems to be the case)
• they might want to discuss with their peers to double check their decision making and to take collective action, this is especially true if the CoC committee gets involved
• they might want to chime in when people have calmed down and they expect to be able to have meaningful conversations with them

At the very least, I would have waited to see what happens with the patches if I were in his position. The review process, which kept going in the meantime, essentially sets a timer for a decision to be made. In the end, Hellwig’s objections would either be acknowledged as blocking or they would be ignored. In any case there would have been a clear stance from the project’s leadership. It makes sense to me to wait for this inevitable outcome before making a committal decision such as stepping down.

Cristoph Hellwig’s initial message was on 2025-01-08. Marcan’s stepping down was on 2025-02-07. So no, it’s not several months; it’s barely one month. Getting in fights in mailing lists and making social media posts is not everyone’s first reaction and it is arguably not the best reaction, especially for people in places of power. It is silly for Marcan to demand everybody’s reaction to be as loud and as quick as his own.

It was very clear that the reaction was going to be no reaction.

Well, it turns out that the reaction was pretty clear not “no reaction”. That’s the reason this thread we’re talking in exists. Marcan was objectively wrong if he assumed Hellwig’s comments and nack would be accepted. Instead, Hellwig was explicitly called out for having no say on the matter and for producing “garbage arguments”.

Marcan is not the submitter. Unless I’ve missed something, the submitter is still working on the patch.

Marcan was probably fed up and was looking for a reason leave. If that’s not the case, then it’s silly for him to just quit mid-discussion, before it’s even become apparent what the reaction to Cristoph Hellwig’s behavior would be and whether his reply would even be taken into account during the review process.

Arch doesn’t require you to “read through all changelogs”. It only requires that you check the news. News posts are rare, their text is short, and not all news posts are about you needing to do something to upgrade the system. Additionally, pacman wrappers like paru check the news automatically and print them to the terminal before upgrading the system. So it’s not like you have to even remember it and open a browser to do it.

Arch is entirely about “move fast and break stuff”.

No, it’s not. None of the things that make Arch hard for newbies have to do anything with the bleeding edge aspect of Arch. Arch does not assume your use case and will leave it up to you to do stuff like edit the default configuration and enable a service. In case of errors or potential breakage you get an error or a warning and you deal with it as you see fit. These design choices have nothing to do with “moving fast”. It’s all about simplicity and a diy approach to setting up a system.

The latter is I think aiming for Linux ABI compatibility.

I had never hard of Asterinas, but this sounds like a the best approach to me. I believe alternative OS’s need to act as (near) drop-in replacements if they want to be used as daily drivers. ABI-incompatible alternatives might be fine for narrower use cases, but most people wouldn’t even try out a desktop OS that doesn’t support most of the hardware and software they already use.

I’m not sure why they feel it’s Linus’ responsibility to make Rust happen in the kernel.

That’s not what’s being said here, as far as I can tell. Linus is not expected to somehow “make Rust happen”. But as a leader, he is expected to call out maintainers who block the R4L project and harass its members just because they feel like it. Christoph Hellwig’s behavior should not be allowed.

I’m not saying Marcan is necessarily correct, to be clear. It might well be that Linus chose to handle the issue in a quieter way. We can’t know whether Linus was planning on some kind of action that didn’t involve him jumping into the middle of the mailing list fight, eg contacting Christoph Hellwig privately. I’m merely pointing out that maybe you misunderstood what Marcan is saying.

Or fork it and make a Rust Linux with blackjack and hookers, and boy, will everyone left behind feel silly that they didn’t jump on the bandwagon.

That’s what they’re doing. But if you read the entire post carefully, he explains why maintaining a fork without eventually upstreaming it is problematic. And it’s not like they’re forcing their dream on the linux project, because the discussions have already been had and rust has officially been accepted into the kernel. So in the wider context, this is about individual maintainers causing friction against an agreed-upon project they don’t like.

EDIT: Basically the immunity system doesn’t work like a muscle.

I think the immune system can be likened to a muscle if someone really wants to go with that metaphor, but only if you consider vaccines to be the gym and getting sick is uncontrollable and dangerous physical exertion. So, wanting to develop natural immunity is like wanting to get into street fights to build arm strength. It might kinda work, but you’ll also be in a lot of unnecessary danger.

Do you have access to Signal servers to verify your claims by any chance?

That’s not how it works. The signal protocol is designed in a way that the server can’t have access to your message contents if the client encrypts them properly. You’re supposed to assume the server might be compromised at any time. The parts you actually need to verify for safe communication are:

• the code running on your device
• the public key of your intended recipient

Yeah, that section is bad.

For one, it’s has classic vibe “if you want to keep the nazis out, you’re the one who’s exclusionary”.

But also, how is refusing to engage on a platform “shutting out a significant portion of [the] community”? That sounds backwards to me. Blocking people from engaging with Debian on its own platforms would be shutting them out. The implication in the article is that Debian is obligated to be unconditionally present on every social platform its users might be on.

Vaxrys literally arguing that Hitler should be welcome in communities as long as pushes his goal of gassing of people outside the discord server, but “SJWs” are the real bigots ruining communities

Comparing pregnant women who drink to men in prison as equally violent individuals?

Straight up adding pregnant women who smoke to pregnant women who drink alcohol to women who get late stage abortions with no concern that an individual might belong to more than one group?

Removing fathers who drank before conception from the equation entirely with the justification that an article called it less harmful, but clearly not harmless, which is the opposite of what he did when he put number of drinkers and convicted criminals in the same equation.

Go there & argue with guy if you are capable of showing a more accurate math

I’m not going to argue with that dipshit because it’s total waste of time. And so is arguing with you. I only commented for the benefit of other users who might scroll by without noticing the absolutely ridiculous evidence you cited, and get trapped into taking your position at face value.

Bro, no way you’re not a troll. I clicked on the 2nd link to see what the source is. It’s a guy using copilot to calculate percentage of women smoking and drinking during pregnancy, as well as late abortions, then does completely arbitrary math to conclude that women are more violent. If I wrote a parody of a person abusing stats to prove stupid points I would never have managed to make it as ridiculous as this.

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

If I have wine on my system and try to run steam-managed proton without any sort of runtime or container, 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, so your statement is false to begin with.

Why are they doing a fork instead of contributing?

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. They cannot contribute the entirety of proton to wine because wine does not want all their contributions. This is a very common situation to arise when someone wants to use an open source project but their goals don’t align.

But I expect it will be easier to push back on using containerization in Proton, than making Valve allow us such control

Valve is never going to rip out a solution that is working great for them and risk causing issues for customers for no good reason. Thinking that Valve are more likely to remove containerization than they are to allow you to modify the container is, frankly, delusional. It’s also completely irrelevant, as I’ve already said. If Valve wants to “fuck us up” then they’re going to do it. Steam is a proprietary piece of software that supports DRM for all your (also proprietary) games, which are stored on the cloud. You have no control over your games, but containers have nothing to do with it. And if they did, and Valve really wanted to pull a trick on us, asking them to remove the containers would make even less sense…

Just follow the instructions here. Snapshots do not recursively traverse subvolumes. So putting the swapfile into its own subvolume means it will be excluded from any snapshots of / . The command should also set No_COW which also implicitly turns of compression if you use that.

I’ll repeat what another user said because it’s important. If you want filesystem encryption you also want swap encryption. Otherwise any data is liable to get leaked by being written to swap.

The issue is that even if you choose a hosting service outside the US, they might choose to block your content anyway in order to comply with US regulations and avoid legal trouble.

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

Which wine though?

The one pre-packaged by your distro? That doesn’t work because Valve needs to control the version you use and to provide additional stuff not part of vanilla wine.

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.

One of the core features of containers is process and process memory separation from host.

As far as container technology is concerned, the isolation is configurable. pressure-vessel is most likely using (possibly indirectly) namespaces and/or cgroups to achieve the isolation. 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.

According to the docs the runtime is based on flatpak and uses bubblewrap and libcapsule. I don’t know about libcapsule, but I recall that bubblewrap has granular control over what resources it isolates.

We have no control over what they put in those containers.

Apparently, you can modify the container as shown here. 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.

Once they disable the PRESSURE_VESSEL_SHELL=instead we will have no insight into what’s inside.

There already exists an alternative that is “more likely to be extended in future” rather than being removed as shown here. But 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.

and app developers neither have!

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.

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.

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.

Worst case scenario, Linux community will figure something out

No, they won’t. Compatibility significantly increased after Valve got involved. In fact, the linux community is porting pressure-vessel outside of Steam to use it across different launchers as umu. The community is headed towards using pressure-vessel for everything.

Now I replied to each claim individually, but it’s not really about any specific point you’re making. The general idea is that 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. Any control that you’ve lost over your system is because you’re using a proprietary app. 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. It’s not about what Steam does, but about how it does it.

And the most recent comment indicates that it’s not currently being worked on by someone.