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.'"
Re:It would be good to have optional GUI (Score:3, Informative)
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.
Re:It would be good to have optional GUI (Score:5, Informative)
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)
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.
Re:It would be good to have optional GUI (Score:3, Informative)
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.
Re:It would be good to have optional GUI (Score:4, Informative)
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.
Re:It would be good to have optional GUI (Score:5, Informative)
Comment removed (Score:3, Informative)
Comment removed (Score:5, Informative)
BS, GUI apps are **ALWAYS** slower! (Score:5, Informative)
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.
Re:It would be good to have optional GUI (Score:4, Informative)
Re:It would be good to have optional GUI (Score:4, Informative)
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