(no title)
ar-nelson | 2 years ago
In a world before Docker and btrfs, this would be enough to make installing FreeBSD worthwhile. I tried it anyway, for a home server, and it was mostly painful.
Jails are tricky and require third-party (?) tools and scripts to manage them effectively. And they don't give you much that Docker doesn't already. And, although it's not as bad as Arch, FreeBSD does update quickly and if you aren't frequently updating your server you can be left behind; it's not noticeable until you try to update and a bunch of packages break, or your jails are no longer running the same major version as their host and that causes subtle bugs.
I recently replaced my FreeBSD home server with a basic Debian machine running a docker-compose cluster, and it's so much simpler. I wanted to like FreeBSD. At its core, it's probably a better-designed system. But it requires too much additional knowledge and maintenance for something that Linux and Docker do just as well.
thijsvandien|2 years ago
yetanotherloss|2 years ago
There are certainly arguments for why the variety of replacements for simple, old, well trod and tested system tools are improvement and yet my 20 year BSD installations get on mostly fine without them and I'd be hard pressed to describe what they're missing in practical terms other than very specific stacks like Docker.
If you live in devops I can see that being a big deal but for the service functions themselves there is something to be said for leaving minor things at "good enough."
ransackdev|2 years ago
> Then I had enough, whiped the whole thing and in 5 minutes installed the FreeBSD base system. A handful of binary packages and a couple of edits to config files later everything worked perfectly.
There seems to be some confirmation bias here. Is writing an iso, installing an OS, installing a “handful” of packages, and configuring everything not somewhat equivalent to the “messy” alternative of upgrading Ubuntu? I bet they were very close to the same amount of work, but one might have seemed like more, or more daunting, due to your experience and preference for bsd. Just throwing it out there
As for Ubuntu upgrades, apt-get update, apt-get dist-upgrade, and do-release-upgrade have always worked well for me, though I hardly ever do a major version upgrade and opt to do a fresh install after the first minor point release. If you were jumping major versions or a few major versions, of course packages are going to give you a hard time. I imagine a fresh install might have gone as seemingly smooth as the bsd route you took. Anyway, hacking is hacking, keep at it!
toast0|2 years ago
In modern times, point releases tend to be about once a year, which doesn't seem too frequent to me? But if you use pkg, and the new point release added a syscall, you will have problems installing new packages (or upgrading) once the package builders update; I don't quite remember the timeline, but it's usually a few months after the point release. (Although, I think there was a time where pkg would default to a faster updating repository, and you might see problems sooner)
My upgrade process is a bit laborious (freebsd-update -r ... upgrade; freebsd-update install; shutdown -r now; freebsd-upgrade install; pkg update; pkg upgrade; reboot). Might be another pkg command I forgot, but it will likely prompt you.
If you're not interested in upgrading everything together at once, ports is probably a better choice. Sometimes after an OS upgrade, you'll need to install a compat port to continue to run old software; it's possible to do that with pkg, but IMHO, it's difficult to get the compat package installed without upgrading other packages, and then you may as well upgrade everything.
Personally, I don't find docker-compose simple. Probably from lack of experience, but I find it hides so much that makes it much more difficult to debug. Most of the time, I'd rather run everything in a single host, but I'm encouraged to use docker-compose by my workplace, so...
kevans91|2 years ago
The previous release in the branch gets dropped after ~3 months, probably aligned to the end of the month that its EOL lands in; then pkg builders switch to the newer release in the branch.
hn8305823|2 years ago
I know this is in lots of textbook examples but I didn't think anyone ever actually typed this. I've always used 'halt' or 'reboot'
znpy|2 years ago
FreeBSD is really missing out in not implementing something to run containers, and it shouldn’t even be impossible.
The podman people basically reimplemented the docker daemon command line (and apis), and I remember a talk by Bryan Cantrill about how joyent reimplemented the docker API to spawn Illumos/SmartOS zones backed by zfs volumes (i guess either datasets or zvols). And there was some person reimplementing the docker apis using jails as a backend… but I guess that project never went anywhere and didn’t get the attention (and funding/developer time?) of the freebsd foundation.
stonogo|2 years ago
ar-nelson|2 years ago
Docker is less elegant than jails in a lot of ways, but not having to figure out how to install each service on your own is a huge advantage.
I tried using Ansible to set all of my services up, and it really didn't work. Probably because I was using a different machine as the Ansible controller, and there is no Ansible plugin to connect to jails on a remote machine. I tried writing my own, and it just barely worked, but with a lot of bugs I could never fully track down (because Ansible's internals aren't documented at all). Eventually it just wasn't worth it to keep trying to use FreeBSD.
znpy|2 years ago
all2|2 years ago
gjvc|2 years ago
kjs3|2 years ago
Docker is a third party tool. People use third-party tools and scripts to manage them effectively.
Having done jails for years and now having to get comfortable with Docker for $DAYJOB, there's not a huge difference in complexity, just different complexity, as long as you actually learn the tools.