Wandering Thoughts archives

My view on FreeBSD versus Linux, primarily on the desktop

Today I wound up saying on Twitter:

@thatcks: @devbeard I have a pile of reasons I'm not enthused about FreeBSD, especially as a desktop with X and so on. So that's not really an option.

I got asked about this on Twitter and since my views do not in any way fit into 140 characters, it's time for an entry.

I can split my views up into three broad categories: pragmatic, technical, and broadly cultural and social. The pragmatic reasons are the simplest ones and boil down to that Linux is the dominant open source Unix. People develop software for Linux first and everything else second, if at all. This is extremely visible for an X desktop (the X server and all modern desktops are developed and available first on Linux) but extends far beyond that; Go, for example, was first available on Linux and later ported to FreeBSD. Frankly I like having a wide selection of software that works without hassles and often comes pre-packaged, and generally not having to worry if something will run on my OS if it runs on Unix at all. FreeBSD may be more pure and minimal here but as I've put it before, I'm not a Unix purist. In short, running FreeBSD in general usage generally means taking on a certain amount of extra pain and doing without a certain amount of things.

On the technical side I feel that Linux and Linux distributions have made genuinely better choices in many areas, although I'm somewhat hampered by a lack of deep exposure to FreeBSD. For example, I would argue that modern .deb and RPM Linux package management is almost certainly significantly more advanced than FreeBSD ports. As another one, I happen to think that systemd is the best Unix init system currently available with a lot of things it really gets right, although it is not perfect. There are also a horde of packaging decisions like /etc/cron.d that matter to system administrators because they make our lives easier.

(And yes, FreeBSD has sometimes made better technical choices than Linux. I just think that there have been fewer of them.)

On the social and cultural side, well, I cannot put it nicely so I will put it bluntly: I have wound up feeling that FreeBSD is part of the conservative Unix axis that worships at the altar of UCB BSD, System V, and V7. This is not required by its niche as the non-Linux Unix but that situation certainly doesn't hurt; a non-Linux Unix is naturally attractive to people who don't like Linux's reinvention, ahistoricality, and brash cultural attitudes. I am not fond of this conservatism because I strongly believe that Unix needs to grow and change and that this necessarily requires experimentation, a willingness to have failed experiments, and above all a willingness to change.

This is a somewhat complex thing because I don't object to a Unix being slow moving. There is certainly a useful ecological niche for a cautious Unix that lets other people play pioneer and then adopts the ideas that have proven to be good ones (and Linux's willingness to adopt new things creates churn; just ask all of the people who ported their init scripts to Upstart and will now be re-porting them to systemd). If I was confident that FreeBSD was just waiting to adopt the good bits, that would be one thing. But as an outsider I haven't been left with that feeling; instead my brushing contacts have left me with more the view that FreeBSD has an aspect of dogmatic, 'this is how UCB BSD does it' conservatism to it. Part of this is based on FreeBSD still not adopting good ideas that are by now solidly proven (such as, well, /etc/cron.d as one small example).

This is also the area where my cultural bad blood with FreeBSD comes into play. Among other more direct things, I'm probably somewhat biased towards seeing FreeBSD as more conservative than it actually is and I likely don't give FreeBSD the benefit of the doubt when it does something (or doesn't do something) that I think of as hidebound.

None of this makes FreeBSD a bad Unix. Let me say it plainly: FreeBSD is a perfectly acceptable Unix in general. It is just not a Unix that I feel any particular enthusiasm for and thus not something I'm inclined to use without a compelling reason. My default Unix today is Linux.

(It would take a compelling reason to move me to FreeBSD instead of merely somewhere where FreeBSD is a bit better because of the costs of inevitable differences.)

FreeBSD, cultural bad blood, and me

I set out to write a reasoned, rational elaboration of a tweet of mine, but in the course of writing it I've realized that I have some of those sticky human emotions involved too, much like my situation with Python 3. What it amounts to is that in addition to my rational reasons I have some cultural bad blood with FreeBSD.

It certainly used to be the case that a vocal segment of *BSD people, FreeBSD people among them, were elitists who looked down their noses at Linux (and sometimes other Unixes too, although that was usually quieter). They would say that Linux was not a Unix. They would say that Linux was clearly used by people who didn't know any better or who didn't have any taste. There was a fashion for denigrating Linux developers (especially kernel developers) as incompetents who didn't know anything. And so on; if you were around at the right time you probably can think of other things. In general these people seemed to venerated the holy way of UCB BSD and find little or no fault in it. Often these people believed (and propagated) other Unix mythology as well.

(This sense of offended superiority is in no way unique to *BSD people, of course. Variants have happened all through computing's history, generally from the losing side of whatever shift is going on at the time. The *BSD attitude of 'I can't believe so many people use this stupid Linux crud' echoes the Lisp reaction to Unix and the Unix reaction to Windows and Macs, at least (and the reaction of some fans of various commercial Unixes to today's free Unixes).)

This whole attitude irritated me for various reasons and made me roll my eyes extensively; to put it one way, it struck me as more religious than well informed and balanced. To this day I cannot completely detach my reaction to FreeBSD from my association of it with a league of virtual greybeards who are overly and often ignorantly attached to romantic visions of the perfection of UCB BSD et al. FreeBSD is a perfectly fine operating system and there is nothing wrong with it, but I wish it had kept different company in the late 1990s and early to mid 00s. Even today there is a part of me that doesn't want to use 'their' operating system because some of the company I'd be keeping would irritate me.

(FreeBSD keeping different company was probably impossible, though, because of where the Unix community went.)

(I date this *BSD elitist attitude only through the mid 00s because of my perception that it's mostly died down since then. Hopefully this is an accurate perception and not due to selective 'news' sources.)

An interesting picky difference between Bourne shells

Today we ran into an interesting bug in one of our internal shell scripts. The script had worked for years on our Solaris 10 machines, but on a new OmniOS fileserver it suddenly reported an error:

script[77]: [: 232G: arithmetic syntax error

Cognoscenti of ksh error messages have probably already recognized this one and can tell me the exact problem. To show it to everyone else, here is line 77:

if [ "$qsize" -eq "none" ]; then
   ....

In a strict POSIX shell, this is an error because test's -eq operator is specifically for comparing numbers, not strings. What we wanted is the = operator.

What makes this error more interesting is that the script had been running for some time on the OmniOS fileserver without this error. However, until now the $qsize variable had always had the value 'none'. So why hadn't it failed earlier? After all, 'none' (on either side of the expression) is just as much of not-a-number as '232G' is.

The answer is that this is a picky difference between shells in terms of how they actually behave. Bash, for example, always complains about such misuse of -eq; if either side is not a number you get an error saying 'integer expression expected' (as does Dash, with a slightly different error). But on our OmniOS, /bin/sh is actually ksh93 and ksh93 has a slightly different behavior. Here:

$ [ "none" -eq "none" ] && echo yes
yes
$ [ "bogus" -eq "none" ] && echo yes
yes
$ [ "none" -eq 0 ] && echo yes
yes
$ [ "none" -eq "232G" ] && echo yes
/bin/sh: [: 232G: arithmetic syntax error

The OmniOS version of ksh93 clearly has some sort of heuristic about number conversions such that strings with no numbers are silently interpreted as '0'. Only invalid numbers (as opposed to things that aren't numbers at all) produce the 'arithmetic syntax error' message. Bash and dash are both more straightforward about things (as is the FreeBSD /bin/sh, which is derived from ash).

Update: my description isn't actually what ksh93 is doing here; per opk's comment, it's actually interpreting the none and bogus as variable names and giving them a value of 0 when unset.

Interestingly, the old Solaris 10 /bin/sh seems to basically be calling atoi() on the arguments for -eq; the first three examples work the same, the fourth is silently false, and '[ 232 -eq 232G ]' is true. This matches the 'let's just do it' simple philosophy of the original Bourne shell and test program and may be authentic original V7 behavior.

(Technically this is a difference in test behavior, but test is a builtin in basically all Bourne shells these days. Sometimes the standalone test program in /bin or /usr/bin is actually a shell script to invoke the builtin.)

An index of non-letter control characters

In Unix and ASCII, bytes 1 through 26 are control-A through control-Z. But there are control characters outside that range: 0, 27 through 31, and 127. As a result of writing up my _.screenrc I've become curious about what all of them are, so here's my handy chart:

0	Ctrl-@	also Ctrl-`, Ctrl-space, Ctrl-2 in xterm
27	ESC, Ctrl-[	also Ctrl-5 in xterm
28	Ctrl-\	also Ctrl-4 in xterm
29	Ctrl-]	also Ctrl-3 in xterm
30	Ctrl-^	also Ctrl-~, Ctrl-6 in xterm
31	Ctrl-_	also Ctrl-/, Ctrl-7 in xterm
127	DEL, Ctrl-?	also Ctrl-8 in xterm

The canonical representation of a control character is based on what Unix prints it as when you enter it (usually with Ctrl-V followed by the character, however you generated it). It turns out that xterm will generate a number of these sequences with alternate Ctrl combinations as noted in the chart (which is probably not complete). Some of these xterm alternates may be more convenient under some circumstances.

Your mileage on actual serial terminals and other terminal emulators may vary, although gnome-terminal and urxvt match up for the primary control sequences and at least some of xterm's alternate ways of generating them. Historically serial terminals could be very variable outside Ctrl-A through Ctrl-Z.

Backspace traditionally sends Ctrl-H. Ctrl-\ is traditionally what stty will report as 'quit', ie it sends SIGQUIT ('please die down with a core dump') to programs; this can make it kind of hard to work out just what ASCII code it represents. I resorted to entering it in vi, saving the file, and then using od to dump the file.

In case you ever need to know this, Ctrl-J is the real end of line character in terminal entry, aka \n; the tty driver maps Return (aka Ctrl-M aka \r) to it normally, but this can be disabled and then you can be stuck if, eg, you crashed a program that uses 'raw mode' when you were trying to work out the ASCII number for Ctrl-\. Many but not all shells will accept Return (or a literal Ctrl-M) as a synonym even in this situation, so you can type commands, but any actual command that prompts you for something probably won't.

(The specific tty mode flag this is controlled by is ICRNL, per CBreakAndRaw. It follows that 'stty icrnl' will help restore a broken session, although you might as well go all the way to 'stty sane'.)

Sidebar: the odd case of konsole

Konsole works just like xterm with the sole exception that Ctrl-? does not seem to generate a Ctrl-? (it can be generated with Ctrl-8, though). Instead konsole appears to swallow Ctrl-? outright, which may have something to do with some sort of magic DEL handling it's doing.