Slashdot Mirror
Windows 10 Gets Core Console Host Enhancements (nivot.org)
x0n writes: As of Windows 10 TH2 (10.0.1058), the core console subsystem has support for a large number of ANSI and VT100 escape sequences. This is likely to prepare for full Open SSH server/client integration, which is already underway over on github. It looks like xterm is finally coming to Windows. OpenSSH was previously announced (last year) by the very forward-looking PowerShell team. The linked article provides some context, and explains that the console host isn't the same as either cmd.exe or powershell.exe, but there is a lot of overlap in functionality.
This is.
Remote shells? Yes! But SECURE, Remote shells? They have never had that built-in.
Powershell's remote shell is secure, and that is built-in to Windows.
Exchange Server is one of the killer points, yes. The other one is Domain Login with the attendant domain-wide security model. As a *nix booster, I must say those two continue to absolutely show up *nix to this day. Those two give more than enough of a "point".
Both Mac OS X and RedHat Linux have answers to both domain login and domain-wide security. The Linux implementation is somewhat less robust (i.e. it's possible to escape exclusion groups, and there's no external group membership resolver like there is on Mac OS X, so there's still the 16 group limit), but it at least is a proof by existence that the claim is wrong. And you can always install the Samba implementation manually on any Linux or BSD box.
If you want to get technical, had Windows not added the proprietary field, we're just talking a KDC implementation, as in Heimdal Kerberos, or before that, MIT Kerberos, and that's been around since Project Athena, which means early 1980's, which means over 30 years. Microsoft's implementation was 1995 or so, and it was the late 90's before they made it non-interoperable with the proprietary field, so they are predated by at least a decade.
Kerberos was interesting, in that it abused the setgroups() and cr->ngroups to store the Kerberos key in the last two groups field, but at that point you were not really using groups anyway (since you were using remote Andrew FS or similar, and it was doing server side credentials enforcement).
So TL;DR: they absolutely did not, and do not, "show up *nix".
Full integration with Active Directory, for fine-grained permissions over all aspects of the mail/calendar system.
For example, with Exchange and AD, I can create a distribution group, and delegate "ownership" of that group to a specific user, so they can add/remove users to that group. I can set that group to "open" or "closed", meaning users can either join it/leave it without owner approval, or not.
I can give an arbitrary user access to another users entire mailbox, or give them only permission to "send as" a different user, or distribution group.
I can allow only certain users to send to specific addresses, meaning I can have a "My Entire Company" distribution group that only specific people can send mail to.
And then there are similar permissions/delegation options for calendars, and Public Folders, and even Skype for Business. If you have VoIP phone systems, and compatible phones, you can even access all of your mail/calendar/Skype messages from your phone.
I can set deletion and archive polices for each user, or a group of users. I can set mailbox size limits per user, or per group. I can create a "discovery search", meaning I can allow access to a user's mailbox, but only for mails that meet a specific search criterion.
And of course, there is a cottage industry of add-ons for Exchange to do a million other things. Mimecast, for example, allows automatic off-site archiving of all email (with an Outlook plugin to search the mail), and automatic failover to Mimecast's servers if Exchange goes offline.
It's just endless. Exchange has no real competition. Is it perfect? No. But it's better than anything else for corporate messaging, by a wide margin.
So essentially it took until 2009 for Microsoft to even begin to admit that RPC, a few rather crappy scripting host options and RDP were inadequate, but it took them over six more years to finally implement what is pretty much the gold standard of encrypted TTY interfaces.
No, they have never stated that their previous technology was inadequate. They are just providing yet another option to their existing solutions. That you think that SSH is the one-and-only answer shows your biases rather than demonstrates any admissions of inadequacy by Microsoft.
Maybe this is part of the turning over a new leaf, but I can't help but imagine that the next version of Microsoft's coursework will announce how innovative all of this...
There is no way that they will attempt to claim that they invented SSH. Apart from being so easy to disprove (and thus ridicule), it would also go against the current Microsoft policy of working with standards.
...much as it went around declaring how innovative Powershell was, when all it really is is an overly complicated descendant of Bash, inelegant, overly verbose and unnecessarily convoluted.
Once again you have let your hatred and obvious lack of knowledge get the better of you. The basis of Powershell is that it treats everything as an object and is integrated with .NET so that it has access to virtually the same class structures that low level languages have. How it that being a descendant of bash? As you say, it has a verbose naming scheme for its commands and functions. How is that being a descendant of bash? Sure it has aliases to allow common *nix commands, but it also has them to allow CMD.EXE commands too. They are simply there to provide convenient shortcuts. Apart from those helpful aides, everything about Powershell is all its own.
I just hope all the Redmondites see the irony of MS sitting around for two decades declaring NT's superiority because, you know, Windows and all, and now essentially reinventing, badly in many cases, what the Unix ecosystem has had for decades.
For someone who thought that the only remote access that Windows had was telnet and that Powershell was a copy of something that it is almost completely unlike, I think that you need some more education before you can lecture anyone about the shortcomings of Windows.
They haven't. When I first tried to use PowerShell it frustrated me so much I wrote an entire article about it. Calling PowerShell a shell is a huge stretch: it's really just a strange and verbose scripting language.
The basic toolset; cat, sh, mv, rm, and so forth are mnemonics.
Funny you used those examples. Three out of the four of those work out of the box in PowerShell because MS included them as aliases. You can be as sleek and incomprehensible as you would like in PS. Nobody is stopping you.
For me Powershell's absurdly verbose naming scheme is as good a sign as any that Microsoft has never really understood CLI work.
Again... see comment re: aliases. New-Alias [alias] [cmdlet].
Having both the long name when you are trying to discover commands and shorter aliases for day to day work is convenient. I use PowerShell day in and day out at work, and there are lots of problems with it. The uniform naming convention is a strength, not handicap.
The Daddy casts sleep on the Baby. The Baby resists!
Have more in depth permission schemes in Zimbra actually.
Can do that in Zimbra.
Can do that in Zimbra, the sharing function are actually a much nicer set of ACL options than what Exchange/Outlook provides.
Can do that in Zimbra.
You can do this in Zimbra, however for the VoIP stuff, you'll need a 3rd party addon (it exists, because I use it). As for the Skype for Business/Lync, I don't really know, but Zimbra has a built in instant messaging solution that works too.
Can do that in Zimbra.
Plenty for Zimbra too.
Where Zimbra can't beat Exchange on is complete perfect integration with Outlook. It does however beat Exchange and Outlook on their offered functionality.
Change is certain; progress is not obligatory.