Vorpal

Not really. Heapless uses compile time sized backing buffers to implement Vec, string etc with a max upper size. You would typically use heapless with a statically allocated variable, but it is possible to use it on the stack too.

Alloca is different and allocates a dynamically sized block on the stack. Rust doesn't really support alloca, but there is a crate for it that works by calling through a helper function in C: https://lib.rs/crates/alloca

Also worth noting is smallvec and compact_str crates. These are useful when you most of the time have small data that you want inline, but are OK with falling back to heap allocation for the occasional outlier.

I have used both inside structs to optimise cache usage. For these uses i tend to use rather short smallvec.

And smallvec in particular is also useful on the stack in a larger variant in hot functions where you might have a Vec that almost always is less than (say) 32 elements, but the program should gracefully handle the occasional long case. I found this offered a small speed up in some batch data processing code I wrote.

• https://docs.rs/smallvec
• https://docs.rs/compact_str

What about the UV cured polymer that dentists use? Surely that is relatively safe, though probably way too high viscosity. (Note: While I know a fair bit about FDM, I'm not at all read up on SLA, so I may be completely wrong here.)

Let's Encrypt is meant yo be used with automated certificate renewal using the ACME protocol. There are many clients for this. Both standalone and built into e.g. Caddy, Traefik and other software that does SSL termination.

So this specific concern doesn't really make sense. But that doesn't mean I really see a use case for it either, since it usually makes more sense to access resources via a host name.

Thanks, didn't think about that. Two reasons I can think of:

• Vase mode should reduce stringing on TPU as it avoids retractions. Though I have found that just drying TPU + enabling "avoid crossing perimeters" usually hides most stringing.
• Additionally, it would let you have more precise control over how squishy/firm the TPU part is by adjusting the number of perimeters. Though you can use modifier volumes in the slicer to adjust infill and number of perimeters locally in a part.

Is there any other reason why this is good for TPU that I missed?

Unless they are in different cities they wouldn't be safe from a fire, lightning strike, earth quake/flood/tsunami/typhon/hurricane/etc (remove whichever ones are not relevant to where you live).

That seems like a really big downside to me. The whole point of locking down your dependencies and using something like renovate is that you can know exactly what version was used of everything at any given point in time.

If you work in a team in software, being able to exactly reproduce any prior version is both very useful and consider basically required in modern development. NixOS can be used to that that to the entire system for a Linux distro (it is an interesting project but there are parts of it I dislike, I hope someone takes those ideas and make it better). Circling back to the original topic: I don't see why deploying images should be any different.

I do want to give Komodo a try though, hadn't heard about it. Need to check if it supports podman though.

I haven't used Komodo, but would it commit to the updated docker files to git? Or just use the "latest" tag and follow that? In the latter case you can't easily roll back, nor do you have a reproducible setup.

The standard library does have some specialisation internally for certain iterators and collection combinations. Not sure if it will optimise that one specifically, but Vec::into_iter().collect::<Vec>() is optimised (it may look silly, but it comes up with functions returning impl Iterator

Hm, that is a fair point. Perhaps it would make sense to produce a table of checks: indicate which checks each dependency fails/passes, and then colour code them with severity.

Some experimentation on real world code is probably needed. I plan to try this tool on my own projects soon (after I manually verified that your crate match your git code (hah! Bootstrap problem), I already reviewed your code on github and it seemed to do what it claims).

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.

Due to the recent xz trouble I presume? Good idea, I was thinking about this on an ecosystem wise scale (e.g. all of crates.io or all of a Linux distro) which is a much harder problem to solve.

Not sure if the tag logic is needed though. I thought cargo embedded the commit ID in the published package?

Also I'm amazed that the name cargo-goggles was available.