Results tagged “rant”

I’ve been taking DDJ for a couple years now. It’s cheap and occasionally has something interesting in it, but it’s been less interesting than I remember it being when I read it in college. I’ve been much more enamored with the Communciations of the ACM. Today, I received my issue and there’s an interview with Paul Jansen of TIOBE Software. In the article, he’s quoted saying:

Another language that has had its day is Perl. It was once the standard language for every system administrator and build manager, but now everyone has been waiting on a new major release for more than seven years. That is considered far too long.

While I am biased, I have to admit that I disagree pretty strongly with Jansen’s assessment. First, let me go into the problems with how he came to this conclusion and then explain why I think I’m justified trusting that Perl is in it for the long haul despite my bias that would have me think so anyway.

I want to first evaluate the way Jansen has collected the data he’s used to make this statement. TIOBE puts together what they call the TIOBE Index. This is a rating of the popularity of various programming languages. The TIOBE web site claims, “The ratings are based on the number of skilled engineers world-wide, courses and third party vendors.” How do they measure this? By performing a search for:

+"<language> programming"

on 5 popular search engines, including: Google, Google Blogs, MSN, Yahoo!, and YouTube. That’s it.

What they are measuring is not actual popularity, but the amount of hype surrounding each one. Not only are they measuring hype, but only hype that discusses “programming”. What if everyone prefers to say “programming Perl is fun!” That wouldn’t get picked up by the search they use. What about “Perl scripting”? Nope. Missed. (Here I should point out that Andy Lester appears to have been on to something when he gave his lightning talk about Perl programs versus scripts at OSCON last year.) In essence, this is, if they’re disclosing the complete metric, incomplete. It’s a shortcut that might be 90% right or 50% right. This is just poor statistics.

The second aspect of Jansen’s comments I take issue with is the statement that there has not been a major release in seven years. That’s not strictly true. Perl 5.10 has just been released and it includes new features like the new smart match operator. Beyond that, there has been some very active development on a closely related project, Parrot, and language development toward a huge milestone, Perl 6. Furthermore, where Perl truly shines is in all the development on CPAN. CPAN is getting large and complex enough now that we’re having to rethink how it works just so we can find anything on it. This is a good problem to have.

This comment by Jansen does, however, serve to indicate a certain perception gap caused by the long wait for Perl 6. It’s even been considered that the name of Perl 6 is harmful to Perl 5. This has been discussed out by others for some time.

In my opinion, Jansen is on shaky ground with his claims and probably only because he’s not well informed by anything but his own metrics. I should think that he’d at least research the trends and issues facing the top 10 languages listed by his survey as to provide some better justification for it’s accuracy.

As for the reasons I still have warm and fuzzy feelings toward Perl’s future, I can list them off rather easily.

1. I am participating in a number of growing projects that depend on Perl’s future. Jifty and rethinking-cpan are just a couple I’m involved in. I can point you to several other vital projects that I use or am familiar with.
2. I know of several companies actively pursuing Perl to develop core projects and continuing to train developers. This includes imdb.com, Socialtext, Best Practical, Six Apart, and several others.
3. Recently, Google launched Google App Engine. This tool provides services to Python developers as part of the initial release. The top most voted for issues are first to add support for Ruby and second to add support for Perl, as of this writing.
4. There’s an average of 50 new and updated modules being posted to CPAN every day. That’s not a small number.

I can probably come up with more, but now it’s getting late, so I’d better end this thing. If Perl is going to die, it’s got some years left before it happens. I think there will be enough activity to keep it going and increasing during those years rather than dying.

Cheers.

I have a certain frustration with due dates. I have determined that this frustration stems from a misunderstanding of the nature of software and their timelines. I am, therefore, banishing the terms "due date" and "deadline" from the realm of software project timelines (as a lot of software engineering literature has wisely already done) and insist that the word "milestone" be used in its place. Why?

When you decide to create a piece of software to perform some task, you are starting down a path that has no end. Once a software project is created, that project immediately takes on an eternal soul. If you want to add feature X to the software by deadline Y, you will soon find that even if you succeed in getting this feature in by the deadline you still have more work to do on that feature after the deadline. Why?

Features are nebulous little critters. Even when you think you have them well defined, you find out they are more complex once actually implemented. For example, I'm in the process of converting our server infrastructure to use a tool that will help us scale upwards as we add more clients. We aren't done once we move our servers to this new infrastructure because we'll still need to retool it and play with the optimization settings to make sure it's performing well. This will continue for as long as we have the servers.

There's no finality on a software project ever. It will always require a little more maintenance until the business decides we're not doing that anymore. Even then, depending on the project, we may need to do some level of support down the road. I would be surprised if Microsoft doesn't still get support calls for DOS or Windows 95, which have been dead products for years.

My conclusion: A software project is never finished. A deadline is not a deadline, it's a milestone. "Deadline" and "due date" imply finality. A "milestone" is just another landmark along the path, a much better description. There's always one more bug to knock out. There's always one more improvement to be made. Anyone who thinks otherwise is simply naive.

Okay, so we've all heard of and mocked the BSOD (Blue/Black Screen of Death) on our computers. Today, I'm going to deride the Blue Screen of Dumb on my Apple. I just forceably shutdown my laptop by holding down the power button for 10 seconds. Was it hung? No. My mouse was still moving, it was still taking keyboard input, and Expose (Apple's window switching effect) appeared to be working. What was the problem? My screen was blue.

When you plug an additional monitor into an Apple computer, it turns the screen a pleasant shade of soothing blue while it figures out how to add the second screen. Apple tries to protect the user from ugly screen change side-effects by covering them over with a uniform color. This way, even if your screen flickers and blinks, you won't notice it so much. It's one of the ways Apple politely pats the users on the head so they don't have to be so worried about they're computer.

The problem is that sometimes when you're in a hurry and you don't take the time to unplug the external monitor cable and wait for the blue screen to go away before closing your Apple laptop and putting it to sleep, when it comes time wake-up, the Apple sometimes leaves that pleasant Blue Screen of Dumb up. Interestingly, I can still tell where the password box is for my screen lock-out (corporate computers MUST HAVE SCREEN LOCK PASSWORDS you know) by moving the mouse around. If it moves off where the box is it turns into the pretty Apple wait pinwheel. If I move it back on, it becomes an arrow or the "I" cursor over where the text fields should be shown.

After typing my password and hitting "Enter" (which I don't recommend doing if you think you had a chat window open before you shutdown that might be active again, that burned my on my Linux workstation the day when I told all my friends in the local LUG channel on IRC what my password was), after typing my password, I can then move the mouse into the corner that actives Expose and it turns to the finger cursor normally in place for Expose. Going back to the corner, it turns back to a regular pointer. All this indicates that if it weren't for the Blue Screen of Dumb, I should be able to use my computer. In fact, I suppose if I were blind and had all the accessibility features turned on, I might not even notice since I can't see the screen anyway.

The same thing has been known to happen with the lock-out screen, particularly if I get a little too eager to enter my password. I have my Mac set to lock the computer when waking up or after the screen saver starts as per company policy. However, if I start typing before the password box shows up (which can take several seconds after waking up because of how many programs I usually have running that it has to notify of the wakeup) then sometimes when I hit enter the password box goes away but this time the Black Screen of Dumb stays in place. This one I can almost always eliminate by closing my laptop again waiting about 30 seconds and then reopening and trying again.

Now, I know the real issue here is that properly handling sleep and wakeup is hard, very hard. I don't know of anyone who's had a computer running any OS that really got it right 100% of the time. Apples (other than the two issues I mention here) have got it about as close as I've seen in my experience, which is why I rarely hesitate to close my laptop lid to sleep at any point, even when I've been using a second monitor. These problems really don't come up very often. I don't know that that's because of any particular ingenuity or good design on Apple's part so much as it is that Mac OS X doesn't run on anything but Apple hardware so there are fewer variations to test and debug.

Anyway, that's just one annoyance on my Mac, but at least it doesn't crash as often as any Windows laptop I've ever had. Furthermore, since there aren't a lot of ways to tweak things under the hood without going into questionable territory I don't attempt to break it as much as any Linux laptop I've ever had. :)

Cheers.

I've heard this mistake before, but the local talk radio station has at least one current offending commercial running that I heard the other day right after hearing a local leader talk to a reporter and make the same mistake. Both state something to the effect of, "Come visit our web site at Blah-Dot-Com-BACKSLASH-Yadda." For those of you that are non-techy, there is a significant difference between a forward slash (generally just called the "slash") and a backslash. Here's the difference:

The slash is used in web site addresses, typed fractions (like 3/4), in abbreviations (such as "w/" and "w/o"), and indicating that two ideas stand side by side (such as "and/or" or "meet me tomorrow/Sunday"). The other is generally not used for anything unless you run CMD.EXE on Windows or are a programmer needing to write out escape codes or break up lines.

The slash is commonly enough used that it is beneath your right pinky on a standard QWERTY keyboard. The backslash, on the other hand, has no standard placement on a QWERTY keyboard. It usually appears above the ENTER key with another rarely needed character, the vertical pipe ("|"), but it also appears next to the space bar and near the escape key among other places depending on your keyboard.

So, when you give out your web address, don't be tempted to sound fancy or use an extra syllable. Rather, just keep it simple and say "slash." In fact, most folks can erase the term "backslash" from their mind and just ban it from their vocabulary altogether.

Cheers.

I was scrolling through my morning feeds and came across this gem on Slashdot, "Should Schools Block Sites Like Wikipedia?
" The story goes on to describe someone's question regarding the fact that the local school board decided to block access to Wikipedia "because students may be exposed to misinformation". This simply describes an opportunity lost and a new form of book banning.

I grew up learning about how books like the Wizard of Oz were banned from schools because some people didn't like the fact that it had a witch. Other books were banned because they praised opposing political ideals. Now, apparently, it's vogue to ban something because it might not be accurate. However, this is still just as bad an idea as all the original book bans.

Where do you stop? The New York Times has in the past few years had at least one reporter fired because he fabricated information published in the Times. Should we block the New York Times because it might expose students to misinformation? Should we also block cable television because certain news anchors published stories in that medium without verifying the facts? Should we start blocking the text books because they sometimes contain errors or misrepresent facts?

Should we stop allowing teachers in the class room because sometimes teachers share incorrect informatino? I once had a teacher tell me that NASA was experimenting with mounting monkeys heads on robots and that the monkeys were controlling the robots successfully, but only for a few hours until the head died. Should we throw all the teachers out because there are some that are crackpots?

No! Of course not. This is an opportunity to explain that all sources are suspect until they are corroborated. If you read something in Wikipedia, you take a note to check any fact you can't verify from your own experience. You then verify that fact in the quoted source (for articles that properly quote sources), you can check your local library and do a database search, check another encyclopedia, look in a journal or magazine, find related books, etc. I find that Wikipedia is a great place to get started, but I certainly don't think of it as authoritative.

On the other hand, you should always do the same thing, insofar as you are able, for any source of information. If a source of information makes a claim, you should check it's sources and possibly verify the claim in other places. It's easy to make an unverified claim. It's hard to make a claim that is cited and backed up with facts and also backed up by other unrelated sources.

The lesson is that some sources are more trustworthy than others, but none are beyond suspicion. The lesson should be that you should always check your sources and verify that what you're reading is factual and reliable. Banning a source only means that you take this object lesson away and you raise students that are actually less able to think for themselves and more ignorant. Great, that's just what we need. Good job Anonymous School Board.

Cheers.

There's an old saying that goes, "If it ain't broke, don't fix it." Scott Adams once made the comment regarding how engineers think, "If it ain't broke, it doesn't have enough features." I think the latter thinking must have applied when Google released their latest Google Notebook
improvements this week.

I've become a major fan of this tool over time, but the new look is clunky and cluttered. I liked how sleek the interface was before, but now there's a bunch of extra shadows and rounded corners and borders that really serve no purpose but to distract me from my note taking. The notes also don't collapse very well anymore. I've also found some bugs in the search.

Bah. I hope they fix this soon.

I run Windows on my Linux desktop using VMware Server. It works pretty well. However, one thing I hate about VMware is the fact that it has a direct key binding to reboot the system, without confirmation. The key binding is to one of my most oft-used keys: Ctrl-R. I hit Ctrl-R on a very regular basis because that's the hot key to reload a page in Internet Explorer and Firefox, which is something I do pretty frequently as a web developer. Anyway, since I mouse back and forth between VMware and my Firefox browser, about once in every 50 Ctrl-R's, focus is occasionally back on VMware, which causes an immediate reboot and also an immediate expletive from me.

This is stupid and, from reading the VMware forums, a problem that's existed since at least 2004 that still hasn't been addressed. So far the solutions are either to make it so that it's really hard to give VMware focus by accident or to turn on hints and enabled the hint on resets to add an additional confirmation when you make this action. Both are unsatisfactory.

However, in case you are also frustrated by this, I can keep you from going further to look for a solution. Close your VMware Console and edit the preferences file, which is ~/.vmware/preferences under Linux. In that file, add a line reading:

pref.vmui.reset = "TRUE"

Next, save the file and open VMware Console back up and go to Help > Hints > Show Enabled Hints. Make sure you do both or you will still be frustrated the next time you hit Ctrl-R.

Cheers.

This weekend I attended my first Circle
meeting. These meetings are attended by our work clients, which are partners in accounting firms and their IT leadership. If you are not familiar with accounting agencies, let me warn you that they are nearly 100% Microsoft shops. Being a Mac/Linux guy myself I chose to use this as an opportunity to introduce some of them to the concept of another operating system. These folks tend to be stuck in the "Ew! It's Apple!" crowd. Since accounting firms tend to be 4 to 6 years behind in technology (even our Circle members, who are way ahead of the curve tend to be a bit behind the main stream) these folks haven't yet seen how cool the Mac is. Anyway, here are the misconceptions I encountered most this weekend:

1. It's just a pretty box; you can't use it to work unless you're some kind of designer. Actually, I find that the Mac is a very nice platform to run from as a web developer. If you are in an enterprise environment using Microsoft Exchange, it's not so nice (Entourage is a PoS). However, if you do not run Exchange, I'd say that Windows has very little advantage over the Mac. Even if you run Exchange, you can run Windows on Mac now and get Outlook to run there anyway. I'll let you know when I get my new MacBook Pro how well that works out.
2. There aren't any good Anti-Virus solutions for it. Well, this is true, but it's also true that you don't hardly need Anti-Virus on a Mac. I got really skeptical looks from the IT folks across the table when I said it and said that there really aren't any major viruses for the Mac and I've never heard of anyone with a Mac getting a virus. Could it happen? Certainly. It's possible, but because of the built in limitations and security implementation, it's rarely a problem. I'm hoping that the UAC
   features of Microsoft Windows Vista might provide a similar security improvement for reducing the need for AV, but we'll see how well those security features really work over the next few months.
3. Finally, my favorite: Yeah, but it's only got a one button mouse. Simply not true. The Mighty Mouse
   from Apple now supports two buttons. Not only this, but two button mice have been supported for years. Even with just the one button mouse, you get essentially the same functionality (context menus) by holding Control while clicking the mouse button. After about 2 minutes of using it, I didn't notice the difference anymore. This one is especially insidious because even after I explained this to the folks present, they continued to believe this fallacy as if I hadn't spoken and this is the least true of all of them.

Before I go, I don't want anyone left with the feeling that I'm insinuating that these IT folks are backwards, blind, or stupid. They're good at what they do and the accounting profession, in general, simply doesn't have a need for anything but Windows. None of the specialized software they require will run on anything else, so why would they bother? Until CCH, CSI, Intuit, or another major vendor comes up with something on another platform, they will continue to ignore what they don't need to do their job and focus on getting better on what's actually applicable.

Of course, ASP
services are also on the rise and as that happens, it's going to matter less and less what OS you use. The OS will not be a lock-in for applications anymore. As that happens, I suspect that the existing accounting firms will continue to use Windows because that's what they've always done. However, new firms might consider alternatives based on merit. Yet, given the shortage of new blood in the accounting profession, I expect that more of accounting will be outsourced overseas rather than anything changing in the way of OS in the United States.

Cheers.

For part of today, I moved our internal IT support from a Trac-based system to a Sharepoint site. I'm making the move because we're starting to use Sharepoint to help improve internal communications and this seemed like a more logical place since our IT doesn't involve any need for Subversion---code repository integration is where Trac really shines, IMO.

Fortunately, we'd only been using Trac for IT support since I started in February, so there really wasn't much in there yet. We'd organized the Wiki into a few categories of information to describe computers, software, printers, network devices, policies, etc. There were really only about a dozen documents and about 20 tickets in the system, so I did all the work by hand rather than trying to script the maneuver.

For those who don't know, Sharepoint is a portal system that allows any user of the system to create lists of custom records very nicely. It's kind of like a dumbed down version of Microsoft Access for the web with some extra connective tissue and less up-front flexibility---it's just as flexible, but that requires doing a lot of extra footwork. We've used Sharepoint as a document management system up to this point, but are now expanding our use to help us in publication tracking and general project management and collaboration---the kinds of things that Microsoft itself uses Sharepoint for.

Now, in order to get this transition to work properly, I had to create some custom lists because Sharepoint 2 provides nothing close to Wiki functionality unless you want to use Word documents (yuck!) without any help linking items together. Since most of our records were concerned with computers, printers, and software, I created custom lists (i.e., tables with the CRUD forms you need) for each of these and then copied the data over (and filled in a bit more than we had before while I was at it). I then customized the prefab "Issue" list template to connect it with these lists. I copied the tickets over and added the extra comments and then created our one actual How-To document to a Word file and stuck it into a document library. After spending the afternoon putting it together, it does the job, but it's just not quite right.

What I really needed was another Wiki, but Microsoft doesn't provide one in 2.0 (the current version, though I understand 3.0 may offer such a thing out of the box) and there's really no simple way to emulate anything close without cracking open Visual Studio. There are some pay for Wiki add-ons, but while the price isn't out of reach, it's not really worth the price if I can just use a Wiki as a separate piece. There are other small annoyances in Sharepoint such as the lack of configurability or that what is configurable is really the wrong kind of configurable. I don't really care that much if I can set the width of the panels in the portal, but it sure would be nice to have an easy way of adding menus to the sidebar or topbar of static pages: sorry, no easy way to do, señor. Bah. Oh, and don't get me started on the lack of RSS/Atom syndication support in a Portal! (Though, techincally, I can write an XSL stylesheet and import the RSS as an XML panel, in this case. There's no non-programmatic way to do the export, to my knowledge, though.)

This pretty much confirms my experience with most Microsoft products. They work great so long as you conform your way of doing things to The-Microsoft-Way. When I worked to develop an Microsoft Access call database a few years back, it seemed that I spent most of my time trying to make my VB code weave through a field of "Not-The-Microsoft-Way" mines. I've faced the same issues when working with creating styles in Word or formulas in Excel or trying to configure the front page of Outlook. My favorite language is Perl simply for the fact that there's no conformance on any level. You can imagine that I don't handle this way of doing things very well.

The other issue Microsoft has is due to their hugeness. It takes a very long time to release product updates. Microsoft hasn't made a major feature release to Sharepoint since 2003. Wikis have started taking off in the corporate environment since then. Three years is a long, long, long time in the Internet Age. Sharepoint is an obvious delivery platform for a Wiki, but since Microsoft hasn't really added any features to it in three years, one can hardly expect it to have any groundbreaking functionality.

These two problems combined with my long-standing distrust of any software for which I can't find the source of a bug by reading the source are the reasons why I dislike Microsoft-based solutions. I don't really care for their business practices, but I don't really expect anything different from such a large bureaucracy.

Microsoft has a problem with agility. Their software solutions are sluggishly developed and new features are static in nature. I assume the highly structured nature of things is due to the massive testing and documentation infrastructure they've built to ensure quality (fifty or more people might be involved with adding a new method to a library), but I think this has ended up creating software solutions that feel stiff and are so often delayed months or years in delivery.

Open Source software can suffer for the opposite reason. The bigger projects seem to do alright because their is such a massive amount of contribution guaranteeing quality. The smaller projects, however, can suffer from a lack of quality because the authors don't put enough emphasis on design and testing and just hack some code together (which works for the smartest developers, but not the average folks like me).

I think Microsoft could definitely benefit by trying to streamline their process and reduce the amount of overhead required to get a new feature. Until they start putting out solutions that are a little more flexible and a little more timely I'm going to have a strong dislike for Microsoft products. Until they open the source (hah!), I'm going to distrust Microsoft products because I know I won't always be able to find the original source of bugs. That's all I have to say about that.

Cheers.

In a recent discussion on the Magnolia developers list, Nicolas referred to a post discussing the negative side-effects of using JDK 1.5 to code readability. This pretty well demonstrates one of the reasons Java bugs: the developers want a language that guarantees code readability.

I'm all for code readability, but Java programmers seem to have an irrational fear of giving out tools that could be used for evil. This is a pretty irrational fear since Java already has features like the reflection API, which is like a programmer's version of the nuclear option, one mistep and you've blown up half the planet and it makes some of the worst code I've ever seen.

Anyway, David Flanagan points out that the new import static can make your code less readable. He contrives a couple examples of poor uses of the new construct and warns folks. Now, I want to say that Flanagan has it correct, "This isn't meant as criticism of static import; just an exploration of it." My criticism is of Nicolas and others that make statements like, "I would tend to think it's better to stay with 1.4, especially as the code is easier to read. (in my own opinion). [sic]" JDK 1.5 is not any less readable than JDK 1.4. That's like saying British English is less readable than American English, it's not a valid comparison. It's the usage that matters.

If someone engages in irresponsible coding via the static import mechanism, is this any worse than some of the issues one can have with regular imports? For example, look at:

import com.boomer.mgnl.firmadmin.User;

// Later...

public info.magnolia.mgnl.user.external.bean.User copyToExternalUser(User firmUser) {

  info.magnolia.user.external.bean.User user = new info.magnolia.user.external.bean.User();

  user.setFirstName(firmUser.getFirstName());

  return user;

}

I have some of that crap in my code because User was used to name an interface in one package, a bean implementation in another, and an extension of that bean in another, and then used in a totally different module to connect to external users in another place. This is an example of poor choice in names. If your application is going to have multiple user classes that might be used in the same object now or in the future, name them something different from each other! The code above works in JDK 1.4, so JDK 1.4 code can also be hard to read.

Thus, the point for any programmer in any language, is think when you write your code. You can write horrible code in even the simplest language with the best enforced rules and weakest capabilities. Adding powerful tools that can be abused does not mean that the code will suddenly become unreadable, it just means that you've got a few extra pitfalls that you need to put railings around (i.e., corporate/project policies to make sure no one does the stupid). And then, you have to have code reviews and enforce these policies on yourselves or via a community.

I hope that wasn't too much of a rant and I hope my ramble didn't negate what I said too much. Cheers.

This is not about a TV show, but about the west wing of Nichols Hall, the building where I work. The CIS department fills up most of the west wing of this building on KSU campus including all four floors. However, if the design of this building was a positive for the CIS department in the past, I believe the design of the building itself is inhibiting CIS as a department now.

First, let's overview the arrangment of the floors. Thanks to facilities and Travis I can include some maps to help you see what I'm talking about.

Starting with the basement, we have four computing labs and two sets of offices for graduate studennts. Room 16 contains our main classroom lab and houses 24 PCs running Microsoft Windows XP. Room 16A contains offices for a half-dozen or so graduate students. Room 19 contains offices for a couple dozen graduate students. Room 21 is space that CIS gave to CNS for a general public lab for the whole campus to use (and is used by CIS for some of our 100 level courses). Room 22 is (as of a week or so ago) our special projects lab to be used whenever a faculty or student requires software that will break a normal lab machine and make it unuseful to other students---it's the smallest and least used lab. And Room 24 is the robotics lab, which is mostly used by our software project course and the department head of the CIS graduate school. The rest of the space is used by the department of Speech, Theatre, Communication, and Dance.

The other three floors are separated from the east wing by a large, three-story high atrium, which features a large mural depicting the various uses Nichols has been put to. (Nichols Hall does have an interesting past ranging from basketball stadium and swimming facilties to victim of arson—possibly in protest to the Vietnam War—to home to a very diverse set of students in computing and the oral and dramatic arts.) On the west wing, the only room that isn't used by CIS is the main office for SCTD just right of the atrium as you enter the building.

On the first floor, we have our main server lab, two student computing labs, two classrooms, two research labs, and the offices for the systems staff. Nichols 114 is the server lab for the department and includes raised flooring and an enormous and ancience HVAC for cooling. Nichols 116 is my office. Nichols 117 is the office of Travis and Tyson. Nichols 118 is the office of Cole and Andy. Nichols 119 is a research laboratory used primarily by Dr. Andresen. Nichols 122 is the largest CIS classroom capable of seating about 50 students. Nichols 123 is Earl's office. Nichols 124 is a research laboratory used primarily by Dr. Hsu. Nichols 126 is our mixed Linux/Windows computing lab with two dozen PCs and room 126D is a small conference room off to the side. Room 127 is our other classroom which seats around 30 students. Finally, Nichols 128 is our Linux lab with 17 PCs running Linux.

The second floor is mainly office space for faculty and staff. The main office is in Nichols 234 and the conference room is in room 236 next door. Room 237 is office and lab space primarily for Dr. Deloach's students. Room 232 holds the break room, mail, and copy machine. The department head's office is in Nichols 234C and the administrative staff is in N234 or N234B. The advisor's offices and the accountant are off of Nichols 232 and our library can be found in Nichols 233 off of Nichols 232, which houses our journal subscriptions, course books, loans from the main library, copies of papers published within the department, and a small meeting area where the systems staff have our weekly meetings. Nichols 218 is south of the break room and contains cubicle space used primarily by Dr. Hsu and the offices of Todd Wallentine, Dr. Stoughton, Dr. Hsu, and Dr. Robby (and yes, that is his only name, "Robby"). Nichols 219 holds cubical space for more grad students and some research space for Dr. Neilsen. Off of Nichols 219 are the offices of Dr. Schmidt, Dr. Andresen, Dr. Amtoft, and Dr. Nielsen. In the corridor between the faculty common rooms is room 223 which houses a lecture recording studio for online lectures. Room 227 holds more grad student offices and some research machines for Dr. Hsu and Dr. Hankley. Off of this area are the offices for Dr. Howell, Dr. Gustafson, Dr. Mizuno, and Dr. Hankley.

The third floor is all office space for graduate students (especially Ph.D. students), research staff, and faculty. Nichols 316 houses the main cubicle space for Ph.D. students and a few extra machines for use by them. Room 317 is also space for Ph.D. students. Rooms 318, 323, and 324 are utilized primarily by the SAnToS research group for offices. Off of room 324 are the offices of Dr. Deloach, Dr. Banerjee, Dr. Singh, and Dr. Hatcliff.

Okay, now that we know what it looks like, what's wrong? I think the primary problem with the buildings design is that it enforces a fairly segregated and professional atmosphere. Some of the younger staff have taken to occassionally started calling Nichols, "The Prison" or "Nichols Penn" because of all the doors and small spaces. The only open space in the building is the atrium and that is generally considered the territory of the more outgoing drama nuts and dance majors. Furthermore, there's no part of this space that could be useful for studying or relaxing (at least from my perspective) because the only places to sit are hard wooden benches with either no backs or backs designed to look cool rather than for comfort. Why would I relax there when I can go to a lab and sit on a cushioned office chair? There's no table space for those with laptops either.

Anyway, that leads us back into the confining spaces of the rest of the building. All the labs have heavy wooden doors that remain closed at all times (as per the fire marshall's requirement). The building's original windows remain in place, unmoved, which is a problem because the building wasn't designed with the same layout it currently has, so some of the windows, such as in N114, 116, 117, 118, and 127 are too high to see out of or deliver much light. Also, Nichols 119, 124, and 128 have no windows making for a very cave like feeling (especially 119 and 124 which don't even have interior windows). Of all the space, N126 should be the most open as it is on a corner and has lots of windows, but we've ruined that by putting in cubicle dividers, the study space in the back of the lab with the extra high dividers is an especially heinous window blockage, in my opinion—and serves little purpose since few students even know what's back there, so it's largely a dusty, unused space.

The other floors are similar. The basement is as basements tend to be, very cave-like. Nichols 16 is better than the rest, but is generally stiflingly hot because of poor air circulation—we hope to work on the problem soon. Nichols 19 has high windows that barely let in light. Nichols 16, 22, and 24 have no windows. I won't complain too much about this space, though, since I'm not sure what could be done (accept for better lighting and decore). It is a basement, after all.

The second floor and third floors are all doors. They really scream, "Go away! You don't belong here!" You have to go through at least one door to get to any professor's office door and most will go through two, three, or four doors before they even reach their professor's office. You will also have to turn multiple corners to get there. All of this presents an aura of unwelcome to students. The systems staff offices are similarly foreboding being down a back hall and around a corner that dead-ends in an unmarked door that is two steps up. Then each of our offices has a closed, solid-wood door (closed again as per the fire marshall's requirement).

All of this means that while students are supposed to be in the basement and first floor for classes, the faculty are all above the fray in offices on the second and third floors. This is nice for research staff because it means fewer interruptions, but it also means that there are extra psychological barriers to cross for students that might ask for help. Some students don't even know how to navigate the confusing labrynth on the second and third floors and don't want to bother trying after seeing it once.

Having the systems staff segregated from the main corridor is convenient for us, especially since we have no first tier support to help students, staff, and faculty with common and small problems like CNS has. However, it also means that I get a lot of apologies for disturbing me when they come ask questions (of course, that might be because I have a tendancy—unintentional, I assure you—to glance murderously at interruptions, or so I'm told by my wife). Anyway, it's still very foreboding and segregated.

Next, our decor really sucks. Most of our walls are an odd off-white hue with a tinge of purple. The floors are generally plain white tile, except for the main corridors, which are brick tiled. The lighting in this building is frightful as it's nearly all uniform flourescent tubes with their flickering, 60-cycle, greenish light that is oh so nice on the eyes. We've now replaced all the incandescent flood lamps in the halls with energy saving, twisty, flourescent tubes that look rather stupid in their sockets, bare and flickering themselves. The accents on the walls is also very plain and functional—generally limited to bulletin boards, display cases, and pictures of former graduates. The only place we had something more interesting (and even personal!) was on the second floor where our former janitor had placed pictures of her children and grandchildren, but those were taken down (sadly, that was even before she retired because God forbid that we actual have personality in the department!).

Finally, there is no place for students to take a break and for them to make Nichols a comfortable home for themselves. We need a place with a couple computers, a couple televisions, a telephone, a microwave, a couple couches, and a table—a space that's just open, pleasantly decorated, and relaxing. I know for a fact that nearly every senior class recently exiting our program has asked for this in their exit interviews. My class did and we've all been told, "Probably not."

I've talked it out with my staff and we've even come up with a plausible location for such a thing. Nichols 126 would provide an ideal location. Nichols 126 is especially ideal because it already has bathroom facilities on the south wall. If we split the room in half and used N126D and the south half of N126, we could have a fairly nice lounge facility. This could work even better if we could move part of the lab facilties in N126 into N119 (or even half of it), which is, in my estimation, currently underutilized as work space and overutilized as storage space.

Anyway, can it happen? Yes. Will it happen? Sadly, "Probably not." I think the faculty want to really improve faculty/student relations in theory, but I haven't been convinced they want to in practice. Some of them do for sure, but it seems like they are still trying to do so professionally. This generation of students doesn't buy into the "professional" mentality. Lots of them have long hair and such that they'll only cut in order to make money, but would rather work for a company that doesn't care. The companies that don't care about traditional notions of professional protocols are the ones that are making the headlines. The one that is probably the most famous is Google. They put fussball tables in the middle of their office space. They have a whiteboard along one wall that's reserved for doodling. A friend of mine works (or used to) at a company called Quantam Leap and he said they took breaks by playing risk and using fussball to decide the outcomes of battles.

Environments that encourage having a life in addition to professional productivity are becoming important. Especially because it's been shown that workers are more productive if they can really relax and be a person while at work. If CIS is really interested in impressing students that they are important and encouraging them to see CS/IS as something more than just a way to make money but an interesting endeavor in and of itself, we're going to have to start sharing personally with them. I think that remodeling our foreboding space to encourage students to interact and a way to get faculty to stop being so serious as a part of that vision.

Anyway, that's just my opinion. Take it or leave. Cheers.

Most of my readers will probably consider the above to be self evident, but I'm mostly ranting about a specific bug I've encountered with the Google Maps API map I've put together for my church web site, newhopeks.org.

Try viewing that page in MSIE (5.5+ please, since that's what Google supports) and see what you get. (Well, it might be fixed by the time you read this, but if not...) If you're lucky, it'll just work. If you're not lucky, you got a box saying:

Internet Explorer cannot open the Internet site http://www.newhopeks.org/map

Operation aborted.

If you're especially unlucky, when you clicked OK, it took you to a page saying "The page cannot be displayed." (This error comes up even though you could see the map and everything up until you clicked OK.)

So, what's the problem? It turns out that if you have some JavaScript (the language Google Maps is written in) and you use a technology called DOM to manipulate the page (which Google Maps does) and you put the script in a <script/> tag inside of a <div/> tag or a table, MSIE freaks out some large percentage of time. I haven't even gotten the error consistently even on the same machine. This is complete idiocy. There's no way an error like this should have made it into production software and if it did, it should have been found and patched ages ago. This is what regression testing is for. Especially since this is a very well known error (just google for ""Internet Explorer cannot open the Internet site" "Operation aborted"" if you don't believe me).

The moral of the story is, don't use Internet Explorer. I recommend Firefox or Apple Safari or Opera or any of the Mozilla-based alternatives (except for Netscape as AO-Hell has ruined it).

Oh, well. Being the web developer who has to make his stuff work everywhere, I now I have to figure out how to move my script out of all the <div/> tags that make up the New Hope theme...

I have a few friends in the career of "design" and they simply cannot comprehend my affinity for my favorite editor, Vim. Now, I have proof for them that I'm not an idiot! A recent Slashdot article has pointed me to a blog by Paul Tyma discusses the usefulness of the keyboard as for exclusive use for those of us who spend most of their day manipulating text.

I write programs for a living and, dang it, I don't really need my mouse a lot of the time. My most common use of the mouse is when I need to browse the web. Otherwise, I can Alt-Tab/Apple-Tab/Apple-` my way around and use key strokes to do my most critical tasks. Anyway, Tyma is right on...except, his objection to the claim that Emacs was created to scare children is right out. Emacs was created not only to frighten children but also as a means of illegal torture for enemy non-combatants.

I'm constantly amazed at some of the really great ideas Apple chooses to ruin. I, like many other Apple groupies, picked up my copy of Tiger (i.e., that's the code name of the latest version of Mac OS X for the uninitiated). Anyway, there are some nifty features, there are some features that will be cooler once there are more plugins available, and there are a few misfires.

Mail's Smart Folders are one of those failures, IMO. A "Smart Folder" is like the "vFolder" of Evolution or the "Virtual Folder" of Mozilla or Thunderbird. The basic concept is that you create a search for some mail and then create a folder which always contains an updated search. This way, you can avoid the risk of filing a message inproperly and can make it possible to sort your mail without taking hours. Since I receive hundreds of email messages a day (sysadmins get a lot of log information and error notifications in the form of email, plus spam, plus help requests, plus personal messages, etc.), I was looking forward to this feature. I thought I might be able to replace my traditional folders. Well, I was wrong.

Basically, it works great, except that the available search options are too limited. If they had made it as useful as the "Rules" feature, it would have been enough. But, instead it's crippled to the point where it is incomplete . I've attached a comparison of the options for Rules and the options for Smart Folders. The considerably larger menu is for the Rules. There may be a solution I haven't yet found yet since Apple often does include undocumented or little documented features for the power users that buy the Mac sycophant magazines. However, it should have been a no brainer.

Apple, why!? Why cripple something that you've already added in another place? Why?

Grrr! I do not like spam. I've added CAPTCHA to my site (via this Drupal module) to prevent it. I got nailed by "online pharmacy" yesterday and I don't intend to have a repeat, again, ever. So, it may be annoying, but all comments on this site will, from now on, require you to pass the Turing test (i.e., Are you human?) by identifying a Captcha image.

Cheers,
Andrew Sterling Hanenkamp

Update: COLE EDITTED MY BLOG!? ---- wow, I can edit your blog!!! YAY

Okay CAPTCHA dies. Stupid Drupal module...yeah. Apparently there are session bugs.

It has been a crazy long time for me not to rant. But Mr. Rant is back and on a repeat of a previous one, no less. September of last year, I posted a not on my old blog---which has apparently stopped functioning...oh well. I'll dump its content into Andrew.Sterling.Hanenkamp.com Blog 3.0. Anyway, I mentioned a few work Pet Peeves. Well, the last few months have given way to a few new ones and I also wanted ot make a three other comments.

One: My job is completely bipolar. It is either way cool or way crap.

Two: My job is way cool because my boss is cool. Dr. Virg Wallentine is da bomb. The toys are nifty-awesome. My employees are easy to manage and are quite capable. I have flexibility in how the systems are managed, so long as I do my job well. My job is cool.

Three: My job is crap because flexibility disappears when things go wrong. Things go wrong about 50% of the time and when that 50% starts (and even ends) is completely unpredictable. I can be having a great day and someone pops in and says, "Is there something wrong with mail?" The great day becomes completely eclipsed by the ensuing hellish one. Which brings me to the second part of this, I just about only hear from folks when stuff breaks. That's the nature of the work; if you fix broken stuff for a living, nobody talks to you when it ain't broke.

Anyway, if you ever pop into my office and get the LookOfDeath(tm), it's probably because you just interrupted Two and I am trying to steel myself for a potential Three. Okay, on to my pet peeves...

But first, the disclaimer: I love my job despite its inherent frustrations. I really like helping folks out and this job is all about helping people. I also want to say that if you've made yourself a nuisance through any of these peeves, this is nothing personal—just don't do it again! Finally, these are mostly directed at students. Faculty and staff are allowed a bit more leeway in a lot of things because we just don't expect as much from you...er...umm...moving along. ;)

Here go...weeee...

1. Asking questions that are answered already. Search our site for docs before asking questions. I don't know how many times someone has sent me the message saying, "How do I connect to the Oracle server?" To quote Ren, "You eediot!" Check the FAQ on the support site. The User Guide and FAQ are quite helpful. Read them.
2. Replying to a resolved ticket to say, "Thanks." ARG! Thanks for more work. Now I have to resolve the ticket again. We work a thankless job, we'd rather keep it that way.
3. Subject lines that say nothing useful like, "HELP!" Help with....what? Or, perhaps worse, "Can't access mail." Subject lines should be helpful so we can get a quick idea on who should take care of it and it's urgency. I suggest never using the word "help" in your subject. Rather, say something meaningful. "Cannot download email via IMAP" "Mail error: Cannot contact imap.cis.ksu.edu" "Progress bar for sending email never goes away in Thunderbird" Each of these would probably be handled by a different student. Descriptions like this help my students know, "Ah, that's my problem." Otherwise, tickets tend to wait for me to assign them and that can take hours longer.
4. Subject lines that use lots of exclamation points, "I need access to X!!!!!!!!!!!!!!!" These messages tend to turn the systems staff into boiling cauldrons of rage. Angry geeks are frightening to other geeks, but probably a little comical to the rest of the world. Please, don't fuel the worlds fire to laugh at us more.
5. Over explanation. If you need something, tell us what the class or project is named and the faculty member involved. We don't need anything else, or we can ask for it. Giving us a 10 page dissertation on the exact nature of your needs usually just makes it harder for us to find what's being asked for.
6. Whining. I've gotten a fair share of nasty letters (probably 5 to 10 in the last year or so). Such hate-mail is whiney. We have policies, we have them for a reason. If you don't like them, you can either try and talk to us and figure out why we have the policies and use that information to make a suggestion, or you can deal. Screaming doesn't help the problem. Assuming that we're unreasonable power mongers is insulting rather than constructive (not that I would dispute that fact ;).
7. Asking for help without detail. My staff and I aren't prophets, psychic, or otherwise magical. Sending email stating, "Hi, I cannot connect to SSH" is meaningless. You've just guaranteed the maximum possible delay to getting any substantive help. What computer were you using? Where are you? Are you at home? Are you in Nichols? Are you in a campus lab? Are you on a corporate network? What program are you using to connect? Which host did you try to connect to? Did you get an error message? At what part of the process did it fail? Giving a complete explanation will give you the fastest response because we'll spend less time asking you these questions and can instead start fixing the problem.
8. Begging for help "ASAP" or giving us a ticket at noon saying, I need this by 2:30 pm today for an assignment. Sorry, dude. You should have planned ahead. We prioritize everything according to the same system, and your statement of urgency is not likely to be an important factor. The systems staff has a complicated list of tasks to do (usually between 100 and 150 at any given moment). These tasks are carefully prioritized by the significance and nature of the problem and based the role of the person who sent it. Unless your request is completely trivial, our turn over is probably going to be longer than 2 hours. My students are part time, and I have a class to teach. These factors interfere. Unless your task is critical or an emergency, we may not even get to in the same day. Large tasks, such as those that require changing policies or installing applications can take weeks. Unless you can convince the department to give me a much larger staff and we can somehow shunt aside the fact that this is a state University and we just take time because of flat beauracracy, you'll just have to be patient.
9. Sending us your username and password. Okay, this made it into my list this year because a student did this recently. I believe the joke immediately was something to the effect, "You start enrolling him in classes, I'm going to go take a look at his financial records." Don't ever send anyone your username and password. Your password is your personal secret. Giving that information away is simply not smart.
10. Stepping behind my desk without being asked. This is a personal pet peeve of mine. I like to have a certain amount of personal space and keeping you a few feet away at least makes me feel a bit more secure about typing various secret passwords into the machine while you are in the room. Please don't step behind my desk. My employees will make fun of me for this one I'm sure, but pride be damned, this annoys me.
11. Leaning over my shoulder or stepping within a couple feet of me to talk. This creeps me out. Again with the personal space. Step back, please. I'd really rather not know how recently you bathed.
12. Asking one of my staff for something and then asking me, or vice versa. This is the old trick every 4 year old tries: "Mom, can I do X?" "No." Go to the next room. "Dad, mom says that I can do X if you say it's okay." This is annoying. I have pretty good hearing when my door is open and my music is turned down. If one of my students says, do X to get your problem solved. Do that. Don't come to me and ask the same question again.

So that concludes this year's edition of "Pet Peeves." Thank you and good night.

There is exactly one aspect of Perl that annoys me and it's the same aspect that everyone makes fun of Perl for and it's exactly the reason I love Perl too: JAPHs. JAPH = Just Another Perl Hacker. The Perl world is filled with JAPHs.

I think Computer Science is divided into several overlapping camps. You have the mathematicians who think that CS who spend their time with theory and showing that programs and designs are provably correct. You have the software engineers who want to model everything and then do almost no coding and then use the model to verify the code. And then, you have the hackers who just like to play and want to figure things out on their own on their own terms.

I've come to believe I stand in the last group. I like to beat an idea to death and I'm never satisified with any result short of perfection. I don't have the patience for mathematics (nor the brain). I just don't think that way. And software engineering strikes me as more like a cross between bad wizardry, meteorology, middle management, and a pipe dream. Who wants to draw models according to someone else's idea of a good diagram? *co-UML-ugh* I've taken my SE and math classes and learned from both, but I can't really say I like either camp. Finally, I design in vi, I code in vi, I research with Google, and I use print-statements and logs to debug my code. I'm definitely in the "hacker camp."

The term "hacker" has received a lot of press and has been generally defined by the culture, but I think the term finds it's most appropriate meaning in it's original denotation: a dude that literally hacks away at something until he gets what he's looking for or just broken pieces. The term hacker has come to mean: a dude that likes to break into systems and read your email. However, that's more of the realm of the Script Kiddie. Anyway, I digress...

Back to Perl: The problem is that Perl code is extremely expressive. That's why us hackers like it. I feel like saying, "do this or do that", then I say , "this or that." Or, if I prefer "unless this do that," then I say, "unless (this) { that }." Or, "that unless this" or "that if not this," etc. I can think in Perl. I can design in Perl. Perl doesn't enforce very many policies, so I get to choose my own. That's Perl's beauty.

This lack of policy enforcement is also it's bane. As one of the CIS professors (in a Japanese accent) stated during my MS Presentation (just got my diploma in the mail today, btw), "This language is very strange to me. Why did you pick this?" I like it. I didn't tell him that, I gave him the BS about it being the language of the tools we already use. (BS only because I chose those tools partly because of their language, though RT is head and shoulders above any other similar tool I've taken a look at.)

The problem Perl has is that so much of the code written in Perl is simply hacked together. This means that CPAN (a great feature of Perl), has to be carefully sifted to find the module that fits your need. For example, if you need a tool for object persistence, there's Tangram, SPOPS, Class::DBI, Alzabo, DBIx::SearchBuilder, and a few others. Each has their own strengths, but all of them were written by hacker types with more or less lenience towards the math and SE mentalities. I'd say Tangram is the most mathematical and Alzabo is the most SE. DBIx::SearchBuilder is completely in the hacker camp. However, I think they all find themselves written from the JAPH perspective: hacking is a fact of life in Perl.

I'm looking forward to Perl 6. I think part of the reason so much Perl is so hackish is because the Perl 5 language is so hacked. Larry Wall built a simple tool for processing log files and then hacked on more and more features until he got to Perl 5. Now, we have hacked on object support. Hacked on packages. Hacked together subroutines. Hacked together regular expressions. All of it is brilliant, but the "cruft," as Larry Wall calls the entropy that hacking inevitably brings along, it has started to take over. Perl 6 should freshen the slate, especially since the development is very heavily design driven. Anyway, in another year or two when the preliminary versions of Perl 6 start coming out, we'll see.

Enough ranting....now for more hacking....

I've classified this as a rant, but this is an extremely mild one. The business of the start of semester has reached it's conclusion. I say this on the basis that the last "emergency" in RT was ended a couple days ago and I haven't been handed another emergency since.

Speaking of emergencies, I'll just use the rest of this blog to explain how the tech staff (namely me since I do the prioritizing) prioritize incoming requests. As most systems administrators can tell you, the job of sysadmin is a little difficult because there are usually more things to be taken care of than you are able to during than a short 70 year life span may allow for. As such, it is necessary to setup prioritization. Based upon the prioritization ideas of other systems administrator, I put together a policy with the following priorities:

• 80 - 89 : Emergency
• 75 : Routine
• 60 - 69 : Critical
• 55 : Unprioritized Fac/Staff Request
• 50 : Unprioritized Other Request
• 40 - 49 : Very Important
• 30 - 39 : Important
• 20 - 29 : Not Important
• 10 - 19 : Wish List

I've left the top and bottom of the ranges unspoken for in case I want to add something else or move things around a bit in the future.

Basically, tickets are assigned a starting priority of 50 or 55 based upon whether or not the ticket is posted to the normal help list or the special one given to faculty and staff. In the future, I think I'd like to make this assignment more or less automatic based upon the sender rather than the destination, but that's probably a "Not Important" task which will never get done. I then assign a ticket to some range and then I assign (or the someone takes) ownership to the ticket, the administrator responsible for following up on the problem. The assigned person may then adjust the ticket within the priority range as he sees fit (or she, should a woman ever apply and get the position; none have applied since I've been Coordinator).

If anyone has one or more Emergencies, they are not permitted to handle anything else until all action they are able to take action on all Emergency tasks. That is, the task might not be resolved, but everything that can be done to move towards resolution has been done. All other tasks should wait in lieu of an Emergency. Only the tasks that require the most urgency and have the highest importance are given Emergency status. They should never be ignored. Generally, only faculty or staff are able to make requests that reach this high of a status unless a request by a student will affect faculty or staff, or the entire student body.

The Routine tasks are generally simple tasks that are easy to complete. This is not always the case as I know Tyson has a number of Routines that have been in his list for a long time while he waits for me to complete more pieces of the account manager software. It's also a place to place notes about routine tasks that might not go away, but need to be reviewed on a routine basis (such as disabled accounts for printing fees and other reasons).

The Critical tasks have the same requirements as the Emergencies. However, they aren't so urgent as to cause Routine tasks to stack up unattended to. Emergencies are sometimes downgraded to Critical if they cannot be handled quickly. Most problems that have no known work around and bother faculty, staff, or a group of students are assigned Critical status. The "work-around" requirement is the major difference between Critical and Very Important. If a user has to work more, but can still get their work done, then it's Very Important. If this problem keeps a user from doing their work, then it's Critical. This is a troublesome rule because annoyances are (in some cases) worse than something without a work around. In those cases, I have been known to upgrade what would otherwise be a Very Important to a Critical.

The four remaining levels are treated as essentially part of the same category. These tasks can be worked on in any order, but the tasks at the top are preferred. The levels 20 through 49 are assigned by me to faculty, staff, and PhD student requests that aren't Critical, Emergency, or Routine, but we'd like to handle when we finish of those---which usually means late in the semester or during the summer. The levels 10 through 39 are assinged by me to all other student requests. The 40 through 49 is also the location for internal systems projects related to improving overall system quality and adding new features.

The Very Important stuff will probably be taken care of within a year. The Important stuff may be handled if we ever find time and it's easy enough. Anything else might happen, but probably won't in the foreseeable future (or might happen, but only as a side-effect of something else).

Anyway, for those who are interested, that's pretty much how we prioritize things. If you're task doesn't get taken care of for a long time and you think it should be, a large cash donation to hire more tech staff would be a move in the right direction.

I've just about had it with Microsoft Active Directory and the latest problem isn't even their fault. The saga that has been the CIS authentication system hasn't been a very fun one. However, in case someone else may be fighting the same problems out there let me elaborate.

When I started in as a systems administrator we had two parallel authentication systems: a Windows/Linux system and a Solaris one. The Windows/Linux one used Active Directory as the user database. Windows clients used the internal Windows authentication voodoo (mostly Kerberos) to do their thing. The Linux boxen used the SMB protocol to authenticate users. The latter had one major problem: case-insensitive passwords (FooBar == foobar == FOOBAR == fOoBaR). It's a "features" of the LANManager protocol dating back to Windows for Workgroups 3.11.

The Solaris authentication system was the real nightmare. Originally, we'd tried to make the Sun Solaris 9 boxen use Active Directory via LDAP or SMB to authenticate. Problem: Solaris 9 will not allow you to login to CDE (their front-end to X-Windows) without having an entry in /etc/passwd. (Barf.) That's actually a simplificiation, it'll work if you use Sun's own alternative to Active Directory, either their directory server or NIS+. Right or wrong, my predecessors decided that having two parallel authentication systems was superior to implementing NIS&emdash;I'm told NIS is a nightmare, but I have zippo experience with it to know one way or the other. At this point, nightmares of holocaust are starting to sound better to the holocaust I've been experiencing.

Anyway, the solution was that a central server would keep a master copy of /etc/passwd, /etc/group, and /etc/shadow. Then, every hour, that master database would be munged (based on access permissions of different machines) and distributed to all the other Solaris boxen. This means that any changes to account information must be updated in both Active Directory and the master files. This, inevitably, let to inconsistencies between accounts on Solaris and Active Directory.

To further aggravate the problem, Microsoft Windows Server 2003, which we started upgrading to around the time I joined the staff as a student in October 2003, increased security on its servers. This is a good thing, but eliminated our ability to run an SSH server on one of our 2003 servers. We used scripts on Solaris to create, modify, and delete accounts in both systems by using shell scripts on Solaris which then ran VB scripts on Windows 2000. With the move to 2003, this was becoming infeasible and the presence of 2003 on our network was destabilizing the abilities of the Windows 2000 domain controller. (Actually, it was probably the other way around as the Windows 2000 DC had a nasty habit of claiming ultimate authority over the 2003 boxen, so probalby the 2003 boxen were doing all they could to keep Mr. Clinton from taking over&emdash;an apropos 2000 server name, I think.)

Okay, so all of this put together led me to complete my Master's Degree with fixing this mess as my project. My solution, replaced the slowing dying scripts with a new system built of independent agents that each performed the tasks of maintaining the accounting systems. In the process, we decided to just retire the Suns rather than try and get them to work (especially since we could keep the Sun servers as SSH and other services function without the need for entries in /etc/passwd). Once all the Sun boxen were replaced with Linux boxen, I switched everything over to LDAP over TLS to perform authentication, authorization, and account profiling. My agents then created accounts and is, for the most part working fine.

Unfortunately, Microsoft has a problem. Using LDAP via TLS appears to cause serious problems with the LSASS module. After switching the Linux fleet (and the remaining Solaris fleet) to the new setup, Jefferson, our only Windows domain controller at the time, started crashing, frequently. This was a mess, so we hurried and grabbed a machine that had been slated for another purpose and made it a second DC to act as the new primary authentication server. Mostly, this just moved the crashes to the new server, Ford. Furthermore, sometimes both would still bite the dust if first Ford went down and the same problem was exploited on Jefferson simultaneously. This combo wreaked all sorts of havoc: users couldn't login during these times, Linux users already logged couldn't do some things because of the infamous "You don't exist, go away!" error, and the biggest problem was that any email sent to our mail exchanger during these times bounced, "User unknown." That's a bad message. It tells the sender something like, "yep, we fired him."

A solution was needed. So, we moved ahead to try and fix this problem by switching authentication to use Kerberos instead of LDAP over TLS. I figured that this solution had a better chance of succeeded because, technically, Kerberos is the protcol Windows uses internally and it follows a standard, RFC 1510. Being an IETF standard and one set in pretty solid language, it would be a difficult one to "embrace and extend" and it's one that probably isn't in Microsoft's best interest to do so with anyway. So, we switched to that. And, like magic, the Ford/Jefferson cycle of death has ceased.

However, a new problem surfaced. At first, it was pretty mild, but steadily grew until yesterday, Thursday, January 27, 2005, it became pretty unbearable. Every dozen or so times a person authenticated, authentication would fail and they would be asked their password. This became more frequent under heavy loads.

Having had loads of network problems and especially NFS issues, I thought it might just be that the communication load between the IMAP server and NFS server might be too heavy. About this time, we discovered that the mail server was only on a 100MB link (actually, worse, it was connected to a 4-port 100MB switch shared with three other computers!) I don't know who in the ancient past decided that was acceptable, but as Garfield would say, "that person should be drug out into the street and shot." It was not a good idea.

However, fixing this didn't solve the problem. Actually, following the reboot we performed after fixing this, it seemed to get much worse. It wouldn't let anybody in for nearly an hour yesterday. And yet, there were no problems in the logs accept a TEMPFAIL from Courier authlib and the Event Logs on Jefferson showed "Pre-authentication failure" for each user.

After several hours of staring at logs, searching Google, etc. I discovered that "pam_krb5" (the Linux Kerberos authentication module) is explicitly listed as not supported via the authpam module for the Courier IMAP server. DOH!

So, after all that work, I must, ironically, switch the mail server back to LDAP over TLS. It appears to be working to this point, but I've learned not to hold my breath.

Where do I go next? I see two possibilities. The reason I must use LDAP over TLS and not just plain LDAP is because I'm not stupid enough to make all my users pass their passwords across the network in plain text. Sending passwords out in cipher text is still a minor risk, but it's a far cry better than shouting, "Sniff my passwords in plain text!" Thus, I either need to authenticate without passing the passwords around (Kerberos) or I need to find another encrypted authentication protcol that Microsoft supports. Those are my two solutions: Kerberos and NIS.

But wait, I already tried Kerberos. Well, yes. However, there is another Kerberos solution. Instead of using Kerberos directly and explicitly, I can instead use LDAP without TLS with Kerberos. That is, LDAP has three modes of authentication: Simple, Kerberos, and SASL. Simple requires sending the password across the link. This is what we've done already. Kerberos isn't currently supported, as far as I can tell, with our Gentoo Linux distro. However, SASL authentication can be made to use Kerberos under the hood via it's GSSAPI authenticator.

Thus, I am now going to try and setup LDAP via SASL via GSSAPI/Kerberos to perform authentication. Maybe, this will work. Maybe not. If not, I'm going to give the Microsoft NIS server a try, nightmare or not, this dream is already bad enough, why not?

Not trusting at this point that anything will work, I can set up an independent KDC on Linux to perform authentication by and then, I'll just make Windows trust that KDC and use that as the Windows authentication system. If I can't get this to work, the only solutions left require spending lots of money (explicitly this time, rather than in the form of my time). I can either beg Microsoft to come look at our problem and fix it or I can decide Microsoft is full of it and replace it altogether with something else...that something else would probably have to be Novell NetWare. I'd really rather it be NetWare anyway, but I don't really want to run a NetWare server without training, it costs us a lot more since Microsoft practially gives us their software, and the changes required to make the switch make my head hurt.

I already work too much and already feel like I've wasted half my life fixing this problem. As I like to say during times like this: "I hate computers." Maybe I should accelerate my plans to go into seminary because problems like this will eventually eat me alive.

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.