Forum: Ruby on Rails Mongrel 3.15, Ubuntu and Park place (S3)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
46710a442003bd7f8e0100b41e4cfe7c?d=identicon&s=25 Maurizio Balestrieri (Guest)
on 2006-05-03 18:56
(Received via mailing list)
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.
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 unknown (Guest)
on 2006-05-03 18:57
(Received via mailing list)
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.
722a18819725c0f6275b556ced89a3f4?d=identicon&s=25 Sascha Ebach (Guest)
on 2006-05-03 18:57
(Received via mailing list)
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
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 18:57
(Received via mailing list)
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
722a18819725c0f6275b556ced89a3f4?d=identicon&s=25 Sascha Ebach (Guest)
on 2006-05-03 18:57
(Received via mailing list)
> } 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
59528506e6297141161afcde91d677c9?d=identicon&s=25 Nicolai Reuschling (codeblogger)
on 2006-05-03 18:57
(Received via mailing list)
Hi Sascha, maybe you want to check this out (I presume you're German):

http://o9y.net/archives/2006/02/17/ruby-on-rails-m...
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 Zed Shaw (Guest)
on 2006-05-03 18:57
(Received via mailing list)
On 5/1/06 7:13 AM, "Gregory Seidman" <gsslist+ror@anthropohedron.net>
wrote:

> without stepping on one another's toes. A good part of the policy can
> 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/
46710a442003bd7f8e0100b41e4cfe7c?d=identicon&s=25 Maurizio Balestrieri (Guest)
on 2006-05-03 18:57
(Received via mailing list)
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).
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 18:57
(Received via mailing list)
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
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 18:57
(Received via mailing list)
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
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-05-03 18:57
(Received via mailing list)
# cd /usr/ports/lang/ruby18 && make install clean

That's how the REAL 1337 h4x0rz do it OMG LOL!!1one
30fc5b9fc8155d9c8bd171bd0de4c8b9?d=identicon&s=25 Marcelo Bello (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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...
38a8230ed3d5c685558b4f0aad3fc74b?d=identicon&s=25 Joe Van Dyk (Guest)
on 2006-05-03 18:58
(Received via mailing list)
On 5/1/06, Zed Shaw <zedshaw@zedshaw.com> wrote:
> > } I know because I'm smart and I love explaining things to people.
> >
> basically amounts to a personal attack with pathetically structured insults
> If this many people continually run into the problem of how debian packages
> 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).
678aa0aabf79a4933b7efc6d585dc141?d=identicon&s=25 Matt White (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-03 18:58
(Received via mailing list)
On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:
> 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
30269682335f1fb247d71969fa715b5e?d=identicon&s=25 Roberto Saccon (rsaccon)
on 2006-05-03 18:58
(Received via mailing list)
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 ?
678aa0aabf79a4933b7efc6d585dc141?d=identicon&s=25 Matt White (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
31ae911dd0fe0ee0b81519d6d2627886?d=identicon&s=25 Gravy Face (gravyface)
on 2006-05-03 18:58
(Received via mailing list)
Hows does Ubuntu stack up?   It's based on Debian.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
31ae911dd0fe0ee0b81519d6d2627886?d=identicon&s=25 Gravy Face (gravyface)
on 2006-05-03 18:58
(Received via mailing list)
What Linux/BSD distros out there make the RoR kids happy?
F9eaf9f5508d6ce31cf779445d77d2af?d=identicon&s=25 Karl Brodowsky (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
31ae911dd0fe0ee0b81519d6d2627886?d=identicon&s=25 Gravy Face (gravyface)
on 2006-05-03 18:58
(Received via mailing list)
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.
70d14478017f13972bb6d82a5dcf161f?d=identicon&s=25 Toby Boudreaux (Guest)
on 2006-05-03 18:58
(Received via mailing list)
I've had great luck with RHEL4 and CentOS4 (usually with SELinux
enabled).
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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 :-)
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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/ScaleWithR...

--
Giles Bowkett
http://www.gilesgoatboy.org
882cc23c77c5c6d27613c51396a02a0d?d=identicon&s=25 Stephen Bartholomew (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
4ba4bb954bcfec077d9708b540558926?d=identicon&s=25 Guido Sohne (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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.
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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.
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
632a66b453075df1176d8a0c7e33cfc9?d=identicon&s=25 Rafael Szuminski (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
6805b35d0a8ea3ede0a7da2d4cf5ae77?d=identicon&s=25 Jonathan Weiss (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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
6805b35d0a8ea3ede0a7da2d4cf5ae77?d=identicon&s=25 Jonathan Weiss (Guest)
on 2006-05-03 18:58
(Received via mailing list)
> }
> } 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
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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.
6805b35d0a8ea3ede0a7da2d4cf5ae77?d=identicon&s=25 Jonathan Weiss (Guest)
on 2006-05-03 18:58
(Received via mailing list)
>
> 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
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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?
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-03 18:58
(Received via mailing list)
On 5/1/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:
> 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
632a66b453075df1176d8a0c7e33cfc9?d=identicon&s=25 Rafael Szuminski (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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?
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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.
Bcfc926d36e15709d7e6c70b9791211a?d=identicon&s=25 Vamsee Kanakala (Guest)
on 2006-05-03 18:59
(Received via mailing list)
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.
A760c1a3dfb5a31e6139838a43e94089?d=identicon&s=25 Nicolas Kassis (Guest)
on 2006-05-03 18:59
(Received via mailing list)
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:
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>



--
Nicolas Kassis
3ccecc71b9fb0a3d7f00a0bef6f0a63a?d=identicon&s=25 Kent Sibilev (Guest)
on 2006-05-03 18:59
(Received via mailing list)
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:
>
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Kent
---
http://www.datanoise.com
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2006-05-03 18:59
(Received via mailing list)
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
99c89698aa4661ec1750c0fb9b798eab?d=identicon&s=25 Nicholas P. Mueller (Guest)
on 2006-05-03 18:59
(Received via mailing list)
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
434e2f06e24f21b297bfd52a782264fb?d=identicon&s=25 Michael Gurski (Guest)
on 2006-05-03 18:59
(Received via mailing list)
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
4ba4bb954bcfec077d9708b540558926?d=identicon&s=25 Guido Sohne (Guest)
on 2006-05-03 18:59
(Received via mailing list)
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?

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

> 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.
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 19:00
(Received via mailing list)
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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-03 19:00
(Received via mailing list)
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.

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
4ba4bb954bcfec077d9708b540558926?d=identicon&s=25 Guido Sohne (Guest)
on 2006-05-03 19:00
(Received via mailing list)
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.

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

> } Typical answer. You're saying it is not broken. I have another
> 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 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.
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 19:00
(Received via mailing list)
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
55428cbf149e35dd4b65f1d019d04139?d=identicon&s=25 Matt Palmer (Guest)
on 2006-05-03 19:01
(Received via mailing list)
On Tue, May 02, 2006 at 04:32:54PM +0000, Guido Sohne wrote:
> 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
55428cbf149e35dd4b65f1d019d04139?d=identicon&s=25 Matt Palmer (Guest)
on 2006-05-03 19:02
(Received via mailing list)
On Tue, May 02, 2006 at 01:35:51PM -0400, Austin Ziegler wrote:
> >>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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-03 19:02
(Received via mailing list)
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
55428cbf149e35dd4b65f1d019d04139?d=identicon&s=25 Matt Palmer (Guest)
on 2006-05-03 19:02
(Received via mailing list)
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
A52b0e1c5d982f2512a03c5dbfd033d6?d=identicon&s=25 Dick Davies (Guest)
on 2006-05-03 19:02
(Received via mailing list)
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/
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-05-03 19:05
(Received via mailing list)
Can't we all just get along? THis is the ruby on rails mailing list,
*not* the Religion on Rails list.

-Ezra
58213d4c1552914aaa20e9cab0010149?d=identicon&s=25 David N. Welton (Guest)
on 2006-05-03 21:48
(Received via mailing list)
> 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/
58213d4c1552914aaa20e9cab0010149?d=identicon&s=25 David N. Welton (Guest)
on 2006-05-03 21:51
(Received via mailing list)
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/
58213d4c1552914aaa20e9cab0010149?d=identicon&s=25 David N. Welton (Guest)
on 2006-05-03 22:00
(Received via mailing list)
> 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/
4c7fefbf939854394fdd6bc25ab49d91?d=identicon&s=25 Kevin Monceaux (Guest)
on 2006-05-04 03:01
(Received via mailing list)
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
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-05-07 06:48
(Received via mailing list)
Alex Young wrote:
> 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
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-05-07 06:54
(Received via mailing list)
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:
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
A0ed1bbfe42f4f87e6db0a16706246e2?d=identicon&s=25 mgreenly (Guest)
on 2006-05-07 23:12
>
> 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.
This topic is locked and can not be replied to.