
OpenBSD from a veteran Linux user perspective - mulander
http://cfenollosa.com/blog/openbsd-from-a-veteran-linux-user-perspective.html
======
batou
Thanks for taking the time to write this up.

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.

However I end up with CentOS every time when it comes to rolling out something
professionally in production. Why is this?

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.

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.

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.

4\. IO perf, particularly on SSDs is 2-3x better on Linux on the same kit (HP
DL380 gen 8, Samsung 845 DC PRO).

As a side issue, both are crap on the desktop so I'm sitting here on Windows
8.1...

~~~
keithpeter
Is there any Linux or _BSD that is_ good* on the desktop for you? Just
wondering!

PS: There appear to be a number of CentOS boxes that have been left for _more_
than a decade judging by the thread on CentOS Forums about patching a CentOS 4
server for Heartbleed...

~~~
noir_lord
Xubuntu is close to perfect for me, fast, stable, has everything I want, they
don't stop the boat mid ocean to redesign it.

Used it for years and have basically no complaints.

~~~
digi_owl
Just wish Gnome would lighten up on their GTK chokehold.

~~~
noir_lord
Agreed, I wish GTK was isolated from Gnome like Qt is from KDE but I can't see
it happening.

------
carlesfe
Hi, OP here.

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.

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 :)

~~~
Sanddancer
I use FreeBSD instead of OpenBSD, but for your next revision, I'd recommend
symlinks for your mount problems with build directories. Before I switched
over to ZFS, I would always just create a /home/ports and symlink /usr/ports
over to it, same with /usr/src and /usr/obj. Bit ugly, but it works.

~~~
Mordak
This is a good suggestion. OP could also mount /usr/ports, /usr/obj, etc. via
NFS from a dedicated build machine, and just pkg_add the built packages from
/usr/ports/packages/, or 'make install' precompiled errata from /usr/src/.
Having a dedicated build machine also keeps all the build dependency stuff
contained elsewhere, and makes it easy to update multiple machines.

------
JoshTriplett
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.

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".

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.

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.

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 _better_ than the GNU userspace tools?

~~~
woodman
That depends on how you define "substantially" and "better". Consider cat.c
from gnu [0] and openbsd [1]. I'd say that openbsd's implementation is
"substantially better", because:

1\. it does everything I need in 194 LOC (vs 488 LOC)

2\. the code is so understandable that it needs no commenting (and I'm not
just saying that because it has no comments, it is braindead simple code)

3\. there are no ifdefs and the program state is much more shallow

Now obviously that is from the perspective of a programmer, but it has been my
experience that if the code base sucks for programmers - then things suck for
the users as well (surprising behavior, security issues, long lag in bug fix,
etc). I once spent a day chasing a bug related to autotools and colorized
output from grep... sometimes the bells and whistles get in the way of
actually getting things done.

[0]
[http://git.savannah.gnu.org/cgit/coreutils.git/plain/src/cat...](http://git.savannah.gnu.org/cgit/coreutils.git/plain/src/cat.c)

[1] [http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/bin/cat/cat.c?r...](http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/bin/cat/cat.c?rev=1.21&content-type=text/x-cvsweb-markup)

~~~
JoshTriplett
While I appreciate the value of a cleaner or simpler codebase, I can't place
as much value on that as I do on usability, unless the code is utterly
unmaintainable beyond all hope of redemption. And whatever you might think of
the extra complexity of the GNU code, for good or ill, it certainly isn't
_that_.

~~~
woodman
Again, a lot of words with definitions that intelligent people can disagree
on. This is why there are so many different operating systems... and
implementations of echo.c. So to answer your original question more directly :
yes, there are many instances of the standard command-line tools available on
other UNIXen being substantially better than the GNU userspace tools. In my
opinion. You may disagree, but who is to say?

------
brynet
> The base system config files are properly centralized in /etc, but not the
> ports.

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.

------
barosl
> For example, ext4 is officially supported read-only but in my case it didn't
> read some folders properly.

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.

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?

~~~
laumars
FAT32 is an open standard AFAIK, however it's extensions (eg long file names)
and forks (eg exFAT) are patented. But in fairness, FAT32 isn't much use
without support for long file names.

Interestingly, some FAT32 forks do support journalling. Sadly those tend to be
the patents Microsoft are the most proactive in upholding.

As for an alternative, ZFS is supported on FreeBSD, Linux, Solaris and OS X -
so that's one option. Albeit it's not a great option in this specific
criteria. ext2 receives pretty good support as well, even on Windows. However
ext2 doesn't support journalling. Another option is to run ext3 as that
gracefully downgrades to ext2 if no ext3 driver is available. Sadly NTFS is
probably the most ubiquitous journalling file system. ntfs-3g - which are
actually pretty decent drivers - has been ported to quite a few platforms.

~~~
wtallis
The FAT32 long file name patents are expired. That's a big part of why exFAT
exists.

------
nailer
2015 era command line Rosetta Stone, including OpenBSD and current Debian:

[https://certsimple.com/rosetta-stone](https://certsimple.com/rosetta-stone)

Also: SmartOS and FreeBSD.

------
zf00002
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.

~~~
carlesfe
But one does get used so quickly to the nice things... :) That's the main
reason that put me off Slackware and Gentoo. Package managers are a great
improvement.

Think about it: we also spent a lot of time configuring drivers, and I think
we all agree that hardware autodetection is something to be desired in 2015,
isn't it? That was my thought with compiling from source. Not that there is
anything wrong with it, I just found it very weird because I didn't know that
was the usual way to go on BSDs

~~~
laumars
That depends on the BSD. FreeBSD does have binary repositories and a pretty
decent package manager (pkgng). PC-BSD is basically a distro of FreeBSD, so
would also have the same; as does DragonflyBSD, which is a much older fork but
these days a standalone BSD in it's own right.

NetBSD still uses pkgsrc which does support binary packages but the command
line tools are a little less intuitive in my opinion. Incidentally, a few
other UNIXes also support pkgsrc.

You may already be aware of this, but it's worth noting that the different
BSD's are more like separate OS's, rather than distributions of the same OS
like you see with Linux. eg DragonflyBSD, despite being a fork of FreeBSD, has
some quite significant kernel changes (different schedulers, file systems,
etc). And it's a similar story with NetBSD and OpenBSD too - though they're
forked from other, much older, BSDs.

------
pronoiac
> In a few years we've gone from _/ etc/init.d/sshd restart_ to _service sshd
> restart_ to _systemctl start sshd_.

Aw man, I just got used to the second one!

~~~
rjcz
OpenBSD grows and changes, and its rc.d(8) is no exception!

man 8 rcctl

------
simplexion
"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."

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.

------
markhellewell
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
[https://stable.mtier.org/](https://stable.mtier.org/)

