Slashdot Mirror


Take This GUI and Shove It

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

12 of 617 comments (clear)

  1. Bad GUI and no CLI: way too common by alain94040 · · Score: 5, Informative

    Here is a Link to the print version of the article (that convenientily fits on 1 page instead of 3).

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

    A bad GUI with no CLI is the worst of both worlds, the author of the article got that right. The 80/20 rule applies: 80% of the work is common to everyone, and should be offered with a GUI. And the 20% that is custom to each sysadmin, well use the CLI.
    --
    dead simple alternative to incorporating for web startups

    1. Re:Bad GUI and no CLI: way too common by Anonymous Coward · · Score: 3, Informative

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

    2. Re:Bad GUI and no CLI: way too common by Alain+Williams · · Score: 4, Informative
      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.

    3. Re:Bad GUI and no CLI: way too common by Anpheus · · Score: 3, Informative

      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.

    4. Re:Bad GUI and no CLI: way too common by DAldredge · · Score: 3, Informative

      Is it really too much to expect people on /. Modern to actually know what they are talking about when it comes to Windows and Microsoft?

      Screen-scraping?  Really?

    5. Re:Bad GUI and no CLI: way too common by Anonymous Coward · · Score: 4, Informative

      You forgot:

      = Still alpha code.
      = Cannot handle multiple group membership from a Linux file system, such as NFSv4 (http://www.pubbs.net/201004/samba/41361-samba-viewing-if-not-editing-nfsv4-acls-from-samba-shares.html).

  2. Re:/etc/resolv.conf by cheater512 · · Score: 4, Informative

    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.

  3. Re:Config files. by Svartalf · · Score: 3, Informative

    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.

    --
    I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
  4. Re:/etc/resolv.conf by arth1 · · Score: 4, Informative

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

  5. Re:And the whole GUI overhead by sirsnork · · Score: 4, Informative

    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

    --

    Normal people worry me!
  6. Re:Better test! by arth1 · · Score: 4, Informative

    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.

  7. Re:Exchange 2007 and Powershell by shutdown+-p+now · · Score: 3, Informative

    There has been a steady transition to PowerShell for all Microsoft server products, precisely so as to enable CLI scripting with full feature coverage, similar to what has been enjoyed on Unix for a long time. It had started with Exchange 2007, but the most recent addition (to the best of my knowledge) is SharePoint 2010.