GUI’s and Open Source

Tweet

There are frequently debates in open source circles about the impact of layering graphical user interfaces across Linux and Open Source applications. The issue revolves around encouraging GUI use to configure daemons (the Linux version of Windows services) and servers when the user may not know how or understand how to configure the underlying application from the system shell or via individual configuration files.

Those new to open source often see this as Unix snobbery. However, the concern is that from time to time, a GUI may become unavailable and require “going under the hood” in the system shell or in a text editor. This could lead to system disasters due to lack of in-depth knowledge of an application, such as Apache or Postfix (mail server).

My own philosophy falls in the middle. I encourage the use of well-designed GUI’s for configuring servers while promoting and encouraging new administrators to take the time to learn the system shell, to learn how to edit text files in Pico or Vi, and to read the man pages for each application they use. Thus, the convenience and speed of GUI configuration prevails, and in an emergency, the administrator is capable of dropping to the system shell and cautiously proceed with management of any troubled application(s).

One open source GUI that has been growing by leaps and bounds is Webmin, which enables comprehensive control over a Linux server, including management of Apache, DNS, FTP, database services and mail services as well as system level administration.

They are found at http://www.webmin.com

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Nick Aghazarian

    I started working for a company that had a software package on the IBM system 36 and 38. Six months into my job, we received a “beta” copy of the new offering from IBM called an AS/400. The AS/400 has a full command line interface, as well as a fairly nice menuing system (this came by combining the best parts of both the systems 36 and the 38).
    The command line was much faster to use, if you knew what you were doing. One benefit of the system was the ability to prompt for a command, which would bring up a screen with a text description of each command, and often, a list of possible values. Better yet, once you finished typing in the parameters, you could hit a key and see what the command line version will be.
    Just like most shells, there was a retrieval key to bring back previously entered commands, so you could also exectue the command from the prompt, and then retrieve the command to see what you could have typed in.
    With a tool like that, learning the command line tools was not only reasonably easy, it bordered dangerously on fun (which should never happen at work).

    Wouldn’t it be cool to have a shell with a tool like that?

  • psp

    GUI configuration tools are all well and good for individual use, but the greatest advantage of text based configuration is that it can be kept in a revision controlled repository. This allows for accountability, revision control, ease of rollback and (very importantly) commenting of what has been done/changed and why. Self documenting configs are a god-send. Probably why IIS in Windows 2003 server stores it’s config in an XML file which can be rolled back ;-)

  • http://www.practicalapplications.net bwarrene

    Excellent point on cvs and revision control of configuration files. That might be a topic worth expanding into one of my SitePoint columns…any thoughts or feedback on that..?