Do we do a disservice to young sysadmins by teaching them important rules of thumb as if they were incontrovertible truth?

When I was starting out, I heard a lot of these, especially in security. For example, "a login server is always crackable". I was dubious, because I didn't understand the complex thought being expressed. What I heard was something like: "There are these invisible über-crackers who can take over any machine, any time, just give them a login and they'll get root, so you might as well give up and stop offering login service. What? Your employer won't let you stop? Too bad, you're just screwed, and you're probably a bad junior sysadmin for not threatening to quit over this."

I've been reading with horrified interest about the state of collapse in Zimbabwe. I've heard several public health experts remark that the rising deaths from cholera are a sure sign of the total collapse of the state of Zimbabwe.

Cholera is a disease that is easily prevented with modern sanitation, and even when it breaks out, is easily stopped with hydration and inexpensive medicine. For people to be dying on a mass scale from cholera shows that the state has completely failed.

Not to minimize such a horrific situation or equate it to the economic situation we're facing here, but it did get me to thinking: what are the tell-tale signs of an IT organization in collapse from neglect or lack of funding? I have my own thoughts, but want to get some discussion going first. What do you think are sure signs that an IT organization is collapsing?

My old MacBook Pro (a two-year-old refurbished 2.16 GHz Core 2 Duo with 2 GB of RAM and 120 GB hard drive) had developed problems with its left fan some weeks ago. It was noisy (like, outboard-motor noisy) and the internal temps were alarmingly hot (often exceeding 200° F). I knew I needed to get it repaired, but I use my laptop as my primary development machine, carting it from home to work, and just couldn't be without.

macallan wrote:

As an educational IT guy, I am frequently asked about when to buy a new machine. My advice is always: buy when you need a new machine, and get the "best" one for your needs at that time. There are lots of separate discussions about what the "best" machine for any given user will be, but I never advise people to wait more than a week, since there is always something better[1] coming soon[2]. Most people are constrained by the lead time on a new machine, or some other deadline, so I say just buy something already.

1] that's what marketing calls every new thing
2] marketing will have you believe it's going to be here tomorrow

I think that's right; when I'm asked about "what computer should I buy?" I generally tell folks it's best to buy based on:

• When you need it, at the latest
• What you need, at a minimum
• What you can afford, at a maximum

With CES and MacWorld behind us, I've noticed something: people who last month were saying, "don't buy one now, they're announcing new models soon" are now saying, "don't buy one now, let them shake out the bugs first".

Suppose announcements were more frequent than they are now. Is there a point at which product announcements would become so frequent that such people would never buy one? Maybe they'd start buying models as soon as they're announced. Or would they buy the current (soon-to-be prior) model only once they hear an announcement is coming?

I saw a bit recently on TMZ about Hillary Clinton complaining about her TiVo deleting shows she wanted to watch while saving things she's not interested in. I don't know if it's a true story or apocryphal, but it illustrates something I've been thinking about for awhile: what makes someone a "techie"? It seems to me there's a very big divide between technical and non-technical people, but teasing out what those differences are isn't as easy as recognizing that the divide exists.

I think this story illustrates one of the more obvious differences between techies and non-techies. The difference is this: techies implicitly understand the difference between content and metacontent. Techies understand it so implicitly, that you can be forgiven if you're a techie for scratching your head and saying, "I don't know what you're talking about". Because this understanding is so deep and so automatic that we don't even think about it, and we don't even realize we understand it. But we do.

Something—I'm honestly not sure what—has changed in Mac OS X Leopard in a subtle way that has totally derailed my workflow for making presentations involving code samples.

I give a lot of Keynote talks that are very heavy on code samples. For years, I've had a workflow for creating code-sample slides that's worked pretty well for me:

First, I create a directory for the slide show. Inside is my Keynote presentation, and subdirectories for ancillary materials. The relevant ones here are code-samples/ and images/.

In the code-samples/ directory, I create little files containing the code fragments. I edit them in Aquamacs Emacs (a very nice Aqua GUI for GNU Emacs) which gives me code syntax highlighting:

System administrators are busy people, and folks who volunteer for LOPSA tend to be busier than most.

This causes problems when we try to manage projects with volunteer help, because sometimes people get snowed under with more important things. It's unreasonable for us to expect LOPSA volunteer work to come before work and family commitments. But yet, the projects still need to get handled in a timely manner.

I've decided I'm going to start putting a "pong-by" date at the bottom of email requests to volunteers. What that means is, if I don't get a response by that date, I'm going to assume that the answer is "no" and move onto someone else. No hard feelings—I don't know whether you've fallen into a hole, you thought you'd have time and now don't, you're on vacation and not reading email, or what—I'm just going to find someone else.

So if you've gotten an email from me and see "Pong by January 1", now you know what that means. :)

Feel free to use this yourself. http://lopsa.org/pong redirects here.

--
Trey Harris is President of LOPSA. His blog entries do not represent the views of LOPSA, its Board, or its membership.

I've been thinking recently about what the term "mentoring" means for professional sysadmins.

I've usually said that I'm "self-taught" in system administration. Most sysadmins I know say the same thing. I say this because I didn't take any classes on sysadmin, and in the technical aspects, at least, I was self-directed in my first few system administration jobs. My supervisors and coworkers may have given me hints or things to look at, but I didn't have the opportunity to watch them work directly.

But I'm not really "self-taught", certainly not in the way that a musician might be "self-taught" or a cook might be "self-taught". You can imagine someone teaching themselves to play the piano, for instance, by sitting down at the keyboard and pressing different keys in various ways and observing how the piano sounds, or someone trying cooking ingredients in different ways and tasting the results. But can you imagine someone sitting down at a Unix prompt and typing random keystrokes until they learned how to administer a machine?