RE: Why Are You NOT Using FreeBSD?

> -----Original Message-----
> From: owner-freebsd-current_at_freebsd.org [mailto:owner-freebsd-
> current_at_freebsd.org] On Behalf Of Daniel Kalchev
> Sent: Wednesday, June 06, 2012 2:46 AM
> To: freebsd-current_at_freebsd.org
> Subject: Re: Why Are You NOT Using FreeBSD?
> 
> 
> 
> On 06.06.12 05:31, Erich wrote:
> > On 05 June 2012 10:55:57 Chris Rees wrote:
> >> It is absolutely a bad idea for "beginners" to be using tagged/dated
> >> ports trees-- they are not supported and will lead to many complaints
> >> about problems that were solved since the tag.
> > How do they fall back when things went wrong?
> >
> > The handbook states that there is no fall back option.
> >
> > Their fall back option has a name: Windows.
> 
> No need for Windows propaganda here. We have had enough of this
> already.
> Thanks.
> 
> By the way, for those who tried FreeBSD and found it "too much", there is
> another, way better alternative: OS X Someone else does the packaging,
> testing etc. for you and you still don't run Windows :)
> 
> This, of course, if the person, unlike you, does not ignore the advice to
use
> PC-BSD. The same FreeBSD, with someone else taking care of watching the
> ports tree, configuring, compiling, packaging etc.
> 
> Daniel

I don't see what the overall issue is. When I first got introduced to
FreeBSD, I installed all of my 3rd part software using packages as I thought
that's how it was done. It installed fast but was a little out of date.
Later I learned about ports and slowly started using that for more and more
software to get the newer versions. Now I am at the point where all of it is
compiled from updated portstree and I fully expect every time that I upgrade
that some ports will break and have to be manually corrected. I would not
expect less from software that has so many random interdependencies that are
handled by multiple groups.

Have you ever mapped a tree of all the package dependencies it takes to
install gnome on a bare system? I got lost after the 20th level or so in. 

There is constant compilation testing on the software to ID the blatant
compile errors, but tsometimes we just have the magical winning "combo of
fail" options on our system and it will break.


Overall I see it as packages are flat stable at the cost of being out of
date, and ports are current but not guaranteed to compile without
intervention. The Maintainers do give a very good shot to make them stable
but sometimes one person cannot maintain millions of lines of code and not
make a glitch occasionally, or make it out on time when a dependency
changes.