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 …
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+
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.
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.
This post has been deleted by its author
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)).
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.
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.
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.
The terminals of MacOS, Linux and Unix are all similar.
For Mac OSX and most GNU/Linux :
:~$ echo $SHELL
/bin/bash
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.
@Ramazan
"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!"
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.
Profit.
Leave the holy wars to the wannabes who think reading everything in hex makes them 1337.
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.
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.
@eulampios You are absolutely correct; until PowerShell, there wasn't anything grep-like. PowerShell 2.0 however...it'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.
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.
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.
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"
Grr.
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.
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.
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.
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+.
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.
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".
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.
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.
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...
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...
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!
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.
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.
"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.
> 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"?
@AC
>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...
@Alister
"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.
@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.
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 http://technet.microsoft.com/en-us/library/dd297932.aspx 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.
This post has been deleted by its author
> 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.
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.
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.
> 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.
"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.
This post has been deleted by its author
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!
Then you are..
A: Not a sysadmin
or
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..
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.
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...
This post has been deleted by its author
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.
(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).
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.
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.
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.
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.
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.
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.
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).
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.
"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.
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.
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).
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.
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.)
This post has been deleted by its author
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.
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.
> 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?
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
