A Brief History of Slashdot Part 1, Chips & Dips

As part of our 10 year anniversary celebration, I've decided to post a story here telling the tale of the transition from Chips & Dips to Slashdot back in 1997. For those of you who are new here (cough), CnD was the precursor to Slashdot, hosted on my personal homepage on the CompSci cluster of Hope College. Along with a number of random Linux related webpages, themes for window managers, random bits of code I wrote, this page was read by a great number of folks, mostly from the IRC scene. Hit the link below to read the tale of its transformation into an Internet superstar (and maybe later I'll write the the sequel where I talk of the transformation into sellout mega corporate evil and eventually irrelevant blemish on the history of the net ;) And don't forget to check for a Slashdot 10 year anniversary party in your area.


In the summer of 1997 I was contacted by a stranger out of the blue with a kind of random offer. During the previous school year Nate Oostendorp (who now works with SourceForge, Inc. while working on his Masters) had coded a Space Invaders clone. He wrote a Java sprite library, and I wrote the game and illustrated the alien armada. This guy had an old DEC Alpha Multia 166, and a client that wanted to remake the game with popcorn instead of aliens. So I drew the popcorn up, replaced the gifs, and he mailed me my first non x86 box since the 286 I got in middle school. (Later Sun sent me legal threats forcing me to take the game offline since it was called Java Invaders, and clearly this was an evil crime against the universe. My hatred for Java has never died since that moment.)

I immediately installed Red Hat on it. I was working at an ad agency called The Image Group at the time as a webmaster. I coded whatever needed doing and handled various admin tasks to keep their clients happy. At the time they needed full control over email addresses on the domains they built. Since they shared their mailserver with their ISP, there were frequent name collisions -- if the client wanted bob@theirdomain.com but there already was a bob on the system, they couldn't do it. They agreed to let me move my little Alpha onto their network to host their email... and I could use it to fart around with on my personal hobbies.

I named the box Ariel. It sat under my desk. I learned enough Perl to write a stupid simple CMS to replace the functionality of Chips & Dips, which up until that point was just a text file. Dave DeMaagd wrote a simple comment system. Since we both had a long history with BBSes, it seemed obvious to us that there needed to be a discussion system. There were no user accounts -- you entered whatever name you wanted each time you posted. If you left it blank, it auto-filled the space with the name 'Anonymous Coward', a title that stuck and spread throughout the net.

The original system was written in Perl because I wanted to learn more Perl. All the data storage was flat text files. (We lost most of the original stories during a data import a year or so later) The files were named like 0000001.shtml and so forth and were all rendered at time of page request. Best of all, since the system was written as a CGI, the whole script needed to be compiled every time there was a page request. It was months before I ported the whole thing to use MySQL and mod_Perl.

I registered the domain name Slashdot.org as a joke. It was 'org' because I didn't want a .com -- those were so common. I always thought org would be cooler, and besides, I had no commercial plans in mind. (Years later this bit me on the ass since someone else registered the .com. Doh!) The URL was meant to be unpronounceable by anyone -- a joke ultimately that has backfired on me countless times when I'm called and asked what the URL is to the damn thing. Jeff 'Hemos' Bates (now a VP of something or other with SourceForge, Inc.) was in the living room when I was registering the domain name. We all wanted email addresses with a unique domain name that wasn't attached to our school, so he chipped in on the registration fee.

When it came time to design the website's look, I took elements from a theme we had designed at The Image Group -- Paul Hart and I spent hours on it -- that was supposed to be the new website for the company, but it was passed on for another look. I still liked it, so I redesigned it more to my personal aesthetics (choosing #006666 as the dominant green replacing an earth tone green) and putting drop shadows all over everything (a habit I still haven't broken, and for which I am still mocked). Within days, most of the design elements you see on Slashdot were in place... the curves, the greens, the polls, the vertical list of stories so common in 2007, and, of course, discussions on each story.

And Slashdot was born. At first it had just a few thousand daily readers migrating over from Chips & Dips, but in a matter of weeks it had grown so fast that we started really having fun with it. One night we put up a poll asking how many shots Kurt 'The Pope' DeMaagd should drink. (Kurt later became our defacto HR man when we formed Blockstackers... today he is a professor at MSU.) But that night, Slashdot readers told him to take a dozen shots of alcohol -- he failed, but he tried.

I remember around the same time just watching 'tail -f' on the access_log. My world was rocked over and over again as I watched the domain names... mit.com! ibm.com! redhat.com! Hell, even microsoft.com kept scrolling through the log. I knew we had something... people from around the world, from the highest institutions in the land, from the biggest companies in the tech sector and to the most influential in the Linux world were all reading Slashdot. In fact, they were posting comments... as were a lot of people. It became commonplace to see hundreds of comments on stories, and the so-called 'Slashdot Effect' slowly grew into our lexicon as site after site buckled under our links.

In those days the content was a lot more personal then it is today. Stories would frequently refer to alcohol-related activities. I'd constantly mention that I had to leave to go to class so there wouldn't be more stories posted for a few hours. And when a professor in my pottery class assigned homework of to mass produce and sell some pottery as a lesson in being a commercial artist, I posted it, and ended up getting over 100 requests to buy my shitty mugs (all glazed teal ;) In the end I never did sell them -- I fulfilled the assignment locally. I think I still have one of those mugs left but I'm not sure- over the years my mediocre ceramics have been filtered out of a home increasingly tastefully decorated by my wife.

I continued to go to class and work my part time job. Ariel soon had loads so great that the machine was unusable during the day. And occasionally I would accidentally kick it and knock out a cable, bringing the machine offline. Soon after it saturated the office T1, I started realizing that there was no way I was going to be able to do this as "Just" a hobby. Essentially, every second of my life was consumed without time for a break. I'd go to class -- and often just work on Slashdot in the back row. (This was the first year we had computers at our desks in the CS dept at Hope.) My classwork suffered. On the upside, I became far more proficient at webwork, which really helped the part time job. I'd go home and code, post stories, reply to email until 2-3 a.m. and repeat it the next day. It was going to eventually be a full time job, requiring revenue and infrastructure that didn't exist back then. But I guess that's another story.

Parallel programming environments: less is more

The single most important paper for programming language designers to read came out in 2000. It wasn’t written by a computer scientist, mathematician, or physical scientist. It was written by a couple professors studying social psychology:

“When Choice is Demotivating: Can One Desire too Much of a Good Thing?” Iyengar, S. S., & Lepper, M. Journal of Personality and Social Psychology, 79, 995-1006. (2000).

This paper explored the phenomena of “choice overload.” Here is what they did.

They created two displays of gourmet jams. One display had 24 jars. The other had 6. Each display invited people to try the jams and offered them a discount coupon to buy the jam. They alternated these displays in a grocery store and tracked how many people passed the displays, how many people stopped and sampled the jams, and how many subsequently used the offered coupon to buy the jam.

The results were surprising.

• 24 jar display: 60% of the people passing the display sampled the jam, 3% purchased jam.
• 6 jar display: 40% of the people passing the display sampled the jam, 30% purchased jam.

The larger display was better at getting people’s attention. But the number of choices overwhelmed them and they just walked away with out deciding to purchase a jam. In other words, if the goal is to attract consumers, less is more. Too much choice is demotivating. Admittedly, selecting a gourmet jam is insignificant. Maybe for more important issues, “choice overload” is not relevant? The authors of this paper, however, went on to consider more important choices such as 401K plans, and once again, a clear choice overload effect was found. Choice overload is real. When people are faced with too many choices, the natural tendency is to “not make a choice” and just walk away (probably in frustration).

Why is this relevant to parallel programming?

Think about it. We (that is, computer companies) want to sell hardware. To do that, we need software. We display our platforms and hope software developers will spend their valuable development dollars porting to our platform.

So what is the situation today with multi-core processors? A software vendor walks up to “our display.” We show them our nice hardware with its many cores and we tell them they will need to convert their software so that it will scale. And then we show them the parallel programming environments they can work with: MPI, OpenMP, Ct, HPF, TBB, Erlang, Shmemm, Portals, ZPL, BSP, CHARM++, Cilk, Co-array Fortran, PVM, Pthreads, windows threads, Tstreams, GA, Java, UPC, Titanium, Parlog, NESL,Split-C … and the list goes on and on. If we aren’t careful, the result could very well be a “choice overload” experience with softwre vendors running away in frustration.

Think about the impression this glut of choices creates. If we “experts” can’t agree on how to write a parallel program, what makes us believe parallel programming is ready for the masses? In our quest to find that perfect language to make parallel programming easy, we actually harm our agenda and scare away the software developers we need.

We need to spend less time creating new languages and more time making the languages we have work. This is why anytime I hear someone talk about their great new language, I pretty much ignore them. Tell me how to make OpenMP work. Tell me how to fix MPI so it runs with equal efficiency on shared memory and distributed memory systems. Help me figure out how to get pthreads and OpenMP components to work together. Help me understand solution frameworks so high level programmers can create the software they need without becoming parallel algorithm experts. But don’t waste my time with new languages. With hundreds of languages and API’s out there, is anyone really dumb enough to think “yet another one” will fix our parallel programming problems?