I'm already settled here in Europe, but I take it the dedicated box you're referring to would be somewhere in the US/Canada? Depending on the price (and the things it offers) I might be interested. Do you already have something in mind?

Why not go with a VPS at Slicehost or Linode?

Do you need a lot of system resources?

That'll be my final recourse.

I'd prefer to have a dedicated box where I can run multiple virtual hosts myself.

Not at the moment, but I'd also like to run asterisk and a few other things. And I've noticed that my VMs with 256MB or less tend not to perform so well with apache and mysql running. They do ok, but if a site ever gets even remotely busy, you're asking for trouble.

I had to tweak the crap out of the apache and mysql configs on http://svn.tomasu.org to get it to run decently with 256MB ram, and still have some room for page/file cache (so it isn't constantly hitting the disks for files).

append:

Thats the fun of running virtual machines. Anyone in on it could have their own test VMs to play with. No-one should be logging into the host instance on a regular basis.

This isn't particularly about the wiki, but I probably would move it to the new hosting if I found a good enough place.

append: That is to say I'm looking for people to share the on going cost of a decent server, rather than one off donations (not that they would hurt anything though).

I'd be down if we could somehow guarantee serious uptime. During the lunch and dinner rushes I really can't go down.

The chances of that (going down at a specific time) are usually slim, though it depends on the load your customers would put on the server. Really though even the best data centers can't do any better than "5 nines" which is 5.25600 minutes of downtime a year, though that can be quite expensive if they can actually provide such uptime (it means multi redundant connections to the internet, multi redundant UPSs and desil generators, multi redundant cooling systems, etc), and to make sure you could make use of that uptime would mean you'd need to have multiple servers hosted there, and possibly in other datacenters so you could instantly switch to another server should yours go down.

So If you're willing to pay for it I can setup something that gets you "5 nines" or more. But its not going to be cheap. (multiple servers in multiple datacenters, each with expensive contracts )

Cool. So thats 2 or 3 people that might be interested. Should anyone want to talk about this in real-time, join #tomasu@irc.freenode.net

I tweaked it all down to almost minimum counts. And I could pick a worse httpd. I'm running SVN via WEBDAV, Web::SVN, and trac. I don't think nginx or lighttpd would even handle those properly.

And now I have two separate httpd's running? Whats the point? Just run them all under apache. As for why they may depend on apache, One is perl, the other is PHP. So the httpd would have to handle both at the same time as well as not bing horribly slow at it (and I REALLY don't want to setup fcgi).

We were. Though his priorities were not anywhere near what they needed to be if he was actually interested in doing it.

I've got a bunch of the software written for it, may eventually start it up. We'll see.

Again, fsck fcgi. I already have a decent setup and I only need to have a single httpd running.

svn:~# free -m
             total       used       free     shared    buffers     cached
Mem:           246        209         37          0         31        120
-/+ buffers/cache:         57        189
Swap:          447          0        446

I also happen to care about ease of maintenance.

Indeed. Money is a big issue. I currently don't have a lot. A base setup would probably cost $10k in hardware alone. (if I wanted to do it right)

If you have to stick with Apache HTTP server, then at least go with FastCGI. Having 100s of mod_php processes is a memory killer, especially considering a single instance of PHP is enough to handle a lot of requests.

I recently switched a client's (old) server (256M RAM) from Apache 1.3 to lighttpd due to security audits, and page views were easily 3x faster.