Dragonfly is tough by default because unless you use something like Salt, you can't connect to it to get keys to it in the first place. You can curl keys to it, of course. But you need totally different processes than you would typically use with any other OS to get it set up.
That means it's not even Ansible friendly. Pretty much agent-based tools like Puppet, Salt, etc... is the way to go.
Yup, unless you have some way to push the Ansible key ahead of time, like in a curl. So back to the beginning there :)
for curiosity sake: who is actually using dragonfly bsd and why?
I've deployed it a bit in labs. I'm always watching it closely because Hammer is very important.
One of the world's most advanced fileystems. Dragonfly is important as a kernel alternative ecosystem to FreeBSD, from which it split (in many ways Dragonfly is the real FreeBSD and FreeBSD is the "new" product that split from it) but its real relevance is as a filesystem research platform. The kernel maintainer there writes a totally unique filesystem, called Hammer, just for Dragonfly.
Thanks - I will proceed without using ZFS - I prefer hardware RAID.
ZFS is perfectly fine with hardware RAID, if you like ZFS' features otherwise (like zsend is nice) then there's no reason to avoid it. If you don't plan to use any unique features, then XFS is my "go to" choice by default. Very fast, very stable.
So, do you think the reason I am seeing a lot more gzip in use with tarballs is due to the familiarity of gzip and the negligible difference in the compression between it and bzip2? Basically, bzip2 doesn't make enough of an improvement with sufficient regularity to entice people to move away from gzip, or is there some other benefit to gzip that my training material hasn't covered?
That's correct. The difference between the two is generally small enough that people are not concerned. And lots of systems still don't have bzip2 installed by default so if you want scripts or whatever to work universally you often use gzip because you know that it is always there and predictable.