Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GUI Linux IT

Take This GUI and Shove It 617

Posted by Soulskill from the i-ain't-clickin'-here-no-more dept.
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.'"
This discussion has been archived. No new comments can be posted.

Take This GUI and Shove It More

Take This GUI and Shove It

Comments Filter:

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

    by alain94040 ( 785132 ) * on Monday October 04, 2010 @07:07PM (#33789324) Homepage

    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 (Score:5, Insightful)

      by maxwell demon ( 590494 ) on Monday October 04, 2010 @07:17PM (#33789408) Journal

      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: (Score:3, Informative)

        by Anonymous Coward

        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 (Score:4, Informative)

          by Anpheus ( 908711 ) on Monday October 04, 2010 @07:41PM (#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 (Score:5, Informative)

        by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Monday October 04, 2010 @07:31PM (#33789568) Homepage
        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: (Score:3, Insightful)

          by GumphMaster ( 772693 )
          Ditto, pretty well executed I thought.

        • Re: (Score:3, Interesting)

          by McNally ( 105243 )

          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.

          It's been years since I administered an AIX machine but my recollection is that the CLI command strings it came up with were generally amusingly-specific unique-to-AIX commands with very long names like resizepartitionandinstallbootblock or something like that. They were generally specialty scripts built t

      • Re: (Score:3, Informative)

        by Martin Blank ( 154261 )

        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: (Score:3)

        by jd ( 1658 )

        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 detai

      • Re: (Score:3, Informative)

        by turbidostato ( 878842 )

        "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: (Score:3, Informative)

        by Ephemeriis ( 315124 )

        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.

        Cisco's GUI stuff doesn't really generate any scripts, but the commands it creates are the same things you'd type into a CLI. And the resulting configuration is just as human-readable (barring any weird naming conventions) as one built using the CLI. I've actually learned an awful lot about the Cisco CLI by using their GUI.

        We've just started working with Aruba hardware. Installed a mobility controller last week. They've got a GUI that does something similar. It's all a pretty web-based front-end, but i

    • Re: (Score:3, Insightful)

      by arth1 ( 260657 )

      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: (Score:3, Informative)

      by afidel ( 530433 )
      But a great GUI is one that teaches a new user to eventually graduate to using CLI.

      I couldn't agree more which is why it's really cool that the Exchange GUI tools will show you the exact PowerShell commands they are running if you want to learn how to use the CLI (and in fact that are still things that can only be done in the CLI, though the list is greatly reduced in EX 2010 vs 2007).

      • Re: (Score:3, Interesting)

        by Penguinisto ( 415985 )

        I couldn't agree more which is why it's really cool that the Exchange GUI tools will show you the exact PowerShell commands they are running if you want to learn how to use the CLI (and in fact that are still things that can only be done in the CLI, though the list is greatly reduced in EX 2010 vs 2007).

        Crap. I was hoping they would've encouraged more CLI and less GUI... (using Exch2k7 here - haven't had time to dink with 2010 yet). I'm guessing the typical MCSE types (comprising the majority, not the whole) have decided that command-line stuff must be too hard to learn.

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

      by ToasterMonkey ( 467067 ) on Monday October 04, 2010 @09:24PM (#33790470) Homepage

      Providing a great GUI for complex routers or Linux admin is hard. Of course there has to be a CLI, that's how pros get the job done. But a great GUI is one that teaches a new user to eventually graduate to using CLI.

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

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

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

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

       

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

        by starfishsystems ( 834319 ) on Tuesday October 05, 2010 @12:53AM (#33791596) Homepage
        For sure if you're going to deliver more than one kind if interface they should relate to each other as much as possible.

        Under this expanded mandate, let's also compare the programmatic interface to the system with the command and graphical interfaces. I've always been bothered that there isn't a tight relationship between the standard Unix command set and their programmatic equivalents. It's pretty accidental, and that's a shame. As long as the coupling is not rigorous, that means two learning curves as well as two compatibility surfaces to maintain.

        I used to ponder this a lot, so it was very instructive to work with the Symbolics Lisp Machine for a few years. Here we had an environment which was Lisp from the microcode upward. It was a completely fresh start, a chance to do it right. The operating system was very open. And with Lisp being an interpreted language, you'd think it would be dead easy to provide a rich CLI that gave direct access to both the system and the GUI.

        Well, no, that's not how it worked out. Part of that is due to our natural fondness for line breaks as command delimiters. Lisp wants things to be delimited by parentheses. But that's not an insurmountable problem. Unfortunately, the Symbolics developers thought it was, and they instead went off and built a CLI that was only vaguely coupled with the corresponding system methods. It was heartbreaking to see such a basic advantage thrown away.

        To make matters worse, when the CLI ended up throwing an exception (which was not all that uncommon in such an experimental environment) what you saw on the stack bore little resemblance to the documented system methods. See, most of those were not really methods at all but wrapper macros of one kind or another. So, you'd execute a shell command, which would invoke one of these macros, which would push some undocumented methods on the stack. And since the CLI didn't relate to the system documentation, you'd have to guess where to go to find the documented methods.

        It could have been the best. Instead it was kind of the worst. Well, I guess it beat looking at IBM core dumps.

  • GUIs make documentation hard (Score:5, Interesting)

    by petes_PoV ( 912422 ) on Monday October 04, 2010 @07:14PM (#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 (Score:5, Insightful)

      by skids ( 119237 ) on Monday October 04, 2010 @08:55PM (#33790242) Homepage

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

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

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

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

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

  • Better test! (Score:5, Insightful)

    by AnonymousClown ( 1788472 ) on Monday October 04, 2010 @07:14PM (#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! (Score:4, Insightful)

      by Steve Max ( 1235710 ) on Monday October 04, 2010 @07:18PM (#33789420) Journal
      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! (Score:5, Insightful)

      by snspdaarf ( 1314399 ) on Monday October 04, 2010 @07:21PM (#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! (Score:4, Interesting)

      by skids ( 119237 ) on Monday October 04, 2010 @07:23PM (#33789468) Homepage

      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: (Score:3, Interesting)

      by panda ( 10044 )

      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.

      It is also easier to fix scripted errors because the error is identical in all places. I often find myself using sed to make complicated changes to config files and keeping backups or putting the changed config into a temporary file to get diffs of the results. In the odd case that something gets messed up in production, then it is usually another sed command or two to fix it.

      With a GUI it is harder to verify that you are making the desired changes beforehand, and if you do mess it up royally, then you are

    • Re: (Score:3, Insightful)

      by dbIII ( 701233 )
      One little mistake in a global GUI and you not only fuck up the whole organization but can't really be sure what you did unless you had something capturing the screen while you were making the changes.
      Scripts can be debugged, working out which pictures were pointed at is a bit more tricky.
      Communicating with computers can be compared to communicating with people. You can get somewhere by pointing at things but you get better results faster if you can use words as well.

  • One small problem... (Score:5, Insightful)

    by pedantic bore ( 740196 ) on Monday October 04, 2010 @07:14PM (#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.

    • You meant Windows admins, right?

      • Re:One small problem... (Score:5, Interesting)

        by Darkness404 ( 1287218 ) on Monday October 04, 2010 @07:23PM (#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 (Score:5, Insightful)

      by Sycraft-fu ( 314770 ) on Monday October 04, 2010 @07:37PM (#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 (Score:5, Insightful)

        by turbidostato ( 878842 ) on Monday October 04, 2010 @09:07PM (#33790358)

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

        That should be the case, but it isn't firstly because becoming a good sysadmin is a full time activity as it is being a good programmer and secondly because of subtle character differences between the people that choose one role or the other.

        "I know more than a few programmers that are abysmal at system administration, and I know sysadmins that can't program. There is nothing wrong with this."

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

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

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

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

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

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

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

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

        "They also can help prevent errors. For example I can't count the number of times our DNS has been temporarily broken by a student messing up the file."

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

        So it's a stalemate on this.

        "In Windows? Not a problem"

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

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

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

        • Re: (Score:3, Insightful)

          by arth1 ( 260657 )

          "They also can help prevent errors. For example I can't count the number of times our DNS has been temporarily broken by a student messing up the file."

          That's not an argument, it only seems to. While "manual handling" is prone to syntax failures, GUIs are prone to knowledge failures which are, by the way, much, much more dificult to debug.

          Never mind the things that the GUI just can't do, because the GUI is limited by the knowledge of the person who wrote it. Try entering an rdata_44 record in the DNS thro

      • Re: (Score:3, Insightful)

        by 10101001 10101001 ( 732688 )

        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.

        I'd presume this comes about from the fact that [administration] software used to be very expensive so it was normally cheaper to hire a sysadmin/programmer than to hire a sysadmin and seperate software. The fact that most sysadmins used to be at least minimally programmers (ie, they could write a

      • Re: (Score:3, Interesting)

        by Shadow99_1 ( 86250 )

        All I have to say is: Amen! (in a nonreligious sort of way)

        I'm a not very good programmer who is a good system admin. I've been fighting the general apathy to anyone who can't read the source for the linux kernel in the linux world for going on a decade now! I'm always being told 'write it yourself' when I bump into a wall in administering linux systems that would be a simple button press in Windows... I don't want to reinvent the wheel! I'd frankly suck at it! That A) doesn't mean I'm a bad admin and B) Is

      • Re: (Score:3, Informative)

        by codepunk ( 167897 )

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

        Funny, nobody finds it disturbing when I interview for a job. Usually they just say holy crap
        you are a experienced and accomplished programmer as well as a crack administrator, hired.

      • Re: (Score:3, Interesting)

        by Rantastic ( 583764 )

        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.

        Not only have I spent over 10 years as a professional *nix system administrator, I currently work training professional system administrators. I don't know *anyone* who thinks that a system administrator should be a programmer. That being said, shell scripting is a tool of the skilled system administrator. Writing simple scripts is nothing like programming. While shell scripts can be quite complex, most that a system administrator would write are very simple. Really just a series of commands.

        I know more than a few programmers that are abysmal at system administration...

        And how! The va

      • Re: (Score:3, Insightful)

        by sjames ( 1099 )

        If you type a question mark in the IOS CLI, it will show you all of your possible options from that point. Tab completion is another way to accomplish that, some CLIs use that.

        In Unix, you have the tab completion, man and apropos to help you out.

        Shell languages are designed with an emphasis on very simple "programming" tasks such that a sysadmin can easily use it for simple string substitutions and such while it remains a turing complete language (meaning anything that can be expressed to a computer can be

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

    by MichaelSmith ( 789609 ) on Monday October 04, 2010 @07:15PM (#33789398) Homepage Journal

    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.

  • /etc/resolv.conf (Score:3, Interesting)

    by kharchenko ( 303729 ) on Monday October 04, 2010 @07:19PM (#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 (Score:5, Informative)

      by cheater512 ( 783349 ) <nick@nickstallman.net> on Monday October 04, 2010 @07:24PM (#33789482) Homepage

      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 (Score:5, Informative)

      by arth1 ( 260657 ) on Monday October 04, 2010 @07:37PM (#33789620) Homepage Journal

      /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 (Score:5, Insightful)

        by IICV ( 652597 ) on Monday October 04, 2010 @08:25PM (#33789996)

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

  • More and more... (Score:5, Insightful)

    by Darkness404 ( 1287218 ) on Monday October 04, 2010 @07:21PM (#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... (Score:5, Insightful)

      by oatworm ( 969674 ) on Monday October 04, 2010 @07:38PM (#33789624) Homepage
      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: (Score:3, Insightful)

        by turbidostato ( 878842 )

        "Realistically, if you're a company with less than a 100 employees [...] it just won't matter to the admin if they can script, say, creating a mailbox for 100 new users instead of just one."

        Well... it won't matter till the day your single server dies and you learn that, being a little drop in the sea, you don't have a "gold support contract" and it takes you one week to get a new spec'ed server (if only I weren't such a cheap ass and I'd buy two...). And when you turn on the new server you learn that you d

  • Config files. (Score:3, Insightful)

    by Timmmm ( 636430 ) on Monday October 04, 2010 @07:22PM (#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. (Score:4, Informative)

      by Svartalf ( 2997 ) on Monday October 04, 2010 @07:28PM (#33789532) Homepage

      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: (Score:3, Interesting)

      by mirix ( 1649853 )

      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.

  • Webgui? Just use cUrl (Score:5, Interesting)

    by icebraining ( 1313345 ) on Monday October 04, 2010 @07:24PM (#33789494) Homepage

    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.

  • Yes (Score:3, Insightful)

    by prichardson ( 603676 ) on Monday October 04, 2010 @07:27PM (#33789520) Journal

    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.

  • Exchange 2007 and Powershell (Score:4, Insightful)

    by maotx ( 765127 ) <{maotx} {at} {yahoo.com}> on Monday October 04, 2010 @07:42PM (#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...

  • Why I moved to FreeBSD (Score:4, Insightful)

    by Charles Dodgeson ( 248492 ) <jeffrey@goldmark.org> on Monday October 04, 2010 @08:51PM (#33790206) Homepage Journal

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

  • Comment removed (Score:3, Interesting)

    by account_deleted ( 4530225 ) on Tuesday October 05, 2010 @01:46AM (#33791776)
    Comment removed based on user account deletion

    • Re: (Score:3, Insightful)

      by Junta ( 36770 )

      YaST over SSH in not CLI, it's TUI. The important difference is CLI is scriptable, TUI has the lack of scriptability of a GUI, but the bandwidth characteristics of CLI.

      I think it's a nice example of how something running in a text-only mode is not necessarily a sufficient improvement over GUI.

  • GUIs are a management requirement (Score:5, Insightful)

    by SpaghettiPattern ( 609814 ) on Tuesday October 05, 2010 @04:06AM (#33792242)
    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.

  • Grandpa, Really? (Score:3, Insightful)

    by TheNetAvenger ( 624455 ) on Tuesday October 05, 2010 @08:25AM (#33793060)

    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.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close