Pretty funny to reference anti-open-source reddit in a privacy community

This kind of immutable distros require a very specific partitioning scheme. I tried a couple years ago trying to match the requirements while preserving/reusing my other volumes but it was too finicky and the installation kept failing. I ended up just installing it on its own in a different device that is more fit for purpose (a small PC plugged to my TV). It works great for that use case, but it's not worth experimenting with it beyond that, imho.

Staff criticized a very specific thing, not a vibe: the approach for installing software.

You don't really need to use the terminal at all if you just stick with the software that's available in flatpak / bazaar. If you had to use the terminal then that means you most likely wanted to install software / tweak stuff outside of the intended channels.

I don't think Bazzite is very suitable as an all-purpose distro or a distro for people who want to tweak or use the terminal much, it was originally designed as a SteamOS distro (before Valve made available their own SteamOS image), intended to be installed in Steam Deck / Steam Box style devices. I use it in a living room PC for gaming and watching videos and it works perfectly for this usecase. For desktop / laptop I run a different Linux distro.

Were you using an AMD graphic card with HDMI 2.1 connection to a monitor/TV?

Because it happened to me that the HDMI connection stopped working after a Bazzite update, and I had to downgrade to Bazzite 44.20260802 (see the Github ticket here), which seems to be the last stable release without the problem.

My understanding is that the problem is still present in Bazzite 45.. and it likely won't be resolved until the next Kernel update (7.3.1) lands. The good news is that it just recently was updated on the unstable branch.. I haven't tested but if the issue is fixed there, I'm hopping it will be ready by the end of this month, since they normally roll updates every few weeks.

Well, it's still early, so we won't know yet how friendly, robust / stable and compatible it will be. I expect not every program will work regardless of whether you have installed the right version of the libraries or not. In the tests they are doing they say VLC for example is not starting up.

I also think that the stats showing it running better than Wine might be a bit premature too.. it's not impossible for the performance to get worse when more gets implemented in order to have wider support. But we'll see, maybe it does result in a better approach.

You still need to run the exe through raven. Though you can do that (and it's also possible with wine already) by having the runner assotiated with exe files in your file browser. Normally with wine it's already the case that you can double click on the exe from there and have it launch.

When they say "run directly in the CPU" what they mean is that it's not a VM.. but this was already true of wine too.

My understanding is that they are replacing the windows kernel (with help of ReactOS code) and asking you to install official Microsoft libraries into a separate runtime environment.. so it's similar to a VM in the sense that it's running a different kernel with its own runtime, but at the same time not a VM because it's not emulating the hardware level.. it's a lower level than wine but a higher level than a VM.

I feel this can potentially be more of a moving target (since it depends on Microsoft not changing the lower level ABI used in future versions of the libraries) and less legally-safe (you need to agree to MS terms when you install their libraries.. at any time they can change them and say you cannot do this).

Wine instead implements higher level APIs, which MS is incentivized to keep stable, since changes at that level would also break compatibility with programs (and in some cases, Wine's API is actually more compatible with Windows software than modern versions of Windows that have dropped older APIs).

Plus.. it necessarily relies in closed source software (the MS libraries) to run.. so I'd argue it's less free than wine.

It's still unclear where the "Raven’s guest components or libraries" come from.. which I think it's the question that was being asked (given that wine is a reimplementation of the Windows components).

EDIT: apparently they are using ReactOS implementation of the Windows kernel & system libraries to translate the system calls, and beyond that they use the official Microsoft libraries that need to be installed inside the Raven runtime, like you would install in ReactOS.

EDIT2: Also apparently there's some controversy going on because ReactOS is GPL but Raven is getting distributed as MIT, so there's a bit of a mix of licenses which opened a bit of a debate.

handwaving away the same argument against Linux or Wayland

Honestly, I would be happy if there was a mature implementation that was practical to use and was more modular for these too. I'd argue Wayland is much better than X11 in this respect, since the Wayland protocol is much more minimalistic in its design, so I think a big reason why X was superseded was the need for removing things that had been needlessly integrated in the X server and added technical debt.

If there had been usable and working alternatives that were less monolithic at the time those were launched, and people were actually using them but had to switch due to the pressure of other bigger projects.. then I'm sure there would have been criticisms too.

Imagine if someone came and proposed "graphicd", a service that combines not just compositor & display manager but also management of priviledges (like polkit), GUI toolkit (like a Gtk/Qt replacement), password manager, terminal emulator, filebrowser, web-browser and any program that might benefit from tight integration with the GUI environment. And it used protocols and methods that are entirely incompatible with Gnome, KDE or other more modular desktop environments, but the API/ABI is so big and fast moving that it's very hard for alternative apps to integrate well with the core of graphicd (the external API on the components is stable, but not the API between the components and the core). Then it started becoming the default everywhere, with some programs adding its specific components (and along with them, the graphicd core) as a dependency.

Filesystem mounting can depend on network availability for example

This is one of my pet peeves with systemd.. I've multiple times tried to use mount units (the "systemd-native" way) but I often have always ended up just relying on either the older /etc/fstab configuration conventions or layers like gvfs and custom scripts (through the init.d-like rc.local compatibility service..) because when writting systemd units to mount conditionally remote drives that might or might not be available they sometimes (not even reproducibly) led to problems in one way or another (like sometimes slowing down my boot or even my shutdown).

The issue is that systemd is considerably more opaque and complex.. so it's hard to tell whether something is a bug in the software, an intentional behavior / quirk, something specific to particular circumstances/cases or an issue in your configuration.

And I'm not saying all of what systemd did is bad, it has advantages.. but acting as if it doesn't have problems that could be smoothed out with a different approach would not be right either.. it's not like it's impossible to do what you are stating in a modular way, for a long time before systemd was a thing we had syslog implementations (like rsyslog) that handled structured, secure remote logging across networks without needing a monolithic init system to dictate how logging architecture should work.

You are agreeing with me. I didn't mean they were mutually exclusive. What I said is that avoiding a dedicated tool like cargo that helps you manage those risks makes the security issues worse.

You literally said "nobody will target it and everyone assumes Cargo.".

We know that there's people who target it.. so the only way I can interpret "nobody will target it" is that you are saying that people are generally not interested in using rustc on itself because cargo is there.

And yet, what I'm saying is that there's people that are actually interested still in doing that, and they actually do it, regardless of whether cargo is there or not. Cargo being there is not an obstacle for them.

Sure, those people might be a minority, but you said that it's not about popularity.. so what is it about?

Imagine rustc+stdlibs were available by default like Python, ideally installed on default

Even gcc is not preinstalled in most distros. The reason python is preinstalled is because it's an interpreter, so it's required at runtime, you need it to run the programs. If python was a compiler then it wouldn't be preinstalled by default since the end users wouldn't need it.

And that's completely unrelated to cargo.. one could argue that there's just as much reason to include cargo preinstalled too if you were to pre-install rustc.

Maybe the problem is that you think that rustc is an interpreter? it's not, it's a compiler, you don't need others to have rustc, they can run programs made with rust without needing to have rust installed in their system (it's not something you "target" in that sense). That's not the case for python, so that's why python comes already installed, specially given that many distros depend on python for some config tools.

You also said earlier that it's not about it stopping anyone from using rustc only.

So honestly, I don't understand what is the problem. People can (and do) use rustc without cargo, and make projects with zero dependency.. so I don't get why you say that "nobody" would want to do that. There's people doing it. Like the Linux devs.

The only thing I can think of is that you think that "most" people don't want to do that.. but then that would mean you are talking about popularity (ie. what the mainstream people do, what is the most widespread).

But if Cargo is the only package available with rustc

The package is actually called "rust", not Cargo, "rust" is the only package available with rustc (and cargo): https://archlinux.org/packages/extra/x86_64/rust/files/

Then we can't make the argument

I absolutely can make the argument I made. The argument I made was that you need to have rustc to use cargo, because cargo uses rustc, and this means that assuming rustc exists is a lot safer than assuming that cargo exists... because if cargo is installed then it follows that rustc must be installed too. And this is true in all distros, not specific to Archlinux, which is why it's a more universal distro-wide assumption.

If rustc is not installed, cargo will give an error when trying to compile rust. So one can assume that rustc is there whenever cargo is there. But you can't say the same thing the other way around, not everywhere.

There are many ways of compiling Cpp, even without using a package manager

You can also have rustc without using a package manager. Some places also recommend installing rustup instead of rust through the package manager. Cargo is the officially recommended manager for rust packages, so naturally is very popular. I still don't think the packaging in archlinux should be attributed the merit of the popularity of cargo for rust development...