Paying a visit to planet BSD

Paying a visit to planet BSD

I've received some comments from readers asking me about my distribution choices, and specifically what I thought about the various flavors of BSD. It seems like a fair question. It's been a long time since I ran any of them for any "serious work", and it's likely much has changed. In any case, it seemed like a good opportunity to mess around and see what's out there.

So, over the span of about a week, I tested out the latest offerings: FreeBSD 13.0-RELEASE, NetBSD 9.2, DragonFly BSD 6.2.1_REL and OpenBSD 7.1. This all happened in identically-configured VMs on a Macbook I have that's just kind of sitting around not doing much otherwise. The primary goal was to build as much of my C++ code that I could. The secondary goal was to try to rig up an X environment that looks and works like what I tend to use on my normal workstation: fluxbox, urxvt, bash, a couple of specific (and ancient) Dock/Wharf/Slit/whatever widgets, and so on.

I had actually tried this out on my own about a year ago and things didn't go too well. This time, things are a lot better. I have a bunch of random dumb things or amusements to share.

Now, since I'm talking about operating systems, and then potentially comparing them to each other, I run the risk of bring out all of the people who have nothing better to do but smear poop all over the Internet on a Friday night. So, I'm going to steal a trick from another post: I'm going to list a bunch of things that are strange or just broken, but I'm not going to say which one it was. If you've used it, you might recognize it. Otherwise, eh.

One of the installers is really worried about hard drive geometry. It's odd to be asked about such things in 2022, to be honest. I'm talking about the whole "cylinders, heads, sectors" thing that you used to do. (I'm a little surprised it didn't ask me to type in a list of badblocks from the sticker on top of the drive.)

One of the package installation tools that you're supposed to use to bring in extra stuff (like, you know, bash...) has this giant security warning when you install it. Both the binary and its shared library use tmpnam. It looks like you can race it to the actual path, so that's not great. It's marked as obsolete and there are other ways to accomplish the same goal. It's not a good look when you're getting started and this shows up. You just set your first foot into the jungle and heard "click".

There's an installer which uses its own color scheme which involves a background color other than black. That's fine. But, when it's installing things, it clears the screen... and it clears it back to black. Then a moment later it repaints it as that other color and starts putting text on it. This means every time it flips between files (and this happens a lot), it flashes. Blink. Blink. Blink.

One system said I could only have an 8 character username. It's like, personally, that's not a problem, but I have had many users back in the good old days of running multi-user systems who would not appreciate that. 1996 called and it wants its 8-character username restriction back. (At least it's not using DES for the encrypted password with that wonderful 7 character limit, eh?)

At least two different systems installed dependencies which don't compile with -Wshadow (a flag I usually have enabled for my builds). In both cases, the dependency conflicts *with itself*. One of them is protobuf, and the other one is boost. This is the fault of whoever wrote that code, NOT the port maintainers, but it's still goofy and annoying. Since I use -Werror, I have to compromise on something in order to build when this kind of thing is present.

Also in the realm of dependencies from ports, a fair number of these things ship pkg-config hint files (blahblah.pc) that miss out on stuff you actually need to make it compile and/or link. This is stuff like providing "-L/some/dir/foo" for the direct libs and not providing "-L/some/dir" for the dependency libs. This is also usually not the fault of the port maintainers.

Case in point: mariadb, which is what you use if you want "mysqlclient" type behavior. It relies on -lcrypto and -lssl, both of which are from OpenSSL. It's a port, so it's in a non-system path too. You have to do -L/top/level/lib to pick them up. But, you *also* need to do -L/top/level/lib/mysql to make -lmariadb work.

I'm able to deal with all of this due to how my builds work, but anyone using a build system which believes that 'pkg-config --libs foobar' is the gospel truth is going to have a bad time.

GNU Radio is particularly bad about not telling you when it needs -llog4cpp or -lboost_system. This is *not* specific to any of the BSDs. They also get this wrong on Debian and a bunch of other places. You're better off using "ldd" on any GR lib you intend to link to in order to be sure you have everything covered. Or, you know, keep trying to link and add -l flags for what's missing every time it yells, and keep going until it stops yelling. Clowntown, party of one, your table is now ready.

One of the installers offered a nice "auto" disk setup system, and then promptly sliced up the disk space a bunch of different ways. Everything was fine until maybe 30 minutes later when it was time to install GNU Radio. It was just trucking along until... it ran out of disk space. What happened? The path for ports was given its own filesystem for some reason, and it was 4 GB.

Meanwhile, on that same system, two other filesystems were given 10 GB and 3 GB and had ZERO utilization. This makes no sense. ports are going to take up tons of room since very little comes from the system itself, and you have to augment it.

I found myself having to either go back and start over, or figure out how to wrangle a bunch of existing partitions to reallocate the space. I wound up punting, since it's not worth the effort.

There's this vmware-user-suid-wrapper thing which pokes the X server to tell it how big the "screen" is. This is what you need to make it follow the size of the VM's output, like when you resize the window, push it to an external display, pull it back onto the laptop's native screen, or whatever. If you have this running, then it Just Works. Otherwise, you have to figure it out yourself and hack xrandr calls into your X startup and your xdm/whatever startup, and just never resize or move things. Most of them have it. One does not. If you're running as a VM and not on real hardware, this might get annoying.

It's easy to download the wrong file for one of them. It's a disk image instead of a bootable ISO-9660 image. I'm not even sure when you'd want the first one. You'll probably download it (since it's first on the list), wonder why you keep getting the PXE boot screen on a VM, then double back, *facepalm*, and download the right one. Hope you have a fast connection.

There's a system which asks if you want it to autoconfigure the network, and then it happily sets the hostname to "localhost". It then asks you if everything is okay. If you say no, you don't get a chance to fix the one bad part. Instead, you start over where your choices are effectively "do everything by yourself" or "take everything we autodetect". I said, fine, you can be localhost. Have fun with that.

One of the installers put a ^A in the search domains in /etc/resolv.conf. I still have no idea where that came from, or what it means in that context. I've certainly never seen that before. It's quite a surprise when you first see it. I didn't keep it running long enough to see if it started spewing bad queries at the root servers like some broken configs have done in the past.

It's kind of funny to see which systems let you su from your newly-added local account and which ones balk because you're not (yet) in group wheel. It's like, oh yeah, /that/ whole thing. Better log in as root and fix your account, peasant.

Speaking of su, once I switched my personal account to bash, I also twiddled PS1 to put some hostname/path info into my prompt. This is pretty important when messing with a bunch of machines in parallel so you don't apply a change to the wrong one. On this system and this system only, doing "su" kept my PS1 around... and the root shell displayed it literally. It looked mighty ugly. That's one way to get me to do "su -", I guess, but... really?

Filesystem choices seem to have a lot of magic associated with them. They tend to ask you questions for which you probably have no good answer, at least, not as a new user, or at least one who hasn't used it for many years. There's also one that steers you into a specific recommended filesystem and then gives you two different warnings afterward. One of them is essentially "small filesystems can fill up very quickly". Part of me goes "yeah, and water is wet". The rest of me (battle-scarred from far too much Unix use) goes "oh great, another ENOSPCfs, that'll run out of metadata or something, just what we needed".

Keyboard selection is just bizarre in some cases. Quick, do you want emacs, iso, pc-ctrl, or unix?

In terms of my goals, it went like this:

Primary: build personal C++ code: mostly done. Some of the GNU Radio ports didn't have full hardware support like gr-osmosdr (for rtlsdr sticks, among other things) and gr-uhd for USRPs. I have both kinds of hardware, so the systems without one or the other wouldn't be able to use it unless I went and built support for it myself. Considering that was the status quo pre-Debian for me, that's not a massive problem. It's just not as clean as having someone else do it for you in a nice neat binary form.

I had to turn off -Wshadow in a few places to work around some dumb broken libraries that conflict with themselves.

One of the systems has a build of gcc which hates "non-trivial designated initializers". This basically means you can't do the new fancypants { .foo = bar } C++ stuff on a struct unless you initialize ALL of the fields. This is the code which gave it fits:

struct sockaddr_in in = {
    .sin_family = AF_INET,
    .sin_port = htons(port),
    .sin_addr = in_addr
};

What's wrong? Well, this system has other members in their struct sockaddr_in, and I'm not mentioning them in that initializer. I could explicitly mention them and set them to something, but then this code would fail to compile on other systems where those members don't exist (they aren't in POSIX.1). Not great.

One of them is already on GNU Radio 3.9 where they've done another round of API changes that broke compatibility with existing stuff. It's all stupid minor stuff, like boost::shared_ptr turning into std::shared_ptr (yay) and gr::fft::window taking over some types from gr::filter::firdes. It's relatively simple to fix, but it also means that the same code won't Just Build across all of the systems. Welcome to #ifdef hell (or worse).

If the stuff I had to do didn't cross paths with the missing hardware support, I'd probably be fine on that system. The "turn off -Wshadow" stuff is a harder pill to swallow. I'd probably end up hand-hacking those headers to make them less goofy so I could switch it back on.

Secondary: run my usual X setup. Also largely OK. One of them doesn't have wmcpuload so I'd have to figure out how to make that work on there. This can be annoying at times, since every system has a slightly different way of figuring out just how busy the CPUs are. It's really nice when someone else has gotten there first. I'd probably do without it until one of those lazy afternoons rolled around where literally nothing else needed to be done.

The missing vmware-user-suid-wrapper thing in that one case is mildly annoying, but if I'm running on a VM, I've already compromised on some of my sanity. It's on me to get onto native hardware to get rid of the hacks and unavoidable jank.

Conclusion? All systems have bits of weirdness. Most of it stems from the varying degrees of "hands-off-ness" which applies to basically anything that's not in the (relatively tiny) base systems. Installers are all over the place. Some of them could probably benefit from setting some people loose who have no previous context with their systems to see where the rough spots are.

With enough practice, you can fix any of these problems or otherwise "get in front of them" so the system doesn't get mis-installed the first place. The question is whether you want to. Is that you what you wanted to spend your time on?

I could use any of them in a pinch to get my work done. Lacking such a pinch, however, I choose not to. That says more about me than them.