Using Landlock to Sandbox GNU Make

This is pretty cool! I have a habit of using Makefiles to automate a lot of things that aren't really build systems (it just maps nicely to how i think of a lot of problems - the whole target + dependency graph concept is powerful). While I'm positive that this work is great for build system stuff too, this will certainly also help solve some problems I've created for myself in the past - namely accidentally acting on files I didn't intent to.

That 200 lines doesn't include our pledge() implementation, which Make assumes is provided by the C library. Right now only Cosmopolitan Libc and OpenBSD have an unveil() implementation. It would take some thought to decide what the best approach would be for incorporating something like that into GNU Make. So I'm waiting on more feedback from the community and the GNU developers. Because upstreaming is totally something I'm open to considering.

Also please consider that GNU Make supports so many ancient platforms, like DOS, QDOS, Amiga, Windows 3.1. When I forked GNU Make, the first thing I did was delete all that support for ancient defunct platforms to give me enough room to think about how to approach implementing this feature. I don't think I could have done this if I had to wade through all that code from the start. I'm doing this work just for fun and to help out, and coding is only fun when the code is clean.

This is definitely interesting and cool, however:

> Landlock Make can build code five times faster than Bazel, while offering the same advantages in terms of safety. In other words, you get all the benefits of a big corporation build system, in a tiny lightweight binary that any indie developer can love.

In terms of safety, maybe almost (bazel can check if the source files changed during the build, this (afaict) can not). But bazel also provides a lot more (caching, remote builds, ...). So, while cool, read more on it and evaluate it in depth before deciding to replace bazel with this.

One of the nice things about Bazel that the article didn't get a chance to go into is it uses SHA hashes of files, rather than file timestamps, to determine when an artifact has changed and therefore needs to be updated. It's slightly more costly to compute hashes, but it's necessary if you want to have something like a global cache of build artifacts, since synchronizing time across machines is hard.

What I'd recommend for anyone really, is to just do what Google did. For the first six years of Google's lifecycle, they got along just fine with GNU Make. Then they switched to the huge scalable thing once they actually reached that inflection point. I'm obviously not there since I'm just a scrappy open source coder. So for me I'm quite happy to be working with GNU Make and I can foresee myself getting many additional years of use out of it.

> and coding is only fun when the code is clean.

I wish I could upvote this more than one time.