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 …

COMMENTS

This topic is closed for new posts.

Page:

        1. This post has been deleted by its author

        2. Ramazan
          Joke

          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)

      1. Tom 38

        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.

  1. Ramazan
    Coffee/keyboard

    Long time ago in a galaxy far, far away there was a guy named Jef Raskin (http://en.wikipedia.org/wiki/The_Humane_Interface). Hint: you can always measure GUI vs. CLI performance for any given task.

  2. Mostor Astrakan
    Flame

    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.

  3. teknopaul

    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.

  4. h3

    I use the CLI for almost everything.

    UWIN ksh on Windows (ssh to localhost with putty)

    or

    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.

  5. DJO Silver badge

    Doh!

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

  6. 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.

  7. 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.

  8. Oninoshiko
    Megaphone

    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...

      Smalltalkish?

  9. 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.

  10. Jim 59

    History

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

  11. Stevie

    Bah!

    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.

  12. Ramazan
    Pint

    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).

  13. Anonymous Coward
    Anonymous Coward

    Anecdote

    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.

  14. John Deeb
    Boffin

    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.

  15. 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.

  16. 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).

  17. 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.

  18. 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

      Amen.

  19. 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...

      Start-->Run-->\\some-server\somefolder\somesubfolder

      Mynetworkwhatnow?

    2. This post has been deleted by its author

  20. Anonymous Coward
    Anonymous Coward

    CLI

    rm -Rf /your/GUI

    CLI everytime.

  21. 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?

  22. seraphim
    Meh

    Why?

    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
      Happy

      Re: Why?

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

  23. 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.

  24. 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.

Page:

This topic is closed for new posts.

Other stories you might like