Rails - Apr 2006 - Mongrel 3.15, Ubuntu and Park place (S3)

Hello. I installed under Ubuntu (Dapper) Park Place. I followed the
instructions given at the RedHanded site. I get the following mongrel
error when launching the application:

** Please login in with `admin'' and password `pass@word1''
** You should change the default password or delete the admin at
soonest
chance!/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:584:in
`register'': undefined method `resolve'' for
nil:Mongrel::URIClassifier
(NoMethodError)
        from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:720:in
`uri''
        from /usr/local/lib/site_ruby/1.8/parkplace.rb:45:in `cloaker_''
        from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:703:in
`listener''
        from /usr/local/lib/site_ruby/1.8/parkplace.rb:44:in `cloaker_''
        from /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:661:in
`initialize''
        from /usr/local/lib/site_ruby/1.8/parkplace.rb:43:in `serve''
        from /usr/bin/parkplace:28

I did some research attempting to fix this issue, but without luck.
Any ideas form the mongrel/parkplace people?

Thank you.

Hey,

What you''re experiencing is the annoying habit of Debian to not install
half of every package you intend to use.  By default it installs only a
bare ruby carved out of the main source, and then separates just about
everything else you need to compile extensions.  Since a *huge* number of
gems and software for ruby requires a compiling extensions, this means you
can''t use just about anything on the internet without installing a
billion
other debian packages.

I''m sure there''s some information on the other 100,000,000,000
debian
packages you''ll need in addition to ruby just to use ruby.  Make sure
you
remember to install the following as well:

1) letters-a-c, letter-d-e, etc.  You need these to type.
2) tcpip-header-bytes-0-40, etc.  Without this you''re missing tcp/ip.
3) gcc-headers, gcc-compiler, gcc-preprocessor, gcc-assembler,
gcc-backend-c, gcc-backend-c++, gcc-documentat-page-1,
gcc-documentation-page2 and lots of other gcc packages.
4) Then anything that says ruby in it, just in case.

And always remember, the people doing debian know a lot more about how
ruby works than you''ll ever know, and I''m sure they are chock
full of
explanations (but not solutions) to nearly every complaint leveled at
them.  See, that''s what smart people do, they explain rather than
listen.
I know because I''m smart and I love explaining things to people.

Can anyone tell I''m incredibly annoyed at the state of the debian
packages?  Is there a way to get this fixed for good?  Can we *please*
*always* ***always*** install the gear needed to compile new extensions
and install any gem?  That''d be super fresh for sure.

Hell, at least a damn message that says, "If you plan to do anything with
anything related to ruby ever then you probably want to install [INSERT
200 PACKAGES HERE] as well."

That''d be awesome.  Thanks.

Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/

P.S. I''m going to write up what you need to do and put it on the
Mongrel
site.  Basically you need to install a few more packages and make sure
that the http11 extension gets created.

> Hello. I installed under Ubuntu (Dapper) Park Place. I followed the
> instructions given at the RedHanded site. I get the following mongrel
> error when launching the application:
>
> ** Please login in with `admin'' and password `pass@word1''
> ** You should change the default password or delete the admin at
> soonest
> chance!/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:584:in
> `register'': undefined method `resolve'' for
nil:Mongrel::URIClassifier
> (NoMethodError)
>         from
> /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:720:in
> `uri''
>         from /usr/local/lib/site_ruby/1.8/parkplace.rb:45:in
`cloaker_''
>         from
> /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:703:in
> `listener''
>         from /usr/local/lib/site_ruby/1.8/parkplace.rb:44:in
`cloaker_''
>         from
> /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:661:in
> `initialize''
>         from /usr/local/lib/site_ruby/1.8/parkplace.rb:43:in
`serve''
>         from /usr/bin/parkplace:28
>
> I did some research attempting to fix this issue, but without luck.
> Any ideas form the mongrel/parkplace people?
>
> Thank you.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Hi Zed,
> What you''re experiencing is the annoying habit of Debian to not
install
> half of every package you intend to use....
Yeah, this is annoying as hell. We already discussed this a while back. If 
I remember correctly, even Matz defended this or at least said we should 
show more respect. He himself uses Debian as do a lot of other Ruby 
committers. It was suggested that there would be a virtual package that 
links to all the others, but I haven''t checked if this was actually
done.

-Sa?a Ebach

On Sun, Apr 30, 2006 at 08:16:23PM -0700, zedshaw@zedshaw.com wrote:
} What you''re experiencing is the annoying habit of Debian to not
install
} half of every package you intend to use.  By default it installs only a
} bare ruby carved out of the main source, and then separates just about
} everything else you need to compile extensions.  Since a *huge* number of
} gems and software for ruby requires a compiling extensions, this means you
} can''t use just about anything on the internet without installing a
billion
} other debian packages.

Gee, yeah, that''s terrible. I had a whole lot of trouble when I was
trying
to install... no, wait, everything worked pretty much perfectly. Hm. I
installed ruby, ri, and irb. And librmagick-ruby. And libdbd-pg-ruby. And,
oddly, I never had a need to compile an extension through a gem install
since the packages already existed, precompiled.

} I''m sure there''s some information on the other
100,000,000,000 debian
} packages you''ll need in addition to ruby just to use ruby.  Make sure
you
} remember to install the following as well:
} 
} 1) letters-a-c, letter-d-e, etc.  You need these to type.
} 2) tcpip-header-bytes-0-40, etc.  Without this you''re missing tcp/ip.

Oh, yes, very clever. Ha ha. You are so witty.

} 3) gcc-headers, gcc-compiler, gcc-preprocessor, gcc-assembler,
} gcc-backend-c, gcc-backend-c++, gcc-documentat-page-1,
} gcc-documentation-page2 and lots of other gcc packages.

apt-get install build-essential

} 4) Then anything that says ruby in it, just in case.

apt-get install ruby1.8-dev

} And always remember, the people doing debian know a lot more about how
} ruby works than you''ll ever know, and I''m sure they are
chock full of
} explanations (but not solutions) to nearly every complaint leveled at
} them.  See, that''s what smart people do, they explain rather than
listen.
} I know because I''m smart and I love explaining things to people.

The most important aspect of Debian is consistent policy. That policy
allows hundreds of people to work independently on packaging software
without stepping on one another''s toes. A good part of the policy can
actually be checked automatically, which reduces the QA load for packages.
One aspect of that policy is to separate out the part of an application one
uses (e.g. executables and core libraries) from extensions (e.g. rmagick)
and development headers (e.g. ruby1.8-dev). This provides flexibility in
system administration in that one can create a small-footprint system that
provides all the functionality needed for a particular purpose.

Needing to compile anything under Debian is deliberately rare. Various
flavors of the kernel, a wide variety of flavors of programs (e.g.
vim-tiny, vim-ruby, vim-full, vimpart, etc.), and lots of program
extensions (e.g. librmagick-ruby, libdbd-pg-ruby) are all provided
precompiled. I don''t think I''ve needed to compile anything on
my Debian
system for nearly three years other than code I wrote myself. This is a
Good Thing.

} Can anyone tell I''m incredibly annoyed at the state of the debian
} packages?  Is there a way to get this fixed for good?  Can we *please*
} *always* ***always*** install the gear needed to compile new extensions
} and install any gem?  That''d be super fresh for sure.

Yes, it''s pretty easy. Create that virtual package you want. Host it
somewhere as a Debian repository (you might even be able to host it on
alioth). Tell people about it.

} Hell, at least a damn message that says, "If you plan to do anything with
} anything related to ruby ever then you probably want to install [INSERT
} 200 PACKAGES HERE] as well."

Talk to Fumitoshi Ukai, the maintainer of the Ruby packages for Debian. Ask
him to put it in /usr/share/doc/ruby/README.Debian for the ruby package.
Maybe submit a Debian bug report on it. (You *do* know how to use
reportbug, don''t you?)

Pissing and moaning on the Ruby list is not going to change anything on the
Debian side. Many years and a lot of effort has gone into converging on
good policy and channels for change. If you learn about them and follow
them, you have a much better chance of succeeding at your task, whether
that is compiling/installing extensions or changing how Ruby is packaged.

} That''d be awesome.  Thanks.
} Zed A. Shaw
[...]
--Greg

> } 4) Then anything that says ruby in it, just in case.
> 
> apt-get install ruby1.8-dev
Oh, cool, I have to check that out.

-Sa?a Ebach

Hi Sascha, maybe you want to check this out (I presume you''re German):

http://o9y.net/archives/2006/02/17/ruby-on-rails-mittels-mod_fcgi-fur-apache-2-unter-debian/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060501/7e47f026/attachment.html

On 5/1/06 7:13 AM, "Gregory Seidman"
<gsslist+ror@anthropohedron.net> wrote:
> On Sun, Apr 30, 2006 at 08:16:23PM -0700, zedshaw@zedshaw.com wrote:
> 
> } And always remember, the people doing debian know a lot more about how
> } ruby works than you''ll ever know, and I''m sure they are
chock full of
> } explanations (but not solutions) to nearly every complaint leveled at
> } them.  See, that''s what smart people do, they explain rather
than listen.
> } I know because I''m smart and I love explaining things to people.
> 
> The most important aspect of Debian is consistent policy. That policy
> allows hundreds of people to work independently on packaging software
> without stepping on one another''s toes. A good part of the policy
can
> actually be checked automatically, which reduces the QA load for packages.
> One aspect of that policy is to separate out the part of an application one
> uses (e.g. executables and core libraries) from extensions (e.g. rmagick)
> and development headers (e.g. ruby1.8-dev). This provides flexibility in
> system administration in that one can create a small-footprint system that
> provides all the functionality needed for a particular purpose.
> 
> Needing to compile anything under Debian is deliberately rare. Various
> flavors of the kernel, a wide variety of flavors of programs (e.g.
> vim-tiny, vim-ruby, vim-full, vimpart, etc.), and lots of program
> extensions (e.g. librmagick-ruby, libdbd-pg-ruby) are all provided
> precompiled. I don''t think I''ve needed to compile
anything on my Debian
> system for nearly three years other than code I wrote myself. This is a
> Good Thing.
I rest my case.  No fix to the problem--hell not even an acknowledgement
that it is a problem--instead an explanation of why it''s not a problem
which
basically amounts to a personal attack with pathetically structured insults
and then a stance on the pedestal of elitism.

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.

If this many people continually run into the problem of how debian packages
are managed then it''s time to evaluate how they''re done. 
Since I''m not a
debian person, but I have to support them, I feel pretty annoyed.  Of course
the response you get from clever and intelligent Debian folks like yourself
is not, "Hmmm, we could probably fix that for everyone by doing ...." 
but
is instead, "You''re a fucking moron because I''m a billion
times smarter than
you since I use debian. RTFM you luzer. LOL OMG!  I''m so l33t h@x0r.
Windoze
sucks! LOL!"

But then again, this is exactly why Linux will never be worth piss in a
barrel on the desktop and all you brilliant little debian hackers with your
precious QA process--which is obviously broken since nothing seems to work
in an obvious manner--can live in your dark corner of the world spending
days setting up trivial things like ruby.  Hell, even Ruby on *Windows* is
easier to use than on Debian.

Zed A. Shaw
http://www.zedshaw.com/

On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net>
wrote:
> Needing to compile anything under Debian is deliberately rare. Various
> flavors of the kernel, a wide variety of flavors of programs (e.g.
> vim-tiny, vim-ruby, vim-full, vimpart, etc.), and lots of program
> extensions (e.g. librmagick-ruby, libdbd-pg-ruby) are all provided
> precompiled. I don''t think I''ve needed to compile
anything on my Debian
> system for nearly three years other than code I wrote myself. This is a
> Good Thing.
The gem for sqlite requires compilation. For the rest, only after Zed
shed some light on this matter, I''ve benn able to find the packages
you mention in your post, and have been able to compile mongrel
(unfortunately a problem still seems to exist, and I''ll email Zed
separately to seek for assistance).

On Mon, May 01, 2006 at 07:13:59AM -0400, Gregory Seidman wrote:
} On Sun, Apr 30, 2006 at 08:16:23PM -0700, zedshaw@zedshaw.com wrote:
} } What you''re experiencing is the annoying habit of Debian to not
install
} } half of every package you intend to use.  By default it installs only a
} } bare ruby carved out of the main source, and then separates just about
} } everything else you need to compile extensions.  Since a *huge* number of
} } gems and software for ruby requires a compiling extensions, this means you
} } can''t use just about anything on the internet without installing a
billion
} } other debian packages.
} 
} Gee, yeah, that''s terrible. I had a whole lot of trouble when I was
trying
} to install... no, wait, everything worked pretty much perfectly. Hm. I
} installed ruby, ri, and irb. And librmagick-ruby. And libdbd-pg-ruby. And,
} oddly, I never had a need to compile an extension through a gem install
} since the packages already existed, precompiled.
} 
} } I''m sure there''s some information on the other
100,000,000,000 debian
} } packages you''ll need in addition to ruby just to use ruby.  Make
sure you
} } remember to install the following as well:
} } 
} } 1) letters-a-c, letter-d-e, etc.  You need these to type.
} } 2) tcpip-header-bytes-0-40, etc.  Without this you''re missing
tcp/ip.
} 
} Oh, yes, very clever. Ha ha. You are so witty.
} 
} } 3) gcc-headers, gcc-compiler, gcc-preprocessor, gcc-assembler,
} } gcc-backend-c, gcc-backend-c++, gcc-documentat-page-1,
} } gcc-documentation-page2 and lots of other gcc packages.
} 
} apt-get install build-essential
} 
} } 4) Then anything that says ruby in it, just in case.
} 
} apt-get install ruby1.8-dev
} 
} } And always remember, the people doing debian know a lot more about how
} } ruby works than you''ll ever know, and I''m sure they are
chock full of
} } explanations (but not solutions) to nearly every complaint leveled at
} } them.  See, that''s what smart people do, they explain rather than
listen.
} } I know because I''m smart and I love explaining things to people.
} 
} The most important aspect of Debian is consistent policy. That policy
} allows hundreds of people to work independently on packaging software
} without stepping on one another''s toes. A good part of the policy can
} actually be checked automatically, which reduces the QA load for packages.
} One aspect of that policy is to separate out the part of an application one
} uses (e.g. executables and core libraries) from extensions (e.g. rmagick)
} and development headers (e.g. ruby1.8-dev). This provides flexibility in
} system administration in that one can create a small-footprint system that
} provides all the functionality needed for a particular purpose.
} 
} Needing to compile anything under Debian is deliberately rare. Various
} flavors of the kernel, a wide variety of flavors of programs (e.g.
} vim-tiny, vim-ruby, vim-full, vimpart, etc.), and lots of program
} extensions (e.g. librmagick-ruby, libdbd-pg-ruby) are all provided
} precompiled. I don''t think I''ve needed to compile anything
on my Debian
} system for nearly three years other than code I wrote myself. This is a
} Good Thing.
} 
} 
} Pissing and moaning on the Ruby list is not going to change anything on the
} Debian side. Many years and a lot of effort has gone into converging on
} good policy and channels for change. If you learn about them and follow
} them, you have a much better chance of succeeding at your task, whether
} that is compiling/installing extensions or changing how Ruby is packaged.
} 
} } That''d be awesome.  Thanks.
} } Zed A. Shaw
} [...]
} --Greg
} 
} _______________________________________________
} Rails mailing list
} Rails@lists.rubyonrails.org
} http://lists.rubyonrails.org/mailman/listinfo/rails
} 

On Mon, May 01, 2006 at 12:18:01PM -0400, Zed Shaw wrote:
} On 5/1/06 7:13 AM, "Gregory Seidman"
<gsslist+ror@anthropohedron.net> wrote:
} 
} > On Sun, Apr 30, 2006 at 08:16:23PM -0700, zedshaw@zedshaw.com wrote:
[...]
} I rest my case.  No fix to the problem--hell not even an acknowledgement
} that it is a problem--instead an explanation of why it''s not a
problem which
} basically amounts to a personal attack with pathetically structured insults
} and then a stance on the pedestal of elitism.

*sigh* Clearly my post was too long, and you didn''t actually read to
the
bottom. This one is shorter. Let me quote the relevant fixes I gave:

	} Can anyone tell I''m incredibly annoyed at the state of the debian
	} packages?  Is there a way to get this fixed for good?  Can we
	} *please* *always* ***always*** install the gear needed to compile
	} new extensions and install any gem?  That''d be super fresh for
	} sure.

	Yes, it''s pretty easy. Create that virtual package you want. Host
	it somewhere as a Debian repository (you might even be able to host
	it on alioth). Tell people about it.

	} Hell, at least a damn message that says, "If you plan to do
	} anything with anything related to ruby ever then you probably
	} want to install [INSERT 200 PACKAGES HERE] as well."

	Talk to Fumitoshi Ukai, the maintainer of the Ruby packages for
	Debian. Ask him to put it in /usr/share/doc/ruby/README.Debian for
	the ruby package. Maybe submit a Debian bug report on it. (You *do*
	know how to use reportbug, don''t you?)

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

} Zed A. Shaw
--Greg

Oops! Didn''t trim properly in the last message.

On Mon, May 01, 2006 at 12:18:01PM -0400, Zed Shaw wrote:
} On 5/1/06 7:13 AM, "Gregory Seidman"
<gsslist+ror@anthropohedron.net> wrote:
} 
} > On Sun, Apr 30, 2006 at 08:16:23PM -0700, zedshaw@zedshaw.com wrote:
[...]
} I rest my case.  No fix to the problem--hell not even an acknowledgement
} that it is a problem--instead an explanation of why it''s not a
problem which
} basically amounts to a personal attack with pathetically structured insults
} and then a stance on the pedestal of elitism.

*sigh* Clearly my post was too long, and you didn''t actually read to
the
bottom. This one is shorter. Let me quote the relevant fixes I gave:

	} Can anyone tell I''m incredibly annoyed at the state of the debian
	} packages?  Is there a way to get this fixed for good?  Can we
	} *please* *always* ***always*** install the gear needed to compile
	} new extensions and install any gem?  That''d be super fresh for
	} sure.

	Yes, it''s pretty easy. Create that virtual package you want. Host
	it somewhere as a Debian repository (you might even be able to host
	it on alioth). Tell people about it.

	} Hell, at least a damn message that says, "If you plan to do
	} anything with anything related to ruby ever then you probably
	} want to install [INSERT 200 PACKAGES HERE] as well."

	Talk to Fumitoshi Ukai, the maintainer of the Ruby packages for
	Debian. Ask him to put it in /usr/share/doc/ruby/README.Debian for
	the ruby package. Maybe submit a Debian bug report on it. (You *do*
	know how to use reportbug, don''t you?)

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

} Zed A. Shaw
--Greg

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

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


On 4/30/06, zedshaw@zedshaw.com <zedshaw@zedshaw.com>
wrote:
> Hey,
>
> What you''re experiencing is the annoying habit of Debian to not
install
> half of every package you intend to use.  By default it installs only a
> bare ruby carved out of the main source, and then separates just about
> everything else you need to compile extensions.  Since a *huge* number of
> gems and software for ruby requires a compiling extensions, this means you
> can''t use just about anything on the internet without installing a
billion
> other debian packages.
>
> I''m sure there''s some information on the other
100,000,000,000 debian
> packages you''ll need in addition to ruby just to use ruby.  Make
sure you
> remember to install the following as well:
>
> 1) letters-a-c, letter-d-e, etc.  You need these to type.
> 2) tcpip-header-bytes-0-40, etc.  Without this you''re missing
tcp/ip.
> 3) gcc-headers, gcc-compiler, gcc-preprocessor, gcc-assembler,
> gcc-backend-c, gcc-backend-c++, gcc-documentat-page-1,
> gcc-documentation-page2 and lots of other gcc packages.
> 4) Then anything that says ruby in it, just in case.
>
> And always remember, the people doing debian know a lot more about how
> ruby works than you''ll ever know, and I''m sure they are
chock full of
> explanations (but not solutions) to nearly every complaint leveled at
> them.  See, that''s what smart people do, they explain rather than
listen.
> I know because I''m smart and I love explaining things to people.
>
> Can anyone tell I''m incredibly annoyed at the state of the debian
> packages?  Is there a way to get this fixed for good?  Can we *please*
> *always* ***always*** install the gear needed to compile new extensions
> and install any gem?  That''d be super fresh for sure.
>
> Hell, at least a damn message that says, "If you plan to do anything
with
> anything related to ruby ever then you probably want to install [INSERT
> 200 PACKAGES HERE] as well."
>
> That''d be awesome.  Thanks.
>
> Zed A. Shaw
> http://www.zedshaw.com/
> http://mongrel.rubyforge.org/
>
> P.S. I''m going to write up what you need to do and put it on the
Mongrel
> site.  Basically you need to install a few more packages and make sure
> that the http11 extension gets created.
>
>
> > Hello. I installed under Ubuntu (Dapper) Park Place. I followed the
> > instructions given at the RedHanded site. I get the following mongrel
> > error when launching the application:
> >
> > ** Please login in with `admin'' and password
`pass@word1''
> > ** You should change the default password or delete the admin at
> > soonest
> >
chance!/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:584:in
> > `register'': undefined method `resolve'' for
nil:Mongrel::URIClassifier
> > (NoMethodError)
> >         from
> > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:720:in
> > `uri''
> >         from /usr/local/lib/site_ruby/1.8/parkplace.rb:45:in
`cloaker_''
> >         from
> > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:703:in
> > `listener''
> >         from /usr/local/lib/site_ruby/1.8/parkplace.rb:44:in
`cloaker_''
> >         from
> > /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12.5/lib/mongrel.rb:661:in
> > `initialize''
> >         from /usr/local/lib/site_ruby/1.8/parkplace.rb:43:in
`serve''
> >         from /usr/bin/parkplace:28
> >
> > I did some research attempting to fix this issue, but without luck.
> > Any ideas form the mongrel/parkplace people?
> >
> > Thank you.
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

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.

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?

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

But yes, there are many dists out there...

On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net>
wrote:
>
> On Sun, Apr 30, 2006 at 08:16:23PM -0700, zedshaw@zedshaw.com wrote:
> } What you''re experiencing is the annoying habit of Debian to not
install
> } half of every package you intend to use.  By default it installs only a
> } bare ruby carved out of the main source, and then separates just about
> } everything else you need to compile extensions.  Since a *huge* number
> of
> } gems and software for ruby requires a compiling extensions, this means
> you
> } can''t use just about anything on the internet without installing
a
> billion
> } other debian packages.
>
> Gee, yeah, that''s terrible. I had a whole lot of trouble when I
was trying
> to install... no, wait, everything worked pretty much perfectly. Hm. I
> installed ruby, ri, and irb. And librmagick-ruby. And libdbd-pg-ruby. And,
> oddly, I never had a need to compile an extension through a gem install
> since the packages already existed, precompiled.
>
> } I''m sure there''s some information on the other
100,000,000,000 debian
> } packages you''ll need in addition to ruby just to use ruby.  Make
sure
> you
> } remember to install the following as well:
> }
> } 1) letters-a-c, letter-d-e, etc.  You need these to type.
> } 2) tcpip-header-bytes-0-40, etc.  Without this you''re missing
tcp/ip.
>
> Oh, yes, very clever. Ha ha. You are so witty.
>
> } 3) gcc-headers, gcc-compiler, gcc-preprocessor, gcc-assembler,
> } gcc-backend-c, gcc-backend-c++, gcc-documentat-page-1,
> } gcc-documentation-page2 and lots of other gcc packages.
>
> apt-get install build-essential
>
> } 4) Then anything that says ruby in it, just in case.
>
> apt-get install ruby1.8-dev
>
> } And always remember, the people doing debian know a lot more about how
> } ruby works than you''ll ever know, and I''m sure they are
chock full of
> } explanations (but not solutions) to nearly every complaint leveled at
> } them.  See, that''s what smart people do, they explain rather
than
> listen.
> } I know because I''m smart and I love explaining things to people.
>
> The most important aspect of Debian is consistent policy. That policy
> allows hundreds of people to work independently on packaging software
> without stepping on one another''s toes. A good part of the policy
can
> actually be checked automatically, which reduces the QA load for packages.
> One aspect of that policy is to separate out the part of an application
> one
> uses (e.g. executables and core libraries) from extensions (e.g. rmagick)
> and development headers (e.g. ruby1.8-dev). This provides flexibility in
> system administration in that one can create a small-footprint system that
> provides all the functionality needed for a particular purpose.
>
> Needing to compile anything under Debian is deliberately rare. Various
> flavors of the kernel, a wide variety of flavors of programs (e.g.
> vim-tiny, vim-ruby, vim-full, vimpart, etc.), and lots of program
> extensions (e.g. librmagick-ruby, libdbd-pg-ruby) are all provided
> precompiled. I don''t think I''ve needed to compile
anything on my Debian
> system for nearly three years other than code I wrote myself. This is a
> Good Thing.
>
> } Can anyone tell I''m incredibly annoyed at the state of the
debian
> } packages?  Is there a way to get this fixed for good?  Can we *please*
> } *always* ***always*** install the gear needed to compile new extensions
> } and install any gem?  That''d be super fresh for sure.
>
> Yes, it''s pretty easy. Create that virtual package you want. Host
it
> somewhere as a Debian repository (you might even be able to host it on
> alioth). Tell people about it.
>
> } Hell, at least a damn message that says, "If you plan to do anything
> with
> } anything related to ruby ever then you probably want to install [INSERT
> } 200 PACKAGES HERE] as well."
>
> Talk to Fumitoshi Ukai, the maintainer of the Ruby packages for Debian.
> Ask
> him to put it in /usr/share/doc/ruby/README.Debian for the ruby package.
> Maybe submit a Debian bug report on it. (You *do* know how to use
> reportbug, don''t you?)
>
> Pissing and moaning on the Ruby list is not going to change anything on
> the
> Debian side. Many years and a lot of effort has gone into converging on
> good policy and channels for change. If you learn about them and follow
> them, you have a much better chance of succeeding at your task, whether
> that is compiling/installing extensions or changing how Ruby is packaged.
>
> } That''d be awesome.  Thanks.
> } Zed A. Shaw
> [...]
> --Greg
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060501/f9df517a/attachment.html

On 5/1/06, Zed Shaw <zedshaw@zedshaw.com> wrote:
>
>
> On 5/1/06 7:13 AM, "Gregory Seidman"
<gsslist+ror@anthropohedron.net> wrote:
>
> > On Sun, Apr 30, 2006 at 08:16:23PM -0700, zedshaw@zedshaw.com wrote:
> >
> > } And always remember, the people doing debian know a lot more about
how
> > } ruby works than you''ll ever know, and I''m sure
they are chock full of
> > } explanations (but not solutions) to nearly every complaint leveled
at
> > } them.  See, that''s what smart people do, they explain
rather than listen.
> > } I know because I''m smart and I love explaining things to
people.
> >
> > The most important aspect of Debian is consistent policy. That policy
> > allows hundreds of people to work independently on packaging software
> > without stepping on one another''s toes. A good part of the
policy can
> > actually be checked automatically, which reduces the QA load for
packages.
> > One aspect of that policy is to separate out the part of an
application one
> > uses (e.g. executables and core libraries) from extensions (e.g.
rmagick)
> > and development headers (e.g. ruby1.8-dev). This provides flexibility
in
> > system administration in that one can create a small-footprint system
that
> > provides all the functionality needed for a particular purpose.
> >
> > Needing to compile anything under Debian is deliberately rare. Various
> > flavors of the kernel, a wide variety of flavors of programs (e.g.
> > vim-tiny, vim-ruby, vim-full, vimpart, etc.), and lots of program
> > extensions (e.g. librmagick-ruby, libdbd-pg-ruby) are all provided
> > precompiled. I don''t think I''ve needed to compile
anything on my Debian
> > system for nearly three years other than code I wrote myself. This is
a
> > Good Thing.
>
> I rest my case.  No fix to the problem--hell not even an acknowledgement
> that it is a problem--instead an explanation of why it''s not a
problem which
> basically amounts to a personal attack with pathetically structured insults
> and then a stance on the pedestal of elitism.
>
> 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.
>
> If this many people continually run into the problem of how debian packages
> are managed then it''s time to evaluate how they''re done. 
Since I''m not a
> debian person, but I have to support them, I feel pretty annoyed.  Of
course
> the response you get from clever and intelligent Debian folks like yourself
> is not, "Hmmm, we could probably fix that for everyone by doing
...."  but
> is instead, "You''re a fucking moron because I''m a
billion times smarter than
> you since I use debian. RTFM you luzer. LOL OMG!  I''m so l33t
h@x0r. Windoze
> sucks! LOL!"
>
> But then again, this is exactly why Linux will never be worth piss in a
> barrel on the desktop and all you brilliant little debian hackers with your
> precious QA process--which is obviously broken since nothing seems to work
> in an obvious manner--can live in your dark corner of the world spending
> days setting up trivial things like ruby.  Hell, even Ruby on *Windows* is
> easier to use than on Debian.
I''ve also been frustrated by the Debian packaging of Ruby.  It always
pissed me off having to go and find each stupid dependency package
that I need for each thing (zlib, readline, gnomecanvas, termios,
etc).

I may not be much of a power-user, but I used Ezra''s instructions to
get a
Debain VPS up and running from a base install of Debian Sarge, and I had
absolutely zero problems with Ruby. The only thing I had to compile and
install was Lighty. I actually had the hardest time getting the ImageMagick
stuff to work with FreeType, and I don''t really feel that I can blame
that
on Debian. Overall, I''ve been very happy. It''s a small
footprint, extremely
stable, and has worked as expected the whole time.

Just my 2c.

Matt

On 5/1/06, Joe Van Dyk <joevandyk@gmail.com>
wrote:
>
> On 5/1/06, Zed Shaw <zedshaw@zedshaw.com> wrote:
> >
> >
> > On 5/1/06 7:13 AM, "Gregory Seidman"
<gsslist+ror@anthropohedron.net>
> wrote:
> >
> > > On Sun, Apr 30, 2006 at 08:16:23PM -0700, zedshaw@zedshaw.com
wrote:
> > >
> > > } And always remember, the people doing debian know a lot more
about
> how
> > > } ruby works than you''ll ever know, and I''m
sure they are chock full
> of
> > > } explanations (but not solutions) to nearly every complaint
leveled
> at
> > > } them.  See, that''s what smart people do, they explain
rather than
> listen.
> > > } I know because I''m smart and I love explaining things
to people.
> > >
> > > The most important aspect of Debian is consistent policy. That
policy
> > > allows hundreds of people to work independently on packaging
software
> > > without stepping on one another''s toes. A good part of
the policy can
> > > actually be checked automatically, which reduces the QA load for
> packages.
> > > One aspect of that policy is to separate out the part of an
> application one
> > > uses (e.g. executables and core libraries) from extensions (e.g.
> rmagick)
> > > and development headers (e.g. ruby1.8-dev). This provides
flexibility
> in
> > > system administration in that one can create a small-footprint
system
> that
> > > provides all the functionality needed for a particular purpose.
> > >
> > > Needing to compile anything under Debian is deliberately rare.
Various
> > > flavors of the kernel, a wide variety of flavors of programs
(e.g.
> > > vim-tiny, vim-ruby, vim-full, vimpart, etc.), and lots of program
> > > extensions (e.g. librmagick-ruby, libdbd-pg-ruby) are all
provided
> > > precompiled. I don''t think I''ve needed to
compile anything on my
> Debian
> > > system for nearly three years other than code I wrote myself.
This is
> a
> > > Good Thing.
> >
> > I rest my case.  No fix to the problem--hell not even an
acknowledgement
> > that it is a problem--instead an explanation of why it''s not
a problem
> which
> > basically amounts to a personal attack with pathetically structured
> insults
> > and then a stance on the pedestal of elitism.
> >
> > 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.
> >
> > If this many people continually run into the problem of how debian
> packages
> > are managed then it''s time to evaluate how they''re
done.  Since I''m not
> a
> > debian person, but I have to support them, I feel pretty annoyed.  Of
> course
> > the response you get from clever and intelligent Debian folks like
> yourself
> > is not, "Hmmm, we could probably fix that for everyone by doing
> ...."  but
> > is instead, "You''re a fucking moron because I''m
a billion times smarter
> than
> > you since I use debian. RTFM you luzer. LOL OMG!  I''m so l33t
h@x0r.
> Windoze
> > sucks! LOL!"
> >
> > But then again, this is exactly why Linux will never be worth piss in
a
> > barrel on the desktop and all you brilliant little debian hackers with
> your
> > precious QA process--which is obviously broken since nothing seems to
> work
> > in an obvious manner--can live in your dark corner of the world
spending
> > days setting up trivial things like ruby.  Hell, even Ruby on
*Windows*
> is
> > easier to use than on Debian.
>
> I''ve also been frustrated by the Debian packaging of Ruby.  It
always
> pissed me off having to go and find each stupid dependency package
> that I need for each thing (zlib, readline, gnomecanvas, termios,
> etc).
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060501/54d74537/attachment.html

On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net>
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.

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.

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

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.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

amusing thread. I got ruby running easily running on my debian box, but
failed at Lighty...

Zed and Austin, what distro are you guys using ?

--
Roberto Saccon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060501/682655aa/attachment.html

Yeah, I second that. What are you using? I''m open to suggestions for
future
deployment... I see a lot of people using FreeBSD, but I don''t know
enough
to say whether it''s good or bad.

Matt

On 5/1/06, Roberto Saccon <rsaccon@gmail.com>
wrote:
>
> amusing thread. I got ruby running easily running on my debian box, but
> failed at Lighty...
>
> Zed and Austin, what distro are you guys using ?
>
> --
> Roberto Saccon
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060501/df678e20/attachment.html

On 5/1/06, Roberto Saccon <rsaccon@gmail.com>
wrote:
> amusing thread. I got ruby running easily running on my debian box, but
> failed at Lighty...
>
> Zed and Austin, what distro are you guys using ?
I don''t do Rails software, but I support people using PDF::Writer.
Currently, I do all of my development of the various packages that I
created/support/own on Windows.

I will be buying a Mac later this year.

That said, I *do* use Ubuntu on my linode, when I remember that I have
it. I just don''t have any applications running on it yet.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

Hows does Ubuntu stack up?   It''s based on Debian.

On 5/1/06, Matt White <stockliasteroid@gmail.com>
wrote:
> Yeah, I second that. What are you using? I''m open to suggestions
for future
> deployment... I see a lot of people using FreeBSD, but I don''t
know enough
> to say whether it''s good or bad.
>
> Matt
>
>
>  On 5/1/06, Roberto Saccon <rsaccon@gmail.com> wrote:
> >
>
> amusing thread. I got ruby running easily running on my debian box, but
> failed at Lighty...
>
> Zed and Austin, what distro are you guys using ?
>
> --
>  Roberto Saccon
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

On 5/1/06, GravyFace <gravyface@gmail.com> wrote:
> Hows does Ubuntu stack up?   It''s based on Debian.
Just as bad.

It does some things better than Debian itself, but it inherits a lot
of the nonsense.

I always build Ruby from scratch on Debian. Anything else is nonsense.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

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

On 5/1/06, Austin Ziegler <halostatue@gmail.com>
wrote:
> On 5/1/06, GravyFace <gravyface@gmail.com> wrote:
> > Hows does Ubuntu stack up?   It''s based on Debian.
>
> Just as bad.
>
> It does some things better than Debian itself, but it inherits a lot
> of the nonsense.
>
> I always build Ruby from scratch on Debian. Anything else is nonsense.
>
> -austin
> --
> Austin Ziegler * halostatue@gmail.com
>                * Alternate: austin@halostatue.ca
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

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 Brodowsky <listen@brodowsky.com>
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. :)

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


On May 1, 2006, at 3:30 PM, GravyFace wrote:
> What Linux/BSD distros out there make the RoR kids happy?
>
> On 5/1/06, Austin Ziegler <halostatue@gmail.com> wrote:
>> On 5/1/06, GravyFace <gravyface@gmail.com> wrote:
>> > Hows does Ubuntu stack up?   It''s based on Debian.
>>
>> Just as bad.
>>
>> It does some things better than Debian itself, but it inherits a lot
>> of the nonsense.
>>
>> I always build Ruby from scratch on Debian. Anything else is  
>> nonsense.
>>
>> -austin
>> --
>> Austin Ziegler * halostatue@gmail.com
>>                * Alternate: austin@halostatue.ca
>>
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

On Mon, May 01, 2006 at 02:30:42PM -0400, Austin Ziegler wrote:
} On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net> 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

Karl Brodowsky 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 :-)

-- 
Alex

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, Gregory Seidman <gsslist+ror@anthropohedron.net>
wrote:
> On Mon, May 01, 2006 at 02:30:42PM -0400, Austin Ziegler wrote:
>> On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net>
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
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

On 5/1/06, Karl Brodowsky <listen@brodowsky.com>
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
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

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

http://www.scalewithrails.com/downloads/ScaleWithRails-April2006.pdf

--
Giles Bowkett
http://www.gilesgoatboy.org


On 5/1/06, Austin Ziegler <halostatue@gmail.com>
wrote:
> On 5/1/06, Karl Brodowsky <listen@brodowsky.com> 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
> --
> Austin Ziegler * halostatue@gmail.com
>                * Alternate: austin@halostatue.ca
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

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

Giles Bowkett wrote:
> 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.)
> 
> http://www.scalewithrails.com/downloads/ScaleWithRails-April2006.pdf
> 
> -- 
> Giles Bowkett
> http://www.gilesgoatboy.org
> 
> 
> On 5/1/06, Austin Ziegler <halostatue@gmail.com> wrote:
>> On 5/1/06, Karl Brodowsky <listen@brodowsky.com> 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
>> -- 
>> Austin Ziegler * halostatue@gmail.com
>>                * Alternate: austin@halostatue.ca
>>
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 
>

On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net>
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 Ziegler wrote:
} On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:
} >On Mon, May 01, 2006 at 02:30:42PM -0400, Austin Ziegler 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 Bowkett 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.

-- 
Alex

On Mon, May 01, 2006 at 08:45:14PM +0000, Guido Sohne wrote:
} On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net> 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 ;-)

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

Just my two cents.

Rafael

Pat Maddox 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


-- 
Jonathan Weiss
http://blog.innerewut.de

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

-- 
Jonathan Weiss
http://blog.innerewut.de

Rafael Szuminski wrote:
> Ubuntu maintainer even tried
> to convince me that Ubuntu ships Ruby 1.8.4 ;-)
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.

-- 
Alex

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

-- 
Jonathan Weiss
http://blog.innerewut.de

Guido Sohne wrote:
> Quick question: What do most people using Ruby these days use it for?
> Hint: Ruby on Rails.
Numbers?
> 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?
For what it''s worth, it''s not actually 1.8.3 (as far as I can
tell).
It''s actually 1.8.2 with some fairly significant backports, which is
why
the package number and the --version numbers differ.  I never remember 
having triggered Rails-relevant bugs with Rails 1.0 and Ubuntu''s Ruby 
1.8.3, but Rails 1.1 version-checks using the number rather than 
capabilities and won''t let itself be run.

Besides, I''d take issue with Rails being the "NUMBER ONE
APPLICATION
BEING USED" when Breezy was frozen - it hadn''t even hit 1.0rc1
yet.

What you''re complaining about will happen with *any* distro with a 
cyclical stable release policy.  At least with Ubuntu, we know that 
Dapper''s just around the corner - with 1.8.4 goodness just oozing from 
the seams.
> Ruby from Darwinports works just fine. Both are packaging systems.
Maybe.  They may even have similar mechanics.  They''re not going to be 
equivalent, though, because they''ve got *completely* different 
intentions and target audiences.
> I''ll leave it to you to tell us why the QA process is harming
users
> rather than helping them?
Some it harms, far more it helps.  Can''t be all things to all people. 
Overall, the QA process is absolutely fantastic.  Rails has just been 
unlucky in that it sprung into relevance largely after the QA process 
had run its course.  Just bad timing.
> IMHO, I don''t need protection from upstream developers. I rather
need
> protection from obsolete packages ... caused in the main by a
''QA''
> process.
Then you should take a good look at a distro with a more permissive (or 
less cyclical) release policy than Ubuntu, or not rely on running a 
Stable release.

Why are you migrating to Ubuntu, by the way?

-- 
Alex

On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net>
wrote:
> } 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.
Except that PDF::Writer works without RubyGems, too. You''re expected
to know whether you installed from RubyGems or not.

Unit tests are not possible with PDF::Writer. If you really want to
get into why, I will, but that''s a separate discussion.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

On 5/1/06, Alex Young <alex@blackkettle.org>
wrote:
> Rafael Szuminski wrote:
> > Ubuntu maintainer even tried
> > to convince me that Ubuntu ships Ruby 1.8.4 ;-)
> 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
Where did you get the Dapper server from?

Rafael Szuminski wrote:
> On 5/1/06, Alex Young <alex@blackkettle.org> wrote:
> 
>> Rafael Szuminski wrote:
>> > Ubuntu maintainer even tried
>> > to convince me that Ubuntu ships Ruby 1.8.4 ;-)
>> 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
> 
> Where did you get the Dapper server from?
I didn''t.  I''ve got an existing Breezy install which I was
developing on
fine until I upgraded to Rails 1.1.  Then I found I needed to shift up, 
and the simplest way to get that to work was to download libruby1.8, 
ruby1.8 and ruby1.8-dev from
http://packages.ubuntu.com/dapper/devel/ruby1.8-dev
http://packages.ubuntu.com/dapper/interpreters/ruby1.8
and
http://packages.ubuntu.com/dapper/libs/libruby1.8

I don''t recall upgrading any of the other packages, but I could go 
through and check.

-- 
Alex

GravyFace wrote:
> Hows does Ubuntu stack up?   It''s based on Debian.
>
I don''t know what everybody is getting worked up about. I moved to 
Debian from the rpm world (*shudder*) and it never gave too much of 
trouble for me. I''m thinking, people who have been using Debian/Ubuntu 
for a while can easily get Ruby or Rails running on it. New users might 
be tripped as apt-get way of package management is a little different 
from other ways of doing it.

I''m a regular web developer (read: not l33t h4x0r), albeit running 
Ubuntu Breezy on my laptop, and the upgrade from Ruby 1.8.2 to 1.8.4 
took some 10-15 minutes, including searching for the right sources (in 
Dapper) and installing them. I''m running Rails 1.1.2 now, and I have 
upgraded all my apps, and I have zero problems. I think it''s just a 
matter of getting used to Debian way of doing things.


Vamsee.

I have noticed that Installing the *-dev packages fix a lot of things ;-)

Nic

On 5/1/06, Sascha Ebach <se@digitale-wertschoepfung.de>
wrote:
>
> > } 4) Then anything that says ruby in it, just in case.
> >
> > apt-get install ruby1.8-dev
>
> Oh, cool, I have to check that out.
>
> -Sa?a Ebach
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Nicolas Kassis
--------------------
http://www.nickassis.net
http://www.nickassis.net/blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060502/b1bb92c5/attachment.html

I agree, I''ve been running Debian in production for a long time with
zero problems. I have to get used to it and it''s clearly one of the
most reliable distributions out there. RH''s rpm way of doing things is
just a disaster.

On 5/1/06, Vamsee Kanakala <vamlists@gmx.net>
wrote:
> GravyFace wrote:
>
> > Hows does Ubuntu stack up?   It''s based on Debian.
> >
> I don''t know what everybody is getting worked up about. I moved to
> Debian from the rpm world (*shudder*) and it never gave too much of
> trouble for me. I''m thinking, people who have been using
Debian/Ubuntu
> for a while can easily get Ruby or Rails running on it. New users might
> be tripped as apt-get way of package management is a little different
> from other ways of doing it.
>
> I''m a regular web developer (read: not l33t h4x0r), albeit running
> Ubuntu Breezy on my laptop, and the upgrade from Ruby 1.8.2 to 1.8.4
> took some 10-15 minutes, including searching for the right sources (in
> Dapper) and installing them. I''m running Rails 1.1.2 now, and I
have
> upgraded all my apps, and I have zero problems. I think it''s just
a
> matter of getting used to Debian way of doing things.
>
>
> Vamsee.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
Kent
---
http://www.datanoise.com

From: "Zed Shaw" <zedshaw@zedshaw.com>
> 
> If this many people continually run into the problem of how debian packages
> are managed then it''s time to evaluate how they''re done.
Just as a data point: I like debian, and the only package I''ve
had trouble with to the extent that I compile it myself is ruby.

Ruby is the only thing I compile myself and install to /opt.
Everything else has worked from flawless to mostly flawless for
me with a simple apt-get.

Most of the time it''s "apt-get install subversion" ... done.
"apt-get install vsftp" (automatically de-installs proftpd, installs
vsftp) done.  "apt-get install slash" (installs the notoriously
complicated slashcode and about 100+ dependent modules)... done.

But ruby?  In my experience so far debian policy on ruby is just
broken somehow, and I got tired of it and compile it myself.


FWIW,

Bill

Someone get out the red pen and underline this note.  Installing *-dev 
packages routinely fixes problems I encounter in Debian.

FWIW I found my questions answered on the wiki.rubyonrails.org pages 
when I first tried to get Rails running on Debian after ramming my head 
into the wall trying to get rmagick to work on an existing RH9 box 
(shudder).

I''m sorry the original poster encountered the problem and yes, the 3.1 
release is a little behind defaulting to ruby 1.8.2.  But on the other 
hand, OS X Tiger ships with 1.8.2 for instance.

Nicholas P. Mueller

Nicolas Kassis wrote:
> I have noticed that Installing the *-dev packages fix a lot of things ;-)
>
> Nic
>
> On 5/1/06, *Sascha Ebach* < se@digitale-wertschoepfung.de 
> <mailto:se@digitale-wertschoepfung.de>> wrote:
>
>     > } 4) Then anything that says ruby in it, just in case.
>     >
>     > apt-get install ruby1.8-dev
>
>     Oh, cool, I have to check that out.
>
>     -Sa?a Ebach
>     _______________________________________________
>     Rails mailing list
>     Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org>
>     http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>
>
> -- 
> Nicolas Kassis
> --------------------
> http://www.nickassis.net
> http://www.nickassis.net/blog
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On Tue, May 02, 2006 at 12:00:38AM -0500, Nicholas P. Mueller
wrote:
> I''m sorry the original poster encountered the problem and yes, the
3.1
> release is a little behind defaulting to ruby 1.8.2.  But on the other 
> hand, OS X Tiger ships with 1.8.2 for instance.
And CentOS 4.2 seems to ship still with a severely broken ruby 1.8.1.
And the ISOs I saw were dated the middle of March.  I can only assume
from the way that CentOS builds things that the latest RHEL is the
same.

Repeat after me: All OSes/distros/languages suck [to some degree or
other].


-- 
Michael A. Gurski (opt. [first].)[last]@pobox.com  http://www.pobox.com/~[last]
1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7  17 57 1E 4E 62 56 45 70
1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB  AD81 ADC9 E606 1166 213E
4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042  7788 1DCE B5EE C0B4 F04B
Views expressed by the host do not reflect the staff, management or sponsors.

"A democracy cannot exist as a permanent form of government. It can
only exist until a majority of voters discover that they can vote
themselves largess out of the public treasury."  --Alexander Tytler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060502/7a83aa39/attachment-0001.bin

On May 1, 2006, at 9:09 PM, Gregory Seidman wrote:
> 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.
So now we need a distro for PHP development, another distro for Java  
development and another for Perl development, Python development etc?

That sounds like a really good idea! Not!
> } 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.
So where do the packages in Ubuntu universe come from?
> } 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.
How much space does irb take? What the point in splitting Ruby into  
lots of little pieces? How well did that work for Perl CPAN stuff?  
What does that do to you when you are running a heterogenous shop?  
Gems and CPAN modules have a much better chance of working on  
different boxen than a Debianized approach no?
> } 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.
Then why do they bother to include Python, Perl and PHP? Or gcc, for  
that matter?
> } 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
Typical answer. You''re saying it is not broken. I have another  
machine running 6.06 and I am well aware that Ruby 1.8.4 is there. I  
use it. I was simply trying to install a new application on an  
existing /stable/ server. Between having an up to date Ruby package  
and installing or upgrading the WHOLE DISTRO, guess which one is more  
preferable?

If someone can put up his own packagers, then how hard could it be  
for the maintainers to add in packages? If it works for me, then what  
is the problem in placing those packages for people to uses? With all  
the fancy pinning features that apt has, don''t you think it is  
possible to make it work for those who want to while keeping the  
distro stable for those who don''t want to?

Maybe I don''t understand maintenance. What I do understand is whether  
it worked or whether it is borken.
> } 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.
Actually, I picked Ubuntu because I prefer apt-get to RPM hell. I  
would have picked Debian. But Debian has some particular problems  
relating to slow upgrade cycles and general laziness, all in the name  
of whatever. Anyway, why should I change distros just to get a  
working and up to date Ruby? Are you talking results or excuses?

-- G.

On Tue, May 02, 2006 at 04:32:54PM +0000, Guido Sohne wrote:
} On May 1, 2006, at 9:09 PM, Gregory Seidman wrote:
} >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.
} 
} So now we need a distro for PHP development, another distro for Java  
} development and another for Perl development, Python development etc?
} 
} That sounds like a really good idea! Not!

If you want a distribution that caters to people who only know how to do
those things and are unwilling to learn anything about administering the
system, then yes. Of course, if you''re willing to put some effort into
learning to use the system effectively, you can use almost any
distribution.

I don''t know how many times I''ll have to repeat this before
people get it.
It''s all about the tradeoffs. It isn''t possible to build a
system that
makes everyone happy all of the time. Choose the distribution with the
tradeoffs that best match your needs.

} >} 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.
} So where do the packages in Ubuntu universe come from?

They are modified, lightly or heavily, from Debian packages. A huge number
of packages that are available in the Debian repositories are not provided
by the Ubuntu repositories. Debian and Ubuntu have different goals and
that is reflected in their respective tradeoffs, including which packages
are available and supported.

} >} 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.
} 
} How much space does irb take?

484k on my system.

} What the point in splitting Ruby into  lots of little pieces?

Flexibility.

} How well did that work for Perl CPAN stuff?  

Beats me. I don''t use Perl.

} What does that do to you when you are running a heterogenous shop?  

I don''t see the relevance.

} Gems and CPAN modules have a much better chance of working on  
} different boxen than a Debianized approach no?

I don''t know what you mean by that.

} >} 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.
} 
} Then why do they bother to include Python, Perl and PHP? Or gcc, for  
} that matter?

Because if you put any effort into learning about the system you are using,
Debian makes things easy. I have had no trouble whatsoever with Ruby, gems,
or rails on my Debian box because I actually know how to use it. If you
aren''t willing to learn how to use your tools, pick a tool that
doesn''t
require as much learning. Debian''s stated goals do not include making
it
easy to start using it without any effort to learn anything. Ubuntu''s
goals
do, but they limit *what* they make easy to start using without learning
anything; web development is not among those things.

} >} 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
} 
} Typical answer. You''re saying it is not broken. I have another  
} machine running 6.06 and I am well aware that Ruby 1.8.4 is there. I  
} use it. I was simply trying to install a new application on an  
} existing /stable/ server. Between having an up to date Ruby package  
} and installing or upgrading the WHOLE DISTRO, guess which one is more  
} preferable?

Tradeoffs, tradeoffs, tradeoffs! Release cycles exist for stability. If you
want to go off the release cycle, you can do so by using the betas of the
next release. I use a combination of Debian testing and unstable because I
don''t want to be tied to their release cycle. I pay for it in that
sometimes things break.

} If someone can put up his own packagers, then how hard could it be  
} for the maintainers to add in packages? If it works for me, then what  
} is the problem in placing those packages for people to uses? With all  
} the fancy pinning features that apt has, don''t you think it is  
} possible to make it work for those who want to while keeping the  
} distro stable for those who don''t want to?
} 
} Maybe I don''t understand maintenance. What I do understand is whether
} it worked or whether it is borken.

If you understood maintenance you wouldn''t be asking these questions
(nor
would you be using such a confrontational tone). The maintainers, like
everyone else, have a finite amount of time. They aren''t paid for their
package maintenance work, so they have to spend a chunk of that time making
a living. They may have other demands on their time, such as family,
eating, sleeping, or even other packages. They have established these
release cycles in an effort to release stable software in a reasonably
timely manner without dedicating their entire lives to it.

} >} 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.
} 
} Actually, I picked Ubuntu because I prefer apt-get to RPM hell. I  
} would have picked Debian. But Debian has some particular problems  
} relating to slow upgrade cycles and general laziness, all in the name  
} of whatever. Anyway, why should I change distros just to get a  
} working and up to date Ruby? Are you talking results or excuses?

If you are otherwise happy with your distribution of choice, learn how to
work around its flaws. If you are unhappy enough with it that you have to
piss and moan about it on a public mailing list, switch. If you cannot
stand the idea that these lazy maintainers are not addressing your specific
problems as soon as you find them, if not sooner, switch to a commercial
distribution, purchase a support contract, and bitch them out on your dime.

Have you ever heard the phrase, "There ain''t no such thing as a
free
lunch"? It implies, among other things, that if you aren''t paying
money for
your software then you will pay in other ways. That may include your time
and your frustration. You have three rational responses:

1) Fix your problems for yourself.
2) Fix your problems and make your fixes available to the world.
3) Pay someone to fix your problems. (This includes switching to commercial
   software.)

Complaining loudly and repeatedly that other people aren''t fixing your
problems gratis is pretty much useless. Note how far it''s gotten you so
far.

} -- G.
--Greg

On 5/2/06, Gregory Seidman <gsslist+ror@anthropohedron.net>
wrote:
> On Tue, May 02, 2006 at 04:32:54PM +0000, Guido Sohne wrote:
>> On May 1, 2006, at 9:09 PM, Gregory Seidman wrote:
>>> 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.
>> So now we need a distro for PHP development, another distro for Java
>> development and another for Perl development, Python development etc?
>>
>> That sounds like a really good idea! Not!
> If you want a distribution that caters to people who only know how to
> do those things and are unwilling to learn anything about
> administering the system, then yes. Of course, if you''re willing
to
> put some effort into learning to use the system effectively, you can
> use almost any distribution.
Developers should not have to be system administrators. The two
functions are different.

This sort of attitude, by the way ("learn to administer your system")
has greatly hindered (and will continue to hinder) wider adoption of
Linux by people who neither have the time, inclination, or need to learn
the intricacies of administering their system.

My job is to develop software. Not administer an operating system. Our
accountant shouldn''t have to learn to administer his operating system
just because the Debian people want to cater to highly technical people
who want to control how many pixels above the body the dot of the I
belongs.
> I don''t know how many times I''ll have to repeat this
before people get
> it. It''s all about the tradeoffs. It isn''t possible to
build a system
> that makes everyone happy all of the time. Choose the distribution
> with the tradeoffs that best match your needs.
This is increasingly MacOS X and Windows.
>>>> 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.
>> How much space does irb take?
> 484k on my system.
A minimal amount, probably caused by the inclusion of readline. The
1.8.2 version of irb takes up approximately 200kb. More importantly, it
is considered *by the Ruby developers* to be part of the core standard
library for Ruby. IRB, RDoc, and various other packages that have been
split off by Debian''s micromanagement mania.
>> What the point in splitting Ruby into lots of little pieces?
> Flexibility.
...which results in inflexibility when it comes to deployment. Debian
has sliced the core standard library into unrecognisable bits. The
*only* part of the core standard library that should probably be pulled
out and made into site library stuff that would be separate is, IMO, the
Tk support.
>> How well did that work for Perl CPAN stuff?
> Beats me. I don''t use Perl.
Hint: it didn''t work well.
>> What does that do to you when you are running a heterogenous shop?
> I don''t see the relevance.
Of course you don''t.
>> Gems and CPAN modules have a much better chance of working on
>> different boxen than a Debianized approach no?
> I don''t know what you mean by that.
Obviously. They do have a much better chance of working the same -- and
properly -- on a wide variety of operating systems and distributions
than the Debian nonsensical approach to matters.
> Because if you put any effort into learning about the system you are using,
> Debian makes things easy.
That''s a joke. It''s also arrogant, asinine, nonsense.
> If you understood maintenance you wouldn''t be asking these
questions (nor
> would you be using such a confrontational tone).
Arrogant nonsense. Hint: I understand maintenance.

Debian is so slow as to be backwards. Debian is best avoided by people
who want to do anything useful. Even FreeBSD is more up to date than
Debian.

I really can''t stand the arrogant garbage that Debian apologists give
out.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

On 5/2/06, Gregory Seidman <gsslist+ror@anthropohedron.net>
wrote:
> If you want a distribution that caters to people who only know how to do
> those things and are unwilling to learn anything about administering the
> system, then yes. Of course, if you''re willing to put some effort
into
> learning to use the system effectively, you can use almost any
> distribution.
I do know how to use it. That''s why I expect little things like having
a reasonably popular package work. Would you say the same thing if
Firefox didn''t work?
> I don''t know how many times I''ll have to repeat this
before people get it.
> It''s all about the tradeoffs. It isn''t possible to build
a system that
> makes everyone happy all of the time. Choose the distribution with the
> tradeoffs that best match your needs.
Ubuntu is that distro. That''s what I would like it to be easier, so
that instead of thousands of people wasting their time, one person
just bumps up a package version. If they went to the extent of putting
a 1.8.2 ruby and making it pretend it is 1.8.3, then why not just do
the real thing? It is easier at least to my way of thinking.
> } So where do the packages in Ubuntu universe come from?
>
> They are modified, lightly or heavily, from Debian packages. A huge number
> of packages that are available in the Debian repositories are not provided
> by the Ubuntu repositories. Debian and Ubuntu have different goals and
> that is reflected in their respective tradeoffs, including which packages
> are available and supported.
Excuses. Does it work? Yes or no? All the hand waving just wastes time ...
> } How much space does irb take?
>
> 484k on my system.
So for a lousy 484k people have to pull their hair out? Granted, it''s
just a apt-get irb away but methinks the cart is before the horse
here.
> } What the point in splitting Ruby into  lots of little pieces?
>
> Flexibility.
And pain for those who don''t need the flexibility. Which is most
people.
> } How well did that work for Perl CPAN stuff?
>
> Beats me. I don''t use Perl.
I do on occasion. The packages you want tend to be out of date when
they are Debianized. Not everything was Debianized, so you always
ended up running stuff that wasn''t in the package manager.
> } What does that do to you when you are running a heterogenous shop?
>
> I don''t see the relevance.
The package system gets in the way. It''s not a help. There are certain
situations where that happens. Trying to make it go away by pretending
it doesn''t exist doesn''t solve it.
> } Gems and CPAN modules have a much better chance of working on
> } different boxen than a Debianized approach no?
>
> I don''t know what you mean by that.
I mean that gem install mongrel works on all boxes, not just Debian.
And it covers all the gems in the repo, not just what someone saw fit
to Debianize.
> } >} 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.
> }
> } Then why do they bother to include Python, Perl and PHP? Or gcc, for
> } that matter?
>
> Because if you put any effort into learning about the system you are using,
> Debian makes things easy. I have had no trouble whatsoever with Ruby, gems,
> or rails on my Debian box because I actually know how to use it. If you
> aren''t willing to learn how to use your tools, pick a tool that
doesn''t
> require as much learning. Debian''s stated goals do not include
making it
> easy to start using it without any effort to learn anything.
Ubuntu''s goals
> do, but they limit *what* they make easy to start using without learning
> anything; web development is not among those things.
This is not about learning. This is about when you know how to and
there are some brain dead issues or decisions or policies in the way.
Debian could be a much better distro. Ubuntu proves that. Does Debian
have some problems that could be fixed? Isn''t that what we are trying
to say here, while dodging the flak from the ''oh, this reason''
and
''oh, that reason'', none of which appear to be grounded in real
life,
mass usage?
> } >} 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
> }
> } Typical answer. You''re saying it is not broken. I have another
> } machine running 6.06 and I am well aware that Ruby 1.8.4 is there. I
> } use it. I was simply trying to install a new application on an
> } existing /stable/ server. Between having an up to date Ruby package
> } and installing or upgrading the WHOLE DISTRO, guess which one is more
> } preferable?
>
> Tradeoffs, tradeoffs, tradeoffs! Release cycles exist for stability. If you
> want to go off the release cycle, you can do so by using the betas of the
> next release. I use a combination of Debian testing and unstable because I
> don''t want to be tied to their release cycle. I pay for it in that
> sometimes things break.
I would be happy if I could install ruby1.8.4 and something else
breaks while what I want to work works. Why should that be so hard? I
get to keep both pieces ... Release cycles are for who? Real users or
the theoretical ones? By the time you release, what happens when those
waiting got tired and just jumped ship?
> } If someone can put up his own packagers, then how hard could it be
> } for the maintainers to add in packages? If it works for me, then what
> } is the problem in placing those packages for people to uses? With all
> } the fancy pinning features that apt has, don''t you think it is
> } possible to make it work for those who want to while keeping the
> } distro stable for those who don''t want to?
> }
> } Maybe I don''t understand maintenance. What I do understand is
whether
> } it worked or whether it is borken.
>
> If you understood maintenance you wouldn''t be asking these
questions (nor
> would you be using such a confrontational tone). The maintainers, like
> everyone else, have a finite amount of time. They aren''t paid for
their
> package maintenance work, so they have to spend a chunk of that time making
> a living. They may have other demands on their time, such as family,
> eating, sleeping, or even other packages. They have established these
> release cycles in an effort to release stable software in a reasonably
> timely manner without dedicating their entire lives to it.
Yeah? What about the guy who put the packages up for Ubuntu? Didn''t
that save time for the maintainer? How hard is it to run unit tests
and make sure it is sane before putting it up? Can the package be put
up and masked so only those who really want to risk breaking their
system actually get to do so? If the maintainer did the last package,
doesn''t the infrastructure already exist for making the new package?
> If you are otherwise happy with your distribution of choice, learn how to
> work around its flaws. If you are unhappy enough with it that you have to
> piss and moan about it on a public mailing list, switch. If you cannot
> stand the idea that these lazy maintainers are not addressing your specific
> problems as soon as you find them, if not sooner, switch to a commercial
> distribution, purchase a support contract, and bitch them out on your dime.
I switched long ago. That''s why I no longer use Debian. Unfortunately
it still appears to resurrect itself and find ways to bite innocent
people who just want a real life. I like Ubuntu enough that I don''t
want to switch. That''s why I am doing the ''piss and
moan'' thing, so
someone can wake up and put in the twenty minutes needed.
> Have you ever heard the phrase, "There ain''t no such thing as
a free
> lunch"? It implies, among other things, that if you aren''t
paying money for
> your software then you will pay in other ways. That may include your time
> and your frustration. You have three rational responses:
>
> 1) Fix your problems for yourself.
> 2) Fix your problems and make your fixes available to the world.
> 3) Pay someone to fix your problems. (This includes switching to commercial
>    software.)
I fixed it. Before posting. So should a hundred more people fix it
before someone realizes that there is a better way to do this?
> Complaining loudly and repeatedly that other people aren''t fixing
your
> problems gratis is pretty much useless. Note how far it''s gotten
you so
> far.
Except it is not just my problem. And that my personal problem is over
but things are still broken. That''s all I am saying. That it is
broken. Just as folks earlier said at the beginning of the thread.
Maybe you just don''t want to get it. Maybe you want to spend the rest
of your life babysitting the system''s idiosyncracies. Maybe you should
try coding Struts and doing Windows admin?

-- G.

On Tue, May 02, 2006 at 01:35:51PM -0400, Austin Ziegler wrote:
} On 5/2/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:
} >On Tue, May 02, 2006 at 04:32:54PM +0000, Guido Sohne wrote:
} >>On May 1, 2006, at 9:09 PM, Gregory Seidman wrote:
[...]
} Developers should not have to be system administrators. The two
} functions are different.

Correct, but you are attempting a system administration task by installing
something on your system. If you have a system administrator to perform
system administration tasks, it''s his (or her) problem, not yours, and
quit
trying to do his (her) job. If you don''t have a system administrator
then
you *are* the sysadmin.

} This sort of attitude, by the way ("learn to administer your
system")
} has greatly hindered (and will continue to hinder) wider adoption of
} Linux by people who neither have the time, inclination, or need to learn
} the intricacies of administering their system.

I will point out that the only people who have the luxury of not learning
how to administer their machines are those who either pay someone else
(e.g. IT staff, Geek Squad, etc.) to do it or have friends/relatives who do
it gratis. This is true independent of operating system choice. There is no
such thing as a zero administration machine. MacOS X is the best of the
bunch for many purposes, in my experience, but it still requires
administration.

} My job is to develop software. Not administer an operating system. Our
} accountant shouldn''t have to learn to administer his operating system
} just because the Debian people want to cater to highly technical people
} who want to control how many pixels above the body the dot of the I
} belongs.

If your job is to develop software, then where is your sysadmin and why
isn''t he (or she) taking care of this for you?

} >I don''t know how many times I''ll have to repeat this
before people get
} >it. It''s all about the tradeoffs. It isn''t possible to
build a system
} >that makes everyone happy all of the time. Choose the distribution
} >with the tradeoffs that best match your needs.
} 
} This is increasingly MacOS X and Windows.

Excellent. Go use what works for you. Stop eating brussels sprouts if you
don''t like brussels sprouts.

} >>>>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.
[...]
} >>What the point in splitting Ruby into lots of little pieces?
} >Flexibility.
} 
} ...which results in inflexibility when it comes to deployment. Debian
} has sliced the core standard library into unrecognisable bits. The
} *only* part of the core standard library that should probably be pulled
} out and made into site library stuff that would be separate is, IMO, the
} Tk support.
[...]

Tradeoffs. See above.

} >Because if you put any effort into learning about the system you are
} >using, Debian makes things easy.
} 
} That''s a joke. It''s also arrogant, asinine, nonsense.

And you are a foul-smelling mule. Please skip the ad hominem attacks. I
said that because I *did* put some effort into learning how to use Debian
and it *did* make things easier for me. It works for me. If it doesn''t
work
for you, go use something else. No one here is forcing you to use Debian or
Ubuntu.

} >If you understood maintenance you wouldn''t be asking these
questions (nor
} >would you be using such a confrontational tone).
} 
} Arrogant nonsense. Hint: I understand maintenance.
} 
} Debian is so slow as to be backwards. Debian is best avoided by people
} who want to do anything useful. Even FreeBSD is more up to date than
} Debian.
} 
} I really can''t stand the arrogant garbage that Debian apologists give
} out.

You have resorted to name-calling and FUD. I will not be baited.

} -austin
--Greg

Gregory,

I understood your advice.

I think this has sunk to the level of help vampire:
http://www.slash7.com/pages/vampires

All of your good advice and help will just keep getting sucked down a
black hole.

-Sean

It is not the help vampire. We don''t need help. I solved my problem
before my first post by searching this list. It''s not help and good
advice here. It is denial ...

-- G.

On 5/2/06, Sean Lynch <sean.seanlynch@gmail.com>
wrote:
> Gregory,
>
> I understood your advice.
>
> I think this has sunk to the level of help vampire:
> http://www.slash7.com/pages/vampires
>
> All of your good advice and help will just keep getting sucked down a
> black hole.
>
> -Sean
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 5/2/06, Sean Lynch <sean.seanlynch@gmail.com>
wrote:
> Gregory,
>
> I understood your advice.
>
> I think this has sunk to the level of help vampire:
> http://www.slash7.com/pages/vampires
>
> All of your good advice and help will just keep getting sucked down a
> black hole.
Dear god, I wish they hadn''t published that article. It''s now
reached
the level of nonsense where people who are arrogant and asinine
because they know they''re right are using it to dismiss legitimate
concerns with a broken process.

Fact: Debian is broken for most people who need anything reasonably up-to-date.
Fact: This brokenness is a fundamental design misfeature.
Fact: People defend this as a "good thing." Even though it''s
undefensible.
Fact: Users are blamed for being insufficently technical when
complaining about the brokenness of the problem.
Opinion: People should be directed to more usable operating systems.

Like MS-DOS.

What''s wrong with you people?

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

On 5/2/06, Sean Lynch <sean.seanlynch@gmail.com>
wrote:
> Gregory,
> I understood your advice.
> I think this has sunk to the level of help vampire:
> http://www.slash7.com/pages/vampires
>
> All of your good advice and help will just keep getting sucked down a
> black hole.
I''m replying a second time because this nonsense has *really* pissed
me off to the point that I will no longer support any railser who uses
Debian. Sorry, but you need to get an operating system or distribution
where the maintainers and "enlightened" users aren''t so
damned
arrogant and asinine so as to not recognise legitimate problems.

Sean, this isn''t a help vampire thing. I don''t use Debian. I
don''t
*want* Gregory to give me advice on how to fix my Debian. Because I
don''t use Debian.

I write software that other people use. If it doesn''t work on Debian,
guess who gets a support message? That''s right, me. Not the idiots who
defend nonsensical Debian packaging. Me. Not the overworked volunteers
who make bad decisions in the process of Debian packaging. Me.

If Debian is the source of numerous problems, AS IT HAS BEEN SHOWN TO
BE MANY TIMES, then the problem isn''t my software. It''s
Debian.

As such, Debian users must first reproduce their problems on a
non-Debian-based system before I will provide support to them for
Ruwiki, PDF::Writer, Archive::Tar::Minitar, MIME::Types, Text::Format
or anything else that I''ve written. If you don''t like it, why
don''t
you thank Greg and Sean for their arrogant and asinine responses here.
I''ve had enough of supporting Debian stupidity.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

On Tue, May 02, 2006 at 04:32:54PM +0000, Guido Sohne
wrote:
> On May 1, 2006, at 9:09 PM, Gregory Seidman wrote:
> >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
> 
> Typical answer. You''re saying it is not broken. I have another  
> machine running 6.06 and I am well aware that Ruby 1.8.4 is there. I  
> use it. I was simply trying to install a new application on an  
> existing /stable/ server. Between having an up to date Ruby package  
> and installing or upgrading the WHOLE DISTRO, guess which one is more  
> preferable?
The whole distro.  It''s called a release cycle -- it means that at some
point you stop adding random new crap and say "this is what we''ve
got".

You''re taking all this far too personally.  You do know that Debian
(and
Ubuntu, by extension) has in excess of 10,000 source packages to work with
and get into some sort of shape?  The fact that the declared-stable version
of the distribution doesn''t include Your Pet Package In It''s
Latest Form
isn''t a personal insult to you, designed to enrage you, but rather just
a
simple fact of release management.
> If someone can put up his own packagers, then how hard could it be  
> for the maintainers to add in packages?
To the stable release?  Very difficult, and quite rightly so.
> If it works for me, then what is the problem in placing those packages for
> people to uses?
There''s that egoism again.  The target audience for these stable
releases
isn''t just you, and what works for you probably doesn''t work
for somebody
else.
> With all the fancy pinning features that apt has, don''t you think
it is
> possible to make it work for those who want to while keeping the distro
> stable for those who don''t want to?
Kinda-sorta, but not really.  Library dependencies in binary packages tend
to cause massive problems there when you try to pin some stuff to unstable. 
This is, in fact, a major benefit of Gentoo -- that it is much easier to
selectively upgrade bits and pieces of your distro without having to drag in
whole new chunks of library.  Glibc is the usual offender, along with
it''s
large and unwieldy friends, but it could be any number of library packages
that happen to have had an ABI bump.  Recently, anything using C++ has been
incompatible with almost everything, as each new compiler minor version has
had a new ABI, meaning that not only do you need to get your library ABIs
right, you also need to ensure that everything was built with the same
compiler.  Thankfully, Debian packages'' metadata can track this and
ensure
that your system doesn''t break itself in horrible, horrible ways, but
it
sure does make it hard to cherrypick packages without going completely nuts.

Experience with Debian Woody indicates that tracking the unstable binaries
for even a small number of packages results in dragging in a fairly huge
amount of the unstable distribution pretty quickly -- as packages get
rebuilt with newer versions of libraries, they get dependencies on new
versions of packages, which have their own dependencies on new versions of
other packages, and so pulling in one or two packages results in half your
system (seriously) comprising packages with versions newer than that
provided in Woody.

The solution (such as it is) to the problem is backports -- where you
rebuild (and sometimes slightly modify to fit) the newer package using the
older environment (libraries, compilers, etc).

But I''m sorry, I''m providing useful information, which
probably gets in the
way of your pissing and moaning.
> >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.
> 
> Actually, I picked Ubuntu because I prefer apt-get to RPM hell. I  
> would have picked Debian. But Debian has some particular problems  
> relating to slow upgrade cycles and general laziness, all in the name  
> of whatever.
"I don''t understand what they''re doing and why
it''s so hard, so I''ll just
insult them, instead".

On behalf of all Debian Developers, I''d like to say "Fuck you very
much, and
the horse you rode in on".
> Anyway, why should I change distros just to get a working and up to date
> Ruby? Are you talking results or excuses?
Ultimately, if your distribution isn''t giving you what you need, then
you
need to use something else.  Certainly what you *shouldn''t* be doing is
complaining on a mailing list totally unrelated to the development of that
distribution.

- Matt

-- 
Sure, it''s possible to write C in an object-oriented way.  But, in
practice,
getting an entire team to do that is like telling them to walk along a
straight line painted on the floor, with the lights off.
		-- Tess Snider, slug-chat@slug.org.au

On Tue, May 02, 2006 at 01:35:51PM -0400, Austin Ziegler
wrote:
> On 5/2/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:
> >On Tue, May 02, 2006 at 04:32:54PM +0000, Guido Sohne wrote:
> >>On May 1, 2006, at 9:09 PM, Gregory Seidman wrote:
> >>>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.
> >>So now we need a distro for PHP development, another distro for
Java
> >>development and another for Perl development, Python development
etc?
> >>
> >>That sounds like a really good idea! Not!
> >If you want a distribution that caters to people who only know how to
> >do those things and are unwilling to learn anything about
> >administering the system, then yes. Of course, if you''re
willing to
> >put some effort into learning to use the system effectively, you can
> >use almost any distribution.
> 
> Developers should not have to be system administrators. The two
> functions are different.
Indeed they are different functions.  So you should stop complaining about
System Administration problems on a Developers mailing list, and go and
nail your System Administrator to the wall and ask them why you have to deal
with these issues.  Don''t have a System Administrator?  Then *you* are
the
System Administrator.
> This sort of attitude, by the way ("learn to administer your
system")
> has greatly hindered (and will continue to hinder) wider adoption of
> Linux by people who neither have the time, inclination, or need to learn
> the intricacies of administering their system.
Seems like things are going exactly to plan, then.  Hint: I don''t
particularly care whether people who don''t care about their system use
Linux.
> My job is to develop software. Not administer an operating system. Our
> accountant shouldn''t have to learn to administer his operating
system
> just because the Debian people want to cater to highly technical people
> who want to control how many pixels above the body the dot of the I
> belongs.
I just don''t get what your problem is.  Debian doesn''t cater
to your
accountant, so instead of choosing from the myriad of other distributions
out there, you want to change Debian so it does cater to your accountant?
> >I don''t know how many times I''ll have to repeat this
before people get
> >it. It''s all about the tradeoffs. It isn''t possible
to build a system
> >that makes everyone happy all of the time. Choose the distribution
> >with the tradeoffs that best match your needs.
> 
> This is increasingly MacOS X and Windows.
Then damn well use it.
> >>>>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.
> >>How much space does irb take?
> >484k on my system.
> 
> A minimal amount,
Depending on how much space you''ve got to play with.
> >>What the point in splitting Ruby into lots of little pieces?
> >Flexibility.
> 
> ...which results in inflexibility when it comes to deployment. Debian
> has sliced the core standard library into unrecognisable bits. The
> *only* part of the core standard library that should probably be pulled
> out and made into site library stuff that would be separate is, IMO, the
> Tk support.
See, your Opinion cuts the package one way, and then someone else''s
opinion
cuts it slightly another way, and then before you know it it''s in all
these
unrecognisable pieces.  Apart from your massive ego, what tells you that
your opinion is so much more important than everybody else''s that your
way
is absolutely and undeniably right, and everyone should do things the way
you claim they need to be done?
> Debian is so slow as to be backwards. Debian is best avoided by people
> who want to do anything useful. Even FreeBSD is more up to date than
> Debian.
What version of Ruby does FreeBSD-STABLE have?  When was it released?  When
is the next version of FreeBSD-STABLE going to be released?

Compare and contrast that with the corresponding answers for Ubuntu
releases.  Don''t try and compare FreeBSD-CURRENT against the stable
releases
of Debian and Ubuntu, though -- that way lies madness.
> I really can''t stand the arrogant garbage that Debian apologists
give
> out.
And vice versa, I''m sure.

- Matt

-- 
"Left to themselves, [marketers] would butt-tag us like polar bears to
track
our buying habits and bombard our phones and emails and computer screens
with ads benefitting them and their clients." --- Tsu Dho Nimh, NANAE

On 5/2/06, Matt Palmer <mpalmer@hezmatt.org>
wrote:
> > Actually, I picked Ubuntu because I prefer apt-get to RPM hell. I
> > would have picked Debian. But Debian has some particular problems
> > relating to slow upgrade cycles and general laziness, all in the name
> > of whatever.
> "I don''t understand what they''re doing and why
it''s so hard, so I''ll just
> insult them, instead".
>
> On behalf of all Debian Developers, I''d like to say "Fuck you
very much, and
> the horse you rode in on".
This further validates my decision to no longer support users of a
Debian distribution. May I include your name and email address as
someone to complain to when someone has a problem with one of my
packages? Frankly, everyone should redirect issues with their packages
on Debian to Matt, Gregory, and Sean.

Nevermind. I''ll add it anyway.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

On Tue, May 02, 2006 at 06:26:41PM +0000, Guido Sohne
wrote:
> On 5/2/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:
> >} So where do the packages in Ubuntu universe come from?
> >
> >They are modified, lightly or heavily, from Debian packages. A huge
number
> >of packages that are available in the Debian repositories are not
provided
> >by the Ubuntu repositories. Debian and Ubuntu have different goals and
> >that is reflected in their respective tradeoffs, including which
packages
> >are available and supported.
> 
> Excuses. Does it work? Yes or no? All the hand waving just wastes time ...
How can you answer the question "where do the package in Ubuntu universe
come from?" with a yes or no?
> >Tradeoffs, tradeoffs, tradeoffs! Release cycles exist for stability. If
you
> >want to go off the release cycle, you can do so by using the betas of
the
> >next release. I use a combination of Debian testing and unstable
because I
> >don''t want to be tied to their release cycle. I pay for it in
that
> >sometimes things break.
> 
> I would be happy if I could install ruby1.8.4 and something else
> breaks while what I want to work works. Why should that be so hard? I
> get to keep both pieces ...
The distribution isn''t called Guidobian.  *You* might be quite happy to
have
Ruby 1.8.4 break something else.  Somebody else is almost guaranteed to be
mightily pissed off.  You are not more important than any other Debian user.
> Release cycles are for who? Real users or the theoretical ones? By the
> time you release, what happens when those waiting got tired and just
> jumped ship?
Release cycles exist so that everybody is made fully aware of how, exactly,
a particular release of the distribution is going to act -- warts and all. 
Any deviation from that specified action is a regression.

If people jump ship because Debian wasn''t fulfilling their needs, then
so
be it.  There are derivatives and alternatives that may well suit their
needs better.  Debian wishes them well, and hopes that they find the perfect
distribution for their personal, particular, needs.

That, in fact, is a great idea -- Guido, I highly recommend that you
commence the creation of Rubian (you can call it Guidobian if you''d
prefer),
a distribution of Linux that contains all the most wonderful Ruby and
Rails-related packages in the world, built just right.  You can even use all
of the existing Debian technology, like apt repositories and the like.

This will serve two purposes: one, you''ll be able to show the Debian
Ruby
maintainers just how easy it is and how much better your way is, and
you''ll
be able to find out just how hard it is to keep all that stuff organised in
a coherent manner.  Remember that you''ve got to make sure that nothing
*ever* breaks or is suboptimal for anyone, or you''ll be bombarded with
hecklers who''ll tell you everything you''ve done is wrong, that
you''re lazy,
and so on.  But I''m sure that won''t happen to you.
> Yeah? What about the guy who put the packages up for Ubuntu?
Didn''t
> that save time for the maintainer? How hard is it to run unit tests
> and make sure it is sane before putting it up?
Point me to a test suite that is 100% guaranteed to catch all possible
regressions.
> Can the package be put up and masked so only those who really want to risk
> breaking their system actually get to do so?
Yes.  It''s called unstable.  Let me just have a look... oh dear me,
imagine
that, the latest Ruby is already there.
> people who just want a real life. I like Ubuntu enough that I
don''t
> want to switch. That''s why I am doing the ''piss and
moan'' thing, so
> someone can wake up and put in the twenty minutes needed.
Then please, do the ''piss and moan'' thing constructively.  Go
to malone,
report your bugs, deal with the objections, and convince the maintainers to
fix it.  Note that fundamentally changing the way that Ubuntu does releases
isn''t going to happen, so don''t bother suggesting that --
"yeh canna change
the laws of Physics" and all that.

Incidentally, if all it *really* takes is 20 minutes, why don''t you do
it
yourself?
> Maybe you just don''t want to get it. Maybe you want to spend the
rest
> of your life babysitting the system''s idiosyncracies. Maybe you
should
> try coding Struts and doing Windows admin?
That''s why we know that these little niggles aren''t real
problems.  <grin>

- Matt

OK, not that I''m the list-police but can we either stop this thread
immediately and/or take it off-list, please?  The conversation is no
longer constructive or helpful to RoR developers and is straying way
off-topic.

Thanks.

Peace and progress,
..dean

On Tue, May 02, 2006 at 03:20:13PM -0400, Austin Ziegler
wrote:
> Fact: Debian is broken for most people who need anything reasonably 
> up-to-date.
Rewording for truth: Debian *stable* does not contain the most up-to-date
software.
> Fact: This brokenness is a fundamental design misfeature.
Correct.
> Fact: People defend this as a "good thing." Even though
it''s undefensible.
Not having your system change out from underneath you when you''re
running
large-scale production systems isn''t a good thing?
> Opinion: People should be directed to more usable operating systems.
Please do so.

To save slightly on list traffic (hah!) -- I heartily endorse your decision
to refuse to support Debian users using your software.  You are unable to
provide effective support for their environment, and you should not be
burdened with their problems.

- Matt

-- 
I am cow, hear me moo, I weigh twice as much as you. I''m a cow, eating
grass, methane gas comes out my ass. I''m a cow, you are too; join us
all!
Type apt-get moo.

On 02/05/06, Matt Palmer <mpalmer@hezmatt.org> wrote:
> What version of Ruby does FreeBSD-STABLE have?
1.8.4. The ports tree updates as needed between releases.

--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

Can''t we all just get along? THis is the ruby on rails mailing list,  
*not* the Religion on Rails list.

-Ezra

[ccing just to be on the record - replies back to me if you like]

On 03/05/06, Matthew Palmer <mpalmer@hezmatt.org>
wrote:
> [Taking this off-line, as it''s well off-topic]
>
> On Tue, May 02, 2006 at 09:47:39PM +0100, Dick Davies wrote:
> > On 02/05/06, Matt Palmer <mpalmer@hezmatt.org> wrote:
> >
> > >What version of Ruby does FreeBSD-STABLE have?
> >
> > 1.8.4. The ports tree updates as needed between releases.
>
> So what does the STABLE actually mean, then?
It means the base system (which comes as a full package - userland
and kernel) is stable.

Ports is a cvs tree of makefiles for third party apps, managed under cvs,
which install into /usr/local. They''re completely optional.

The Freebsd ports tree has 1.8.4. freebsd stable doesn''t include ruby,
or perl, or apache, etc

FWIW, when it comes to to stablity
I respect the ''you don''t have to like it, but please
don''t get ass prints on
my door when you leave'' Debian policy (that''s not ruby
specific).


What pissed off at ruby being broken into multiple packages by Debian,
and I''m also pissed off at the ''we know best''
attitude of maintainers
*when talking to those users*. Are there really a lot of ruby users
crying out for those savings? Everyone I speak to ''puts up''
with
debian on this issue (until they find something better, at least).

irb and ri may be a few hundred k on intel (they''re much smaller on
arm incidentally, I built ruby on my gumstix last month), but they''re
part of ruby.
If you decided to put man pages into separate packages you''d get
the same response from many more users.
> I understand I''m coming at this from a very different
point-of-view than
> that of an experienced FreeBSD admin, but I don''t think you can
compare a
> stable, unchanging release, from something that doesn''t really
even *have* a
> release.  How can you "certify" a 3rd party software package as
working on a
> particular version of FreeBSD?
Don''t be scared :) The Makefile specifies what OS versions the port
works on,
and that''s checked at install time.

[ Incidentally, NetBSDs pkgsrc tree lets you set an ''`ACCEPTABLE
LICENSES''
string in /etc/mk.conf so you can state your opinion on whether, say,
openssl has a sensible license or not. If Debian could incorporate something
similar, I might think about trying it again :) ]

--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

> 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.
/usr/lib belongs to the distribution, /usr/local is for local (non
distribution) additions.  As far as I know, that rule more or less holds
for any modern Linux distributation, and is part of the standards.

Ciao,
-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

Guido Sohne wrote:
> 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?
To better understand the problem, you need to look at things from
another point of view - that of the distribution.  Ruby is one of
*thousands* of packages in Debian and Ubuntu.  This pretty much
guarantees that a package that is very important to someone will be
released just after the distribution does.  And release they do - can
you imagine trying to make something stable out of a distribution that
has bits and pieces constantly being upgraded?

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

> The package system gets in the way. It''s not a help. There are
certain
> situations where that happens. Trying to make it go away by pretending
> it doesn''t exist doesn''t solve it.
Sure, packaging systems get in the way when you have a laser-tight focus
on some component of a system, and are capable of maintaining it,
upgrading it, and watching it for security fixes, because it''s
absolutely vital to what you do.  99% of the software on your system,
however, isn''t stuff you want to maintain by hand.  Imagine this debate
repeated for all of your system... Perl, Python, Apache, Postgresql,
OpenOffice, Gnome... all those development teams can bitch about their
baby not getting all the attention, but on a general-purpose system, you
have to make some tradeoffs.

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

>From http://packages.debian.org/testing/interpreters/ruby1.8 
On Debian, Ruby 1.8 is provided as separate packages. You can get full Ruby 1.8
distribution by installing following packages.

  ruby1.8 ruby1.8-dev ri1.8 rdoc1.8 irb1.8 ruby1.8-elisp
  ruby1.8-examples libdbm-ruby1.8 libgdbm-ruby1.8 libtcltk-ruby1.8
  libopenssl-ruby1.8 libreadline-ruby1.8


Should take all of about 5 minutes

Ross

On Wed, May 03, 2006 at 09:57:32PM +0200, David N. Welton wrote:
 
> Sure, packaging systems get in the way when you have a laser-tight focus
> on some component of a system, and are capable of maintaining it,
> upgrading it, and watching it for security fixes, because it''s
> absolutely vital to what you do.  99% of the software on your system,
> however, isn''t stuff you want to maintain by hand.  
And, if you happen to be the type of sysadmin that enjoys maintaining
everything by hand then Linux From Scratch, http://www.LinuxFromScratch.org,
might be just the distribution, or lack of distribution, for you.  Whatever
the case, if the distribution one is using doesn''t fit one''s
needs/style
then try another distrubution.  I started out with Slackware in the 1.x
Linux kernel days.  At some point I switched to Mandrake.  And recently,
after Mandrake got on enough of my nerves, I switched to Gentoo.  I''ve
also
went through building a Linux From Scratch system a couple of times and
learned alot in the process.


Kevin
http://www.RawFedDogs.net
http://www.WacoAgilityGroup.org
Bruceville, TX

One scanario where you might want to separate would be a productions server
running Ruby apps.  Would you want or need irb, ri and rdoc on a server where
you''re not doing development? (that''s not a retorical question
I''m new to Ruby and Rails)

For the Ruby or Rails developer I agree it is a bit of a pain.  I''m
planning on building a Debian Rails box so I might look at creating a meta
package and submit it to the package maintainer time permitting.  The downside
is the long time it will take to get to a stable release (the one problem I have
with Debian).

Cheers

Ross
> -----Original Message-----
> From: Austin Ziegler [mailto:halostatue@gmail.com]
> Sent: Friday, 5 May 2006 3:30 AM
> To: Ross Dawson
> Subject: Re: Why Does Ruby on Debian Blow? (Was: [Rails] Mongrel 3.15,
> Ubuntu and Park place (S3))
> 
> 
> On 5/3/06, Ross Dawson <Ross_Dawson@aas.kaz.com.au> wrote:
> > >From http://packages.debian.org/testing/interpreters/ruby1.8
> >
> > On Debian, Ruby 1.8 is provided as separate packages. You 
> can get full Ruby 1.8 distribution by installing following packages.
> >
> >   ruby1.8 ruby1.8-dev ri1.8 rdoc1.8 irb1.8 ruby1.8-elisp
> >   ruby1.8-examples libdbm-ruby1.8 libgdbm-ruby1.8 libtcltk-ruby1.8
> >   libopenssl-ruby1.8 libreadline-ruby1.8
> 
> And the problem is that irb1.8, ri1.8, and rdoc1.8 have no business
> being separate. (At least the program files.) The data files, I
won''t
> argue with. But the items noted are part of the core distribution.
> OpenSSL is probably also core enough to be important.
> 
> Debian has made a lot of stupid decisions regarding Ruby. At one
> point, ruby zlib support wasn''t standard, even though it was in
the
> core.
> 
> Ultimately, there''s no defence for the decisions they have made
> contrary to what the development team have made.
> 
> -austin
> --
> Austin Ziegler * halostatue@gmail.com
>                * Alternate: austin@halostatue.ca
>

On 5/4/06, Ross Dawson <Ross_Dawson@aas.kaz.com.au>
wrote:
> One scanario where you might want to separate would be a productions
> server running Ruby apps.  Would you want or need irb, ri and rdoc on
> a server where you''re not doing development? (that''s not
a retorical
> question I''m new to Ruby and Rails)
That''s why I made the statement that I did:

    And the problem is that irb1.8, ri1.8, and rdoc1.8 have no
    business being separate. (At least the program files.)
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    The data files, I won''t argue with.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ok. ri and rdoc aren''t just commands. There are classes behind both.
Rdoc is a full-on document generator and templating system with an
interface to graphviz. (Limited purpose on that interface, but it''s
present nonetheless.) Ri is *generated* by rdoc, but the ri system is
also a YAML data lookup.

These things -- and bits and pieces of irb -- could be used by the
enterprising developer interested in reuse.

So ... no.

There''s no good excuse for carving up the bits of the Ruby Standard
Library that aren''t bringing in X (e.g., Ruby''s Tk support).

I do not believe that zlib and OpenSSL are optional components of Ruby,
either. (zlib is required to make RubyGems run; there is an optional
security feature built into RubyGems that can be done with ... OpenSSL.)

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

>>>>> "Ross" == Ross Dawson
<Ross_Dawson@aas.kaz.com.au> writes:
> One scanario where you might want to separate would be a productions
> server running Ruby apps. Would you want or need irb, ri and rdoc on
> a server where you''re not doing development?
Yes, you would. Because at some point, probably at 3AM on a Sunday
morning, the application is going to break down and you''ll want tools
available with which to fix it. If someone decided to save a few
measly kilobytes out of the machine''s several hundred gigabytes of
disk by not including those tools, you''re going to hate that someone
quite a lot.

Reverse the question, if you will. When does it ever *hurt* to have a
full Ruby installation there? The whole thing is only a few megabytes
(26MB for Ruby 1.9.0 on my OSX machine, and half of that is
documentation), you''d have to be extremely short on disk for it to
make a practical difference to take out _parts_ of it. The Debian
variant of chopping it up into (according to a Debian proponent''s post
yesterday) _twelve_ pieces (several of which don''t even mention Ruby
in their names!) seems to me to very much be a "one size fits nobody"
solution.
-- 
		     Calle Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
              Please pay no attention to the panda in the fridge.

Calle Dybedahl wrote:
>>One scanario where you might want to separate would be a productions
>>server running Ruby apps. Would you want or need irb, ri and rdoc on
>>a server where you''re not doing development?
> 
> Yes, you would. Because at some point, probably at 3AM on a Sunday
> morning, the application is going to break down and you''ll want
tools
> available with which to fix it. If someone decided to save a few
> measly kilobytes out of the machine''s several hundred gigabytes of
> disk by not including those tools, you''re going to hate that
someone
> quite a lot.
We are rather assuming that they were split out because of the space 
argument, here...  Maybe there was another issue?  It wouldn''t be
unlike
Debian to split a package over, for instance, legal or licencing issues.

-- 
Alex

>>>>> "Alex" == Alex Young <alex@blackkettle.org>
writes:
> We are rather assuming that they were split out because of the space
> argument, here...  Maybe there was another issue?  It wouldn''t be
> unlike Debian to split a package over, for instance, legal or
> licencing issues.
Space is the only issue the Debian proponents have mentioned so far.
And when it comes to licensing issues I''ve only seem them distribute
cut-down packages with the content that was insufficiently pure for
them simply removed, not moved to a separate package. For example, to
the best of my knowledge you don''t get the full documentation for Perl
on a Debian system unless you download and install a source
distribution yourself.
-- 
		     Calle Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
    "I don''t know what art these programs are state-of; possibly
macrame."
		     -- Dr Richard A. O''Keefe, comp.risks

On 05/05/06, Austin Ziegler <halostatue@gmail.com> wrote:
> I do not believe that zlib and OpenSSL are optional components of Ruby,
> either. (zlib is required to make RubyGems run; there is an optional
> security feature built into RubyGems that can be done with ... OpenSSL.)
No doubt someone will correct me if I''m wrong,
but debian seem to have political reasons for breaking
out openssl - see:

  http://lists.debian.org/debian-legal/2002/10/msg00111.html

for starters (realize that''s an old post, but it was still making my
life awkward
at Christmas).

 I don''t have time for that sort of thing, so I stopped using it.





--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

It sure doesn''t cost too much to keep them there and it would be  
great to know that Ruby is Ruby where ever you are.

The day you need to debug something on the server in a jiffy, it''s  
great to have irb, ri and rdoc. Is it that expensive to have them  
there compared to fragmenting Ruby and the troubles and difficulties  
that may bring?

Any way, I think I''m done with this thread.

-- G.

On May 4, 2006, at 11:20 PM, Ross Dawson wrote:
> One scanario where you might want to separate would be a  
> productions server running Ruby apps.  Would you want or need irb,  
> ri and rdoc on a server where you''re not doing development?
(that''s
> not a retorical question I''m new to Ruby and Rails)
>
> For the Ruby or Rails developer I agree it is a bit of a pain. 
I''m
> planning on building a Debian Rails box so I might look at creating  
> a meta package and submit it to the package maintainer time  
> permitting.  The downside is the long time it will take to get to a  
> stable release (the one problem I have with Debian).
>
> Cheers
>
> Ross
>
>> -----Original Message-----
>> From: Austin Ziegler [mailto:halostatue@gmail.com]
>> Sent: Friday, 5 May 2006 3:30 AM
>> To: Ross Dawson
>> Subject: Re: Why Does Ruby on Debian Blow? (Was: [Rails] Mongrel  
>> 3.15,
>> Ubuntu and Park place (S3))
>>
>>
>> On 5/3/06, Ross Dawson <Ross_Dawson@aas.kaz.com.au> wrote:
>>>> From http://packages.debian.org/testing/interpreters/ruby1.8
>>>
>>> On Debian, Ruby 1.8 is provided as separate packages. You
>> can get full Ruby 1.8 distribution by installing following packages.
>>>
>>>   ruby1.8 ruby1.8-dev ri1.8 rdoc1.8 irb1.8 ruby1.8-elisp
>>>   ruby1.8-examples libdbm-ruby1.8 libgdbm-ruby1.8 libtcltk-ruby1.8
>>>   libopenssl-ruby1.8 libreadline-ruby1.8
>>
>> And the problem is that irb1.8, ri1.8, and rdoc1.8 have no business
>> being separate. (At least the program files.) The data files, I
won''t
>> argue with. But the items noted are part of the core distribution.
>> OpenSSL is probably also core enough to be important.
>>
>> Debian has made a lot of stupid decisions regarding Ruby. At one
>> point, ruby zlib support wasn''t standard, even though it was
in the
>> core.
>>
>> Ultimately, there''s no defence for the decisions they have
made
>> contrary to what the development team have made.
>>
>> -austin
>> --
>> Austin Ziegler * halostatue@gmail.com
>>                * Alternate: austin@halostatue.ca
>>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Alex Young wrote:
> Karl Brodowsky 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 :-)
As far as I know, those who want to go with "bleeding edge" or
"testing
level" software, rather than the stable stuff, generally either

a. build from pure source downloaded from the Internet, or
b. use an unstable distro like Fedora Core or Debian unstable, or
c. Use Gentoo, which compiles nearly everything from source.

I''ve picked c., because it''s pretty convenient to mix stable
and testing
and unstable without leaving the Portage repository. Security patches
for most distros only apply to the stable subset.

-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

I''ve had fairly good luck with CygWin, although I don''t do
development
there. I''m constrained to a Windows workstation in my day job, and my
order of preference is

a. Native Windows packages
b. CygWin
c. VMWare with a Linux guest.

I was dual-booted for a while, but it got to be a real PITA to go back
to Windows in the middle of an intensely focused Linux session.

Speaking of Linux guests, I am probably going to upload my Gentoo Rails
server Virtual Machine tomorrow. I''ve done all the tweaking I can and
want some testers.

Austin Ziegler wrote:
> ... 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
> -- 
> Austin Ziegler * halostatue@gmail.com
>               * Alternate: austin@halostatue.ca
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>   
-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

> 
> It does some things better than Debian itself, but it inherits a lot
> of the nonsense.
> 
> I always build Ruby from scratch on Debian. Anything else is nonsense.
> 
> -austin
I agree with this 100%

In my opinion the problem with Debian isn''t so much Debian but the
users
having trouble.  They are expecting Debian to be something it''s not.

The reason I''ve always prefered Debian is because all of the system
compontents are stable and slow moving and since I''m not an expert in
managing those that''s ideal.

On the other hand the parts that I am an expert with, my primary
application stack, I run from source and manage myself.

Although Debian''s handling of Ruby has been exceptionally poor.

-- 
Posted via http://www.ruby-forum.com/.