moochmooch

so use Bazel or buck2 if you need an iteration on make's handling of changed files. Bazel is much more serious of a project than buildkit. I'm not saying make is more functional that buildkit (it might be to some), I'm saying its better written software than buildkit. two separate things

unfortunately, make is more well written software. I think ultimately Dockerfile was a failed iteration of Makefile. YAML & Dockerfile are poor interfaces for these types of applications.

The code first options are quite good these days, but you can get so far with make & other legacy tooling. Docker feels like a company looking to sell enterprise software first and foremost, not move the industry standard forward

great article tho!

This is cool, is there a docs website available?

That is a downside. However, it's better to look at Tauri like you might look at React Native. If complete consistency between platforms is required, Tauri still saves you time by letting you write a single codebase and then do a low effort port to each platform. For many applications, Tauri applications will look the same between platforms out of the box.

That's the pitch anyway. People can spend a lot of time on ios vs android in react native applications, so ymmv

it stops low effort grifting of network-enabled open source for cash.

That should not be the litmus test for writing software. Lots of software can have 1 user, yourself. Stability and ability to distribute be damned

ts-node introduces its own bugs and ergonomics inconsistencies on top of node. I've used it on multiple projects in the past and ended up removing it as a dep when I've been able to.

Not saying anyone who is using ts-node should immediately jump to Deno. Their use cases don't fully overlap.

whinging about supply chain security is the bikeshedding topic of 2022

It wouldn't be better, it would be arbitrary

JPL is such an outlier it's not even worth talking about in this discussion

> thoroughly vetting a candidate

Either you work at startups or you thoroughly vet candidates, not both.

I'm scoping my statement to container security & orchestration best practices, not their competency as a whole. I know the specifics of their guidance due to the industry I work in, so I feel comfortable speaking generally about specific guidance in regards to specific technology.

Your comments reads overly defensive to me.

It's funny that you use the term "actual" to describe the guidance from the US government. They don't really know what they are talking about. Their release process for guidance takes so long that by the time it's release, it's out of date. This is absolutely true for k8s guidance. Last I checked, they were suggesting everyone use "Docker Enterprise" on their guidance long after it no longer existed (are vendors supposed to magically know mirantis is now an option?)

Do you use a proprietary tool to filter containers lacking the certificate mechanisms or is this handled as part of the manifests?