back to article Sysadmins! There's no shame in using a mouse to delete files

I am curious about the thought process of some systems administrators. When Linux is mentioned in an El Reg article, the discussion in the comments section can collapse into a tired debate of GUIs versus CLIs: a bitterly fought war over point-and-click visual interfaces in software versus typing out lines of commands and …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    Things move in GUI's.

    The cynic in me believes that this is to sell training with every version (Oracle, and your enterprise manager - I'm looking at you!). If you use the CLI then you only tend to have to learn things once.

    There is nothing more frustrating than knowing a feature exists, but not being able to find it. Which is why I spend about 20 minutes swearing profusely when someone gives me something to do in office 2007+

    1. FartingHippo

      Re: Things move in GUI's.

      Which is why I spend about 20 minutes swearing profusely when someone gives me something to do in office 2007+

      Yeah. I really miss clippy :(

      1. perlcat

        Re: Things move in GUI's.

        Even worse than the location of GUI elements/widgets moving is the unholy piece of shit that is known as 'FriendlyTree' -- where when you drag a folder or files, folders open and close below it.

        People that think this is a feature need to have horrible things done to them. It is the sole reason I refuse to use GUIs on Windows-based servers for file management -- you've never lived until you accidentally did that little fiddly click-swipe, and your critical files disappear into the nether regions of a random directory. Unless you're watching like a hawk for it, you will be well and profoundly screwed.

        Yes, you can turn it off. Usually after you got burned by this product of the morons in Redmond.

        1. Anonymous Coward
          Anonymous Coward

          Re: Things move in GUI's.

          Dragging? You heathen! That's what cut and paste / paste into folder* is for.

          *horrible word, you mean a directory, right?

        2. ZweiBlumen

          Re: Things move in GUI's.

          regarding the friendly tree accidental drag and drop issue: Usually CTRL-Z will undo this in my experience.

          1. Anonymous Coward
            Anonymous Coward

            Re: Usually CTRL-Z will undo this

            Yep, fuck up with the pointy-clicky thing, and it's back to the good old keyboard to fix it. Par for the course.

          2. perlcat

            Re: CTRL+Z

            Yeah, it works just fine if you were trying to do task A, something went wrong, and you knew about it when it happened. Again, the problem is when you do the click-swipe thing, and don't catch it immediately.

        3. DJ Smiley

          Re: Things move in GUI's.

          Ah the wonders of control z to undo eh?

        4. Fatman

          Re: morons in Redmond.

          I have learned a few years ago, it is best to stay away from the crappy software foisted upon the world created by those morons in Redmond.

      2. Anonymous Coward
        Anonymous Coward

        Re: Things move in GUI's.

        I worked out where most the stuff I needed to use was before clippy existed.

        Although you get points for reminding me of an old boss who must've been a fan; all you could hear all day was 'ting ting ting' as he worked away.

      3. Fatman

        Re: swearing profusely

        Is what I do when a WindblowZE using family member requests my assistance in fixing their fucked up system.

        To deal with them, I have had a business card printed up, which looks like this:

    2. Tony Proudlove

      Re: Things move in GUI's.

      There is nothing more frustrating than knowing a feature exists, but not being able to find it. Which is why I spend about 20 minutes swearing profusely

      If I know a feature exists but don't know where it is in a different version, then I click Help and enter a few keywords to show me what I'm looking for. The problem is so called 'IT Professionals' consider using Help beneath them, although if an end user asks them something 'stupid', then they're very quick to ask why they didn't use the Help function first.

      1. This post has been deleted by its author

      2. Anonymous Coward
        Anonymous Coward

        Re: Things move in GUI's.

        Yeah, that might might work for office. You try doing that in anything Oracle have ever made, ever.

        Google usually works a lot better than in-built help, with it's shitty, invariably broken search function.

    3. SpaMster

      Re: Things move in GUI's.

      How exactly would doing it in a command prompt make an excel task any easier?

      1. Trevor_Pott Gold badge

        Re: Things move in GUI's.

        I wonder, does Lotus 123 from back in the day count as a CLI spreadsheet? No mouse interface on that...

  2. Arrrggghh-otron

    The right tool for the job...

    Use whatever works best for the task in hand given the constraints of the systems on which the task must be carried out and don't worry about the dyed in the wool CLI or GUI evangelists...

    1. Arrrggghh-otron

      Re: The right tool for the job...

      I was thinking about scripting yesterday. I used to write code for a living but don't much any more and, to my shame, am pretty rusty. Also I don't know any one command line inside out and so couldn't write anything but the simplest of scripts from memory. If I need to do anything more complicated, I need to reach for reference manuals (metaphorically speaking (I really mean 'man', /help, --help, Get-Help or google)). That means I often find myself staring at a command line weighing up if it is going to be quicker to manually enter a series of basic commands and collating the information generated or spend time trying to write a script to do it for me. Given the size of the information sets I am dealing with it is usually the former.

      I often feel a twinge of shame that I don't spend longer trying to figure out how to script it, but when it takes longer to script something than to get the results manually is that wrong? (I should qualify that question by saying if it was something I was asked to do regularly then I would spend the time to figure out how to script it and automate the process - like 99% of my existing repetitive work (don't tell the boss)).

    2. Khaptain Silver badge

      Re: The right tool for the job...

      Yes definately agree here. I perform at least 95% of what I do from the GUI. When the GUI is not able to offer the complexity for a given task I will move to the CLI.

      There is no "ultimate" method, there is simply the method at hand which gets the job done. I won't argue that either is better, it's a case of both are good and when combined they are great.

      It's like the Linux / Windows never ending debate, they are both great tools. You learn to live and adapt to their up and downs. At the end of the day I really don't care which system I use, I have to get the job done and I will always find a method which will allow me to do it.

      Any tool is only as good as the person using it.

      1. Ramazan
        Paris Hilton

        Re: The right tool for the job...

        I'll be concise. Gui (mouse/wacom) only fits for deathmatching and photoshopping. If you do sysadmin tasks in GUI, you're a loser. Right tool for sysadmining is CLI, stupid

        1. The BigYin

          Re: The right tool for the job...

          CLI? Real sys admins don't use a CLI. They use butterflies, stupid.

          1. Anonymous Coward
            Anonymous Coward

            Re: They use butterflies, stupid.

            Yes, real professionals use the tool for the job, whether that's a gui file manager, a command line ...or a butterfly (God, even Emacs has its place!). Real professionals are not uncomfortable with that, and they do not feel threatened by it.

            1. Trevor_Pott Gold badge

              Re: They use butterflies, stupid.

              I am now determined to somehow make a butterfly into a systems administration tool.

              Thoughts on how this can be done?

              1. Anonymous Coward
                Anonymous Coward

                Re: butterfly tool. Thoughts?

                Not yet, but if this becomes popular then I look forward to seeing yabt (Yet Another Butterfly Tool) in the manuals

              2. DJ Smiley

                Re: They use butterflies, stupid.

                Butterfly = bug == random point of failure instance?

            2. Anonymous Coward
              Anonymous Coward

              PS... they do not feel threatened by it

              ... Or feel the need to call others stupid for using what works for them.

    3. Amorous Cowherder

      Re: The right tool for the job...

      Well said sir!

      I use CLI for most day to day stuff at work as I know the systems and what I need to do, it's simply quicker to bounce about in the CLI on various servers. When I need to code Perl and shell scripts for work I use command line vi. Some SQL scripts I code in vi, some I use Oracle's SQLDeveloper GUI tool when I need to make a small change to an existing object in a DB. I use Oracle's Grid Control GUI console to get a quick overview of what a DB is upto, then I drop out to terminal session with my admin scripts to dig deeper into the DB problem at hand as I wrote them and I know them well.

      When I have documentation to write, I push Linux desktop to one side and jump on to my virtualised Windows XP box and knock the documentation. Sadly it has to be written in Word and stored in Sharepoint, so I use a GUI to everything.

      When I get home I use OSX GUI to work on my photos but I use a command line to rip off my DVD discs as Handbrake command line is the dog's wotsits on CLI, the GUI is awful.

      I flip back and forth depending upon what is needed for the task at hand, neither is better than the other, just that I find more useful than another to get certain things done.

  3. Anonymous Coward
    Anonymous Coward

    I've actually found many of my CLI skills are transferable, with Windows Powershell being the obvious exception. The terminals of MacOS, Linux and Unix are all similar.. but then that's because they are all derived from or based on each other.

    I've always been a mix and match kinda bloke though... I'll use CLI if that's the best thing for the job, or GUI if that is.

    1. eulampios

      bash and gawk

      The terminals of MacOS, Linux and Unix are all similar.

      For Mac OSX and most GNU/Linux :

      :~$ echo $SHELL


      POSIX shells are very similar. As well as tools. However, on FreeBSD it took me awhile to figure out why some of my bash scripts did not work properly, even though the paths were correctly identified. Turned out, I had to use gawk instead of awk. Also FreeBSD tools utils are a little different, e.g., date.

      1. Ramazan

        Re: However, on FreeBSD

        You ain't seen nothin' yet (TM). There are also SunOS(Solaris), HP-UX, Tru64(OSF/1), DIGITAL UNIX, AIX, HURD and so on, each with some shell/awk/find/etc quirk...

        1. Trevor_Pott Gold badge

          Re: However, on FreeBSD


          "Each with some shell/awk/find/etc quirk."

          Some diverge more from "what you're used to" than others. The beauty of learning bash and other POSIX-like shells as "baby's first CLI" is that there are just so many that more-or-less follow the same rules. You don't have to relearn an entire CLI interface to get the job done (like moving from bash to CMD.) You mostly just have to internalise the exceptions and differences.

          PowerShell is different for me here I think largely because a lot of the tools I got used to using with *nix operating systems aren't there. Chaining also works slightly differently, with the weird emphasis on OO shell structures, there are just some things that require a different headspace. (Linear scripting and I are just fine, but OO starts to wander outside my bailiwick.)

          More to the point, some of the fundamental assumptions about system usage are different in Windows versus most POSIX systems. Flat-text configuration as one example. (Though I must point out that more and more I can just feed XML into PowerShell-compliant apps and that works. It’s a start.)

          Where I start really getting outside my comfort zone though are programming-language CLI shells. Cshell, Rhino, etc.

          That’s all a really long way of saying “I think it really matters which CLI is your first.” You never forget your first, and it deeply influences how you view and interact with CLIs forever. Using something like Bash is grand, because it’s close enough to all the other POSIX shells that you can adapt quickly.

          Using a real outlier on the POSIX branch might not be as good; the mental list of “exceptions” to what you perceive as “normal” might be significantly higher than otherwise.

          I can’t find much empirical research into the difficulties of learning (specifically) shells – nor the deltas imposed on cognition by different POSIX shells – but there is plenty into similar areas. GUI design – as one example – has had billions put into fundamental research on “how far from what someone first learned” you can stray before they get really uncomfortable or have a hard time. Similarly, keyboard design…even the design of musical instruments.

          How much those “little differences” matter amongst similarly structured CLIs really could boil down to “which CLI you learned first!"

  4. The BigYin

    Tool for the job

    A CLI is a tool.

    A GUI is another tool.

    The CLI is easily scriptable, a GUI usually not.

    The GUI is often just a pretty wrapper on the CLI, but maybe not exposing all the features.

    The GUI may not even be a desktop app, it could be in a browser.

    The CLI is often backwards compatible, the GUI can change radically yet offer no new features.

    Sometimes one is better, sometimes the other.

    Learn both, their strengths and weaknesses.


    Leave the holy wars to the wannabes who think reading everything in hex makes them 1337.

    1. Ramazan

      @Sometimes one is better, sometimes the other.

      The only time when GUI is better for sysadmin tasks than CLI is when there's no CLI option at all (e.g.: braindamaged vendor like Microsoft).

      1. The BigYin

        Re: @Sometimes one is better, sometimes the other.

        A GUI is better (generally speaking) when a graphical layout is better able to display the current problem/fix/layout/whatever.

        At other times, a CLI can be better.

        You pick the best tool for the job.

        Did you know Windows now has a CLI back? I've not had cause to use PowerShell, but it is there.

        1. Ramazan

          Did you know Windows now has a CLI back?

          Windows has cmd.exe, and you can always install some kind of POSIX environment like Cygwin there and run sshd, but this won't make it fully scriptable. My job involves systems integration and glueing a lot of things with Tcl/Expect (and bash and awk and grep and sed...). Good luck doing the same with Windows.

          1. Anonymous Coward
            Anonymous Coward

            Re: Did you know Windows now has a CLI back?

            You've obviously never heard of Power-Shell.

        2. eulampios

          super-gui or super-cli

          May I suggest GNU Emacs, which maybe seen to unify the power of CLI and demonstrativeness of GUI, say M-|, M-!, dired, tramp etc? The ncurses stuff is very blessed type of tools too, like the orthodox mc :)

      2. Anonymous Coward
        Anonymous Coward

        Re: @Sometimes one is better, sometimes the other.

        @Ramazan - You obviously don't really know much about Windows - Every single thing that you can do from the GUI (and more) you can also do from the command line.

        1. Ramazan

          Re: Windows - Every single thing ... you can also do from the command line.

          So educate me - lsof|awk|kill, umount, fsck, lvreduce/lvextend, cryptsetup, mkfs, mount, for the start, from cmdline. And we use Windows NT 4.0 in production BTW.

          1. Trevor_Pott Gold badge

            Re: Windows - Every single thing ... you can also do from the command line.


            FSCK = CHKDSK


            MKFS = FORMAT

            LVREDUCE/LVEXTEND = FSUTIL (Is this in Windows NT??)

            1. eulampios

              Re: Windows - Every single thing ... you can also do from the command line.

              And how to properly "find" if I can ask?

              1. Trevor_Pott Gold badge

                Re: Windows - Every single thing ... you can also do from the command line.

                @eulampios FINDSTR might do you...

                1. eulampios

                  Thanks, Trevor

                  However, this one looks like semi-find, semi-grep semi-bulldog. I asked that question because I know there is nothing even getting close to "find" with its -printf, -exec, -regex, -type, -atime and so on in Windows.

                  If I need to grep it, I'd "-exec grep {} "or | xargs -0 grep"...

                  1. Trevor_Pott Gold badge

                    Re: Thanks, Trevor

                    @eulampios You are absolutely correct; until PowerShell, there wasn't anything grep-like. PowerShell 2.0'll take grep on.

                    In the Windows NT 4.0 world (which was the context of the original question,) nothing from that era of Microsoft software can match a modern grep command.

                    1. Anonymous Coward
                      Anonymous Coward

                      Re: Thanks, Trevor

                      Of course you can either install the gnu grep for windows of me sfu, if you specifically want grep...

  5. Lee Dowling Silver badge

    In terms of computer *administration* (i.e. running networks, etc.):

    If you use only CLI, you're an idiot.

    If you use only GUI, you're an idiot.

    Because each provides ways to do things safer, faster or more efficiently than the other. Hint: Repermission all files dated 12th of June, 2012, filesystem wide, so that user X doesn't have write access to them any more. You can do it in both, but one way will work better than the other depending on your experience and familiarity with the system. Now try to select 20 essential files out of 2000 by going through them and opening them up and assessing their contents. Similarly, just dragging a folder with Gb's of data to copy it is often a nightmare of needing to be in front of the computer till the bitter end (Ten minutes into the copy: "Are you sure you want to move this read-only file?" Yes to all. Ten minutes later: "Are you sure you want to move this system file?" Yes to all. And if you don't answer, you can wait forever and the copy will never complete). Not to mention the performance comparison between doing that via CLI and GUI. But, equally, I wouldn't want to manage an group-policy-like structure without a tree-based, multi-panel graphical app with help text.

    An admin who uses only one, all the time, doesn't have enough experience of the other and is wasting time and/or risking accidents that could be avoided the other way. This is *why* I whinge when MS (and now Ubuntu) tries harder and harder to hide the command-line from me on my personal machine too. There are some things that are either a) not possible, b) not sensible (e.g. "mv" versus an undo-able drag-drop) or c) plain inefficient when it comes to using just one method of issuing commands.

    And how, precisely, would you set up a GUI so that someone familiar with "sed"/"grep"/"awk" syntax could create the complex rules necessary for some tasks in the same amount of time? You wouldn't. I've run entire schools off sed and grep commands that are pages wide, something I'd have to write a graphical program specifically to do if I wanted a pretty button that did the same.

    1. Keith Langmead

      Different tools for different situations

      Completely agree with you. I regularly use both method, with the choice depending purely on which is more suitable and convenient for a given situation. If I want to do the same exact task lots of times then being able to script and automate it is fantastic, but for those simple tasks I do once in a blue moon I'd never remember the specific command, but a GUI is easy to remember.

      I loved it with SQL 2005 when they introduced the option to generate the script for what you'd just setup in the GUI. It might not have been the most efficient code, but for something I want to run at night once a week / month I don't care, it's not worth spending hours working out how to script it manually. On the other hand, I hated how MS decided with Exchange 2007 that lots of functions (including some simple day to day ones) should be done exclusively via PowerShell! Why? Allow me to do everything via either interface (allowing for some specific, unusual, high level options you couldn't fit into the GUI) and let me decide which one suits my current task.

      GUI wizards may be simplistic at times, but they do make delegation of simple tasks to junior staff much easier. I can show a junior how to run through the wizard and be confident of them not screwing anything up, at the command line I wouldn't feel as secure. But having the command line option means I can use that method when something more complex comes along that the GUI can't handle.

    2. Mako

      @Lee Dowling

      I agree with everything you said, but I upvoted you specifically for this:

      "Ten minutes into the copy: "Are you sure you want to move this read-only file?" Yes to all. Ten minutes later: "Are you sure you want to move this system file?" Yes to all. And if you don't answer, you can wait forever and the copy will never complete"


  6. mikeyboosh

    It's all about automation, which is usually via CLI.

  7. Alister Silver badge

    I agree with Trevor

    I make use of CLI for some things, and GUI for others, across a wide range of server and desktop operating systems and differing network appliances.

    Some of the appliance GUIs available are excellent, obviously well thought out, others not so much, just as is the case with the operating systems.

    I fail to see the need for the snobbery associated with using a CLI for everything, it can be work for work's sake sometimes.

  8. IHateWearingATie

    Mr Pott...

    Can I be the first to say that this kind of reasoned article has no place on El Reg. Please read Andrew Orlowski and others to better understand the frothing, sarcasm laden, biased invictive that has made this website what it is today

    Thanks you

    1. lurker

      Re: Mr Pott...

      Indeed! Where's the anti-environmentalist anti-"freetard" angle? Anyone would think this was some kind of IT forum.

      You could have at least thrown in some kind of Apple vs Non-Apple flamebait!

      1. Trevor_Pott Gold badge

        Re: Mr Pott...

        But...but...this was my trolling article! Chris even came up with the most trolly possible title!

        Clearly I need to spend more time under my bridge.

  9. Andraž 'ruskie' Levstik


    I must say I do a lot of stuff via CLI but yes some things just aren't workable via CLI. I'll use a GUI webbrowser. True one that supports vi like keys and keyboard navigation. I'll rdesktop since managing windows is still a GUI approach and that's not necessarily bad.

    Use what works best of what you need. But I must say that I've learned so much more about how things work with CLI vs GUI that it's sad how things are masked.

  10. Badvok

    Job Security

    Totally agree that anyone who can't use both is going to struggle to get much done on any OS.

    But I feel that those who favour the CLI are those who like to protect their job by ensuring it is only those fully initiated into the inner-circle that can ever hope to understand and support what they have done.

    It all depends on whether you want an easy life and focus on the important things or whether you really want to ensure that application X uses a 64K buffer to talk to application Y on the third Friday of any month with an 'r' in it rather than the default 48K buffer.

    1. chr0m4t1c

      Re: Job Security

      Er, no, not even close.

      GUI is almost always good for the first-time quick-setup stuff, but it very rarely gives you an optimal solution and when it goes wrong you will find that your inexpensive, inexperienced administrator is probably so out of their depth that you will only find them by searching the Mariana Trench. At that point, fixing things will get very expensive very quickly.

      The article is entirely correct, both are useful tools. I recently set up a VPN server and the GUI allowed me to create all of the configuration files in about 5 minutes by answering a few questions. The CLI allowed me to quickly tailor the configuration in ways that were impossible via the GUI *and* it allowed me to copy the tested configuration from the VM test server to where I wanted to deploy it in seconds without needing to make any further changes.

      What you're talking about is the difference between a fitter and a mechanic. Both can do basic jobs competently, but when you have a real problem the fitter will only be able to suggest replacing random(ish) parts in the hope one of them fixes the problem, whereas the mechanic will diagnose the actual problem and do what is necessary to fix it (which might be something as simple as tightening a nut). That's why fitters are paid £10/hour and mechanics £50+.

  11. Ninetailed

    I agree entirely with the sentiment behind this post. I can't help but shake my head whenever I see a GUI versus CLI "debate", and just carry on using both side by side.

  12. Flocke Kroes Silver badge

    No need to learn new command line tools for every OS

    If all else has failed, and you have to use Windows, install Cygwin so all your favourate Linux command line tools will be available.

    The amount you have to learn is not that big either. The name of the command is plenty as almost all of them will explain themselves if you type:

    command --help

    If you cannot remember the name of the command to handle some topic:

    man -k some_topic

    The commands you need to get started are:

    man man

    man bash

    info info

    Those are the manual pages for reading the manual and using the shell, and the info page for using the info documentation library. If there are some details of a command you cannot remember, read the manual. If you are dealing with a new topic, try info. After a couple of months, you will find things in the manual far more quickly than by clicking on all the menu entries and reading all the options in the dialog boxes.

    There are some tasks that are best handled with a GUI, but if you have to do something once, then there is a bad chance you will have to do it again. If you got the job done using the command line, then it takes almost no work to get atd or cron to do it for you in future.

  13. Anonymous Coward
    Anonymous Coward

    I prefer CLI over GUI because of RSI!

  14. dz-015

    Trevor, I don't think any of the commenters in your last article were saying that GUIs are inherently bad. You just reacted as if they were.

    I certainly wasn't saying that, and particularly not as far as the desktop is concerned. In general this article makes a fair amount of sense, but I don't think it really addresses the points which were raised in the comments on your last article.

    I was making a couple of subtly different points which didn't seem to be fully grasped: firstly, that Linux is inherently a CLI-based system, and that adopting this mindset is going to work much better for you over the long-term if you want to become a professional and competent Linux admin; and secondly, that IMHO webmin is not in general an appropriate thing to be running on a professionally-administered, live, Internet-facing production server.

    "I am curious about the thought process of some systems administrators."

    OK, great. Hopefully that means you'll have a good listen to what experienced administrators are saying and think about taking it on board rather than saying their "entire argument is bullshit".

    1. Trevor_Pott Gold badge

      And I completely disagree with you on your points.

      A GUI is a tool; it has a place, even on production servers. You haven't offered anything to explain why it shouldn't be there excepting your own personal bias.

      Your arguments are based entirely off the base that "proper sysadmins use the CLI." The GUI thus being equivalent in your version of the universe to training wheels. Again; I disagree. Your entire perspective on the GUI vs CLI debate is pretty cracked. Listen carefully here: GUIs are perfectly fine things for administering servers, production, testbed and otherwise. So are CLIs. Better to have the option of both.

      Quit limiting yourself, and for the love of His Noodly Self, quit advocating the limitation of others, just because you want to believe in the sacred power of your secret nerd club. No, the CLI is not "what a proper sysadmin uses, to the near exclusion of the GUI." I fundamentally reject that premise. I also reject the idea that you need to be tossed into the CLI deep end to learn the CLI.

      More to the point, I reject your unspoken assertion that people are only "experienced administrators" when they agree with your views on how systems administration should be done. Seems to me there are quite a few very experienced administrators - myself included - who disagree with you.

      So I’m back to “I want to know how your brain works.” Preferably with some DNA samples so I see if the issue is socialised or genetic.

      1. dz-015

        Trevor, if you're got some inferiority complex about your use of the GUI then it might be an idea to stop projecting it onto Linux/Unix administrators who have more experience than you do and who really aren't impressed with your personal attacks on the way they do things which has arisen through many years of experience and understanding that's clearly far in advance of your own. You're not making the effort to read what I'm saying or to understand it properly, and it's really getting very tiresome. I strongly advise you to give up trying to make it look like you know what you're doing with Linux and go back to your Microsoft articles. You'd be doing us all a favour.

        1. Trevor_Pott Gold badge

          Just so we're clear here - and I think it's important to be - I don't have a problem with a Linux administrator who decides he wants to run his own Linux systems in a GUIless fashion. In certain circumstances (embedded, high-density-every-MB-of-RAM-matters, ultra-high security requirements) I can understand why it might be necessary or desirable.

          But I do take issue with those administrators who feel it is necessary to lash out against others who choose to maintain a different set of tools on their servers. I especially have issues with those – like yourself – who can offer nothing excepting rhetoric to back up your decision.

          Your arguments are consistently based on unproven assumptions about human learning patterns that simply don’t hold up to empirical testing. You even trot out appeal to authority without defining that authority in anything but the vaguest of terms. “More experience than me” is one you use…except there are plenty of Linux administrators in senior positions with decades more experience than me who agree with my take on this.

          You bust out the “no true Scotsman” fallacy by implying that anyone who doesn’t agree with you isn’t a “real” systems administrator and – by virtue of disagree with you – obviously doesn’t know what they are talking about. That borders carefully on merging no true Scotsman with argument from personal incredulity.

          Other sysadmins can do whatever they want. If however they want to belittle the rest of us for choosing not to limit our options, I believe it is incumbent upon them to do a damned through job of explaining their position, and backing it up with primary sources.

          The whole debate has certainly devolved into ad homenim on both sides. Separate from my professional disagreements – and they certainly appear to be pretty fundamental – I believe your approach to this has been pretty damned douchey. You repeatedly assert yourself as superior in knowledge, character and professional capability without offering anything to back it up.

          You attack me and my credibility based on assumptions and your own personal predjudices. I think that’s pretty damned douchy. Instead of attempting to have a rational debate about the topic you have made assertions grounded in obvious logical fallacies followed by personal and professional ad homs.

          So if I obtain the impression that you, personally, may be unwell please understand that this analysis is entirely separate from the professional disagreement occurring regarding the use (or not) of GUI administration tools in various circumstances.

          I am perfectly willing, capable of (and in fact, rather enjoy) having the CLI/GUI/Both debate in a dispassionate, professional setting backed by plenty of evidence, experimentation and so forth. That said, when I believe that you personally are a giant dong, don’t be surprised if I troll you.

          After all, I have to do something amusing while yum runs 1064 package updates...

          1. Tank boy

            Well put.

            Out here in the wild there is more than one way to skin a cat.

  15. Philip Storry

    I fall more towards the CLI camp

    GUIs are nice, but they change. Because CLIs are often scripted, they become an API, and therefore don't change much over the years.

    A CLI is also, perversely, easier to document - documenting a process for a GUI often results in 20 pages of screenshots, with no real detail about what you're actually DOING. Whereas a CLI document is often much shorter, so people feel they should pad out the document with a little explanation...

    Sometimes, a GUI is superior - as others have pointed out, some selections can be hard to do with CLIs. Although if we had tools for the CLI like 4DOS/4NT/Take Command's SELECT, we'd be laughing there too.

    What I really wish is that each played to their strangths more. I've seen too many GUIs that should have had some decent reporting or status monitoring, but were instead just bunches of buttons and checkboxes.

    Conversely, I've seen CLI administered programs that were pretty poor, with minimal scripting (required input during the program) and more of an "edit the config file" attitude than actually providing a tool to make the change.

    There is no panacea. Which is lucky, as it keeps us all employed...

  16. Anonymous Coward
    Anonymous Coward

    IT was invented to automate stuff. GUIs have retarded the development and progress of that goal.

    1. Gav

      No, it wasn't

      In that case, your input was not required, automation will handle responses to this article without you.

      Or are you telling us you are browsing this website using a CLI browser?

      1. Ru

        Re: No, it wasn't

        A quick test reveals that el Reg and its commentary are useable via Lynx. I don't imagine that many would make a habit of it though...

  17. Jimboom


    I had the experience of teaching some young IT apprentices last year and helping them get their Comptia A+ certification. When we got to learning command line there was all sorts of grumbles of "why would I ever need to know this?" and "I'm never going to use this, I can do this all in windows.". At the time I never thought that they were going to learn what I considered very basic commands.

    Now, a year on the 1 young man who has done quite well for himself has told me that knowing those few simple command lines has helped him to not only do his job, but to progress his learning far beyond that of the certification.

    I say use whatever you are comfortable with. Personally I think both have a time and a place. But even now I still make simple little script files to do simple things quickly. Makes my life easier.

    But then again I find Exchange 2010 easier to administrate in GUI, even though I know there are certain things I can only do in Powershell.

    Just depends on what job you are trying to accomplish and what you feel comfortable with. But restricting yourself to one or the other simply on the fact that a CLI or GUI is what it is, well thats just plain crazy!

    1. Jimboom

      Re: Funny

      And the further point of that IT apprentice story was that without him first learning to use GUI he would never have even known about let alone used CLI

  18. vagabondo

    CLI !== Text Shell

    OSs are not restricted to one shell, and most shells are available on more than one OS. So learn a flexible shell and use it everywhere. Text shells have the advantage of also being scripting languages. Google shell is more of an apllication than a general purpose shell, so its shrtcomings as such are irrelevant.

    "If you really know what you're doing" surely a sine qua non for anyone claiming competence as a SysAdmin.

    1. Ramazan

      Re: CLI !== Text Shell

      job doesn't end with a shell (unless it's some kind of a Perl/Python shell with thousands of libs installed). You'll also need the whole POSIX environment (awk/grep/sed/pwd/find/etc).

  19. Rich 2 Silver badge

    Remote Control

    One of the single biggest advantage of the CLI over a GUI is that using a CLI, you can easily remote log-in to whatever machine you like and do stuff. This is simply not possible with a GUI. Yes, I know (and it pains me to admit that I have to sometimes use) that there are remote GUI/desktop things available, but since when did passing video over the network just to run a script become a "good idea"? It's a bloody stupid and clonky idea! This, incidentally, is one of my biggest gripes with Windows - it doesn't have a useful command line and you can't remote log in to it anyway; you have to use stupidly inefficient KVM systems to achieve what you could achieve for free and out of the box with any other OS.

    Another huge advantage of a CLI is that you can script it, and automate it. I have loads of scripts that do stuff that would be inordinately tedious and time consuming with GUI (even if it were possible at all).

    Of course, (as you already pointed out), GUI systems tend to hide settings data etc, which means that if something goes wrong, it can be very difficult to work out what; it's all simply too opaque. Pretty, but opaque.

    Of course, if you want to browse the web (to post stuff up on the Reg for example) then a GUI is great. It's just a crap idea for administering a computer system.

    1. Alister Silver badge

      Re: Remote Control

      "This, incidentally, is one of my biggest gripes with Windows - it doesn't have a useful command line and you can't remote log in to it anyway; you have to use stupidly inefficient KVM systems to achieve what you could achieve for free and out of the box with any other OS."

      Windows comes with a telnet server or remote desktop - neither are ideal, I admit, but to say "you can't remote log in to it anyway" is complete bollocks.

      1. Anonymous Coward
        Anonymous Coward

        Re: Remote Control

        > Windows comes with a telnet server or remote desktop..

        Wow. Telnet now that's going to be secure. Clear text user names and passwords over the network.

        As for remote desktop, as the original commentator said:

        but since when did passing video over the network just to run a script become a "good idea"?

        1. Alister Silver badge

          Re: Remote Control


          >Wow. Telnet now that's going to be secure. Clear text user names and passwords over the network.

          If you're going to quote me, at least do it in context. I said:

          Windows comes with a telnet server or remote desktop - neither are ideal, I admit, but to say "you can't remote log in to it anyway" is complete bollocks.

          It's also trivially easy to add an SSH server to Windows...

      2. Wensleydale Cheese

        Re: Remote Control


        "Windows comes with a telnet server or remote desktop - neither are ideal, I admit, but to say "you can't remote log in to it anyway" is complete bollocks."

        The trouble with telnet in the remote login context is that it passes usernames and passwords in the clear.

        Many of us swittched to ssh years ago and now routinely disable telnet server.

        Life would be much simpler for those of us working in multiplatform environments if Microsoft would provide an ssh client and server for their products.

        1. Alister Silver badge

          Re: Remote Control

          @Wensleydale cheese

          I agree entirely, and always prefer to install an ssh server if I have to deal with windows boxen.

          However, I was answering the original poster who said "you can't remote log in to it anyway"" referring to windows. He made no mention of secure access or otherwise.

    2. Anonymous Coward
      Anonymous Coward

      Re: Remote Control

      Um, remote desktop is pretty much standard on Windows servers now isn't it? As it pains me to admit, its actually quite good to use, especially vs things like VNC, presumably because its tied deeply into the desktop code.

      Horses for courses and all that.

    3. Anonymous Coward
      Thumb Up

      Re: Remote Control

      Windows now has a WinRS (remote shell), for all your remote text-based login needs! It's not enabled by default, you have to first configure WinRM - easiest way = winrm quickconfig

      You have also got remote PoSH too if you want it.

    4. Keith Langmead

      Re: Remote Control

      Surprised no one's mentioned PowerShell, which certainly since v2 has included the ability to remotely administer systems!

      1. Philip Storry

        Re: Remote Control

        Kind of.

        Yes, PowerShell can connect to a remote machine and yes you can administer it.

        But have you tried it for anything but Windows stuff? For example, Exchange Server? It's not very smooth. If I SSH to a Linux/BSD based MTA, I'm fine - every tool that's installed on that box is now available to me. If I run them, because I'm actually running on the remote machine, there are no issues. It all just happens over port 22, which is basically an encrypted text pipe. (I simplify, but not by much.)

        If I connect to an Exchange Server via PowerShell, I need a port 80 connection with which to fetch the special PowerShell tools that Exchange needs. I then have to create a new session on that machine, and import that session into my current session.

        (See for details.)

        It's the same for SQL Server and other Microsoft server software.

        You could view this as a security boon, albeit security by interface obfuscation. Personally, I view it as a bloody stupid way to work. The *NIX method is both more seamless and intuitive. PowerShell still has some way to really rival it.

  20. This post has been deleted by its author

  21. Dave 62

    Do you get paid to write stuff like this? I once wrote a story about a dog and his friend who was also a dog. Can I have a job at El Reg?

  22. Pinkerton

    At the risk of stating the obvious...

    > Forum denizens the internet over seem to view CLI versus GUI as a binary choice

    It's not just CLI vs GUI.

    Human nature seems to err towards *everything* being a binary choice! Whether it's Windows vs Linux, Labour vs Conservative, Man-made Climate Change vs Natural Cyclic Climate Change, Today's Music vs When I Were A Lad, Bitter vs Lager and so on.

    I reckon that for any given debate, those that are willing to see all the various hues of grey are in the minority with most commentators firmly at one pole or another.

    1. Gav

      Re: At the risk of stating the obvious...

      Not actually human nature, more like immature human male behaviour. The sort of mentality that leads to extreme fanboism, or any other obsessive devotion to mundane things.

      I always reckon it's a manifestation of adolescent development among boys, where everything is a competition and everything you do has to fit in with your chosen peer group, and must be demonstrably better than the other groups. After all, if what you buy/do/read/listen/enjoy/pursue/believe/support/create/learn is not obviously so much better than what they buy/do/read/listen/enjoy/pursue/believe/support/create/learn, how are people to know that you are better than them? Stands to reason. Therefore it must be pointed out forcefully and often, less people miss what is obvious.

      It's just a pity that some take a whole lot longer to grow out of that than others.

      1. Ramazan

        Re: must be demonstrably better than the other groups

  23. Patrick Evans

    Good grief

    Anyone bothering to even debate the absolute merits of one against the other needs to grow up. Anyone who refuses to do so needs to be put against a wall and shot.

  24. wheelybird


    Well of course you should use the correct tool for the job. I use a GUI on my desktop, and you know what; I often use a GUI file manager to copy and browse files!

    However, I find that I can't do that so easily on remote, production servers on account of not running a GUI on them and in fact not installing the libraries I'd need to use to run a GUI on them even if I wanted to. Crazy! So when you're talking about being a *LINUX SYSADMIN*, you perhaps shouldn't be surprised that people flame you for telling people to use a GUI.

    Your articles, despite the titles, simply aren't aimed at professional sysadmins and the advice you give for novice/trainee Linux sysadmins won't be applicable for a large number of Linux installations.

    1. Anonymous Coward
      Anonymous Coward

      Re: Servers

      > So when you're talking about being a *LINUX SYSADMIN*, you perhaps shouldn't be surprised that people flame you for telling people to use a GUI.

      Have to agree with you with this. Any Unix/Linux sysadmin should be able to do their job using the CLI only. This doesn't mean they can't use a GUI if available, just that they should be able to do without it.

      Up until I retired a couple of years ago, I would say about 90% of the servers I've administered were incapable of running any form of GUI.

  25. Anonymous Coward


    "Lack of standardisation is another issue; we don't live in a utopia where every operating system uses the same CLI. I, for one, have zero interest in learning a new CLI for every OS. It will take me quite some time to become as familiar with the intricacies of PowerShell for Windows as I am with Bash and its fellow tools."

    This is actually partly true, there actually /is/ some (minor!) form of standardisation at work here. To be honest I'm a little disappointed that this wasn't noticed.

    In Bash (or Ksh which is my favourite) or 'sh' (to save typing) you use ls to, well.. you know. However, modern Linux distributions also tend to honor the "dir" command.

    In PowerShell ("PS") you tend to use 'dir' but it will also easily accept the usage of "ls".

    Removing files? rm in sh obviously, PS also accepts this just like it allows "del" to be used.

    Now; in the end these are all aliases, the syntax of PS is actually a /whole/ lot different than any CLI environment I'm familiar with.

    But here is where the 2nd standardisation comes into play. When I'm at a loss on a *NIX commandline then I try to use the "man" command. This has helped me get up to speed on Solaris after not having used it for 6 years, it helped me get around HP/ux (iirc) a little.

    Actually the command I used was "man man" because I needed to check up on how I could search for something, but you get the idea...

    You may have guessed it by now but "man" is also an alias which is accepted by PS and it gives you the main help screen about the "Get-Help" command. PS will even happily accept "man man" which gets you into the same help screen.

    SO yes; I concur that PowerShell is a /whole/ lot different than Bash on Linux or a Korn shell on Solaris. But I also think that by adding those *nix -like aliases Microsoft has actually honoured a form of standardisation by itself. Which IMO does them some credit.

    Having a *nix background myself I have to say that I found PS relatively easy to find your way around in.

    1. This post has been deleted by its author

  26. LinkOfHyrule

    Windows using Idiot here...

    I sometimes type things such as search queries and passwords using the on screen keyboard - I consider myself fully bi-mousual in this respect rather than to lazy to reach forward ten inches and use the keyboard! I don't need to use command lines for work related stuff or anything and I certainly have not memorised any commands but have been known to go native under special circumstances. Maybe next time the need arises I will be mousing my commands into the console window rather than fingering my way in using the keyboard, who knows, might give it a whirl!

    I actually started using the on screen keyboard because for a while I shared a computer with a disabled person who could not type and his keyboard was literally, underneath his desk as he never used it!

    1. geekclick

      Re: Windows using Idiot here...

      Then you are..

      A: Not a sysadmin


      B: Not trying hard enough or never have anything to do that would be considered tricky..

      Exchange 2010, most stuff is and can be done via GUI, if you want to restore a mailbox from a DPM backup then PowerShell is a MUST!

      Want to see who has a file open and locked to them from a network share? Command prompt all the way..

      It is horses for courses but to get to sysadmin status and not be at least proficient in both GUI and CLI is foolish...

      No offense but i see too many boys and girls taking the first step in IT and not have the first clue about command prompt and or powershell, it makes me sad..

      1. Arrrggghh-otron

        Re: Windows using Idiot here...

        >Want to see who has a file open and locked to them from a network share? Command prompt all the way..

        You can do that from 'Computer Management' -> 'Shared Folders' -> 'Open Files'

        You can close the open files from there too...

  27. Christian Berger

    Some things are certainly wrong

    For example we do live in a world where virtually all OSes have the same CLI. By now you can have, virtually every shell on virtually every system. And even the default shells are so simmilar the layperson wouldn't even notice a difference. The notable exception is Windows, but you can get Cygwin there. (which you need anyhow to get things done)

    So stating "I don't want re-learn the shell for every operating system" as a reason is simply not a valid argument.

    But then again, reason has no place in IT.

  28. Tom 38 Silver badge

    Of course you need to use both

    You to need to use the GUI to launch xterm.

    Seriously though, this is all about personal choices. For me, it is easier to tap in "CTRL+SHIFT+T, eog /path/to/pics" than it is to "launch nautilus, browse to a folder, right click a file and choose launch in eye of gnome".

    For lots of others, it is different, but for me, almost everything is done in a terminal, but I still use a GUI to manage my terminals - I know refuseniks who simply use no GUIs, just hi res consoles. I suppose you could call the SVGA graphics mode of the browser links as a GUI...

    1. Ramazan

      You to need to use the GUI to launch xterm

      I hooked it on Win-Y key combo (xbindkeys).

    2. h3

      Re: Of course you need to use both

      You don't need to use the gui to launch xterm you can do it from .xinitrc or .xsession

      1. vagabondo

        @h3 Re: Of course you need to use both

        Did you miss the Joke icon?

        1. This post has been deleted by its author

        2. Ramazan

          Re: Did you miss the Joke icon?

          Did you ever try to do with just bare twm? (h3's advice to customize ~/.xsession is relevant for modern wm's too)

      2. Tom 38 Silver badge

        Re: Of course you need to use both

        If you are suggesting using xbindkeys or .xinitrc as ways to launch xterm without involving the X11 GUI, then I think your cunning plan may have some flaws.

  29. Ramazan

    Long time ago in a galaxy far, far away there was a guy named Jef Raskin ( Hint: you can always measure GUI vs. CLI performance for any given task.

  30. Mostor Astrakan

    I'm a Unix guy and I have nothing against GUIs.

    I've nothing against GUIs, as long as they have been well designed, and one day I hope I will see one that is. Honestly, the number of completely crap graphical apps I've been forced to work with makes me wonder whether anyone ever tries to use these things before allowing them to escape from R&D. Among the most common mistakes are:

    Hiding the useful information behind several layers of screens.

    Being completely fscking useless unless you run them full-screen.

    Wasting space on my screen with blank pixels, while squeezing the useful data somewhere in a corner

    Menu structures designed while on LSD (I don't know where this goes... Let's shove it under "Advanced" or "Tools" or "Actions"!)

    Overly ambitious misfeatures that slow down your machine to a crawl. Usually, using some kind of "Framework" that is bigger than your actual application, consumes half of whatever RAM you have, and takes ages to load. If I have the time to move my hand from the mouse to the keyboard while you start, you're slow. I still remember the PRESS PLAY ON TAPE prompt. I thought computers could load programs into memory faster these days. This is 2012. I don't want to watch applications slowly build up their screens.

    Toolbars with stupid pictures When was the last time you looked for something using a pair of binoculars or a magnifying glass?

    Tooltips. How many times have you hovered your mouse over something in the hopes that something would pop up explaining what the fsck this random collection of pixels was supposed to represent? And if you're going to tell me what the word is, why not put it on the screen in the first place?

    Non-trivial shit happening when all I do is hover the mouse somewhere. Usually obscuring the information I'm interested in.

    Modal boxes that prevent you from using some other part of the application.

    Trying to be fscking helpful when you are trying to get things done.

    Over the years, I've found just a few applications that either work well out of the box, or that I can make work properly by disabling most of the crap. The Linux file manager is one. The Linux document viewer is one - I have illustrated this by using Adobe Acrobat to open a PDF, turning to my Linux laptop to open the same file, and having it on-screen before Acrobat shows itself. All wordprocessors suck, but I now know how to make OpenLibreOffice suck less and keep its filthy mitts off the things I type. Kompozer also falls into this category. Software, whether GUI or CLI, should get on with my jobs, and stay the fsck out of my face.

    1. h3

      Re: I'm a Unix guy and I have nothing against GUIs.

      (BSD) UNIX was designed on LSD (Came out of Berkeley about the same time and the way it works is exactly how you think when you are on LSD). The whole patterns thing is nothing like the junk way that GUI's are designed.

      "There are two major products that came from Berkeley: LSD and Unix. We don't believe this to be a coincidence."

      (Even though the quote is not technically correct you can see the influence in the design).

    2. Wensleydale Cheese

      Re: I'm a Unix guy and I have nothing against GUIs.

      Class rant there Mostor!

      "Honestly, the number of completely crap graphical apps I've been forced to work with makes me wonder whether anyone ever tries to use these things before allowing them to escape from R&D"

      In the late 90s I came across a so called management console that was supposed to make life easier than using the CLI. The two main components of it that I hated were:

      User maintenance

      Nuts to that. I've got a list of 5000 users in a text file I got from another department. I'm going to use CLI and some scripting to get that lot in. I am not going to type that lot in by hand!

      Disk maintenance

      The evil side of this one was that the manufacturer's policy said this was the only officially supported way of managing disks.

      Again nuts to the GUI. The thing could only show you half a dozen disks at a time. I had several hundred to manage. Oh, the server component of that GUI would grab the disk controllers so that engineers couldn't use the serial interfaces on those controllers to do trouble shooting.

      The icing on the cake with this GUI was that it offered no way of printing out the items being managed.

  31. teknopaul Silver badge

    CLI is an API

    anyone who programs and scripts appreciates a CLI, guis serve a different purpose. you can't say in five mins click this button. you can say sleep 300 && whatever.

    those that can't code can't see the benefit of a CLI. Seeing a CLI as just a human interface missed the point entirely. CLI is an interface that both humans and computers can share. a GUI can only be used by a human, us coders have to learn the GUI then find some lib that does something similar to automate work. Learn the CLI and its all you need to know.

    the CLI interface is a long established standard you don't have to relearn, the fact that you can't get any info out of a GUI in any way other than a screenshot makes them inconvenient for programmers.

  32. h3

    I use the CLI for almost everything.

    UWIN ksh on Windows (ssh to localhost with putty)


    zsh on *nix (But I can use any interactively but I prefer some sort of tab completion)

    For scripting I use ksh93 (Sometimes POSIX subset).

    I don't like bash but don't mind tcsh and can put up with the original borne shell or the posix sh

    even cmd.exe is ok once you realise that the equivalent to deltree.exe is rd.exe in modern versions of Windows.

  33. DJO Silver badge


    I've written a fair few GUI interfaces for generating CLI instructions, where do they stand in the Evil <--> Neutral <---> Not Evil range?

  34. Alan Brown Silver badge

    Why I don't use GUI for move/delete/rename

    GUIs traditionally issue one mv/cp/rm command per file affected.

    There's a fair amount of overhead in starting/stopping commands, so being able to do it as one CLI command is normally faster and easier on the system.

  35. vgrig_us

    "real men use the command line"?

    I don't know about "real men", but real sysadmin use whatever gets job done with enough time spared to read Reg.

  36. Oninoshiko

    The GUI is better in all cases...

    or atleast is should be.

    Now that I have your attention (and ensured I will get negged by those who only read the title), let me explain why.

    The defencincies of modern GUIs are implemetaion details spacific to them, the people designing them do not understand why CLIs are sucessful, something Douglas McIlroy came up with in the 1960s. Pipelines.

    The success of most of our modern command-lines is not that commandlines are inherently more expressive then GUIs. It is the streaming nature of the common implementation; the pipeline. When I perform a complex task on the command line it always involves multiple commands on a pipeline. This is without question, the single most important feature of a CLI, the simple genius of McIlroy for this cannot be overstatedstated. The easy to comprehend structure combined with the power of this structure are why the commandline is as expressive as it is...

    So, can we apply this to a GUI? It should be possible, infact it should be slightly MORE expressive (because it should be possible to represent splitting and converging streams easily), but it would take a shift in what we think of as a GUI. I imagine the end-result would look something like Visio, with each picture representing a program, or atleast some type of manipulation on the stream.

    1. vagabondo

      Re: The GUI is better in all cases...


  37. Tom Maddox Silver badge
    Thumb Up

    Thank you!

    One of the biggest turn-offs about working in IT is the prevalent my-sideism, especially the recurring assertion of personal superiority based on how one uses technology. Explanations to fanboys of various stripes that one has an actual need for a technology or approach which is not the one they prefer tend to fall on deaf ears.

    Newsflash: your choice of technology or how you use it does not make you a superior being.

  38. Jim 59


    The article fails to mention perhaps the biggest advantage of CLI interaction: it creates a permanent history that can be saved.

  39. Stevie Silver badge


    On the other hand, I once diagnosed a perplexing problem that had had a certain department of "No GUI's, Not Now, Not Ever, NEVER" admins baffled for days by simply not knowing that is was a sign of unmanliness to boot the GUI to Sco Unixware. After a five minute poke around in the GUI to see what was what I found the clearly announced and prominently flagged network permissions issue that was new to that release and couldn't be spotted in a CLI if you looked for ever and a day if you were firmly convinced Unixware was SVR4.

    A computer is just a tool. Unfortunately, so are many of the people who are in charge of them.

  40. Ramazan

    Re: Avoiding CLIs entirely borders on career suicide

    Let's drink to that.

    On the other hand, NT server is required to have a videocard. On the server. There was a market for 2U ATI Rage XL cards 15 years ago IIRC. I don't have even the Hercules MDA on my 2 Linux routers. It should be a mystery for Microsoft guys that they work at all, but they fucking do.

    BTW in order to configure SAP or SAS or whatever requires GUI installer on let's say HP-UX machine you don't need the VGA/SVGA/SXGA/etc-compatible adapter to be physically installed in the box. X11 works just fine (and worked for all those years).

  41. Anonymous Coward
    Anonymous Coward


    I once had a boss who sneered at anyone who used a GUI over his beloved CLI (given what we were doing/working with it's somewhat understandable as for most things CLI was quicker). One day, same boss mis-typed several commands or ran them on the wrong box (can't remember) and buggered part of the production environment which impacted service, all because he was dabbling in using commands he didn't understand when it was a Windows system with RDP and he could easily have pointed and clicked.

    Believe me, his zealotry disappeared after that.

  42. John Deeb

    there is no debate^M

    "debate of GUIs versus CLIs"

    No there is no such debate at all. Only in the minds of people not completely understanding the power and terror of either activity. One cannot replace the other because at the core very different things are being processed and whole other methods are being applied. Only a fraction does overlap. At least I'm assuming serious usage.

  43. Anonymous Coward
    Anonymous Coward

    The endless debate...

    Well I use both for different things, work smarter not harder! Sometimes when troubleshooting you need the extra detail that you only get from running tools from the command line, however as a checkpoint firewall administrator if someone claims there is a "firewall" problem the first thing I do is load up checkpoint's smartview monitor at a glace I can see the status of all the firewalls, it alerts me if any are down, it lets me know that HA is working and that they all have a firewall policy and none of them are are seeing high CPU or memory load, I can see that in 30 seconds rather than logging into every firewall individually and running half a dozen commands. However when for example creating new objects on a juniper netscreen I go for the CLI option its a damn sight quicker especially if the objects have similar names and IPs.

    Use the best tool for the job! The argument is both tedious and childish.

  44. Fred Flintstone Gold badge

    There is actually a simple extra consideration here..

    In the early days of XWindows, the main reason to have a GUI was so that you could have more command line windows on one screen :)

    I see GUI and CLI complement each other. GUI is for the quick, routine stuff (which you can also delegate to people who are not quite so up to speed yet), CLI tends to be your answer if you want precise control, want to do something that wasn't quite in the original plan or want to automate something (but you'd probably write the code in a GUI editor again).

  45. asdf

    everyone knows

    The only "sysadmins" not comfortable with the command line and scripting are mouth breathing window licker MCSEs praying to make it to retirement before Windows becomes irrelevant. Not all windows admins mind you. I have seen some doing some impressive stuff with the power shell.

  46. Justicesays

    Would prefer admin gui's not to exist unless complemented by equally full-featured CLI

    The main reason people in this topic state that they have to use GUI's is because "There is no easy way of doing it on the CLI" or "The GUI presents information difficult or impossible to obtain on the CLI".

    This isnt a fault of the CLI, its the fault of the application/OS designer.

    Personally I hate it when admin tasks can *only* be accomplished in the GUI. Like being forced to use a graphical installer (bye-bye easy automated deployment) or security settings that can only be determined via GUI pages (say goodbye to automated security audit scripting).

    Sure, using a GUI can be nice when casually monitoring systems or doing a simple config change, but that task or information should also be obtainable/executed via CLI queries or commands.

    And GUI's are ideal for general information creation and display, or for unskilled users (when well written).

    Moving to GUI's means more people have to be employed to manage things, as GUI's are designed for humans to use. CLI's can be used by both humans and computers, which enables automation. Automation means one skilled sys-admin can keep on top of multiple systems and gainfully use their experience to work on new business projects. Doing the same work with GUI's requires the employment of more people, who will also be paid less, thus less skilled and less able to work on new projects.

    Of course GUI writers can try to include automation in their designs, but this has a big flaw. Automation in GUI's allows you to do what the writer wants you to do.

    Automation in a CLI allows you to do what *you* want to do.

    1. Trevor_Pott Gold badge

      Re: Would prefer admin gui's not to exist unless complemented by equally full-featured CLI


  47. Henry Wertz 1 Gold badge

    Real simple for me...

    I have a CLI preference, (if I have a terminal open I will run "firefox" rather than click the icon) but you REALLY should know both. Brief examples...

    If I just want to move *some* of the files from one directroy to another, it can be easier to control-click those couple files and put them wherever they need to go. Yes, I have seen some of my contemporaries (who view a GUI as a necessary evil) bang away for several minutes typing in filenames they could have control-clicked in probably 15 seconds flat. Also, some GUI admin tools do use fewer clicks compared to making the equivalent change to the config files (I'm not using Windows so opaque non-user-editable files are no issue for me.)

    If I want to get all my .nuv files, or files with "foobar" in the name, then "mv *.nuv /tmp/" or "mv *foobar* /tmp/" is easier than mucking about in a GUI. "ls media/*/*Top*Gear*" is easier to search through my media for Top Gear compared to clicking on a bunch of folders (and the "find" function in GUIs typically searches the *whole* hard drive, which is much slower than searching just a small tree as I'm doing.)

    So, simple. A good admin can certainly prefer one or the other interface (plenty of tasks are about as easy either way*) but you're really crippling yourself if you don't have some familiarity with both.

    *For those who aren't real familiar with the CLI, you should know about tab completion. If you see someone that seems to be typing at the CLI impossibly fast, they are probably using tab completion; you type a partial filename or program name, hit tab, and the shell completes the filename for you. (Linux and Mac do it "the one true way", Windows does it differently... with files "foobar" and "foobaz", "f-tab" will get "fooba" in mac and linux, while windows will pick either "foobar" or "foobaz" seemingly at random.)

    1. Trevor_Pott Gold badge

      Re: Real simple for me...



    2. This post has been deleted by its author

  48. Anonymous Coward
    Anonymous Coward


    rm -Rf /your/GUI

    CLI everytime.

  49. lamont
    Thumb Down

    "as long as they understand the fundamentals of how a computer works"

    Okay, i'll bite... What fundamentals are you talking about?

    The fundamentals of how systems work that I interview for are things like what strace does and what a system call actually is, and what subsystems one would expect to see in a unix or unix-like kernel. Explain the TCP 3-way handshake, or explain how traceroute works. Other interviewers like to use the boot process question.

    Generally you find very little understanding of the /fundamentals/ of how a computer works in people that just push around the mouse on the GUI. Those are the admins who don't know TCP at all or who barely stumble through SYN, ACK, SYN|ACK (yes, usually in that order). The ones that know options negotiation and PMTU discovery, SYN cookies, etc are the ones that also have strong commandline fu.

    Only using a GUI keeps you dumb.

    1. Trevor_Pott Gold badge

      Re: "as long as they understand the fundamentals of how a computer works"

      I would consider most of that "fundamentals," yes...but that's just scratching the surface.

      I'd add understand file layouts. Specifically how files are organised on a hard drive; the difference between a block of data and and file system information. (Raw storage versus indexes, journals, etc.) The basics of various partition types, limits, features, etc. Why you have to "eject" removable storage on most systems (delayed write!)

      Understanding how applications use tiers of memory, from L1 up to (at least) a basic understanding of ASLR in main memory. The concepts of tiered storage, deduplication (memory in re: virtualisation and block storage/file storage for the physical stuff.) DAS versus NAS versus SAN.

      ON the networking side being able to say "synchronisation, synchronisation, enquire" is cute, but I want an understanding from my PFYs regarding "buffer bloat," and what the various different "experts" in the field are still arguing about. (Yes, buffer bloat is still a debated topic.) I want them to be able to explain spanning tree, network reconvergence, broadcast domains and VLANS.

      They need to know about MAC addresses. Specifically that they are emphatically not globally unique, that the manufacturer is part of the beginning of the address and that virtualisation generates virtual MACs for each vNIC. They need to be aware of issues surrounding MAC address conflicts and what the symptoms are.

      I want an understanding of system services, scheduled tasks, how to avoid resource starvation cascades (system-local, but especially in auto-failover virtualised environments!) This carries over from the simple system utilisation into networking of course; an understanding of everything from link saturation to overloading network gear with too many connections is pretty “fundamental.”

      I would also expect a basic understanding of scripting, even if they aren’t very good at it (yet.) This would include the concept of data extraction from one application, parsing that data for another application, injecting it and analysing the result. (Chaining.)

      I think knowledge of how a hypervisor works, including a basic understanding of things like VT and IOMMU are pretty fundamental. An understanding of basic electrical theory (including digital to analogue and analogue to digital signalling) is pretty important.

      I’d also toss in an understanding of how graphics are output from display subsystems; why some remote applications are “screen scrapers,” while others can use “mirror drivers” and still others actually send raw data and expect the client application to construct a graphical representation locally instead of dragging imagery across.

      Without the above knowledge as a bare minimum, I don’t think you can survive proper SME systems administration. You need to know the fundamentals of “computing.” Not just “that application, shell or OS.” You don’t have a team to rely on; there are no storage specialists, network specialists and so forth. As SME sysadmins, we’re it.

      Oddly enough, I find the above level of information pretty common for sysadmins in their second year out of our local polytechnic. I’d say the city of Edmonton produces these folks at a rate of about 30 per year. (From a graduation size of about 90 per year.)

      Oh, and yes, they are almost universally GUI-grown. They know some command line, but the young folk I encounter who know all of the above things to a reasonable degree aren’t steeped in the dark arts of Bash. They don’t run slackware on their home PC, and most of them use an iPhone.

      Get one that’s willing to learn, teach them the power of the command line…and you’ve got a right proper sysadmin there.

    2. Anonymous Coward
      Anonymous Coward

      Re: "as long as they understand the fundamentals of how a computer works"

      > stumble through SYN, ACK, SYN|ACK (yes, usually in that order).

      Actually it is SYN, SYN|ACK, ACK

      In plain English.

      1. The client sends out a SYN packet with its starting sequence number.

      2. the server responds with a SYN|ACK packet that acknowledges the clients sequence number and also send its own starting sequence number.

      3. The client sends back an ACK that acknowledges the servers sequence number.

      The client and server can now communicate.

      Do I get the job?

  50. seraphim


    These "holy wars", be they vi/Emacs (and gods forbid you bring up an IDE around that crowd), Windows/Linux, GUI/CLI, all strike me as dead silly. It's like watching two carpenters argue over whether a screwdriver or a hammer is invariably better for all situations, and when you ask "Well...are you trying to put in a nail, or a screw?", getting a blank stare and a sarcastic inquiry as to how that could possibly be relevant.

    Trying to design a "one size fits all" tool inevitably results in one size doesn't fit any very well. If I need to automate or script a medium to large process, CLI is almost certainly the way to go. If I need to do significant manipulations to the filesystem, CLI. If I need to write an actual formatted document or read my email, probably GUI. If I'm handling a large and complex codebase with many dependencies, I may prefer to do that in an IDE (involving a GUI, of course) rather than a commandline text editor, but if I need to make a quick change, vi is probably significantly faster and easier than firing up Eclipse and throwing it in there. And while it's not my personal preference, if someone else prefers Emacs to vi, I don't care. It's their work to do, they should use whatever they're most efficient in, not what I'm most efficient in.

    Figure out what you're doing, and then pull the best tool out of the toolbox. That's what real professionals do.

    1. Spiff66

      Re: Why?

      You must have strayed into the wrong forum. That's far too sensible a comment for the frothing hordes here.

  51. Jay 2

    I'm more of a CLI guy, as it was drummed into me a long time ago then when (UNIX) boxes go wrong you've usually only got a CLI console session and vi to try and fix everything. The point being that you can't always rely on a GUI. That was slightly more in the days of X, though even now apps or web-based GUIs still need something to connect to. Mind you back then it was almost always quicker/easier to use a CLI than (on Sun kit) run admintool or the horrors that were AdminSuite/DiskSuite. And as others have pointed out, when you have to automate something, then the CLI is usually your friend.

    Plus on the more practical side, none of the Linux boxes I look after has a windowing environment installed so it's not as if I have a choice! Though from remote point of view handy things like FileZilla client and even the web front end for Dell's OMSA do allow you to take a quick glance at what's going on without having to resort to CLI antics.

  52. FreeBrad

    Everything has its place

    On AIX I use cli for most things but there are times when I need the gui interface. The gui on AIX is ancient, CDE1.0 but it does enough to copy and paste up conf files and for debugging purposes. There is no doubt that a gui helps to jog the memory, but if you have a reasonable memory for commands then cli is way quicker.

    Having said that windows NEEDS the gui. The layers upon layers of code and the complexity in windows mean that it would be difficult to find anything without the gui. Rooting through the AD schema or the registry using cli if you are not entirely sure what you are looking for does not really sound appealing.

    Powershell is good although my experience is limited to the MS Exchange server version, but why on earth do the commands have to be so bleeding long?

    Having said all that, if you want to win a CLI vs GUI argument in favour of the CLI give someday a cisco router. I could have set up the entire thing in the amount of time it takes for the GUI to "discover" the thing.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2020