Forgot your password?
typodupeerror
Unix Technology IT

Common Traits of the Veteran Unix Admin 592

Posted by Soulskill
from the no-tolerance-for-stupidity-and-epic-beards dept.
snydeq writes "Deep End's Paul Venezia offers a field guide to understanding your resident Unix veteran, laying out the nine traits common to this grizzled, hardcore set. From not using sudo, to wielding regular expressions like weapons, to generally assuming the problem resides with whomever is asking the question, each trait is key to 'spotting these rare, beautiful creatures in the wild,' Venezia writes. 'If some of these traits seem anti-social or difficult to understand from a lay perspective, that's because they are. Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic.'"
This discussion has been archived. No new comments can be posted.

Common Traits of the Veteran Unix Admin

Comments Filter:
  • by theillien (984847) on Monday February 14, 2011 @10:04PM (#35205910)
    Don't forget the neck beards.
  • vim? really? (Score:5, Insightful)

    by shitetaco (1954742) on Monday February 14, 2011 @10:05PM (#35205916)

    vim? svelt? Puhleez. When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.

    • by c0lo (1497653) on Monday February 14, 2011 @10:10PM (#35205952)
      Butterflies [xkcd.com] - and no, emacs is not an option, unless you code the command yourself and store the code in your deepest vault.
    • Re:vim? really? (Score:5, Insightful)

      by Culture20 (968837) on Monday February 14, 2011 @11:12PM (#35206396)

      vim? svelt? Puhleez. When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.

      That's like saying Real Unix vets still use telnet and rsh to remotely administer machines. Sometimes it's nice to be able to move up and down lines without having to leave edit/write mode. vim is used by Real Unix vets who have kept up with the times, just like ssh. Only washed up has-beens don't learn to eventually use better tools.

      • Re:vim? really? (Score:5, Insightful)

        by eln (21727) on Monday February 14, 2011 @11:54PM (#35206624) Homepage
        I have to go with the GP on this one. It's not that vim is inherently bad, it's just that it's *unnecessary*. It includes tons of features that an old-school admin has no use for. Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim), but we rarely use the features that separate vim from vi. Moving in and out of edit mode is second nature. Hell, even using the arrow keys to move around is a needlessly inefficient waste of motion, since the arrow keys are usually far from any other useful key on the keyboard. The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.

        The comparison to ssh is inaccurate as well. We use ssh because ssh gives us clear security advantages over telnet and rsh, and allows us to use one tool where we previously needed two. Any Unix admin worth his salt, no matter how long and luxurious his neck beard, will gladly upgrade his tools to improve his own efficiency or increase security. SSH does both of those things, while vim does neither.
        • Re:vim? really? (Score:4, Insightful)

          by TheRaven64 (641858) on Tuesday February 15, 2011 @05:30AM (#35207816) Journal

          The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on

          I second the other poster's WTF here. It's one thing not to rely on the advanced features of vim - after all, the Single UNIX Spec only mandates vi, so it's the only thing you can guarantee being available, but it seems crazy to not take advantage of them when they are available. Do you also turn of auto-indenting and multi-level undo so that you can spend more time typing and less time actually being productive?

        • by skids (119237)

          Any Unix admin worth his salt, no matter how long and luxurious his neck beard, will gladly upgrade his tools to improve his own efficiency.

          Which is why, as a seasoned UNIX admin, I remove all vi from my systems (to prevent broken programs that do not use $EDITOR or /etc/alternatives from dropping me into vi) and use emacs exclusively. Or jove on small systems.

          C-X-( and M-x yank-rectangle improve my efficiency vastly for the one-off scenarios which it is not worth scripting.

          Original article author apparently has never met seasoned admins of the emacs species. Specist! :-)

    • Re:vim? really? (Score:5, Informative)

      by Ungrounded Lightning (62228) on Tuesday February 15, 2011 @12:06AM (#35206666) Journal

      When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.

      Indeed.

      A particularly nasty vim change is that:
        - In vi "u" undoes the last change - even if it was another "u". Hit "u" repeatedly and the screen flips between with and without the last change, making it blink. Useful if a multi-change command may have done something goofy.
        - In vim "u" backs you through a history of changes. Handy sometimes. But to redo you have to "control-r". Forget about blinking the screen to use your eye's motion sensors to spot the trouble. Also watch out for accidentally undoing a bunch of changes just before you close and exit. Oops!

      Geez, guys. If you want to add new stuff (like a history to go backward through), don't change the behavior of an existing command. Add another, or at least make it configurable - preferably with the default the old behavior.

  • RegEx? (Score:5, Funny)

    by Mr. Sketch (111112) <`moc.liamg' `ta' `hcteks.retsim'> on Monday February 14, 2011 @10:06PM (#35205918)

    wielding regular expressions like weapons

    Reminds me of:

    Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
    - Jamie Zawinski

    • by BitterOak (537666)

      wielding regular expressions like weapons

      Reminds me of:

      Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. - Jamie Zawinski

      I think the point is that what separates the true Unix gurus from the wannabees are that the gurus have no problems with their regular expressions.

      Still, it's sad though. I remember the day when regular expressions were considered basic knowledge, and what distinguished the true Unix gurus was the ability to read and write sendmail configuration files by hand.

    • by jaymzter (452402)

      Some people, when confronted with a Unix problem, think 'I know, I'll use sed'. Now they have two problems.

      From the Unix Hater's Handbook.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Beware, Cthulu awaits [stackoverflow.com].

    • by jomama717 (779243)
      I know you're joking (and it's funny), but I'm inclined to jump to the defense of using regex to solve problems - take this example:

      Requirement: Long URLs must have a slash between the domain and the path component. For example, http://example.com?query=parameter [example.com] is invalid, and instead should be formatted as http://example.com/?query=parameter [example.com]

      I challenge you to find a non-regex solution as nice as this:

      url = url.replaceFirst('(://[^/]*)\\?','$1/?');

      Java, in this case - but that's another beau
      • I've also heard regex solutions, while nice and pretty sometimes, can also be very inefficient especially if you are doing something like url parsing.
        • by jomama717 (779243)
          That's very true, if it is ultra-high traffic code I wouldn't use regular expressions for much, although you can improve performance a bit (even in the above example) by pre-compiling the pattern and using a static reference to it. How many times though do you run across terrible abuses of chained/nested substring calls (usually without bounds checking) to accomplish things like the above? This is just one area where regex is a godsend.
      • by wvmarle (1070040)

        I'd say your solution is as nice as it's readable!

      • Re:RegEx? (Score:4, Informative)

        by vux984 (928602) on Monday February 14, 2011 @11:33PM (#35206522)

        Requirement: Long URLs must have a slash between the domain and the path component.

        The generic URI syntax consists of 4 main components... ://?

        The path component is optional, and the authority component can be terminated directly by a ?. Per RFC 2396.

        3.2 The authority component is preceded by a double slash "//" and is
              terminated by the next slash "/", question-mark "?", or by the end of
              the URI.

        So I am unclear sure where your requirement to insert a slash actually comes from.

        I challenge you to find a non-regex solution as nice as this:

        Given you are using java, using the URL class. I would expect url.toString() to emit a well formed URL, with the various components separated to spec.

        I suppose you could also construct the string manually from the url parts in a straightforward manner... something along the lines of...

        urlstring = url.getProtocol() + "://" + url.getAuthority() + "/" + url.getFile();

        • by vux984 (928602)

          Follow up to fix this as /. ate my angle brackets...

          The generic URI syntax consists of 4 main components...

          [scheme]://[authority][path]?[query]

        • by jomama717 (779243)
          The requirement actually comes from a popular URL shortening service (I don't know why I'm resisting identifying it, but I am). The "url" variable is a plain String generated in one of many other parts of the code - these other parts guarantee that the URL is valid by the spec, but as you point out this particular requirement is beyond the spec. And anyway, to gain the advantage of the URL class's built-in validation the string would have to be used to instantiate a URL instance, and a failure to validate
          • The requirement actually comes from a popular URL shortening service...

            Which, of course, makes the service incorrect as RFC 2396 says [/?] are valid authority delimiters and just makes it their "requirement" ... Just sayin'. From the RFC:

            The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI.

    • All I know is that when first saw regular expressions, I thought my modem had been disconnected and I was about get that damn "CARRIER LOST" signal again. Then I realized I was using Ethernet. After changing my shorts, I realized how [regex] I was.
  • Hmmm (Score:3, Insightful)

    by mmj638 (905944) on Monday February 14, 2011 @10:07PM (#35205926)

    Lemme just email this to all my friends with the subject line "If you know someone like this pass it on LOL"

  • by mgichoga (901761) on Monday February 14, 2011 @10:08PM (#35205930)
    Real Unix admins would be reading this post in lynx.
  • Guilty as charged to all nine counts...

  • by 140Mandak262Jamuna (970587) on Monday February 14, 2011 @10:10PM (#35205950) Journal
    We also throw a nickel at the rookie Windows sys admins and tell them, "Here's a nickel. Get a real operating system, kid."
  • by Ynot_82 (1023749)

    We will never (ever) admit we are at fault

    If an off-by-one error results in the monthly report generation failing if the last day of the month falls on a saturday, then we'll quietly fix the code and tell the user this was a one-off problem most likely caused by incorrect user input but if it ever happens again to let you know

    • by nedlohs (1335013)

      That's what developers do. Unix admins just say "the job ran as scheduled and did whatever the developers programmed it to do".

    • Long before you become "grizzled", you learn time. You learn calendars. You think in UTC. All the jobs happen on UTC. With the correct leap years plotted out for the next thousand years.

      That's because you ran into that problem during your development and you learned it and kept your code.

      • by scdeimos (632778)

        Long before you become "grizzled", you learn time. You learn calendars. You think in UTC. All the jobs happen on UTC. With the correct leap years plotted out for the next thousand years.

        And then along come leap seconds, thus enhancing your grizzledness.

  • Stupid (Score:3, Insightful)

    by nedlohs (1335013) on Monday February 14, 2011 @10:26PM (#35206074)

    Unless unix veteran is a code word for idiot of course.

    Take #9: "Our thinking here is there's no reason why a reboot should ever be necessary other than kernel or hardware changes, and a reboot is simply another temporary approach to fixing the problem.". When a run away program fills the disk or sets off the OOM killer then after fixing the problem itself rebooting is the obviously wise thing to do - who knows what random proceess got put in a bad state by the resource exhaustion best reboot and get everything into a known good state.

    And of course have fun when the machine does need to be rebooted for a "kernel of hardware change" and some vital service doesn't restart because no one checked that the damn init script was enabled.

    • Re:Stupid (Score:5, Insightful)

      by nonguru (1777998) on Monday February 14, 2011 @10:44PM (#35206198)
      Not stupid at all. This guy is into root cause analysis as a process of understanding faults and finding lasting solutions. (See reference to "bandaids".) Covers up your tracks until the next crash. A fully functioning fault-free system working as designed should not require a reboot except for the cases outlined. Unless unix systems aren't as reliable as people like to assume...
      • by ebuck (585470)

        I used to routinely work on systems that had three or more years of uptime. We didn't like that, but not because rebooting had any value. We didn't like the fact that they weren't applying their operating system patches at least yearly.

    • Re:Stupid (Score:5, Insightful)

      by thogard (43403) on Monday February 14, 2011 @10:49PM (#35206228) Homepage

      Real sysadmins know when things get in odd states and can restart those things without rebooting.

      Of course reboot tests are required to make sure the box will come back up correctly but those are to reset things, they are part of system testing.

    • by matt-fu (96262)
      Just because you *can* leave your system up for five years straight doesn't mean it's a good idea.
  • by C_Kode (102755)

    That was creepy to read. I'm guessing a few of you will understand what I mean.

  • Rebooting (Score:5, Informative)

    by pz (113803) on Monday February 14, 2011 @10:43PM (#35206196) Journal

    The reason that Unix SAs don't like to reboot is deep seated in the history of Unix running decades ago on hardware for which a reboot cycle meant interrupting potentially dozens of people all sharing the same machine for a sequence that might take 10 to 20 minutes if nothing went wrong. Rebooting was correctly viewed as something to avoid whenever possible.

    Windows was not engineered for long uptimes until NT 4.0 and is a johnny-come-lately OS in comparison. Windows didn't run on significant (read: capable of simultaneously supporting more than one user in a non-trivial way) hardware until, what, 1994 or 1995? Meanwhile Unix and its intellectual antecedents had been supporting multi-dozen-user installations for nearly three decades.

    When there's only one user, rebooting isn't nearly as big a deal as when there are 20, 30 or more. That dichotomy alone drove the reliability of Unix, and the the lax attitude of Windows.

    Personally, even though rebooting my desktop Linux computer with it's fast processor, SSD and RAID disks, takes well under a minute, I still don't like doing it. There's something wrong: It shouldn't need to be done. If I'm rebooting for a non-hardware related issue, it's because I'm being sloppy.

  • by krray (605395) on Monday February 14, 2011 @10:44PM (#35206200)

    You've already ticked me off by wasting my time.
    Link to the print version next time: http://www.infoworld.com/print/151276 [infoworld.com]

    I prefer my password. It's just a PITA that changes daily. alias s='sudo -i'
    Same result as "su -" but with less typing.

    Yes, root's password was set / changed. It's insanely long. I like it that way.

    PS: this /. interface sucks now :wq

  • You're not a real unix admin unless you've written a compiler in awk or emacs in sed.
  • The article did not mention:
    • luser [wikipedia.org]
    • LART [catb.org]
    • clue-stick or clue-by-four
  • http://www.theregister.co.uk/odds/bofh/
  • The only admins I've seen that are allergic to rebooting are basically children who are new to a paying job. Most experienced Unix admins I've known have no problem with rebooting, when they feel it's the most appropriate option. They're pragmatic, above all else.

    • by tnk1 (899206) on Monday February 14, 2011 @11:42PM (#35206566)

      True. I will reboot a host without a second thought if a specific type of issue comes up. Root cause analysis is great, but when you're in production, the host really needs to be running. You can figure out the RCA from the logs later on, if need be.

      However, most issues with a box can easily, and much more quickly, be fixed by simply restarting specific processes. I've had plenty of hosts stay up for years at a time with nothing else needed but to occasionally restart some processes. And that is the way it should be. Rebooting isn't some magical maintenance cycle where the oil gets changed and the hamsters are replaced, its just a wipe of the RAM and reload of the OS to an initial state. It doesn't fix hardware errors, bad code or poor planning.

      Unfortunately, most of the time, the order comes from someone who doesn't know what they are doing. In that case, as long as it doesn't make things worse, if it takes longer to convince them to not reboot the host than it does to actually reboot it, you might as well go, "Right away, sir." and get it over with.

    • You must not have ever admin'ed many big iron servers. You know, the ones which take upwards of 30 minutes to reboot and are typically servicing 100+ users or mission critical applications. As the rest of the article says, simply rebooting doesn't fix the underlying issue. All you do is set yourself up for a repeat down the road. You are simply kicking the can down the road for someone else to pick it up and put it in the trash/recycle bin...
  • "Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic."

    Really? Rather than doing something a simple way, over the years veterans learn that complicated and difficult is better? K.I.S.S! There's even an acronym for it!

    This sounds like it was written by a junior admin or programmer who's in awe of what some of the more seasoned vets are doing.

  • What, they've built Angry Birds into emacs now?
  • by seeker_1us (1203072) on Tuesday February 15, 2011 @07:49AM (#35208390)
    VI vs Emacs is an old and silly argument. This guy loses major points for essentially claiming that the only one true editor for "veteran UNIX admins" is VI.

"You need tender loving care once a week - so that I can slap you into shape." - Ellyn Mustard

Working...