I know that Alpine has a package manager but I haven't tried it because I worry that Musl might present problems compiling software (I sometimes like to compile things myself, like Vim or Emacs). Is this worry valid?

Also are there any issues compiling Go and Rust programs on Alpine?

Alpine is a very popular platform for both compiling and hosting Go applications--especially static, no n-CGO binaries--given it's minimal footprint.

A common issue people have with Alpine is musl libc's DNS resolver, which can behave differently (thus confusingly) than glibc's. But that wouldn't effect Go applications unless CGO is enabled and it uses the libc resolver. Go's native resolver behaves differently than glibc's, too, but I don't think that's any more of an issue. And the musl resolver has fewer quirks today than it used to, so fewer surprises than a few years ago.

If you're only building common packages I wouldn't expect trouble. For example, I don't see any patches in the official vim package: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/c...

I only recently realized that xsv is now unmaintained. The author now suggests using qsv or xan.

Thank you for making cool stuff and sharing it with us.

I worked at a business that managed its inventory with dBase IV For DOS. I used it from 1997 to 2012, when the business closed. I personally liked it.

Speaking of OpenZFS encryption, has there ever been any third party review of the source code? Or any testing of any kind of its effectiveness?

Ahh, new stupidity inbound.

I don't know why but having a minimal system that only contains what is needed really scratches an itch for me.

I have to admit to still having some philosophical discomfort over SystemD as I feel that it encompasses too much functionality. That said, it does work and that is probably the most important thing.

Linux (the kernel) has LOTS of functionality anyone barely use or even know. Without that, there's no tooling around this functionality, no adoption. Not even all TCP socket options (setsockopt) are documented!

Systemd pushed forward proper usage of capabilities, better watchdogs (in a broader sense, as systemd supports all kinds of them), isolation, policies, and so on and so forth. You need it all to efficiently control the daemons, and it's great when it's all available in a single suite.

Because of SystemD, you can't use Linux control groups. On systemd systems, only systemd is allowed to touch control groups. I think they even tried to make the kernel enforce this but they failed, so now it just breaks systemd if you do.

There are other things just work too.

> why the downvote?

I can see no reason for it.