Hi mpdehaan. I hadn't seen parametered roles - maybe I just overlooked them. I did use a lot of parameterized includes but roles would be more flexible. Thanks for the heads up.
Haven't used the web gui, so can't comment on it. The core open source ansible product is text-based. A few months ago, I migrated a provision and deploy system from a bundle of fabric and shell scripts to ansible. I'm happy with the results.
Some things are easier to do: builtin templating for things like config files is nice and all the modules I've used work as advertised. Some things are harder: reusing groups of similar tasks is kind of awkward but doable. The main advantage is that the ansible imposes a structure that is necessarily self-descriptive and that makes everything very readable. The docs are great and the learning curve is pretty linear so you can defer messing with advanced features until you need them (at that point you'll probably be happy they exist).
That's not so far off. It has all of the really beautiful system stuff of FreeBSD (rc.conf, predictable file hierarchy, documentation) and matches them or does better. It forces you to learn how things work and does a good job of teaching you good practices. Even if you don't use Arch, the Arch wiki is a gold mine on configuring pretty much anything.
The main thing Arch has over FreeBSD is you get easy access to lots of shiny toys. Pacman repos update much more frequently and the process of updating packages is much faster. If your favorite text editor drops a new version, it will be available in Arch repos in minutes/hours; it may be months before it makes it to FreeBSD ports. And things like audio, video drivers, wireless are pretty painless in Arch compared to FreeBSD.
The biggest downside of Arch is that it sits on the complete opposite side of the security spectrum. FreeBSD makes sure you start with a secure machine and anything you do to cheapen the security is your bag; most of the time it'll try to let you know you when you're doing it wrong. The BSDs in general have a really healthy culture of security paranoia. You don't get that with Arch. Signed packages have only recently made their way into pacman and I'm not sure if they're even required yet. So a lot of the time, it feels like you just have to cross your fingers and trust that the repos you're hitting haven't been compromised. And you're constantly installing software from them.
Also, occasionally you'll need to spend 5 or 10 minutes recovering from a wonky upgrade (upgrading often is better than not).
Arch is an excellent, if not secure, desktop/laptop environment and you'd be crazy to run a production server on it.
I think it's actually where the second derivative (concavity) of a function changes sign; but you're right in that it can be a positive as much as a negative indication.
The idea is very similar: you create a set of jails that behave as independent systems. Then every process started from a jail is tagged with a jail ID corresponding to the jail that the process was started from. All processes run in the same kernel and the jail ID gives the kernel just enough information to tell whether or not a process should have access to a given resource when sys calls are made.
I've never used OpenVZ so I don't know how they compare in practice but I can say that FreeBSD jails worked beautifully when I was using them heavily (about 2 years ago). They are super easy to manage and were as stable as you'd expect in FreeBSD (you'd have to be trying really hard to knock them down).