I do, however, hold to the fact that any sudo implementation will be more complicated than doas. Sudo, as a project, has more options and usecases than doas so it also has more posibilities for bugs or misconfiguration for the user.
Fair.
I’m unable to tell what codebase your are refering to with you’re grep arguments, sorry.
sudo-rs
Opendoas has a significantly smaller codebase. It only has 4397 lines of code compared to Sudo-rs’s staggering 35990 lines.
Hmm.
% tokei src | rg ' (Language|Total)'
Language Files Lines Code Comments Blanks
Total 76 16243 13468 682 2093
% tokei src test-framework | rg ' (Language|Total)'
Language Files Lines Code Comments Blanks
Total 196 34274 27742 1072 5460
% git grep '#\[cfg(test)\]' src |wc
40 44 1387
I too love making unaware "Tests Considered Harmful" arguments based on some blind analysis.
Funnily enough, one could easily do some actually potentially useful shallow analysis, instead of a completely blind one, simply by noticing the libc crate dependency, then running:
git grep -Enp -e libc:: --and --not -e '(libc::(c_|LOG)|\b(type|use)\b)'
Ignoring the usage in test modules, use of raw libc appears to be more than you would think from the title. One can also argue that some of that usage would be better served by using rustix instead of raw libc.
Of course authors can counter with arguments why using rustix* is not feasible or would complicate things, and would argue that the use of unsafe+libc is required for this kind of project, and it's still reasonably limited and contained.
And a little bit more informed back-and-forth discussion can go from there.
* Searching for rustix in the sudo-rs repo returned this. So this predictably has been brought up before.
exa (which OP's readme says eza is built on) supports creation times. Actual creation time (the "Birth" line in stat output), not ctime.
I would bad mouth Axum and Actix just because of the overhype. But then, the latter is powering this very platform, and the former is used in the federation crate examples 😉
So let me just say that I tried poem and it got the job done for me. Rusty API. Decent documentation. And everything is in one crate. No books, extension crates, and towers of abstractions needed.
I try to avoid tokio stuff in general for the same reason, although a compatible executor is unfortunately often required.
Look into Arc, RwLock, and Mutex too.
Later, check out parking_lot and co. and maybe async stuff too.
From your list, I use bat, exa and rg.
delta (sometimes packaged as git-delta) deserves a mention. I use it with this git configuration:
[core]
# --inspect-raw-lines=false fixes issue where some added lines appear in bold blue without green background
# default minus-style is 'normal auto'
pager = "delta --inspect-raw-lines=false --minus-style='syntax #400000' --plus-style='syntax #004000' --minus-emph-style='normal #a00000' --plus-emph-style='normal #00a000' --line-buffer-size=48 --max-line-distance=0.8"
[interactive]
diffFilter = "delta --inspect-raw-lines=false --color-only --minus-style='syntax #400000' --plus-style='syntax #004000' --minus-emph-style='normal #a00000' --plus-emph-style='normal #00a000' --line-buffer-size=48 --max-line-distance=0.8"
[delta]
navigate = true # use n and N to move between diff sections
light = false # set to true if you're in a terminal w/ a light background color (e.g. the default macOS terminal)
[merge]
conflictstyle = diff3
Still on 0.17.4 btw.
--all-features doesn't work with that particular crate because two of the features conflict with each other. The features list in my command is the one used for docs.rs from the crate's Cargo.toml.
are there any hurdles or other good reasons to not just adding this to every create?
I'm no expert. But my guess would be that many crate authors may simply not be aware of this feature. It wasn't always there, and it's still unstable. You would have to reach the "Unstable features" page of the rustdoc book to know about it.
Or maybe some know about it, but don't want to use an unstable feature, or are just waiting for it to possibly automatically work without any modifications.
Of course, I would assume none of this applies to the embassy devs. That Cargo.toml file has a flavors field, which is something I've never seen before 😉 So, I'm assuming they are way more knowledgable (and up-to-date) about the Rust ecosystem than me.
So, this is being worked on. But for now, that crate needs this line in lib.rs
#![cfg_attr(docsrs, feature(doc_auto_cfg))]
And this line in Cargo.toml's [package.metadata.docs.rs] section:
rustdoc-args = ["--cfg", "docsrs"]
With these changes, feature gating will be displayed in the docs.
To replicate this locally:
RUSTDOCFLAGS='--cfg docsrs' cargo doc --features=nightly,defmt,pender-callback,arch-cortex-m,executor-thread,executor-interrupt
I constantly seem to include something from the docs, only to be told by the compiler that it does not exist, and then I have to open the source for the create to figure out if it’s hidden behind a feature flag.
As others mentioned, the situation is not perfect. And you may need to check Cargo.toml. Maybe even the source.
But as for the quoted part above, the docs should definitely indicate if a part of the API is behind a feature. Let's take rustix as an example.
Here is the module list:
Here is the view from inside a module:
Here is the view from a function page:
This is also true for platform support. Take this extension trait from std:
Now, it's true that one could be navigating to method docs in the middle of a long doc page, where those indicators at the top may be missed. But that's a UI issue. And it could be argued that repeating those indicators over and over would introduce too much clutter.
Practically speaking, you don't have to.
Your executor of choice should be doing
tokiocompat for you, one way or another, so you don't have to worry about it (e.g. async-global-executor with thetokiofeature).async-stdis dead.