Take This GUI and Shove It 617
snydeq writes "Deep End's Paul Venezia speaks out against the overemphasis on GUIs in today's admin tools, saying that GUIs are fine and necessary in many cases, but only after a complete CLI is in place, and that they cannot interfere with the use of the CLI, only complement it. Otherwise, the GUI simply makes easy things easy and hard things much harder. He writes, 'If you have to make significant, identical changes to a bunch of Linux servers, is it easier to log into them one-by-one and run through a GUI or text-menu tool, or write a quick shell script that hits each box and either makes the changes or simply pulls down a few new config files and restarts some services? And it's not just about conservation of effort — it's also about accuracy. If you write a script, you're certain that the changes made will be identical on each box. If you're doing them all by hand, you aren't.'"
GUIs make documentation hard (Score:5, Interesting)
With a CLI or a script that's easy: it comes down to "log in as user X, change to directory Y, run script Z with arguments A B and C - the output should look like D". Try that when all you have is a GLUI (like a GUI, but you get stuck): open this window, select that option, drag a slider, check these boxes, click Yes, three times. The output might look a little like this blurry screen shot and the only record of a successful execution is a window that disappears as soon as the application ends.
I suppose the Linux community should be grateful that windows made the fundemental systems design error of making everything graphic. Without that basic failure, Linux might never have even got the toe-hold it has now.
GUI interface can sell a product to management (Score:5, Interesting)
Without a GUI it will be hard to sell, but automation is next to impossible with GUIs, so they are expensive to use in the long run because you have to pay for more Users.
not entirely sys admin related (Score:2, Interesting)
In most of my professional life, if there's an OSS alternative the OSS alternative is usually better. LateX is more professional than Office, in my opinion. I prefer the look and repeatability of gnuplot over Excel. Python is much more extensible than VBA. SQLite and python really helped me clean data for my professional paper, as well.
Granted, I'm using Microsoft Office in addition to the aforementioned (except LateX).
/etc/resolv.conf (Score:3, Interesting)
Agreed. For instance, I've been trying to figure out how to add a simple "search" entry into resolv.conf in Fedora .. it keeps overwriting it on boot no matter what level scripts I modify (e.g. going up to DHCP config, etc.) - because some genius came up with a new admin tool and thought that something as basic as resolv.conf doesn't need to be followed.
Re:Better test! (Score:4, Interesting)
Well, one little mistake pushing a windows domain policy via GUI, and the same.
This is one of the weakest points in the article, IMO, though. It's quite possible (even if MS MMC is a kludgy example) to GUIfy multi-system administration.
There will always be a place for both GUI and CLI -- status screens, for example, generally demand a GUI (and yes, ANSI menu systems are a GUI.)
Re:One small problem... (Score:5, Interesting)
Its cheap, its easy and its stable. I'm sure if you look through all of the businesses running servers, very few of them are ran by real "admins" but rather by the employee who "knows about computers"
Webgui? Just use cUrl (Score:5, Interesting)
I have a cheap router with only a web gui. I wrote a two line bash script that simply POSTs the right requests to URL.
Simply put, HTTP interfaces, especially if they implement the right response codes, are actually very nice to script.
Re:ITT: "Get off my lawn" (Score:5, Interesting)
Probably because it's also about the ease of troubleshooting issues.
How do you troubleshoot something with a GUI after you've misconfigured?
How do you troubleshoot a programming error (bug) in the GUI -> device communication?
How do you scale to tens, hundreds, or thousands of devices with a GUI?
CLI makes all this easier and more manageable.
Re:ITT: "Get off my lawn" (Score:4, Interesting)
I don't think you really understand systems administration. 'Users,' or in this case admins, don't typically do stuff once. Furthermore, they need to know what he did and how to do it again (i.e. new server or whatever) or just remember what he did.
One-off stuff isn't common and is a sign of poor administration (i.e. tracking changes and following processes).
What I'm trying to get at is that admins shouldn't do anything without reading the manual. As a Windows/Linux admin, I tend to find Linux easier to properly administer because I either already know how to perform an operation or I have to read the manual (manpage) and learn a decent amount about the operation (i.e. more than click here/use this flag).
Don't get me wrong, GUIs can make unknown operations significantly easier, but they often lead to poor process management. To document processes, screenshots are typically needed. They can be done well, but I find that GUI documentation (created by admins, not vendor docs) tend to be of very low quality. They are also vulnerable to 'upgrades' where vendors change the interface design. CLI programs typically have more stable interfaces, but maybe that's just because they have been around longer...
Re:Bad GUI and no CLI: way too common (Score:2, Interesting)
Not saying it's easier for all people, but for most people, I can see where they're coming from. Sadly, I know alot of companies who don't want their admins to be the best, they want their admins to be the most efficient. They equate 'clicking' with quick, and typing out 'lines and lines of code' as long and arduous, and expensive.
Re:Config files. (Score:3, Interesting)
Yeah, instead of flat text conf files, why don't we put a whole bunch of config in some obscure place in the registry somewhere...
i entirely fail to see the point as to why you would want a gui to do something that is integral to the cli.
Re:Bad GUI and no CLI: way too common (Score:1, Interesting)
That's just because you haven't written a decent GUI for those options yet, it doesn't mean it couldn't be done if one wanted to.
Really, find isn't always faster or better, especially since most scripts or tutorials you find online use -exec instead of |xargs.
Hell, even the man page uses -exec in its examples instead of the superior xargs.
Re:Well there's another side to that (Score:2, Interesting)
Re:Better test! (Score:3, Interesting)
If you write a script, you're certain that the changes made will be identical on each box.
One little mistake in the script and you fuck up the whole organization.
It is also easier to fix scripted errors because the error is identical in all places. I often find myself using sed to make complicated changes to config files and keeping backups or putting the changed config into a temporary file to get diffs of the results. In the odd case that something gets messed up in production, then it is usually another sed command or two to fix it.
With a GUI it is harder to verify that you are making the desired changes beforehand, and if you do mess it up royally, then you are usually touching all of the configs individually with the GUI to fix your mistake.
With the cli in the hands of someone who know what they are doing, the fixes can be implemented in seconds (or less).
Re:Bad GUI and no CLI: way too common (Score:3, Interesting)
Why would you even want Server 2008 to run without a GUI? The windows command line tools are dodgy and it only takes up like 64MB of your 16GB server memory.
got this from Fyodor's Good Reading List (Score:2, Interesting)
Re:Well there's another side to that (Score:3, Interesting)
All I have to say is: Amen! (in a nonreligious sort of way)
I'm a not very good programmer who is a good system admin. I've been fighting the general apathy to anyone who can't read the source for the linux kernel in the linux world for going on a decade now! I'm always being told 'write it yourself' when I bump into a wall in administering linux systems that would be a simple button press in Windows... I don't want to reinvent the wheel! I'd frankly suck at it! That A) doesn't mean I'm a bad admin and B) Isn't something I even have time for in my day.
I can just see my last employer waiting as I read through 10k lines of source code to figure out why X isn't working with Y. Those above me want things to 'just work' and when they don't and it takes time to fix it's the end of the world. I'll take tracking down the idiot on the campus who plugged the network cable into the same switch twice over writing my own app any day.
Re:Bad GUI and no CLI: way too common (Score:2, Interesting)
What would be even nicer is if they started using OpenBSD on the routers so we could use pf instead of iptables.
Refusing to feed the beast is not mindless (Score:2, Interesting)
Re:Well there's another side to that (Score:3, Interesting)
I find it rather disturbing the UNIX ideal that sysadmins should be programmers. The opinion seems to be that it is perfectly ok for someone to need to do a fair bit of programming work to solve a system problem.
Not only have I spent over 10 years as a professional *nix system administrator, I currently work training professional system administrators. I don't know *anyone* who thinks that a system administrator should be a programmer. That being said, shell scripting is a tool of the skilled system administrator. Writing simple scripts is nothing like programming. While shell scripts can be quite complex, most that a system administrator would write are very simple. Really just a series of commands.
I know more than a few programmers that are abysmal at system administration...
And how! The vast majority of developers I know are terrible system administrators. There is a reason we keep them as far from the production systems as possible. The problem is that they think they do know system administration, but they have a completely different mindset.
...this attitude smacks of the "People should just get down and code what they need," thing. No, not really. Not everyone should have to learn that skill, and you could well be excluding people you want by requiring it.
Again, I don't know anyone who thinks this. People should learn the tools they are being paid to work with. That includes shell scripting. Now, some shops like to write a lot of in house tools in perl or python and will look for people skilled in system administration as well as those languages. Most big shops have a small number of sys admins who can write such tools. Don't confuse the tools team with the rest of the sys admins. This is a specialized role.
Also there's the simple matter that GUIs work better for unfamiliar situations. While it might be easy to just say "Well a good admin should know about this," that is rather stupid. Nobody knows everything, you never get someone with limitless experience. Part of systems administration is being able to solve novel problems.
I could not disagree more. While a GUI might help someone plod through without really understanding what they are doing, this is not a good thing. I agree that no one knows everything. However, a skilled sys admin can research and learn new things when needed. Most GUIs just get in the way of learning and deeply understanding. Then when something doesn't work as expected, you are SOL. Or you miss a subtle issue that bites you in the ass later.
I'd like to point out that I use GUI tools all the time. However, I make a point of learning the technology I am paid to understand. When I use a GUI it is because it is the best or most convenient way to get something done. I can also tell you all the places on the system that GUI changed and what to do if something went wrong.
That can make it much faster to deal with something you are not familiar with. This is important and useful in real IT work.
I have worked in IT for long enough to know this isn't true. The simple reality is that most people working in IT suck. Seriously. I have interviewed and worked with more than enough of them. They use GUIs as crutches. They are over worked and have no time to learn anything even if they were so inclined. They have a very shallow understanding of the technology they are paid to understand. They choose "easy" tools instead of tools that require learning. It is the sad state of things that truly skilled system administrators are a rare find.
Should everything be CLI? Of course not. Should everything be GUI, of course not. However, to say that GUI tools are better because you don't have to be familiar with them is a very scary attitude if you ask me.
Re:Bad GUI and no CLI: way too common (Score:3, Interesting)
I couldn't agree more which is why it's really cool that the Exchange GUI tools will show you the exact PowerShell commands they are running if you want to learn how to use the CLI (and in fact that are still things that can only be done in the CLI, though the list is greatly reduced in EX 2010 vs 2007).
Crap. I was hoping they would've encouraged more CLI and less GUI... (using Exch2k7 here - haven't had time to dink with 2010 yet). I'm guessing the typical MCSE types (comprising the majority, not the whole) have decided that command-line stuff must be too hard to learn.
Re:That is entirely irrelevant (Score:3, Interesting)
Only that you went back to mention Scripting under CLI. True, every OS I seen that implements it allows for it to be scripted, but this is not necessarily true.
An application can be written with dual interfaces, GUI + CLI (at least in windows) and [arguably] bad design can lead the CLI to require a user to confirm actions without allowing the confirmation to be scripted.
On a similar line, I have seen GUI programs that have designed CLI equivalents for every menu and button with confirmation bypass parameters.
As you said at first, in the end, it's just a third tool, one meant for programmers or at least power users with at least minimal programming experience.
This will sound odd, but there are users that can work a CLI but can never ever program a single line of code. I worked in a company that has a completely CLI collection software. Not only is it impossible to script, but everyone uses it yet these are people that can't get the difference between shutdown and hibernate.
Re:Well there's another side to that (Score:1, Interesting)
So a good sysadmin that knows GUI is cheaper on the payroll than say, a sysadmin that can master a CLI. Good to know that when standing in the unemployment line. Learn your freaking GUI for a job!
Re:Bad GUI and no CLI: way too common (Score:3, Interesting)
It's been years since I administered an AIX machine but my recollection is that the CLI command strings it came up with were generally amusingly-specific unique-to-AIX commands with very long names like resizepartitionandinstallbootblock or something like that. They were generally specialty scripts built to parallel SMIT menu choices and you'd never wind up guessing the command without SMIT telling you what to use, but having the command-line version was nice because you could do something by menus in SMIT on one machine and then use the command-line equivalents to automate the same operations on dozens of other hosts.
Re:Bad GUI and no CLI: way too common (Score:3, Interesting)
1) Your argument against CLI is a moronic volume mounting system designed explicitly to only be used with a GUI. Really, the whole C:, D:, E: thing was fucking moronic. The Unix scheme of mounting seamlessly as a folder under /, in a way which renders the underlying volumes invisible is far saner (which is, of course, an entirely separate debate from the merits of CLI vs. GUI, but a personal pet peeve with Windows).
2) Tab completion. I don't think I've ever typed more than 5 letters of a filename, of any length.
Comment removed (Score:3, Interesting)
Re:Bad GUI and no CLI: way too common (Score:2, Interesting)
GUIs are unquestionably faster for simple things. Copy this file here. Select this word that's miles away from the input cursor.
Even for simple tasks I find the CLI faster. A few days ago I was playing with this idea, so I ran a little timer ($time read x) to find out how much time did it take to do simple tasks like the ones you mention. In every tasks, I was faster in the CLI, except for renaming one file.
Re:/etc/resolv.conf (Score:3, Interesting)
Re:Bad GUI and no CLI: way too common (Score:4, Interesting)
Could be configuraion syntax. Simple, readable, concise, possible to understand even in very complicated scripts without looking at the manual. I'm using iptables routinely, but I liked pf for its simplicity.
Re:Better test! (Score:3, Interesting)
Actually they had no clue what a 'good server' was, so when they left it up to me they were functional and up to date systems. Though most of our windows servers were from HP's server line.
Others not so much, like when they decided web hosting should move in house and gave me a zero dollar budget. So I cannibalized a bunch of antique desktops and made a new 'linux apache web server'.
Funny enough I'd gotten a 5k raise every year (much needed though as the pay started fairly low for an network admin). Though with a change in leadership the board took power and they decided I was to expensive and outsourced me about a year ago. Hence it was 'my last employer'.
OOS did ok, though it's still not the year of the linux desktop. Remember I said I had to keep a bunch of antiques running and made them linux? Well normal people would use them, or more not use them. They were considered non-functional by everyone that used them and this is ubuntu, so the interface wasn't exactly CLI and not terribly unlike windows. On the server end I could have probably pieced together another antique web server, but I didn't really need much of a test system for a limited use web server...
Btw I argued against getting the web server in house. We existed on a 2Mb fiber connection (they chose to only pay for 2Mbps anyways), having the web server take away from our already pathetic bandwidth was a bad idea...
Re:/etc/resolv.conf (Score:1, Interesting)
situations like that makes me wish dtrace was also available on linux.