Real Admins are Unix Admins? Sure

Bash terminal in Mac OS X

There are some IT tropes that have been around for so long one takes them for granted.  There is a belief that Unix machines, including Linux, BSD and Mac OS X, are better than anything.  Not only is Unix better than Windows, a fact taken as a given in IT, but those who manage them are also better, smarter and more logical than Windows admins.  Not to mention more “pure”  than other admins.  (Richard Stallman is perhaps the leading avatar for this belief, whether he believes it or not.)

InfoWorld, apart from Bob Lewis, has meant IT yellow journalism for quite some time, ever since their Save XP campaign and Randall Kennedy’s supposed revelations last year.

Now, Paul Venezia is telling us about “Nine Traits Of The Veteran Unix Admin”.  I thought immediately of that Dilbert strip with the bearded Unix guy (and he is almost always male) who gives him a nickel and tells him to “buy a better computer!”

His points can only make sense if he is tongue-in-cheek, or else he has never done any IT for anyone.  Going down some of them:

Veteran Unix admin trait No. 2: We use vi, not emacs, and definitely not pico or nano
While we know that emacs is near and dear to the hearts of many Unix admins, it really is the Unix equivalent of Microsoft Word. Vi — and explicitly vim — is the true tool for veteran Unix geeks who need to get things done and not muck about with the extraneous nonsense that comes with emacs. Emacs has a built-in game of Tetris, for crying out loud.

I’ll grudgingly admit that the bells and whistles in vim such as code folding and syntax highlighting might be considered fluff, but at the end of the day, real Unix work blends extremely well with vi’s modal editing concepts. In addition, its svelte size and universal portability make it the One True Editor. Thanks Bill, thanks Bram.

I’ve used a lot of different editors in nearly 30 years of IT, on many different systems. 

I’ve used some very primitive line editors;  many of you may remember EDLIN in MS-DOS, but editors like it were also common on mainframes such as the CDC Cyber 170 I used in college.  I remember using TECO, Emacs’ predecessor, on the PDP-11 machines I had access to, and was delighted to use the full-screen version that was available for the VT-52.

When I got my first Net access via a Unix shell, I learned Emacs and that’s all there was to it;  no arguing, no fuss.  If I had to learn Unix to be on the net, then there it was.  On our Amigas at SATV, Memacs, the Amiga port of this editor, was the one to use.   Other Linux distros I have used have had vi, vim, nano, and pico, to say nothing of whatever GUI editors came with Gnome, XFCE or KDE, which are all a blur to me.

I didn’t care what editor I needed to use just as long as I could get it to edit whatever config file I needed edited at the moment.

You care that much about vi to make that strong a point?   Get a life.

Veteran Unix admin trait No. 3: We wield regular expressions like weapons
To the uninitiated, even the most innocuous regex looks like the result of nauseous keyboard. To us, however, it’s pure poetry. The power represented in the complexity of pcre (Perl Compatible Regular Expressions) cannot be matched by any other known tool. If you need to replace every third character in a 100,000-line file, except when it’s followed by the numeral 4, regular expressions aren’t just a tool for the job — they’re the only tool for the job. Those that shrink from learning regex do themselves and their colleagues a disservice on a daily basis. In just about every Unix shop of reasonable size, you’ll find one or two guys regex savants. These poor folks constantly get string snippets in their email accompanied by plaintive requests for a regex to parse them, usually followed by a promise of a round of drinks that never materializes.

Regexs have been a part of Windows from at least VBScript, and are fully included in .Net and PowerShell. Just to say, although I know it is not supposed to count.  It’s worth noting that I studied compiler design in college in 1987 and regexs are one of the first topics covered in the Dragon Book.  

I can’t imagine what specific problem is so simple that you can change every third character in a 100,000 line file except when followed by four and not run into problems with that scale, regardless of what the solution is programmed in.  Regex or not, how would you verify the output?

But, derrrp, I stupid Windows guy.  I no know regexs!

Veteran Unix admin trait No. 4: We’re inherently lazy
When given a problem that appears to involve lots of manual, repetitive work, we old-school Unix types will always opt to write code to take care of it. This usually takes less time than the manual option, but not always. Regardless, we’d rather spend those minutes and hours constructing an effort that can be referenced or used later, rather than simply fixing the immediate problem. Usually, this comes back to us in spades when a few years later we encounter a similar problem and can yank a few hundred lines of Perl from a file in our home directory, solve the problem in a matter of minutes, and go back to analyzing other code for possible streamlining. Or playing Angry Birds.

I consider myself lazy in that way too.  Funny though, that it’s a virtue.  You’d never know it reading Slashdot.  To hear some tell it, when Unix guys are lazy they’re brilliant—even when they’re bad lazy with planning—when Windows guys are good lazy (time-saving strategic laziness), they’re stupid.

Veteran Unix admin trait No. 6: We generally assume the problem is with whomever is asking the question
To reach a certain level of Unix enlightenment is to be extremely confident in your foundational knowledge. It also means we never think that a problem exists until we can see it for ourselves. Telling a veteran Unix admin that a file “vanished” will get you a snort of derision. Prove to him that it really happened and he’ll dive into the problem tirelessly until a suitable, sensible cause and solution are found. Many think that this is a sign of hubris or arrogance. It definitely is — but we’ve earned it.

Snort!  I think that is a trademark in the Linux community, WorksForMe!   Now, when a Unix admin (like Mr. Venezia?) finds something genuinely wrong, does he go to the user who raised the original question and apologize?  Naw, he’s always right;  it’s everybody else who’s antisocial!

Veteran Unix admin trait No. 7: We have more in common with medical examiners than doctors
When dealing with a massive problem, we’ll spend far more time in the postmortem than the actual problem resolution. Unless the workload allows us absolutely no time to investigate, we need to know the absolute cause of the problem. There is no magic in the work of a hard-core Unix admin; every situation must stem from a logical point and be traceable along the proper lines. In short, there’s a reason for everything, and we’ll leave no stone unturned until we find it.

To us, it’s easy to stop the bleeding by HUPping a process or changing permissions on a file or directory to 777, but that’s not the half of it. Why did the process need to be restarted? That shouldn’t have been necessary, and we need to know why.

Naw, that Windows I use is made by pixies, and is even run by pixies.  As I’m writing this, some pixie is messing around with one of my GPO’s at SATV and I have only spent a few hours trying to get down to said cause which is driving me nuts right now.  Hur hur I derrrrrrrr!

Veteran Unix admin trait No. 8: We know more about Windows than we’ll ever let on
Though we may not run Windows on our personal machines or appear to care a whit about Windows servers, we’re generally quite capable at diagnosing and fixing Windows problems. This is because we’ve had to deal with these problems when they bleed over into our territory. However, we do not like to acknowledge this fact, because most times Windows doesn’t subscribe to the same deeply logical foundations as Unix, and that bothers us. See traits No. 5 and 6 above.

Facepalm.  ROFLOL!

The Unix-Haters Handbook is very old, but sadly, it is not much less relevant than it was in the day.  It’s pointless to  go over it in length, but it does have something important to say still:  Systems like Unix, like Windows, like everything, are designed with assumptions and use-cases.  Unix has escaped its research origins and has far surpassed its original reach, yet its practitioners are still stuck in the 1970’s, when they thought it was God’s gift to computing. 

It was.

Then.

As if there weren’t other systems out there long before Bill Gates used his first computer.  As if I’m going to spend hours in awk picking apart some CSV file or process list when I have built-in objects in Powershell that can give me way more discoverable information than bash could even provide on a good day.  I once used a very nice source-level debugger on the Cyber that could handle multiple languages including assembly.  30 years ago! It was something I have  never seen on PC’s until very recently.  It wasn’t on Unix at the time, either. 

From what I’ve seen in passing in Slashdot, most Slashdotters, who seem also to overlap the Unix admins that Mr. Venezia talks about, are rather incurious about Microsoft.  Except when the next security exploit comes out, in which case they know everything there is to know about Microsoft and security (supposed to be an oxymoron, right?)

Otherwise, the Unix administrator who really does know Microsoft, and knows the flaws of his own application software too well, might not be so arrogant.

But Unix admins wouldn’t be real admins if they weren’t arrogant alpha-hotels who hated the people they worked for, would they?

I say that tongue-in-cheek, Paul.  Really.