Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Take This GUI and Shove It

Soulskill posted about 4 years ago | from the i-ain't-clickin'-here-no-more dept.

GUI 617

snydeq writes "Deep End's Paul Venezia speaks out against the overemphasis on GUIs in today's admin tools, saying that GUIs are fine and necessary in many cases, but only after a complete CLI is in place, and that they cannot interfere with the use of the CLI, only complement it. Otherwise, the GUI simply makes easy things easy and hard things much harder. He writes, 'If you have to make significant, identical changes to a bunch of Linux servers, is it easier to log into them one-by-one and run through a GUI or text-menu tool, or write a quick shell script that hits each box and either makes the changes or simply pulls down a few new config files and restarts some services? And it's not just about conservation of effort — it's also about accuracy. If you write a script, you're certain that the changes made will be identical on each box. If you're doing them all by hand, you aren't.'"

Sorry! There are no comments related to the filter you selected.

Bad GUI and no CLI: way too common (5, Informative)

alain94040 (785132) | about 4 years ago | (#33789324)

Here is a Link to the print version of the article [infoworld.com] (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 [fairsoftware.net] to incorporating for web startups

Re:Bad GUI and no CLI: way too common (5, Insightful)

maxwell demon (590494) | about 4 years ago | (#33789408)

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.

Re:Bad GUI and no CLI: way too common (1)

0123456 (636235) | about 4 years ago | (#33789478)

What would be nice is if the GUI could automatically create a shell script doing the change.

While it's not quite the same thing, our GUI-based home router has an option to download the config as a text file so you can automatically reconfigure it from that file if it has to be reset to defaults. You could presumably use sed to change IP addresses, etc, and copy it to a different router.

Of course it runs Linux.

Re:Bad GUI and no CLI: way too common (3, Informative)

Anonymous Coward | about 4 years ago | (#33789560)

Exchange Server 2007 (and I assume 2010) does this for many of its GUI operations, gives you the powershell after you've run it.

Re:Bad GUI and no CLI: way too common (3, Informative)

Anpheus (908711) | about 4 years ago | (#33789660)

Just about every Microsoft tool newer than 2007 does this. Virtual machine manager, SQL Server has done it for ages, I think almost all the system center tools do, etc.

It's a huge improvement.

Re:Bad GUI and no CLI: way too common (1)

h4rr4r (612664) | about 4 years ago | (#33789918)

If they could get server 2008 to work without any gui than that would be really worth it. Maybe for 2012 or whatever. Does dcpromo work without a gui yet?

Re:Bad GUI and no CLI: way too common (4, Informative)

Alain Williams (2972) | about 4 years ago | (#33789568)

AIX's SMIT did this, or rather it wrote the commands that it executed to achieve what you asked it to do. This meant that you could learn: look at what it did and find out about which CLI commands to run. You could also take them, build them into a script, copy elsewhere, ...

I liked SMIT.

Re:Bad GUI and no CLI: way too common (2, Informative)

triple.eh (1482301) | about 4 years ago | (#33789632)

I agree with you, AIX's SMIT [wikipedia.org] was an excellent tool for learning. When I first began using AIX all of my UNIX experience was with HPUX, Solaris, Slackware and Red Hat. When I discovered SMIT it was like peering in the Ark without all the melting...

Re:Bad GUI and no CLI: way too common (2, Insightful)

GumphMaster (772693) | about 4 years ago | (#33789822)

Ditto, pretty well executed I thought.

Re:Bad GUI and no CLI: way too common (2, Informative)

Martin Blank (154261) | about 4 years ago | (#33789648)

Aruba's web-based GUI does this. You stack up all of your changes per-page, and you can click on an option at the bottom that shows you the CLI changes that it will make (since it's going to run just those lines when you apply it anyway). It shows you when something is simple and can be done quickly from the CLI, and also when what takes three clicks actually takes five or six somewhat complex lines.

Re:Bad GUI and no CLI: way too common (2, Insightful)

jpate (1356395) | about 4 years ago | (#33789730)

learn about how to do it per CLI by looking at the generated shell script

Have you ever seen generated code? You do not want to learn shell scripting from generated code...

Re:Bad GUI and no CLI: way too common (4, Insightful)

petermgreen (876956) | about 4 years ago | (#33789836)

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:Bad GUI and no CLI: way too common (2)

jd (1658) | about 4 years ago | (#33789750)

That would be one option. Another would be to be able to drive the GUI from a script (test systems such as Silk and Selenium already do this). Provided standard options were accessed in a standard way, there is nothing to stop you from driving things from this direction. Alternatively, have a configuration server that applications installed plug-ins for. The configuration server can then abstract out the nuances. You then feed it a script in the server's language and it takes care of the configuration details.

(This is where LinuxConf and Webmin fell down - they didn't really abstract out a whole lot and didn't allow this kind of autoconfiguring. Great tools for those scared of raw textfiles, though. I convinced more than a few Windows users that Linux wasn't this Big Bad Scary Monster with them.)

Re:Bad GUI and no CLI: way too common (2, Informative)

turbidostato (878842) | about 4 years ago | (#33789894)

"What would be nice is if the GUI could automatically create a shell script doing the change"

AIX's SMIT, and it's... how old? merely 20 years now?

Re:Bad GUI and no CLI: way too common (-1, Troll)

plover (150551) | about 4 years ago | (#33789474)

A bad GUI with no CLI is the worst of both worlds, the author of the article got that right.

And it's screamingly obvious to anyone whose had to administer a Windows system.

What's making it worse is that with the whole no-CLI is the dawning of the age of powershell. Yes, otherwise rational people think that screen-scraping is the technology of the future for automating Windows administration tasks.* They at least recognize the lack of CLI as a crippling handicap, but don't get the whole concept of "screen scraping is about the worst (brittle, least maintainable) approach to interfacing two systems, ever."

John

*for sufficiently weak definitions of 'rational'

Re:Bad GUI and no CLI: way too common (2, Insightful)

amRadioHed (463061) | about 4 years ago | (#33789636)

I'm a bit curious, could you explain how powershell encourages screen-scraping for those of us who've never had to deal with that beast.

Re:Bad GUI and no CLI: way too common (2, Insightful)

jandrese (485) | about 4 years ago | (#33789704)

Here's something you might want to try: Next time you're on a Windows box, open up a cmd prompt and type "netsh". You might be surprised what you can accomplish from the commandline, at least if you want to mess with the network settings.

Re:Bad GUI and no CLI: way too common (2, Insightful)

arth1 (260657) | about 4 years ago | (#33789512)

But a great GUI is one that teaches a new user to eventually graduate to using CLI.

I disagree. The "great" GUIs teach new users that they don't need a CLI, and many of them will never proceed past the point-and-drool stage, but expect a GUI app for anything they do.

When push comes to shove, a single line of awk or perl can easily do what half an hour of GUI clicking can't. And there's no way for a GUI to prepare you for perl or awk, only distract you from learning them.

Re:Bad GUI and no CLI: way too common (2, Interesting)

SudoGhost (1779150) | about 4 years ago | (#33789826)

But by the same token, I can click and drag a file from a folder to the desktop, easily. Much 'easier' than typing it out on the CLI, and much quicker for most people.

Not saying it's easier for all people, but for most people, I can see where they're coming from. Sadly, I know alot of companies who don't want their admins to be the best, they want their admins to be the most efficient. They equate 'clicking' with quick, and typing out 'lines and lines of code' as long and arduous, and expensive.

Re:Bad GUI and no CLI: way too common (2, Informative)

h4rr4r (612664) | about 4 years ago | (#33789930)

Cool, now move only the files that end in mp3, do not contain a number in the name and are between 10 and 60 days old. I bet the CLI starts looking might fast then.

GUIs make documentation hard (5, Interesting)

petes_PoV (912422) | about 4 years ago | (#33789374)

All good admins document their work (don't they? DON'T THEY?).

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.

Re:GUIs make documentation hard (1)

furgle (1825812) | about 4 years ago | (#33789524)

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

This works great, until you log in as user X, change to directory Y, run script Z with arguments A B and C, and the output looks like F or even G (not G!!!!). Then you spend quite some time trying to find what was different this time.

GUI's are better for reporting and displaying information

Re:GUIs make documentation hard (2, Insightful)

maxwell demon (590494) | about 4 years ago | (#33789662)

GUI's are better for reporting and displaying information

In my experience, GUIs tend to display less information (probably to not "confuse" users). But from the basic ability to provide useful information, I don't see why one should have an advantage over the other. After all, the information is just text; if that text is shown on the console or in a window with "OK" button doesn't matter. What does matter is whether the text is informative (e.g. "foo.cfg: file not found") or uninformative (e.g. "unable to change configuration" as only error message).

Re:GUIs make documentation hard (1)

Vancorps (746090) | about 4 years ago | (#33789808)

Or my favorite, unknown error! Or Oracle's approach of reusing codes with different applications, thank you Oracle! In both the GUI and CLI sides here it depends on the development philosophy and target demographic. If you're making tools that display in public then presenting errors on screen is probably not a good idea. If you're a sysadmin configuring a mail server then probably the more output the better. Of course in all cases there should be a way for an experienced user to get detailed diagnostic information but logging is a pain in the ass.

Re:GUIs make documentation hard (1)

parlancex (1322105) | about 4 years ago | (#33789604)

I suppose it's been a while since you've used Windows Server and associated admin tools. Everything Microsoft has written in the last 4 years has a complete Powershell back end interface exposed to the user and you anything you can do from their GUI tools can be done from the shell. In fact, most of their GUI tools just use the Powershell interface in THEIR back end.

Re:GUIs make documentation hard (2, Insightful)

petes_PoV (912422) | about 4 years ago | (#33789870)

Oh there's much more to it than merely the O/S. It's all the applications and third party management tools, too. They all provide GUIs (sometimes only GUIs) as they think it makes their stuff look easy to use. In fact all it does is make it easier to sell to decision makers who don't have the background to distinguish "friendly" from repeatable.

Re:GUIs make documentation hard (1)

bhcompy (1877290) | about 4 years ago | (#33789716)

Or you could check out Windows 2008 Server Core. There are some limits and limited GUI, but it's essentially CLI

Better test! (5, Insightful)

AnonymousClown (1788472) | about 4 years ago | (#33789376)

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! (3, Insightful)

Steve Max (1235710) | about 4 years ago | (#33789420)

So you test your script offline? You know, exactly like you test the changes you will do through a GUI in an offline server before going to the live one?

Re:Better test! (-1, Troll)

Anonymous Coward | about 4 years ago | (#33789782)

Yeah, cause we all have test environments.

Re:Better test! (4, Informative)

arth1 (260657) | about 4 years ago | (#33789838)

Yeah, cause we all have test environments.

Yes, we do. In many case it's called a chroot jail which acts as a sandbox.
In other cases, a VM that can be rolled back is the way to go.

There are two words describing those who run untested changes directly on production systems: Former employees.

Re:Better test! (1)

cheater512 (783349) | about 4 years ago | (#33789430)

Erm.....and doing it manually with a GUI is better than that how?

At least you can correct the problem and run the script again to fix it.

Re:Better test! (1)

moonbender (547943) | about 4 years ago | (#33789596)

I don't agree with GP, but to be fair, GUIs (even admin tools) do usually show a confirm dialog before most destructive operations. And even if not, it's often more difficult to accidently maneuver into a "dangerous" part of the app than it is to misspell a shell command.

Re:Better test! (1)

Martin Blank (154261) | about 4 years ago | (#33789682)

Microsoft's Group Policy also recently got a Recycle Bin of its own, allowing certain deletions to be undone. I haven't tinkered with it in depth yet, so I don't know its full limitations, but some form of state retrieval would be helpful for both GUIs and CLIs.

Re:Better test! (5, Insightful)

snspdaarf (1314399) | about 4 years ago | (#33789442)

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.

Re:Better test! (1)

hsmith (818216) | about 4 years ago | (#33789868)

Any well written admin GUI should have logging anyway.

Being someone that uses SharePoint daily, I'll tip the hat to MS that at least the GUI uses/does everything based upon the API that you'd use from the CLI.

Re:Better test! (3, Interesting)

skids (119237) | about 4 years ago | (#33789468)

Well, one little mistake pushing a windows domain policy via GUI, and the same.

This is one of the weakest points in the article, IMO, though. It's quite possible (even if MS MMC is a kludgy example) to GUIfy multi-system administration.

There will always be a place for both GUI and CLI -- status screens, for example, generally demand a GUI (and yes, ANSI menu systems are a GUI.)

Re:Better test! (0)

Anonymous Coward | about 4 years ago | (#33789572)

The assumption is also made that all servers are running the same distro with the same versions of all CLI tools (and thus, all CLI tools have the same parameter options). This is not the case often enough.

Re:Better test! (2, Insightful)

fruviad (5032) | about 4 years ago | (#33789668)

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.

Perhaps so, but the scripted mistake is easily fixed because every single machine exhibits the same symptoms. Easy to debug. Once debugged, easy to fix.

Do you think it better to have a half-dozen different mistakes on a half-dozen different servers in a pool of 40?

One small problem... (4, Insightful)

pedantic bore (740196) | about 4 years ago | (#33789388)

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:One small problem... (1)

microbee (682094) | about 4 years ago | (#33789416)

You meant Windows admins, right?

Re:One small problem... (4, Interesting)

Darkness404 (1287218) | about 4 years ago | (#33789476)

More and more people are switching to things like Ubuntu for small business things like file-servers and the like.

Its cheap, its easy and its stable. I'm sure if you look through all of the businesses running servers, very few of them are ran by real "admins" but rather by the employee who "knows about computers"

Well there's another side to that (5, Insightful)

Sycraft-fu (314770) | about 4 years ago | (#33789618)

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 (0)

Anonymous Coward | about 4 years ago | (#33789958)

I wholeheartedly thank you for your post. That has been my argument for a long, long time.

Re:Well there's another side to that (0)

h4rr4r (612664) | about 4 years ago | (#33789972)

GUIs are limiting period. How do you call some other tool from a gui? You don't.
The sheer lack of pipe does that.

Re:One small problem... (1)

h4rr4r (612664) | about 4 years ago | (#33789952)

I think you meant, not admin.

Re:One small problem... (1)

turbidostato (878842) | about 4 years ago | (#33789970)

"I think the author might not fully understand who most admins are."

I think you -and most people, is forgetting what an system admin is. If all you do is push buttons and follow menu entries, then you are not an admin, you are an operator.

Yes, the vast majority of people with administrative privileges on Windows environments are operators, not admins.

GUI interface can sell a product to management (5, Interesting)

MichaelSmith (789609) | about 4 years ago | (#33789398)

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.

Moderated: (0)

Anonymous Coward | about 4 years ago | (#33789410)

-1 Bleeding obvious

not entirely sys admin related (2, Interesting)

ThorGod (456163) | about 4 years ago | (#33789418)

In most of my professional life, if there's an OSS alternative the OSS alternative is usually better. LateX is more professional than Office, in my opinion. I prefer the look and repeatability of gnuplot over Excel. Python is much more extensible than VBA. SQLite and python really helped me clean data for my professional paper, as well.

Granted, I'm using Microsoft Office in addition to the aforementioned (except LateX).

/etc/resolv.conf (2, Interesting)

kharchenko (303729) | about 4 years ago | (#33789426)

Agreed. For instance, I've been trying to figure out how to add a simple "search" entry into resolv.conf in Fedora .. it keeps overwriting it on boot no matter what level scripts I modify (e.g. going up to DHCP config, etc.) - because some genius came up with a new admin tool and thought that something as basic as resolv.conf doesn't need to be followed.

Re:/etc/resolv.conf (4, Informative)

cheater512 (783349) | about 4 years ago | (#33789482)

Usually there will be resolv.conf.head and resolv.conf.tail files somewhere which get stuck at the beginning and end of the generated resolv.conf.
That way you get a semi-dynamic and semi-static config.

Re:/etc/resolv.conf (1)

0123456 (636235) | about 4 years ago | (#33789502)

vi /etc/resolv.conf
chattr +i /etc/resolv.conf

I had to do that on Ubuntu a couple of years back because it kept overwriting resolv.conf and the GUI wouldn't accept the configuration I wanted to use.

Re:/etc/resolv.conf (1)

Anonymuous Coward (1185377) | about 4 years ago | (#33789534)

I'm not using Fedora, but it's usually dhclient-script(8) that is overwriting resolv.conf.

RTFM, it can be fixed.

Re:/etc/resolv.conf (4, Informative)

arth1 (260657) | about 4 years ago | (#33789620)

/etc/init.d/NetworkManager stop
chkconfig NetworkManager off
chkconfig network on
vi /etc/sysconfig/network
vi /etc/sysconfig/network-scripts/eth0

At least they named it NetworkManager, so experienced admins could recognize it as a culprit. Anything named in CamelCase is almost invariably written by new school programmers who don't grok the Unix toolbox concept and write applications instead of tools, and the bloated drivel is usually best avoided.

Re:/etc/resolv.conf (1)

MSDos-486 (779223) | about 4 years ago | (#33789908)

I F'n hate NetworkManager.

Why is it such a hard thing to grasp that a machine can have multiple interfaces on different networks (I work in a networking testing lab were this is very common) simultaneously. I refuse to help anyone with network problems if their using NetworkManager on Linux.

The line isn't that sharp (1)

hackwrench (573697) | about 4 years ago | (#33789432)

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.

More and more... (5, Insightful)

Darkness404 (1287218) | about 4 years ago | (#33789446)

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... (1)

Svartalf (2997) | about 4 years ago | (#33789514)

Ah... But the thing is... You don't NEED the GUI with recent Linux systems- you do with Windows.

Re:More and more... (1)

sleeper0 (319432) | about 4 years ago | (#33789718)

Windows server 2008 and 2008R2 both support no GUI installations called "server core" and can be managed with CLI tools (minus a few exceptions).

Re:More and more... (1)

YrWrstNtmr (564987) | about 4 years ago | (#33789742)

You don't NEED the GUI with recent Linux systems- you do with Windows.

No you don't. Powershell.

Re:More and more... (1)

Martin Blank (154261) | about 4 years ago | (#33789768)

As pointed out elsewhere, no, you don't have to have a GUI with Windows. PowerShell now comes by default on all versions of Windows. Windows Server 2008 Core even comes without any GUI on the system at all -- it's all PowerShell, nothing else (though you can administer it remotely with GUI-based tools). If you want to do anything local, you must be able to use PowerShell.

Re:More and more... (5, Insightful)

oatworm (969674) | about 4 years ago | (#33789624)

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.

Re:More and more... (1)

devent (1627873) | about 4 years ago | (#33789680)

And the huge amount of spam and bot nets reflects that. That they don't need to know what they are doing, it's all nice pretty GUI and they are paying a few $ to MacAfee or Symantec. No wonder the anti virus companies can afford the biggest buildings in the city.

Config files. (2, Insightful)

Timmmm (636430) | about 4 years ago | (#33789450)

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.

Re:Config files. (3, Informative)

Svartalf (2997) | about 4 years ago | (#33789532)

Really? Ever heard of editing /etc/profile and changing the PATH statement there? No, there's no GUI tool- but under Windows it's not wholly clear like you make it out to be where it is. Yeah you can change it- but then so can I under Linux in as much of an easy way as you can under Windows- it's just different and if you're unfamiliar with one or the other, you're not going to be doing it on EITHER.

Re:Config files. (0)

Anonymous Coward | about 4 years ago | (#33789540)

For example, how do you change the PATH in linux through the GUI?

Before I tell you how to do this, please tell me *why* it's necessary to use a GUI to change a CLI parameter? If you're going to use the CLI (which you are) why not just use the CLI to change the PATH?

Re:Config files. (1, Troll)

devent (1627873) | about 4 years ago | (#33789646)

Why should you? Under Linux you never have to change the PATH. The applications will be installed in pre-defined directories and the path is already set. It's only in Windows where you just install applications in random places and need to change the PATH in this horrible small dialog, plus you need to restart Windows to make it work.

In Linux it's just works, but if you really need to change the path you should be knowing what you do.

Re:Config files. (0)

Anonymous Coward | about 4 years ago | (#33789696)

Eh, no. I had to change the path fairly often to have things like custom compiled versions of Mono to work, and other things like for ccache to play automagically. On Windows, never had to change it of course, the setup did it for me.

Re:Config files. (0)

Anonymous Coward | about 4 years ago | (#33789814)

In Linux I have had to change path directories hundreds of times, adding in new locations.

You see this application was designed by a debian user but packaged in an RPM for Fedora, but to run it under mandrake you have to edit the path as the install script doesn't see that change.

This application was designed for Ubuntu, but under debian standard the paths are different, under fedora the paths are different.

Only OS X has had a consistent file location schema over the past 10 years. Every linux distro uses their own file paths and unless the programmer explicitly modifies their application for said distribution you have to edit you profile paths, and system wide paths to fix such things.

Before you say Linux just works I suggest you actually use more than one distro. I still have hardware (monitor) that no current linux distro supports. The drivers were released by the manufacturer 3 years ago under a BSD license. Things like randr only partially support it. Meaning I can get the monitor work only under static settings however I live with dynamic monitors and don't feel like rebooting my computer 3 times a day as I swap out monitors. dropping into vi 3 times a day to modify x.config just for the privellage of using what I have.

Oh and windows and OS X have had those abilities for the last decade.

posted Anonymously to preserve moderations

Re:Config files. (0)

Anonymous Coward | about 4 years ago | (#33789758)

When it comes down to it, all environment variables and system configuration details are stored in some configuration file somewhere on a system. Any system. Yes, even Windows. Though, in the case of Windows, the system itself is dependent upon the wonderfully-clear, well-documented, well-commented configuration files that make up the Registry.

Re:Config files. (1)

jd (1658) | about 4 years ago | (#33789878)

I've mentioned them above, but you can do damn-near anything that Windows can do via either LinuxConf (for older distros) or Webmin/Usermin. (The option for file paths is in Usermin under "Operating System and Environment" and, frankly, I consider it infinitely superior to the way Windows displays the path.)

Yes, these are not "standard". Almost nothing in Linux is "standard" and that is a Good Thing. It allows you to have the system set up to match how you think rather than force how you think to match the system.

Re:Config files. (2, Interesting)

mirix (1649853) | about 4 years ago | (#33789940)

Yeah, instead of flat text conf files, why don't we put a whole bunch of config in some obscure place in the registry somewhere...

i entirely fail to see the point as to why you would want a gui to do something that is integral to the cli.

Bad GUIs and bad CLIs (0)

Anonymous Coward | about 4 years ago | (#33789466)

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.

Programmers suck at making GUIs (0)

Anonymous Coward | about 4 years ago | (#33789472)

Just because the GUIs written by most programmers suck doesn't mean they all do.

Developer vs. user (0)

Anonymous Coward | about 4 years ago | (#33789484)

"GUI isn't that necessary." said the software developer.

"GUI is necessary." said everyone else on the planet.

Webgui? Just use cUrl (5, Interesting)

icebraining (1313345) | about 4 years ago | (#33789494)

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.

And the whole GUI overhead (1)

devent (1627873) | about 4 years ago | (#33789508)

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.

Re:And the whole GUI overhead (4, Informative)

sirsnork (530512) | about 4 years ago | (#33789672)

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

Re:And the whole GUI overhead (1)

YrWrstNtmr (564987) | about 4 years ago | (#33789762)

Or better, do you have an option for no-GUI installation?

Mostly. Server2008 server core [microsoft.com] .

Re:And the whole GUI overhead (1)

Martin Blank (154261) | about 4 years ago | (#33789800)

Being able to ssh into a Windows server without installing a third-party SSH service is news to me. There is a version called Server 2008 Core that does not have a GUI, and the installation can be automated.

Re:And the whole GUI overhead (0)

Anonymous Coward | about 4 years ago | (#33789966)

From Windows Server 2008 you can have a no GUI installation for certain server roles.

Yes (2, Insightful)

prichardson (603676) | about 4 years ago | (#33789520)

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.

ITT: "Get off my lawn" (1)

MrEricSir (398214) | about 4 years ago | (#33789526)

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.

Re:ITT: "Get off my lawn" (0)

Anonymous Coward | about 4 years ago | (#33789602)

Nice post. Almost half of one sentence is relevant to the discussion.

Try reading the article.

Re:ITT: "Get off my lawn" (4, Interesting)

ak_hepcat (468765) | about 4 years ago | (#33789626)

Probably because it's also about the ease of troubleshooting issues.

How do you troubleshoot something with a GUI after you've misconfigured?
How do you troubleshoot a programming error (bug) in the GUI -> device communication?
How do you scale to tens, hundreds, or thousands of devices with a GUI?

CLI makes all this easier and more manageable.

Re:ITT: "Get off my lawn" (2, Insightful)

arth1 (260657) | about 4 years ago | (#33789726)

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.

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

Re:ITT: "Get off my lawn" (3, Interesting)

fandingo (1541045) | about 4 years ago | (#33789778)

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

This, from the journal "Duh." (0)

Anonymous Coward | about 4 years ago | (#33789536)

Why is this newsworthy?

Each in their place (1)

Kaboom13 (235759) | about 4 years ago | (#33789644)

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

No (1)

idle12 (1871570) | about 4 years ago | (#33789664)

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

Exchange 2007 and Powershell (3, Insightful)

maotx (765127) | about 4 years ago | (#33789666)

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 [petri.co.il] feature, but they still have to load a GUI to present a prompt...

Sorry, I just banged my head on something. (1)

sootman (158191) | about 4 years ago | (#33789678)

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.

Re:Sorry, I just banged my head on something. (1)

ThorGod (456163) | about 4 years ago | (#33789802)

I hear you. I expected to see many people complaining about exactly that when I loaded the comments.

But, at some point it says something that this is still true in 2010. Many would love to see the CLI go the way of the dinosaur, but that seems pretty naive.

There is no real difference (1)

Pharago (1197161) | about 4 years ago | (#33789684)

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.

Just say no... (1)

ManiaX Killerian (134390) | about 4 years ago | (#33789736)

... 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 :)

Do this with your GUI (2, Insightful)

fishbowl (7759) | about 4 years ago | (#33789770)

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.

Couldn't agree more (1)

starfishsystems (834319) | about 4 years ago | (#33789828)

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.

the only excuse for a lack of a good GUI is profit (1)

PJ6 (1151747) | about 4 years ago | (#33789920)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?