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


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
GUI Microsoft Windows Technology

Windows Admins Need To Prepare For GUI-Less Server 780

msmoriarty writes "We knew Windows Server 8 was going to be a departure for Microsoft, including an 'optional' GUI, but in a blog post made earlier this week, the Windows Server team said that working without the GUI will be the 'recommended' method, and is telling developers not to assume a GUI will be present. According to Windows consultant and author Don Jones, this is a big hint to Windows admins that they better get used to not having a GUI in future releases. From the article: 'I'm well aware that many Windows admins out there aren't looking forward to a GUI-less server operating system from Microsoft. ... I'm sure Microsoft has, too.They're proceeding anyway. We have two choices: adapt or die.'"
This discussion has been archived. No new comments can be posted.

Windows Admins Need To Prepare For GUI-Less Server

Comments Filter:
  • by Sipper ( 462582 ) on Friday January 13, 2012 @10:28AM (#38686162)

    Yes, it's easy to install X11 on a Linux server - but it's also generally a stupid thing to do, security-wise, if your server is internet-facing.

    In general you're probably right, but it's not necessarily the case. You can install X11 without it actually running a GUI so that in a pinch you can run a GUI program via ssh X forwarding when you have to. This works even on headless machines. The question I (personally) have is how safe X forwarding over ssh is.

  • by sideslash ( 1865434 ) on Friday January 13, 2012 @10:47AM (#38686484)

    I think you proved his point by making the assertion that by running a Windows Server with a GUI you are somehow magically increasing your bandwidth. Care to explain how a GUI increases that?

    Since the other guy didn't answer your question, I am happy to...

    Let's suppose that your home connection is dial-up, like 56 kbit/s. That's the slow home connection. Got it?

    Let's suppose that the "server" computer is hosted in a nice data center with a fast connection. That's the faster server connection. Got it?

    Now, this is the part you missed -- the admin wants to do something like upload database files somewhere, or move media around, or something related to his organization's operations. If he does it through his dial-up, it will be excruciatingly slow. However, his dial-up is fast enough to let him access the server via Remote Desktop or VNC, so hey, presto! Using the GUI remotely allows him to have faster bandwidth. He is effectively then using his local machine analogously to a "dumb terminal".

    It's the kind of thing that makes sense after you've experienced it once or twice.

  • Re:Shows ignorance. (Score:5, Informative)

    by Enderandrew ( 866215 ) <enderandrew@gmailELIOT.com minus poet> on Friday January 13, 2012 @11:03AM (#38686816) Homepage Journal

    True, but the GUI doesn't take 25% CPU or 30-50% of memory. Our cheapest, oldest servers are 32-bit and can only use 4 GB of RAM. Even then, the GUI environment probably adds 300 MB of memory utilization, which is rarely an issue for those servers than usually don't go over 2 GB of total memory utilization.

    Intensive applications reside on servers with 76GB of RAM, where those 300 MB become a drop in the bucket.

    When you start talking about really large numbers of servers and virtualization, you can see real savings by skipping the GUI. But the parent claiming that a GUI always takes 25% CPU and 30-50% of memory is frankly lying.

  • by Rakishi ( 759894 ) on Friday January 13, 2012 @11:29AM (#38687222)

    That has absolutely nothing to do with having a GUI or not. In other words you utterly fail to understand the point of what you replied to. Congrats.

    Command line tools let you do everything on the server even more easily than a GUI, your whole argument is worthless.

    In fact, your GUI will be an order of magnitude slower on that limited connection than my ssh command line. After all, you need to have all the data sent back and forth that describes the GUI. I just need to have a few kb worth of text sent back and forth.

    In other words it's you who utterly missed the point.

  • by LVSlushdat ( 854194 ) on Friday January 13, 2012 @11:29AM (#38687238)

    In the case of a Linux server, you can configure your GUI to only run WHEN you want it to, via the tried/true "startx" command. In my last corporate job, we had a rack full of Redhat servers where the previous admin had decided that the default "runlevel 5" was just peachy for these number-cruncher systems. For those who don't know, on a Redhat-type Linux server, runlevel 5 means the GUI (usually Gnome) is running ALL THE TIME. I convinced the IT manager, who was a long time Windows admin type, but knew very little about Linux, that it would be FAR better, performance-wise, to change these to runlevel 3, and only start the GUI when it was truly needed. He was hesitant about this, as the only Linux he knew was basically via the Gnome GUI. I showed him how easy it was to switch the kvm to the desired box, type "startrun" and voila! there's your gui... Now when I set up an Ubuntu server, I use the basic server ISO, then after installation of it on the system, I install one of the light-weight GUI like Blackbox/LXDE or the like, and configure it to run only with "startx". Given the ease of this, I wonder if Microsoft intends this type of switchability in Windows 8.. I'm gonna go out on a limb and bet that its going to be an "either-or" configuration with Windows 8, either the GUI running all the time or no GUI functionality at all.

  • by aztracker1 ( 702135 ) on Friday January 13, 2012 @11:36AM (#38687368) Homepage
    Not to mention that a GUI-less mode was available in Windows Server 2008 already.
  • by datavirtue ( 1104259 ) on Friday January 13, 2012 @11:54AM (#38687708)

    Dropping the video cards will save on power usage and costs. As an observation, out of many of the IT force now emplyed, a majority are actually afraid of the command line. Out of all the people in my department, I'm the only one who prefers a command line. Those who have elected to avoid it are not very productive since they cannot script anything. Everything they do is through repetitive GUI travel. Many have established their tech brain pathways with a GUI; it will be a painful transition for some who are forced to use a command line. Personally, I like to script things so I can pass the tasks off to a monkey and free my time for more automation. Before I arrived, the only scripts in the house were copy and pasted from the Internet.

  • by DigiShaman ( 671371 ) on Friday January 13, 2012 @12:14PM (#38688034) Homepage

    What massive savings? Most of the Dell PowerEdge servers I've worked with have barebones ATI video chips that frankly do nothing more than 2D video. Were talking about something equivalent of 10+ year old graphics technology shrunk down in die size with newer chip fab processes. It consumes all but what, a fraction of a watt? And that's if it's heavily utilized via consoled KVM?

  • by mangu ( 126918 ) on Friday January 13, 2012 @12:48PM (#38688522)

    Since these two posts have got so much positive moderation one must assume there are moderators here who have absolutely no idea of how a server works.

    Logging in remotely to a server has nothing to do with having a GUI. I do it routinely on my Linux servers using SSH. Using SSH my personal computer is working as a dumb text terminal, which is orders of magnitude faster than a VNC when you have a slow connection.

    Having a GUI on the server will worsen your performance.

  • by slaxative ( 1867220 ) on Friday January 13, 2012 @01:30PM (#38689250)
    Just an FYI, runlevel 5 by default, does not kick off Gnome or any other window manager under RHEL. It starts GDM or KDM which is simply the login manager for launching your selected window manager. It does not tax the machine very much to simply run the login manager. Now if you were in fact launching KDE 4 or Gnome then yes that would be an undesirable load on the system.
  • by TheLink ( 130905 ) on Friday January 13, 2012 @01:32PM (#38689280) Journal

    Removing the GUI is forcing people to learn more efficient ways to manage their environment.

    Removing the GUI would be a stupid move by Microsoft. I doubt they would actually do that despite what Don Jones says.

    As the summary says, Microsoft is telling _developers_ of server software not to assume the presence of a GUI. So if you're writing software for servers, you may have to provide configuration and management methods via the CLI as well.

    If Microsoft somehow comes up with a decent standardized way of making writing such interfaces easier, server software for windows might actually end up easier to manage than for Linux. Not sure if that is possible, but perhaps the geniuses in Microsoft Research can think of a way. The ".Net framework" of server management, or something.

    While Microsoft doesn't have to much more efficient in that the GUI isn't a big resource drain for most server hardware, there are many areas where Windows as a Server is still behind.

    For example:
    1) Windows Services aren't shutdown in an order that respects the service dependencies as provided/registered by the services. The service dependencies are only used during start up[1]! http://support.microsoft.com/kb/203878 [microsoft.com]
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms685149(v=vs.85).aspx [microsoft.com]

    2) To make matters worse a .Net service can't register to be notified that windows is shutting down: http://stackoverflow.com/questions/7437590/is-it-possible-to-register-for-preshutdown-service-events-using-net [stackoverflow.com]

    3) The Windows event log looks nice in (some) theory but is a piece of crap in practice. IMO tail -f syslog |grep -i pattern |grep -v foo works better in practice. Yes if you're Facebook/Google scale you'd need something much better than syslog, but whatever it is, it's not the Windows Event Log/Viewer.

    4) In normal Windows convention and operation you cannot rename/overwrite folders/files that are in use (aka open). This makes updates/upgrades harder to do well and in a consistent manner. This is one of the reasons why on Windows you often have to reboot just to update stuff that in Unix/Linux servers would not need a reboot to be updated. If you have $$$, you can work around this by having load balancing (but it still sucks for a developer to have to resort to this for _reliable_[2] updates: http://technet.microsoft.com/en-us/sysinternals/bb897556 [microsoft.com] ) . It's not so simple on most Unix/Linux machines to some of this "perfectly" either - since you normally can't do two directory renames atomically: e.g. move the directory "current" to "bkp" and "new" to "current" atomically, but just doing it and hoping for the best is often good enough ;).

    Caveat: I'm not an expert on Windows (or Unix) stuff (only started on VB.Net last year) so maybe I'm wrong. But if I am do let me know because I would really like easy solutions to the above (no, I do not consider it easy to write a Windows C++ service that registers for Preshutdown and then shuts down the .Net stuff in the correct order, yes it can be done, but it'll take time that I'd rather spend on other stuff).

    [1] And quite often just because the OS has successfully started a service doesn't mean the service is ready for work, so services that depend on it still need to check for readiness - this is not a Windows only problem (can happen on Unix/Linux machines as well), but Microsoft could create a way for a windows service to say it's "ready" and allow services to depend on a service being "ready" rather than just "started".

    [2] Yes you can have something shutdown your service and try to do the moves and copies (of

"The urge to destroy is also a creative urge." -- Bakunin [ed. note - I would say: The urge to destroy may sometimes be a creative urge.]