We’re working behind-the-scenes to seriously ramp up our server fleet. When David started PBwiki the core servers were a bunch of 2001-vintage VA Linux boxes from Craigslist — Essentially “San Carlos: 400 pounds of 2U servers $10 OBO, you pick them up tonight”. Since those heady days of off-brand ramen and Mountain Dew we’ve accumulated a few generations of machines, with a handful of 0.5U Rackable units still providing low-load services. Today the bulk of PBwiki’s heavy lifting is done by a few white label 1U P4-3Ghz machines with twin SATA drives. This piecemeal approach has produced two interesting outcomes: a very capital-efficient company and a very diverse server stack. We’ve got hardware from several generations of chipsets — bogomips ratings span 1×1300 through 4×6100 and RAM from 512Mb through 4Gb. We’ve got IDE, SCSI, SCSI RAID, and SATA, plus 8 different ethernet controller chipsets.
Normally this kind of diversity isn’t such a big deal — just install whatever OS and let the drivers fight for survival on every boot. We add to the challenge with our security policy, which has us using a monolithic kernel, patched with grsecurity and identical across all the production machines. We use Debian which makes this a bit easier but it’s still a lot of things to keep straight.
We’ve recently embarked on a project to build One Heck Of A Server Cluster with more or less modern hardware bought new. PBwiki is the baby sister and she’s about to get her own prom dress. The funny part of all of this is of course the orders of magnitude we’re talking about versus the first dot-com boom circa 1999 — We’ll spend less for ten of these new machines than a single Sun E420, and each one is easily five or six times faster than the one E420.
So we ordered up a sample machine which had chips we were familiar with and specs and a price that made sense. The machine was a dual core P4 3Ghz with a single 500Gb SATA drive in your average white label 0.5U case. One great thing about modern hardware is the monitoring you get — temperatures, voltages, and fan speeds are all measurable if you’ve got the right driver code compiled into your kernel (see above). After some yelling at ssh terminals I got lm-sensors working on this new machine and we got some numbers out. As an aside, we’ve set up syslog so every machine in our system sends all of its health, security, and operational log events into a pair of machines with big hard drives and we have an ongoing record of everything (logins, temperature changes, hard drive health measurements, etc etc) in one place. Very handy.
Since it’s a dual-core machine running one thread of “while(1) {}” will occupy one CPU, and two threads of the same will run both CPUs at full throttle.
| Intel Dual Pentium 4 @ 3Ghz | |
| Ambient air temp | 65F |
| Idle CPU temp | 131F |
| One CPU running | 176F |
| Two CPUs running | 186F |
So — those numbers are terrifying. The machine at idle raised the ambient temp by almost 70F, and running full steam the delta was a full 120F. We looked around for a T-max-ever spec for these parts and the general consensus was that our numbers were a bit high but ‘yep those chips run hot, don’t they’. Unbelievable.
So we decided to give the newer Core2Duo chips a try. They’re more expensive and require a slightly more modern motherboard and so on which means added cost there as well. They’re clocked a bit slower in general but between deeper caches and some other differences the real performance is actually equivalent or better. This new motherboard required a bit more yelling at the ssh terminal to get lm-sensors working (spot the trend?) All in all the extra few hundred bucks will be worth it — check out the new test results:
| Intel Core2Duo @ 2.4Ghz | |
| Ambient air temp | 66F |
| Idle CPU temp | 73F |
| One CPU running | 87F |
| Two CPUs running | 98F |
Yeah - with both cores of the Core2Duo running full-throttle the chip surface is 90F cooler than the equivalent Pentium 4. Sold.
The heat output is really important for us because the Bay Area is out of power. We’ve got enough fiber optic cable running up and down the peninsula that you can trip over it if you’re not careful, but the limiting factor for adding machines to our server cages will be how much power they consume and how much heat they put out — since any heat burned off by the computers needs to be cooled by big expensive air conditioners eating up more power than your server burned through to keep the whole thing from melting down. It’s really the difference between being able to rack 5 of the Pentium 4 boxes or 10 of the Core2Duo ones.
In hindsight this makes a good deal of sense given the data I’ve seen from the Mac crowd (myself included) — the previous generation of MacBook Pro machines were almost painfully hot in general use. I’ve got a current-generation unit (with basically the same chip as in the second test box) and it’s never more than warm, even running several virtual machines at once and doing all sorts of divx decoding in the background. Very impressive work from Intel getting these chips to run more efficiently.
-Nathan
Sometimes I get a funny reaction when I talk about PBwiki to people:
“But…what about access controls? Who controls the content?”
Our response is always the same: “The problem is not access controls! The real problem is figuring out how to get people to contribute to a community.”
Whenever I start a PBwiki, my biggest challenge is simple: getting people to contribute valuable content. Only once, after I had lots of people adding to a rich community, did I start to worry about access controls.
To be fair, we know access controls are important. Our business users care because they want to make sure their data is safe and secure. Our educational users care because they want to protect their students and monitor what goes on. For them, we’ve built features like the ability to easily track revisions and to revert back to an older version of the page. They can also get notified of every change by RSS or email.
But I see sharing and openness as the core benefit of a PBwiki. The upside, in other words, is greater than the downside, and when you get lots of great people to contribute to your wiki, serendipitous things can happen that are almost always good. To that end, we’ve made it easier to share your wiki (now, after your first successful edit, you’ll see a little text box that asks you if you’d like to share your wiki with others). Coming up, we’ll be making it easier to share with your existing contacts by importing friends from your address book (and other places), and we’ll let you see exactly who’s made what change in a more intuitive way.
Stay tuned. And if you have any stories or feedback about sharing your PBwiki, we’d love to hear it.
-Ramit from the PBwiki Team
We’d love to hear what templates you want to see on PBwiki (e.g., plan a trip, run a group project, etc).
Also, if you’ve built a template and think it might be useful for others, we’d love to see it. We’ll keep an eye out and add the best template submissions PBwiki-wide for thousands of others to use.
Add / request a template at http://templates.pbwiki.com
Currently, when creating a new wiki on PBwiki, one must choose between ‘Classic Editor’ and the ‘experimental WYSIWYG editor’. Depending on your answer, this enables (or not) our fancy new editor for that wiki. We’ve been receiving a lot of praise for the new editor (thanks guys!) as well as a few questions regarding continued support for our old interface that we would like to address.
As it stands now, there is no way to change editing style for a particular wiki. Once you create a WYSIWYG wiki, it can’t be edited in the classic “WikiStyleâ€? interface, and vice-versa.
We’re going to change that.
First and foremost, in January we will be giving all wiki administrators the ability to upgrade their wiki to WYSIWYG mode. There will be no charge for this upgrade!
Additionally, for those of you who just can’t get enough WikiStyle, you will also have the option of editing WYSIWYG wikis with our classic, WikiStyle editor. We can’t promise that all new WYSIWYG-specific features (like plugins) will be available, but you should still be able to use the same wiki markup that you have come to know and love.
As an aside, it is worth mentioning how we came around to this decision. The decision to maintain support for WikiStyle editing was greatly influenced by feedback from our users. We originally thought WYSIWYG would be the best option for everyone. But we sought feedback, mulled it over at lunch, and came to the conclusion that 1) we underestimated how much people like our classic interface and 2) Red Lobster’s cheese rolls are amazing. Listening to feedback is a big part of PBwiki, and drives a lot of the discussions here.
Stay tuned for more progress around WYSIWYG editing, and other new PBwiki features!

We’re so excited to welcome Brian Klug to the PBwiki team! He sold his house and flew to the Bay Area all the way from Virginia. He’ll be working on the WYSIWYG interface immediately, and then some other stuff we have up our sleeve. A little bit about Brian:
Brian co-founded MindSay with Adam Ostrow in 2003. Bringing over 12 years of software development and industry experience, he enabled the birth of a competitive blogging product in a tightly growing market. Before MindSay, he was president of his own web hosting company. At MindSay, he used his extensive product, technical and operational experience to architect, design and implement MindSay’s 130,000+ member social networking and blogging site.
Welcome, Brian!
There’s been a lot of discussion about the Peanut Butter Manifesto, in which Yahoo SVP notes that Yahoo is “spread too thin.” He also notes that he hates peanut butter.
Outrageous! Here’s our official response: In defense of peanut butter.
We spent the last week talking to educators from around the country who told us what they wanted from PBwiki. Each call took about 30 minutes and we tried to really understand what’s working, and what’s not. Here’s some of the feedback we got.
We also asked general (non-PBwiki) questions about the challenges you face as educators. One of the most common responses was “keeping my students engaged.”
We’ve taken your feedback and made some new plans for PBwiki. Stay tuned for PBwiki to be even better for your classroom. And be sure to check out our new PBwiki editor — it’s coming soon.
If you have other suggestions for what you want to see in your educational wiki, please email us!
The wonderful Rhys Wynne has provided us a Welsh translation of our WikiStyle help page, adding to the long list of volunteer translations, including Chinese, Danish, Dutch, Esperanto, Filipino (Tagalog), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Lithuanian, Norwegian, Polish, Portuguese, Russian, Serbian, Spanish, Swedish, Turkish, and Vietnamese. Thanks, everyone, for chipping in to help us help others! And if you’d like to provide a new translation not listed here, please email us at translate@pbwiki.com. Thanks!
So we’ve been talking to a lot of users who would like more control over who gets access to their wikis, and how. Some people really like the fact that we’re hosted and secure but want to use a behind-the-firewall LDAP server to authenticate users. Others have custom single-signon solutions (like Stanford’s WebAuth). Others yet want to support completely separate authentication measures, like being able to use Facebook, AIM, or Yahoo! to sign on. We’d like to support all of you, but only have so much time in the day. So we’ve gone and made something totally new, that nobody else in the wiki space can give you - an Authentication API.
What this will let you do is code your own web service that will authenticate a user against PBwiki however you want. We’re still sketching out the technical details but we’d love if you could take a peek and let me know what you think. ![]()