I kindly disagree.

The biggest advantage of Perlmonks is the user base, which is both incredibly knowledgeable and helpful.

our german perl-community.de board runs on one server at the moment (which costs about 50€/month, and is financed by several forum members donating 2-10€ every month.

When the new community is starting, a small server is probably sufficient, and as soon as it gets popular, there will likely be someone who wants to sponsor this I guess.

Who do you think would donate the servers and administration and internet access for this hypothetical new server?

Noted; Thank you. Now is not the time to solve such problems. Instead, let's be optimistic and assume that they can be solved.

If they say no, then "finding sponsorship" becomes a TODO. Which is not impossible. It will enforce a bit of positive advocacy.

approach Pair with the question about running both

Or not. Given how well they've supported us prior to, and since, the password hack debacle, I'd put "Get PAIR to host the new PerlMonks" in the "Things not to repeat" column.

What is the sound of Windows? Is it not the sound of a wall upon which people have smashed their heads... all the way through?

I believe jdporter gets the idea that pair.com has offered us lousy support from me. I have to disagree with that assertion, however.

I regularly but infrequently complain (nearly bitterly) about being "stuck" with pair.com hosting because the two most important things that would make dramatic improvements to PerlMonks performance are both tied to getting off of FreeBSD and back on Linux. pair.com does a good job of hosting but this job is built around an infrastructure that requires FreeBSD and a few other things that cause PerlMonks some real problems and certainly frustrate me on several levels when I try to work on performance problems.

One of the two major performance problems that always come back to cause impressive slowness at PerlMonks is mysql on FreeBSD becoming incapable of getting much done for periods of quite varied lengths. Even worse is Apache children becoming too large (and sometimes too numerous) and the web servers running out of memory. The reason this second one is made worse by FreeBSD is that the solution for it is to use Apache::SizeLimit to reap bloated children and that module is significantly more difficult to get working well on FreeBSD due to how process size is reported (we are using that module but it just isn't that effective on FreeBSD).

Well, there are a lot of other potential solutions. But all of them require either a significant investment in time or some basic operating system privileges that pair.com does not generally allow their clients to have.

I don't consider FreeBSD as something to be generally avoided when looking for hosting. And I don't fault pair.com for choosing FreeBSD nor for exercising strict control over their hosts. And I doubt most people would have significant problems with either of those points if they decided to purchase hosting from pair.com. But they certainly continue to cause serious problem for PerlMonks and for my efforts to improve site performance due to some peculiar quirks of the site's implementation and of my personality.

I am personally quite thankful to pair.com for hosting PerlMonks for so long. They have certainly donated a lot of resources over that time. And they have demonstrated their ability to deal effectively with problems with the hosts over that time. They don't deal with problems with the site because that isn't their business.

I personally don't deal well with the structure of the relationship and end up often not getting around to filing help requests when I probably should. I'm not sure why each of the other gods likewise appear to rarely file help requests. I'm quite sure many of them have reasons quite different from mine.

So I certainly won't discourage anybody from choosing pair.com for their hosting needs.

But, yes, the very best, quickest improvement to PerlMonks' performance would be changing hosting to a place that supports Linux (and allows for more client input into security-related configuration). That has almost happened several times already. I should be rattling chains trying to get momentum behind that again but haven't yet.

- tye