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.

True. But you still need to configure cargo there, the vendoring he’s talking about is one where cargo is not used.

Ok, that’s vendoring.

So for example, Rust regex crate also tries to prevent duplicating efforts so it also has its own dependencies (like “memchr”, some library for fast dictionary matching, some regex-* modules it’s split into, etc)… Rust packages are very modular with the goal of keeping very simply reusable pieces, and this is what makes something like cargo necessary. If you want to vendor regex by including it into your code, you also need to include those tiny modules.

You are right having big dependency trees has risks, but I’d argue that avoiding a dedicated package manager that helps you manage those risks makes that security nightmare worse.

Cargo generates a Cargo.lock file that guarantees the version you want will be used, but it also allows devs to run cargo audit, to scan the dependencies against a live database of vulnerabilities. You don’t get any of that when you vendor, and you’ll have to manually actively monitor your dependencies for vulnerabilities anyway. It’s not like including the code of the dependencies in your repo makes the problem go away.

The reason they are not included is not to prevent including them when not needed (the Rust compiler makes a good job at cleaning up dead code, so even if they were part of the standard library, they would not be in the binary anyway), but because it allows iterating, optimizing, and patching security flaws in those libraries much faster than the release cycle of the compiler itself.

And yeah, that’s also what cargo’s goal is, only pull what you need in your dependency graph. But what do you mean by self-confined? I hope you don’t mean writing everything from scratch because not only would that be duplicating efforts but it also can potentially lead to security gaps…

If by “self-confined” you mean “vendoring”, then that does not necessarily mean you have fewer dependencies, it just means you commit the raw source code of your entire dependency tree directly into your own Git repository instead of fetching it from crates.io during the build. I don’t think you get much benefit from doing that manually, and it just adds maintenance burden.

Unlike Python or C++, Rust’s standard library is intentionally kept tiny. It does not include regular expressions, random number generation, JSON parsing, or an HTTP client.

To do modern programming tasks the way you can with Python, you will most likely have to use external libraries. Choosing not to rely on dependencies in Rust doesn’t make your project simpler, it just forces you to write more things from scratch.

ABI-compatibility is only relevant when we talk about binary libraries… if I were talking about user programs then it would be the API what matters, not the ABI.

“a lot” of dependencies is a fuzzy line to cross… most projects start small, then as they grow big they might modularize, attempt to de-duplicate efforts, etc. So I feel for big Rust projects you’d end up essentially duplicating what cargo is already designed to handle.

As I said before: your approach might work if you just want to use some Rust included in a C project (like the kernel is doing)… or if your Rust project is small and does not have many dependencies… but the moment you start relying in more and more components and the dependency tree grows enough, it’ll become hard to manage.

Rust? You mean the developers of Rust? That’s not a decision to make by them. Also the Linux distributions include many precompiled binaries. So I don’t see what this point is.

I’m talking about the compiler. ABI compatibility is a non-goal in the compiler itself. You’d need to make a new version of rustc that somehow manages to handle generics/templates in an ABI-compatible way and handles optimizations with more care.

What distribution includes precompiled libraries (not user programs) in Rust?

If you install a C library like libcurl via apt install, you get a precompiled .so file. If you install a Rust library like librust-serde-dev via Debian’s package manager, you do not get a precompiled binary. If you inspect that package, it is literally just a zip file of raw .rs source code that gets dumped into /usr/share/cargo/registry/.

Putting all libraries into the git repo or using OS package managers to essentially maintain a registry just like cargo’s can work… but it’s duplicated effort in keeping everything well managed, updated, and free of vulnerabilities.

If you use your distro’s package manager, depending on which one you use, it might not offer as much flexibility (like how if you need 2 different versions of the same library in Debian, you’ll need workarounds if the maintainers have not created separate versions for it) or be as build-aware as an integrated build tool would. Some libraries might only need a particular dependency when a particular feature flag is enabled… a package manager most likely would have to download all dependencies of every library you want to use since it does not know what build options you are gonna use when you install the package.

I think one of the reasons why this is not done is because Rust deliberately works against using precompiled dependencies.

Unlike traditional C compilers, for the Rust compiler trying to keep ABI compatibility is a non-goal… the Rust compiler retains the freedom to aggressively optimize how data is laid out in memory and how functions are called. Binaries generated by one version (or particular settings) might not work in the next… making it much harder to work the way we work with C libraries.

This means managing dependencies between rust libraries is a lot more involved… since you are essentially recompiling the library along with your project, so you need a way to download, not just the library headers as you would with C, but its entire sourcecode.

So your approach might work if you just want to use a little bit of Rust included in a C project… or if your Rust project is small and does not have many dependencies… but the moment you start relying in more and more components and the dependency tree grows enough, it’ll become hard to manage.

If you use a Makefile, then you are not doing it manually, you are using a tool to automate it. I think that was the point.

“nobody” means: those who have big projects with multiple .rs files but no Makefile, no cargo.toml, no build.sh, nothing, only the .rs files. Can you point to a project that does that?

Nobody is gonna manually compile each .rs file one by one and link it… unless you really are specifically talking about 1 file simple projects like a helloworld, you’d want to use another tool (like make or cargo), to automate it.