Best way to switch from Linux to BSD

[Michal Varga]

Hi,

On Tue, 2011-03-29 at 12:59 +0200, Christian Walther wrote:
> What's the benefit of building everything from source? Yes, you can
> configure some of the ports, but in these days you'll end up with
> stuff you don't want to have anyway. I'm a zsh user and have hardly
> any need for bash, except that there are ports that have it as run
> and/or build dependency. And I reckon it's rather difficult to setup a
> system without having python and ruby installed.

Well, port options aren't only about removing unneeded stuff, but also
the other way around - make that application actually able to perform
some task so in the end, you don't need three different ones to
successfully finish a single specific process.

Take, as one example, the mplayer/mencoder combo (which Thomas Zander
[re]started actively maintaining recently, and is doing an awesome job
with that). Get mplayer, turn off every possible option you can and all
you get is a glorified "hello world" program (well, it might be even
able to display that hello world graphically, yay).

Now do it the other way, learn what all the respective techs (and so
dependencies) mean and do, pull in whatever stuff you need to get your
work (or entertainment time or whatever else) done, fine tune your
compiler whistles (multimedia processing benefits heavily from extended
instruction sets, I obviously don't need to stress that), and poof, you
end up with a single most complete multimedia playback AND transcoding
package that covers most people's 99% needs [citation needed].

But many people don't get that (sometimes just simply don't know), so
they end up with systems polluted with multiple sets of multimedia
packages that "sometimes work, sometimes don't". Then a user comes to
you complaining how FreeBSD sucks, that this or that video stream
doesn't work, DVDs don't work, some things work in Totem, some only work
in crappy VLC, "ZOMG I need flashez for my Youtubez!" (yeah, sure you
do), some even keep Xine backends for "this or that that only plays with
it", some run Windows video encoding software over Wine to get their
stuff done (and crashing five times during the process). Now you ask the
guy -

"But why are you doing that? I'm perfectly sure that for example,
mplayer covers everything you just mentioned and I know first hand that
these things work there as they should, everybody does it, I do that
daily, for years straight without any issues."

"No no no they don't, look I tried it, it just said soemthing about not
supported or whatever and then crashed after or dunno it simply didn't
work, so I used Totem like that's the other media thingie and that
didn't work either dunno some graphics driver or what error heh but who
cares, brb going to boot up Windows".

"Sigh, fine, but then out of curiosity, where did you get that mplayer
of yours?"

"Like how, where? I only did the 'pkg_add -something mplayer' or
whatever like they said on the web, and it sucks and doesn't work, sorry
but it's the FreeBSD way, it's simply that FreeBSD is broken, and it
sucks, everybody says that, so it must be, like, true. Yeah."

"Duh.. Ok. Yeah then."


Now you probably see where I'm getting at with all the fine-tuning mumbo
and configurations and customizations. Yes, FreeBSD takes time, but it
gives you the possibility and opportunity to do it. You don't need to -
there are prebuilt generic packages that do generic stuff (somehow),
there are systems like PC-BSD that already come "complete" and well - do
stuff - somehow, but FreeBSD *lets* you do much more, the moment you
realize that you need to.

To put it as a hyperbole - if you just want generic stock off-the-shelf
crap, yes, FreeBSD has that (too). Some, or *most* of it might even
work. Some might be bloated, some might be insufficiently
'stock-configured' so instead of one, you will end up with system
stuffed with multiple applications of the same kind, only because "some
of them sometimes work with something and some with the rest". But for
people that want the control and need the control and need to get under
the hood and tune it for the best possible outcome, FreeBSD offers
everything all the way down like no other OS does.

It's probably not worth the hassle for your regular grandma, but then,
that's why there is this other "FreeBSD for dummies", it's called Mac
OSX. And it's pretty good.


> Compiling from source can be done on fast, modern systems, e.g. amd64.
> My primary "workstation" is a rusty Thinkpad T30. Building all ports
> from scratch takes two days, and we're not talking about any IDE.

You can always build your "tuned" ports infrastructure someplace else
and deploy everything on T30 via packages after (see what I did here?). 

Sure, it's probably not worth it simply for a single personal machine
(you can keep running the T over night and let it crunch through your
own FreeBSD "universe", you rarely rebuild totally everything from
scratch), but try maintaining a larger workplace and the return is
instantly huge. That's when you realize what a lumbering 7-legged
dinosaur the stock FreeBSD is and why it needs to be cleansed with fire,
first, and repeatedly.


> Additionally, using compiler optimization doesn't seem to be that
> recommended anymore, since it can break code, thus leading to nasty
> results.

I wouldn't agree there. The basic O2 is perfectly safe for ages now (O3
not so, *but* depends on your time and resources to put into testing and
possible troublesolving, and even then you might still turn out to be a
winner in most cases in the end). Processor specific optimizations are a
must too, otherwise you don't even need the fancy new one with the
latest SSSSSE9-THIS-TIME-IN-STEREO, when your plan is to keep using just
the raw i386 out of it, that's like buying a latest state-of-the-art
sportbike and for the rest of the life keep dragging it tied behind a
Pinto.


> Which is why several developers state in their trouble
> shooting guide to rebuild their application with default settings
> before opening a bug report. This further decreases the benefit of
> compiling everything from scratch.

"State".

Several developers are simply lazy and nobody pays them to debug someone
elses issues. Keeping it simple and unified saves anyone's time, but
mostly theirs. I personally support this approach and everyone sane
should.


[I snipped a large part because this is getting seriously way too long,
but I agree with many of your points there, so now just to one more
thing...]


> On the downside there seem to be some work needing to be done IRT
> kernel based 3D acceleration. I don't know the current status, but the
> last I heard was that NVidias drivers can't be ported to FreeBSD
> because the kernel lacks some functionality required (something
> related to addressing the graphics board directly from software,
> AFAIK).

Nvidia has 100% support on FreeBSD (not comparable to their
Windows/Linux support, but great nevertheless):

http://www.nvidia.com/object/freebsd-x86-260.19.44-driver.html


http://www.nvidia.com/object/freebsd-x64-260.19.44-driver.html


Nvidia's drivers on FreeBSD are pure complete awesome sauce and they
would cook you a dinner if you asked them to, and clean up in the
morning afterwards.

(No, really, I don't work for Nvidia and I'm probably years away from
any possibilities for fanboy-ishms, but this is how it really is.. So
you are mistaken, Nvidia single handedly saved FreeBSD on desktops many
years ago and does it till present times, over and over. No, they're not
that much into charity, but some of their corporate customers run
FreeBSD, so this is the outcome, and it's pretty good).


> So if you want the latest features and eye candy (say, KDE4s Plasma)
> and make heavy use of xcompmgr, there might be better choices.

Don't believe that (see above).

m.


-- 
Michal Varga,
Stonehenge (Gmail account)