Slashdot Mirror
Yahoo! Orders Wikipedia Hardware
Edit This Page writes "Jimmy Wales announced today that Yahoo! has ordered 23 HP servers for the Wikimedia Foundation. The three database servers are model DL 385, and will come with dual Athlons, 8GB of RAM, and 6x 146GB 15K RPM drives each. They will also provide rackspace and bandwidth. The announcement comes four months after Google's announcement of support, and two months after Yahoo's own. Google has not yet made their intentions clear. You can read more about the specifications of what will soon be a 100+ server cluster at the Wikimedia Servers wiki article."
Does wikipedia seriously need all that? I thought the data they were serving up was mostly just text and wasn't really a huge problem. As in, weren't their current servers enough? Or am I missing something?
Does anyone know why they are being set up in South Korea?
The server hardware spec link said the "athlons" in fact are opterons. *sigh*
I have a really elegant proof for Fermat's last theorem. If this sig was only a bit longer...
Since I can't think of anything really insightful to say, I'll just say thanks.
Thanks to Yahoo, for supporting the Wikimedia Foundation, and thanks to the Wikimedia folks and all of their contributors for their great contributions to what I hope will become (and is already on its way) one of the world's best disseminators of human knowledge. It's meant to be free, at least as in speech, but they're pulling it off as in beer, too.
Much kudos to them - One day when I'm not a poor college student, I'll help out. They've certianly made themselves worthy.
Unicode is assumed for 1.5, so all wikis will be converted as part of the transition process, including the English Wikipedia.
James F.
Seems to be a war to be the best "opensource" helper. See Google wants to help wikipedia, Yahoo helps wikipedia, Google makes Google summer code ...
;-) ?
What's next
Bonjour !
It's nice they're all donating new hardware and such, but really...
who's gonna be paying those killer power bills?!?!
Because the technical team at Wikipedia includes the developers and we know that there are sure to be problems as it is introduced to full service. Anything from outright bugs to database queries with unacceptable load properties. It'll probably be released for a general audience in four to eight weeks, once it's been very thoroughly tested at its biggest user site.
I'm wondering about setting up a network of boxes running the Coral software. Those have built in fault tolerance so it wouldn't take lots of admin work and would allow accepting many small bandwidth offers, in countries with comparatively low traffic. Makes most content even closer to the end users and spreads the bandwidth load around. Nothing actually happening on this front yet, though.
A very large number of places witih full database servers and page builders, like this Yahoo announcement, would have too much admin overhead - 3-6 of those places is about right.
P2P is a security problem. People can always modify P2P programs to add nasty content and Wikipedia has already seen people trying to upload that and has filters in place to catch and block some things.
This is a classic case of considering the hardware to be the problem rather than the software. The software has serious issues when it comes to performance and the developers are very slow to address it. Hell, Tim Starling, a lead developer, even stated that one of the design goals of the MediaWiki software was to spend as little time as possible developing it. I kid you not, that's paraphrasing something (with NO exaggeration) that was said in a presentation document which I can find if anyone doesn't believe me.
I've heard some whining from some of the developers because they didn't have a ready made solution for certain things, meaning they would have to put actual *effort* into making their own. The idea of writing glue code (to C code) to make up for a feature lacking in existing php libraries was considered an abhorrent thing.
Their best response to me pointing out flaws in their "development philosophy" was to them retort with the oh-so-clever "well why don't you write something better yourself?" Of course, that phrase is just a code word for "we know it sucks and we're just not willing to put all the extra effort into rewriting major portions of it." Really, it's sad when you have to define your software in terms of someone else (your opponent specifically) not writing something better.
This isn't just unfounded complaints either. The developers have often complained that the existing implementation (and especially the choice to write the original code in PHP) needs to be rid of. They've said it has "everything and the kitchen sink" and that it degrades performance, but aren't trying that hard to get rid of it. They know this as a matter of fact through testing--Mediawiki has a massive overhead in setup time compared to other wiki software.
Not just that, but the Wikipedia admins are all volunteers and aren't exactly the cream of the crop. They took them as volunteers since they were the best ones to devote that much time to it and unfortunately that means they're mediocre and they REALLY are not experienced for such a high traffic website.
If they actually had a paid full time admin who had considerable background in sites like this, you'd suddenly see a massive drop in down time and other problems.