I’m confused. Wasn’t threading fixed in 1.8.6, negating the need for
fastthread? Why is fastthread still a requirement of Mongrel? Just
curious. 
On Jan 1, 2008 10:26 PM, Kevin W. [email protected] wrote:
I’m confused. Wasn’t threading fixed in 1.8.6, negating the need for
fastthread? Why is fastthread still a requirement of Mongrel? Just
curious.
1.8.6 ships with fastthread enabled by default, but some distro
maintainers build with --disable-fastthread (I don’t remember the
exact configure command right now).
Also, mongrel is compatible with 1.8.4 and 1.8.5, and that is the
standard version that is currently powering a lot of servers.
–
Luis L.
Multimedia systems
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams
Thank you.
I think we will probably remove the Fastthread and
cgi_multipart_eof_fix dependencies at the same time we get 1.9
compatibility. Seems appropriate to me at least.
Evan
On Tue, 1 Jan 2008 17:26:38 -0700, “Kevin W.” [email protected]
wrote:
I’m confused. Wasn’t threading fixed in 1.8.6, negating the need for
fastthread? Why is fastthread still a requirement of Mongrel? Just
curious.
Welll… it greatly depends which patchlevel of 1.8.6 you have. The
earlier
patchlevels are actually kind of broken; using fastthread in that case
works around the problems.
-mental
On 1/2/08, Evan W. [email protected] wrote:
I think we will probably remove the Fastthread and
cgi_multipart_eof_fix dependencies at the same time we get 1.9
compatibility. Seems appropriate to me at least.
Evan,
I hope I’m wrong here, but the way I understand what you’re saying is
that
Mongrel will stop patching Ruby once Mongrel is ready to run on Ruby
1.9.
Wouldn’t that mean that you at the same time removed support for all
Ruby
versions below 1.8.6 p36?
I’m happy to play with Ruby 1.9, but afaik it’s not meant for production
use
until it’s called 2.0.
Happy new year, all!
/David
On Wed, 2 Jan 2008 20:05:13 +0100, “David V.” [email protected]
wrote:
I hope I’m wrong here, but the way I understand what you’re saying is that
Mongrel will stop patching Ruby once Mongrel is ready to run on Ruby 1.9.
Wouldn’t that mean that you at the same time removed support for all Ruby
versions below 1.8.6 p36?
Well, I’d hope what he meant was that Mongrel would still use fastthread
if
it was installed, but it would no longer be a dependency of the Mongrel
gem.
Which would be as it ought to be – my intent was for fastthread to fill
the
gap between 1.8 and 1.9, and then eventually go away once people stopped
needing/installing it. But the folks on 1.8.x aren’t going away for a
while,
so I think it’s important that Mongrel uses it if it is
installed/supported.
-mental
Yeah, it would.
That’s why we need to talk about it.
I know people complained when the idea was broached last time, so we
need to see if p110 is stable and widespread enough now.
Of course everyone is free to continue using older Mongrel versions.
Evan
On Wed, 2 Jan 2008 15:17:48 -0500, “Evan W.” [email protected]
wrote:
I know people complained when the idea was broached last time, so we
need to see if p110 is stable and widespread enough now.Of course everyone is free to continue using older Mongrel versions.
I think the best option is to make it a “soft dependency”. That way
people who need fastthread can install it and benefit from it, but
we can stop forcing it to install with the gem.
-mental
That’s what I should have meant. It could stop being a gem dependency
but still be a rescued require.
Who is still deployed on 1.8.5 or 1.8.4?
Evan
On Jan 2, 2008 1:55 PM, Evan W. [email protected] wrote:
That’s what I should have meant. It could stop being a gem dependency
but still be a rescued require.Who is still deployed on 1.8.5 or 1.8.4?
I’m still using 1.8.5 on my production servers.
Kirk H.
On Jan 2, 2008 6:55 PM, Evan W. [email protected] wrote:
That’s what I should have meant. It could stop being a gem dependency
but still be a rescued require.Who is still deployed on 1.8.5 or 1.8.4?
EngineYard uses 1.8.5 in most of their servers (AFAIK).
Other VPS/Xen hosts that have ruby pre-installed have 1.8.4 or 1.8.5,
but most of them allow you build ruby from sources.
–
Luis L.
Multimedia systems
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams
On Jan 2, 2008, at 2:55 PM, Evan W. wrote:
Who is still deployed on 1.8.5 or 1.8.4?
Debian etch ships 1.8.5.
-Nate
On Jan 2, 2008, at 1:25 PM, Luis L. wrote:
–
Luis L.
Multimedia systems
We have been updating to 1.8.6 p111 but we do still have a lot of ruby
1.8.5’s out there. But I am in favor of making it an optional
dependency.
Cheers-
- Ezra Z.
– Founder & Software Architect
– [email protected]
– EngineYard.com
CentOS 5 still ships with 1.8.5…
Quoting Ezra Z. [email protected]:
1.8.5’s out there. But I am in favor of making it an optional
dependency.
I know of quite a few 1.8.4 deployments out there as well. Please
don’t exclude these. We are also working towards getting these
upgraded. Release of Ruby 1.9 should help this.
Mike B.
On Jan 3, 2008, at 8:04 AM, Will G. wrote:
CentOS 5 still ships with 1.8.5…
And by extension (or perhaps pretension) so does Red Hat Enterprise
Linux version 5 - which is the licensed linux at NC State University
(and which I use for most of extension.org’s servers). I’ve been
hand replacing the RHELv5 RPM’s with a configure/make/make install
version of Ruby 1.8.6 - but until RHELv6 comes out, I seriously doubt
many of the RHEL customers are going to have a 1.8.6 version of Ruby -
except for the crazy ones like me.
We are going to be using LogicWorks for hosting portions of
extension.org and they are also apparently a RHEL shop.
I doubt 1.8.5 is going away anytime soon.
Jason
Jason Y. -- Systems Manager, eXtension
http://about.extension.org/wiki/Jason_Young
______________________________________I’m a little surprised. We always build things like ruby so we have a
bit
more control over what is turned on or off. Most distributions ship with
a
version of ruby (or python, or any other scripting language) that is
configured for their convenience rather than ours. We build ruby on our
development machines even though Macs ship with a reasonable ruby
installed.
Why are you surprised? The version that ships with CentOS 5 is, IMHO,
quite reasonable - ruby 1.8.5 (2006-08-25) [i386-linux]
Best of all, its supported by a commercial entity (CentOS packages lag
behind RedHat Enterprise by about 2 days, I believe). Meaning that I, a
lone developer/sysadmin , can spend my time building apps for my
customers instead of recompiling Ruby.
It’s a case of “good enough”. I suspect you’ll also find this sentiment
resonates with other small groups of developers.
==
Will G.
It may be good enough but it’s built for i386 and you get the features
redhat chose to install with it. The one on my local machine is: ruby
1.8.6(2007-09-23 patchlevel 110) [
i686-darwin9.1.0]. If nothing else it is compiled for i686 rather than
i386
which means the compiler can use 686 instructions to build my version of
ruby rather than be limited to 386 instructions in yours.
If you build your own you can control what features are installed and
the
gems library will not mix with what ever gems redhat chose to install.
(I
don’t remember if they actually install gems or not so I may be off base
here.)
In any case, it’s not that important, Just my feeling…