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
-1 Bleeding obvious
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.
I think in some GUI's (if not then it is posible) you can select a bunch or machines, save that configuration, then every time you have to make a change you click on a file the GUI comes up and there all the machines already selected are for you.
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.
If your idea of a GUI is that you have to connect to each machine and make changes manually, then why would you expect a CLI which allows you the flexibility to make the necessary changes automatically? There are bad GUIs and there are bad CLIs. A good management GUI allows you to make changes and apply them to a bunch of systems. A good CLI has consistent naming and syntax, autocompletion and powerful control flow statements. If you're stuck with a bad CLI, you're not going to be any faster than with a bad GUI.
Just because the GUIs written by most programmers suck doesn't mean they all do.
"GUI isn't that necessary." said the software developer.
"GUI is necessary." said everyone else on the planet.
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
Why Windows servers have a GUI is beyond me anyway. The servers are running 99,99% of the time without a monitor and normally you just login per ssh to a console if you need to administer them. But they are consuming the extra RAM, the extra CPU cycles and the extra security threats.
I don't now, but can you de-install the GUI from a Windows server? Or better, do you have an option for no-GUI installation? Just saw the minimum hardware requirements. 512 MB RAM and 32 GB or greater disk space. My server runs with 260 MB RAM and 2.1 GB disk space, and I have Php, Apache, MySQL, Redmine, Rails, ISPConfig, Tomcat6 installed. Really, 512 MB RAM and 32 GB or greater disk space as a minimum requirement? I guess there is already ASP.NET, IIS, MSSQL installed, plus a few tools like remote desktop. But really, 512 MB RAM and 32 GB? My whole server takes just 7% of the minimum requirements of MS Server 2008.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
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.
Just because you're used to a CLI doesn't make it better. Why would I want to read a bunch of documentation, mess with command line options, then read whole block of text to see what it did?
I'd much rather sit back in my chair, click something, and then see if it worked. Don't make me read a bunch of man pages just to do a simple task.
In essence, the question here is whether it's okay for the user to be lazy and use a GUI, or whether the programmer should be too lazy to develop a GUI.
There's no -1 for "I don't get it."
Why is this newsworthy?
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.
CLI's are great for scripting, but they also make it very easy to make errors of omission. If you don't know about a command, you don't use it. If there's an important security setting for example, you might see it poking through the GUI, but not know you need to add it when starting from a blank config file. Of course in theory no one should be admin for a system they didn't know and fully understand, but we all know in reality that is not what actually happens, especially in smaller operations. A good system uses both to do what they are best at, and a good admin should be familiar with both. Even MS finally got on this bandwagon, with Powershell and server 2008, anything you can do in the gui can be done with powershell, and a lot of rarely used commands are powershell only (keeps you from overly complicating the gui which is a good thing).
> '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.'" If you are using a bad GUI tool. Nothing says you can't have one GUI that connects to all servers and has a mutlti list select. Select the ones you want, run the command. It'll be the same command across all servers. That doesn't mean shell script is better, it means you suck at writing GUI interfaces. Anything you can do in shell scripting you can do in a system language.
Instead of a ssh script that logs into each server, you can create a GUI program that logs into each server the exact same way.
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.
Is it 1998?
I think half of the readers here could have written that article (natural aversion to articles in general notwithstanding) if any of them thought that the topic hadn't been thoroughly addressed a decade or so ago.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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, someone makes a gnome app to control some program or to provide an interface to some utility, and when you try it, you find out it lacks the most important stuff and you are better off writing things inside a terminal. That dosn't make all GUI apps any worser that any other text app, if it lacks it, code it yourself.
... to crap like web control panels and GUIs. They might be great for some brain-dead users and other office furniture, but when your actual work is in making sure something works, the CLI is just better - fast to work with (everyone has tab completion these days, and if you haven't learned to type, go sit in irc for a while), can be easily scripted and automated (even windows has something useful right now), can easily be scheduled, and you can see the results pretty easy.
All GUIs I've seen plainly suck. There's ONE general idea that the programmer had how everything should be used, and that's wrong all the time. There's never something like "do this to these N selected objects", there's nothing like pipes, they're slower (navigation-wise) and they tend to fuck up horribly, having to restart the whole interface (I've managed to break too many of these).
Long live SSH :)
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.
This seems to be a message doomed to be endlessly repeated. That's because every person who has grown up surrounded by a GUI environment becomes unconsciously resistant to the idea that any alternative that isn't graphical could possibly have distinct advantages.
The distinct advantage of a CLI comes from the L in the acronym. It stands for language, and languages when implemented according to accepted design principles have valuable characteristics like composability and parameterization.
Languages give us the ability to create tangible things which can be named and shared and pointed at and talked about constructively. Thus we become ever more literate. How can we refer to an elaborate series of mouse gestures, except by precisely reconstructing the gestures? All we gain from that is practice in rote memorization.
I have a similar concern about opaque configuration. A system which is based on a configuration language lets you talk about configuration in a tangible way. You can save and copy and restore and manipulate and annotate configuration values.
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? Let me tell you. What you have then is a maintenance nightmare. And they abound. No two systems behave in quite the same way, and yet nobody can say exactly what makes them different.
Parity: What to do when the weekend comes.
Admins and developers we may be, but we're end users, too, and we get fatigued and annoyed by the same design no-no's as everyone else. Honestly I'm tired of just having to suck it up when I have to use a product that had no thought to usability put into it. It's waste multiplied a thousandfold over every unfortunate user that had to wade through a thicket of XML and poor documentation to do the most basic of tasks.
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
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?
If the equipment is remote and not easily accessible you had better have good CLI skills. If your system looses data connectivity and you have to dial in through Iridium or a dial up modem a GUI is of no use. GUIs dont work very well at 19200 baud.
sorry for my comments, I'm drunk
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
... where Microsoft seems to have progressively gone out of their way to deliberately obscure elements in the GUI since Windows 98. It is now such a chore that the search feature in the start menu and in control panel is a REQUIREMENT for most users. How many of you know where to change the DPI in Windows 7? You can add to that their guidelines promoting the criminal waste of screen real estate (nVidia drivers, 800x600 window, one checkbox in the middle?!).
Look, no SIG!
"Use the right tool for the job".
GUIs are perfectly fine for the jobs they are designed to handle, just as CLIs are perfectly fine for the jobs THEY are designed to handle. No one tool paradigm is overall better than the other in all (or even most) cases.
This is, of course, assuming that the tools in question of both paradigms are quality tools. You can most certainly have a PoS CLI tool, just like a PoS GUI tool.
-SS "Teach the ignorant, care for the dumb, and punish the stupid."
This was obvious, like, 20 years ago.
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
I was happy to learn about wevtutil.exe on windows machines until I learned that it was considerably harder to parse info than with eventquery.vbs. Why should I have to open a GUI to form a query string, then copy/paste that into a command prompt to use wevtutil.exe?
I used to assist a IT director for a medium business and I had to manage Cisco routers at some point. I tried the Web Based gui at some point, but ended up dumping the config file and modify it, found it more easier. Eventually I learned the basic of their CLI and it was WAY more efficient. And their "engineers" working from Mexico was about as useful as monkeys with user manuals and typewritters.
Tomorrow is another day...
Bad GUI. Should have a checkbox next to each server and a select all /toggle selection action. Then make the change once. It is a way people think and too many GUI front-ends are written by hard core CLI people or others with little GUI design experience. I do advocate a well written backend setup for such tools and then a CLI front-end, a GUI one, and a programmable API that is user friendly (may be the same as the normal backend.)
Each mode has its own uses and its own fans, but in this day and age the GUI has proved useful more than enough. There are bad CLIs to systems as well. Having to use --help or man often is a sign maybe something is wrong.
- Tjp
I am in wallow with my inner money grubbing capitalistic pig. ... Oink!
The curse of late posting, this is likely not going to be read by anyone but I can't help it:
The CLI (command Line Interface) does not make things any easier than the GUI. What makes the CLI easier is the existence of things like .bat files (in windows) that will be interpreted as a sequence of commands.
At the end of the day, the one that goes on writing some script that tells the OS to execute a list of commands is not a virtue of the CLI but just result of a programmable operative system. Throughout the years I have done the same thing with a lot of different systems. All the way to 1997 doing Apple Scripts that would run on every machine in my network to configure all machines identically, making VBS scripts to do updates, or even making user friendly Excel sheets with VBA that allow users to easily change programmable cells and then execute VBA across a whole network or huge list of replicating SQL servers.
In sake of redundancy: this has nothing to do with the interface and all to do with the OS providing users/administrator with quick and easy to use scripting tools that allow programmable automation of common processes, without forcing them to jump into compiled languages.
http://www.catb.org/esr/writings/cups-horror.html
Look at the postscripts, particularly "Are there settings you can do from the command line or hand-editing config files that cannot be done from the GUI? Are they documented anywhere? Does using the GUI erase these settings?"
Anyone who has ever dealt with SuSe's 'yast' tool knows that their tools overwite text configuration setting. X configuration tools are almost as bad, and don't speak to me about what RedHat's 'authconfig' tool does to PAM and nsswitch.conf.
Fortunately for other tools, "webmin" is an excellent example of a tool that Does Things Right. Most of its modules are cleanly written, deal with odd cases, and don't blow away existing settings. I highly recommend it for the education of new GUI authors. No Java based graphics: no pretending that the client is the server: just light, text processed information between client and server.
The windows solution to this is to set a policy in the GUI, and apply it to a group of severs. No need to give up the speed and intuitiveness of the GUI, but all the machines get an identical configuration.
Linux is decades behind in enterprise management. Writing scripts is an order of magnitude slower than just ticking a checkbox. Also, declarative administration has other benefits over procedural scripting. For example, with big pools of servers, what happens if one of the servers is down for maintenance when you run a script? It's skipped, that's what! What if you add a new server to a cluster? How do you make sure it has every script applied, in order? With group policy, a new Windows server will catch up to the current desired configuration every few hours. If it misses an update for whatever reason, it will get it next time around automatically.
Oh, and most group policy settings take effect live -- there's no need to "simply" restart services!
We are also expected to second guess developers and identify, workaround or fix their mistakes. That often requires programming skills. Not necessarily skills on par with the developers, but enough to have an idea of what is going on.
The argument is really not about the CLI at all, but really that the idea that everything should be GUI based is silly. The GUI often can only be there when you have devised a standard operating proceedure for something and have no need of flexibility.
It's not a failure if you succeed. Why does it matter that I read documentation that I've written myself just to make sure I've got it exactly the same as when I did it the last time?
CLI is for the pretentious.
That concept only makes sense in certain situations... What about video or photo editing. Sure you can process photos programatically, but what about making someones arm pop out of focus or rotoscoping and the like. A great GUI with a the capabilities to record actions such as in Adobes Photoshop definitely make for a powerful tool when the user doesn't have to learn or write any code or scripts whatsoever...
It's amazing how much more efficient one can be when one really knows ones CLI. I've allways tried my darndest to be as efficient as possible when using a computer and over the last ten years I've started to rely on CLI more and more, and the more I rely on CLI the faster I get. These days I actually only need GUI for web browsing, and even there I use conkeror. Everything else is done in CLI.
I work as a *nix sysadmin at a college. One of the first things I did many years ago, when I was hired, was install subversion. Any *nix system, router, switch, or firewall config change goes into SVN.
I (and anyone else in our group) can tell who did what and why going back many years.
A change caused issues for a tiny subset of students a full year after the change. I looked through past changes, and could see what was changed, why it was changed, who made the change (me; although I did not remember it), instantly revert it, and have a jumpstart on coming up with a new fix for the issue of a year ago.
Then we have the windows folks... "did you change something?" "I don't know. What are you seeing." "Hmmmm. I don't remember." "Reboot." etc.
So GUIs have no place in my preferred admin work flow. The only GUI that does not completely break the work flow is one that generates plain-text configs, but even then, unless you can edit those configs directly (no obscure interactions between many xml files for instance), then you still lose with a GUI. Besides, click, click, click... is tedious.
> What would be nice is if the GUI could automatically create a shell script doing the change.
It IS nice: AIX has been doing this for 2 decades in "SMIT".
And BTW, GUIs that allow changing settings on multiple boxes at once have been around for a long time too--SMOP.
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's the best automation framework I've ever seen. I really envy it, a lot. It's almost enough to put a candle to Ubuntu and our built-in app store. Once we copy that too, we'll be all set :P
We weren't all born as system admins, we all started somewhere. GUIs can be built to create, store, and call scripted functions, so the "make GUI mistakes by hand on lotsa boxes" arguement is pretty thin. The "really understand your systems" arguement is also pretty weak. I've seen *nix admins who had no clue and Windows admins who actually understood Bind (gasp!).
The truth is that the various tools we all use have their strengths and their weaknesses, largely dependent on who built them, and how well-built and extensible they are.
I've been at a backtrack (esp earlier versions) command prompt thinking, ok, wth now? Yeah, I slogged through man pages, but there were items where a GUI would have been tremendously handy for visually vaulting on up the learning curve.
On the other side, I've sat at a GUI thinking, what freaking moron designed this PoS that will not allow me to perform an incredibly basic function (search/grep) on GUI output.
He grew up at a command line...ok. He likes command lines...ok. Command lines are inherently better than GUIs.....only in the hands of those who have an idea what they are doing. Command lines are a pretty freaking unforgiving place to learn....and I've seen more systems completely mangled from mistyped command-line arguements than I ever did from a GUI. Yeah, yeah, I know. That's why we script and test. But everyone isn't born with 3-10 years experience or an excellent mentor, and sometimes all you really need (can afford) for a 6-person family business is the 17-year old neighbor kid. Don't mock it, the CFO is an ex-stripper and it works.
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
Real servers don't have gui's installed on them!
Got Code?
I am so damn tired of this kind of geek-cred bullshit. With today's computers, there's no good reason not to have a GUI. Unless, of course, you think girls will be impressed by your CLI skills.
that GUIs are more user friendly. I disagree. CLIs are just more careful about who their friends *ARE*!
I'd be happy with documentation that gives all the CLI commands and what they do in plain english (or your language of choice)... Nothing worse than getting a new piece of equipment that upper-management was sold on as the best thing "evah!", only to discover that you have to use the GUI for part of it, the CLI for another part, and then call the manufacturer (whom, without a maintenance/support agreement would otherwise charge a rediculous fee), whom requests remote access (lol-right...) or uses the CLI via remote-desktop-web-session and uses undocumented commands...and can't speak (your language here) well enough to explain what they just did and why. As for the article - Exchange 2007 does this pretty well - it gives you the exchange powershell command script when doing things with the GUI as part of the last step - kind of like holding one's hand and saying, here, try this as a script next time (not that I do)...there's some things that you can't do with Ex2007 without using the powershell - such as exporting a mailbox to PST, or changing SSL certificate info...
Look, I loooove CLIs. It's why I love Linux so much and it's why I prefer Mac to Windows, even when I don't spend as much time in a shell there as I do on Linux.
But this is not a GUI problem. There's nothing that says that a GUI can't update multiple machines identically and from one location. In fact we know they can, with Active Directory on Windows servers being probably the best example. They simply need to be written to do so. There are certainly valid discussions to be had as to whether or not a good GUI with people intimately familiar with it could ever be as fast to perform tasks as a good CLI with people intimately familiar with it, how much time each solution takes to develop and even the possibility that a CLI doesn't need to pre-plan such support when a GUI probably does, but most are not inherent limitations -- they are design choices.
Of course, being a CLI lover I prefer the CLI. I love the idea of scripting something up, or how you can chain tools designed to do exactly one thing and do it well together to have a ridiculous amount of power at your fingertips. At the same time, if I were asked which to do for a product that was being released (sold or otherwise) I would choose a GUI. Or better yet, have the best of both worlds: A CLI that the GUI sits on top of, Windows 3.1 style. You can even have a little "Import configuration file" button that would make this guy's example sync perfectly, which it sounds like he suggests at the end. His other complaints seem to be about how the GUI is actually designed, which is once again not a GUI problem but rather a problem with a particular GUI.
Beyond that, if you really have to pick one or the other it's little more than a "know your audience" and solve for success, whether you define that as profit or adoption or otherwise.
The author presents a false choice. The right way is to write a management api and then write cli/gui/web interfaces as needed or desired.
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.
I'm a windows admin and I use scripts when I absolutely positively definitely can't use anything else (or for things I want to do once). Scripts are bad for you, they go in to organisations and sit around, quietly working for years until the admin who wrote them left, everyone who knew what it did left and everyone else has to puzzle it out and guess at what it is doing. So I keep it simple. Group policy where possible, little batch files on login if GP won't work, and, after that I will resort to scripting. It should not be ancouraged as a standard practice. As for powershell, I'll use it when nothing else works.
Repetition by hand, even by a skilled operator, is error prone. I think that's the main message in this article, and I couldn't agree more. The task at hand doesn't even have to be that complex. That's why, in a system administration context, tools like puppet (http://www.puppetlabs.com/) and cfengine (http://cfengine.com) make so much sense. Tools like those help you make sure that items that need to be the same stay the same, and make sure changes happen in sync across systems when need be (courtesy of your version control system). And of course, local variations can be catered to in a number of ways and maintained across global reconfigurations. If you're lucky enogh to be working on a Unix or BSD, that is. Not sure what's available in Cisco or Windows space.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
glad we have that covered
Let's see, since I can do a Regex search from Total Commander's GUI, use any of it's file-system plugins - from a GUI to add more rules to the Search requirements. Then feed the Results to TC Tab, Select them all... from a GUI and then Click a button to feed them to a one liner script to move them where they need to go -- of which the Script can take the destination input (From a GUI).
... that you are using right now. The Internet and more specifically the web is a command line interface we use everyday without really realising it. Through urls, google, other search features. It's nice and easy to use for novices with search suggestions and instant search in google, even correcting spelling and (sometimes horrendous) grammar to guess what you mean. But, the interenst also harbors more advanced functions in a nice layered manner.
:D
Oh and you can easily learn HTML, CSS whatever, it's all there in the 'view source' feature. Prime example of how to bridge dumbed down interfaces to the technical underpinnings and oh gee I don't know, spark a technology revolution?
The whole CLI vs GUI argument is highly tired and in the post-hyperlink world a debate that's been invalid since 1992. Obviously the most productive tool is one that hybridizes the ability of GUIs to present complex information and not require detailed study and memorizing of the system commands to be productive.
CLIs while traditionally powerful (though not always ie DOS) are epic usability and discover ability fail, have always been so. Before you argue, go type something obvious like 'help' in a bash shell, it doesn't work, it's always been that way as far as I can remember. Now try that in Google, the Firefox awesome bar or even the Window Vista/7 start menu, you get suggestions within a split second. That's the difference between a couple decades of progress vs adhering religiously to kludgey once perhaps relevant design decisions in the late 1980s. I hate the *nix command line, I spent years supporting with it. I went to web development and left OS mayhem to those who love self-torture
CLIs are still all around us, they have merged with GUIs. Old dumbed down GUIs have now moved off to touchscreen iStuff.
Curret Linux, Freebsd, etc CLI's fail *HORRIBLY* when you're restricted to bash, coreutils and friends. Processing different output from different programs all with differing switches is a complete and utter waste of time compared to just grabbing a library for ruby, python, whatever and doing programming it. But then we would be hiring a programmer and not a system administrator to fill this job, what's needed is a concise system based on a dynamic language (meta programming) so a simple say (if it was object orientated) VideoPlayer.play('somecontainer'). Remember dynamic doesn't have to mean slow it's just a lot harder to make fast, but the tradeoff of ease of use and complete 'fluidity' if you will is much much better.
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)
I think "concordant" is the word you want instead of "Integrity". Your use of it is more like "integral" as in they bind closely with little translation. Concordant is the right word, I think.
So what your saying is "Bring back DOS & make Windows run on top of it." - Check.
I'm sorry, shove where?
I agree that GUI's are nice eye candy and can visually organize a space. but... they are not blind friendly.
I still use cli for editing scripts and modifying system settings (including editing configuration files for custom settings). I don't see a lot of this in GUI interfaces (I use orca under gnome and believe me, a lot of options for settings in some system settings are simply not there). in OS X, I have also found that knowing how to modify settings on the CLI is a very powerful skill to have. anyone that thinks the GUI is the only way to go is severely limiting what they can really do.
how many of you can setup a true firewall script in linux using strictly a few guy tools and have it do some really powerful stuff? I know of perhaps 2 apps that might give you something approaching what you can create using VI in a command line. its the same with a lot of other deep level items in Linux (and OS X as well).
even though I am speaking from the P.O.V of a blind person, the same holds true for everyone. having a command line ability to make/modify/create scripts, documents and configuration files is definitely a useful (and powerful) alternative that should not be discounted.
Understanding is much like a 3-edged-sword. in this: there are always 2 sides and the truth.
"The moral of this particular story is that GUI interfaces are fine and necessary in many cases. But they need to be built after a complete CLI is already in place, and they cannot interfere with the use of the CLI, only complement it. Otherwise, all you've done is make easy things easy and hard things much harder"
If you can do it with a GUI and prefer to use a GUI, then use a GUI. If you can do it with a CLI and prefer to use a CLI, then do it with a CLI. What you shouldn't do is write an article about it, because it's an unbelievably banal observation to make.
" 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.'"
No... if you write a script, you're certain that the change ATTEMPT made is the same. The changes may very well not be the same, if one of the boxes is messed up, but you can be certain it wasn't because you did it differently on that box. That's the difference between a GUI and a CLI... you get a same attempt guarantee, which allows you to blame the box instead of yourself when management comes asking why it failed.
stuff |
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.
AIX's SMIT was pretty cool back in the day. You could do most things via a GUI but save your commands to use in shell scripts to automate routine tasks outside of the GUI. MS-SQL DBA admin tools as well as Oracle Enterprise Manager all give the ability to generate scripts of GUI action....
Never having used OSX I can't speak to how it works in practice, but conceptually the concept of an XML config file that has it's GUI embedded, yet is also viable to access by things like sed/awk/gedit (No, I don't use emacs/vi. Ubuntu: Linux for wimps. **** off - {G}) seems like an awfully cool method to combine the CLI and GUI concepts as two aspects of a common interface.
Pug
An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
...is the number of comments to this article, which insist that the CLI should die completely, is obsolete, should be obsolete, and should never, ever be used again.
Without saying anything about the CLI or GUI specifically, I will simply say this. I have observed on a consistent basis that there is a connection between a person's level of intelligence, and their level of willingness to tolerate diversity. Intelligent people tend to advocate and believe in multiple different approaches to solving a given problem. It is overwhelmingly the unintelligent or narrow minded, in my experience, who seek monoculture, or only a single option which everyone is then forced to use; primarily so that they themselves can avoid having to think.
I understand that the target audience for this request are probably the least likely to actually listen to this, but if you do have the above attitude, I would diplomatically request that you examine your level of broad mindedness in general. Narrow mindedness, a desire to minimise available options, and an insistence on monoculture are not positive or desirable mental characteristics.
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....
Windows Server 2008 only requires 512 mb of RAM
The problem isn't GUI vs CLI.
The main problem is automation.
If you need to do something once a day a GUI will do just fine.
Do the same thing 100 times a day and you scream for an automated process.
CLI often has more possibilities for automation.
Having said this, the solution is not providing a CLI for those tasks but a way to interact with the system that requires the least human interaction as possible.
This can be CLI, but also some kind of listening process that picks up a file or data in a message queue.
I remember a few years back when Microsoft took over Hotmail and converted all those FreeBSD servers to Windows Servers, they had an article interviewing one of the lead admin's for hotmail. He stated that there was no way they could GUI their way through all those hotmail servers, so they scripted everything at cmdline for the Windows Servers. I think their experience lead to more cmdline options within Windows to cover stuff that formerly only been GUI.
See, even Microsoft does CLI.
to understand what a mess it was. just being well read was enough.
rm -rf $somevar/*
have a lot of fun, if your system does not have $somevar set.
I've said this quite a number of times, but it doesn't seem to be catching on.
We need a toolkit of some sort that will allow you to write a single code base, that gives you both a GUI and a CLI from the same code.
I mentioned this to a Microsoft guy when I was onboarding during a Microsoft acquisition of a Linux company; he seemed quite interested. And yet when I took this idea to a GTK+ mailing list, I don't know that anything happened.
I GUI is bad idea when you don't know the CLI. A CLI is a true interface to the system, a GUI is a covered up point to access the system. So what I'm I say, never run a Desktop, NO of course not. A GUI is great but only when you don't relie on the GUI to be your life line. If you see a bash prompt and give up and reinstall then you aren't ready to even run a GUI.
This term we had to get Linux put on our machines at school. It took 3 weeks for IT to install Ubuntu. Before we had a Ubuntu install ready, I had an Arch install ready to go. When I told my prof all we had to do was to pacman -S xorg-server gnome. He said NO because were not going to work on the CLI and it's to much control to give the other students in my class.
People have become so reliant on the fact there nice comfy GUI will be there, they don't want to even see a "localhost>", Even when the solution can take 10 min there are people who will reject it so they can see a GUI. It goes even more then this though.
When I tell my profs I made a Graphic Interface for our robot project the first thing they were concered about was that it could be compiled and used in a graphic enviroment. When I said no it can't and they have to deal with it they didn't want to use it.
I'm not saying they don't know how to work the command line but there not willing to use it when it makes there job so easy. There is very little that can't be done from a command line but there is a ton that can't be easily done from a GUI. If you shy away from the command line your really shying away from the operating system.
you must not have a very good skill set if you can't design, test and deliver a script without breaking things.
Some tools I've used only need the CLI, others need a gui...Nagios for one...Great with a web interface...Same with Cacti. You can have a myriad of tools to help, whatever works for your institution is what the standard should be (for that inst.).
Huge improvement, still not optimal but never the less an improvement.
/category/virtual-server-hosting/
I agree 1000%.
GUI is nice sometimes as an overlay, but let me do my scripting to keep down errors and speed repetitive tasks.