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

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

You may want to lookup Freenet(Hyphanet) first.

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

(didn’t read OP, didn’t keep up with chimera recently)

From the top of my head:
The init system. Usable FreeBSD utils instead of busybox overridable by gnu utils (which you will have to do because the former are bare-bones). Everything is built with LLVM (not gcc). Extra hardening (utilizing LLVM). And it doesn’t perform like shit in some multi-threaded allocator-heavy loads because they patch musl directly with mimalloc. It also doesn’t pretend to have a stable/release channel (only rolling).

So, the use of apk is not that relevant. “no GNU” is not really the case with Alpine. They do indeed have “musl” in common, but Chimera “fixes” one of the most relevant practical shortcomings of using it. And finally, I don’t think Chimera really targets fake “lightweight”-ness just for the sake of it.

I don’t do Go (thankfully). But that description reminded me of “A False Midnight”, which is a Python story from almost 12 years ago (time flies).

The fact that these two stories concern Python and Go, the two supposedly easy and simple languages, are good examples of why such descriptors were always intellectual smell.

No. This one is actually cool, useful, and innovative. And it tries to do some things differently than everyone else.

Not knowing about opt-in telemetry doesn’t convey lack of experience, or lack of (relevant) knowledgeability. Especially considering the fact that Arch purposefully keeps the existence of it low-key to avoid the possibility of pissing off anyone.

I was already an Arch user when that opt-in telemetry was introduced. And only heard about it because I was relatively active in Arch communities back then (relatively young, relatively new to Arch). If pkgstats were introduced two years later, I would have never heard of them. Because believe it or not, Arch is just a reliable OS, where you don’t have to interact with anything other than reading the odd announcement every other year. It’s not a “community”, or a “way of life”, or anything in that bracket.

The premise of the question is wrong, since it assumes a general preference.

If you’re asking 👉 this 👈 Arch user, the answer is “NONE”.

EDIT: The majority of users, especially experienced ones, don’t enable pkgstats. So such stats always end up in some form of self-selection (biased towards users who would use a DE in this case).

They know you can just do if ((age < 18)) in bash, right?

Or rather if ((10#$age < 18)) because age=021 would not be adult 😉 Hopefully, they protect against that at least.

(I had to double-check this stupid default is still a thing, since I moved to zsh many years ago.)

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