Long-time Linux and Windows Admin here
I've been administrating Linux boxes since RedHat 6.1 and Windows since Windows 2000 Server and here's my take on the whole situation.
Since the very first Linux server I set up 15 years ago right to today I deploy every single one of my Linux server installations without a GUI. As a matter of fact "Bare Minimum Install" is my installation preference of choice and I subsequently install what I need post-installation. This allows me to better understand what it is I precisely require along with the dependencies of my requirements.
I have always believed that it is important to know what you are installing as it subsequently allows you to evaluate what should or should not be configured post-installation.
CLI-only management on Linux will always be my preference. Not only do you dramatically reduce the storage footprint of the OS it also greatly reduces the number of attack vectors. Anyone who has installed a GUI on a Linux box and subsequently reviewed the sheer number of dependencies required will know what I'm on about. Linux without GUI allows for dramatically less packages to maintain.
And I love it. And to be brutally honest; it is a lot more intimidating than it is difficult to learn. Does it mean I loathe GUI's in general however? No it does not. I too adore Windows Server for what it is capable of. Active Directory, Group Policy et al are awesome for the management of enterprise clients and neither Apple nor Linux come close to giving this level of client management and control.
You cannot really compare Linux and Windows however in this regard.
CLI-only management on Linux works because just about everything is configured via config files (one of the key aspects why I am pro-Linux when it comes to mission-critical external services such as mail). It also works because Linux commands are short and easy to remember. Most Linux admins for example know what "grep" does but the vast majority do not know why "grep" is called "grep."
But it works.
Tried using PowerShell? The sheer insanity of how long commands can get is both mind-boggling and CTS-inducing. If you had an identical task to complete on Bash and Powershell the command for the later would almost always be a LOT longer than that of the former. And because you do not configure Windows via config files (thank you Registry) you end up with a LOT of commands to remember.
A simple example would be to compare typing "vi httpd.conf" on Linux to manage Apache to the dozens and dozens of PowerShell Cmdlets which exist to manage IIS on Windows Server.
The reason CLI management on Linux works and the reason GUI management on Windows works is simply because that is how the operating systems were designed and how they subsequently evolved. Trying to change it is going to be a massive challenge especially if you are going from GUI to CLI. Each do have their pros and cons however and there is no point debating which is better.
I absolutely love how easy it is to backup, restore and otherwise move around config files on Linux and also how easy it is to manage and track config updates as a simple diff between an old and new config will immediately tell you what has changed (and likewise running a versioning system against your config files is awesome for ensuring that config changes are always accurately kept track of).
On the other hand I could never see myself managing something like Windows Group Policy on a CLI. There's simply too many configurable parameters and a GUI allows for the intuitive display of vast amounts of configuration data along with their respective help files to very quickly grasp what is configured and what the purpose of the configuration in question is.
And again with Linux the portability of configuration files means it's 100% possible to set up the ENTIRE operating system in advance of deployment. The time I spend rolling out a Linux server deployment is usually 1% config, 4% installer, 95% waiting for data to copy. Since all I need to do post-installation is to run a script which copies all of my config files into place.
Doing this on Windows is often lot trickier if not impossible.
Above all however I demand that my server operating systems be 100% configurable stand-alone without any network connectivity. It is a bloody joke that Microsoft expects you to use MMC to remote into a Windows Server simply because the server in question does not have a GUI. And don't think PowerShell will save you either because you will either be spending a lot of time trying to figure out which Cmdlet you require or the Cmdlet in question will simply not exist. Even Microsoft themselves admit that you cannot fully deploy and configure Windows Server purely from PowerShell.
When I need to cut connectivity to a server due to whatever emergency that warrants such an action I will want to be able to get in front of the server and immediately troubleshoot the problem if it is within my means to do so. If I'm already in front of the server with monitor and keyboard why should I need to dig out my notebook to manage the damn thing?
Anyhow this was my 0.02$ and my sincere apologies for the length of this post.
Biting the hand that feeds IT
