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

Comments

Better test!

[AnonymousClown]

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.

Re:Better test!

[snspdaarf]

Ah, but with a script you have a record of what was done. The GUI does not provide that, unless the author had the sense to write the changes to a log file.

One small problem...

[pedantic bore]

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.

Re:Bad GUI and no CLI: way too common

[maxwell demon]

What would be nice is if the GUI could automatically create a shell script doing the change. That way you could (a) learn about how to do it per CLI by looking at the generated shell script, and (b) apply the generated shell script (after proper inspection, of course) to other computers.

More and more...

[Darkness404]

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.

Re:More and more...

[oatworm]

Bingo. Realistically, if you're a company with less than a 100 employees (read: most companies), you're only going to have a handful of servers in house and they're each going to be dedicated to particular roles. You're not going to have 100 clustered fileservers - instead, you're going to have one or maybe two. You're not going to have a dozen e-mail servers - instead, you're going to have one or two. Consequently, the office admin's focus isn't going to be scalability; it just won't matter to the admin if they can script, say, creating a mailbox for 100 new users instead of just one. Instead, said office admin is going to be more focused on finding ways to do semi-unusual things (e.g. "create a VPN between this office and our new branch office", "promote this new server as a domain controller", "install SQL", etc.) that they might do, oh, once a year.

The trouble with Linux, and I'm speaking as someone who's used YaST in precisely this context, is that you have to make a choice - do you let the GUI manage it or do you CLI it? If you try to do both, there will be inconsistencies because the grammar of the config files is too ambiguous; consequently, the GUI config file parser will probably just overwrite whatever manual changes it thinks is "invalid", whether it really is or not. If you let the GUI manage it, you better hope the GUI has the flexibility necessary to meet your needs. If, for example, YaST doesn't understand named Apache virtual hosts, well, good luck figuring out where it's hiding all of the various config files that it was sensibly spreading out in multiple locations for you, and don't you dare use YaST to manage Apache again or it'll delete your Apache-legal but YaST-"invalid" directive.

The only solution I really see is for manual config file support with optional XML (or some other machine-friendly but still human-readable format) linkages. For example, if you want to hand-edit your resolv.conf, that's fine, but if the GUI is going to take over, it'll toss a directive on line 1 that says "#import resolv.conf.xml" and immediately overrides (but does not overwrite) everything following that. Then, if you still want to use the GUI but need to hand-edit something, you can edit the XML file using the appropriate syntax and know that your change will be reflected on the GUI.

That's my take. Your mileage, of course, may vary.

Well there's another side to that

[Sycraft-fu]

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.

Re:Well there's another side to that

[turbidostato]

"I find it rather disturbing the UNIX ideal that sysadmins should be programmers."

That should be the case, but it isn't firstly because becoming a good sysadmin is a full time activity as it is being a good programmer and secondly because of subtle character differences between the people that choose one role or 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."

Yes, there is, and very wrong. Maturity of current IT systems is still far away to what's needed to be able to work in aisles. A programmer doesn't need to be a top notch sysadmin nor the other way around, but they both need to have very clear ideas about the other's trade because is needed both to understand where your program is going to be run and how and what would make proper practices to acomodate the programs within a wider and partially peculiar local environment (and in order to recognize properly engineered programs from lame intents).

"Not everyone should have to learn that skill, and you could well be excluding people you want by requiring it."

And, in fact, not everyone needs to learn that skill, it's only sysadmins that need it. And take for granted you are not excluding interesting people to fill a sysadmin role if they don't have at least clear foundations on programming.

"Also there's the simple matter that GUIs work better for unfamiliar situations."

Quite true (but proper man pages with examples and tutorials work almost as well).

"Part of systems administration is being able to solve novel problems. Ok well GUIs help in that regard, at least when well designed. "

But don't forget a *very* critical point: a new thing is only novelty the first time you do it. Do not let a bit of easiness for your first time getting in your way for the subsequent 10.000 times you will do it again from then on.

And that's exactly why GUIs sell so good. When you are "buying" something new (it might mean literarilly exchanging money, but it means commiting yourself to the effort that will require work with new thingie) it usually will be to do new things, which is the kind of situation when GUIs (and "wizards", for that matter) will help, so the GUI by itself will be a very valuable agent to sell the app/services. By the time you understand that the shiny GUI gets in the middle you have invested too much in the app (money, time and effort) to get away from it. Microsoft, for instance, has learnt that leson very, very well.

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

That's not an argument, it only seems to. While "manual handling" is prone to syntax failures, GUIs are prone to knowledge failures which are, by the way, much, much more dificult to debug. For each time you had a student making a severe syntax error on a DNS zone file, I can show you a self-called sysadmin making horrible design choices that led to situations dificult to repair and problems dificult to debug because the GUI allowed for an action on Windows environments (which was not a failure of the GUI itself, because the action was correct under the proper circumnstances, but because the GUI allowed for someone without enough knowledge on the consecuences of their acts to do "something" resulting in an "OK" message: a case of "garbage in, garbage out").

So it's a stalemate on this.

"In Windows? Not a problem"

Now that you mention the text config files vs. GUIs on a multiple admins (some of them students) environment, here comes a hugh problem with the vast majority of GUIs:

You get at work early in the morning and something is not working properly. You summon your minions and tell them "something is broken; what have you messed up since yesterday?"

On a text files-based environment the answer is easy and you already advanced it: "we have it in a versioning system so

Re:Bad GUI and no CLI: way too common

[petermgreen]

Have you ever seen generated code?
Yes

You do not want to learn shell scripting from generated code...
IMO the generation process should be limited to taking the users input and "plugging it in" to a "template" command or short sequence of commands. If a process that is simple in the GUI is complex in the CLI then your system has a design fault.

It's not about teaching the user how to write complex scripts with lots of conditionals (manuals and tutorials are better for that). It's about teaching the users the command line equivalents of their GUI actions and hence creating a bridge between the "discoverability" of a GUI and the power and repeatability of a CLI.

Re:/etc/resolv.conf

[IICV]

And to drive the point of this article home: how long would your post have been if you'd had to describe how to do this through the GUI? Would it have even been possible without screenshots?

Re:GUIs make documentation hard

[skids]

I think this is a stronger point than the OP: GUIs do not lead to good documentation. In fact, GUIs pretty much are limited to procedural documentation like the example you gave.

The best they can do as far as actual documentation, where the precise effect of all the widgets is explained, is a screenshot with little quote bubbles pointing to each doodad. That's a ridiculous way to document.

This is as opposed to a command reference which can organize, usually in a pretty sensible fashion, exact descriptions of what each command does.

Moreover, the GUI authors seem to have a penchant to find new names for existing CLI concepts. Even worse, those names are usually inappropriate vagueries quickly cobbled together in an off-the-cuff afterthought, and do not actually tell you where the doodad resides in the menu system. With a CLI, the name of the command or feature set is its location.

Not that even good command references are mandatory by today's pathetic standards. Even the big boys like Cisco have shown major degradation in the quality of their documentation during the last decade.

Re:Bad GUI and no CLI: way too common

[ToasterMonkey]

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.

Just about everyone reading this is heavily biased one way or another, and there is too much presumption that a CLI is this or a GUI is that.

Why can't we break this down into what makes any type of interface good or bad, and keep open to the possibility of new types of interfaces or better ways of implementing existing ones?
If we can bitch and moan about CLI vs. GUI with little choice in the matter I think the floor's open to made up interfaces too. These are qualities I think any computer interface should have.

Learning curve no steeper than the underlying concepts. Probably even lower.
Consistent, and predictable.
Expressive, and concise.
Integrity. Um.. as in, the state of the machine vs. what's conveyed to the user. Accurate?
Available over a network.
Can be automated.
Online documentation. Of the interface. If you have trouble describing the concepts in your native language, maybe it sucks.
Efficient, in the sense of labor involved, but in the sense of learning too, like my first rule.

That's a start anyway. I don't see why any kind of interface can't shoot for those. For sure if you're going to deliver more than one kind if interface they should relate to each other as much as possible. A CLI is dead simple to turn into script, but a GUI could also be. A CLI should map so closely to a corresponding GUI that it effectively IS a script of the GUI. A GUI should convey state information just by looking at it. Duh. If it doesn't HAVE to be an either/or situation, why make it into one?

 

Re:Bad GUI and no CLI: way too common

[Anonymous Coward]

> * It requires a sysadmin with a clue
> * You need to not be a mouth-breather to configure it

Still wonder why you're not taken seriously, eh?

I like Samba. It could use less advocates like you.

GUIs are a management requirement

[SpaghettiPattern]

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.