I once wrote a (very complicated) spreadsheet in Excel to calculate bonuses for drug peddlers at a pharmaceutical company. The problem screamed for a database, but the algorithm for calculating the bonuses was so complicated that it as a royal pain in the ass when I tried it. So I ended up with a fugly spreadsheet that still works 5 years on.

The ridiculous thing was that it could've all been well approximated with an exponential function, but that idea was a big no-no. The bonus algorithm is sacred.

In (mathematics) open-book exams I've taken, the books were essential. The highest scored solutions consisted of recognizing the problem, butchering equations for a few lines, and then pointing to the correct page in the correct book. The people who got highest grades were done in 15 minutes, though you were allowed to sit for at least 3 hours.

But, of course, to do that, you had to actually understand what it was all about, and you certainly couldn't learn that in 3 hours with all the books in the world.

That depends on where you live.

What you are seeing now is cached static copies of articles that are normally generated on the fly (turns out rendering of wikicode is not a bottleneck in the whole thing plus rendering of pages needs to be at least partly dynamic for several reasons).

The two web servers serve pages from the database server, which is where all data is, so if that croaks, the whole thing croaks.

Running a huge mult-language encyclopaedia with complete revision history for all pages, proper interlinking and redirecting of pages, discussion about articles, daily discussion, etc. is not a small thing.

The site is just way too big (traffic on par with slashdot.org or sun.com, database size 35 MB) to be run on creaky machines. It needs proper hardware.