Author couldn’t help himself but do some “wisdomry” at the end!

That’s a question of API, not type system. And FD types (e.g. OwnedFd, BorrowedFd) are already in std.

There is the odd (genuine) security issue tbf. But they are more of the variant:

“If an attacker is close enough to sneak that on me, then I’m probably already screwed.”

Why are you hallucinating facts?

• There is no “team of 200 rust developers”.
• “<lang> developer” is not an identity.
• uutils is not a “professional” project, as in people are paid by the (non-existing) uutils company to work on it.
• The project started as personal hobby of one person during COVID, There were no 200 contributors who sprung up magically and simultaneously from the start.

They wanted to avoid the “politics” and are not entertaining comments or explaining their decisions. It’s not up for discussion.

If you think you saw a group of 200 people starting uutils and doing this. You should seek medical help.

The “reported upstream” link is broken (fixed link).

mostly compatible with C

It’s not mostly compatible, not even on the surface level, with any version of C post C89. And most of the ever-growing crap in the language came after the early years anyway, with constructs that are C++-exclusive.

compatible with C

myth

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?

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

You may want to lookup Freenet(Hyphanet) first.

@calcopiritus@lemmy.world

fun with flags (run it)

I gave this a quick look at 2X speed with a lot fast seeking, and my brain still hurts.

First of all, and concerning Rust, please familiarize yourself with the mem module and its functions at least. You didn’t even get near a situation where using unsafe{} was actually required.

Second of all, and concerning the task at hand itself, for someone who knew to make the distinction between bytes and chars, you should have known about grapheme clusters too. There are a lot of multi-char (not just multi-byte) graphemes out there. You can make a “Fun With Flags” 😉 segment to show that off (no attribution required). Just don’t do anything silly, and make sure to just utilize the unicode-segmentation crate.