Mongrel 3.15, Ubuntu and Park place (S3)

What Linux/BSD distros out there make the RoR kids happy?

GravyFace wrote:

What Linux/BSD distros out there make the RoR kids happy?

I do not really see your point.
Do not install ruby from your distribution.

download the sources of ruby,
upack them with tar, cd to the directory
./configure
make
make test
su
make install
exit
download rubygems
upack it with tar
install it with
ruby setup.rb install

and then use ruby gems for the rest:

gem install rails

etc.

Please, have a short look at files called README and INSTALL
instead of just copy-pasting from this mail, which might contain typing
errors or so. Just the point is: It is not too hard to install ruby
on Linux or BSD or even Windows 2000/XP with cygwin.

Best regards,

Karl

On 5/1/06, Karl B. [email protected] wrote:

GravyFace wrote:

What Linux/BSD distros out there make the RoR kids happy?

I do not really see your point.

I don’t see a point either, I see a question. :slight_smile:

I was just curious, that’s all – there’s seems to be a lot of Debian
hate mail flowing through the list so I was interested to hear what
distro is feeling the love.

I’ve had great luck with RHEL4 and CentOS4 (usually with SELinux
enabled).

Karl B. wrote:

GravyFace wrote:

What Linux/BSD distros out there make the RoR kids happy?

I do not really see your point.
Do not install ruby from your distribution.
That’s the point… You should be able to install ruby from the
distribution. That way, you can have the distribution take care of
things like security patches, dependencies and uninstalls for you.
Hell, that’s why we have distributions :slight_smile:

On Mon, May 01, 2006 at 02:30:42PM -0400, Austin Z. wrote:
} On 5/1/06, Gregory S. [email protected] wrote:
} >} And no, blasting more package install commands at me when “apt-get
} >} install ruby” should be enough is not a fix. The problem still
comes
} >} up, it is reported about once a week, and nobody notices or cares.
} >} Bitching and whining is about the only thing I’ve got time for, and
} >} since I didn’t break it and the people involved don’t listen to
} >} complaints or consider this a bug (see your own explanations above
as
} >} to why nobody in control thinks it’s a bug) I don’t feel
obligated
} >} to do much to help fix it.
} >[…]
} >You seem to feel an extraordinary level of entitlement about this.
Why is
} >it someone else’s responsibility to solve your problems when you are
} >providing neither money nor so much as a pleasant word as
compensation?
}
} As one of the most vocal people about the insanity that Debian’s
} supposedly “sane” model causes, I will state something unequivocally:
}
} Debian claims to protect people from upstream issues. It doesn’t.

That is an interesting statement. I haven’t seen that claim anywhere.
Can
you point to a reference?

} More importantly, it doesn’t actually protect upstream developers from
} Debian’s insanity. Zed’s problem, I think, is that he doesn’t use
} Debian. Neither do I. But we have users who do use Debian. We feel a
} responsibility to those users of our packages to support them. But the
} problem isn’t in our software. The problem is – and always has been
} – Debian.

To which packages do you refer?

} I have actually started saying something like: “It looks like a Debian
} problem. I don’t use Debian. I can’t help you. Once you have the
} Debian side solved, if you’re still experiencing a problem, I’ll be
} happy to help you.”

This is a reasonable response, given that you don’t, yourself, use the
platform that is causing problems.

} Ruby on Debian is broken. No, that’s too kind. Ruby on Debian is a
} disaster. And this is the team that wants RubyGems to change to
} support its disastrous model? No, thanks.

It seems to work well for a lot of people, myself included.

As for RubyGems, my only problem with it is that it takes significant
hoop-jumping to get it to install itself and subsequent gems in the
directory of your choice. It really wants to be in /usr/lib, whether I
want it there or not.

} -austin
–Greg

On Mon, May 01, 2006 at 02:43:13PM -0300, Marcelo Bello wrote:
} Ruby On Rails is a success (at least within us) because it has
reasonable
} defaults and conventions.
}
} Now you are saying that debian is nice because it has everything we
need…
} it is just a lot of effort to figure it out… but at least some linux
} hacker could easily build a small-footprint system.

Debian is a general purpose GNU/Linux distribution. Ruby on Rails is a
framework for developing a particular kind of web application. These are
apples and oranges.

} What’s the ratio of people building small footprint systems versus
people
} that just don’t care about package size and just want things working
as they
} expect (i.e. the principle of Least Surprises). Why default to the
least
} used scenario?

Various Debian-based distributions exist to cater to such people. Ubuntu
caters to a certain group of such users. Xandros caters to another
group.
Knoppix caters to another group. There may not be a Debian-based
distribution that caters to Ruby on Rails developers (though there was
talk
of a Knoppix-based CD specifically for RoR). Debian is flexible enough
that
those of us who have grown comfortable with it find it easy to use it to
develop RoR apps, but its default behavior is designed to be consistent
across thousands of dissimilar packages and, therefore, may not be
perfectly suited to some particular packages.

} Debian’s policies are the opposite of RoR’s policies - and that is
what
} makes me like RoR by the way.

Apples and oranges…

} But yes, there are many dists out there…
–Greg

On 5/1/06, Karl B. [email protected] wrote:

GravyFace wrote:

What Linux/BSD distros out there make the RoR kids happy?
It is not too hard to install ruby
on Linux or BSD or even Windows 2000/XP with cygwin.

… just avoid cygwin like the plague. It has a fundamental disconnect
with the underlying platform. If you want a unix-like environment, run
a VMWare Server with a Unix on it.

-austin

I’m probably just stepping into a flamewar here, but if you want to
run Rails on an Apple machine, you have to jump through some hoops too
– but those hoops are well-documented, and they really don’t seemed
to have inspired quite the same reactions as the Debian hoops have.

And all the negativity really doesn’t get to the core question, which
is, besides the Apple alternative, which is pricey at best – and
useless if you’ve already got an x86 server on your desk – what’s the
most stress-free *nix distro?

(The “Scale with Rails” guys advocate Open Solaris, of all things, but
they’re running server farms, or something.)


Giles B.
http://www.gilesgoatboy.org

On 5/1/06, Gregory S. [email protected] wrote:

On Mon, May 01, 2006 at 02:30:42PM -0400, Austin Z. wrote:

On 5/1/06, Gregory S. [email protected] wrote:
As one of the most vocal people about the insanity that Debian’s
supposedly “sane” model causes, I will state something unequivocally:

Debian claims to protect people from upstream issues. It doesn’t.
That is an interesting statement. I haven’t seen that claim anywhere.
Can you point to a reference?

Don’t dissemble. You yourself said that Debian is based on strong QA.
That’s an intent to protect people from upstream (e.g., developer)
issues. That’s the whole point of the QA process.

More importantly, it doesn’t actually protect upstream developers
from Debian’s insanity. Zed’s problem, I think, is that he doesn’t
use Debian. Neither do I. But we have users who do use Debian. We
feel a responsibility to those users of our packages to support them.
But the problem isn’t in our software. The problem is – and always
has been – Debian.
To which packages do you refer?

In Zed’s case, this should obviously be Mongrel. In my case, it’s as
simple as PDF::Writer that has been broken because of Debian nonsense.

I have actually started saying something like: “It looks like a
Debian problem. I don’t use Debian. I can’t help you. Once you have
the Debian side solved, if you’re still experiencing a problem, I’ll
be happy to help you.”
This is a reasonable response, given that you don’t, yourself, use the
platform that is causing problems.

It’s also a reasonable response, when you get a significant number of
people using the same platform (Debian) complaining about certain
issues, and you get arrogant pedantry from the people who maintain that
platform, to ask WTF is wrong with the platform that it can’t get this
simple stuff right.

Ruby on Debian is broken. No, that’s too kind. Ruby on Debian is a
disaster. And this is the team that wants RubyGems to change to
support its disastrous model? No, thanks.

It seems to work well for a lot of people, myself included.

As for RubyGems, my only problem with it is that it takes significant
hoop-jumping to get it to install itself and subsequent gems in the
directory of your choice. It really wants to be in /usr/lib, whether
I want it there or not.

shrug

As far as I’m concerned, it belongs in /usr/lib. But that’s just me. If
it isn’t apparent, I don’t think that the Debian issues are worth
Rubyists worrying about. Let the Debian people stew in their own mess.

-austin

I’m running freebsd on a development server with rails running on
apache/fastcgi. I haven’t had this running on a production server yet,
but it was easy to set up and i’ll be using it on a production setup
later next month.

Steve

On 5/1/06, Gregory S. [email protected] wrote:

On Mon, May 01, 2006 at 02:43:13PM -0300, Marcelo Bello wrote:
Debian is a general purpose GNU/Linux distribution. Ruby on Rails is a
framework for developing a particular kind of web application. These are
apples and oranges.

Hello, I’d like to chime in here. I just spent the whole afternoon
moving a working application from my OS X box to an Ubuntu server.
Ubuntu is miles ahead of Debian, so I can only imagine how bad Debian
could actually be here.

Here’s what I had to do to make it work.

i) Add some random package source to my apt/source.list
ii) Say yes to installing unauthenticated packages
iii) Upgrade ruby to the ruby that is only available from the third
party (unauthenticated) source
iv) Install irb seperately since some wiseass decided I might not need
it

Who care about apples and oranges? I care if things work or not. I
think it is bloody irresponsible to know that something DOESN’T WORK
and keep it that way. All this random configuration and hoop jumping
is the reason why I like Rails - it’s history.

Quick question: What do most people using Ruby these days use it for?
Hint: Ruby on Rails.

Now, WTF is Ruby doing stuck at 1.8.3 when it is going to cause
problems with the NUMBER ONE APPLICATION BEING USED? What’s the
problem, the apple or the orange?

Ruby from Darwinports works just fine. Both are packaging systems.
I’ll leave it to you to tell us why the QA process is harming users
rather than helping them?

IMHO, I don’t need protection from upstream developers. I rather need
protection from obsolete packages … caused in the main by a ‘QA’
process.

– G.

On Mon, May 01, 2006 at 04:24:47PM -0400, Austin Z. wrote:
} On 5/1/06, Gregory S. [email protected] wrote:
} >On Mon, May 01, 2006 at 02:30:42PM -0400, Austin Z. wrote:
[…]
} >> Debian claims to protect people from upstream issues. It doesn’t.
} >That is an interesting statement. I haven’t seen that claim anywhere.
} >Can you point to a reference?
}
} Don’t dissemble. You yourself said that Debian is based on strong QA.
} That’s an intent to protect people from upstream (e.g., developer)
} issues. That’s the whole point of the QA process.

The QA I was referring to is about keeping packages from interfering
with
one another. This has to do with the packaging system, not the upstream.
Yes, Debian has its own bug tracking system, but Debian developers are
expected to work with the upstream to address issues not related to
packaging.

} >>More importantly, it doesn’t actually protect upstream developers
} >>from Debian’s insanity. Zed’s problem, I think, is that he doesn’t
} >>use Debian. Neither do I. But we have users who do use Debian. We
} >>feel a responsibility to those users of our packages to support
them.
} >>But the problem isn’t in our software. The problem is – and always
} >>has been – Debian.
} >To which packages do you refer?
}
} In Zed’s case, this should obviously be Mongrel. In my case, it’s as
} simple as PDF::Writer that has been broken because of Debian nonsense.
[…]

I can’t say have much use for either, but I just installed them
successfully under Debian (gem install -r -y pdf-writer && gem install
-r
-y mongrel). I also ran mongrel’s unit tests successfully and ran
PDF::Writer’s demo successfully (at least it created a PDF and didn’t
complain about anything).

By the way, it might be nice if your README said something about running
the demo with ruby -rubygems or if your demo.rb actually required
rubygems.
It might also be nice to have unit tests, as mongrel does.

} >As for RubyGems, my only problem with it is that it takes significant
} >hoop-jumping to get it to install itself and subsequent gems in the
} >directory of your choice. It really wants to be in /usr/lib,
whether
} >I want it there or not.
}
} shrug
}
} As far as I’m concerned, it belongs in /usr/lib. But that’s just me.
If
} it isn’t apparent, I don’t think that the Debian issues are worth
} Rubyists worrying about. Let the Debian people stew in their own mess.

This isn’t just Debian users’ problem. Anyone on any *nix who doesn’t
have
root access but wants to play around with gems has to jump through those
same hoops.

} -austin
–Greg

Giles B. wrote:

And all the negativity really doesn’t get to the core question, which
is, besides the Apple alternative, which is pricey at best – and
useless if you’ve already got an x86 server on your desk – what’s the
most stress-free *nix distro?
If I had to guess, I’d say FreeBSD - check out http://www.flpr.org for
how simple it is. I haven’t tried it yet, but 37s use it, among others.

On Mon, May 01, 2006 at 08:45:14PM +0000, Guido S. wrote:
} On 5/1/06, Gregory S. [email protected] wrote:
} >On Mon, May 01, 2006 at 02:43:13PM -0300, Marcelo Bello wrote:
} >Debian is a general purpose GNU/Linux distribution. Ruby on Rails is
a
} >framework for developing a particular kind of web application. These
are
} >apples and oranges.
}
} Hello, I’d like to chime in here. I just spent the whole afternoon
} moving a working application from my OS X box to an Ubuntu server.
} Ubuntu is miles ahead of Debian, so I can only imagine how bad Debian
} could actually be here.

Ubuntu is miles ahead of Debian… for certain purposes. You snipped the
part of my post about Debian being a general purpose distribution, not
optimized for use by RoR developers. Neither is Ubuntu.

} Here’s what I had to do to make it work.
}
} i) Add some random package source to my apt/source.list

Ubuntu’s problem, not related to Debian.

} ii) Say yes to installing unauthenticated packages

This is a feature, not a bug.

} iii) Upgrade ruby to the ruby that is only available from the third
} party (unauthenticated) source

Ubuntu’s problem, not related to Debian.

} iv) Install irb seperately since some wiseass decided I might not need
it
[…]

Perfectly reasonable given that the package maintainers have no reason
to
inflict irb on those who are simply running existing Ruby scripts rather
than developing them.

} Quick question: What do most people using Ruby these days use it for?
} Hint: Ruby on Rails.

Say that on the Ruby list and see what kind of flamewar you provoke. In
the
meantime, ask yourself why you expect a distribution optimized for
desktop
use to be optimized for web app development in Ruby.

} Now, WTF is Ruby doing stuck at 1.8.3 when it is going to cause
} problems with the NUMBER ONE APPLICATION BEING USED? What’s the
} problem, the apple or the orange?

It has to do with release cycles. Ubuntu releases (or tries to) every
six
months. The December release of 1.8.4 occurred after the October release
of
Ubuntu 5.10. The next Ubuntu release (6.06) is scheduled for June and
will
include Ruby 1.8.4. I found the information about Ubuntu releases at
http://www.ubuntu.com/ubuntu/releases

} Ruby from Darwinports works just fine. Both are packaging systems.
} I’ll leave it to you to tell us why the QA process is harming users
} rather than helping them?
}
} IMHO, I don’t need protection from upstream developers. I rather need
} protection from obsolete packages … caused in the main by a ‘QA’
} process.

Any distribution has its tradeoffs. That’s why there are so many. If you
don’t like the tradeoffs of Ubuntu, pick a different distribution. Be
sure
you understand the tradeoffs when you make your choice.

} – G.
–Greg

Interesting thread. As a non-linux person, I attempted about a month
ago to install a linux server for rails hosting (development only,
inside VMWare). My choice was to go with debian based distro to have
an easier life with software upgrades and installations.

Well, what a disaster it was. I tried Ubuntu Server and Debian stable.
After running into the usual issues (Ruby 1.8.3 on Ubuntu and no
instructions on Debian) and numerous posts to support forums and
visits to IRC channels I gave up the whole idea. In total, I wasted
about two weeks of time, at one point an Ubuntu maintainer even tried
to convince me that Ubuntu ships Ruby 1.8.4 :wink:

In retrospect, I should have stayed with Win2k3 and live with the
slower performance.

Just my two cents.

Rafael

}
} i) Add some random package source to my apt/source.list

Ubuntu’s problem, not related to Debian.

The funny thing about Ubuntu (the new beta) is, that you even need this
in order to install irb, ri and rdoc!

So the included Ruby is broken for somebody who want to use external
gems which rely on irb&co.

Jonathan

Rafael S. wrote:

Ubuntu maintainer even tried
to convince me that Ubuntu ships Ruby 1.8.4 :wink:
Dapper does. I’m running Breezy with Dapper’s ruby1.8 and ruby1.8-dev
packages, and everything’s working fine. Admittedly it’s not an ideal
situation, but it beats checkinstall.

Pat M. wrote:

cd /usr/ports/lang/ruby18 && make install clean

That’s how the REAL 1337 h4x0rz do it OMG LOL!!1one

The real hackers do

cd /usr/ports/www/rubygem-rails && make install clean

and get the easiest way to install rails and several libraries like the
native mysql, postgresql or sqlite bindingngs, fastcgi or
memcache-client.

Jonatahn

As for RubyGems, my only problem with it is that it takes significant
hoop-jumping to get it to install itself and subsequent gems in the
directory of your choice. It really wants to be in /usr/lib, whether I
want it there or not.

I had no problems forcing Rubygem to live in /usr/local/ on FreeBSD or
in /usr/ports/devel/ruby-gems/work/fake-root on OpenBSD.

AFAIK you just need to set GEM_HOME or so for the install.

Jonathan