At least in the case of sqlite, rusqlite pulled in 5 or so in total whereas Go had a single library that was a thin wrapper around sqlite, and integrated into the stdlib interface. Many fewer deps
Edit: counts are fair, that’s still hundreds unaccounted
This is probably going to sound generic / repetitive, but my biggest complaint about Rust is the package management situation, which is entirely the result of the developer mindset. I love the ergonomics on the rust side (the functional approach to data types is beautiful), but I’m working on two projects side by side, one in rust and one in go at the moment. The dependency trees are entirely different beasts, with most of the stuff on the go project covered by the stdlib whereas I think the rust project is over 400 despite asking for just rusqlite (sqlite), clap (cli), ratatui (tui), and tauri (gui), the last of which is by far the worst offender but even without it, it’s still close on 100 which is crazy. If there were (and maybe there are, I just haven’t found them) decently maintained alternatives to the rust crates that actually have a sane dependency approach, I’d feel much better. I’m just trying to not shai hulud my system, and the rust-web people seem to want to turn cargo into npm in that regard.
Built on meaning the technology is using Git under the hood, not that it is developed using git.
Edit:
Breaking down the “word salad”:
> Radicle is a peer-to-peer code collaboration platform (“forge”) built on Git.
Peer-to-peer: it functions with individual nodes on the network spreading state for tracking it without relying on a single entity or centralised service.
Code collaboration platform (forge): you use it not just to store code but provides a way to keep track of “patches” (their term for PRs) and issues, amongst other things, to enable multiple people to collaborate on a code base
Built on git: the technology runs on top of git insofar as not only is the VCS just git, but the issues, patches, etc are stored in git. So the project isn’t merely developed using git, but when running the tool yourself it’s still backing everything under git.
Since the exploit can be mitigated by simply blacklisting the AF_ALG module, why didn’t they release an advisory to disable the problematic module (which AFAIU is hardly used), and then only later, say after a week, release the patch for it? At least then you would have the immediate ability for a mitigation without giving away exactly how to exploit the bug.
Not by default but tools like agent-sandbox.nix (bwrap, seccomp) or other nixpak (just bwrap but more popular) can provide those capabilities if you want in a fairly simple interface
That’s fair, NixOS avoids the direct stuff from Docker itself but if you’re basing on an Alpine image or something that would probably be more minimal / smaller