Slashdot is on my RSS feed, but I try not to wade into the article comments (or trust the article summaries, for that matter). Once in a while, my curiosity gets the best of me and I start reading comments. The end result is usually an increase in my blood-pressure and a decrease in my faith in the future of humanity. Whenever a technical topic comes up, I cringe. It’s amazing how much incorrect and crazy information gets modded as “insightful” or “informative.” Someone once complained to me that Slashdot is full of computer nerds who have very little knowledge in other “hard” sciences, and they get that information wrong all the time. I replied saying that they get the computer stuff wrong all the time too, but the majority of the audience simply does not have enough grounding to be able to accurately assess their own level of knowledge.

It’s not quite the “blind leading the blind,” but pretty close, and that makes the moderation a bit impotent. Certainly some knowledeable people read and post there, but the quality of the average comment is quite low and the moderation turns into “mob rule.” That’s not to say that all Internet venues will end up this way: some less popular sites have much higher quality forums (e.g. Real World Technologies). I think Ed Felten said it well in a post several years old titled “The Slashdot Effect”. He notes, “sadly, the treasures of Slashdot are often buried in a vast wasteland of speculation, misinformation, and irrelevant blathering.”

A Slashdot quote I noticed today:

“And people who sit in glass houses shouldn’t throw stones. Looking through [Vaughan] Pratt’s publication list, the first two papers I came across on a topic that I know a lot about should never have passed peer review.” [0]

Yes, this random schmo on Slashdot is criticizing the quality of Vaughan Pratt’s publications. Vaughan Pratt, who proved PRIMES is in NP, of the Knuth-Morris-Pratt string matching algorithm, fellow of the ACM, PhD student of Donald Knuth, etc. I guess Knuth didn’t teach Pratt enough rigor to satisfy this random Slashdot poster. I can’t put into words how hard I’m rolling my eyes at this comment. Of course it was modded “4, Insightful” (4 out of 5). Now, I’m not saying Vaughan Pratt is infallible or that his reputation puts him above criticism, but he has infinitely more credibility than some Slashdot poster who criticizes two unnamed papers in an unnamed area of expertise. Referring to Pratt’s publications as a “glass house” with respect to his credibility in the area of CS theory is just the kind of arrogant nonsense that I unfortunately expect from Slashdot.

BTW, for people like me who have recently read or are reading Beautiful Code, note that Chapter 9 — Top Down Operator Precedence also involves Pratt. Although he didn’t write that chapter of Beautiful Code, he did create the top down operator precedence parsing technique it describes.

LUG@GT, my school’s LUG, holds regular “InstallFests,” and for the past few InstallFests, I’ve provided a PXE boot install server with many Linux distros to streamline our installs. For our last event (in September), I also wanted to offer the option of various BSDs to install. It is not as straightforward to offer simultaneous PXE installs of the various BSDs with multiple versions and architectures using pxelinux. I wanted to do this all in a single pxelinux offering, so this post describes how I prepared pxelinux netboot installs for FreeBSD 6.2, OpenBSD 4.1 and NetBSD 3.1 and 4.0RC1 in both 32-bit and 64-bit flavors, all selectable from the same shared install menu (along with the Linux options).
Read more…

Traffic was extra terrible this weekend. I’m not going to claim that Atlanta has the worst drivers in the country (practically everyone claims their city of residence deserves that title), but Atlanta is often ranked among the worst traffic cities in the country.

However, the point of this post is not to complain about Atlanta traffic in general, because that would be unoriginal and not nearly nerdy enough. To me, it is always interesting to observe CS concepts at work in real life, like a pipelined drive-through with separate payment and food windows to provide better customer throughput (the Checkers around here even has a superscalar drive-through, with two independent paths on separate sides of the building). Anyway, in that vein and continuing on the theme of parallel programming, recently I observed classic example of deadlock in traffic. Atlanta drivers seem to block intersections as standard operating procedure, which resulted in the following deadlock:

Neither car is able to turn and make progress because the cars traveling in the opposite direction are blocking the intersection (which are themselves blocked behind the turning cars). This is a good reason why people should not block intersections (or driveways), because it’s not just a matter of courtesy. This deadlock was resolved by one of the cars – the one trying to turn into the driveway – giving up and turning around a bit further up the street (after being honked at by a line of cars sitting in a major intersection after the light changed). Anyway, I’m sure Atlantans will read my blog and adjust their behavior accordingly.

As an aside, I always liked Dijkstra’s colorful “deadly embrace” terminology for referring to a two-process deadlock.

Practically every technical talk I’ve seen over the past few years starts with the same exact 5-10 minute opening. And they all have that same exact graph of Moore’s law (or sequential execution speed over time), too. Frankly, I’m getting a bit sick of hearing this explained in detail over and over again. I get it. I haven’t been in a coma for the past 4 years. I think we all understand that the transistor density increases afforded to us by Moore’s law are no longer speeding up sequential execution speed as much as in the past. So chipmakers have moved to multiple cores, hardware threads, “synergistic processing units,” etc., thus making parallel computing research more mainstream again.

Could we please dispense with the unnecessary retelling of this story already? I think, by now, a technical audience will understand and accept the premise without that graph of Moore’s law.

Note: My intent is not to offend the numerous talented researchers spending their time on these important related problems; I’d just like to see less time spent rehashing why everyone is working on parallel computing research.

A while ago, I published a paper describing an abstract distributed programming model – and middleware providing the abstractions of said model to applications – for a class of continuous stream analysis programs. I named the system Stampede^RT, which seemed like a good name at the time and was neatly abstracted underneath a short LaTeX macro. Unfortunately, I may have fallen into a naming trap: the fact that the name contains a superscript is problematic for web search. Now it is unclear how to search for my system. In the abstract, the name got transliterated as Stampede^RT (since the caret provides superscripting in LaTeX math mode). In other places, it may appear as “Stampede RT,” “StampedeRT” or “Stampede-RT.” Although Google and other search engines are generally pretty good at still finding things with similar names, it just makes life more difficult (and this whole issue is easily avoidable).

Search-engine ranking and friendliness are important for software projects, research efforts, businesses, etc. I’d been thinking of some key traps for future reference:

1. Unusual/extended characters – in some cases, they may be completely appropriate (e.g. “Improving flow analyses via ΓCFA: Abstract garbage collection and counting”), but it is probably best to avoid naming a project after your favorite Sanskrit phrase.
2. Sub/superscripts or various font manipulations – Stampede^RT could have just been StampedeRT.
3. Aliasing – don’t give your project the same name as another, higher-profile project/business/entity – big enough projects can get away with this (e.g. The R Project for Statistical Computing is the first hit if you Google just the letter R).

I’m sure other people have probably blogged/posted/ranted about this too, but this is just what I came up with off the top of my head when I first realized my folly.

slashdotv(“First post!”);

Yes, a blog. Now, people who know me in real life will probably say that I’m one of the last people they’d expect to start a blog. I’ve frequently ranted about how blogs are stupid, for hipsters, where people blather on about mundane details of their lives, etc. I don’t like social networking sites or anything similar, and I value my privacy. I also don’t like to reveal personal details of my life, particularly on the Internet. But this isn’t going to be that kind of blog.

I do, however, value technical blogs as a source of current information on software development, computer hardware, CS research and other things of that nature. In addition, blog commenters often provide valuable pointers to related work and feedback on ideas. Therefore, I decided to create a simple blog where I could post about random technical stuff that is either relevant to my research or just personally interesting.  Occasionally I may just rant on a related topic, hence the name /dev/rant.