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…

What I say is, that the current infrastructure and distributions doesn’t treat rustc+stdlib as its own thing, that nobody will target it and everyone assumes Cargo.

That’s just what you believe, not something you can prove. In fact, if anything, it’s easier to assume rustc is present than it is to assume cargo is present, because cargo needs rustc, but rustc does not need cargo… so if you really were looking for the most universal cross-distro assumption, then it would make more sense to assume rustc (which has to be installed to have cargo anyway) than to assume cargo.

I think the g++ comparison doesn’t hold here, because it’s not the only way of using the language.

I’m not sure what do you even mean by “use”… are you saying if I find a way to “use” rust without achlinux rust package then it’s ok for it to bundle cargo?

Well it needs to be a standard in most common distributions. No one wants to rely on something that is found in one distribution only.

A lot of things aren’t standard across distros. The way the 32bit variants of gcc are packaged between distros is also not a universal standard… do you think nobody wants to rely on it only because you need to check what name for the package corresponds to your distro?

How many distros do you need to follow the same approach to consider it “standard”?

Debian doing this means that essentially all apt-get based distros follow the same approach of separating rust and cargo (Ubuntu, Mint, and all the variations).

Also in Fedora / RHEL / AlmaLinux / Rocky Linux… “rust” contains rustc, cargo is split to its separate “cargo” subpackage.

Also Alpine Linux, cargo is a separate package from rust.

Void Linux, also cargo separate package from rust,

NixOS, has pkgs.rustc and pkgs.cargo as separate derivations.

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

As I said, there’s only a minority of cases where that’s possible and/or advisable.

Because there is no infrastructure supporting this. Why would anyone write Rustc only programs, if there is no such package and widespread availability?

Because people still need to write such programs for those minority use cases (and if there was no need, then they should not write them).

And rustc is in fact widely available. Whenever there’s need for no-dependencies “freestanding” software (which has a specific meaning, it’s not the same as your “self-confined”) or rust being on the side (ie. like Linux kernel), people have no problems to use rustc (if it fits their toolchain better). It being packaged together with cargo does not stop rust devs from using rustc when it’s appropriate to do so.

I find it hard to believe that you legitimately do think that the one thing stopping people from using rustc for these usecases is that archlinux happens to include cargo in the same “rust” package that provides rustc.

Did you know that there’s no g++ package in archlinux either? it’s bundled in the gcc package… do you think that means that there’s no widespread availability of g++ in Archlinux?

Debian does have a dedicated rustc package, is writting “rustc only programs” more widespread in Debian?

Ok, then we are back to what I said earlier, unlike python / c++, you are likely gonna need dependencies in rust. regex was just an example…

Perhaps you can manage without dependencies if you use rustc for very basic things or for pieces in an otherwise C project (like Linux), or maybe for some particular rare scenarios that require it being “freestanding”, but you’d be in the minority. If this was a significant usecase then we would indeed have a rustc package in archlinux… in the meantime you would need to homebrew yourself a rustc aur package if you really want to have rustc without having cargo.

Using Rust as some freestanding - side thing is not the common usecase, I don’t think adding a rustc package would make that usecase more popular. We do have a rustc package in Debian, I believe. And it’s not like having to install cargo in archlinux somehow makes it mandatory to use it.

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.

I think what that person is saying is that rustc can be used in the same way as gcc (so… through makefiles, cmake and other build methods), without depending on cargo’s registry and all the crate infrastructure (your Makefile did depend on the overall cargo “crate” ecosystem). They are saying you can use existing tools with Rust, integrating Rust into the ecosystem, as opposed to making a new tool and whole new ecosystem for Rust.

This kind of approach used with C has been working for many projects during a long time, why does it not scale well?

Are you trying to compare the Makefiles? because that was not a fair comparison.

The first one does not have the library dependencies and flags that you are wanting to use in the second one. I’d argue the first Makefile (the one for the C project) would be just as complex as the rust one if you were going to have it point to libraries under particular versioned folders set up by a third party dependency management tool (in this case, cargo… but you might as well have used nix or any other packager that uses versioned directories for its libraries).

Earlier you said that you can use cargo as a build tool without depending on its package system… but now your proposed Makefile is doing the opposite, you are depending on cargo’s package registry (/usr/share/cargo/registry) while trying to not use cargo… which of course it’s gonna be awkward and not what was being suggested.