Slashdot Mirror
Take This GUI and Shove It
snydeq writes "Deep End's Paul Venezia speaks out against the overemphasis on GUIs in today's admin tools, saying that GUIs are fine and necessary in many cases, but only after a complete CLI is in place, and that they cannot interfere with the use of the CLI, only complement it. Otherwise, the GUI simply makes easy things easy and hard things much harder. He writes, 'If you have to make significant, identical changes to a bunch of Linux servers, is it easier to log into them one-by-one and run through a GUI or text-menu tool, or write a quick shell script that hits each box and either makes the changes or simply pulls down a few new config files and restarts some services? And it's not just about conservation of effort — it's also about accuracy. If you write a script, you're certain that the changes made will be identical on each box. If you're doing them all by hand, you aren't.'"
Here is a Link to the print version of the article (that convenientily fits on 1 page instead of 3).
Providing a great GUI for complex routers or Linux admin is hard. Of course there has to be a CLI, that's how pros get the job done. But a great GUI is one that teaches a new user to eventually graduate to using CLI.
A bad GUI with no CLI is the worst of both worlds, the author of the article got that right. The 80/20 rule applies: 80% of the work is common to everyone, and should be offered with a GUI. And the 20% that is custom to each sysadmin, well use the CLI.
--
dead simple alternative to incorporating for web startups
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.
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
/etc/init.d/NetworkManager stop /etc/sysconfig/network /etc/sysconfig/network-scripts/eth0
chkconfig NetworkManager off
chkconfig network on
vi
vi
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.
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!
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.
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.
Win2008 Core still has a GUI. It's just that it's a GUI that only has a single graphical terminal window open by default, but nonetheless there's a window manager and all the other stuff. And you can open more terminals, and run GUI apps which open their own windows as well (if I remember correctly, it does have Notepad out of the box which can be used that way).
That said, resources consumed by such a thing are so tiny that they won't be noticed even on a mid-range modern desktop, much less an actual server. And it does make life somewhat easier when you actually have to work with it directly (e.g. because ssh is failing for some mysterious reason).
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.
"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.
Got Code?
'admins don't typically do stuff once' WTF world do you live in...? I administered a 500 user network a bit over a year ago and very few things were repeated. I set up servers once, and then unless I needed to change something I didn't need to reconfigure them. Now some things like new user accounts is common and repeatable... But those take 2 or 3 minutes and it's done, unless you really cycle massive amounts of employees this should never be more than a half hours work... And a GUI is easily adept at simple repeated tasks. In my 4 years I found little need for scripted anything outside an oracle database and maybe some rare cases with exchange (of all things). Everything else was usually taken care of from a centralized system once, and rarely if ever done again.
we are all invisible unless we choose otherwise
Eh? We've got several thousand users, a working master/slave replication setup, and very few issues with our LDAP. Usually if something goes awry it's indicative of another problem that also has side-effects on LDAP....
http://en.wikipedia.org/wiki/Windows_PowerShell
.NET objects, they share a .ToString() method, which retrieves the text representation of the data in an object. Windows PowerShell uses this method to convert an object to text. In addition, it also allows formatting definitions to be specified, so the text representation of objects may be customized by choosing which data elements to display, and how. However, in order to maintain backwards compatibility, if an external executable is used in a pipeline, it receives a text stream representing the object, and does not integrate with the PowerShell type system.
.NET type system, but with extended semantics (e.g. propertySets and 3rd party extensibility) . For example, it enables the creation of different views of objects by exposing only a subset of the data fields, properties, and methods, as well as specifying custom formatting and sorting behavior. These views are mapped to the original object using XML-based configuration files.[17]
Another concept used by PowerShell is that of a pipeline. Like Unix pipelines, PowerShell pipelines are used to compose complex commands, allowing the output of one command to be passed as input to another. A pipeline is set up by piping the output of one command (or pipeline) to another command, using the | operator. But, unlike its Unix counterpart, the PowerShell pipeline is an object pipeline; that is, the data passed between cmdlets are fully typed objects, rather than character streams. When data is piped as objects, the elements they encapsulate retain their structure and types across cmdlets, without the need for any serialization or explicit parsing of the stream, as would be the need if only character streams were shared. An object can also encapsulate certain functions that work on the contained data. These also become available to the recipient command for use.[13][14] For the last cmdlet in a pipeline, PowerShell automatically pipes its output object to the Out-Default cmdlet, which transforms the objects into a stream of format objects and then renders those to the screen.[15][16]
Because all PowerShell objects are
The PowerShell Extended Type System (ETS) is based on the