November 2004 Archives

Wowsers. Okay, I started working for the Department of Computing and Information Science in October of 2003. At that time, I started as a student employee and had my office in Nichols 118, where Diesel currently lives. At that time, I shared my office with four machines in my office, Kirin, Saru, Kuma, and Printserv. Kirin is the department's backup server. Saru was my workstation and one time application depot and firewall for the Linux lab—when Nichols 128 had need for such things. Kuma was the Unix print server. And Printserv is the Windows print server. Kate Adams became my office mate and a fifth machine moved in, Scorpion, which was her workstation.

After working for the department about two months, Tim Bower, the bossman, got offered a position as Assistant Professor in Salina, which he subsequently took. Seeing an opening for a real job I believed I was qualified for, I applied. This was an internal search for temporary position. They offered me the job and I took it. I then moved into Tim's old office, Nichols 116, and took Saru with me.

In Nichols 116, I no longer had a human office mate, but I shared the office with Achird, Zaurak, Oracle, Remote, and Saru. Achird was Tim's old workstation, which was used frequently by a professor via SSH. Zaurak was the recently (at that point) retired web server, but was removed very shortly thereafter. Oracle is the (since rebuilt) Oracle RDBMS server. Remote is the Microsoft Windows RDP server that acted as Tim's other workstation.

I don't hold to using servers as workstations, as was the wont of the previous administration, so I rearranged the office so that Remote was no longer a workstation. Oracle was in bad shape, so I replaced Oracle with Oracle2, which was a worse machine, but worked better than Oracle. Oracle was briefly put on sabbatical, but both remained in my office. Achird stayed in my office for a few months before I grew tired of it's presence and banished it to the Tower of Not So Much Power in our server room (which is growing to Biblical proportions). Saru, I'm sorry to say, needed a face lift and became Aldebaran, the prototype Gentoo Linux workstation in our department.

Back in my old abode, Cole moved in. He, briefly, shared space with Kate until the summer when we wished her a fond farewell as she moved on to bigger and better things. (Or perhaps more mundane, but better paying and closer to her real interests, according to her description...) Anyway, during this time, another machine was added to his brood, Seer. Seer is the Nagios and MRTG machine used to monitor our network and computer systems.

In April, the search for the permanent holder of the office of Systems Coordinator was begun. The search ended with two interviews, one with myself and one with another. An epic contest ensued and the two of us battled for days on end. In the end, my foe was vanquished and I smote his ruin upon the quad. Er...maybe the staff just decided that even though I might have been a little less qualified it was better not to change administrations again. Whatever happened, I was given the honor of staying with the department.

Since then, I rebuilt both Oracle and Oracle2 to make them a super-combo. That is, the computer formerly known as Oracle is now Catera. The computer formerly known as Oracle2 is now Cougar. These two machines together form the ultimate duo: Oracle Server and Oracle Client. Cougar keeps Catera happily hidden so we no longer have to compromise the quality of our Oracle server in order to keep from compromising security—which had formerly been the bane of our Oracle servers.

In addition to this, I created the initial framework (which Cole has since rewritten) which makes our fleet of Gentoo lab computers possible. In order to prove the concept, Saru, aka Aldebaran, had it's identity altered again to become, DUM-dum-DUM-dum-DUMMMMM, Silverado. I was tired of star names, really tired, really, really, really, really, really....really tired. Therefore, I decreed that henceforth, all CIS managed Linux servers and workstations shall have American automobile names.

Recently, Cole also built another machine, Montecarlo, to replace Kuma, who's age was really beginning to show. Ultra 5's are well beyond their prime. Kuma is an Ultra 5 and due for banishment with Achird, Zaurak, and dozens (literally!) of others.

Anyway, all of this to say, "Holy crap! We have a lot of servers in our offices!" I mentioned before that I don't hold to using servers as workstations. Well, I don't hold to keeping servers in offices at all. They belong in the server laboratory with all of their parallelepiped brethren. I have had the goal, since my start in October last year to get all these freaking servers out of our offices. Today, I have finally, mostly succeeded.

There was a mass migration of servers from offices into the server room. This migration was made possible due to the retirement of several unnecessary servers during the last week. Sarin, Hadar, Izar, and Clinton were all assassinated in the last week freeing up spots to move machines out of offices. Cougar, Catera, Kirin, Remote, Montecarlo, and Seer were all moved into our server laboratory today and yesterday. Awesome!

The mass migration is incomplete because Printserv has not been moved. Unfortunately, it is tethered to the wall in such a way as to make it's migration infeasible. However, it is also in a sorry state, very sorry. We worry for it's health and are afraid it may succumb to something akin to Alzheimer's disease soon. As printing is considered fairly important, we are going to replace Printserv with a brand spankin' new 1U rackmount when it arrives in another couple weeks. When that happens, Printserv will be unceremoniously nixed and tossed with extreme prejudice onto the Tower.

Once that is done, there will be no more servers in the office of any of the systems staff. As of this time, no more servers will be built within the confines of our offices. I will not encourage the breaking of the policy that servers belong in the server room. Humans and their own faithful workstations only belong in offices. Of course, this policy should not be difficult to enforce when I have another policy that states all new servers must be rackmount units. We don't have any racks in our offices, so a rackmount is really not very appropriate in our offices.

For one of my longest blogs ever, I wanted to say, "W00T! Victory is mine!" I am going to spend the evening doing the happy dance of joy rather than sleeping tonight...hmm...maybe I'll just dream about doing the happy dance instead. Cheers.

Preparing for CIS 450 is, in some ways, very easy. It really doesn't take a lot of time (when I have the time to spare). I spent the last hour to hour-and-a-half to make all the preparations I needed for todays class.

On the other hand, it does require a bit of concentration. Right now, for those not in the class, we're covering how pointer arithmetic actually works out in assembly. I actually find this is pretty rewarding work as it comes together. I decided to cover pointer arithmetic very early in the semester—I started on the fourth class session, third session of C++. Pointers are, in my opinion, the single most important practical computer science any student can learn. They also account for one of the most difficult concepts to grasp properly.

I remember when I was an undergrad taking CIS 540, I had to explain the purpose of C++ delete and why my fellow students' code didn't function because they had their types screwed up, asterisks misplaced, etc. A lot of students seemed to use the, "Um, that didn't work, I wonder what happens if I stick an asterisk here" method of programming. They'd work at it until it compiled and then then, "Aha! I got it." And then they'd run their code and it would promptly result in a Protection Fault.

This is why I think C or C++ needs to be an integral part of the curriculum. Computer scientists shouldn't need managed code environments like the Sun JVM or the Microsoft CLR in order to save them from themselves. A computer scientist should be able to use these to catch their typos and mistakes, not to save their souls 'cause they don't really know how to code. That is, an adequately trained computer scientist should know where to put the asterisk in her code because she knows exactly what it does and why it works that way. That's a computer scientist. Anything less is a mere programmer. (There's nothing wrong with programmers, by the way, we sometimes need those grunts to that work too. Yet, the Computer Science program should be turning out Computer Scientists, not just programmers; programming is only one aspect of Computer Science.)

Anyway, back to my real point...it takes quite a bit of concentration to get these things right, especially because the GNU C Compiler is sneaky. It does lots of funky tricks like using the lea instruction to add integers, sal for mulitplication and sar for division, etc. To compare GCC to the Fire Swamp, "It certainly keeps you on your toes."

Working with a pencil and paper to figure these things out feels a lot more like work than hacking away at my computer does. I'm not sure why this is, but it does. All that meandering, just to say, I actually feel like I've accomplished something preparing for class. Most of the rest of my job working with the systems leaves me with a sort of nebulous, "Did I really do anything today?" feeling. Cheers.

You force your computer to have unprotected sex with other computers?! I can't believe you. That's truly awful.

Okay, a bit of hyperbole, but it's warranted. There is no reason for viruses to be as rampant as they are today. Just today, a professor in the Computer Science department sent me a Microsoft Word document. Have you lost your mind? I wouldn't open a Word document sent by the President himself, even if the NSA had certified that it was clean. That'd be like me forcing my computer to have sex with every computer that the President's computer has ever taken a Word document from. No way. This just goes to show how few people, even of those that should be in know, don't know how disgustingly dangerous such seemingly innocuous things as Word files can be.

If you are in the nasty habit of downloading and installing software from the Internet, you're crazy. I do download and install software from the Internet, but I'm pretty selective about which stuff I'll install. Anything stored at Tucows, CNET, Download.com, etc. I wouldn't touch with a full-body condom. Yuck.

Anyway, all of this to say don't exchange any Microsoft documents, they're great carriers of every computerized STD (VDs for you old timers) you can imagine. And don't download useless crap from the Internet, it's the same thing. You may think you use a condom (antivirus/anti-adware software), but nothing is going to be as safe as abstinence. So, stay clean and don't be a pimp for your computer.

I am told that this is a fairly insane position for a real Computer Scientist to take. In an age where static checking, managed runtimes, virtual machines, etc. are king, Perl doesn't make sense. Even during my defense last week, Dr. Mizuno asked, "So, why did you do this in Perl? This language is very strange to me." So, I'm going to try and give a defense of my language of choice.

Flexibility. If there's anything a Perl programmer is looking for, it's flexibility. Perl's motto is, TMTOWTDI, or There's More Than One Way To Do It. In Perl, there are more like 10,000 ways to do anything. For example, all of these are common expressions for saying the same thing:

# TMTOWTDI #1
if ($x == 2) { $a = "Hello World!"; }

# TMTOWTDI #2

$a = "Hello World!" if $x == 2;

# TMTOWTDI #3

$x == 2 and $a = "Hello World!";

# TMTOWTDI #4

$x != 2 or $a = "Hello World!";

# TMTOWTDI #5

unless ($x != 2) { $a = "Hello World!"; }

# TMTOWTDI #6

$a = "Hello World!" unless $x != 2;

# TMTOWTDI #7

$a = $x == 2 ? "Hello World!" : $a;

# TMTOWTDI #8 (not exactly the same on false)

$a = $x == 2 && "Hello World!";

# TMTOWTDI #9 (ugly)

goto EVIL unless $x == 2;

$a = "Hello World!";

EVIL:

I could probably have come up with more, but we start exhibithing worse and worse style if we do. My point is, I can think in Perl. I don't have to reorder my neurons to operate in one style or programming or another as enforced by a language. Perl gives me the opportunity to program in multiple styles simultaneously depending on what suits my need at the moment: procedural, functional, object-oriented (there are actually several OO styles available), spaghetti (via goto), whatever.

Features: Perl has most of the same features as Sun Java, Microsoft .NET, and other "modern" languages/language platforms. Perl, despite popular belief, is a compiled language rather than interpreted. However, Perl is usually compiled from source on every build. This isn't a requirement, however, as it does have the ability to build objectcode and bytecode executables. In fact, there are tools to translate Perl into forms acceptable for both the Java Virtual Machine and Microsoft .NET—I've never used them, so I can't attest to their efficacy. Perl supports garbage collection. This garbage collection is performed via reference counting, so it's far from perfect (make sure you break any reference loops). It is a heckuva lot faster than the stop-and-copy style of garbage collection used by Java (ever notice Eclipse or JEdit just stop doing anything for 60 seconds or that a Java program takes up twice as much memory as necessary?).

Static Checking: This is a strong sucking point for Perl. However, my collegues often tout the beauty of Python and yet, Python suffers under the same problem. The problem is that both Perl and Python allow for runtime modification of the symbol table. Therefore, I can, as a Perl/Python programmer, create new functions, removing existing function, and replace functions while the program runs. It isn't a good idea to make a habit of doing this, but it provides a great deal of power when it comes to coding.

I'm sure Dr. Banerjee and Dr. Stoughton can probably prove that such constructs are unnecessary and that by using static code we can achieve much of the same power if we reduce these patterns down logically. Bah! I am not a mathematician, just a logician. I'd much rather have the Stoughton's and Banerjee's of the world make my code safe by creating new and better compiler technology than have to reshape my mind to fit some mold. (Yes, that's an emotional argument, get over it.)

On the other hand, static checking doesn't guarantee your code works. This is the common misconception the incoming freshman has when s/he says, "It compiled without errors, so it must be right!" Wrong! Static checking can verify that your code doesn't contain any typos and that did in fact make sure that you only used your numbers like numbers. It cannot say, "Aha! Your code does what it's supposed to!" No, only humans can do that. The guys working on verification software or ways to prove that code fits a specification are closer to finding the truth on this subject. The only way to verify that your code is correct is to either logically prove that your code does what it's supposed to and/or provide exhaustive test cases for all code. Since the latter is generally impossible (unless you have the next 40 trillion years to run your tests), proving the correctness of your code is your only fully correct recourse. On the really delicate parts of my code, that's generally what I will do. However, for the more general bits (input/output especially), I will create unit tests.

Unit tests are the only way to really make sure your code is generally safe. The more tests, the better. Using good testing strategies is also important. Anyway, it doesn't matter if your code is statically checked C++, OCAML, Standard ML, or loosely checked Perl, Python, or Ruby: You must either proof or test all of your code! Thus, I see static checking as helpful, but not the ultimate answer to coding problems.

Unit Testing: Perl has a built-in unit test framework called the Test::Harness. All you have to do is create your Perl Makefile (ExtUtils::MakeMaker) or Build script (Module::Build) and then dump a bunch of test scripts in the ./t directory. On more complicated systems, you may have to use a web server or web client or some other such thing to test your code. In this case, you can use Test::Harness directly to run the tests and write in any extra stuff you need. Unit tests in Perl are easier to write than any other testing framework I've used—I've not used Python's, so I cannot attest to it's abilities.

POD: Perl uses a documentation format called POD. This language is not powerful, but it is very simple. It's superior to Javadoc because it allows for the creation of complete documentation, not just API docs. I can write POD and have it translated into man pages, HTML documentation, printable documentation, or plain text. I can have it translated into custom formats relatively easily because the language is so simple. I've also used Python's docutils reStructured Text format and have to admit it is cool because it is so flexible, but the parser itself is not. If you want something else besides LaTeX or HTML, you're SOL.

Ugly: Perl is ugly. I will agree to that. However, are there any "pretty" languages out there? I haven't met one. I happen to think that Java is really, really, really ugly (do I have to cast back and forth to and from Object every time?). C++ is pretty ugly (ever use templates?) and Java 1.5 will earn the same ugliness with it's generics too. Python is just queer without any brackets or braces to start and end your statements, but is probably prettier than most (Mr. Idiot-Programmer can't format his code badly 'cause it won't run if he does). C is completely disgusting. OCAML and SML look like Calculus equations to me and I've already told you I'm not a mathematician.

I'm sorry, but this just isn't an argument that holds much water with me. The sigils ($/@/%) are the major intimidation, but once you know what those mean, it becomes worlds easier. Perl does have a context-sensitive grammar, which is a little scary as one statement can take on different meaning based upon which construct it's placed in. But that's the scariest part. Given this:

$x = 1 if $a == 2 and $b == 3;
$a == 2 and $b == 2 and $x = 1;

The context sensitive aspect of the grammar causes both of these to work as expected, even though the and might normally throw us off. For those who don't know, Perl has two "and" operators, and and &&. The former is the ultra-low precendence version. Therefore, in general, it is the very last part of a statement to be executed. The if here modifies the context of the and though, causing both of the above statements to be treated the same, parsed as if:

($x = 1) if (($a == 2) and ($b == 3));
((($a == 2) and ($b == 2)) and ($x = 1));

That is, the and in the first statement is executed before the if rather than after, as would be expected in a context-free grammar, but counter-intuitive to human reasoning. Anyway, Perl tends to do a lot of dwimming to help out the programmer. This can get a person into trouble sometimes, but I've found the rules to be intuitive more often than say the strict grammar rules of most other languages.

All of this to say: I think Perl is ugly, but no uglier than any other language once you understand it.

Perl 6: I'm holding out for Perl 6. Perl has a long history. As such, it has grown quite a bit and inherited much that is evil from it's earlier days. Many of the objections folks have had with Perl 5 are resolved with Perl 6. It looks like 2005 may see the debut of Perl 6 and it will be a good year if it does. Perl 6 rewrites Perl 5 from the ground up and includes (as I understand the writings of Larry Wall, Tom Christiansen, and the other Perl gods):

• Static checking: The new Perl will feature a complete type system and static checking. This checking will be as strong or as weak as you demand. This will make it's type checker as strong as C if you don't want to modify the symbol table after the fact, or as weak as nothing if you want all your checking to happen at runtime.
• Better Regexp: Regular expressions are a huge feature of Perl and have become huge features of most other languages because of Perl. Perl has raised the bar by creating a new readable regexp format that allows the creation of recursive descent grammars, in addition to plain regular expressions.
• Parrot: Perl 6 will run on top of a virtual machine named Parrot. Parrot is a VM optimized for dynamically checked languages and is decidedly different from the Java VM or the .NET CLR. It is similar to the CLR in that it allows multiple languages, C++, Java, Python, and Perl to extend and use each other's code as natively as if code were written in each its own language.
• Better Coding: They've improved the syntax and general features of objects and classes. They've improved the subroutine, methods, and functions are defined and executed. These will make Perl 6 faster and better. One of the coolest new features is that every block in Perl is a closure, so there will never again be confusion as to what value was bound to a variable when executing a subroutine. Blocks can be handed around like any other value.

Finally, I do need say something about agnosticism. Language is something akin to religion for most programmers. Typically, a programmer will try one or more languages and will become and expert and follower of one or two particular languages. Mine tend to be Perl and C++ (but I do use some Bash, Java, and C too). Unlike religion, however, I don't believe there to be a one true language. (I don't really like to make Christianity a religion, but for the sake of this argument...) I am a linguistic agnostic and believe that language preference is just that, a preference. I think all languages have value, though perhaps some are much more valuable than others. I don't assume anyone is an idiot based solely upon their language choice (though, Visual Basic programmers come close). I'd appreciate if you would give me the same courtesy. Playful jest is fine, I'd just rather not be insulted. However, (dramatically) as with being a Christian, I can accept the Perl pogroms as part of my fate—along with the insults that I'm an idiot for believing in a seven-day creation. Anyway...

Those are the major reasons (I can think of right now) that I like Perl. This isn't a real review, just my opinion. The information here was drawn from my memory, so I may have stated something wrong. In general, I think Perl is cool, but you're free to think whatever you like.

Now that I've finished the bulk of my Master of Science program, it's time to consider the next move for the systems. I've made most of the major changes I wanted to coming into this position, now I'd like to make those changes robust. So, the coming year's theme: stability.

I believe we must examine, to achieve the goal of stability, there are four aspects of the systems (in no particular order):

• Network infrastructure
• Server infrastructure
• Security infrastructure
• Information infrastructure

Network Infrastructure: This is the foundation of our systems. In the Department of Computing and Information Sciences, this is a completely uknown quantity. None of our current staff can state with certainty the current network's history or current quality—we just don't know. The students and myself have not been around long enough to know. Our hardware specialist, Earl has been around long enough to know quite a bit, but still doesn't really know the network infrastructure well enough to gauge it's condition. Before we can really begin to guarantee quality anywhere else, we will need to quantify the quality of the network. Once quantified, we will need to address any problems found. This research will begin this month and should be finished by May. At that time, we make any changes we can to stabilize this aspect of our systems.

Server Infrastructure: Work on this aspect has already begun. Our server systems are actually in fairly good shape, but still require tweaking to bring the system completely into the 21^st Century. We'll be moving to a new web server, the old web server will be handling email services, other services will be moved around, and our obsolete hardware will be retired or placed on standby to be retired in the future. Most notably, our Solaris fleet is made entirely of computers that were never meant for server use and reached End-Of-Life years ago. If we're to continue our use of Solaris, new servers must be purchased. Solaris used to be our flagship system because Sun offered such great support. Yet, as of now, the support offerings from Sun don't look to be that compelling, in my opinion.

Another notable aspect of this issue, is the problem of file services on our systems. For the duration of my time in the Systems Coordinator position, we have been plagued with NFS problems. I intend to resolve this via one of several solutions. The first solution is to attempt to remove the current Solaris NFS server from our systems. It seems to be a major cause of problems on our Linux workstations (it's actually got to be a bug on Linux, but a probable work-around is to remove the Solaris NFS server). This should solve the current stability issues.

Security Infrastructure: Account management and authentication was a major focus of my M.S. Report. These were, really, the largest changes I have implemented on our systems. These have resulted in the most significant discomfort to users as well. Hopefully, most of the pain associated with these changes has ended. The account manager has not been fully implemented. During the next few weeks, it will be set in place. This should decrease the amount of effort spent performing account maintenance and allow us to monitor accounts much more closely than is currently possible.

As mentioned above, NFS is a stability problem on our system. However, while the solution given above will resolve the stability problem, it doesn't address the underlying security flaws of the NFS protocol. The NFS protocol itself has irreparable problems that demand it be replaced. This might be as simple as hoping for full NFSv4 support in Linux soon or as complicated as implementing a different file system infrastructure under Linux. This is, as yet, uncharted territory, so more news will come as we further research the issue.

Information Infrastructure: Communication is a major problem for the systems staff. As such, we're looking at better ways to communicate with students and to put a "human face" on what we do. If we can do this, students, staff, and faculty will be more likely to work with us rather than grumble about us. I have a few ideas that range from improving the support web site, to improving our support tracking system, to posting more information in the form of banners and posters in the labs, and even possibly requesting some renovations to Nichols to make the systems staff hallway more accessible.

I think lots of exciting things will happen during the coming year with the services. I hope we can prove our worth to faculty, staff, and students for the next coming year. Consider this an early New Year's resolution. Cheers.

Insanity: doing the same thing over and over again and expecting different results. —Albert Einstein

I just discovered this quote by Einstein. It's a fact that every Windows user out there, will double-click on an icon and an error will occur. There seems to be a law of nature that requires the Windows user to then double-click again and again and again at least three or four times before giving up.

They are insane. Of course, the real joke is that the software is written in such a way that it might actually work on the third or fourth try. Pathetic. ;)

Microsoft Internet Explorer Sucks describing my Google Map hack problems has moved during a recent update of my web site.

I've spent the last three hours putting together a unit test suite for the agent library. This was to be the first of three groups of unit tests. The next group of unit tests would test the agents themselves. Then the next group would test the server extensions. So far, the first extensions are going slowly.

I can't tell if the hold up is that I'm not thinking clearly because I'm just a bit tired or what. This should be going faster than it is. Oh well, keep on truckin'...