Slashdot Mirror
Take This GUI and Shove It
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.'"
Here is a Link to the print version of the article (that convenientily fits on 1 page instead of 3).
Providing a great GUI for complex routers or Linux admin is hard. Of course there has to be a CLI, that's how pros get the job done. But a great GUI is one that teaches a new user to eventually graduate to using CLI.
A bad GUI with no CLI is the worst of both worlds, the author of the article got that right. The 80/20 rule applies: 80% of the work is common to everyone, and should be offered with a GUI. And the 20% that is custom to each sysadmin, well use the CLI.
--
dead simple alternative to incorporating for web startups
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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.
RIP America
July 4, 1776 - September 11, 2001
I think the author might not fully understand who most admins are. They're people who couldn't write a shell script if their lives depended on it, because they've never had to. GUI-dependent users become GUI-dependent admins.
As a percentage of computer users, people who can actually navigate a CLI are an ever-diminishing group.
Am I part of the core demographic for Swedish Fish?
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.
http://michaelsmith.id.au
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).
PS: I don't reply to ACs.
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.
There are more and more small businesses (5, 10 or so employees) realizing that they can get things done easier if they had a server. Because the business can't really afford to hire a sysadmin or a full-time tech person, its generally the employee who "knows computers" (you know, the person who has to help the boss check his e-mail every day, etc.) and since they don't have the knowledge of a skilled *Nix admin, a GUI makes their administration a lot easier.
So with the increasing use of servers among non-admins, it only makes sense for a growth in GUI-based solutions.
Taxation is legalized theft, no more, no less.
Config files are one of the problems with linux. Most of them are far too hard to parse and modify so there aren't any GUI tools to do so. For example, how do you change the PATH in linux through the GUI? As far as I know there is no way. In windows it is (fairly) simple.
Of course there's no reason why you can't have the best of both worlds - every program can be abstracted into a CLI and GUI on top of the same base library.
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.
Dilbert RSS feed
This is also a problem with Max OS X Server. Apple builds their services from open source products and adds a GUI for configuration to make it all clickable and easy to set up. However, many options that can be set on the command line can't be set in the GUI. Even worse, making CLI changes to services can break the GUI entirely.
The hardware and software are both super stable and run really smoothly, so once everything gets set up, it's awesome. Still, it's hard for a guy who would rather make changes on the CLI to get used to.
Help I'm a rock.
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. Ok but the thing is programming and systems administration are not identical skills any more than say being a musician and being a recording engineer are. They are related, but proficiency in one is not the same as the other. I know more than a few programmers that are abysmal at system administration, and I know sysadmins that can't program. There is nothing wrong with this.
While I realize a simple (emphasis on simple) script isn't quite the same thing, 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.
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. Ok well GUIs help in that regard, at least when well designed. They show you your options, and how they flow, what ones exclude and influence others and so on. That can make it much faster to deal with something you are not familiar with. This is important and useful in real IT work.
They also can help prevent errors. For example I can't count the number of times our DNS has been temporarily broken by a student messing up the file. If you do the formatting incorrect, screw up the serial number, etc and suddenly things stop working (we have it in a versioning system so it can be undone easily, of course). In Windows? Not a problem. The GUI keeps you from screwing things up. You can still make a bad entry or whatever, but you can't go and break the entire server.
I'm not saying there's anything wrong with the command line, or that it should go away. However the idea that everything should be CLI based is silly.
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.
Support FSF: Stop thinking with your wallet, and think with your imagination. (cc/non-commercial)
That's one thing Microsoft did right with Exchange 2007. They built it entirely around their new powershell CLI and then built a GUI for it. The GUI is limited in compared to what you can do with the CLI, but you can get most things done. The CLI becomes extremely handy for batch jobs and exporting statistics to csv files. I'd say it's really up there with BASH in terms of scripting, data manipulation, and integration (not just Exchange but WMI, SQL, etc.)
They tried to do similar with Windows 2008 and their Core feature, but they still have to load a GUI to present a prompt...
I'm a virgo and on Slashdot. Coincidence? Yes.
it's called a "core" install in Server 2008 and up, and if you do that, there is no going back, you can't ever add the GUI back.
What this means is you can run a small subset of MS services that don't need GUI interaction. With R2 that subset grew somwhat as they added the ability to install .Net too, which mean't you could run IIS in a useful manner (arguably the strongest reason to want to do this in the first place).
Still it's a one way trip and you better be damn sure what services need to run on that box for the lifetime of that box or you're looking at a reinstall. Most windows admins will still tell you the risk isn't worth it.
Simple things like network configuration without a GUI in windows is tedious, and, at least last time i looked, you lost the ability to trunk network poers because the NIC manufactuers all assumed you had a GUI to configure your NICs
Normal people worry me!
Because then you'll be stuck at doing simple tasks, and will never be able to do more advanced tasks. Without hiring a team to write an app for you instead of doing it yourself in two minutes, that is.
The time you spend reading man pages is an investment which pays off in the long run. But if you belong to the instant gratification generation, that may not be what you want, no...
In a directory hierarchy, find files with the extension ".ftl" that have been modified since the last SVN revision, and containing the expression "${inventoryItem.qoh}", and for each of these, substitute "${inventoryItem.atp}".
I'd love to see GUI's that can facilitate the kinds of work I do on a constant basis, but since there's no such thing, I've become something of a Unix shell power user over the past couple of decades.
-fb Everything not expressly forbidden is now mandatory.
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...
Duhh... He does show a keen grasp of the obvious. And for people who use command lines he is preaching to the choir.
On the other hand for the GUI based people, they will miss it entirely. They will talk about add on GUI replay tools that allow one set of mouse clicks to be replayed to many different servers, or configuration management tools that do the work for you. I believe they truly do not understand that someone could get 20 mouse clicks on 40 different servers wrong. "Why would someone ever click the wrong check box?" They also believe that screen shots are valid ways to store configuration information off line.
Only half in jest.
RLH
OTOH, I'd say if there's an important security setting, and it's not set to the secure value by default (or, if that is not possible, gives an error when not set explicitly), that's a design error in the application.
Also, empty configuration files IME are rare nowadays; usually they are pre-filled with (mostly commented-out) example-settings with explanations in comments. Which often allows you to just uncomment the settings you want, instead of writing the complete command by hand.
BTW, comments are another advantage of config files vs. GUIs. Not only because you can state the reason why you put a certain setting right at the setting itself, but also because when you change a setting you can just comment out the previous setting, and therefore easily undo whatever you changed (another option for that is, of course, to make a backup copy of the original config file). I don't see how you can do that with a GUI.
The Tao of math: The numbers you can count are not the real numbers.
A few other people have mentioned UIs that do precisely this, but to add another example: a lot of database administration GUI tools allow you to graphically create tables, indexes and other schema objects, and export the SQL script to recreate them automatically.
Are you adequate?
it's called a "core" install in Server 2008 and up, and if you do that, there is no going back, you can't ever add the GUI back.
Win2008 Core still has a GUI. It's just that it's a GUI that only has a single graphical terminal window open by default, but nonetheless there's a window manager and all the other stuff. And you can open more terminals, and run GUI apps which open their own windows as well (if I remember correctly, it does have Notepad out of the box which can be used that way).
That said, resources consumed by such a thing are so tiny that they won't be noticed even on a mid-range modern desktop, much less an actual server. And it does make life somewhat easier when you actually have to work with it directly (e.g. because ssh is failing for some mysterious reason).
But what happens if the system stores those values opaquely, so that you can't ever know what they are, or refer to them as something distinct from the system itself?
The Windows registry.
Apparently, it's fully documented, and much easier to understand, parse, manipulate, backup and restore than those nasty "config files" that need to be "edited manually" using "cryptic commands".
Or so I'm told. ;-)
Your comment on the "rote memorization" aspect of using GUIs I found particularly astute. When I see official documentation that consists of a little other than a series of screenshots, I wonder how it came to be that behaving like a monkey, or more charitably, aspiring to ignorance, became not only widespread, but acceptable.
Probably Debian would have been OK, but I was finding admin of most Linux distros a pain for exactly these reasons. I couldn't find a layer where I could do everything that I needed to do without worrying about one thing stepping on another. No doubt there are ways that I could manage a Linux system without running into different layers of management tools stepping on each other, but it was a struggle.
There were other reasons as well (although there is a lot that I miss about Linux), but I think that this was one of the leading reasons.
(NB: I realize that this is flamebait (I've got karma to burn), but that isn't my intention here.)
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
http://www.insecure.org/stf/scoville_unix_as_literature.txt Sums up my feelings very nicely. Sure the GUI is good for some things, but after hours it leaves me lacking in understanding, since I have been essentially reacting to my computer instead of telling it when I want it to do.
you don't eat crackers in the bed of your future--or else you'll get all scratchy
'admins don't typically do stuff once' WTF world do you live in...? I administered a 500 user network a bit over a year ago and very few things were repeated. I set up servers once, and then unless I needed to change something I didn't need to reconfigure them. Now some things like new user accounts is common and repeatable... But those take 2 or 3 minutes and it's done, unless you really cycle massive amounts of employees this should never be more than a half hours work... And a GUI is easily adept at simple repeated tasks. In my 4 years I found little need for scripted anything outside an oracle database and maybe some rare cases with exchange (of all things). Everything else was usually taken care of from a centralized system once, and rarely if ever done again.
we are all invisible unless we choose otherwise
"If your GUI dosn't offer the same advantages than a console/terminal text interface, then your GUI is lacking some features and is a GUI for some but not all your needs, very common in the nix world btw"
Now, please, tell me how well a GUI-oriented environment copes with:
* Repeatability (I want exactly the same you did yesterday on server A, now on server B)
* Auditory (what did change in this server from yesterday, who did it?)
* Automation (remember what you did yesterday on server A? I want you to do it again on server B; but do it tonight at 2AM -no, no extra hours payment allowed)
* Conformance (now that we know how exactly it has to be done from our working on the test environment, let's do it -without mistakes, in our 100 production servers)
* Orchestration (let's do changes a, b and c on servers A, B and C as fast as possible, without mistakes, in proper order and each step only after being sure the previous one is properly working -oh, and let's do it at 2AM -why do you ask it again? No, no extra hours payment allowed)
For I know all of them are virtually trivial on text-based CLI-oriented systems.
The last Microsoft product I bought was Windows 98, so I have mercifully missed the whole disaster since then. All my clients are just now starting to switch from XP to Windows 7, because I advised against Vista. And in all these years of supporting dozens of computers I have never heard of PowerShell until this article. It's nice to hear that Microsoft is starting to do what I did on Unix in 1980. Too bad they did not build on Xenix, and save everyone much grief. Imagine where Apple could have been in the 90s, had they switched to Unix a decade earlier.
It wouldn't have been so bad if Microsoft had just supplied a generalized configuration parser for application developers to use. Then it could be applied to files, streams, digitally signed blobs, whatever.
But no, they had to build another way to lock you in, didn't they? So you don't get the security controls or network transparency of the file system. You're not reusing the file system, so you have added another source of complexity and another attack surface for security. You don't get composability or scope control where one subsystem can feed live configuration data to another.
And if the Registry breaks, you're kind of hooped. Sure, there's regedit, but it's off to the side, not part of the main paradigm. Mostly it serves to remind you of what you're missing. It's far from common practice to track changes to the Registry in order to monitor how an application has been configured. And that's because the application has not necessarily used the Registry. So tracking it is in general neither necessary nor sufficient.
Ooh. Don't get me going.
Parity: What to do when the weekend comes.
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.
If you were to read a how-to on a blog about configuring a router using a GUI, it would take a few pages. If it were about configuring a router using a CLI, it would fit in one page. Bottom line: in today's world where a forgotten command can be remembered quickly using our friend Google, I much prefer CLI because it makes me read less, and do more.
iTx Technologies: Open source development in Montreal
GUIs can make unknown operations significantly easier
IMO, this is the biggest advantage that GUIs have over CLI: they allow you to see all of the legal choices at once, and as you make a change in one field you can see which other fields are now made illegal. Good "help" in a CLI can help, but it's much more trial and error. Esp if the help isn't good, and you combine illegal choices.
--
$tar -xvf
Funny the article singles out YaST as an example of GUI work. YaST works great in CLI. here an example. I have used it both as GUI and CLI (over e.g. ssh) and alongside 'normal' CLI commands for e.g. the firewall and editing things by hand and what not.
This means that if you want standard options, you can easily use YaST (in GUI or CLI after ssh) or use anything else if you want. So it is very strange that he uses YaST as an example for GUI only ways of doing things.
Don't fight for your country, if your country does not fight for you.
GUIs usually are a management requirement. The common misconception is that sysadmin GUIs make you more productive. Well, they don't. On the contrary, they slow you down, cause repetitive and boring activities where the human factor thrives (E.g. copy paste from spreadsheet.) GUIs look good on presentations but are crap to operate.
But it's not only the god forsaken Windows platform that has them. Ever tried configuring network interfaces and the DHCP server on OpenSolaris? Ever tried getting a readable manual on how to do either by editing files or through command line? That for me was the practical reason for discarding OpenSolaris and continuing with FreeBSD.
In an ideal world, configuration files adhere to a specific syntax. Libraries are available and convenience tools and utilities (CLI and GUI) should be based on them and are equally effective.
Cheerfully ignore comments stating that scripts for changing configuration files can screw up production. Hobbyists stating such manure apparently don't know you should run unit and integration tests before deploying any change whatsoever in a production environment. Nowadays any half professional organisation can afford multiple test environments to minimise production failures caused by untested software.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Wow, I can't believe that this is just accepted.
With the advances in GUI design and beyond GUI design technology, a CLI should be obsolete, even if it is not obsolete in practice on the specific examples.
There is no reason a written script should be necessary, when an object constructed visual script could also be generated that is just as specific and functional. Again, just because the tools and technology are not common does not mean it is the standard and will always be a truth.
There was a time that writing software required 'writing code' as well, and today we have technologies that let graphic designers put together robust applications without writing a single line of code. (MS Blend for a simple example of XAML based GUI development.)
By nature Unix based OS models are CLI dependent(textual pipes and generic I/O constructs); however, this is not true of all OS models(NT is an object based OS, where a CLI is counter intuitive which makes PowerShell a brilliant CLI model that came years after the OS, and uses the object nature of the OS design).
Even with some imagination this isn't a 'truth' in a UNIX OS model either. There is no reason that all constructs have to derive or remain at a CLI level with a GUI strapping onto the CLI. Replace the CLI constructs with GUI based interactions and instead of textual pipes, object and graphical piping could be the model that replaces the CLI nature of UNIX.
This line of thinking is a failure of imagination and factually incorrect when viewed from an object based OS design like NT where the CLI(PowerShell) was an achievement to harness objects at a regressed CLI level.
Eh? We've got several thousand users, a working master/slave replication setup, and very few issues with our LDAP. Usually if something goes awry it's indicative of another problem that also has side-effects on LDAP....