Even assuming all those accusations are true (which I strongly suspect some are false), my "nobility" comment is more a function of a specific noble purpose and mission than it is a measure of individual perfection. We can imitate Dr. King's work for a good cause, while recognizing and eschewing his flaws, which include that his doctorate probably would have been revoked under a truly fair and color-blind evaluation by Boston University (i.e. I agree with your point #1).
To reframe the issue a bit, we don't write off most of the founding fathers of the USA as immoral scoundrels because they owned slaves; rather, we are thankful for their positive contributions and honor them for the good things that came out of their lifes' work.
...a heck of a lot more of a contribution to society than his greed-fixated offspring. But this is America; we are supposed to know that the best kind of nobility doesn't always run in families.
Maybe you read through this thread further than I did; I didn't see anything about a stats pane. But I'm happy to report that your generalization is still technically false. The fact that a stats pane could be implemented in a non-GUI fashion doesn't mean that a company has the resources to re-write their software. If they don't have the resources to rewrite it, and they need those stats, then maybe they still have a need for a GUI capability on their server. Is it elegant? No. Do we wish they would re-write it? Sure. But you're still wrong.:p
You made a claim that a GUI is superior to a CLI in terms of performance on low speed connections. Furthermore the OP made the claim that a CLI is utterly unable to rival the GUI in this area.
That is false; I never said that. And the OP was talking about a legitimate corner case, not generalizing that a GUI is always better. We are talking about a situation where you need to run a specific GUI app that requires high bandwidth, for which you don't have a CLI alternative. Maybe you don't have that need. Neither do I right at this moment. But I have in the past, and I know people who do, and I may again in the future, because I work on a wide variety of software projects.
Plausible real world example: A small company needs to operate on a bunch of files on their server, running some operation on them, and then uploading them somewhere. The best method they have for the "running some operation" part is a GUI app for which they have neither the source code nor the ability to rewrite it. So this setup might be effective for them -- a server with GUI capability. If their server didn't have GUI capability, they would be constrained by their local bandwidth limitations and unable to take advantage of the server's better connection for the network part of it.
So it may or may not "require" a GUI in an absolute sense. But in the real world governed by budgets and limited availability of things we need, yes, a company may "require" a GUI in that sense.
Translation: "Even though I don't know anything about the GUI applications the OP is talking about that he needs, I can assure everybody that CLI/MMC equivalents exist, which fact I just now retrieved from my posterior. And also, instead of having a Windows Server that needs a GUI actually, you know, provide a native GUI, I think we should add a heavy layer of virtualization that will slow the poor server down even more."
Actually, though snark-ily put, that's exactly what needs to happen. Except it's MS that's pushing it.
I am a professional software engineer, and I call, uh... masculine bovine defecatory by-product. As mentioned in my admittedly snarky response, many organizations don't have the source code, budget, or skill to rewrite their GUI software, even assuming such software lent even itself to MMC or pure CLI operation. You're making an otherwise fine and good point that I would agree with in other contexts, but this is the specific topic being discussed, and so in this instance you are wrong. The OP said "it would be good to have optional GUI" -- which Microsoft agrees with, according to the article.
From a business (Microsoft shareholder) standpoint, you make a good point about the risk of losing corporate users by standardizing on a new (albeit optional) configuration that would break compatibility for them. On the other hand I think this is part of Microsoft's forward-thinking strategy of staking a claim to cloud computing, and competing less lamely against Linux. Will they be successful? I have no idea. But I think Microsoft is doing things like this out of a fear that the momentum of their existing customers is not sufficient to keep them successful forever.
Sorry that you misunderstood this, but it's not merely moving stuff around. The conversation is about a not-easily-replaceable GUI application that has bandwidth needs. For example, maybe it does stuff to the files before moving them around. If these situations exist (and they do), then there is a legitimate use case for GUI-capable Windows "servers".
You know, you're absolutely right. Why don't you just march right over to the management at that OP's company, and demand that they rewrite their GUI based, bandwidth-hungry apps in CLI form, especially since we know they are guaranteed to have all the source code, budget, and skill for such a task. I'm sure they will see your logic and immediately comply. Congrats on being the smartest person here and immediately seeing a simple answer to problems that have stumped all of these lesser mortals. lol
Remote use of MMC is a great and wonderful thing. But that's not what the original post was talking about. It was talking about the use of other apps (e.g. legacy, proprietary), for which neither CLI nor MMC interfaces exist.
the admin wants to do something like upload database files somewhere, or move media around, or something related to his organization's operations
Additional clarification -- in the specific context of the discussion, he was talking about use of a GUI application that does something like the above, for which there is no command line / text equivalent. Hope that helps.
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.
While I would hope that Blackwater has changed its operational standards and ethics after all its negative publicity, I am not holding my breath. However, in the case of Windows Phone, I have personally experienced the difference -- the part that matters is a total rewrite, and it provides a fantastic development framework. I develop professionally for Android and iOS too, so I have a pretty reasonable frame of reference to evaluate this.
Er... this feels like too much information, but I actually do personally have a beard, and don't shave my neck, though it's all reasonably trim otherwise. In using that phrase I simultaneously quoted the parent post, and also narrowed it into a non-subtle reference to RMS (who admittedly has me beat in the scraggliness of beard department) pretty much so I could take a "GNU/Linux" swipe.
I am a Windows Phone developer and something of a fan, but I would bet money that you are not -- you are just a troll. Hint: It's "Windows Phone". And while we're at it, let's throw a bone to the "unshaven scraggly neckbeards" and add that it's "GNU/Linux" (I wouldn't ordinarily, but I'm having fun smacking you down). And to be fair, Android isn't trash, especially when compared to the (old) Windows Mobile, which had all the sex appeal of Windows 3.1 to bring to your 21st century mobile device. I develop for Windows Phone because it's fun and similar to the technologies I use in my day job, and I like to create things for consumers, but I carry an Android phone because I can do anything I want with it in terms of homebrew and my own geekish forms of enjoyment.
Then, there's what appears to be the blatantly incorrect statement of 64-bit windows offering 4GB of address space - shouldn't that be way bigger, or am I stupid?
The 64 bit architecture does indeed offer 4 GB. Of course, it also offers 8 GB, 16 GB, etc. The article was focused on the 4 GB number because of FF, so it phrased a legitimate fact in a confusing way.
Maybe you were unaware that "the previous guy" disagreed on this point, and took a very careful view of complying with the "War Powers Resolution". In other words, unlike Obama, Dubya got congressional approval for his war(s). Whatever vague point you were trying to make, your post is factually misleading.
Slashdot Mirror
Even assuming all those accusations are true (which I strongly suspect some are false), my "nobility" comment is more a function of a specific noble purpose and mission than it is a measure of individual perfection. We can imitate Dr. King's work for a good cause, while recognizing and eschewing his flaws, which include that his doctorate probably would have been revoked under a truly fair and color-blind evaluation by Boston University (i.e. I agree with your point #1).
To reframe the issue a bit, we don't write off most of the founding fathers of the USA as immoral scoundrels because they owned slaves; rather, we are thankful for their positive contributions and honor them for the good things that came out of their lifes' work.
...a heck of a lot more of a contribution to society than his greed-fixated offspring. But this is America; we are supposed to know that the best kind of nobility doesn't always run in families.
Maybe you read through this thread further than I did; I didn't see anything about a stats pane. But I'm happy to report that your generalization is still technically false. The fact that a stats pane could be implemented in a non-GUI fashion doesn't mean that a company has the resources to re-write their software. If they don't have the resources to rewrite it, and they need those stats, then maybe they still have a need for a GUI capability on their server. Is it elegant? No. Do we wish they would re-write it? Sure. But you're still wrong. :p
You made a claim that a GUI is superior to a CLI in terms of performance on low speed connections. Furthermore the OP made the claim that a CLI is utterly unable to rival the GUI in this area.
That is false; I never said that. And the OP was talking about a legitimate corner case, not generalizing that a GUI is always better. We are talking about a situation where you need to run a specific GUI app that requires high bandwidth, for which you don't have a CLI alternative. Maybe you don't have that need. Neither do I right at this moment. But I have in the past, and I know people who do, and I may again in the future, because I work on a wide variety of software projects.
Plausible real world example: A small company needs to operate on a bunch of files on their server, running some operation on them, and then uploading them somewhere. The best method they have for the "running some operation" part is a GUI app for which they have neither the source code nor the ability to rewrite it. So this setup might be effective for them -- a server with GUI capability. If their server didn't have GUI capability, they would be constrained by their local bandwidth limitations and unable to take advantage of the server's better connection for the network part of it.
So it may or may not "require" a GUI in an absolute sense. But in the real world governed by budgets and limited availability of things we need, yes, a company may "require" a GUI in that sense.
Capisce?
I'll elaborate. Your ID is WAY to high to be talking about Windows in here.
Let's file that away for a bit.
Now again, you make even more comments during your elaboration that make no sense whatsoever.
Aha. So just above this you made a "comment" during your "elaboration" that "makes no sense whatsoever". Are you talking to yourself again?
Translation: "Even though I don't know anything about the GUI applications the OP is talking about that he needs, I can assure everybody that CLI/MMC equivalents exist, which fact I just now retrieved from my posterior. And also, instead of having a Windows Server that needs a GUI actually, you know, provide a native GUI, I think we should add a heavy layer of virtualization that will slow the poor server down even more."
:/
Really?
Actually, though snark-ily put, that's exactly what needs to happen. Except it's MS that's pushing it.
I am a professional software engineer, and I call, uh... masculine bovine defecatory by-product. As mentioned in my admittedly snarky response, many organizations don't have the source code, budget, or skill to rewrite their GUI software, even assuming such software lent even itself to MMC or pure CLI operation. You're making an otherwise fine and good point that I would agree with in other contexts, but this is the specific topic being discussed, and so in this instance you are wrong. The OP said "it would be good to have optional GUI" -- which Microsoft agrees with, according to the article.
From a business (Microsoft shareholder) standpoint, you make a good point about the risk of losing corporate users by standardizing on a new (albeit optional) configuration that would break compatibility for them. On the other hand I think this is part of Microsoft's forward-thinking strategy of staking a claim to cloud computing, and competing less lamely against Linux. Will they be successful? I have no idea. But I think Microsoft is doing things like this out of a fear that the momentum of their existing customers is not sufficient to keep them successful forever.
Sorry that you misunderstood this, but it's not merely moving stuff around. The conversation is about a not-easily-replaceable GUI application that has bandwidth needs. For example, maybe it does stuff to the files before moving them around. If these situations exist (and they do), then there is a legitimate use case for GUI-capable Windows "servers".
You know, you're absolutely right. Why don't you just march right over to the management at that OP's company, and demand that they rewrite their GUI based, bandwidth-hungry apps in CLI form, especially since we know they are guaranteed to have all the source code, budget, and skill for such a task. I'm sure they will see your logic and immediately comply. Congrats on being the smartest person here and immediately seeing a simple answer to problems that have stumped all of these lesser mortals. lol
Remote use of MMC is a great and wonderful thing. But that's not what the original post was talking about. It was talking about the use of other apps (e.g. legacy, proprietary), for which neither CLI nor MMC interfaces exist.
the admin wants to do something like upload database files somewhere, or move media around, or something related to his organization's operations
Additional clarification -- in the specific context of the discussion, he was talking about use of a GUI application that does something like the above, for which there is no command line / text equivalent. Hope that helps.
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.
While I would hope that Blackwater has changed its operational standards and ethics after all its negative publicity, I am not holding my breath. However, in the case of Windows Phone, I have personally experienced the difference -- the part that matters is a total rewrite, and it provides a fantastic development framework. I develop professionally for Android and iOS too, so I have a pretty reasonable frame of reference to evaluate this.
Er... this feels like too much information, but I actually do personally have a beard, and don't shave my neck, though it's all reasonably trim otherwise. In using that phrase I simultaneously quoted the parent post, and also narrowed it into a non-subtle reference to RMS (who admittedly has me beat in the scraggliness of beard department) pretty much so I could take a "GNU/Linux" swipe.
:D
So chill, dude.
Bravo to you for being a good sport in response to my post, which was largely a joke.
Yeah, and it's soon going to be "Windows Phone 8", so smart copy writers refer to it as "Windows Phone". Should be good for a few years, anyway. :D
sloppy and imprecise thinking and communication is just as much of a danger
You should have written "are" instead of "is".
I am a Windows Phone developer and something of a fan, but I would bet money that you are not -- you are just a troll. Hint: It's "Windows Phone". And while we're at it, let's throw a bone to the "unshaven scraggly neckbeards" and add that it's "GNU/Linux" (I wouldn't ordinarily, but I'm having fun smacking you down). And to be fair, Android isn't trash, especially when compared to the (old) Windows Mobile, which had all the sex appeal of Windows 3.1 to bring to your 21st century mobile device. I develop for Windows Phone because it's fun and similar to the technologies I use in my day job, and I like to create things for consumers, but I carry an Android phone because I can do anything I want with it in terms of homebrew and my own geekish forms of enjoyment.
This should also be want Slashdot wants.
I like diversity in Slashdot opinions. If all Slashdot readers were Apple fanboys like you, it would be boring around here.
Isn't competition what drives innovation? Where's the innovation if everyone just does what everyone else is doing?
It's ironic that you chose the word "competition" to describe forcing people out of a space via an effective monopoly.
I know Visual Studio provides a native x64 compiler. Are you sure there's not an x64 linker? I don't have immediate access to a machine to check this.
Then, there's what appears to be the blatantly incorrect statement of 64-bit windows offering 4GB of address space - shouldn't that be way bigger, or am I stupid?
The 64 bit architecture does indeed offer 4 GB. Of course, it also offers 8 GB, 16 GB, etc. The article was focused on the 4 GB number because of FF, so it phrased a legitimate fact in a confusing way.
Whether "declared" or not, it was surely "waged" by both. And as such, Congressional approval has to be obtained.
Maybe you were unaware that "the previous guy" disagreed on this point, and took a very careful view of complying with the "War Powers Resolution". In other words, unlike Obama, Dubya got congressional approval for his war(s). Whatever vague point you were trying to make, your post is factually misleading.