What Linux distribution to choose for learning Ruby and Ruby on Rails

This is true. I am often find my self using ports on FreeBSD where on
Ubuntu i have to use "gem install". Also on Ubuntu (Debian) rails goes to
one place, but gems to another and you'll see only gem docs in gem_server,
rather then all documentation on FreeBSD.

···

On Sunday 16 September 2007 01:29:12 Chad Perrin wrote:

One of the things I like about *BSD, actually, is the tendency for
anything not in the base system to end up in /usr/local. This, combined
with the way everything is ultimately based on source distributions of
software and software management is basically built on the fundamental
tools that are available everywhere, adds up to a system that's really
easy to customize with software compiled from source and added into the
system oneself, without screwing up a package management system.

Your mileage may vary, but I've had really good luck with Perl and Ruby
modules on FreeBSD.

--

- Best regards, Nikolay Pavlov. <<<-----------------------------------

Ubuntu (gnome desktop) or Kubuntu (KDE ) if you want easy to get it going, these are definitely easy to install (and based on Debian). After getting them going, though, Ubuntu has a lot less customization you can do. Kubuntu leaves you with more control over the GUI because its KDE. You can set it up to be more Windows like, more OS X like or something else all together.

If you want a lot of flexibility, Gentoo.

If you want to match your servers, go with Fedora or Red Hat, Suse or OpenSuse, or Debian. They're all Linux, but pretty different from eachother in surprising little ways.

It's a tough call. Grab a few older machines, and try installing them and messing with them.

I've even tried YDL (yellow dog linux) for power pc computers (only?). And it has a nice installer, but a terrible interface called E17.

But while you're at it, if you're planning to do Rails, seriously consider OS X as well, you can run Windows on the same machine these days, so you have a one stop dev shop, and OS X is a BSD with a nice Bash. It's pretty popular in the Rails community, and for good reason. It's got a lot of good Rails development tools available, and workflows well established.

That door can really swing both ways, and may be more related to
unfamiliarity with a new system than anything else.

···

On Tue, Sep 11, 2007 at 03:45:41AM +0900, John Joyce wrote:

On Sep 10, 2007, at 1:16 PM, Lionel Bouton wrote:

>I was under the impression that Gentoo tried to get the best from
>several packaging systems, including the port system so I'm curious
>about what *BSD can bring to a Gentoo admin/user and especially one
>having to deal with Ruby gems on a daily basis.
>
perhaps headaches.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Patrick J. LoPresti: "Emacs has been replaced by a shell script which 1)
Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk
quota by 100K; and 3) RUNS ED!!!!!!"

Hi~

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Reid Thompson wrote:

M. Edward (Ed) Borasky wrote:

Thanks!! If my day job ever decides to make me a .NET developer, I'll
keep "mono" in mind. Till then, there's Gentoo. :wink:

I was running gentoo on a 700 mhz laptop til it died a couple of weeks
ago. I get a new PC at work tomorrow - dell 9200, dual core, 64bit,
blah, blah. Trying to decide whether to put straight gentoo or sabayon
on it ( current work pc is ubuntu feisty ). Have you ever looked at
sabayon? http://www.sabayonlinux.org/

Yeah, I've looked at Sabayon -- it's a Gentoo derivative. I'm not a big
fan of derivative distros. The big three full community distros --
Fedora, Debian and OpenSuSE -- are where I think the real action is,
with Gentoo nipping at their heels in some arenas but hopelessly out of
the running in others. For example, I can't imagine running a scientific
workstation with anything other than Gentoo or Debian, and I can't
imagine running a server on anything except CentOS/RHEL, Fedora or
Debian, although I'm sure OpenSuSE is fine for servers, as is its
commercial big brother from Novell.

Since the OP is interested in Ruby and Rails, and since Rails is a
server, I pointed him towards Fedora and CentOS because I think they're
better servers. Debian stable is also an excellent server, but there's a
lot more publicly-available information about administering the Red Hat
family than there is about Debian.

I don't think, for example, you can walk into a Barnes and Noble or
Borders and pick up a book on Debian system administration that's
current with "etch", but you can find oodles of books on Red Hat
Enterprise Linux and Fedora. Of course, if you live in Portland, you can
walk down to Powell's Technical Books and get anything. :wink:

  I have to step in here with a small data point about Gentoo on servers. If you know what you're doing then it can make some of the most stable fast servers around. I'm currently running just under 1000 gentoo servers all serving Rails and ruby apps and I love it.

  That said for learning linux and ror then probably ubuntu or fedora are your safest bets. Gentoo requires quite a but of tweaking to get right, but once you get it right it screams.

  Gentoo is like a meta-distro, in the fact that you can take it and bend it into your own targeted custom distros.

Cheers-
-- Ezra Zygmuntowicz-- Founder & Ruby Hacker
-- ez@engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

···

On Sep 9, 2007, at 9:12 PM, M. Edward (Ed) Borasky wrote:

(Okay, off topic we go, but I can't help it...)

To put it more on topic, could you describe briefly how you can
integrate gems in the package management system on *BSD?

Basically, it requires to write a very simple makefile, a text
description, and generate a hash of the package.

You can find an actual makefile here :

http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/rubygem-actionmailer/Makefile?rev=1.10;content-type=text%2Fplain

If you want to take a look around, you have a list of all the gems
currently managed here :

http://www.freebsd.org/ports/rubygems.html

(Note that rubygem itself can be installed, and is somewhat integrated
into the system too.)

The FreeBSD ports is build around Makefiles, but very standardized, and
those will pilot the usual makefiles of each software or will launch
every other kind of stange command needed to build your software. From
an administrator's point of view, it's very easy (everything build with
make ; make install). From the porter (who maintains that magic layer
of glue between the software and the building management system), it's
sometimes quite more complicated.

If you want all the gory details (and a sample of that great FreeBSD
documentation mindset) :

/.../

  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.

Simpler, somewhat. The real winning point is that, on all my FreeBSD
machines, I can completely wipe out the installed packages with a 'rm
-rf /usr/local', and still have an usable, bootable system. Not that
it's really useful, but it shows what Chad means with the integrated
system - you have a fully functional base that comes with the OS, and
the packages neatly separated. That also means that I can probably find
my way and manage the basics of any relatively recent FreeBSD system out
there : unless the administrator made some very ugly things, I'll find
the basic tools needed to run the box.

Incidentally, since most of the packages' makefiles are patched to force
the installation under /usr/local, the maintainers also usually put
files in "usual" places (config under /usr/local/etc, samples under
/usr/share/examples, docs under /usr/share/docs, etc) enforcing a
stricter cohesion - in my experience.

On the other hand, the FreeBSD ports system is not the universal
panacea, in my experience. I've had unstable systems and applications
using it, requiring sometimes to launch a lengthy re-compilation of many
ports, and the such. But it's infrequent, and the base system is
usually next to indestructible in a server configuration. (I only have
one FreeBSD system in a desktop config.)

/.../

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

No, no. The _basics_ (which deamon to run at startup, and the
parameters to launch them) are centrally managed, but each package still
has its own configuration file, usually the sample file included with
the software, patched to reflect the strict directory structure.

/.../

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 don't know the numbers for GenToo, but FreeBSD has, at the moment,
17620 ports.

/.../

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.

This is the point I really, really like about FreeBSD. Next to every
system utility and library has a man page, and port maintainers are
known to write or convert some for the packages that would lack those.
Aside from that, the FreeBSD handbook is well written, and a good basis
for many tasks.

Fred

···

Le 10 septembre à 22:38, Lionel Bouton a écrit :
--
I'm shameless, nameless, nothing, and noone now. But my soul must be
iron for my fear is naked. I'm naked and fearless. But I'm dead
inside. You see, shit adds up, now I'm dead inside. Hatred, weakness,
and guilt keep me alive at the bottom. (Tool, Bottom)

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 :slight_smile: 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 :slight_smile: ).

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.

···

On Tue, Sep 11, 2007 at 05:38:32AM +0900, Lionel Bouton wrote:

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

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

While the integration of gems into Portage is good, it isn't perfect.
Things I really want, like Ruport, haven't made it into the tree yet, so
I have to mix gems from the gem server with gems bundled into ebuilds.

The way you get a new gem into Portage is file an enhancement request in
bugs.gentoo.org and wait. But once the gem makes it into the tree, a
keyworded ebuild for updates generally shows up in Portage within a day
or two of the gem being released. That ain't gonna happen with Fedora or
Debian as far as I can tell. The same goes for Ruby itself -- it only
takes a day or so for a release to get into Portage.

Chad Perrin wrote:

I'd say there are really four primary aspects to separating distributions
from one another:

  1. software management system (package manager, ports manager(s),
  whatever)

  2. installation system and procedures

  3. community and maintenance policies

  4. software archives and how they're managed

[snip]

I have had zero problems with Ruby that I haven't had, either exactly or
in rough comparability of the nature of the issue, with any Linux
distribution. My experience so far is that Linux distributions tend to
want to override Ruby's preferred management systems (such as gems) a
fair bit more than FreeBSD, though there are some exceptions.

More in general than that, the big wins FreeBSD provides for me over
Gentoo are related to stability, ease of ports management, and the
benefits it grants me over Linux distributions in general (which I've
addressed elsewhere in this thread today). As I'm so fond of saying
lately, your mileage may vary.

You've left out what I consider is another big win for *BSD -- the
kernel is more stable, is more secure, and easier to tune for
performance. Linux performance tools are hacks piled upon gravel. Then
again, *BSD sucks relative to Solaris for performance tools. :wink:

> From: forgottenwizard [mailto:phrexianreaper@hushmail.com]
> Sent: Saturday, September 15, 2007 1:55 PM
> To: ruby-talk ML
> Subject: Re: What Linux distribution to choose for learning
> Ruby and Rubyon Rails
>
> Symlink should work for any /usr/bin/ruby issues if you install is
> locally.
>
> But, on another note, isn't there a way to install gems for
> Ruby that is
> fairly automated but distro-independent?

The only universal approach is to download the gem source, build it and
install it - that should work anywhere. Then you can install any gem
directly via "gem install", though in some cases you may need the standard
build chain, plus any libraries required.

gem install was what I was thinking of, actually.

I don't see why someone couldn't hack together a manager of some sort
for use if they wanted to.

The main problem with that approach is that pretty much all distributions do
not officially support any custom installed packages outside the packet
management system. You will either lose the official support channels (think
SuSE or RHEL) for the software, may have a harder time getting community
support or may run into difficulties when updating/upgrading as custom
compilation is outside the packet management system. This may leave behind
files in unexpected places, change directory permissions, change
dependencies or library versions etc.

True. Of course, this is also why people use chroots for testing.

That is most unfortunate as the server distributions in particular often
ship software several versions out of date for security or stability
reasons, which can result in feature loss or unfixed bugs - RHEL 4.5, for
example, still has Ruby 1.8.1:

Sounds like Debian...

# ruby -v
ruby 1.8.1 (2003-12-25) [x86_64-linux-gnu]
# cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
#

Depending on your environment, this may be impossible to circumvent - in
shared server environments, you may not have the necessary permissions/tools
available, at work policies or SLA requirements may prohibit any custom
installations. At my job, we only use Ruby interally to the engineering
group, so we can get away with customization. If it were used in production,
we'd be using whatever the official channels provide as our SLA states
having to stay 100% within vendor supported options.

That I can understand.

···

On 06:24 Sun 16 Sep , Felix Windt wrote:

> -----Original Message-----
> On 05:03 Sun 16 Sep , M. Edward (Ed) Borasky wrote:

Felix

Felix Windt wrote:

That is most unfortunate as the server distributions in particular often
ship software several versions out of date for security or stability
reasons, which can result in feature loss or unfixed bugs - RHEL 4.5, for
example, still has Ruby 1.8.1:

# ruby -v
ruby 1.8.1 (2003-12-25) [x86_64-linux-gnu]
# cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
#

Feature loss? Maybe. Unfixed bugs are rare in an enterprise OS like RHEL
4 or its rebuild, CentOS 4. Keeping an enterprise server bug-free and
secure, at least for known bugs and vulnerabilities with known fixes, is
as simple as firing up a command line or one of the GUI package update
tools and saying, "Do it!"

Well, on Red Hat, you have to buy the service. :slight_smile:

Depending on your environment, this may be impossible to circumvent - in
shared server environments, you may not have the necessary permissions/tools
available, at work policies or SLA requirements may prohibit any custom
installations. At my job, we only use Ruby interally to the engineering
group, so we can get away with customization. If it were used in production,
we'd be using whatever the official channels provide as our SLA states
having to stay 100% within vendor supported options.

You've just described the fundamentals of IT anywhere. Just about
everyone knows this stuff. It's when developers forget that their
audience is looking for stability that bad things happen. Fortunately,
test-driven developers can get new functionality out faster in the long
run, which is a win for both IT and the developers.

yo creo que eso depende de la persona mmm... por k puedes tener
diferente distribucion y en cualquiera lo puedes instalar ya sea suse
ubuntu, mandriva, fedora, todo depende de ti y cual te lata más yo
creo que loq ue si se debe de respetar es el entorno grafico que debe
ser nome, pues como ruby se mantiene en mac os gnome esta inspirada en
el XD yo voto por SuSe

MacOS X isn't precisely a BSD Unix. It uses a Mach kernel (not a BSD
Unix kernel), and while it uses some basic BSD Unix environment stuff
(borrowed from FreeBSD) wrapped around that Mach kernel, the vast
majority of what you'll interact with is the proprietary stuff wrapped
around *that*. The proprietary stuff, by the way, is basically just a
combination of things derived from classic MacOS and from NeXTSTEP (Steve
Jobs' non-Apple operating system from the early '90s).

MacOS X is really its own animal. It is not classic MacOS, it is not a
BSD Unix, and it is not NeXTSTEP, even though it combines elements from
all three. When developing GUI tools, it's easy to pretend sometimes
that it's NeXTSTEP; when sitting in front of it as an end-user, it's easy
to pretend sometimes that it's classic MacOS; when doing command-line
sysadmin stuff and anything that verges on server work, it's easy to
pretend sometimes that it's a BSD Unix. In each case, though, all you'd
be doing is pretending.

It's better, I think, to simply realize it's not any of those other OSes,
and just think of it as MacOS X.

Your mileage may vary, I suppose.

···

On Mon, Sep 10, 2007 at 02:05:59PM +0900, John Joyce wrote:

But while you're at it, if you're planning to do Rails, seriously
consider OS X as well, you can run Windows on the same machine these
days, so you have a one stop dev shop, and OS X is a BSD with a nice
Bash. It's pretty popular in the Rails community, and for good
reason. It's got a lot of good Rails development tools available, and
workflows well established.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
print substr("Just another Perl hacker", 0, -2);

(Note that rubygem itself can be installed, and is somewhat integrated
into the system too.)

That's what I've used. I find it easier than to screw with creating my
own ports of gems.

On the other hand, the FreeBSD ports system is not the universal
panacea, in my experience. I've had unstable systems and applications
using it, requiring sometimes to launch a lengthy re-compilation of many
ports, and the such. But it's infrequent, and the base system is
usually next to indestructible in a server configuration. (I only have
one FreeBSD system in a desktop config.)

How many desktop systems does one need, anyway?

I'll have two soon -- but one's my laptop, and the other will be my
recreated "game machine". Both will be FreeBSD. Otherwise, all I need
is servers.

No, no. The _basics_ (which deamon to run at startup, and the
parameters to launch them) are centrally managed, but each package still
has its own configuration file, usually the sample file included with
the software, patched to reflect the strict directory structure.

. . . but the sort of basic utilities that are in many cases viewed as
separate packages in most Linux distributions are maintained as part of
the extended OS by the OS development community itself in FreeBSD, which
means that there *are* a lot of tools for FreeBSD that share a more
consistent interface and set of capabilities than one might have come to
expect from working with Linux systems. Such obviously doesn't extend as
far as software like Apache, but it makes the standard command line tools
we all know and love seem just a bit more lovable (and knowable, for that
matter).

This is the point I really, really like about FreeBSD. Next to every
system utility and library has a man page, and port maintainers are
known to write or convert some for the packages that would lack those.
Aside from that, the FreeBSD handbook is well written, and a good basis
for many tasks.

s/many/most common/

The range of tasks covered by the FreeBSD Handbook boggles my mind, and
the clarity with which it does so is . . . well. I'll stop babbling
about it now. In short, it's great.

···

On Tue, Sep 11, 2007 at 06:30:06AM +0900, F. Senault wrote:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Larry Wall: "A script is what you give the actors. A program is what you
give the audience."

I just checked. Compared with Debian's more than 18k packages (not sure
how many more -- I haven't checked lately) and FreeBSD's more than 17k
ports, it looks like Gentoo provides just over 11k. I think that puts
Gentoo solidly in second place for Linux distributions, but well behind
FreeBSD.

···

On Tue, Sep 11, 2007 at 07:00:50AM +0900, Chad Perrin wrote:

On Tue, Sep 11, 2007 at 05:38:32AM +0900, Lionel Bouton wrote:
> Chad Perrin wrote the following on 10.09.2007 21:12 :
>
> > 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.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
John W. Russell: "People point. Sometimes that's just easier. They also use
words. Sometimes that's just easier. For the same reasons that pointing has
not made words obsolete, there will always be command lines."

F. Senault wrote:

Basically, it requires to write a very simple makefile, a text
description, and generate a hash of the package.

You can find an actual makefile here :

ViewVC Repository Listing

If you want to take a look around, you have a list of all the gems
currently managed here :

FreeBSD Ports Search
  
Exactly the information I needed :slight_smile: I looked around, inspecting several
Makefiles and I find the process roughly as simple as a gentoo ebuild
based on the ruby and gems eclass.
The Makefile syntax isn't exactly my personal preference but it's a
matter of taste.

(Note that rubygem itself can be installed, and is somewhat integrated
into the system too.)

The FreeBSD ports is build around Makefiles, but very standardized, and
those will pilot the usual makefiles of each software or will launch
every other kind of stange command needed to build your software.

Brings back memories (I've actually briefly used FreeBSD long ago). From
a quick count (ruby + rubygems vs dev-ruby and other ruby-related
packages scattered across the Portage tree) it seems there's about the
same ruby support in the ports and in the Portage tree.

[...]
Simpler, somewhat. The real winning point is that, on all my FreeBSD
machines, I can completely wipe out the installed packages with a 'rm
-rf /usr/local', and still have an usable, bootable system. Not that
it's really useful, but it shows what Chad means with the integrated
system - you have a fully functional base that comes with the OS, and
the packages neatly separated.

I see you like clean and lean systems a lot too :slight_smile:

In a similar way you can use the /var/lib/portage/world as a reference
for all the packages you installed on top of the system on Gentoo too.
It's a little different as you'll use the package manager to clean the
system for you and not a simple rm -rf (I concede simple is hard to
argue against). But package managers has their virtues: you don't lose
the configuration files modifications when uninstalling, you even get
archives created for you with 3-way merging of new configuration files
when upgrading, can track everything (the (un)installs are logged, all
files referenced, hashed for tampering checks) dependencies are
maintained (although I see ports supports deps too) and even dynamic
based on your configuration.
I like this world file a lot because it doesn't store all your package
but only the ones you *requested*. Dependencies can be easily cleaned up
thanks to this (with a small dose of precaution involving a dynamic link
checker because of the nature of a source based distribution).

[...] That also means that I can probably find
my way and manage the basics of any relatively recent FreeBSD system out
there : unless the administrator made some very ugly things, I'll find
the basic tools needed to run the box.

It's probably true on any Unix system you mastered (I remember having an
HP admin and me in front of an HP-UX box and even though I had far more
experience, methodology and general CS knowledge, here I was the student
99% of the time...).

[...]
I don't know the numbers for GenToo, but FreeBSD has, at the moment,
17620 ports.

Ok even if it can be difficult to compare, FreeBSD probably wins :slight_smile:
Gentoo has more than 12000 packages in the main tree. Many have several
stable versions, but it's not more common to have what is called 'SLOT
'ed packages (packages where it's meaningful to have several versions
installed simultaneously, some libs and autoconf are known for this)
than packages without any stable version at all.

There may be a catch: I don't know for FreeBSD, but other distributions
get more packages because they split some packages in several
sub-packages (client, server, libs, headers, doc,
<programming-language>-lib...), Gentoo never does this and always ship
one and only one package which may install only what the admin needs
according to the global system configuration.
Some may want to count Gentoo overlays, but very few have what I
consider production quality software.

In short, I'm pleasantly surprised.

/.../

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.
    
This is the point I really, really like about FreeBSD. Next to every
system utility and library has a man page, and port maintainers are
known to write or convert some for the packages that would lack those.
  
For Gentoo it's a *requirement* to document software. IIRC it's a policy
violation to mark undocumented software stable in the tree.

Aside from that, the FreeBSD handbook is well written, and a good basis
for many tasks.

Fred
  
Thanks, you cleared up some misconceptions (or outdated impressions) of
mine. At this point I guess I'll have to install FreeBSD on a system to
play with (in the end, it's always a matter of taste and you can't get
the taste without a test...).

Lionel

Ezra Zygmuntowicz wrote:

    I have to step in here with a small data point about Gentoo on

servers. If you know what you're doing then it can make some of the most
stable fast servers around. I'm currently running just under 1000
gentoo servers all serving Rails and ruby apps and I love it.

You should definitely brag about that on the Gentoo Weekly News. As far
as I know, your 1000 Gentoo servers is more than all the other Gentoo
servers in the world *combined*. :slight_smile:

Yes, it's possible to make a stable fast Gentoo server, and it's a lot
easier than it used to be since they came out with the LiveDVD. It's
precompiled for i686, which is fast enough for most purposes, and has
just about everything on it except "rubygems", "rake" and "rails".

    That said for learning linux and ror then probably ubuntu or fedora
are your safest bets. Gentoo requires quite a but of tweaking to get
right, but once you get it right it screams.

    Gentoo is like a meta-distro, in the fact that you can take it and
bend it into your own targeted custom distros.

I'd say the same goes for (pure) Debian. The base network install CD is
under 200 MB, and you can even boot up a Debian box from scratch over
the network from no more than half a dozen floppies, and if you're
lucky, you only need two. Once you get the base built, you can rebuild
packages from source if you need to for speed as easily as you can
emerge a package from source with Gentoo. But ... I went down the Gentoo
path and I'm not turning back. :slight_smile:

M. Edward (Ed) Borasky wrote the following on 11.09.2007 04:50 :

While the integration of gems into Portage is good, it isn't perfect.
Things I really want, like Ruport, haven't made it into the tree yet, so
I have to mix gems from the gem server with gems bundled into ebuilds.

To solve this I've setup an overlay of my own. As I don't want to
circumvent the package manager and develop software that I can't release
as opensource, this is the only workable way for me. When I need a new
gem, I simply add an ebuild to my overlay: the whole process including
distribution to servers takes 5 minutes on average.

If you take a quick look at gems based ebuilds, I'm sure you can setup a
new overlay of your own on a very short notice. With layman and a svn
server you can distribute your overlay to all your servers easily.

Lionel

Actually, I think Debian is using 1.8.5 currently on the stable version.
At least, that's what's on the Etch system I have in the corner, waiting
for me to copy a few files off it, wipe it, and turn it into some kind of
FreeBSD-based network appliance.

Sarge, on the other hand, is using 1.8.2. Of course, that's not even the
current Stable release, and is in legacy support right now.

I'm not sure what Lenny, the current Testing release, is using. I
haven't touched Lenny yet, since FreeBSD is my primary OS choice these
days.

···

On Sun, Sep 16, 2007 at 07:48:25AM +0900, forgottenwizard wrote:

On 06:24 Sun 16 Sep , Felix Windt wrote:

> That is most unfortunate as the server distributions in particular often
> ship software several versions out of date for security or stability
> reasons, which can result in feature loss or unfixed bugs - RHEL 4.5, for
> example, still has Ruby 1.8.1:

Sounds like Debian...

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Leon Festinger: "A man with a conviction is a hard man to change. Tell him
you disagree and he turns away. Show him facts and figures and he questions
your sources. Appeal to logic and he fails to see your point."

I just checked. Compared with Debian's more than 18k packages (not sure
how many more -- I haven't checked lately) and FreeBSD's more than 17k
ports, it looks like Gentoo provides just over 11k. I think that puts
Gentoo solidly in second place for Linux distributions, but well behind
FreeBSD.
  

See the note about packages splitted in many subpackages in my reply to
Fred. I was thinking of Debian and Ubuntu when writing it... IIRC I had
to install around 10 packages on Ubuntu in March this year to get
roughly the same result than emerge ruby... I must admit I wasn't happy
about it especially as at the time Rails was installed with rubygems
manually so all the missing deps where found with runtime failures :frowning:
In the end Rails didn't even get to work correctly because of different
loadpaths in the gems and the deb packaged libraries. In short the
Ubuntu/Debian admin followed a Rails on Ubuntu tutorial and failed
because making the system consistant was hard even for plain simple
Rails. I sincerely hope Debian is better but I still have doubts (IIRC
the Ubuntu packages were the original Debian ones without any Ubuntu patch).

At least the dependency hell on Debian is benign compared to Fedora. One
time I managed to have eclipse installed on a slow Gentoo box faster
than a colleague on a fast Fedora box without even trying... yum had to
fetch around 70 packages for him while my configuration only generated
15-20 dependencies !

On a positive note, it doesn't seem FreeBSD was chopped in so many
pieces (at least for Ruby I only noticed a ruby18-doc that isn't counted
in Gentoo but there anyway in the basic ruby ebuild).

Lionel

Chad Perrin wrote:

Chad Perrin wrote the following on 10.09.2007 21:12 :

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.

I just checked. Compared with Debian's more than 18k packages (not sure
how many more -- I haven't checked lately) and FreeBSD's more than 17k
ports, it looks like Gentoo provides just over 11k. I think that puts
Gentoo solidly in second place for Linux distributions, but well behind
FreeBSD.

Gentoo's "unstable" doesn't really exist in the same sense that Debian
has "stable", "testing" and "unstable". There's really three separate
classes of packages in Gentoo ... stable, architecture-keyworded (works
for the most part on some architectures but not truly stable on all of
them) and packages in what are called "overlays" -- repositories where
the really edgy stuff lives until it (sometimes) gets moved into the
main Portage tree.

I've run both amd64 and x86 systems successfully with a mix of keyworded
packages and packages from overlays, but I don't recommend it unless
you're a hard-core Gentoo freak like me (learn to love
/etc/portage/package.mask). I have three machines, though, so I can
survive if I have to take one down for 24 hours to clean it up from
scratch. :slight_smile:

Yes, Debian has more packages. I went from Red Hat 9 to Debian ("woody")
when Red Hat spun off Fedora. The main reason I switched from Debian to
Gentoo about six months later was that Debian had this FSF religion
about "the Java trap", and a lot of the software I wanted to run was
written in Java. Gentoo had no such religion -- they had Java, most of
the Java packages I wanted and it all worked. The other nice thing about
Gentoo is that I've found it easier to integrate source packages that
aren't in the tree or one of the overlays that it is to integrate the
same package built from source into a Debian or Red Hat system.

···

On Tue, Sep 11, 2007 at 07:00:50AM +0900, Chad Perrin wrote:

On Tue, Sep 11, 2007 at 05:38:32AM +0900, Lionel Bouton wrote: