Yes, obviously there are more ways to hide malicious code.

As for the git commit ID, I didn't see you using it even when it was available though? But perhaps that could be a weakness, if the commit ID used does not match the tag in the repo, that would be a red flag too. That could be worth checking.

My guess is that the relevant keyword for the choice of OpenSSL is FIPS. Rusttls doesn't (or at least didn't) have that certification, which matters if you are dealing with US government (directly or indirectly). I believe there is an alternative backend (instead of ring) these days that does have FIPS though.

I have only implemented for checking all packages at the current point in time (as that is what I need later on). It could be possible to add support for checking a single package.

Thank you for reminding me of pacman -Qkk though, I had forgotten it existed.

I just did a test of pacman -Qk and pacman -Qkk (with no package, so checking all of them) and paketkoll is much faster. Based on the man page:

• pacman -Qk only checks file exists. I don't have that option, I always check file properties at least, but have the option to skip checking the file hash if the mtime and size matches (paketkoll --trust-mtime). Even though I check more in this scenario I'm still about 4x faster.
• pacman -Qkk checks checksum as well (similar to plain paketkoll). It is unclear to me if pacman will check the checksum if the mtime and size matches.

I can report that paketkoll handily beats pacman in both scenarios (pacman -Qk is slower than paketkoll --trust-mtime, and pacman -Qkk is much slower than plain paketkoll). Below are the output of using the hyperfine benchmarking tool:

$ hyperfine -i -N --warmup=1 "paketkoll --trust-mtime" "paketkoll" "pacman -Qk" "pacman -Qkk"
Benchmark 1: paketkoll --trust-mtime
  Time (mean ± σ):     246.4 ms ±   7.5 ms    [User: 1223.3 ms, System: 1247.7 ms]
  Range (min … max):   238.2 ms … 261.7 ms    11 runs
 
  Warning: Ignoring non-zero exit code.
 
Benchmark 2: paketkoll
  Time (mean ± σ):      5.312 s ±  0.387 s    [User: 17.321 s, System: 13.461 s]
  Range (min … max):    4.907 s …  6.058 s    10 runs
 
  Warning: Ignoring non-zero exit code.
 
Benchmark 3: pacman -Qk
  Time (mean ± σ):     976.7 ms ±   5.0 ms    [User: 101.9 ms, System: 873.5 ms]
  Range (min … max):   970.3 ms … 984.6 ms    10 runs
 
Benchmark 4: pacman -Qkk
  Time (mean ± σ):     86.467 s ±  0.160 s    [User: 53.327 s, System: 16.404 s]
  Range (min … max):   86.315 s … 86.819 s    10 runs
 
  Warning: Ignoring non-zero exit code.

It appears that pacman -Qkk is much slower than paccheck --file-properties --sha256sum even. I don't know how that is possible!

The above benchmarks were executed on an AMD Ryzen 5600X with 32 GB RAM and an Gen3 NVME SSD. pacman -Syu executed as of yesterday most recently. Disk cache was hot in between runs for all the tools, that would make the first run a bit slower for all the tools (but not to a large extent on a SSD, I can imagine it would dominate on a mechanical HDD though)

In conclusion:

• When checking just file properties paketkoll is 3.96 times faster than pacman checking just if the files exist
• When checking checksums paketkoll is 16.3 times faster than pacman checking file properties. This is impressive on a 6 core/12 thread CPU. pacman must be doing something exceedingly stupid here (might be worth looking into, perhaps it is checking both sha256sum and md5sum, which is totally unneeded). Compared to paccheck I see a 7x speedup in that scenario which is more in line with what I would expect.

Another aspect is that calling a cli command is way slower than a library function (in general). This is most apparent on short running commands, since the overhead is mostly fixed per command invocation rather than scaling with the amount of work or data.

As such I would at the very least keep those commands out of any hot/fast paths.

Two tips that work for me:

• After cargo add I have to sometimes run the "restart rust-analyzer" command from the vscode command pallette (exact wording may be off, I'm on my phone as of writing this comment). Much faster than cargo build.
• Consider using sccache to speed up rebuilds. It helps a lot, though uses a bit of disk space. But disk space is cheap nowadays (as long as you aren't stuck with a laptop with soldered SSD, in which case you know what not to buy next time).

Thanks for the clear and detailed explanation!

Looks cool. Absolutely not my area of knowledge let alone expertise. But I thought digital colour stuff was all about ICC profiles (that basically describe how wrong a device handles colour and how to correct for it).

I don't see any mention of ICC profiles in the docs though? Or is this the lower building block which you would use to work with data from ICC profiles? Basically I think I'm asking: who would use this crate and for what? Image viewers/editors?

Interesting repo and seems useful as a teaching aid, the algorithms seem to be written with a focus on readability.

However, if you actually need to do any of these operations in production I would recommend finding an optimised and well tested implementation instead. This is especially important for the cryptographical algorithms! But even for something like counting set bits, modern x86-64 CPUs even have a built in instructions for that (POPCNT).

Saying “it’s a graph of commits” makes no sense to a layperson.

Sure, but git is aimed at programmers. Who should have learned graph theory in university. It was past of the very first course I had as an undergraduate many years ago.

Git is definitely hard though for almost all the reasons in the article, perhaps other reasons too. But not understanding what a DAG is shouldn't be one of them, for the intended target audience.

1. Not for me. It is clearly not trying to be a systems programming language. And that is why I'm interested in Rust. I work in hard realtime (day job) and do embedded as a hobby.
   That rust is also useful higher up the stack is just a nice bonus to me which means I can keep using it when writing automation things that are too complex for a simple shell script (it has largely replaced python for this purpose for me now).

2. Rust gained momentum because it filled a niche that was unoccupied (systems capable but safe and high level). Oxide seems to be aiming for an area already occupied by Rust from one side and things like Go from the other side. That rarely works out.

Seems to be a wrapper around implementing the "index into data store"-pattern (not sure if there is a better name), but without support for removal from said data store.

From a quick glance I don't really see what this gives you that wouldn't also be quite easy with a manual implementation. And then you avoid the proc macro compile time overhead as well.

The code is hard to read since html escaping appears broken on Lemmy. Better file a bug about that and repaste the code to the rust playground with a link?