I love shellcheck. There's no great reason not to have any new shellcheck errors commented on each pull request. It's almost always right and how much you as the developer cares is the big question.

And for goodness sakes, use ShellCheck! It can be easy (i.e. there are CI services that will run shellcheck automatically on your PRs and comment bugs).

What are your thoughts on the overlap between these tools? I have a CI SaaS with checkov by default. It performs really well and requires no configuration, which was exciting. Tfsec would be easy to add but I'm not sure how duplicative it is of checkov. Anyone here have opinions?

It's so neat to see semgrep branching out to support more languages including IaaS. At [muse](https://github.com/marketplace/muse-dev) we went a different path of making a platform to run multiple tools. By default the tools include semgrep and, regarding the IaaS space, checkov.

That's a huge leap from "arbitrary candidates can't give a satisfactory answer during an interview" to "I don't trust it can be done."

Do you apply the same test to cryptographic algorithms?

I think you skimmed a little too fast. The links are chalked full of slides, implementations, and executable examples.

For obvious reasons, I wanted a `.md` domain but those are expensive... also for obvious reasons. This is a rather unfortunate and common result of our DNS system.

And they are also quite pricey for locals too, given our fragile economy. We're not some inhabited island in the ocean.

Some recent happenings in Cryptol land include:

  * Dylan recently released a literate Cryptol version of the CFRG's ChaCha20/Poly1305 document.  Very cool to see more Cryptol code like this.
  * Merged the fork of SBV with upstream.
  * ABC is now a supported prover.
  * Support for parallel (first to finish) proving using ':set prover=any'.
  * The type checker has been revamped for v2.3, so we should see simpler constraints "soon".

Parallel proving should be a big bonus. Nipkow found that on the Isabelle test set, using 3 theorem proves in parallel gave as good results in 5 seconds as the best among them gave in 120.

While correct, I always find the declaration of Mirage (and HaLVM for that matter) as an OS to be unhelpful. It is a cross compiler for OCaml (resp. Haskell) to the Xen ABI along with libraries for interacting with Xen primitives (inter-domain communication, etc).

Mirage is actually not just the Xen ABI. It includes a frontend that swaps in appropriate implementations of module signatures for other backends.

For instance, Andy Ray just got a kernel module target working: http://lists.xenproject.org/archives/html/mirageos-devel/201... (when this mode is complete, the network stack module will call directly into the FreeBSD kthread rather than invoking socket syscalls, for example). This is also how we plan to support the Raspberry Pi (use FreeBSD as a bootloader, with just one kernel thread running which runs the unikernel).

And there are also ongoing ports to JavaScript (to work as an IOCaml notebook, which is itself based on IPython).

All of these just need a recompilation with a different invocation of `mirage configure --<target>`.

I follow you work with great interest.

I had the fortune of using Oberon/Blue Bottle in the 90's and also some contact with Singularity.

So I am very passionate about OS done in memory safe languages and alternative OS designs outside the UNIX System V model.

Congratulations for the work achieved.

Today. Nothing prevents a future version to target hardware directly.

It has been mentioned multiple times that Xen ABI is just away of saving resources to focus on more important areas for the time being.