Thanks for taking the time to write this up.<p>Got a few CentOS 6.x boxes under my command at the moment. At the same time I've got a NetBSD/OpenBSD background. I ran NetBSD for years on Sun SPARC kit and thoroughly enjoyed it. This eventually rolled onto OpenBSD because TBH it just works (to a point) and everything is easy to find.<p>However I end up with CentOS every time when it comes to rolling out something professionally in production. Why is this?<p>1. The amount of information on how to solve even the most complicated problems is a Google away every time. Sure I solve most problems from my head but when I've got a CIFS mount that dumps stack, there's an answer there in 30 seconds.<p>2. I can just leave CentOS to it for a decade and yum update it as required. No PITA world changers every 6 months as a new release drops.<p>3. The OS and the packages are considered as one singular concept. I wasn't a fan of this idea initially but the fact you can drag your kernel and any part of your userspace up from the same source is really cool. There's only one update mechanism to consider. This is stupidly convenient when you have Ansible in the picture for example.<p>4. IO perf, particularly on SSDs is 2-3x better on Linux on the same kit (HP DL380 gen 8, Samsung 845 DC PRO).<p>As a side issue, both are crap on the desktop so I'm sitting here on Windows 8.1...
Hi, OP here.<p>This is actually the second revision of the text; I got some awesome feedback from other OpenBSD users and tried to improve it. I’ll be happy to hear your opinion and fix any errors that may still be on the text.<p>This is my first time with a BSD and its idiosyncrasies. The idea is to create a guide for former "GNU userland" admins and help them jump to BSD or, at least, have a more informed opinion before making the jump. The post will be further updated since I've been receiving more emails :)
The differences between GNU and UNIX behavior can be substantial. I used a SunOS system for a few terms in college; I used Debian to get work done, but for a few things we had to make sure our code compiled and ran on the SunOS system.<p>One of the first things I noticed in the short while before I put the GNU tools at the front of my path: the SunOS tools wanted all options before all other arguments. So if you have "ls something", and you hit up, space, -l, enter, (or "!! -l" if you prefer) then instead of the long listing you expected, you get the same short listing as before, along with an error like "-l, no such file or directory".<p>It's minor, but it's one of those things that adds up when you're used to more capable tools and find yourself in a less capable environment.<p>OpenBSD doesn't necessarily suffer from the same deficiencies (I certainly don't know if they have that one or not), but when you're used to coreutils, any other tools can be a shock, and not typically in a good way. The same goes for environments like busybox, but at least there it's for a good reason: size constraints.<p>I'd be curious to hear examples where the reverse is true: are there instances of the standard command-line tools available on other UNIXen being substantially <i>better</i> than the GNU userspace tools?
> The base system config files are properly centralized in /etc, but not the ports.<p>OpenBSD generally stores ports configuration in /etc as well, however; some software has unique directory layout requirements and/or may be chrooted in /var. In that case they need access to their config files.
> For example, ext4 is officially supported read-only but in my case it didn't read some folders properly.<p>For some reason, I've thought ext4 is "pervasive" or "fundamental" until now. I assumed it to be readable by most systems. So it came as a surprise that OpenBSD could not correctly read a ext4 filesystem. But thinking again, last time I checked, Linux could not write to a HFS+ filesystem, either. OpenBSD's FFS might also not be not supported. So a BSD not supporting the Linux filesystem is very natural.<p>Probably one of the "greatest common divisor" filesystems, which are supported by all major operating systems, should be FAT32. Which is a shame, as it isn't neither an open standard nor a thing from the Unix culture. It also lacks journaling support, which I consider essential. Any alternatives?
2015 era command line Rosetta Stone, including OpenBSD and current Debian:<p><a href="https://certsimple.com/rosetta-stone" rel="nofollow">https://certsimple.com/rosetta-stone</a><p>Also: SmartOS and FreeBSD.
It's kinda strange that he spends so much time documenting his old-school linux admin rep, then really complains about building from source and not being able to just apt-get upgrade. Building from source is the way we used to do it.
> In a few years we've gone from <i>/etc/init.d/sshd restart</i> to <i>service sshd restart</i> to <i>systemctl start sshd</i>.<p>Aw man, I just got used to the second one!
"But this time I didn't want to use a Linux installation which wants me to reboot every 5 days because of some critical patch. I'm looking at you, Ubuntu."<p>Critical patch... I think you mean kernel update and you don't have to perform them. A critical kernel patch that requires you to restart every 5 days would be ridiculous.
For anyone who reads this and is put off by the thought of having to update their system from source; there are binary patches available (both OS and packages) using the `openup' utility from <a href="https://stable.mtier.org/" rel="nofollow">https://stable.mtier.org/</a>