6 ms·

They started on this in the late 2000s when I was an intern there. But there was a lot to untangle. It’s the biggest refactoring job you can imagine. A decade l

They started on this in the late 2000s when I was an intern there. But there was a lot to untangle. It’s the biggest refactoring job you can imagine. A decade long effort. Back then they didn’t really understand the point of ssh though. They had a vision of remote management via .net RPC and powershell.

TimTheTinker 8y ago
> Back then they didn’t really understand the point of ssh though. As an outside observer, it really looked to me like Microsoft had their head in the clouds up until about 2011. It's like the whole decade between 2005-2015 for MS was about recognizing and coming to terms with the multiple "whole worlds out there" and getting past NIH syndrome.
- kwccoin 8y ago
  To be fair to Kodak, it is very hard to invent digital photography but fail greatly to use it. Or Xerox, ... or IBM who is the largest PC seller exactly the time when it was overwhelmed by Microsoft. An organisation large enough would have middle management and people who promote from within. And they are successful in one culture and it worked even for customers. Then ...
- slededit 8y ago
  They understood the GUI couldn’t be everything but NIH was definitely in full swing at that time. It was enforced from the top: If you wanted to use an external product and MSFT had a competitor you needed VP approval. Same went for Open Source. Only the most senior people would even attempt it, and it was understood they were spending political capital. The one place this didn’t apply was your choice of code editor. You could use whatever you wanted and that had long been tradition. I spent a lot of effort getting VIM to work only to realize it didn’t scale well to multi-million LOC code bases.
  - killjoywashere 8y ago
    As someone who uses Vim on relatively large files daily (500k - 1.5M lines), where were the hangups?
    - slededit 8y ago
      The speed of navigating the code base. Ctags existed but people using SlickEdit or Source Insight were able to navigate the code base dramatically faster. As a new hire I wasn't going to get code annotations emitted as part of the build, so an editor with a proper parser was key. Really had nothing to do with the size of the file.
donavanm 8y ago
I dont know if that means they didnt understand it. It reads like they were trying to solve the underlying problems with a different approach. SSH is an awesome tool & capability as a relatively high level network channel. The defacto “shell” approach leads to a lot of problems when used as a management device. It encourages adhoc, unstructured, and opaque changes. Managing your hosts via Secure Shell simply leads to bespoke, unrepeatable, outcomes and crushing debt. Moving to a well structered, repeatable, management paradigm is the only way to survive large or long term deployments. I see “systems configuration” and “orchestration” as the most common ways to achieve that. Personally Ive been trying to move linux/bsd host management off of SSH for 10 years now. I will be very very happy when SSH shell instantiations approach zero per day.
- slededit 8y ago
  They already had group policy for structured administration. What Windows was missing specifically was a non-GUI way for that unstructured "get in there and fix the problem" work flow. Structured workflows may well be better for you, but quick and dirty has a lot of appeal. Sometimes you just have to give people the candy they want - even if its not good for them.
  - mycall 8y ago
    > "get in there and fix the problem" work flow Isn't this an anti-pattern considering the cloud tenants of treating machines as cattle not pets?
    - deleted 8y ago
      [deleted]
    - slededit 8y ago
      Windows had this problem much earlier with every employee getting a PC on their desk. They solved it with Group Policy and domains. That still works well. SSH and Remote Desktop solve a different problem. It may not be the one you have - but some of us just need to log into the machine because we have needs that don’t fit into some predefined workflow. Or we have so few boxes it’s not worth it. Consider SSHing into a large build machine for compiling as an example.
pmontra 8y ago
The point of ssh is that I can easily manage some Windows boxes from a Linux server. A customer of mine fires up servers to run tasks on them. A few of those tasks are programs that unfortunately run only on Windows (the pain of updating those boxes!) I install ssh to be able to perform some basic operations on them and move files over sftp. Hopefully an integrated ssh server works better (issues with terminal, etc.) I understand that this is not a scenario Microsoft would advocate in the past, but eventually Microsoft lost the war for servers so it's giving us interoperability tools now.
jodrellblank 8y ago
This makes you seem like you don't understand the point of PowerShell remoting. Passing serialised scriptblocks to the remote host, executing them, and getting serialized objects back. Meaning you can pass serialisable objects around, handle errors, the multiple output streams, etc. over the remoting connection. Because it's integrated into the language, you can pull PowerShell modules over from the remote host to the local host automatically generating proxy stubs for them ("implicit remoting"). E.g. to manage and Exchange server you can remote to it, and bring the Exchange cmdlets back, and then import them locally as if they were a local module. It's also able to do that and edit the proxies as it builds them for you, to allow and restrict what commands you get - based on your permissions and perhaps which tier of service you're paying for. And not just allow or restrict commands, but allow or restrict individual parameters on those commands, if desired.
- tremon 8y ago
  you can pass serialisable objects around, handle errors, the multiple output streams, etc. over the remoting connection. That's fine in theory, except that some very common Windows Objects can't be serialized in any meaningful way (most painful one for me being the Windows Update Client), which means that certain "remote" operations are actually affecting the client machine, or are failing because the client lacks support for certain operations. I've been using Powershell since v2, but to me, it's essentially a walled garden automation environment. Just one more way for Microsoft not to give you the tools to efficiently manage your fleet.
  - jodrellblank 8y ago
    How is that different from SSH? You can't serialise open sockets and pull them back over an SSH connection either. a) I think the normal use is something like SCCM or InTune to automate Windows Updates, not manually connecting to a machine and trying to script the Windows Update Client. b) Microsoft built Azure Stack with PowerShell automation. Are you saying Microsoft refused to give themselves the tools to efficiently manage their own fleet? What tools even are these?
- slededit 8y ago
pjc50 8y ago
If I had to define one underlying architectural difference between UNIX and Windows, it's that Windows uses RPC (and some other kinds of structured communication) where UNIX uses pipes. This has advantages if you're Microsoft and developing both ends, but in most other cases it's a huge disadvantage to discoverability and transparency. This is partly why nobody developed proper open source Exchange clients: the Exchange protocol is MAPI over DCE/RPC, and you need to build a lot of infrastructure before it will even talk to you.
- amaccuish 8y ago
  OpenChange tried to build an exchange server, and it worked to a certain extent, but it's now dead I believe. Keeping up with the recent protocol changes in Exchange was too much, though ironically with the REST and MAPI over HTTP (not RPC over HTTP), it should be a lot easier to create an exchange replacement. Samba still does amazing stuff on the directory RPC front.

TimTheTinker 8y ago

> Back then they didn’t really understand the point of ssh though. As an outside observer, it really looked to me like Microsoft had their head in the clouds up until about 2011. It's like the whole decade between 2005-2015 for MS was about recognizing and coming to terms with the multiple "whole worlds out there" and getting past NIH syndrome.

kwccoin 8y ago
To be fair to Kodak, it is very hard to invent digital photography but fail greatly to use it. Or Xerox, ... or IBM who is the largest PC seller exactly the time when it was overwhelmed by Microsoft. An organisation large enough would have middle management and people who promote from within. And they are successful in one culture and it worked even for customers. Then ...
slededit 8y ago
They understood the GUI couldn’t be everything but NIH was definitely in full swing at that time. It was enforced from the top: If you wanted to use an external product and MSFT had a competitor you needed VP approval. Same went for Open Source. Only the most senior people would even attempt it, and it was understood they were spending political capital. The one place this didn’t apply was your choice of code editor. You could use whatever you wanted and that had long been tradition. I spent a lot of effort getting VIM to work only to realize it didn’t scale well to multi-million LOC code bases.
- killjoywashere 8y ago
  As someone who uses Vim on relatively large files daily (500k - 1.5M lines), where were the hangups?
  - slededit 8y ago
    The speed of navigating the code base. Ctags existed but people using SlickEdit or Source Insight were able to navigate the code base dramatically faster. As a new hire I wasn't going to get code annotations emitted as part of the build, so an editor with a proper parser was key. Really had nothing to do with the size of the file.

donavanm 8y ago

I dont know if that means they didnt understand it. It reads like they were trying to solve the underlying problems with a different approach. SSH is an awesome tool & capability as a relatively high level network channel. The defacto “shell” approach leads to a lot of problems when used as a management device. It encourages adhoc, unstructured, and opaque changes. Managing your hosts via Secure Shell simply leads to bespoke, unrepeatable, outcomes and crushing debt. Moving to a well structered, repeatable, management paradigm is the only way to survive large or long term deployments. I see “systems configuration” and “orchestration” as the most common ways to achieve that. Personally Ive been trying to move linux/bsd host management off of SSH for 10 years now. I will be very very happy when SSH shell instantiations approach zero per day.

slededit 8y ago
They already had group policy for structured administration. What Windows was missing specifically was a non-GUI way for that unstructured "get in there and fix the problem" work flow. Structured workflows may well be better for you, but quick and dirty has a lot of appeal. Sometimes you just have to give people the candy they want - even if its not good for them.
- mycall 8y ago
  > "get in there and fix the problem" work flow Isn't this an anti-pattern considering the cloud tenants of treating machines as cattle not pets?
  - deleted 8y ago
    [deleted]
  - slededit 8y ago
    Windows had this problem much earlier with every employee getting a PC on their desk. They solved it with Group Policy and domains. That still works well. SSH and Remote Desktop solve a different problem. It may not be the one you have - but some of us just need to log into the machine because we have needs that don’t fit into some predefined workflow. Or we have so few boxes it’s not worth it. Consider SSHing into a large build machine for compiling as an example.

pmontra 8y ago

The point of ssh is that I can easily manage some Windows boxes from a Linux server. A customer of mine fires up servers to run tasks on them. A few of those tasks are programs that unfortunately run only on Windows (the pain of updating those boxes!) I install ssh to be able to perform some basic operations on them and move files over sftp. Hopefully an integrated ssh server works better (issues with terminal, etc.) I understand that this is not a scenario Microsoft would advocate in the past, but eventually Microsoft lost the war for servers so it's giving us interoperability tools now.

jodrellblank 8y ago

This makes you seem like you don't understand the point of PowerShell remoting. Passing serialised scriptblocks to the remote host, executing them, and getting serialized objects back. Meaning you can pass serialisable objects around, handle errors, the multiple output streams, etc. over the remoting connection. Because it's integrated into the language, you can pull PowerShell modules over from the remote host to the local host automatically generating proxy stubs for them ("implicit remoting"). E.g. to manage and Exchange server you can remote to it, and bring the Exchange cmdlets back, and then import them locally as if they were a local module. It's also able to do that and edit the proxies as it builds them for you, to allow and restrict what commands you get - based on your permissions and perhaps which tier of service you're paying for. And not just allow or restrict commands, but allow or restrict individual parameters on those commands, if desired.

tremon 8y ago
you can pass serialisable objects around, handle errors, the multiple output streams, etc. over the remoting connection. That's fine in theory, except that some very common Windows Objects can't be serialized in any meaningful way (most painful one for me being the Windows Update Client), which means that certain "remote" operations are actually affecting the client machine, or are failing because the client lacks support for certain operations. I've been using Powershell since v2, but to me, it's essentially a walled garden automation environment. Just one more way for Microsoft not to give you the tools to efficiently manage your fleet.
- jodrellblank 8y ago
  How is that different from SSH? You can't serialise open sockets and pull them back over an SSH connection either. a) I think the normal use is something like SCCM or InTune to automate Windows Updates, not manually connecting to a machine and trying to script the Windows Update Client. b) Microsoft built Azure Stack with PowerShell automation. Are you saying Microsoft refused to give themselves the tools to efficiently manage their own fleet? What tools even are these?
slededit 8y ago

pjc50 8y ago

If I had to define one underlying architectural difference between UNIX and Windows, it's that Windows uses RPC (and some other kinds of structured communication) where UNIX uses pipes. This has advantages if you're Microsoft and developing both ends, but in most other cases it's a huge disadvantage to discoverability and transparency. This is partly why nobody developed proper open source Exchange clients: the Exchange protocol is MAPI over DCE/RPC, and you need to build a lot of infrastructure before it will even talk to you.

amaccuish 8y ago
OpenChange tried to build an exchange server, and it worked to a certain extent, but it's now dead I believe. Keeping up with the recent protocol changes in Exchange was too much, though ironically with the REST and MAPI over HTTP (not RPC over HTTP), it should be a lot easier to create an exchange replacement. Samba still does amazing stuff on the directory RPC front.