BSD Experiment

[Peter King]

The recent BSD talk at TLUG inspired me to go back
to give *BSD a try, to see if its software was quite
as good as touted. Or at least better than some of
the unarguably bad, half-working, slapdash coding in
the Linux world. I run gentoo by choice -- our motto:
"Burning processor cycles like no other distro" -- so
I have gotten hands dirty with enough code to know just
how bad it can get. Well, time to be broad-minded, to
see what FreeBSD, OpenBSD, and NetBSD have to offer.

The first thing that seriously put me off was finding
out that none of the *BSDs -- none! -- have anything to
equal the console framebuffer in Linux. Since I spend
most of my time at the console, this was a major and
unhappy drawback. And I do mean the console, not some
xterm. OpenBSD has nothing at all, offering at best a
console resolution of 80x50 (perhaps 132x60 with lots
of tweaking). Oh come now. It's 2012. FreeBSD has a 
new (!) driver for the console that actually allows 
"interactive" ways to query the video card. With that, 
I could get a screen resolution of almost 1024x768, 
which is better than nothing, but not even close to the 
capabilities of the 1680x1050 screen on my laptop. So.
NetBSD has a driver in its testing branch (-current) 
that claims to work pretty much like the Linux frame-
buffer. They don't put it like that, but that's clearly 
the model. Anyhow, that might or might not work; the 
NetBSD installation CD gave me kernel panics when I was
trying to install NetBSD -- the first panic came early
on, so I tried again without ACPI; the second one right
after it erased my hard disk to repartition it, thank you
very much. Oh, and no reason was given for the crash. In
the end I never got NetBSD installed to see whether its 
claims were true. By the way, the "framebuffer" driver
in NetBSD has been in the testing branch for at least 
three years...

So I kept going with the unattractive resolution of
FreeBSD since it was the best I could do. I did manage
to get it installed and (more or less) running. Early
on I found out you can basically choose to have it act
as a binary-package distro *or* as a source-code one,
but not mix-and-match. Living with gentoo I opted for
the source-code version. Ahh, the fun started. Forget
things like a completely primitive kernel configuration
file -- I tried to set things up so that my dual-CPU
system could run multiple instances of "make" at the
same time in parallel. This is easy to do in gentoo and
speeds up compile time considerably. In FreeBSD it seems
to be a completely hit-or-miss proposition. Apparently
they leave it up to the coders. And if there is even a
single package in the list that won't compile in parallel,
either the whole thing reverts to sequential (what a way
to use SMP), or, what seems more common in my experience,
the process crashes and burns in the middle with no real
warning. Oh, and wait for it: the kernel *cannot* be
compiled in parallel. This is silly. I've been running
"make -j8" on my gentoo installation for years, and it
is extremely reliable. Where is the supposed "better"
code in BSD?

Well, okay, I'll try life in the slow lane for a while.
Here's another surprise: If FreeBSD discovers that it
needs some dependency while it's trying to install some
bit of software, it puts the current build on hold, goes
to fetch the dependency, and builds that instead. That
sounds reasonable, doesn't it? But here's the thing. It
doesn't tell you in advance just what it's going to need
or how much space it will take up or how many additional
packages have to be fetched/built... Not too big a deal
for your small packages (such as tmux or mutt which I
live by). Even xorg, as big as it is, is more or less
well integrated. But just *try* figuring out how long
it's going to take to build firefox, or libreoffice, or
how much space they are going to take up. I shudder at
the mere thought to trying to install KDE or Gnome this
way. Fortunately, dwm + dmenu aren't too bad. In the
end I never did succeed in getting libreoffice to install
(perhaps because I kept having to go to sleep while waiting
and then waking up to an error message). After seven tries
I managed to get Firefox to run... once... and then it
insisted on recompiling it, simply stopped with an error
message over installing some Java-equivalent by hand, and
kept throwing errors until I gave up.

I'm willing to believe the *BSDs make great servers. But
they didn't make good desktops for me, even given my rather
impoverished text-oriented console "desktop" I prefer to
use. Maybe someone who uses BSD could tell me how to get
things working correctly. As things stand, running BSD as
a substitute for Linux seems like a complete bust, and not
for any particular Linux-centric reasons.

I have run OpenBSD on a server in the past, and it was very
reliable. That seems to be the proper use of *BSD. But then
again, most versions of Linux are very reliable, and they do
not put you through some of the idiocies mentioned above.
While pf (the equivalent of iptables) is indeed a thing of
beauty, and the maniacal focus on security rewarding, in the
end there aren't any compelling reasons to prefer *BSD. Or
at least, so it seems to me. YMMV.

-- 
Peter King			 	peter.king-H217xnMUJC0sA/PxXw9srA at public.gmane.org
Department of Philosophy
170 St. George Street #521
The University of Toronto		    (416)-978-4951 ofc
Toronto, ON  M5R 2M8
       CANADA

http://individual.utoronto.ca/pking/

=========================================================================
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC  36F5 1FE6 D32A 7587 EC42)
gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://gtalug.org/pipermail/legacy/attachments/20120212/158dcf95/attachment.sig>