BB_C, bb_c@programming.dev

I will let you expand on this before responding to both:

And also, cargo.toml has inconsistencies and double-standards.

Not cargo per se, but even the tutorial for a cli-tool is like “setup clap, which has 20 dependencies and a kitchen sink”. The whole (cargo-centric) ecosystem is much like Node, with the same problems.

cargo new with-clap
cd with-clap
cargo add clap --no-default-features

% cargo tree
with-clap v0.1.0 (/tmp/with-clap)
└── clap v4.6.0
    └── clap_builder v4.6.0
        ├── anstyle v1.0.14
        └── clap_lex v1.1.0

And also, cargo.toml has inconsistencies and double-standards.

Can you expand on that?

Why do you think cargo is a problem?

Not sure how are you and @kibiz0r@midwest.social coming up with these concerns.

The only correct way to package such software is to vendor dependencies (packaged together or separately). And you can trivially change the sonames of vendored deps in your build scripts so that there are no conflicts whatsoever (I dual-package some stuff against an upstream and a fork and do just that). So dynamic vs. static is not the crux of the issue. The primary concerns are that distributors hate vendoring, irrespective of whether the vendored libs are linked in statically or dynamically. Distributors also hate potentially diverging forks maintained by random downstreams, which is what "patched dependencies" effectively are.

There is always room for some leeway of course, but that would depend on how relevant your software is, and/or whether a maintainer would want to take that burden on.

And finally, sometimes, such dependencies may provide added value that trumps all these concerns. So judging these things is always situational.

Then you could be forced to vendor everything. And if it’s open-source and relevant for distros to pickup, then you will need to find out if distros would be willing to take your library with its vendored libs (or package them separately just for your library)…etc.

And you may need to figure out if there are bus factor concerns with your direct dependency, since such libraries are not necessarily maintenance free, even from a mere compiling/building stand point (what if a patched indirect dependency no longer builds with new compilers…etc).

This would depend on the language/ecosystem. It’s worse for C and C++ than for example Rust because of packaging policies and ease of distributability.

how many real-world attacks happened since the XZ fiasco outside of the webshit ecosystem?

Off-topic: The switching between light background for text and dark background for code is stupid and annoying. Either use dark for both, or light for both (so I can apply my custom inverse shader without hurting my eyes or breaking the reading flow). This back and forth switching is almost as stupid as using a background color with middle lightness, which I’ve also seen.

This has been irking me for a while, so I decided to randomly whine about it now.

As for the blog content. It’s a weird collection of clippy bugs which covers basically the first half of the blog, then a couple of miri bugs and limitations. Then it finally gets to actual rust compiler stuff which just involves cfg_select (a nice to have) and c_variadic support (ffi use-case). So, IMHO, that title is a bit over the top, and it almost does a disservice to a lot of actual good and interesting work that is being done.

(I guess zsh, dash and probably oil?)

zsh doesn’t even share var eval syntax with bash (${(P)foo} vs. ${!foo})

Maybe I missed it, but you don’t seem to mention anywhere sub-file sync (binary diffing) support (or presumably the lack of it), which is very important for fast syncing when files actually change!

Ask the real poster/dev in one of the lemmy.ml communities.

Only skimmed quickly.

• Four different hex representations for the same 3 bytes is extremely wasteful. You don’t need to store more than a [u8; 3]. You can create a “mapped” struct with those representations if caching them is somehow useful for the use-case. And since we’re micro-optimizing memory usage, Box<str> instead of String (for the two fields with actual string data) would be more efficient since those values are not meant to be mutable. You can then serialize to one of the many efficient binary formats around (e.g. borsh). This is not JavaScript, so you can oftentimes not be bound to JSON.
• Your parsing code looks both unrobust (potentially fragile hard-coded assumptions) and unnecessarily complex. Something much simpler can probably be done with some trivial regex usage.

You may want to lookup Freenet(Hyphanet) first.

what is character?

--no-default-features --features=foo,bar is fine. The harmful part is replacing established crates with smaller ones solely because of ze size.

And the whole dance doesn’t even do what many people think it does, as covered in some comments in that linked old thread.

Note that I made that jerk thread when min-dependency-ing was sort of trending. A trend that was often (not always) as stupid and counter-productive as the other related(-ish) trend min-binary-sizing.

Also note that the harmfulness of that trend went beyond bad ecosystem dynamics and dependants ending up with less quality/reliability. That semi-obsession also encouraged bad coding practices like pervasive use of dyn where it’s not needed. Compromising idiomaticity, and removing zero-cost abstractions to win a faster compiling dependency prize!

I will stop here, because I really don’t want to write that blog post.

trimming down your dependencies

is considered harmful.

^{I don’t know if someone wrote that blogpost for me}

• Use zram so swapping doesn’t immediately slow things to a crawl.
• Use cargo check, often. You don’t need to always compile.
• Add a release-dev profile that inherits release, use cranelift for codegen in it, and turn off lto.

Otherwise, it would be useful to know what kind of system you’re running, and how is the system load without any rust dev involvement. It would also be helpful to provide specifics. Your descriptions are very generic and could be entirely constructed from rust memes.

The majority of actual rustaceans don’t care about these polls (or any "official community" activity for that matter).

If you want actually relevant (and objective) stats, look here.

Didn’t read the whole thing because I had to stop at the right column at the start.

Federated is “decentralized”. The correct word the author is looking for is “distributed”. And even then, direct exclusive P2P is only one form of “distributed”. Hybrid/Multiple approaches are also wide-spread (torrents anyone!).

Not sure how a technical writer gets such a basic aspect wrong.

Also, beyond the closed source aspect, and being a closed up platform in general, Discord was always literal spyware. And pretending like open-source projects who chose to use it didn’t know what they were doing, and glossing over the actions that ranged from collective nagging to almost literal fights in some communities because of such choices, reeks of willful blindness.

It’s laughable before you even get to the code. You know, doing “eval bad” when all the build scripts are written in bash 🤣

There is also no protection for VCS sources (assuming no revision hash is specified) in makepkg (no “locking” with content hash stored). So, if an AUR package maintainer is malicious, they can push whatever they want from the source side. They actually can do that in any case obviously. But with VCS sources, they can do it at any moment transparently. In other words, your primary concern should be knowing the sources are coming from a trustable upstream (and hoping no xz-like fiasco is taking place). Checking if the PLGBUILD/install files are not fishy is the easier part (and should be done by a human). And if you’re using AUR packages to the extent where this is somehow a daunting time-consuming task, then there is something wrong with you in any case.

Edit: That is not to say the author of the tool wouldn’t just fit right in with security theater crowd. Hell, some of them even created whole businesses using not too dissimilar theater components.

@kadu@scribe.disroot.org