←back to thread

185 points psxuaw | 4 comments | | HN request time: 0.613s | source
Show context
rollcat ◴[] No.43537129[source]
I have mixed feelings about FreeBSD. Some stuff is genuinely good: major/minor release branches, the best ZFS experience you can get OOB, actual man pages, overall a lot "cleaner" than most Linux distros.

OTOH when you compare it to e.g. OpenBSD (or in many instances, even Linux), it's an actual mess. The default install leaves you browsing thru the handbook to get simple things to work; it has three (three!) distinct firewalls; the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file; even the tiny things such as some default sysctl value being an XML snippet - actually, WTF?

The desktop story is also pretty bad. OpenBSD asks you during installation, whether you'd like to use X11 - and that's it. You boot to XDM, you get a basic window manager, things like volume buttons just work, all in the base system - no packages, no config files. You can install Gnome or XFCE from there, and rest assured you'll always have a working fallback. FreeBSD still feels like 90's Linux in that area. Regarding usability, both are behind Linux in things like connecting to Wifi networks, but in OpenBSD's case you just save a list of SSIDs/passwords in a text file, and the kernel does the rest for you.

The author is praising jails. I think it's nice that you can trace the lineage all the way back to 6.x, it sings a song of stability. You can also put each jail on a separate ZFS dataset to get snapshot/restore, cloning, etc. But I think it's still a poor middle ground between OpenBSD and OCI. OpenBSD keeps making steps (privsep, pledge, unveil) to provide isolation, while remaining conceptually simple for the developer and imposing no extra maintenance burden on the operator. Containers by design are declarative, separate the system image from state, etc - it's a wholly different concept for someone used to e.g. managing stateful jails or VMs, but it reinforces what already were good design principles.

replies(5): >>43537232 #>>43537514 #>>43538655 #>>43540046 #>>43543318 #
1. yjftsjthsd-h ◴[] No.43537232[source]
> the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file;

Isn't it just that /etc is the base OS and /usr/local is all packages added on top?

replies(2): >>43537538 #>>43546192 #
2. cf100clunk ◴[] No.43537538[source]
Symbolic links can be made, but test test test and make sure anyone else administering that host knows exactly what has been linked and why. Purists might scream, but its none of their business if it doesn't get in anyone else's way.
3. rollcat ◴[] No.43546192[source]
The base/packages split is one of the main reasons why I appreciate the BSDs (that includes macOS). However /usr/local/etc in particular violates several assumptions:

- I can make /usr read-only, exclude it from backups, put it on an NFS share, or otherwise treat it as immutable during normal operation;

- I can nuke /usr/local any time, fall back on the base system, and reinstall packages from there;

- I can put /etc in version control and track all configuration changes;

- I don't need to think whether to look for /etc/nginx or /usr/local/etc/nginx, this also simplifies automation like scripts or Ansible roles; etc

Notably, OpenBSD takes the effort to ensure all packages install their configs in /etc.

replies(1): >>43547403 #
4. yjftsjthsd-h ◴[] No.43547403[source]
I don't think those first two are violated? I'm pretty sure you can make /usr read-only, mount it from a shared source, and nuke /usr/local at will. I do agree that splitting config files by base and not-base means there are two places, but given this particular system design it seems like a bad assumption rather than a bad design.