205
systemd Officially Adds Rust Support for New Components (linuxiac.com)
submitted 3 days ago by to c/linux@lemmy.ml
94 comments fedilink hide all child comments
 

EEE

The systemd project has officially introduced support for developing programs in Rust, following the merger of a pull request submitted by Linux kernel developer Christian Brauner. The change, merged into the project’s main branch, establishes a new development option for systemd while keeping its existing C-based architecture intact.

And before anyone assumes systemd is preparing a complete rewrite in Rust, that’s not the case. The maintainers agreed on a deliberately limited approach: Rust may be used only for new, standalone components that other parts of systemd do not depend on. Existing C code will remain untouched.

Another important decision concerns the build process. Rather than introducing Cargo, Rust’s standard package manager and build tool, systemd continues to use Meson for all builds. This keeps Rust development integrated into the project’s existing build infrastructure.

The implementation also places strict limits on dependencies. Rust programs use the no_std approach, meaning they do not rely on Rust’s standard library or external third-party crates. Instead, they interact with systemd’s existing C libraries through generated bindings.

For memory management, systemd provides its own Rust implementations of common container types, with allocation failures handled explicitly rather than causing the program to abort. The new infrastructure also includes wrappers for logging, command-line argument handling, event processing, and error management, allowing Rust utilities to behave consistently with their C counterparts.

Rust support is optional and automatically detected during configuration. Developers wishing to enable it need Rust 1.85 or later, bindgen 0.71.1 or later, and Meson 1.4 or later. Systems without the required toolchain can continue building systemd without Rust support.

Interestingly, initial tests show that a stripped Rust command-line utility occupies about 32 KB, compared to 20 KB for its C equivalent built with link-time optimization. This gives an early indication of the additional overhead, though the comparison involves only a small test program.

The first planned real-world application of this infrastructure is systemd-keyring-setup, a new utility intended to help manage certificates in Linux kernel keyrings. Its implementation is being developed separately, alongside additional Rust wrappers for systemd’s shared libraries.

For Linux distributions, the change introduces packaging considerations. Builds that enable all available features will need the appropriate Rust compiler and bindgen dependencies or must disable Rust support to avoid build failures.

Whether Rust becomes widely used within systemd will depend on future development, but the necessary groundwork is now in place.

you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 3 days ago* (47 children)

yes, but to manually build packages against libraries yourself would be a nightmare of tooling without cargo.

It's no different than every base-devel and similar package requiring cmake because sure, you could manually run the c/c++ compilers and linkers yourself against every single file, passing in the flags yourself, but that would take an obscene amount of time to manually build and run every compiler command yourself

https://wiki.debian.org/Rust

Debian builds it's own local cargo registry by default. If your distro provides "pinned versions" like I said, you won't need rustup, but you'll still need cargo to do anything beyond a tiny project with no imports, unless you plan on writing async/http/encryption libraries all yourself.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 47 child comments
    •
  • [–] 2 points 3 days ago (46 children)

    It would be similar to how we build C with make or any other language, using a Makefile in example. In example if the project contains all dependencies in the Git repository already and does not need to download extra dependencies. The Makefile and configuration would handle all of that. Or for projects that do not require dependencies, it would be quite simple compiling.

    Debian uses cargo, which is what I would avoid. Cargo is a package manager, that is the exact thing I'm trying to avoid here with the suggestion. I think of dependencies integrated into the system package manager (pacman in example). Debian needs to do this cargo registry, because there is no other infastructure.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 46 child comments
    •
  • [–] 0 points 3 days ago (45 children)

    Cargo combines the features of a package manager with a build system. You can just used the build system without touching the package manager, which is what Debian and other distros do. But I mean sure, for C there's make cmake automake ninja meson so why not make another for rust

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 45 child comments
    •
  • [–] 2 points 2 days ago (2 children)

    CMake also supports building Rust! And guess what, systemd is not using Cargo. All of the new Rust code will be ![no_std], and use the existing Meson build system.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 days ago* (last edited 22 hours ago) (1 child)

    Right, it totally makes sense to use your existing build system if your project is a mature C/C++ project, and especially if your project is something like systemd, which is the backbone of the vast majority of linux installations. That's a special case, I would argue, whereas 1% of rust programs that import any external code can’t be built out of the box with cmake/ninja/meson and 99% of them rely on cargo and likely a build.rs.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] -2 points 3 days ago (41 children)

    Nobody is talking about making another make tool for Rust.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 41 child comments
    •
  • [–] 0 points 2 days ago* (40 children)

    ok a makefile is basically a script runner like this. the c/c++ compiler doesn't touch the makefile, that's a separate tool

    edit : main.o kbd.o command.o display.o \
       insert.o search.o files.o utils.o
        cc -o edit main.o kbd.o command.o display.o \
                   insert.o search.o files.o utils.o

main.o : main.c defs.h
        cc -c main.c
kbd.o : kbd.c defs.h command.h
        cc -c kbd.c
command.o : command.c defs.h command.h
        cc -c command.c
display.o : display.c defs.h buffer.h
        cc -c display.c
insert.o : insert.c defs.h buffer.h
        cc -c insert.c
search.o : search.c defs.h buffer.h
        cc -c search.c
files.o : files.c defs.h buffer.h command.h
        cc -c files.c
utils.o : utils.c defs.h
        cc -c utils.c
clean :
        rm edit main.o kbd.o command.o display.o \
           insert.o search.o files.o utils.o

    for a rust program, you might have a cargo.toml like

    [package]
name = "jsontool"
version = "0.1.0"
edition = "2021"

[dependencies]
anyhow = "1"
clap = { version = "4", features = ["derive"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"

[profile.release]
lto = true```

and .cargo/config.toml like (for the local distro config, no internet packages)

    [source.crates-io] replace-with = "distro"

    [source.distro] directory = "/usr/share/cargo/registry" # or: registry = "sparse+https://crates.internal.example/index/"

    [net] offline = true

    
If you wanted that same functionality from a makefile for rust it would be something like

    Makefile: build jsontool with plain rustc, no cargo.

    RUSTC ?= rustc REG := /usr/share/cargo/registry OUT := $(abspath build) HOST := $(shell $(RUSTC) -vV | sed -n 's/^host: //p') FLAGS := -C opt-level=3 --cap-lints=allow -L dependency=$(OUT) --out-dir $(OUT) ext = $(foreach c,$(1),--extern $(c)=$(OUT)/lib$(c).rlib) extpm = $(foreach c,$(1),--extern $(c)=$(OUT)/lib$(c).so)

    Pinned by hand. Cargo.lock does this for you; here, a distro upgrade

    renames these directories and the build breaks.

    UNICODE_IDENT := $(REG)/unicode-ident-1.0.13 PROC_MACRO2 := $(REG)/proc-macro2-1.0.89 QUOTE := $(REG)/quote-1.0.37 SYN := $(REG)/syn-2.0.85 SERDE_DERIVE := $(REG)/serde_derive-1.0.213

    ... ~20 more ...

    ---- 1. Plain library crate ----

    Edition, crate name (hyphens -> underscores), and features all come from

    reading each crate's Cargo.toml yourself.

    $(OUT)/libunicode_ident.rlib: $(RUSTC) --edition=2018 --crate-type=lib --crate-name unicode_ident
    $(FLAGS) $(UNICODE_IDENT)/src/lib.rs

    ---- 2. Crate with a build.rs: compile it, run it with the env vars cargo

    would set, then scrape its stdout for cfg flags ----

    $(OUT)/proc_macro2.cfg: mkdir -p $(OUT)/bs-pm2 $(RUSTC) --edition=2021 --crate-type=bin $(PROC_MACRO2)/build.rs
    -o $(OUT)/bs-pm2/build-script cd $(PROC_MACRO2) && env OUT_DIR=$(OUT)/bs-pm2 RUSTC=$(RUSTC)
    TARGET=$(HOST) HOST=$(HOST) PROFILE=release OPT_LEVEL=3
    CARGO_MANIFEST_DIR=$(PROC_MACRO2) CARGO_PKG_VERSION=1.0.89
    CARGO_FEATURE_DEFAULT=1 CARGO_FEATURE_PROC_MACRO=1
    CARGO_CFG_TARGET_OS=linux CARGO_CFG_TARGET_ARCH=x86_64
    $(OUT)/bs-pm2/build-script
    | sed -n 's/^cargo::?rustc-cfg=(.*)/--cfg=\1/p' > $@

    $(OUT)/libproc_macro2.rlib: $(OUT)/proc_macro2.cfg $(OUT)/libunicode_ident.rlib $(RUSTC) --edition=2021 --crate-type=lib --crate-name proc_macro2 $(FLAGS)
    --cfg 'feature="default"' --cfg 'feature="proc-macro"'
    $$(cat $<) $(call ext,unicode_ident) $(PROC_MACRO2)/src/lib.rs

    ---- 3. Proc-macro crate: different crate type, must be built for the

    HOST (matters when cross-compiling), linked as a .so ----

    syn's feature list must be the UNION of what serde_derive AND clap_derive

    need. Cargo computes this (feature unification); here you work it out by hand.

    $(OUT)/libserde_derive.so: $(OUT)/libproc_macro2.rlib $(OUT)/libquote.rlib $(OUT)/libsyn.rlib $(RUSTC) --edition=2015 --crate-type=proc-macro --crate-name serde_derive
    $(FLAGS) --cfg 'feature="default"'
    $(call ext,proc_macro2 quote syn) $(SERDE_DERIVE)/src/lib.rs

    ... ~20 more rules like the above (serde, serde_json, anyhow, and

    clap_* each have their own quirks, and several have build.rs) ...

    ---- Finally, your program ----

    clap's derive expands to env!("CARGO_PKG_VERSION"), so you fake cargo's env.

    Source files are listed by hand (or you wire up --emit=dep-info .d files).

    build/jsontool: src/main.rs src/cli.rs src/convert.rs $(ALL_DEPS) CARGO_PKG_NAME=jsontool CARGO_PKG_VERSION=0.1.0
    $(RUSTC) --edition=2021 --crate-type=bin --crate-name jsontool $(FLAGS)
    $(call ext,anyhow clap serde serde_json) src/main.rs

    Still to write: test (rustc --test + every --extern again), doc-tests

    (rustdoc --test), debug vs release flags, clean, install...

    
So are you proposing GNU style makefiles for rust then? You say not another tool, just use the compiler. Either you type those commands yourself, you type them into a make style build script, or cargo or **another tool** automates them.
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 40 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (2 children)

    The commenter above me is proposing to build rust projects without cargo, and mentioning make files (but also saying no other build tools so idk). I'm proposing why that doesn't scale well, and why cargo would be the best choice

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (1 child)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 days ago

    My makefile uses cargo by ripping out the cargo build information from upstream dependencies to manually run, as projects like reqwest and tokio use cargo. My demonstration was that you still would use cargo the build system rather than cargo the package manager (implying upstream registries like crates.io) over a makefile. And yes, you can use existing tools. As mentioned, systemd uses meson, though they need a python hack to get rustc working because it wasn't working on meson upstream until 5 days ago. So yes, you can use existing tools. And as I said in another comment, for a mature project built in C, it makes sense to frankenbuild rust into the build system. But their example was purely about rust projects, I brought up makefiles to demonstrate how you can't just slap a makefile into a rust project and it works

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 2 days ago (35 children)

    No, I am not talking about the same functionality and without using cargo. I am talking about using rustc to compile individual Rust programs.

    $ ls -1
hello.rs
main.rs

    main.rs:

    mod hello;

fn main() {
    hello::print_hello();
}

    hello.rs:

    pub fn print_hello() {
    println!("Hello World!");
}

    $ rustc --target helloworld main.rs
$ ./helloworld
Hello World!

    No Cargo, no toml, no registry.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 35 child comments
    •
  • [–] 2 points 2 days ago (1 child)

    At this point I believe you must be trolling. Yes, you don't need cargo to compile a hello world program, thank you.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 days ago* (32 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 32 child comments
    •
  • [–] 1 point 2 days ago* (31 children)

    What does nobody mean here? We are doing this for ages in C in example. A Makefile can help automate this process. Download git project and run make without any Cargo or regristry or other requirements. Don't talk about everyone, just because you are not doing it.

    Also the shown example is a single rustc command that will automatically compile and link all associated (with the dependency in the files) and produce a single output.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 31 child comments
    •
  • [–] 1 point 2 days ago* (30 children)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 30 child comments
    •
  • [–] 1 point 2 days ago

    “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?

    That's the point. We don't have default rustc on all machines and repositories. In example in Archlinux repositories there is not package rustc only and its standard libraries to install. That's why most people don't do it. You can't fault the missing projects are missing, because the infrastructure is not there yet.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 days ago (28 children)

    But that was not MY point at all. My point is to avoid Cargo, the registry and external dependencies from cratesio. The makefile just uses standard Linux make command. It was just an example to automate this (it could have been a simple Bash script too), but the point is it can be done manually. In this example and even in more useful ones, it can be just a simple rustc invocation.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 28 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (27 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 27 child comments
    •
  • [–] 1 point 2 days ago (26 children)

    I think one of the reasons why this is not done is because Rust deliberately pushes away from relying on precompiled binaries.

    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.

    My suggestion is not to download and use the libraries from third party repositories. The idea is to have all libraries in the repository of the project itself (such as Git) or the standard library in the package manager, matching the rustc compiler that is also packaged there. In example if Debian would include such packages, then this would become quasi industry standard version everyone can target. Basically the same thing that happens with Python in example. So it stays ABI compatible.

    I am not suggesting for full cargo replacement, and suggest not to depend on the registry of those. And I actually believe we will get to that point at some point when gccrs is ready (GNU Compiler Collection including Rust).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 26 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (25 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 25 child comments
    •
  • [–] 1 point 2 days ago (24 children)

    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

    That's exactly what is to be avoided. I'm not suggesting a dependency heavy program to compile. Someone making a program without Cargo wouldn't probably make lot of dependencies, and if any, they are all included in its own repository.

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

    I thought you was talking about user programs. About the libraries, that's what I'm suggesting to include too, alongside with the correct rustc compiler. Maybe even the version which the Linux developers use, so that would be the standard one everyone can target.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 24 child comments
    •
  • [–] 1 point 2 days ago* (23 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 23 child comments
    •
  • [–] 1 point 2 days ago* (22 children)

    But that is the suggestion here, to not rely on many dependencies. And currently this is an odd thing to do in Rust, because there is no other support or eco system to support this kind of building. Yes, if you want rely on many dependencies and crates io, then it makes no sense to go that route I suggest.

    But this would only work widespread if distributions would adopt this kind of packaging and providing a stable environment. Imagine Python wasn't installed by default on Linux, how would anyone think of relying on it? I know it's technically not the same thing, but I'm making a comparison for having it in the distributions repository (or installed by default), not how the language works.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 22 child comments
    •
  • [–] 1 point 2 days ago* (21 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 21 child comments
    •
  • [–] 1 point 2 days ago (20 children)

    Exactly and that's one of the advantages to not rely on dependencies. Not every application need those packages. Otherwise they would be included in the standard library. This would encourage people to build software that is self confined, even if it is harder to do. And not every type of tool needs to be this, this is only meant for projects where it makes sense.

    You guys need to stop thinking that I'm suggesting a complete replacement of cargo and crates io. It doesn't need to be one or the other, we can have both solutions and choose which ever works best for the project or you.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 20 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (19 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 19 child comments
    •
  • [–] 1 point 2 days ago (18 children)

    "self-confined" I think my weak English showed up again. I mean projects that has all dependencies in the project itself. And don't get me wrong, I'm not suggesting to write Regex Parser, GUI system and other huge tasks and put them in the project. If you need those, then its better to use the libraries that are available, with Cargo.

    Not every program needs all those dependencies and features. Also relying on those dependencies, that rely on other dependencies and so on can also be a security nightmare. My point is to have those projects that are much more simple, maybe even part of other projects like Python (just a random idea, don't over analyze that).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 18 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (17 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 17 child comments
    •
  • [–] 1 point 2 days ago (4 children)

    You don’t get any of that when you vendor, and you’ll have to manually actively monitor your dependencies for vulnerabilities anyway.

    Incorrect. Vendoring done right (via replace-with, as done by cargo vendor) is not mutually exclusive with the rest of the tooling. You can have both.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 2 days ago (3 children)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 0 points 1 day ago (2 children)

    And both are still not mutually exclusive. Just like how in C or C++ projects you can both use a proper build system, and still have Makefile(s) around (as fallback, or used as simple runners, or also for tooling reasons).

    Putting vendoring aside, using and not using cargo is itself not an either or. Some projects that incorporate Rust as a non-primary language can still use their own build system, and yet still optionally have cargo around for tooling reasons (e.g. to make LSP just work without much hassle), both at the same time. See this demo for an example (meson for actual building, cargo for tooling/development).

    I also have no idea why you exchanged this long with a person who clearly lacks basic knowledge. But maybe I grew more abrasive and less patient than the average person with my greying hair.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 day ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 day ago

    Yeah sure.

    The problem with those people is that they don't actually know how any software is really built. Even in their simple "Makefile" supposed utopia, tools like pkg-config, just to name one example, could be running from behind their backs, and they wouldn't know what that is, that it's getting executed, and what purpose is it serving in the build process.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 days ago (11 children)

    That's true if you try to replicate the same program without Cargo. But that's not what I am suggesting. If you don't need regex and all the dependencies, then you don't need Cargo. And this could encourage to write programs without all these dependencies. Also Cargo is deeply integrated into Rust, but Rust is not deeply integrated (speak no dependency) to Cargo. I know of all the features and why Cargo is fantastic, I love it myself.

    But one has nothing to do with the other. My suggestion is for tools and code that doesn't need these dependencies. I am not suggesting to replicate the same work or features as when doing huge applications with Cargo and dependencies. We can write programs with stdlib only, hell even without stdlib (technically, I'm not suggesting this as the new normal).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (10 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 1 point 2 days ago* (9 children)

    you are likely gonna need dependencies in rust. regex was just an example…

    As I said, not if you don't need dependencies.

    Using Rust as some freestanding - side thing is not the common usecase

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (8 children)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 1 point 2 days ago (7 children)

    I'm not saying it stops people from using rustc only. I think there is a huge misunderstanding here. Currently, its just highly specialized use cases where they have to use rustc only without even the standard library (I think the Linux Kernel doesn't use the stdlib). 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.

    In example there is no rustc+stdlib compiler as a package by distributions. This should be a standard package by all distributions in my opinion, just like we have C compilers doing the most basic thing. From packaging standpoint. This would encourage people to do such projects, as if you just require basic tools that are not always installed, but can be assumed to easily install. It also should have less dependencies than Cargo and rustfmt in example, or even rustup.

    I think the g++ comparison doesn't hold here, because it's not the only way of using the language. Rust on the other hand has only one other way of doing this, it's the dependency heavy and full package with cargo and the rest, even usually downloading dependencies and and so on. It's a full package manager. If g++ was the only alternative to such a system, I think it would have more widespread adoption.

    Debian does have a rustc package, is using rustc directly more widespread in Debian?

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (6 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 2 days ago (5 children)

    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

    No. Because if there was rustc+stdlib as a package to install, then we could make the argument. But if Cargo is the only package available with rustc, then there is no point in making this argument. In most distributions there aren't rustc+stdlib only package.

    then it would make more sense to assume rustc (which has to be installed to have cargo anyway)

    The point is, not having Cargo and all the other rest of the systems to install when installing rustc. Sorry, but am I talking Chinese? (and yes, I get impatient.)

    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 that…

    I explained it following that quote. I'm trying. You bring g++ as an argument why its not widespread adopted. Because g++ is not the only alternative to something like a package manager like Cargo. Nobody "needs" g++. There are many ways of compiling Cpp, even without using a package manager. So nobody has to use g++ to avoid something like Cargo and all the other stuff.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (4 children)

    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...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 2 days ago (3 children)

    It's not about the popularity...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 2 days ago* (2 children)

    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).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 days ago (1 child)

    What? I'm actually saying the opposite, not that nobody wants to do it. Otherwise why would I suggest it. I am saying its not widespread adopted, and you cannot expect OTHERS to have rustc+stdlib to be installed on the system, like a standard Linux tool. People use it for their specific use cases, like Linux, but its not something you can expect on other machines.

    Imagine rustc+stdlibs were available by default like Python, ideally installed on default. Maybe not installed on default, depending on the system you are, but everyone should expect this package with the stdlib on be available.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 days ago* (last edited 1 day ago)

    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.

  • permalink
  • fedilink
  • source
  • parent