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.'"
It would be good to have optional GUI (Score:5, Insightful)
Re:It would be good to have optional GUI (Score:5, Insightful)
Reading the actual quotes from Microsoft, what they are saying is that if you are developing a server application, you need to expect that there may not be a GUI and you should develop the application with that understanding. Microsoft never said that a GUI may not be available to install, but that applications should be able to handle the case of their not being a GUI. This is drastically different from what the headline is implying.
Re:It would be good to have optional GUI (Score:5, Informative)
Re:It would be good to have optional GUI (Score:4, Insightful)
What is this, something like 15 years after they put the GUI into the NT kernel in NT 4.0? That fantastic Window 95 desktop wasn't even close to the OS/2 WPS yet still was a performance sucking pig so they had to pull the GUI into the kernel to keep an acceptable performing GUI experience.
I wonder what's causing them to do back to pulling the GUI out of the kernel and even telling server software vendors to code to this configuration? It's SOP for *nix systems so what's going on? From what I've seen running Windows in VM's, you can fit way more Linux servers in VM's than you can Windows and it has everything to do with the performance requirements(CPUs and memory) of the environments. Where's the leaked memo about this anyways?
LoB
Re: (Score:3)
Genuine question -- how did you do that?
Re: (Score:3)
* Be a subscriber (this is the key)
* Be signed in, see the summary early (before it is "posted")
* Visit the summary, write your comment
* Wait until the "posted" time on the summary
* Hit "Submit"
Re: (Score:3)
Be a subscriber (this is the key)
He isn't. The alternative is that he has a script that alerts him to specific stories in the firehose and in the main page, or that he submits the stories himself. See also the previous Google is Evil story.
Then you are doing it wrong. (Score:5, Insightful)
"Having them on server means you have access to much better bandwidth and your programs can run 24/7, and you can easily deploy more servers if you need to"
What?
Really what are you talking about? If you are running a GUI application on a server that is not just wrong but down right silly.
You need more bandwidth? Then you get it more bandwidth.
Now if you are talking about machines with more than one CPU and a lot of memory then sure. Those are called workstations. They may use the same motherboard as a server but they are not being used as a server.
A server needs a GUI like a submarine needs a screen door. If you are going to run anything like that on a server you should really use a VM anyway so that it will not take down the entire box when it crashes.
Anything on a server that you can get ride of like a video card means less heat, less power used, and less cost. It is also one less thing to fail. RDP? how much bandwidth does that take? A lot more than ssh and command line.
And that is why real tech companies use Unix/Linux for servers.
Re: (Score:3)
Server apps shouldn't require GUIs. On Linux you can run a server with no GUI no problem, because it's a well-understood convention in the Linux world that server apps should never require GUIs.
Although having a GUI can make administration more convenient, much more handy to have something like Scite open with a bunch of config files in different tabs than to be switching vi instances back and forth in the CLI to do the same thing.
Re:It would be good to have optional GUI (Score:5, Funny)
there are 2 ways to look at this.
1. once again, Windows has copied Unix.
2. there is so much bloat that the GUI is the only place they can trim.
Flame on!
LOL
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: (Score:3)
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.
What did you use for evidence?
Re: (Score:3)
Yeah at runlevel 5 you just have the login manager and maybe a few GUI-related services running on top of everything else. Dropping to runlevel 3 would save some RAM but little to no processing power.
Re:It would be good to have optional GUI (Score:4, Informative)
Re:It would be good to have optional GUI (Score:5, Funny)
I suppose they can call it "WindowsLess or PaneLess" for the non-GUi version and call the GUI addon "PaneFull"
Re: (Score:3, Insightful)
I'm just waiting to see the reactions from guys who are always saying how Windows is better than Linux because everything is GUI based. This is pretty hilarious..
Soon the pigs will write 'Gui good, no gui better' on the wall....
Re:It would be good to have optional GUI (Score:5, Insightful)
He's just trolling. Not every server application for Windows is made by MS, and therefore not all of them will go GUIless. One of the two I administrate cannot be administrated without the GUI, except possibly by some of it's developers. The other can be administrated without the GUI, but even if you run it on Linux, Solaris or HPUX, the creator highly recommends using the GUI and won't support some changes being made except within the GUI.
HOWEVER, as long as I've administrated Windows and *Nix server, and applications on them, I have very much missed the ability to have GUIless access to a server, when working with Windows. This change should mean that pretty much every server/os level task can be done without a GUI, which will be nice. I prefer to not have to pick one or the other, I'd rather have a server that allows both options well. Using the GUI for tools I don't use much, and CLI for tools I use frequently.
Re: (Score:3)
Re: (Score:3, Interesting)
The idea that powershell is superior to a posix shell is laughable. The syntax is inconsistent, arbitrarily long and arcane. It's like perl and python decided to have a baby with old money. It's disgusting.
Get-Comment-Text | LaughOut-Loud | The-CommentIs-Over
Re:It would be good to have optional GUI (Score:5, Funny)
SEEE!!!! I've been saying it for years. A well chosen name does more of for your product than anything else.
PowerShell... your users will think it's powerful while they Bash other shells.
GIMP... your user think it's a lame version of PhotoShop.
OpenSuse is not a reference to a lose woman.
Mono is not... ok, well, maybe it is a disease.
Wine... Will INEbriate.
C Shell phhh wat we at the ocean dude?
Linux will never catch on unless we start renaming things.
Re: (Score:3)
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: (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
Re: (Score:3)
Re:It would be good to have optional GUI (Score:5, Funny)
Re: (Score:3)
But that has nothing at all to do with the server having a GUI. You get exactly the same situation with GUI-less Windows, or GUI-less *nix.
Re: (Score:3)
I don't see how that factors into either my comment, or the one I was responding to. The fact is, regardless of how you connect to a server on a better network, the server will still be on a better network. Using VNC or SSH, RDP or RSH, it doesn't change the server's network bandwidth.
Re:It would be good to have optional GUI (Score:4, Funny)
You do realize that VNC by it's very nature is graphical?
Quoting to be found later in case I need a new sig.
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: (Score:3)
Sounds like he's wanting to run a terminal server or virtualize and use remote access.
Either that, or he is indeed in the weeds.
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: (Score:3)
It's not just the extra memory and cpu used, but the diskspace wasted by having the gui software present on disk... Then you also have to consider the fact that extra software means extra locations where security holes could reside, and therefore extra files that have to have security patches applied etc...
300mb and however much disk space may not be a lot on a single dedicated server, but it soon adds up...
Consider a VM environment where you have a large number of virtual servers running on a single physic
Re:It would be good to have optional GUI (Score:5, Insightful)
Any sane person recognises that both have their benefits and drawbacks.
Re:It would be good to have optional GUI (Score:5, Insightful)
In reality, Microsoft doesn't need to be more efficient. You can always buy more processing power, which everyone loves. You buy more hardware and more Windows licenses.
The real key is administrative tasks. If you have 100 servers in a pool dedicated to a single task, you need to be able to perform tasks easily on all of them at the same time. The shift to Powershell is all about administering MULTIPLE servers. Removing the GUI is forcing people to learn more efficient ways to manage their environment.
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
Re:It would be good to have optional GUI (Score:5, Insightful)
GUIs can be built to send commands to a command line.
By removing the GUI they're actually opening things up to have bigger/better GUIs than before. The difference is the GUI won't be running on your server, it can be running anywhere.
This enables servers without graphics cards - potentially a massive saving in the datacenter.
Re: (Score:3, Informative)
Comment removed (Score:5, Informative)
Re: (Score:3)
Windows Core, does remove a little more than just having explorer not running. There are a bunch of other services, and schedule tasks that do not run. It is lighter but you are essentially correct in that GDI, and all the window-station stuff is still there.
I am sure it was a backwards compatibility decision. Nobody would have been able to do anything with a Core install beyond basic ADs / file server / radius / DCHP / WINS / DNS type platform services otherwise, because nothing would be able to run. E
Re: (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: (Score:3)
In fact, it's not even appropriate to say you're installing X on the remote host, because you're not. X is on your desktop machine, the remote host just runs an X client that accesses it.
It's data run over an encrypted ssh connection. The remote host is not accepting any connections other than the one you used to start your ssh session to do this. Your desktop is not accepting any connections at all to this. It's not any different in
Re:It would be good to have optional GUI (Score:5, Insightful)
NAT solves ONE problem: more devices than public IPs. Any perceived security benefits are purely incidental and can be solved (better) by a firewall.
Re:It would be good to have optional GUI (Score:5, Insightful)
Yeah, and my firewall/router currently does both for me.
Which means I can use one of the internal-only address ranges to layout my home network, be secured behind a firewall, and not have my network layout be made obvious to anyone else. Which is good, because I have two different sub-nets and two different wifi hotspots in my house.
Since I only get one public IP from my ISP, that covers exactly what I need. I'm sure the greedy bastards would like to charge me for each computer I have, but tough.
Are you implying there's a downside to NAT for a home user? For smaller networks, being behind a NATed, firewalled connection gives me exactly what I need ... and, let's be honest, IPv6 has been about to become widespread for slightly longer than the "year of the Linux desktop" has been imminent.
Tell us, how is NAT a bad thing? So far you've just sneered at it -- from my perspective, it solves the problem it's meant to. And I can't even begin to tell you the number of large corporations I've worked at with computers all addressed within these [wikipedia.org] ranges. Not having them routable to the rest of the planet is actually a useful thing.
Re:It would be good to have optional GUI (Score:5, Insightful)
There is a massive downside to NAT that any home user at an ISP that has been allowed few IPs will tell you.
Any ISP in a non-western country will probably have been allocated far far fewer IPs than it's got clients. Therefore that ISP will be using NAT on his outside network. Couple that with NAT on the inside network for the home user, and you've got the clusterfucks called NAT444 and (the slightly better) NAT464 among others. They're also commonly called Carrier-grade NAT (CGN) or large-scale NAT (LSN): http://en.wikipedia.org/wiki/Carrier-grade_NAT [wikipedia.org]
This consistently completely screws up all sorts of connections, such as:
- XBox and Playstation 3 networking (you'll see "NAT Type 3" on the network config)
- FaceTime
- etc...
Basically anything that is a peer-to-peer protocol with reciprocal client-server stuff is shot.
Re:It would be good to have optional GUI (Score:5, Interesting)
Which means I can use one of the internal-only address ranges to layout my home network, be secured behind a firewall, and not have my network layout be made obvious to anyone else. Which is good, because I have two different sub-nets and two different wifi hotspots in my house.
There's nothing about having a globally unique IP address that implies that your network layout would be obvious to anyone outside your network.
Since I only get one public IP from my ISP, that covers exactly what I need. I'm sure the greedy bastards would like to charge me for each computer I have, but tough.
If we had IPv6 we would all have as many ips as we needed free of charge. This is the only problem for which NAT is an appropriate solution.
Are you implying there's a downside to NAT for a home user?
Sure, two desktops can't seed torrents (or host any other services) without manual configuration of the router. It wreaks havoc on VOIP for instance.
And I can't even begin to tell you the number of large corporations I've worked at with computers all addressed within these ranges. Not having them routable to the rest of the planet is actually a useful thing.
You don't need to have NAT to have those addresses non-routable. You just need your firewall to drop all traffic to those addresses.
Re: (Score:3)
NAT is not a physical network separation. An air gap is a physical network separation.
Re: (Score:3)
The program can still have a configuration gui. You just need a remote client running on a client operating system or a web interface, which again you can access from a client platform.
Honestly most 'builtin' windows services can be remotely managed from a client platform machine already. This should be the preferred way. Generally if you as a matter of routine need to use a desktop session on your windows servers barring the ones specifically being used as terminal servers, you are doing it wrong.
Mistak
Re:you're unclear on the concept (Score:5, Insightful)
Some stuff, sure. But, if you maintain clusters of machines or need to do hugely repetitive tasks, a GUI can actually be a hinderance.
I have seen applications in which you might be administering literally hundreds of items, if not thousands ... for some maintenance tasks, you end up manually going through a GUI for hundreds of items one at a time to make a change. Which is boring, repetitive, and error prone. One of the advantage of doing things GUI-less is that it allows for automation of tasks more than a GUI.
Almost anything you need to run at a corporate level where you have a lot of them works way better if you can automate it ... I have seen people trying to make changed to a large number of SAN allocated volumes, and it's painful to watch someone go through the steps with a GUI, and it's a lot more error prone.
If you're talking about a single, stand-alone piece of software that doesn't devolve into having hundreds (if not thousands) of items to control, sure, a GUI is great ... but if you ever have to update hundreds of items at a time, the GUI paradigm can fall apart completely. I once had a task to do in which I had to modify around 75 things ... it took me about 4 hours of "click button, wait, click next button, wait" and made me want to kill the developers who had written it. Partly because there was no multi-select, and partly because if it was scriptable it would become an easy maintenance task -- without it, it's painful. And, it's not like they couldn't anticipate people would need to do this often and to a large number of items.
Even for some routine maintenance I need to do on some machine clusters, it's easier to write a batch script and use "sc" to start and stop services .. because I need to shut down and disable the exact same service on 15-20 machines, I need to do it right now, and I need to get them all down as close as possible. Logging into each machine and shutting these services down with Task Manager ... well, that's pretty much a time sink. Then when I need to start them all up, I've got a corresponding script. These are tasks that we do approaching daily in one or more clusters.
For years Windows has had the "GUI only" paradigm for most applications ... pushing more applications to be scriptable and run headless will go a long way to making many administrative tasks much easier to handle. It may take a bit of a learning curve, but being able to automate certain tasks eventually becomes a huge time save (so it saves money), and is a lot more consistent (which also saves money).
I applaud Microsoft starting to push application developers towards this ... because the sheer amount of items I've seen which can benefit from this has convinced me that we must spend countless man hours of someone clicking through a GUI when a script could do it in a few minutes. That tends to be hugely lost productivity that people could be spending doing other tasks.
Re:you're unclear on the concept (Score:5, Funny)
You should have used a CLI to automate your paragraphs, which restated the same few (valid) points 6 times. :)
Re: (Score:3)
Please no, programs can actually be quite complicated. They aren't like web servers which you configure and leave running. Making them GUI-less will just complicate things and make it much harder to use. There's a reason we use GUI's now a days - it's better for some stuff.
How easy is it to deploy SharePoint automatically? How easy is it to automate the configuration and setup of new SharePoint servers? There are a few tools in the Windows world to automate clicks on various GUI elements...
In Linux, I can deploy complex database sites with a few lines of code in a fab file, or maybe a preseeded dpkg, or maybe bash scripts, or maybe a GET request with a few parameters to generate a config file for the specific server, or I can easily image the server and blow it to all th
Re: (Score:3)
Computer solutions approach coming full circle (Score:3, Funny)
No, admin will still be GUI (Score:4, Insightful)
Microsoft's intention is to just have GUI clients for admin, don't get your hopes up that they would actually raise the bar to have real computer sysadmins who can function from a command line
Core (Score:4, Interesting)
Obligatory quote (Score:3, Insightful)
Those who do not understand UNIX are doomed to reinvent it, poorly.
Re:Obligatory quote (Score:5, Insightful)
Just like they did with Android.
So, why is it called Windows, then? (Score:5, Funny)
Re:So, why is it called Windows, then? (Score:5, Funny)
Or how about MS-DOS 8?
Re:So, why is it called Windows, then? (Score:4, Funny)
Microsoft Shell, has a good ring to it.
Re:So, why is it called Windows, then? (Score:5, Funny)
you missed an " ' " and misplaced a space
Re:So, why is it called Windows, then? (Score:5, Funny)
I always think that when I see their new command line product
Microsoft Powers hell
Oopsie, another misplaced space.
3D Pinball (Score:5, Funny)
How are we supposed to play 3D pinball in the server room now?
Re:3D Pinball (Score:5, Funny)
How are we supposed to play 3D pinball in the server room now?
Wait, you DON'T have a real, physical pinball table in your server room?
ceci n'est pas une fenêtre (Score:5, Funny)
I, for one, welcome our windowless windows overlords.
Start training now: learn linux (Score:3)
Imitation is the most sincere form of flattery. But now, what's the point to windows if there's no GUI?
Re: (Score:3)
Has anyone tried to run Exchange on WINE recently; I wonder....
Client GUI!= No GUI (Score:4, Insightful)
What they actually recommended is running the GUI on the client.
Obligatory question. (Score:3)
The Ancient Battle (Score:5, Interesting)
GUI vs. Command Line. I lived through that argument in the 80's and 90's. With a GUI, syntax problems go away - IF you can figure out how to find/launch the GUI. On the command line, all commands are available in one spot, but the syntax can be challenging. We really just traded one problem for another.
But for those of us who run production shops, a GUI isn't scriptable and is therefore not testable. Command line scripts can be tested in an offline environment, emailed around, put under version control, and printed out for enjoyable bathroom reading. Who doesn't love command line scripts???
Re: (Score:3)
GUI vs. Command Line. I lived through that argument in the 80's and 90's. With a GUI, syntax problems go away - IF you can figure out how to find/launch the GUI. On the command line, all commands are available in one spot, but the syntax can be challenging. We really just traded one problem for another.
They way I usually put this is that GUIs are easy to learn, but tend to be difficult and inefficient to actually use, while CLI is difficult to learn, but once you do, they're very easy and quick to use. Which one is better depends on your particular use case.
Re: (Score:3)
As I see it, GUIs present a limited surface of options to the user. Assuming that the user wants the options provided by the interface, this is fine. Command lines can have a potentially infinite list of options, limited only by the user's willingness to look them up and type them.
Consider all the option dialog boxes you've seen with multiple tabs and buttons to open new dialog boxes with scrolling lists of options on yet another tab (eg, "Internet Options") as an attempt to get a huge number of options in
GUI (Score:3)
Most competent Windows server admins don't need a GUI on the actual server anyway; between the RSAT (Remote Server Admin Tools) and Powershell, there's very little that you need to be "on the box" to do.
Most good Windows server admins can do almost everything via Powershell anyway - of course it would be much easier if Microsoft would write decent Powershell modules for DNS and DHCP so you didn't have to do everything via COM objects and dnscmd.
Bad idea (Score:4, Insightful)
I'm pretty comfortable with a CLI, it's what I grew up with and use on a routine basis for many things. That being said there is a lot out there in terms of server based applications that are wholly dependent upon having a GUI.
Were not talking about simply rearranging the desktop here, were talking about removing the very interface that is depended on by an entire ecosystem of software. That market is easily in the billions of dollars per year. If your going to force all those developers and legacy applications to run as CLI only than your giving those companies an opportunity to re-evaluate the platform they use for a CLI based tool.
If your giving companies the impetus to decide what platform to use for a CLI based tool than many of them are simply going to switch to *nix support since there is a strong legacy ecosystem to support it. In other words if Microsoft were to do this for all of the Window Server based platforms it would be suicidal. That's a pretty poor business case and it simply doesn't make sense.
I think the far more likely case is that certain versions of Windows server will be available as CLI only (web platform etc), which they already are. I really have to question if the source of the story got their facts right, it doesn't make sense unless they didn't.
Legacy Applications? (Score:3)
I like the move, but it will be difficult or impossible to run older (poorly written) applications that need a GUI to run.
Sort the men out from the boys (Score:5, Insightful)
Finally the manager in our IT dept will have to get a clue.
I'm guessing he will do everything he can to hold off upgrading as he knows he wont be able to cut it.
I'm actually hoping he will get moved out so we can finally move to Linux.
From TFA: old boss = new boss (Score:3)
From TFA: "In addition to Server Core (the existing CLI from Server 2008) and Server Graphical Shell (the usual GUI), we are introducing a new experience in Windows Server 8 called the Minimal Server Interface."
Also from TFA: "Technically, the Minimal Server Interface is a full Windows Server install excluding Internet Explorer, Windows shell components such as the desktop, Windows Explorer, Metro-style application support, multimedia support, and the Desktop Experience."
In other words, you'll have a command-line only version, like you do today, a GUI version that behaves like the latest Windows desktop OS, and a GUI version that behaves like a locked down server is expected to behave (the "Minimal Server Interface"). Or at least that's how I read it.
Some things never change - reboot for GUI (Score:3)
FTA:
"In Windows Server 8, users can transition between Server Core and Server Graphical Shell at any time, with a single command and a single reboot."
Don't they EVER learn? It took them literally years to be able to do application and driver installs without required endless reboots. Not poor windows admins need to reboot just to start the GUI?? Why on earth can't MS come up with the equivalent of "xinit" to kick off the GUI?? This is 1980s level functionality FFS!
Probably just sensationalism as usual... (Score:5, Insightful)
"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."
Is it? or is that theory just completely made up?
Just because the server doesn't locally have a GUI doesn't mean it wont allow RDP connections, and doesn't mean you wont just be able to use the likes of event viewer, IIS manager, or whatever, installed on your local system, to connect to and manage a remote server.
I don't think most people manage Windows servers locally anyway nowadays, most IT staff are too busy enjoying the fact they no longer have to get off their arse to go to the server room because they can do everything they need with a GUI from their desk. I don't see anything to indicate that side of things is changing - just that Windows Server will no longer by default sit their handling a locked GUI for local users no one ever fucking uses anyway whilst continuing to offer the console based management option that was introduced in what, Windows 2008 Server? even then I suspect, being Microsoft, the Windows GUI will only be a quick click or command away but will simply be initialised on demand, rather than always there.
Re: (Score:3)
Thank goodness, someone who made a sensible point and got modded up.
The majority of this discussion so far has been rampant speculation. Rant: why can't people read the &^%* articles occasionally? End rant
The second linked article from Technet gives a lot of answers. This is particularly useful:
In Windows Server 8, the recommended application model is to run on Server Core using PowerShell for local management tasks and then deliver a rich GUI administration tool capable of running remotely on a Windows client.
(Emphasis mine.)
It also goes into quite a bit of detail about something called the Minimal Server Interface.
The Minimal Server Interface enables most local GUI management tasks without requiring the full GUI Shell or Internet Explorer to be installed. It is an intermediate state that is installed by enabling the Graphical Management Tools and Infrastructure Windows feature and not enabling the Server Graphical Shell feature.
As you say (and as most people on /. should realize), managing a server locally is pretty anachronistic
Innovation? (Score:5, Insightful)
Microsoft, the company for which the future is what everybody else is doing for more than 30 years.
Long time coming (Score:3)
This sounds like a solid move to me. I've been wanting for a long time for MS to separate IE from the GUI, and it's about time they did.
Keep it sane (Score:3)
In general, I like this approach. However, my faith in Microsoft's ability to produce a sane design for CLI management is not high. They have been moving toward this for about 5-6 years now, so it shouldn't surprise anyone. However, working with Powershell is no walk in the park. Sometimes I think they assign commandlet design to different members of the team. Those team members (thousands of them!) work on the commandlets from their own point of view with little oversight into the syntax or object model.
For instance, the object types that you would expect out of one Powershell commandlet (after you figure out the syntax, that is) is not what the next command expects as input. This has been the most frustrating part of Powershell and I keep hoping that eventually they will attack this with a more holistic approach to produce something with a little more clarity and sanity.
THIS is the year of Linux... (Score:5, Funny)
Suddenly Win Admins everywhere switch to Linux because its "easier".
I wonder (Score:3)
MS Certifications implications (Score:3)
So, MS is going to make a shift towards more CLI. I had already heard rumours and stories that some configurations would have to be done on the Command Line. I may be a little cynical here, but consider the following:
Over the past while, the perceived value of having MS Certifications has dropped somewhat as MS Windows Servers become more easily configured. Now, Administrators will have to know some of the more arcane commands, and have a better understanding of how the systems work in order to properly configure Windows Server without the GUI's.
Aside from some of the improvements that folks have already mentioned, would this not also revitalize the revenue stream that MS gets from the training and certifications? And, make these certifications actually more relevent?
Windows Cl is useless (Score:4, Funny)
I'm baffled by this because the Windows command line is absolutely, positively useless in every way. It lacks a proper history function, proper tab completion, proper environment variables, it is not possible to configure most things with text files, scheduling tasks is practically impossible, the multi-rooted filesystem is an unfunny joke, and most of all Batch scripts are literally, not figuratively, the least useful form of programming I have ever seen, including taking a shit on a keyboard and hoping for the best. The entire Windows stack is completely inappropriate for use in any business, let alone as a server, and thinking of using it without the GUI makes me fear and hate it even more than I fear and hate Windows right now.
No. No, Microsoft, no. No, no, no. If you want to make the world a better place, here is a three-step plan:
1. Discontinue Windows. Burn it in a fire, and then apologize for it.
2. ???
3. The world is a better place.
Sounds great but.. (Score:3)
I'm guessing that the reason for using a Windows server is to support some very Windows specific application(s) otherwise why bother? For almost any purpose Linux is better/cheaper/faster/more secure! Just like you would use Solaris for a Solaris-specific server application or NSK for something very critical/scalable. Windows has been eclipsed, and the GUI is compatible with existing code.
don't call it a comeback, we've been here for year (Score:5, Funny)
Re: (Score:3)
"Novell, UNIX, VMS, MVS, OS/400,"
Don't forget Cisco.
"They've matured enough to now acknowledge they don't need a GUI"
Arguably they've simply returned back to the level of CLI functionality they had - then threw away - with Xenix. If MS had stuck with that OS and developed it as much as Windows has been developed since its initial incarnation then who knows how much more advanced its offerings would be today.
Re:Linux? (Score:5, Insightful)
If you want to talk about server administration, you'd do well to remember that Novell didn't even give you many options on the console on the server. Most of the tools were run on the workstation. The whole point was that there wasn't much reason to ever sit at the server itself.
Re:Not a problem (Score:4, Insightful)
Right, but when a huge chunk of your market is going to be businesses with 15-20 employees and no dedicated IT person, or if they have a dedicated IT person they're not actually a trained IT person, having a CLI only is utterly braindead. Part of the appeal of a windows server is that the poor dude who is asked to do all the IT stuff, but isn't actually an IT guy has a much lower barrier to entry in understanding 'Windows that happens to be a server' than trying to understand 'LAMP'.
Now admittedly, MS may be envisioning this is a 'off in the cloud' scenario, where even small businesses buy time on a professionally run server where that barrier to entry is immaterial. But that's a significant misread of a big blob of their market. All the attention this has been getting should have told them that.
I'm a professional CS guy. I'm getting a PhD in comp sci, and I used to be a dedicated IT guy. I consult and teach people how to do this stuff. When I consult, sometimes even at big outfits (think something like CBS or a hospital) their little offices or division that handle something in particular have a guy on staff who is the least technically incompetent person. They might have a degree in history, but be the youngest person on staff, or they're a gamer and know more about computers than say... anyone else. But they look at a CLI (correctly from their perspective) as something that died 20 years ago, and they have no desire to learn. Even kids in IT programmes are generally unprepared for this. And making them uninspired about your product before they've even started working doesn't seem like a great plan.
Windows server is less about technology and more about brand familiarity. Obviously Microsoft is completely unaware of this.
Re: (Score:3, Interesting)
Part of the appeal of a windows server is that the poor dude who is asked to do all the IT stuff, but isn't actually an IT guy has a much lower barrier to entry in understanding 'Windows that happens to be a server' than trying to understand 'LAMP'.
No, that's part of the problem of a Windows server, in my experience.
Although I suppose I shouldn't bitch too much, as it's made me quite a bit of money over the years fixing the idiot braindead mistakes these "poor dudes" make.
Re:Not a problem (Score:4, Insightful)
So the path to making better software is to make it more obfuscated and less user friendly? Making it easier for those poor dudes is what MS has been doing for 20 years, and why they finally made some inroads into the market.
20 years old today have no clue how to use a command line unless they are from the 1% of users that have a linux desktop at home. We see, in a programme with about 200 students, one or two kids a year like that (and this is in CS). I had to do a class thing yesterday which was basically an 'intro to our unix systems' for non CS kids. Basic stuff, make a directory, list contents that kinda thing. None of them had the slightest clue how to do anything on their own. I was starting from scratch, completely, they didn't even know what to search for on the web, or that such commands still existed. These are kids in physics, math, biochem, and they didn't know how to make a directory without a GUI. Admittedly, that's why we're teaching them the CLI stuff. But they won't use it. It might take longer, but they've grown up with a GUI, so they'll use a GUI. My suspicion is their immediate impression of linux was 'antiquated'. That's not accurate of course, but that was the perception we created. MS should realize who their market is, and make better software and tools for them.
Re:Not a problem (Score:5, Interesting)
So the path to making better software is to make it more obfuscated and less user friendly? Making it easier for those poor dudes is what MS has been doing for 20 years, and why they finally made some inroads into the market.
Or read a different way, the path to having a more powerful, secure, stable, and easy to manage server is to actually have people that know how to admin a server--Windows or Linux.
I run into 'Windows Admins' all the time who only know a few point-and-click things. The moment stuff breaks they are clueless. Every time I run into a Linux admin, they know their shit *and* they know how to properly admin a Windows server. (Or if they haven't touched Windows in years or decades, they will be frustrated but they can figure out the problem because they grok *how* shit works because Linux doesn't abstract them from it.)
This is not a bash on truly good Windows admins--there are lots out there, but they cost a lot, just like good Linux admins. Microsoft has simply created a market for low-cost morons who can call themselves 'admins', but they really aren't. I have several friends who are 'web designers' because they bought Microsoft Front Page. There isn't a chance in hell they could design a 'Web 2.0' style site. HTML5 is just a confusing bunch of characters ending with a number to them.
If Microsoft's change eliminates the short-bus admins, good. I can spend less time going in a fixing their crappy mistakes when companies realize their mistake and scream for help, and I can start working on 'fun' projects to help automate and reduce monotony for other employees.
20 years old today have no clue how to use a command line unless they are from the 1% of users that have a linux desktop at home.
And that 1% are probably more qualified to admin a Linux or Windows server than the remaining 99% who only know point-and-click. They probably also know a lot more about 'advanced' things like how TCP/IP works, they understand a lot of the protocols like POP3/SMTP/IMAP, HTTP, or even understand how to debug a program that's crashing, etc...
These are kids in physics, math, biochem, and they didn't know how to make a directory without a GUI. Admittedly, that's why we're teaching them the CLI stuff. But they won't use it.
I had an IT colleague a few years back trying to work with a CSV file that had some strange embedded UNICODE characters in it. Excel was having problems reading the data. After several hours of dorking around with Excel, Notepad, and a few other GUI tools the file was handed to me--I used tools that aren't available on Windows (hexdump, sed, csvtool) and stripped the characters out, transformed the file to their requirements, and handed it back to him in about 4 minutes. I spent another 15 minutes automating the process of grabbing this automated CSV dump from a Windows app, doing the stripping and conversion, and then e-mailing the results. He wasted *hours* because he--apparently like your students--didn't think the CLI was valuable and GUI tools would solve his problem.
This person now has something like 30 minutes free *every day* where he can work on stuff that will earn the company money instead of dorking around with Windows failures.
Re: (Score:3)
So the path to making better software is to make it more obfuscated and less user friendly? Making it easier for those poor dudes is what MS has been doing for 20 years, and why they finally made some inroads into the market.
No, the path to making better software is to make people understand the ramifications of their actions, and understand not to take those actions unless they understand the consequences, which Microsoft has, in my opinion, been horrible at.
Here's a great example: several times, I've been called in to undo the effects of Windows Load Balancing, a technology Microsoft created to do load balancing in the OS, rather than requiring a separate device. It works by tricking the switch into flooding all incoming pac
Re:Not a problem (Score:5, Interesting)
Having CLI only potentially means that someone could administer the server from abroad, so long as there is someone in the building who the admin can call to cycle the power and swap the backup tapes every so often. My buddy does this via linux for two 50+ person non profits in Seattle.... from his sailboat in Houston. The only reason he's not doing this for more groups is that the market is fairly saturated with guys like him already... working from the CLI.
Re: (Score:3)
The simple answer is that just like Unix servers and all other servers except MS you will configure it and monitor it on a workstation with a GUI, but never actually use the server directly ...
The server should not need a GUI, or a monitor, or a keyboard ... it should maybe need a little input when first setup to get it on the network then be totally configured from clients
I always wondered why Server versions of windows had a GUI (and so needed a graphics card...), a lot of Unix servers don't have one?
Re: (Score:3)
Right, but when a huge chunk of your market is going to be businesses with 15-20 employees and no dedicated IT person, or if they have a dedicated IT person they're not actually a trained IT person, having a CLI only is utterly braindead.
Might be it's time for 15-20 person companies that have a need to run a server to learn that having a skilled IT person is about as important as having a person who makes good business decisions. They don't call this the "information age" for nothing. Business today runs in
Re: (Score:3)
Re: (Score:3)
Not at all. I have been many times accused of being a linux fanboy, but the NT kernel does somethings very well. The tragedy is that it is strapped to the windows userland. DOS on the other hand is a very simple OS with no scheduler, no real HAL, and pretty much is a sad copy of CPM.