Best way to switch from Linux to BSD

[Christian Walther]

On 29 March 2011 14:53, Michal Varga <varga.michal at gmail.com> wrote:
> Hi,
>
[Port building, mplayer/mencoder example w/o options]
Packages are build with the default ports options. These turn out to
be suitable for me, so I guess they are suitable for others, as well.
I never said that building from source is pointless -- at least this
was not my intention.

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

Certainly. This is a question of the use case. I haven't seen a single
case where mplayer was unable to playback a file.

[FreeBSD user complaining about missing mplayer capabilities]
IMO this is about education. Firstly I expect FreeBSD users to read
the documentation, in this case "Packages and ports", which at least
should give them a hint that packages are not everything in existence.
Secondly there are mailing lists and forums where one can ask in case
something doesn't work as expected. Changing an OS or distro just
because something doesn't work IMO doesn't count as problem solving
strategy. ;)
And I think that the problem with mplayer exists on Linux as well, due
to licensing and legal issues.

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

Exactly.

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

Yes, it's about freedom, really. :)
And since the OP asked of how to proceed I think it's fair to mention packages.
I entirely disregarded pre built packages time, because I thought it
best to compile everything myself. When I state that my T30 takes two
days to build all ports I need and want is not a claim, I've seen it
several times. ;)
We have some great tools to deal with updates, but even with those and
"make config-recursive" I occasionally checked the machine in the
morning and saw a dialog window asking for a ports configuration. This
is not a real problem but costs precious hour. And the machine
consumes energy. Download packages enables me to run a shutdown when I
go to bed.

>> 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?).

Yes, I know. And I decided not do so -- which is my choice.

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

Well, you gain much by the speed of the CPU alone. ;)
And I reckon that most tools that I use really don't care if they're
build for i386 or i686. It does make sense for video encoding,
decoding of course, and number crunching (raytracing for example).

[Optimization and debuging]
> 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.

It's not only that, wrong compiler options can really break valid
code. We're not talking about -O2 here, but -O3 on gcc 4.x is a
candidate here. And then there are really harmful ones, such as
-funroll-loops and -fforce-mem. Thing is, there are Gentoo folks who
have those set system wide.
A nice read IRT to optimization is
http://www.gentoo.org/doc/en/gcc-optimization.xml
They basically recommend to stick to -march, -O, and -pipe
Yes, I once had a Gentoo system running, which is why I became
conservative when it comes to optimization. ;)

[Snipped the NVidia part -- got it :)]