Do you prefer to administer servers through a GUI or CLI?

Question

Do you prefer to administer servers through a GUI or CLI?

Please state which system OS's you are answering for.

Answer 1

GUIs can be beginner-friendly, but after that - they're more hostile than helpful.

They place a layer between you and the problem that you're trying to fix - and that "proxy" rarely addresses all the functionality that you are after. The developer who wrote it at the time thought of "what would be required", and after then sealed off your freedom with choices he made at that time. It's not even reasonable to expect a developer to think of every possible problem that may or may not happen.

Having said that - I'll also add that a GUI can be useful too, and when written well, can save time and effort, even provides some enjoyment in use - no arguments there. But when you do eventually need to do something other than "use" the product under "normal circumstances", you should not be forced to go through the GUI - that would be a handicap.

(My view is not based on any particular OS).

Answer 2

I prefer CLI because of piping and stdin/stdout. I prefer this on a all systems.

I also prefer when there is a configuration file rather than registry settings.

Answer 3

CLI all the way, for the simple reason that audit is much easier. When I'm making a change, I simply log my terminal session and then I have a record of exactly what I did, should I ever have to go back and validate it.

Text based configuration also lends itself to automation; it's trivial to throw together some scripts that automatically save configuration off network devices and check them into a version control system, giving you a history of what's changed in your network over time.

Answer 4

Besides that many good answers people have given to the advantages of CLI, another plus for CLI that I didn't see is that in my experience CLI is much less likely to fail. This can be a huge time saver if you administer servers remotely. Also, if the machine starts to experience heavy load, CLI is usually more response.

Answer 5

OS Linux.

Preference CLI. Why? Its fast, succint and you can get to all of the options and you understand what is happening. And it is scriptable which is important when you are deploying/maintaining many systems or even just a few systems which must be kept in a consistent, known state (e.g. dev boxs which might need to be redeployed/ have their state "reset" frequently) If you use a GUI you may be able to get the same effect, but you may never understand what was done.

OS Windows I very occaisonally have to do windows stuff, often to test windows against linux servers. And then I prefer the CLI, even though I don't know it. The reason? It seems that a lot of times the windows GUI won't do stuff. I.e. you performt he operation in the GUI, but it does not actually seem to trigger the operation in the OS. I've found that usually the CLI gives you a better idea of the current state of a windows machine and often you can get things to work, which don't actually work (every time) in the GUI, even though it some times looks like they do. Admitedly I use the GUI more on windows, basically because I am ignorant of windows and simply don't know the command line tools as well.

Answer 6

I personally think that a successful change control system is next to impossible to achive in a GUI only world.

If the change is to be implemented via a cli the steps can be bundled up into a script which is then submitted to change management for approval. Once approved the very same script can be run in the live environment.

As a previous poster mentions text based configuration files make things even better. I won't go into the benefits of using CVS ( or substitute your favorite revison control system) for maintaining your configuration environment but I will just leave this one (slightly made up) example of a configuration file (from tinyproxy):

# 20090527 MJH -- Request for change 564

Allow 192.168.1.100

I know that some GUIs now have a (poorly implemented) comments field and a lot of what I describe above could be implemented in a GUI. But at the moment it is not.

Answer 7

Horses for Courses. Jeff Snover developed PowerShell for Windows because certain key operations in Exchange were three windows deep and difficult in a GUI. No doubt I'd rather have a CLI to do one operation that does something in bulk, rather than twiddle with a GUI.

OTOH, even PowerShell--the best CLI I've ever used--is prone to the endless parameters problem and it's difficult to scale unless the script or cmdlet writer picks defaults very carefully.

I have GUI windows open but I always have a PowerShell window open too. I would suspect most admins do the same, even the hard-core bearded Unix ones.

Answer 8

CLI is the only way to go - especially if you're on call and don't want to be tied to your house. Being able to login to a box over a mobile/cell phone, without 3G being available, and being able to troubleshoot is invaluable, you'll get nowhere fast with a GUI.

There are plenty of reasons stated above that are also valid. Scripting a gui is fairly tricky.

Answer 9

I learned my linux on Slackware, where there was (in the default install) nothing more than a command-line interface. The same is true for many server-edition flavours (like Ubuntu). Maybe I'm set in my ways at an early age, but I still much prefer the CLI, for a two major reasons:

• The only pre-requisite to remote administration is an SSH client. If you realise that your server is down for some reason, and you happen to be at a friend's place running whatever-OS, grab a freeware ssh client, log in, and you're presented with what you're accustomed to. No need to install VNC, an X11 client, etc...

• Lower-to-negligible overhead. I like the idea that I'm not wasting resources drawing a pretty window, and you can't beat the bandwidth used by ssh.

Besides, front-ends are just that: front ends, as in, front end to the command-line. Cut out the middle man :)

Answer 10

Depends entirely on the job at hand but I find I use the GUI more often than the CLI on Windows. About 50/50 on our only Mac server or my MacBook. Our Linux machines don't have a GUI, so obviously it's the CLI all the time and I prefer it that way.

Answer 11

Definitely CLI.

It's so much easier to follow / give instructions as a series of CLI commands than with click here, open this dialog, click there, ...

Also, any CLI command can, by definition, be automated in a script.

Answer 12

Depends on the task and the administrator's familiarity with the ins and outs of the product being administered.

With greater familiarity, the CLI is usually the preferred modality - particularly if that CLI is readily scriptable for common tasks.

A well designed GUI with task-orientated workflows accompanied by helpful prompting and at-point-of-need documentation is often the best way of gaining familiarity, or for completing complex task workflows where using the CLI might lead to steps being missed, etc.

This is particularly true in my experience with specialist appliance products that deviate from the typical mould of a Solaris box or a Windows desktop.

Mostly, though, it comes down to how well the product being used has been designed and usability tested across the spectrum of intended users/administrators.

Answer 13

Windows / Unix:

Because of automation ability I prefer CLI. Windows has always been lacking in this regard but with Powershell it's becoming easier.

Answer 14

Win

I am still learning everyday, but I definitely prefer CLI. It wasnt that long ago though that I would have said GUI. As I have grown into my job it seems that there are many more things that you can do with CLI....especially after installing tools such as pstools (and others that I cant think of just this sec).

Although my company doesnt have any Linux/Unix machines, I do have a couple at home and it seems that EVERYTHING is easier (and believe it or not FASTER) with the CLI if you take the time to learn. You can definitely do more with CLI than GUI.

Answer 15

CLI - transparency is everything.

Answer 16

I tend to view GUI and CLI as just being tools to get a job done, and will use whichever is most appropriate for the job I'm doing, with no absolute preference either way.

This I believe is as it should be.

Answer 17

Debian/OSX. CLI/SSH/SFTP/Cyberduck/TextMate. I'm learning all the time. I think really getting used to some scripting language and to be methodical, structured and to document is key. Although I like GUI when it comes to graphs of CPU load and such :) I use SFTP a lot since Cyberduck lets you edit files "in-place". Very convenient. I like 'graphical' console tools too, like top. I'm gonna try Webmin soon. We'll see.

Answer 18

UNIX/Linux/OSX

Having had to use quite a few different distro's in different versions I'm never quite sure which tool is the current front-end of choice, or how well it interacts with the underlying config files. In quite a few cases I've had to remove the GUI-created file and rewrite a new one by hand.

I know how the CLI tools work, largely the same across linux/unix systems, and the syntax of the files they are using. That doesn't change between systems.

Also, working as a vendor for a while I got used to being told to sit down at a machine and use it, never knowing which OS it was, or which version. I've even been told completely the wrong OS from time to time (Solaris not Linux; HP-UX not Solaris, etc). Knowing the standard CLI tools means I can work on any Unix machine. Sadly that often means vi not Emacs for those wanting a religious war, but vi has been on every unix/linux machine I've ever used.

Answer 19

Unix and Linux platforms of various flavors (OSX, BSD, Solaris, AIX, Ubuntu, Debian, Red Hat, SUSE, etc).

I prefer to administer systems with a configuration management system like Chef. Rather than running commands to manage systems, I write code. Each service or other entity is treated like an object. It's literally programming infrastructure, and its a lot more scalable, easy, and fun than logging into machines and running commands. I write a recipe to manage Apache once, and then any time I need a web server, I add the recipe. Same with any service. I can rebuild systems and reconfigure them on a whim.

Anyone who is manually managing systems as their routine daily work is working too hard.

Now, historically speaking, I have preferred command-line interfaces, because of the power in using scripting languages like Bash, Ksh, Perl, Ruby and Python to glue commands together.