Paul Venezia over at InfoWorld sent me a valentine last week in the form of his entertaining blog post Nine Traits of the Veteran Unix Admin. His post is witty and rings of truth, but the points of conflict we have are places where I tend to think that Venezia has a strong opinion and anecdotal experience instead of any real metric for success in identifying a *nix vet.
Veteran Unix admin trait No. 1: We don’t use sudo
Venezia has a point. If you don’t know what you’re doing, you shouldn’t be in /etc/sudoers anyway.
Veteran Unix admin trait No. 2: We use vi, not emacs, and definitely not pico or nano strong>
Here’s where a personal opinion jumps on into Venezia’s argument. I happen to be a KDE fan, and as a result, I tried out Kate several years ago. I am a HUGE fan. Kate is slim, has tabbed file access, syntax highlighting, and just barely enough features to be functional and tiny. I write almost all my code in Kate now. I think the real question Venezia should be addressing is whether a *nix vet uses an IDE or writes their code hardcore. I can and do write scripts or styles or for-loops on a beer-stained cocktail napkin; why on earth would it matter what interface I use to get my code into a compiler?
Veteran Unix admin trait No. 3: We wield regular expressions like weapons
My favorite use of regex is to identify files where two words appear within a certain character distance of each other. I have a very associative memory, and if I am looking for a file in the depths of my memory as well as a hard drive, I will often use
the proximity of two words as the key in the KV pair of my mind DB. I do agree that regex works like a charm, but specializing in it can be just as isolating as Venezia suggests.
Veteran Unix admin trait No. 4: We’re inherently lazy
He’s dead on the money. Venezia’s claim that we will take days or weeks to solve a problem in order to never have to deal with it again is blindingly accurate. However, I think he hasn’t gone quite far enough. ‘Lazy’ is a good word for it, but ‘insatiably curious to the point of distraction’ would be a better way to put it. I tend to think that solving a problem is a two-pronged process; writing the bash script is the second part. The first step is LEARNING what you didn’t know before. I wrote scripts to divide text files with very specific logic, but writing the script in the end only took a minute. It was learning what I needed to do and debugging, as well as committing the process to memory, that took five days.
nVeteran Unix admin trait No. 5: We prefer elegant solutions
Quod Erat Demonstrandum
Veteran Unix admin trait No. 6: We generally assume the problem is with whomever is asking the question
“Many think that this is a sign of hubris or arrogance. It definitely is — but we’ve earned it.”
Venezia is right in what he says above, but again, he hasn’t gone quite deep enough. We DO assume that the problem is with the person asking the question, because barring hardware failure, computers do not err. That means that if something isn’t working and we can’t figure out why, we believe the problem lies with us and our lack of knowledge or experience in solving that problem. The right to believe that the problem lies with the person asking the question does NOT come with the right to belittle that person, or 97% of the time, we’d be self-immolating over our keyboards. Instead, this statement is a comprehensive acceptance of
responsibility for learning the answers ourselves, and helping n00bs in the same way we ourselves were helped on the Yellow Brick Road to *nix guru-hood.
Veteran Unix admin trait No. 7: We have more in common with medical examiners than doctors
No. We have more in common with medical researchers than doctors. We want to know why things work, and to come up with new solutions no one has ever seen before. We do need to know the whyfors of the problems we’ve already solved, and there are very few things that irritate me more than making a code change that resolves a bug…but not knowing WHY it fixed the problem. I will spend days trying to learn why my code change worked, and barring direct instructions to do so, I will not put that code into production, because if I don’t know why a code change worked, I cannot guarantee that there will not be secondary issues that arise from my use of code I don’t fully understand.
sudo rm -R /home/tarahmarie/.kde may
fix my SQLITE problem with Amarok, but it creates more problems than it solves, to say the least.
Veteran Unix admin trait No. 8: We know more about Windows than we’ll ever let on
Slight disagreement here. I have no problem knowing Windows. Getting inside the guts of a Windows box is harder than a nix box, but there are a few tools that absolutely rule on Windows. Absolutely number one is PowerShell. PowerShell is completely integrated with the .NET architecture, and you can instantiate classes directly from the command line without wrapping them in a script. This is one powerful hammer in the toolbox. You can actually pipe fully instantiated objects rather than passing a character stream that’s then interpreted, as you would in bash. Regardless of that, I want to use the best tool for the job. Call it ‘OS zen’ or whatever you like; I’d rather just get the job done, and that may involve me learning more
PowerShell rather than trying to change the institutional inertia that causes no other option than Windows to be considered.
Veteran Unix admin trait No. 9: Rebooting is almost never an option
sudo service apache2 restart
Who needs to reboot?