What Linux distribution to choose for learning Ruby and Ruby

I’m going to jump in here with a few quick comments.

First of all, how MUCH do you want to learn about linux? If you want to
learn quite a bit, then I suggest Gentoo, simply because its virtually
impossible to NOT learn the details about your OS/distro.

When it comes down to learning the basics, I’d actually suggest steering
clear of Fedora/Ubuntu/ect. which are heavily graphic-based (I could be
wrong about Fedora), and pick up something like Debian, Gentoo,
Slackware and such, as they will give you a bit more of an in-depth look
at the system.

It boils down to how much time and effort you want to put into learning
Linux. If you want to learn the graphic enviroment, then take your pick,
but if you wish to learn more of the system itself, then I would suggest
something that is more command-line centered than Ubuntu and the other
major graphic distros.

you want to
at the system.

It boils down to how much time and effort you want to put
into learning
Linux. If you want to learn the graphic enviroment, then take
your pick,
but if you wish to learn more of the system itself, then I
would suggest
something that is more command-line centered than Ubuntu and the other
major graphic distros.

Why? Nothing keeps you from learning and using the standard command line
toolbox and administration tasks in a GUI centric OS - all the tools are
there, it’s up to you to learn and use them.

I use Ubuntu on my work laptop nowadays simply because it had the
easiest
support for the graphics and wireless card and I prefer to spend any
time
fiddling on servers I have to administrate either way. I use this laptop
exactly the same way I used the FreeBSD laptop I had before this - some
window manager with virtual desktops that give me access to a browser,
whatever remote access software I need for work, and a shell. If I need
to
restart a service, I run the same scripts I would anywhere else - that
there’s a menu option for that somewhere could be perceived as added
bonus
but its existance certainly doesn’t affect me.

I also firmly believe that being able to emerge something in Gentoo
teaches
you nothing about the actual ./configure && make && make install cycle
or
debugging it - those that can do that or learn to do so in Gentoo could
very
much do the same in any other distribution. It may be a source based
distribution, but the compilation steps are very different from what is
common between all distributions, and what it triggers in the
background. To
me, there’s not much difference between apt-get and emerge, and many
things
Gentoo teaches you are Gentoo specific.

That is not to bash Gentoo - one advantage of Gentoo is the excellent
documentation and the outstanding forum (well, it was outstanding last
time
I ran Gentoo, which is a few years back). But I really don’t think that
an
individual willing to spend time learning Linux will benefit from one
distro
over another as long as that distro has good support for individuals new
to
the OS. That’s true for all the major players, though Ubuntu may be
the
most newbie friendly. You can always move on to something else later and
realise that if all you do is browse websites, read emails, do basic
clerical work and write code, there really isn’t much difference in what
distribution you use.

Felix

On 02:29 Thu 13 Sep , Felix W. wrote:

Why? Nothing keeps you from learning and using the standard command line
toolbox and administration tasks in a GUI centric OS - all the tools are
there, it’s up to you to learn and use them.

Thing is, most people would prefer to use the GUI to the command-line.
Thats just a way of making sure you learned it.

I use Ubuntu on my work laptop nowadays simply because it had the easiest
support for the graphics and wireless card and I prefer to spend any time
fiddling on servers I have to administrate either way. I use this laptop
exactly the same way I used the FreeBSD laptop I had before this - some
window manager with virtual desktops that give me access to a browser,
whatever remote access software I need for work, and a shell. If I need to
restart a service, I run the same scripts I would anywhere else - that
there’s a menu option for that somewhere could be perceived as added bonus
but its existance certainly doesn’t affect me.

I also tend to run commands via a terminal myself. I find it easier and
in some cases much quicker, but there are also people who won’t touch a
command-line because they have never used one before, and it scares them
to some extent.

I also firmly believe that being able to emerge something in Gentoo teaches
you nothing about the actual ./configure && make && make install cycle or
debugging it - those that can do that or learn to do so in Gentoo could very
much do the same in any other distribution. It may be a source based
distribution, but the compilation steps are very different from what is
common between all distributions, and what it triggers in the background. To
me, there’s not much difference between apt-get and emerge, and many things
Gentoo teaches you are Gentoo specific.

Lets not turn this into a distro-war, which it could easily do.

The install proccess for Gentoo is a great learning experiance, and the
fact you have to go in and actually configure a program (such as X),
teachs you a bit more about the system itself.

While I’m not going to argue about the ./configure && make && make
install part, you do aquire some experiance with LD_FLAGS and CFLAGS and
such, which isn’t something you can do with many others, but that is
probably more beside the point for a new person than anything.

That is not to bash Gentoo - one advantage of Gentoo is the excellent
documentation and the outstanding forum (well, it was outstanding last time
I ran Gentoo, which is a few years back).

Its still fairly good, although I’m messing with the mailing list more
than the forum right now anyways.

But I really don’t think that an
individual willing to spend time learning Linux will benefit from one distro
over another as long as that distro has good support for individuals new to
the OS. That’s true for all the major players, though Ubuntu may be the
most newbie friendly.

My main problem with pointing someone to Ubuntu for leaning Linux is
that so much of everything is already done for you. Ubuntu is a good
distro for some cases (new hardware seems to be something it handles
well), but it is so automated and does so much for you I see it as
telling someone to learn YaST to learn how to handle package managers.

You can always move on to something else later and
realise that if all you do is browse websites, read emails, do basic
clerical work and write code, there really isn’t much difference in what
distribution you use.

The end-product will generally be the same, yes. It is all the same
base code, anyways. What you do to get there, though, differs greatly.

Felix

P.S.

The reason I mainly suggested Gentoo, btw, is I though LFS would be a
bit much for someone new to Linux. I’ve always seen Gentoo as a sort of
‘LFS for the lazy’.

M. Edward (Ed) Borasky wrote:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5iuV8fKMegVjSM8RApQ3AKDJamNBJmBr74o7zxvH0EGlP8lYoACgtnAX
V5SWzgRZoj7anHL3PBG3kNY=
=ckv0
-----END PGP SIGNATURE-----
heh,
you should check out

http://www.trekunited.com/community/index.php?showtopic=14814

26.25 gigaflops for $2500

Reid T. wrote:

GFlops, and that’s just about what I get out of my dual-core Athlon64
heh,
you should check out

http://www.trekunited.com/community/index.php?showtopic=14814

26.25 gigaflops for $2500
the ‘official’?? writeup ( small enough to fit on your desk :wink: )

Thoughts on Choosing a Cluster File System | Administration | Columns

That’s only 2.5 times what I have (in 32-bit arithmetic, anyhow, which
is what the GF10 was). I paid about $700US for my system including
having their tech do the assembly. What’s sad is that it doesn’t look
like there are going to be consumer-grade (Athlon) AMD Quad Cores for
quite a while – they seem to be fighting a losing battle with Intel in
server land and abandoning the gamers.

And it looks like Intel will have a QC laptop chip next year, while
there may never be a quad-core Turion. That 64-processor RISC/VLIW
chip is looking pretty good right about now.

It runs Linux … it has a C compiler … it can’t be a huge stretch to
port Ruby, Erlang or Gambit Scheme/Termite to it. I should check the
floating point out, though – it may only be an integer architecture,
since it’s mostly intended for embedded networking applications.

Reid T. wrote:

right now. But the biggest thing you can get now is about a petaflop.
you should check out

http://www.trekunited.com/community/index.php?showtopic=14814

26.25 gigaflops for $2500
the ‘official’?? writeup ( small enough to fit on your desk :wink: )

forgottenwizard wrote:

The reason I mainly suggested Gentoo, btw, is I though LFS would be a
bit much for someone new to Linux. I’ve always seen Gentoo as a sort of
‘LFS for the lazy’.

Yeah, but even that is too much for most people. We forget that
sometimes =). I’ve had a lot of fun learning difficult things by just
not offering myself any alternative (Vim, dvorak, Slickware, Hebrew),
but most people don’t want to immerse themselves in something new and
confusing and flounder until it startes to make sense.

Anyway, I think that if the poster wants to use Linux primarily as a
vehicle for Ruby/Rails programming, he might not be the type to enjoy
(and spend time) learning all its internals.

Dan

On 9/15/07, Shot (Piotr S.) [email protected] wrote:

hemant:

NOO never install rubygems from apt tree, its broken.

Why not? I’m using them with great success. They land in /var/lib/gems,
I have /var/lib/gems/1.8/bin in my $PATH and everything works perfectly.

Some get lucky. I’ve had nothing but heartache using the apt tree for
Ruby. This comes up pretty often on this list. I’m kind of at the
point now where I think your should do your own build from source.

Todd

Dan Z. wrote the following on 14.09.2007 12:21 :

Anyway, I think that if the poster wants to use Linux primarily as a
vehicle for Ruby/Rails programming, he might not be the type to enjoy
(and spend time) learning all its internals.

There’s one aspect of the OS choice that I don’t think was mentionned in
this thread.

If you are in the position of being both developper and sysadmin, you’d
better start learning the technical details. Here Gentoo or *BSD are far
better than “user-friendly” Linux distributions (at least with Gentoo
you can’t use it witout learning how to manage partitions/LVM volumes,
how grub is installed, how daemons are started, stopped and configured,
what maintenance tasks should be done and automated and so can avoid
shooting yourself in the foot and know what to do in disaster recovery
situations).
Even in a company where there are both dedicated sysadmins and
developpers, the developpers should at least test their software
(installation and run) on systems similar to the production which
usually means the ones the sysadmins know the best. No matter how good
the application code is, if sysadmins can’t make it run properly, it’s
utterly useless.

Even if the question was “What Linux distribution to choose for learning
Ruby and Ruby on Rails”, if the ultimate goal is to put a Rails
application in production, one should think about system
administration…

Lionel.

hemant:

NOO never install rubygems from apt tree, its broken.

Why not? I’m using them with great success. They land in /var/lib/gems,
I have /var/lib/gems/1.8/bin in my $PATH and everything works perfectly.

– Shot

On 9/9/07, M. Edward (Ed) Borasky [email protected] wrote:

What you don’t want to do with CentOS is try to manage packages that
aren’t part of the distro… That way lies madness

Sorry for self-promotion. RubyWorks stack is trying to take care of
that problem for CentOS/RHEL.

As for development desktop, I’d say go with Ubuntu 7. It seems to be
the closest thing to a consumer-grade desktop in Linux world, which is
a good thing because you will not spend as much time as with some
other distros to make network, sound drivers and printers work.

Ubuntu doesn’t compromise the benefits that you get from Linux as a
developer, either. Most important of which is speed. In my experience,
Ruby on Linux beats Ruby on Windows by a factor of 2 to 3 in practical
benchmarks (such as running automated tests for a Rails app, for
example).

On 19:37 Fri 14 Sep , Lionel B. wrote:

confusing and flounder until it startes to make sense.

Anyway, I think that if the poster wants to use Linux primarily as a
vehicle for Ruby/Rails programming, he might not be the type to enjoy
(and spend time) learning all its internals.

He could also just grab a Knoppix LiveCD to play with, if he wants to
try to use Linux for ruby deving (if it actually HAS ruby installed).

There is also a distro out there that uses Ruby for most everything it
can, although I forgot the name.

Would be nice to have some feedback from the OP on this, so we have a
better idea on what we’re looking for.

situations).

Lionel.

Good point, although how far into the internals you want to go will make
a diffrence on choice.

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

point now where I think your should do your own build from source.
your distro, if anything, install everything in /usr/local from source

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?

Todd B. wrote:

Todd

It’s probably better with Gentoo than most other distros and it’s
probably better with Ruby than some other packages with their own
repositories, but unless the distro (or someone outside) has put a
significant amount of effort into integration, you’re right … if you
want to run a bleeding edge Ruby and gems, you should nuke whatever’s on
your distro, if anything, install everything in /usr/local from source
and from the gem repository, and lie to other packages expecting to see
/usr/bin/ruby when they install.

I went through this with R on CentOS 5. It’s a big hassle. R is in good
shape on Debian, but only because there’s a developer in the Debian
community that repackages R and the interfaces to contributed packages.
I never did get the fonts working in R, and I gave up on it.
Fortunately, I didn’t need to load Ruby or gems on this machine. Or
stick with production stable tested configurations from the distro.

On Sun, Sep 16, 2007 at 05:03:07AM +0900, M. Edward (Ed) Borasky wrote:

It’s probably better with Gentoo than most other distros and it’s
probably better with Ruby than some other packages with their own
repositories, but unless the distro (or someone outside) has put a
significant amount of effort into integration, you’re right … if you
want to run a bleeding edge Ruby and gems, you should nuke whatever’s on
your distro, if anything, install everything in /usr/local from source
and from the gem repository, and lie to other packages expecting to see
/usr/bin/ruby when they install.

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.

I went through this with R on CentOS 5. It’s a big hassle. R is in good
shape on Debian, but only because there’s a developer in the Debian
community that repackages R and the interfaces to contributed packages.
I never did get the fonts working in R, and I gave up on it.
Fortunately, I didn’t need to load Ruby or gems on this machine. Or
stick with production stable tested configurations from the distro.

Everything should work swimmingly on Debian (most of the time, at
least),
as long as you only want the version of Ruby currently in the package
repositories and don’t need gems that aren’t packaged for APT. If you
want a different version of Ruby or additional gems, however, you’re
better off installing in /usr/local/bin rather than /usr/bin, as you
said.

On Sunday 16 September 2007 01:29:12 Chad P. 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.

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.

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

-----Original Message-----
From: forgottenwizard [mailto:[email protected]]
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

On 05:03 Sun 16 Sep , M. Edward (Ed) Borasky wrote:
[…]
expecting to see

/usr/bin/ruby when they install.
[…]
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.

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.

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)

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.

Felix

On 06:24 Sun 16 Sep , Felix W. wrote:

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…

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 Sun, Sep 16, 2007 at 07:48:25AM +0900, forgottenwizard wrote:

On 06:24 Sun 16 Sep , Felix W. 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…

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.