Follow Slashdot stories on Twitter


Forgot your password?
GUI Programming Software Technology

10 Dos and Don'ts To Make Sysadmins' Lives Easier 246

CowboyRobot writes "Tom Limoncelli has a piece in 'Queue' summarizing the Computer-Human Interaction for Management of Information Technology's list of how to make software that is easy to install, maintain, and upgrade. FTA: '#2. DON'T make the administrative interface a GUI. System administrators need a command-line tool for constructing repeatable processes. Procedures are best documented by providing commands that we can copy and paste from the procedure document to the command line.'"
This discussion has been archived. No new comments can be posted.

10 Dos and Don'ts To Make Sysadmins' Lives Easier

Comments Filter:
  • 1. DO switch every don't to a do and do to a don't on that list. You are now a user.
    • This one made my chuckle:

      7. DO tell us about security issues. Announce them publicly. Put them in an RSS feed. Tell us even if you don't have a fix yet; we need to manage risk. Your PR department doesn't understand this, and that's OK. It is your job to tell them to go away.

      My CEO asks me to whip up a web page that users can use to submit who their phone provider is (we were all given options and not tied to 1 vendor. That has its pluses and minuses) and how long they have left on their contract so that he can get an assessment of where the phone situation is at for upgrading people's company phones. He wants this about 5 minutes ago.

      I spent the trivial 1 minute it took to make sure my text boxes were SQL injection proof - but I haven't bothered doing

  • by digitalsushi ( 137809 ) <> on Thursday December 23, 2010 @04:01PM (#34654296) Journal

    10 is an even number. There's no duplicates. None of them are filler.

    I don't understand how this happened.

    Did someone plan this before they wrote it? What gives?

    • Re:i am impressed (Score:4, Insightful)

      by mcgrew ( 92797 ) * on Thursday December 23, 2010 @04:06PM (#34654332) Homepage Journal

      Not only that, but I'd say almost all of them don't just apply to making admins of large networks' jobs easier, but to ALL software development for any computer use.

      #11: NO DRM, dammit!

      • by fuzzyfuzzyfungus ( 1223518 ) on Thursday December 23, 2010 @05:00PM (#34654794) Journal
        There is a special place in hell for vendors who sell bulk licenses(50+ seats) for software whose DRM prevents automated installation, and requires that the IT office's picker of the short straw go around and type in a gigantic license key on all machines.

        If a hole has to be punched in the firewall for the online activation/authentication step; because they were just too damn special to use SSL on a standard port like everybody else, that special place in hell is filled with screwworms.

        If there is a hardware dongle component(that looks exactly like a USB flash drive, and thus wanders accidentally if not carefully hidden) and requires a new purchase order and a nasty pile of cash to replace, that special place in hell automatically inserts bullet ants into the scrotum of anybody placed there.
        • by dbIII ( 701233 )
          Extra points if the USB dongle needs 16bit software that needs both command line switches and a GUI to update licences, but at least it's still possible to run while there are 32bit versions of XP still around. Then there was Macrovision's Y2K bug in flexnet in 2008 which thought permanent licences expired in 2000.
          Dongles and the crapware surrounding them are only there to punish the innocent.
      • #11: NO DRM, dammit!

        God, I really don't know how developers get away with "activation". I have had so many fricken problems with activation over the years that I basically won't buy or install software that requires it. So first, right there, it's costing sales. Of course I can't say for sure that it costs more sales than it creates, but I can tell you anecdotally that multiple companies have lost sales to me because of their activation policies.

        Second, in a strange way it's actually encouraged piracy to some degree. At m

      • by mlts ( 1038732 ) * on Thursday December 23, 2010 @10:05PM (#34657074)

        To elaborate on #11:

        #11: No DRM. The BSA would turn any company inside out and have their entrails for Christmas lights if they are caught pirating even a single copy of WinRAR. Businesses who value being open are not going to be pirating anyway. So why add DRM which removes value from the product?

        #12: Ability to rebuild the product if it gets corrupted. Have it as an option to have the .cab/.bz2/RPM/.deb/etc. file stored in a directory, including patches. This way, if there is concern about registry/NetInfo/ODM/whatever corruption, it shouldn't be hard to have the product reinstall itself.

        #13: An uninstaller. Shit happens and crap gets in a half installed state. It would be great to be able to have a utility that completely removes any and all traces of a program, move aside/archive config files, and rename the config directories. This way, if a config document is causing problems, it is out of the path.

        #14: Ability to send reports to a third location, via E-mail or whatnot. This way, either by system logs or E-mail, there is proof that a package was installed or maintained, and not just the install mechanism; but from the application itself.

        #15: Ability to install as a non-administrative user if the functionality is relevant (this wouldn't be doable for system utilities, but a Web browser, yes.)

        #16: Ability to have a way to completely block installs of the product.

        #17: All executables are signed. Not just with the OS signing mechanism, but either with a manifest, or PGP/gpg detached signatures.

        #18: A "master console" program that can check for updates, store them, check installed clients if the update is needed, push out updates (either by a program or through the OS's install mechanism), perhaps even allow for removal en masse.

        I just wish more operating systems had not just an install mechanism (msiexec, rpm), but an update mechanism from repos (yum, macports). This would make life a lot easier, especially if it can be configured from custom repositories so enterprises can have their own mirrors.

    • 10 is an even number. There's no duplicates. None of them are filler.

      I don't understand how this happened.

      I know how they came up with a high-quality top ten: They had 13 or so, and they cut the weakest ones.

    • by kimvette ( 919543 ) on Thursday December 23, 2010 @04:31PM (#34654516) Homepage Journal

      No slashdot editors were involved in the production of the list. ;)

    • I demand a meta top 10. The top ten list of top 10 lists.

    • by perpenso ( 1613749 ) on Thursday December 23, 2010 @05:56PM (#34655276)

      10 is an even number. There's no duplicates. None of them are filler. I don't understand how this happened. Did someone plan this before they wrote it? What gives?

      Its an article. Not only did the author probably plan, re-read and revise the article before submitting it but a technically knowledgable editor probably read it and may have offered useful and insightful suggestions. Now there may not have been a formal peer review process but the editor may have also had one or more experts in the field read it and offer comments and suggestions.

      Yes the above seems an archaic process but consider that the acm is full of old people who had experience publishing back when things were done with dead trees. ;-)

    • I had 15 items and picked the 10 best.

  • In essence, all 10 items on the list say "Use Linux!"

    Yeah, ok, thank you Captain Obvious, I mean CHIMIT :P

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      In essence, all 10 items on the list say "Use Linux!"

      Yeah, ok, thank you Captain Obvious, I mean CHIMIT :P

      Not really. The same problems exist in Linux -- authentication, logging, putting files in random folders (/var, /etc).

      • In essence, all 10 items on the list say "Use Linux!"

        Yeah, ok, thank you Captain Obvious, I mean CHIMIT :P

        Not really. The same problems exist in Linux -- authentication, logging, putting files in random folders (/var, /etc).

        The difference with Linux is that if you don't like it, you stand a decent chance of actually being able to do something about it.

        Obviously that's sub-optimal. It would be better for vendors to soundly design their software in the first place. Still, open (in the sense of "transparent") systems make it much easier to actually mitigate such nuisances.

  • by subreality ( 157447 ) on Thursday December 23, 2010 @04:09PM (#34654360)

    It's a top-10 list that actually has insightful information on how to do software right, instead of being a random collection of ten things to make a fluff article. Bonus points for being things that I actually agree with.

  • by XanC ( 644172 ) on Thursday December 23, 2010 @04:10PM (#34654378)

    The article author is also behind The Practice of System and Network Administration [], truly an excellent text into the practicalities of work in IT.

  • by eln ( 21727 ) on Thursday December 23, 2010 @04:14PM (#34654400)
    If you want to make a sysadmin's life easier (as if any programmer ever wants to do that), you can start by making your error and status messages 1.) plentiful and 2.) easy to understand. Also, provide several logging levels so we can drill down as needed, and make sure the logging levels are meaningful. Too many programmers put just two log levels: one which shows nothing useful, and another that spews out indecipherable hex dumps of every call it makes.

    Face up to the fact that no matter how awesome your software is, it's going to fail. Not only that, but it's going to fail in ways you never thought possible at the worst possible times. Make sure we have enough information to figure out what happened. Otherwise, stuff like this happens:

    Program: *crash for no apparent reason*
    Sysadmin: Why did you crash?
    Program: Because something went wrong.
    Sysadmin: What went wrong?
    Program: Something.
    Sysadmin: I need more detail. Increasing log level.
    Program: Something bad went wrong.
    Sysadmin: I need more than that. Increasing log level again.
    Program: Fuck you. Here's a 16GB hex dump of system memory. Figure it out yourself jackass.
    Sysadmin: *picks up a crowbar and goes off to find the programmer*
    • by Monkeedude1212 ( 1560403 ) on Thursday December 23, 2010 @04:36PM (#34654566) Journal

      That reminds me of a Web Developer I once knew.

      He said he didn't bother putting try/catches around certain standard things (Like Database connection opening, closing, transactions, etc) - because if anything ever went wrong it was easier for the user to take a screenshot of the Stack Trace if and when it went wrong from the Webapp. Said it took too much time to build in proper exception handling and error messages.

      He said that the user experience basically means nothing if your application doesn't work, so when something doesn't work, don't bother making it pretty.

      He no longer works here, though I can't imagine why.

      • by Jaime2 ( 824950 ) on Thursday December 23, 2010 @05:36PM (#34655100)
        Of course, good error handling is best. But, no error handling is usually better than cargo-cult error handling that displays a pretty message, but doesn't record the error detail anywhere. Very few things bother me more in a code review than somebody who put in the extra effort to ensure that an error message can never be found, I would have rather they simply skipped it.
      • I actually ascribe to your colleague's view. You really need to do your best to anticipate and handle all REALISTICALLY POSSIBLE error scenarios. But if something unimaginable happens, you probably do NOT want to:

        A) Sweep it under the rug so that the user, and you, never even know it happened
        B) Try to recover, i.e. perform complex tasks, while state is corrupted in unknown ways

        Really, the important idea is to make sure the user knows something REALLY bad happened, and give the user enough information to re

      • by jamesh ( 87723 )

        That works both ways though. I kind of agree that crashes shouldn't be pretty - you don't want to make a serious error something you can just click through. If the nightly backup job failed I don't want a benign little error message presented to the user, I want something that will get their attention. And if that means blowing the application up so that Windows lets them know then so be it.

        Crashing with a stack trace because you can't open the database, instead of MessageBox.Show("Could not connect to data

        • Sometimes you don't want to be quite so obvious about the error. They're good to log though. :)

          On one of my sites, it's very dependent on the database working. Sometimes the database isn't available, say someone rebooted it during the middle of the day. Shit happens. Instead of throwing a nasty "Couldn't connect to database - timeout connecting to", it just says "Sorry, we are temporarily down. Please check back in a few minutes.". Of course, the nasty erro

    • if it fails in a way that you never thought possible, how would you write an error message that describes the failure?

      • You describe what it isn't, based on the other exceptions you were designed to handle.

        Narrows down the search/troubleshooting.

      • by catching return codes to functions, and displaying their results back to the user. If a function tries to open a file, and it fails, the OS will tell the program the reason and describe the failure; all you have to do it pass it along to the user. such as: open FILE, "filename.txt" or die $!;
        • Re: (Score:3, Informative)

          by greed ( 112493 )

          Which is a perfect example of a terrible error message. And there's plenty of bad examples like that to crib from, too. (In your particular example, sure, you'll have the "at line XXX" so someone can start digging around in the code... but that's something only suitable for quick-and-dirty hack scripts.)

          What you need to know is WHAT, WHERE and HOW. You know WHO (the program), and are trying to figure out WHY. I've often had to resort to strace -etrace=file to find out "What file couldn't be opened? Why

      • C --- if (err 0) printf("Unexpected Error: some_method() returned %i\n", err);
        C# --- catch (Exception ex) { EventLog.WriteEntry("AppNameHere", String.Format("Unexpected Error:\n{1}", ex.ToString()) }

        There are better ways, but this at least gives *something*.

      • by fishexe ( 168879 )

        if it fails in a way that you never thought possible, how would you write an error message that describes the failure?

        By putting error messages in a ton of places you don't expect an error to arise, just in case (i.e. places where you expect the input to have been sanitized, add error messages for unsanitized input; places where you expect parameters to be in a certain range, check for them to be out of range and indicate which was out of range).

      • if it fails in a way that you never thought possible, how would you write an error message that describes the failure?

        Well, if you (or, rather, the application code) know that it fails (IOW, if it hasn't failed at a level so far down that it just dumped core/GPFed/etc. without even signalling your code) then you probably know something about the context where the error occurred (what was in progress), what code module of yours received the error, and what the exception or other indication of failure you received from outside of your code to let you know that something was wrong.

    • by jimicus ( 737525 )

      Seems to be far worse for Windows applications than Unix ones, and worse for commercial rather than F/OSS applications.

      I've no idea why this is, but I swear to God that Windows developers have no concept of logging. It really makes me wonder how the hell they debug the application - debuggers only ever go so far.

      • Are you saying that having a file under C:\Windows\ called "mytotallycoolapplicationlog.txt" - and writing "It worked :)" everytime the process is successful and having "It failed :(" Everytime it doesn't constitute a good logging procedure?

        • by jimicus ( 737525 )

          IME you're doing well if you get that.

          There's at least a few apps I would like nothing better to get to speak to the dev team leader and ask them why, on FSM's sweet earth, they decided to do that. Was some deranged PHB involved or is there some sort of requirement that nobody can be hired to develop for Windows unless they point-blank refuse to log a single damn thing?

        • Are you saying that having a file under C:\Windows\ called "mytotallycoolapplicationlog.txt" - and writing "It worked :)" everytime the process is successful and having "It failed :(" Everytime it doesn't constitute a good logging procedure?

          Windows does have a system logging facility, as in it's provided by the operating system. I have no idea whether it's as functional, but otherwise it's comparable to the syslog facility provided by Unix and Unix-like systems. Maybe I'm being fanciful but this is what I imagined when I read Jimicus' post.

    • as if any programmer ever wants to do that

      Got that right!

      Face up to the fact that no matter how awesome your software is, it's going to fail.

      As any good programmer knows, failure is not an option. If software fails it is because of misuse, foreign (read "anyone who isn't me") programming staff, or failure to RTFM. Please do not bother us with your petty problems and See Figure 1 []. Understand this and your life as an admin will be forever simpler.


      Your most awesome programming staff

      • Please do not bother us with your petty problems and See Figure 1 []...

        I couldn't help but notice that the last line of the linked article was, "Love VMS or leave it, but don't complain."

        I guess we all got tired of being told to see Figure 1 and just left VMS... I haven't logged into a VMS machine in over 15 years.

    • God I love slashdot sometimes

    • At last, we know why Gordon Freeman was so handy with the crowbar... AND the most solid clue yet as to why Black Mesa went blooey!

      Thank you, sir! You've done us a great service!

    • You joke, but most programmers I encounter think that acceptable error handling is one of the following, in order of preference:
      1. Pretend errors can't happen. Even when code isn't working right, do not put any error checking in.
      2. Check for errors, but simply exit program when one occurs, without telling user of that fact.
      3. Check for errors, and when one occurs, exit program and print "error occurred". Throughout program, return boolean success/failure from routines.
      4. Check for errors, and actually tell user t
    • by jamesh ( 87723 )

      Or even worse:

      Program: *crash for no apparent reason*
      Sysadmin: Why did you crash?
      Program: I didn't crash.
      Sysadmin: What went wrong?
      Program: Nothing went wrong.
      Sysadmin: But there's an error message right there!
      Program: No there isn't.
      Sysadmin: Yes there is. Look. Right there in the logs where it says Error.
      Program: And what does it say after the word Error?
      Sysadmin: ... "the operation completed successfuly"...

      "Error: The operation completed succesfully" is my all time favourite error message!

  • click-wall. (Score:5, Insightful)

    by nblender ( 741424 ) on Thursday December 23, 2010 @04:21PM (#34654448)
    Don't make me use a real browser to click all the way through your site, make me agree to a stupid set of conditions for using the software, and then provide my browser with a cookie that it can subsequently use to download your software; when my browser is on one continent and the machine that wants the software is on another continent; you ass-fucks...
  • by sl149q ( 1537343 ) on Thursday December 23, 2010 @04:23PM (#34654468)

    > DO have a configuration file that is an ASCII file, not a binary blob.

    And by ASCII we mean something that can be edited by any editor.

    XML is the equivalent of a binary blob when you are up to your ass in alligators trying to get things working again with minimal tools available.

    • Wait ... why are the alligators trying to get things working?

      • by Nadaka ( 224565 )

        Because the alligators made the mistake of eating the bottom half of the on call sysadmin before he fixed their server.

        • by jimicus ( 737525 )

          Any self-respecting sysadmin gets attacked by the alligator, it's alligator steak for dinner.

  • 2. DON'T make the administrative interface a GUI.

    Amen, the number of times I have dumped on products because of the lack of a CLI is almost rude and funnily enough it saves a lot in licensing costs so "almost" everyone is happy. Pretty pictures and buttons will get you past the management and sales but if you come near my systems with your "button pushing monkey" toys expect your time in the building to be very short indeed.

    • Ok this I don't understand. A GUI can clean things up a lot. Instead of wading through a 1000 line config file all the options are in front of you. They are better organized and can prevent things like conflicting options or flags. I've seen NFS stop working because there was a space used instead of a tab in the config. At least apache was nice enough to finally split up httpd.conf into different parts.

    • Amendment to #2 (Score:5, Insightful)

      by c++0xFF ( 1758032 ) on Thursday December 23, 2010 @04:42PM (#34654610)

      Feel free to make a GUI for the administrative interface, but not at the expense of an underlying CLI.

      There are two ways to do this: have your GUI call the CLI when necessary, or use a common API behind both. Other methods will lead to bitrot in one of the interfaces, most likely the CLI.

      GUIs are fine and even enjoyable to a certain extent, but the author is right that the CLI takes priority.

  • by Zarhan ( 415465 ) on Thursday December 23, 2010 @04:33PM (#34654530)

    ...if the GUI is well done and complements command line.. Some tasks actually ARE much better performed with Point&Click.

    One example of a "good" GUI that I use a lot is the ASDM for Cisco ASA firewalls. Most of the simpler admin tasks are in fact *faster* via ASDM. If you have your network objects all properly set up and you need to add a firewall rule, it's far simpler to select it from a list (actually, in this case it's a combobox - just type first few letters to filter your choices and then click) than typing that stuff in manually. Packet tracer to check the rules is much nicer to use via the GUI. Setting up VPN profiles is simpler via ASDM. Handling network object groupings is simpler via ASDM.

    Editing access-lists, doing routing configuration and most of the more "rudimentary" tasks are still something I do via command line, though.

    • The gold standard in my opinion is when the GUI utilities are essentially glorified config-file editors. Having a service that is configured with a respectable text-file (xml config files are awful), and ships with a good GUI application to guide configuration, is absolutely fantastic.

      • by Zarhan ( 415465 )

        That's what ASDM essentially is. When you make a change, it basically just generates some commands and then sends them the box. If you tick an option, it even allows you to review those commands in advance (and manually copy-paste them in, if you prefer that instead.).

    • I have to agree. CLI scripting is wonderful and incredibly useful, but it does not render an admin GUI obsolete. It is not feasible to learn the CLI syntax for each of the hundreds of apps I deal with for clients. In most of them, creating a new user is a matter of a handful of clicks and entering the appropriate user information....not poring over poorly written txt files for an hour looking for which switch grants the user rights to edit the time entries of a different practice group.

      GUI and CLI shou

    • by Qhartb ( 1311541 ) on Thursday December 23, 2010 @04:53PM (#34654710)
      I think it's more a matter of not making a GUI instead of a command line interface. Making both is, of course, perfectly fine, so long as the CLI is fully-featured and reasonably usable.
    • by jimicus ( 737525 )

      I'm in two minds. A CLI is a fantastically powerful tool, but at the same time some quick & easy way to change small settings that doesn't require you to go back to the manual (because the last time you looked at this item was eight months ago, and you can't remember a single damn thing) is damn handy.

  • This list is a good start. Don't consider purchasing software that doesn't meet these criteria.

  • Windows CAL cost (Score:5, Informative)

    by tepples ( 727027 ) <{tepples} {at} {}> on Thursday December 23, 2010 @04:36PM (#34654580) Homepage Journal
    From the article:

    8. [...] Similarly, use the operating system's built-in authentication system and standard I/O systems.

    This can be a bad thing if your application runs on a platform whose built-in authentication is a nickel-and-dime revenue stream for the platform's publisher. Microsoft Windows Server is like this: each user account on the built-in authentication system requires a Client Access License.

    • Point taken. Consolidating directories of authenticated accounts in general is a good idea, especially if open standards are involved. If Active Directory (or whatever) isn't your cup of tea, setting up an OpenLDAP server or something similar should be an option.

      I think the basic idea is to avoid over-replicating information and minimizing the potential for human error in the duplications.

    • by Jaime2 ( 824950 )
      Incorrect. Client Access Licenses are for those who use File and Print services. Authentication services only require a license for the server itself.
    • by jimicus ( 737525 )

      WTF are you talking about?

      With Windows, you need the CALs for the user to access any application running on the OS in the first place.

    • by quacking duck ( 607555 ) on Thursday December 23, 2010 @08:42PM (#34656474)

      This is why I hate having to deal with Windows on the side. In this aside about user CALs, there's three different takes (so far) on when you need a Windows CAL and when you don't.

      I got sick of researching Windows Small Business server when I read their FAQ, and the section on licensing was longer than all the other sections combined!

  • My Amiga was a computer that was equally comfortable with CLI and GUI interfaces, and may programs with GUIs had plenty of shell commands with the same executable. I'm not sure why the rest of the computer industry turned it into a religious war that continues to this day.

    Some planning and thought are all that's required to make a balanced interface that handles both methods well.

  • I manage almost exclusively Linux servers and i must say the command line saves me ooodles of time. Some quirks can be alleviated by just restarting some services before they run out of memory, some needs a bit more magic but nothing takes time like having to login to many computers every day and click on the same friggin GUI stuff on multiple servers.

    Bash saves me time by totally taking repetitive tasks away. Ive tried the same with some Windows machines but while powershell has potential, it does not work

    • by jimicus ( 737525 )

      Maybe in time Windows will climb up to the level of Linux when it comes to manageability but right now i spend most of my time doing repetitive stuff on my Windows boxes while i write scripts that handles anything on the Linux boxes.

      I doubt it. Even relatively recently, I've had serious conversations with tech support at companies where they don't put someone with the IQ of a pot plant on the phone explaining that I need to automate something and you would not believe the number of times I've been told something along the lines of "Why would you want to do that? It's not that complicated - just a couple of clicks."

      Getting the message across that it's a couple of clicks to you, it's a couple of clicks possibly several hundred times to

  • Unless you want me to drop the product and choose something else less irritating. Hello VMWare? Xen?
  • Procedures are best documented by providing commands that we can copy and paste from the procedure document to the command line

    Copy Pasta Security®

  • by AntEater ( 16627 ) on Thursday December 23, 2010 @06:08PM (#34655394) Homepage

    This reads like a specification for building a unix system.

    Those who don't understand Unix are doomed to reinvent it... or something like that.

  • Eventlogs (Score:5, Insightful)

    by Spad ( 470073 ) <slashdot AT spad DOT co DOT uk> on Thursday December 23, 2010 @06:37PM (#34655608) Homepage

    In reference to point 8, this is something I wrote I while ago after dealing with several Windows apps that either horribly abused the Eventlog or refused to use it entirely:

    • DO create your own event message DLL(s) where appropriate to avoid your events looking like this []
    • DO log important errors and warnings. Application failures, communication issues, invalid configuration data and the like. Things that will help administrators to troubleshoot issues that may occur.
    • DO make your logs intelligible to someone other than you. Not having developed the application myself, I have no way of knowing if “Invalid foo in bar. More cheese needed at 0×8003387 means that someone’s made a typo in a config file somewhere, a firewall rule needs changing or that the application doesn’t support running during the vernal equinox.
    • DO throttle your logging. Don’t log the same error every second, it’s pointless, generates a lot of “noise” and – much worse – forces other, potentially useful events out of the log’s retention.
    • DO make your logging level easily configurable by the user and DO set a sensible default.
    • DON’T log every single informational or debug event that your application generates. Nobody gives a shit that you successfully checked a message queue and found it was empty; either use a Custom Event Log or a log file in the application directory if you want to record that kind of information.
  • #1 big dont (Score:5, Insightful)

    by MrLint ( 519792 ) on Thursday December 23, 2010 @06:40PM (#34655626) Journal

    Do not assume that your software is running with elevated access... (root/administrator)

  • by PPH ( 736903 ) on Thursday December 23, 2010 @06:56PM (#34655756)

    Make sure its clear whether you meant '10' in base 2, 8, or 16.

  • by Plekto ( 1018050 ) on Thursday December 23, 2010 @07:10PM (#34655854)

    #10 should probably be #1. Support and documentation is everything. Because when it hits the fan, finding the original install CDs or manual is almost always a requirement. It's also why I stopped buying Nvidia cards. They got rid of almost all of their patches and drivers as well as installation CDs on their site and now force you to use their "all in one" tool. And lo and behold, you're screwed 90% of the time with an older machine if you don't have the original install CD because it simply doesn't work without the CD.

    Case in point - I tried to recover an old machine's crashed system(video drivers and dirext X had eaten themselves when "upgrading" as is typical) - but the online driver was useless. The original CD was the only option, but it wasn't to be found. (as is typical, few customers keep driver CDs where they can find them). The manufacturer didn't have the original CD to download, either.(honestly, a 50mb ISO file isn't going to kill their server space) I had to buy a new card to solve what should have been a ten minute problem. Nobody was happy about it, either, as you would imagine, since the card wasn't even two years old at the time.

    (note - a "roll back" option also needs to be available when "upgrading") I'd wager that 95% of the time it is simply not there.

  • by Arrogant-Bastard ( 141720 ) on Thursday December 23, 2010 @07:46PM (#34656054) the install media into a scratch area, just so I can run your obfuscated, opaque Java application, just so it can copy everything into the real installation directory.

    Instead, why not try using, oh, I dunno, "tar" and "make" and friends -- you know, the standard 'nix tools that every system administrator has been working with quite happily for decades and which suffice nicely to install tens of thousands of software packages ranging from the dirt-simple to the incredibly complex.

    I'm looking at you, SAS.

  • by CAIMLAS ( 41445 ) on Thursday December 23, 2010 @08:58PM (#34656604) Homepage

    1. DO have a "silent install" option.

    Silent install is nice, but so is an intelligent install, or a well thought-out, correctable upgrade process.

    These systems do it well:

    Debian and RedHat derived; Windows, post-2003. OS install is still a bit of a bitch with Windows. The upgrade process for MediaWiki is also stupid easy and effective (basically: untar new tree and run db alter scripts).


    FreeBSD, and, really, most BSDs, are horrible for upgrading. I suspect OS X is similarly stupid when it comes to "promptless installs". Cacti, likewise, is awful.

    2. DON'T make the administrative interface a GUI.

    A useful amendment to this is: don't make the administrative interface shitty. GUI is fine, as long as I can leverage it progmatically. CLI tool is great, as long as it's fucking documented and not obtuse.

    Case in point (in opposition): MegaCLI, for MegaRAID cards. Absolute. Shit.

    3. DO create an API so that the system can be remotely administered.

    An API is great, and allows for programmers to dig in and extend the product. I'm thinking of VMWare, XenServer, and Virtualbox right now. The latest Windows versions with PowerShell and the management consoles are not a bad combination of usability/power/utility.

    Most sysadmins don't have the time to dig into the API, though, so a good initial tool that isn't terribly dense or limited in functionality is a must (XenServer, please improve your shitty-useless UI on xsconsole and XenCenter; I'd like a little more access to my VM disks without digging into lv/pv commands, too).

    4. DO have a configuration file that is an ASCII file, not a binary blob.

    No argument here. Likewise, configuration should be human-readable and not have vague incantations.

    Good: samba, and all tools which use similar configuration syntax.

    Bad: sendmail is the worst offender I can think of at the moment. I'm sure all the djb* stuff, too.

    5. DO include a clearly defined method to restore all user data, a single user's data, and individual items (for example, one e-mail message). The method to make backups is a prerequisite, obviously, but we care primarily about the restore procedures.

    Good: any UNIX system and it's $HOME; modern Unix MTAs like Courier.

    Bad: Cyrus IMAP. Pretty much any tape archive system comes close to frustrating as hell. Windows still has a long way to improve until it's capable of Unix-style $HOME utility.

    6. DO instrument the system so that we can monitor more than just, "Is it up or down?"

    WMI is great. SNMP on Unix/Linux hosts, not so much, due to the configuration and divergence involved. Most OEM Linux/Unix based machines or systems (XenServer) are relatively shitty in this regard, too.

    7. DO tell us about security issues.

    Telling us about them is great, but upgrading these things are the most important, time-sensitive upgrades we need to make, so they should also be the easiest. We should not have to break two-three different things just to get the upgrade done.

    BSDs are bad about this; horrible, even. The time consumed by a simple upgrade is enormous.

    Linux is mediocre, but better than most.

    Windows, in this case, "just works". Except when it doesn't (though I'd argue the degree is no greater than, say, the Linux upgrade process). Your biggest cost will be when it installs something you've explicitly told it not to (*cough* new IE versions) or in bandwidth and/or uptime requirements.

    8. DO use the built-in system logging mechanism (Unix syslog or Windows Event Logs).

    Something which doesn't do this isn't even worth looking at. It's yet one more thing to manage and uses exponential

    Addition: make your logging sensible, please. I don't want to see a full trace of everything in the logs and not be able to configura

  • by FoolishOwl ( 1698506 ) on Friday December 24, 2010 @06:20AM (#34658762) Journal

    2. DON'T make the administrative interface a GUI. System administrators need a command-line tool for constructing repeatable processes. Procedures are best documented by providing commands that we can copy and paste from the procedure document to the command line. We cannot achieve the same repeatability when the instructions are: "Checkmark the 3rd and 5th options, but not the 2nd option, then click OK." Sysadmins do not want a GUI that requires 25 clicks for each new user. We want to craft the commands to be executed in a text editor or generate them via Perl, Python, or PowerShell.

    Since I've had to work with Windows servers in my new job, I thought I'd better read up on them, so I've been reading Windows Server 2008: The Definitive Guide []. The sections on the underlying principles and theory of the OS are fine. But that's one third of the text, at most. Most of the text is useless blow-by-blow accounts of sequences of clicks in GUI applets. It's completely unreadable -- the descriptions are meaningless unless you're working through the instructions with an instance of Windows Server 2008 in front of you. And who's going to set up several instances, just to make sense of the description of the applet for configuring load balancing?

    I can't blame the book, particularly, as it's a problem of GUIs.My workplace has lots of documents with step-by-step instructions for configuring services, which have one sentence of text, followed by a screenshot, followed by another sentence of text, and another screenshot, and so on.

    On the flip side, one of the great things about text configuration files is that while they're full of obscure configuration options, they're also full of the documentation explaining the obscure configuration options. Config files are rich with documentation. GUI configuration applets frequently aren't. I'll take a documented option in a config file over an undocumented option in a GUI config applet any day.

What is research but a blind date with knowledge? -- Will Harvey