On Tue, Sep 11, 2007 at 05:38:32AM +0900, Lionel Bouton wrote:
> Thanks for the answer, that was an interesting reading. I've some
> remarks though (maybe some things changed since the last time you tried
> Gentoo).

To be perfectly fair . . . it has been a little while.


> 
> To put it more on topic, could you describe briefly how you can
> integrate gems in the package management system on *BSD? With me being
> very familiar with Gentoo, the ease of integration of gems into Gentoo
> was probably the biggest reasons why I switched all my servers to Gentoo...
> Does it build on gems like Gentoo or do you have to write messy
> Makefiles like I suspect most other Linux distributions do?

In very superficial terms:

Specify a gems hierarchy, install the gem utility from ports, and use as
normal.


> 
> Chad Perrin wrote the following on 10.09.2007 21:12 :
> >
> > FreeBSD, among other things, tends to provide far greater system
> > stability than Gentoo.
> 
> ?!? To be more stable would probably mean repairing the hardware for me!

Again, it's been a while for me -- but the "KDE is broken this week" joke
comes to mind.


> 
> Currently I have 3 desktops including my parents' one (and trust me, I
> don't want to travel to fix their computer...) and 7 servers running
> Gentoo (my business is only 4 months old, this will grow...). I started
> using it 3 years ago and never had any software stability problems (of
> course I don't blindly update gcc or Apache 1.3 to Apache 2.0 without
> reading the upgrading documentation beforehand, actually read the
> installation notices/warnings and use a staging server for critical
> stuff...).
> I've some experience administering Linux (I've done it for more than 10
> years now), so as you said: your mileage may vary :-) Of course I stay
> away from unstable ebuilds as much as I can and test them thoroughly if
> I really have to use them on production servers.

One can always make up for stability failures with diligence,
intelligence, and hard work -- and a bit of luck (of course).  That
applies pretty much regardless of OS (especially if it's an open source
OS with open source software running on it).


> 
> >   As with a comparison with any Linux distribution,
> > FreeBSD also presents a far greater sense of the system as an integrated
> > whole than Gentoo
> 
> I'm not sure if I understand this correctly. Let me rephrase to be sure:
> the FreeBSD administration is more consistant across software packages,
> the base system configuration is simpler.
> 
> If I understood correctly, it may be a good thing, yes. And it probably
> isn't Gentoo specific: most general purpose Linux distributions come
> with roughly the same software and the same heterogeneous configuration
> files too. On a positive note, I like the /etc/conf.d system in Gentoo:
> it brings some consistency to this (even if it can't address all problems).

This is true, on all counts: my comment in this regard applies to all
Linux distributions I've encountered (not just the "general purpose"
distributions), even in a minimal install, and a well-organized /etc
helps immensely in unifying system administration procedures.  On the
other hand, that's not the whole of the matter.  My favorite Linux
distribution is Debian, which is one of the better-organized
distributions available, but a sane filesystem hierarchy is only one
component among many of the sort of integration of system design I mean.


> 
> However I suppose there is some inconsistency in *BSD configuration too:
> the first thing that comes to my mind is Apache configuration (which
> configuration complexity could arguably be compared to the one of a
> whole OS...).

Apache configuration is nontrivial, period.  The OS on which it's
installed doesn't change that.


> 
> > , as well -- while not sacrificing significant
> > customization options (which should be fairly obvious considering it's at
> > heart still a source-based system).  Its source-based software management
> > is at least as easily managed as Gentoo's, and even provides more options
> > for how you may choose to manage it (portupgrade, portmaster, et cetera),
> 
> There are alternatives to emerge (paludis for example) in Gentoo (I
> suppose there's always a problem to fix for someone...).

Too true.  Frankly, I don't find the wide range of options as important
as the design of the primary systems.  As such the make and portupgrade
systems for FreeBSD are really the important part, from my perspective,
and they've proven to be quite pretty damned good tools.


> 
> > but succeeds at this while still sticking closer to its "roots" in source
> > code compilation, as all software management within the standard Ports
> > system can be very simply and easily handled via make, rather than
> > layering the idiosyncratic emerge system over everything to achieve ease
> > of management.
> 
> That's a matter of taste: make without emerge is a definitive no-no on
> my servers and a real headache on any system that I don't plan to
> reinstall from scratch. In fact I don't do reinstalls anymore since I
> switched to Gentoo. I went further and don't even do installs anymore
> too as I keep base system images ready to detar on a partition. I found
> it to be more reliable and quicker than distro-based installation
> methods (of course the usual Gentoo install is painfully slow, which is
> what motivated me in the first place).

The whole ports system can be managed by make without in any way
interfering with the effectiveness of other tools such as portupgrade.
It's essentially interchangeable.  For instance, these two commands are
equivalent:

  # cd /usr/ports/print/scribus; make install clean

  # portinstall scribus

. . . and neither in any way precludes the other's use or causes any risk
of inconsistent states, et cetera.  That's sorta my point.

re: installation . . .
FreeBSD installs about as quickly as a minimal Debian install, too.  I'm
less than enthused with any OS that takes longer than twenty minutes
(give or take) to install, these days.  Debian spoiled me in that sense,
and FreeBSD hasn't disappointed me following that precedent.


> 
> > Additionally, FreeBSD provides more extensive software archives,
> 
> I'm surprised to hear this, Gentoo software coverage is huge and truly
> amazing if you consider the unstable part of the Portage tree.

I have yet to see any system with as much software as in Debian's
software archives -- but FreeBSD comes surprisingly close.  Again, it has
been a while, but last I recall Gentoo didn't have more than 15k ports.
FreeBSD does.


> 
> >  and the
> > software in those archives (in the Ports tree, specifically) is generally
> > more thoroughly tested (in other words, no "KDE is broken this week"
> > jokes).
> 
> KDE broken? My parents would be on the phone in an instant (and I try
> not to let their system lag too much behind the tree so they probably
> used all Gentoo stable KDE versions for 18 months now).

I gather, from that, one of two things is true:

  1. Their system doesn't get software updates very often.

  2. Gentoo doesn't break things with new software versions very often
  any longer.


> 
> >   Most system and software management is more straightforward,
> 
> That I can believe easily, there's always room to improve there.

I've encountered a few instances where I wished something was a little
more straightforward with FreeBSD, but I haven't yet encountered any OS
that provides an overall more-straightforward approach to system and
software management.


> 
> >  and
> > while Gentoo has some of the best online documentation in the Linux
> > world, FreeBSD documentation is the best I've ever seen -- not only
> > because it covers pretty much every damned thing you can think of, but
> > also because it is so incredibly well organized.
> 
> The lack of organization is indeed a defect. Not big (it's not a huge
> pile where you spend hours looking for something) but it definitely
> could be improved.

On that subject . . . you might find that some of the FreeBSD
documentation is of great help for experienced Linux admins, too.  That's
particularly true with regard to software that's common to both systems.
I actually originally got Greg Lehey's book, "The Complete FreeBSD" (from
O'Reilly), because it covered subjects woefully underdocumented in the
Linux world.  I found it invaluable for Linux administration reference
material along with a couple other treasures I've encountered along the
way.  The FreeBSD Handbook (an online reference that is actually
organized like a hardcopy book) is more FreeBSD-specific, but so well
organized and presented -- and so complete -- that it can't help but be
useful at times for any Unix-like system.  While I'm at it, there's some
excellent material in Dru Lavigne's "BSD Hacks" book (also from
O'Reilly) -- again, even for Linux systems.

Manpage coverage is not quite as comprehensive as that of Debian, but
then again, what is?  It gets awfully close, though (and doesn't
occasionally tease you with a manpage that just points at an info page,
like Debian does once in a while).


> 
> >   The FreeBSD community
> > may not be as extensive as what you're used to with Linux, but it is also
> > less scattered and fractious, which means you'll probably never notice
> > the difference in how extensive it is unless you're specifically looking
> > for a local community.  Even having been ever-more heavily involved in
> > the more expert-oriented Linux communities in recent years, I find that
> > short of something like the Linux kernel hackers' community or something
> > along those lines, the average knowledge level of the FreeBSD community
> > is greater than that of the Linux communities, too.
> 
> That's the problem when some technology becomes popular (don't advertize
> too much if you are an elitist :-) ).

True, of course.

I figure that by the time FreeBSD's community online support degrades
appreciably, I'll be using something else ("better"), anyway.


> 
> Thanks again,

My pleasure.  Thanks to you, too.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
MacUser, Nov. 1990: "There comes a time in the history of any project when
it becomes necessary to shoot the engineers and begin production."