Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

gnat (29)

  (email not shown publicly)

Journal of gnat (29)

Sunday April 15, 2001
09:51 PM

More TPC5 Stuff: POE and Hardware

[ #24 ]
Today I'm going to babble about two Perl Conference tutorials: POE and PC Hardware.


You must know about POE by now. It's a way of doing cooperative threading in Perl, and I always describe it as an operating system kernel in Perl. Your "processes" are objects, and the kernel takes care of giving them CPU time. It's cooperative multitasking, so your process is broken into chunks (object methods), and as a chunk finishes it tells the kernel which chunk of that object to do next. It makes network service programs and other event-based systems very easy to write, and it won the "Best New Module" award at an earlier TPC.

This year, by dint of much arm-twisting and cajoling, we have a tutorial from the man himself, Rocco Caputo (the evil genius behind POE). If you've ever asked a question on #perl and been told "use POE!" then now's your chance to learn more. If you've ever wanted to see how to write a POP3 or NNTP or ... server in Perl, look no further.

PC Hardware

Most people don't know, but I worked as a system administrator for three or four years when I first moved to the US. For immigrants it's like working in a NYC clothing factory, only there's less risk of fire killing you (we did have flood problems with water leaking through the ceiling tiles, but that's another story). And as a systems administrator I learned to fear hardware.

I have devoted years of my life to the study and pleasure of software. I enjoy debugging almost as much as I enjoy the ego boost of writing a piece of bug-free code. I've patched fsck. I love Unix and I love Perl and if I had to live on a desert island with only three things, those would be two of the three. (In case my wife reads this, I won't say that the third thing would be a T1. Heh)

So I know software. I can deal with software. When it craps out, I know what to hit with a clue hammer to make it work again.

Hardware, on the other hand, is from another planet. I have the hang of cables, and why you can't plug a monitor into the mouse port. What goes on inside the box is juju to me. Someone says "DIMM" to me, I think "George Bush". Someone says "firewire" I think "urinary tract infection". For two years I thought "USB" stood for "Users Suck Balls". It actually may, come to think of it.

I figure I'm not alone--that many software folks have to work with hardware, but don't really get all the buzzwords and options. That's why I asked the Top Dog sysadmin from the company I worked for to come and explain his magic words to us. Andy Neely's tutorial "Purchasing Commodity Hardware for your Open Source Project" is about understanding PC hardware: the implications to your choice of RAM, which types of SCSI are scuzzy, what life will be like with hot-swappable redundant power supplies (hint: "better"). I figure most people know enough hardware to make good choices, balancing performance, cost, and reliability. But after this class you'll know enough about the options to make the best choice.

So hopefully after Andy's tutorial my long run of poor hardware purchasing decisions will be at an end. (The most recent: "woo! an 80G hard drive! boo! the bios in my basement PC won't recognize more than 30G of it!"). At least, that's what my wife hopes (sorry about the great idea to turn the basement computer into an MP3 player and connect it to the stereo, only to discover that mpg123 belts out large amounts of STATIC on the files we made using RealJukebox, hon!).

And now you know the real truth: the reason I do TPC content planning is so I can put together the tutorials I really want to see :-).