Windows 10 Gets Core Console Host Enhancements (nivot.org) 249
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.
News for Nerds (Score:5, Insightful)
Is it just me, or is this actually news for nerds?
Stuff that matters (Score:3, Informative)
Re: (Score:2, Interesting)
nerds have already cygwin, msys or something like that. nerds needed this functionality so long that they actualy resigned reminding m$ that terminal is a not a dirty word.
to paraphrase: a good console is like a good dog - very rare. a good console with a good language is like a dog speaking norwegian,sir - even rarer. i am mentioning this because in windows 10 they actually got cmd.exe so much better, but the underlying bat language feels like yesterday's vomit. i guess, that's where powershell comes in, b
Re: (Score:2)
How dare you insult hungarians. We are a proud people!
And full of eels, just like our hovercraft!
So Let Me Get This Straight (Score:5, Funny)
So let me get this straight. Windows is getting the kind of terminal support *nix has had for nearly 50 years? Wow, I mean, how fucking innovative of MS.
Fuck fuck fuck.
Re: So Let Me Get This Straight (Score:4, Insightful)
Re:So Let Me Get This Straight (Score:5, Interesting)
This is actually a pretty big deal. Stolen from this post by a ReactOS developer [somethingawful.com]:
why is command prompt so, command prompty i guess
it all goes back to a terrible, terrible architectural choice they made way back in Windows NT 3.1
Win32 consoles are implemented in user mode. god knows why simple, safe consoles are a user mode thing, while a ton of badly written GUI poo poo was violently forced down kernel mode's throat, but they probably hoped that text consoles were going to be a fad? nevermind. this alone wouldn't be an issue, in fact if anything it would make providing multiple implementations of console windows very easy, but they had to double down on the awful, and make console windows run in the user-mode part of the win32 subsystem (basesrv.dll), which runs in a hyper-privileged process, csrss.exe. how privileged?
* the system is immediately shut down with a fatal hard error if it terminates. regular hard errors (like "put the floppy back in, idiot", "executable imports non-existing function from dll", etc.) are passed from kernel mode back to csrss.exe, which turns them into message boxes (when you use MessageBox with the MB_SERVICE_NOTIFICATION flag, you are actually raising a STATUS_SERVICE_NOTIFICATION hard error); they are even interactive (you surely remember the infamous abort/retry/ignore), as in the thread that raised them is blocked waiting for your answer. the caller can even be a kernel mode driver (see IoRaiseHardError). fatal hard errors (passing OptionShutdownSystem to NtRaiseHardError/ExRaiseHardError) on the other hand can't be sent to anyone and result in an immediate shutdown (pretty fast because only drivers are notified, user mode processes are just killed) followed by a bugcheck. so technically it's wrong to say that terminating csrss.exe causes a BSOD because a BSOD is instant, while when you kill csrss.exe you can e.g. hear the disks flushing. little known fact: before Windows XP, crashing on termination of a critical process wasn't a kernel feature; instead, the startup process (smss.exe) would wait for the termination of csrss.exe and winlogon.exe, and hit you with a hard error if it ever returned from the wait. you'll notice a flaw: nobody watches the watcher (kernel don't gaf). you could totally kill smss.exe and then csrss.exe without a BSOD. back then, the debugging APIs were implemented in user mode for some loving reason, and for an even more inexplicable reason they were a RPC API and smss.exe was the server end, so killing smss.exe would have no visible effect, except breaking debugging until a reboot
* it has direct access to the real-mode address space (lowest 1 MB of physical address space), in fact it's mapped at virtual address 0 and everything. csrss.exe doesn't actually use this, it's a hack for calling the VGA BIOS from video drivers. the driver framework attaches to csrss.exe to get its address space (virtual address 0 is in the user mode range, and kernel processes like System have no user mode virtual memory range, so you need to attach to a user mode process for that) and then I have no idea what happens because I've never done VGA. there's a special flag to RtlCreateUserProcess (low level no-Win32 equivalent of CreateProcess, used to start winlogon.exe, csrss.exe, etc. you can tell a process has been launched by RtlCreateUserProcess instead of CreateProcess because its command line will include the full object namespace path, e.g. \??\C:\WINDOWS\System32\winlogon.exe), RTL_USER_PROCESS_PARAMETERS_RESERVE_1MB, whose entire purpose is to reserve the lowest 1 MB of virtual address space in the target process so that stacks, heaps, environment, etc. will be allocated somewhere else and win32k.sys can map the real-mode address space there (how do you allocate memory at address 0? just pass (PVOID)1 as the desired address to VirtualAlloc/NtAllocateVirtualMemo
Re: (Score:2)
Holy hell, someone mod parent up, please.
Re: (Score:3)
Tons of interesting stuff in that link, totally off topic, but details about rewriting win32 kernel with full unicode support as a realtime OS for Windows CE:
Re: (Score:3)
So let me get this straight. Windows is getting the kind of terminal support *nix has had for nearly 50 years?
No, Windows has had the kind of terminal support for years, it is just been their own implementations. The difference now is that they are now using the same particular protocol as the *nix world. In other words, they are going from the kind of terminal support to the exact terminal support.
Re: (Score:3)
Windows had a Telnet server, to be sure. But you had to be pretty damned careful as to which commands you used. We did play around with Cygwin's bash script running in a TTY on Windows 2000, but it was clunky and slow (like everything in Cygwin was, and maybe still is, I dropped it years ago). In the end it just wasn't a very good CLI-based management platform because 1. there was no good native pure CLI-based toolset to administer a system, 2. no good TTY based text editor, and 3. it was bloody Telnet, and
Re: (Score:3)
The Telnet server required an Expect script to use... and yes, you -can- do stuff that way... but it is a relative PITA compared to ssh, Python libraries, and Ansible. As the parent said, sending unencrypted passwords through a link (yes, one -could- do tunnels, but that is another bunch of hoops) was possible... but with SSH (especially with RSA authentication), it is far, far easier.
Re: (Score:2)
You are right that Telnet is not much use and very insecure, but it was not the only option for remote access.
Windows has also had Terminal Services (later Remote Desktop Protocol) since Windows NT 4.0, although it required a special server version. Windows 2000 Server had it in standard configuration, and Windows XP had it by default in workstation versions (except for the Home edition). XP also had the WSHContoller object for running Windows Scripting Host scripts remotely, but that was not much use for a
Re: (Score:2)
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.
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, much as it went around declaring how innovative Powershell was, when
Re:So Let Me Get This Straight (Score:4, Informative)
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.
Re: (Score:2)
I was referring to TTY access. Your misrepresenting what I said.
Re: (Score:2)
I'm sure that MightyMartian feels only heartfelt pity and compassion for the kids on the short bus.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
Well, I think they've decided to finally be useful to developers.
Re:So Let Me Get This Straight (Score:5, Insightful)
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".
Re:So Let Me Get This Straight (Score:5, Informative)
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".
Re: (Score:2)
And you can always install the Samba implementation manually on any Linux or BSD box.
Don't some Linux distros install Samba support automatically? I seem to recall that mine (openSUSE) does, at least.
Re:So Let Me Get This Straight (Score:4, Interesting)
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
_just_ ? Try setting setting up IPA sometime. That's just LDAP and Kerberos too. Have fun...
LDAP is really easy. Well, it is for me:
From the OpenLDAP commit logs:
===
1.1.4.1 Sat Aug 8 23:05:28 1998 UTC; 17 years, 6 months ago by kurt
CVS Tags: FreeBSD_3_3; Branch: FreeBSD
Changed since 1.1: +0 -0 lines
Diffs to 1.1 (colored diff)
Import of FreeBSD LDAP 3.3 Port
---
1.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt
Initial revision
---
1.1.3.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt
CVS Tags: LDAP_3_3+prerelease, UMICH_LDAP_3_3, BOOLEAN_LDAP, LDAP_POSTE, LDAPworld; Branch: UMICH ; Branch point for: RAGE
Changed since 1.1: +0 -0 lines
Diffs to 1.1 (colored diff)
Import of Umich LDAP 3.3
===
See that 1.1.4.1? Those are my patches to get OpenLDAP working from UMich LDAP sources. It added about 40 platforms. OpenLDAP started with the UMich LDAP, added my patches, and then went on from there. Originals of the (120K of) patches are HERE:
http://www.freebsd.org/~terry/... [freebsd.org]
Just because something is hard for you, doesn't make it hard for the rest of us. Some of us have been doing this for nearly two decades.
Re: (Score:2)
Exchange Server is one of the killer points, yes.
What's so great about Exchange Server that other messaging systems don't have? Because from the client side, it doesn't seem all that special to me.......
Re:So Let Me Get This Straight (Score:5, Informative)
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.
Re: (Score:2)
Which Sendmail could do with simple entries in the alias file long before MS Exchange even existed. It's about the only simple thing about Sendmail, but such things were core functions in other MTAs years ago.
Comment removed (Score:4, Informative)
Re: So Let Me Get This Straight (Score:3)
I don't get it either... Outlook is a pile of shit, Exchange may "work" but it certainly is also a pile of shit. Years of cruft, and more added on every year.
I'm not a fan of Google, nor do I use their services, but they are at least based on open standards anyone can use... I don't just mean email, I mean calendars/appointments (CalDAV), contact syncronization (CardDAV), internal messaging (XMPP), etc.
Microsoft and their need to convolute everything until it crumbles in the users hand for the sake of locki
Re: (Score:2)
So if it performs worse than any other available MTA the excuse is "but can an MTA do this" when it's an entirely different part of the suite doing the job.
Exchange. The name itself is very good advice on what to do with it. A positive is it did lead to Volume Shadow Copy because there was no reliable way to back up MS Exchange files without stopping the services and not letting users open their mailbox
Re:So Let Me Get This Straight (Score:5, Insightful)
The same as it's always been... full integration with the entire line of business-oriented Microsoft products (including Exchange) and support for the vital third-party software that requires Windows.
For many years, Microsoft's business model has been to promote a Microsoft-centric universe. If you use Office, you'll get the best service with an Exchange server, which must run on Windows Server, and really needs Active Directory, which supports your Windows workstations, which integrate with Office. It's not just that Windows is a GUI-based OS. Microsoft products are a part of a whole tangled mess of dependencies, and for years we've been stuck dealing with the downside of that glorious integration.
Every IT admin has a story about the vital business process that involved a human robot. Every day a human logs in, and runs an Excel macro to generate a spreadsheet, that he saves as a CSV file and loads into a third-party program, which generates a RTF document, that needs to be renamed to .txt and moved to a different folder for another program to find and render into a PDF, which the human has to open and read the third line on the fifth page to determine which managers need the report emailed to them. This is a GUI-based process, because the software runs on a GUI-based OS. It can't be automated, because the software doesn't support it. For decades, automation has been a "nice to have" feature, because it never fit into the Microsoft business model, so there was never a good framework to support it built into Windows.
Sure, we had some old tricks... Batch files, DDE, COM, OLE, WSH, VBA... but they never really enjoyed full support from Microsoft. They were supported features, but not supported enough that third-party vendors would feel pressure to support any automation.
Now, with PowerShell and the Core offering of Windows Server, there's the notion that everything should be able to be automated. Sure, we've had that idea from the very first days of Unix, and *nix has embraced the concept to maturity, but *nix still doesn't run every piece of business-critical third-party software. For those of us who are already firmly entrenched in that Microsoft-centric world, this is a much-needed good omen.
Re: (Score:2)
True, MS Outlook is very flaky at times doing normal email unless the server is in the same building. I've had to get users onto a VPN simply because MS Outlook does SSL so badly. Phones with 1/10 the CPU on congested networks perform better picking up mail than a fast machine with MS Outlook.
Re: (Score:2)
SQL Server, is another reason.
It's been a mistake everywhere I've seen it used.
True, it's nicer than MySQL, but you pay for it.
Re: (Score:3)
SQL server is a database server, and some applications require it... but at least there are others, and one doesn't have to run their business on it. There are alternatives, from MySQL/MariaDB to Oracle, and the nice thing about Oracle is that there are no license keys to manage, so if there is a disaster, getting your RAC cluster back operable isn't dependent on licensing/activation.
This isn't to say SQL server is bad, but if one wants to move from Windows, there are RDBMS products which are just as good
Re:So Let Me Get This Straight (Score:4, Interesting)
Gosh, what did we ever do before Windows 2000? Authentication by clay tablet?
It's the egocentric nature of MS's claims, that somehow computing couldn't be done without its products, that pisses me off the most. It denies an absolute vast amount of work done in these areas for decades before derivative technologies like AD even existed
Just like how Redmondites are doubtless cheering the innovation of giving Windows admins what everyone else has had for decades. This isn't a moment for pride at Redmond, but the moment when if fully recognizds just how shabbily it treated people stuck trying to do automation on its amazingly incoherent platform.
Re: (Score:3)
That summed up the attitude nicely.
Re: (Score:2)
We got along just fine for years at Sun without Exchange or AD. Outlook was strictly verboten, and our mail servers actually handled lists correctly.
Good times.
Re: (Score:2)
Well, whenever it appears on Server, and by that I'm assuming our Server 2012 seats won't have it, so what this amounts to is "Shell out a bunch more money in operating systems and CALs, and we'll give you this nifty feature (which every other server grade OS has had for a couple of decades now)
Re: (Score:2)
Perhaps if it came with a dose of humility.
Oh, and Bash.
Re: (Score:2)
Am I the only one who finds Powershell exceedingly slow? Load up is crazy, and try to load in extensions like Exchange, and holy shit it crawls.
Meanwhile Bash always seems snappy, despite being a fairly complex interpreter itself.
Pooh-Pooh all you want. This is great news! (Score:5, Interesting)
For those of us that have no choice but to manage Windows and *nix boxes, it's a pain in the ass to have to context switch between RDP and ssh'ing. This will make our job much easier. Between all the open source software, github, and stuff like this, I love the new MS. Of course our real servers will always run FreeBSD.
Re: (Score:3)
SSH and docker support will get the MBA types who fear change and spending cash to consider Server 2016.
I would rather MS innovate than to just EOL good products instead.
SSH support will go everywhere including the MMC SNMP tools and not just powershell for remote work. FOr any organization with security in mind this will be a HUGE reason to upgrade. Sadly, since Server 2016 is already in preview 4 I doubt this will see hte light of day on that release. It will be 2018 with Server 2016 R2 before we see SSH
Re:Pooh-Pooh all you want. This is great news! (Score:4, Insightful)
But why in the hell do you want to shell out thousands of dollars on Windows Server ($6k or so to run unlimited virtualized environments?) for something that runs perfectly fine on (free) Linux.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It is $6,500 plus per core cpu costs for VMWare. Hyper-V comes free with the server license
Re: (Score:2)
Because $6k is s small change compared to the cost of a few admins familiar with Linux. There are far more admins familiar with Windows, so you can pay them less, so your $6k is saved in a few months max.
Oh, and there is the option to move your virtualized servers into the cloud. Microsoft makes it really easy to migrate, or just buy extra capacity from Azure. I'm sure there are people offering something similar for Linux, but you can bet it's not as good.
Re: (Score:3)
It's probably an R2 feature, so right, 2018. I can't possibly see them shoe horning something as foundational as SSH in to Windows at the last minute and expecting it to be secure and with low overhead.
Re: (Score:2)
For those of us that have no choice but to manage Windows and *nix boxes, it's a pain in the ass to have to context switch between RDP and ssh'ing.
Remote shells for Windows have been available for decades. Hell I remember telnet server was included with NT net tools a lifetime ago. A lifetime before that directing command interpreter thru modem ports.
Multiple vendors offer ssh servers for windows and all of the unix shells have been ported to windows. Anyone who really wanted one would already have one.
This will make our job much easier. Between all the open source software, github, and stuff like this, I love the new MS.
You mean the Microsoft that thinks it owns the users computer and can force spying and updates on people unwittingly and or against their will? Yea
Re: (Score:3)
Remote shells for Windows have been available for decades. Hell I remember telnet server was included with NT net tools a lifetime ago. A lifetime before that directing command interpreter thru modem ports.... Anyone who really wanted one would already have one.
Remote shells? Yes! But SECURE, Remote shells? They have never had that built-in. I don't think you realize what a bad idea it is to communicate with you company's servers over plain text. And VPNs aren't always an option. I can always get ssh through, but I've been on plenty of networks that block VPNs. Not to mention needing additional VPN software and hardware key fobs. Give me pure ssh any day!
Re:Pooh-Pooh all you want. This is great news! (Score:4, Informative)
Remote shells? Yes! But SECURE, Remote shells? They have never had that built-in.
Powershell's remote shell is secure [technet.com], and that is built-in to Windows.
Re: (Score:2)
Remote shells? Yes! But SECURE, Remote shells?
Everyone used telnet at the time.
They have never had that built-in. I don't think you realize what a bad idea it is to communicate with you company's servers over plain text.
As I said in the text you didn't bother quoting multiple vendors offer ssh servers for windows. Anyone who wants ssh access to windows already has it. What does it matter if it is built in or not?
Re: (Score:2)
You mean the Microsoft that thinks it owns the users computer and can force spying and updates on people unwittingly and or against their will? Yea real swell...
That would be the Microsoft that lets you pay for the system, then purports to rent it back to you, hoping you'll not notice, yes.
Re: (Score:2)
Your losing a lot of the flexibility and security of SSH by doing it via RDP, eg if your using key based auth then your key must be stored on the rdp host, and you can't pipe stuff back and forth to your local machine..
Also, putty is pretty dated when it comes to encryption ciphers it supports, so you need to maintain a weak ssh configuration on your hosts.
When? (Score:2)
Still running the general release 10240 build.
Allegedly there was some November update that was aborted.
cygwin (Score:2)
I needed that functionality on Win 7, along with other tools.
Dropped Cygwin onto it, and it works pretty well.
http://cygwin.com/ [cygwin.com]
Re: (Score:3)
And you can get a bash shell.....
SSH into windows to get a powershell? No thanks.
For some definition of 'forward-looking' (Score:2)
I applaud them finally embracing a sensible remote shell strategy. I recall many heated debates where MS would say all sorts of nasty things about ssh.
However, I can't say that implementing decades old terminal function and ssh is 'forward looking'.
Re: (Score:2)
Didn't they already do this, though?
I seem to remember that Microsoft Services For Unix (SFU) had an optional ssh component too.
but why ? (Score:5, Interesting)
Not sure why anyone would care ... the whole "Windows 10 experience" is such a horrific platform to try and do any work done on ... fixing the shell is a noble step indeed, but there are so many other show stoppers on that system, that its just a drop in the ocean.
Re: (Score:2)
Like?
Re: (Score:3)
Why? Putting all the privacy shit aside I don't see Windows 10 any different for getting work done than Windows 7. Both of which have the edge over Vista with better window handling.
There's a lot of things to complain about on Windows 10, getting work done on it is not on that list.
Fifteen mentions of Windows on the front page .. (Score:2)
FORWARD looking? (Score:2)
OpenSSH came out in 1999. We are now in 2016. Which means Windows in 17 years behind the curve. When OpenSSH was available for BSD Windows ME was the new hotness and Windows 2000 did not exist yet, never mind XP and 7.
What part of "Forward" am I missing?
Re: (Score:2)
You have to laugh (Score:3)
I think the Unix guys are getting the last laugh...
Re: (Score:2)
Then Microsoft grew up and became a completely different company that values the needs of their enterprise customers.
I hope it has a lot of features (Score:2)
If it is feature-ful enough to complete with the 3rd party terminal clients companies could save a lot of money when they migrate to windows 10.
Re: (Score:3, Interesting)
I can only hope you can run a native version of Bash with a set of GNU or Posix versions of the toolset, and I can send Powershell to the shithole that horrible scripting language belongs.
Re: Turd (Score:4, Insightful)
Powershell has some great features and ideas. And whilst it can be great to script in, it is very long winded to just type and use in an adhoc fashion. Sure there's aliases but its still a bit tedious.
The other thing power shell needs is more social interaction and perhaps just a bit more fun. I guess it's still quite new and evolving. Bash is ancient relatively speaking.
I'd like to see stuff like figlet, write, wall, mutt natively in powershell so it becomes more of a destination than a mere dull workhorse of productivity.
Re: Turd (Score:5, Funny)
I'd like to see stuff like figlet, write, wall, mutt natively in powershell so it becomes more of a destination than a mere dull workhorse of productivity.
Be patient - they have to get the keylogger working correctly first.
Re: (Score:2)
Sycraft-fu [slashdot.org] says that you are an idiotic, paranoid, conspiracy theorist for daring to state that Windows 10 contains spyware.
He's just practicing the latest version of denialism.
Re: Turd (Score:5, Interesting)
I've done a lot of neat stuff with powershell, for example I created a powershell script that gathered information about one system (using the Get-WmiObject Win32_SystemEnclosure to retrieve i.e. a computer's brand name, serial number, bios version, etc) and opened a TCP socket to feed that information to another system across the network that had a listening server which was also written in powershell.
But yeah, it totally violates the KISS principle. It's hard as fuck to look up certain information about the system because the way it's stored and retrieved is almost never intuitive (for example, you literally have to generate an XML file and then parse said file in order to get some stuff.)
It's also very hard to figure out how to do something you might not have done before, or have done very rarely, because the command names are so long that they're difficult to remember. There are shorter aliases, but they don't have any consistent naming (for example, Get-WmiObject can be shorthanded as gwmi, whereas a command like Add-PSSnapIn is shorthanded as asnp) making them also harder to remember.
I would much rather just have bash, and do that server stuff I did with tools like netcat, which although uses a separate binary, is FAR simpler than the method I used with powershell, while also having tools like dd to be able to manipulate binary blobs, and dummy block devices like /dev/zero, /dev/random, and even the ability to directly read/write to hard disks as if they were ordinary files.
If Microsoft did that, and had a good package manager for command line tools with the ability to add third-party repositories (like aptitude does) with options to compile from source (like portage does) I might actually consider using it for servers now and then. But because it doesn't, I only use it for servers either when an application requires it (as in, no Linux version available, but this is quite rare for applications meant for servers) or for active directory (also only occasionally needed.)
Re: Turd (Score:4, Funny)
I've done a lot of neat stuff with powershell, for example I created a powershell script that gathered information about one system (using the Get-WmiObject Win32_SystemEnclosure to retrieve i.e. a computer's brand name, serial number, bios version, etc) and opened a TCP socket to feed that information to another system across the network that had a listening server which was also written in powershell.
You work for Microsoft on Windows 10 then?
Re: (Score:2)
LOL I did that in an IT shop that was primarily Microsoft driven. I was working Tier 2 tech support (also called Desktop Support) and because I wasn't a Tier 3 tech (system engineer they were called) I had to work within the limitations of what the systems already had installed. The actual system engineers were retarded though and didn't know how to manage active directory worth shit, so I ended up finding broken shit all the time and having to build workarounds for said broken shit.
This particular script w
Re: Turd (Score:2)
It's also very hard to figure out how to do something you might not have done before, or have done very rarely, because the command names are so long that they're difficult to remember. There are shorter aliases, but they don't have any consistent naming
How can you complain that PS cmdlets are both too long to type and difficult to discover? They for the most part follow a very straightforward convention of [approved verb]-[specific noun]. Like Get-childitem, add-content, export-csv, etc. There is no rhyme or reason to the naming on Unix commands. Good luck discovering the utility you're looking for the first time without Google. And you really can set aliases quickly in PS so I see that method as being the best of both worlds. Complain all you want about
Re: Turd (Score:5, Interesting)
What do you mean no rhyme or reason? The basic toolset; cat, sh, mv, rm, and so forth are mnemonics. The point being to make the commands as short as possible while retaining some semblance of meaning. For me Powershell's absurdly verbose naming scheme is as good a sign as any that Microsoft has never really understood CLI work.
Re: (Score:2, Interesting)
For me Powershell's absurdly verbose naming scheme is as good a sign as any that Microsoft has never really understood CLI work.
Once upon a time in a galaxy long long ago there was an operating system that had batch scripting and short terse commands like: DEL, DIR, TYPE, CD, ATTRIB, COPY, ECHO... It ran on machines that had 640K of memory because that ought to be enough for anyone...
I think Microsoft did actually understand at one time but somehow that was lost somewhere along the way...
Re: Turd (Score:4, Informative)
They haven't. When I first tried to use PowerShell it frustrated me so much I wrote an entire article about it [medium.com]. Calling PowerShell a shell is a huge stretch: it's really just a strange and verbose scripting language.
Re: Turd (Score:4, Informative)
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.
Re: (Score:2)
How can you complain that PS cmdlets are both too long to type and difficult to discover? They for the most part follow a very straightforward convention of [approved verb]-[specific noun]. Like Get-childitem, add-content, export-csv, etc.
Ok here's the problem: It's never clear when you need to get content or get object or get whatever other verb they want to use. There's so much different ways of retrieving information because the way its stored is never consistent. For example, if I want information about the CPU, that's a WMI object. If I want information about running processes, that's another type of object.
But bash? Everything can be treated as an ordinary file. EVERYTHING. All system objects that you want to examine can be grabbed usi
Re: Turd (Score:2)
I've been wanting Windows to get full Unix emulation, and even better, built in compiler support like a Unix box. I want to be able to test and run python scripts that will run on Unix vms on my box through pycharm without having to use a remote vm environment. Right now, it's easier to use a macbook pro. You'd think some monkey in marketing would have caught on to this fact.
Of course ntfs file permissions behave differently than Unix file permissions but I think that is reconcilable. I know there is cygwin
Re: (Score:3)
This. I'd love the ability to provision a Windows box, toss a SSH key on it and have it ready to be managed via Ansible.
On the development side, being able to Vagrant up a Windows box as easily as I do other boxes would be nice, and make life a -lot- easier when it comes to testing. If I need to create a Windows box to make sure a certain set of Registry settings works, it would be nice to create a base box, boot it, have Vagrant provision it, and have it ready to go. Then, when I want to prove my stuff
Yes, we are still a long way from Mars (Score:2)
isn't the same as either cmd.exe or powershell.exe, but there is a lot of overlap in functionality
Sorry, Major Tom, we have a long way to go
when we still have to apologize for their efforts.
It has been an interesting journey, Ground Control.
Re: (Score:2)
not flamebait; just the facts, ma'am.
The surprise is, MS servers want to collect data on this turd. Very dis turding...
Re: (Score:2)
The implementation of OpenSSH will use the Windows encryption libraries and random number generator, just like their implementation of SSL/TLS used by their webserver and browsers. If you are using Windows, a least some lof of the time you'll probably using at least one of those. Even if it's just to retrieve and verify Windows Updates.
So if you don't trust those... why would you use Windows in the first place ?
Re: (Score:2)
Exactly! Using Windows 7 Pro at home and at work here.
Re: (Score:3)
DOSBox?
Microsoft stopped shipping MSDOS (via Windows Millennium Edition) a long time ago. If you've had 15 years to transition off DOS and Win16 applications that worked only via a compatibility mode of XP then I don't think you can blame MS for not giving your customers ample time to update.
Re: (Score:2)
No but I wouldn't expect a company to indefinitely support a compatibility module for a technology that they haven't actively developed for over 2 decades. I don't hear anyone complaining in 2016 that OS X won't natively run Mac OS 7.1 applications from the early 90s.
Re: (Score:2)
Re: (Score:3)
Backwards compatibility isn't one of the important goals, and in some cases, incompatibility is the goal.
And yet the link you supplied to support this theory states that the AARD code only affected a particular beta version of the operating system. That situation was more about targeting tests than lack of backwards compatibility.
A lot of code that stopped working (for example in the change to Vista) was because the developers did things that were outside the published API and often specifically discouraged by the official documentation. Despite what a lot of people say, Microsoft does work hard to ensure back
Re: (Score:2)
Microsoft try very hard to retain backwards compatibility, and there are all kinds of nasty hacks for that purpose...
The problem is that many things in windows were just so poorly designed that improvements can't really be made without breaking compatibility, scroll up and look at the post about console windows for instance.
Re: (Score:2)
Pity there isn't a -1 ; Conspiracy Theory mod (Score:5, Insightful)
Slashdot needs ones. Seriously, for a community that claims to hate FUD, the OSS types sure like spreading it when it is about the "right" groups. If you actually care about what kinds of things the telemetry communicates back at various settings, the information is all out there for you. No, SSH data isn't one of them. However I am going to imagine you don't, and this is just crap you want to fling at "the bad guys" because you can.
Also a thought for you: Your OS, by definition, has access to anything any program on the system is doing. What would stop it from looking in at any 3rd party SSH server you ran, if you think it does that?
Another Dimension (Score:2)
Pity there isn't a -1; Conspiracy Theory mod
Modding should really be happening along more than one dimension. With a nerd crowd you could easily have multiple scoring systems side-by-side. For example, a 543 might be 5 (insightful or informative), 4(funny), 3(mainstream v. conspiracy). Someone can have an insightful comment that is a bit conspiracy theorist--like most accurate comments about spying that would have been made pre-Snowden, for example.
Re: (Score:2)
You: "I'm your new owner, don't call home"
Windows 7 et al: "OK"
"Hmm... it obeyed me"
You: "I'm your new owner, don't call home"
Linux et al: "OK"
"Hmm... it obeyed me"
"Hmm... its meant to obey me"
You: "I'm your new owner, don't call home"
Windows 10: "OK, jump through these extra hoops"
"No, not obeying me"
Re: (Score:2)
Please point me to the place where the information where Microsoft provides the detailed information about what telemetry data is collected. I don't think you can because I've checked and such a document does not exist. It is not 'out there' and while I only present a hypothesis, you are simply factually wrong (aka full of shit).
>Also a thought for you: Your OS, by definition, has access to anything any program on the system is doing. What would stop it from looking in at any 3rd party SSH server you ran
Re: (Score:2)
FUD is only a bad thing when it is manufactured artificially with no regard to truth. Vaccines causing autism, preached by someone selling a "safer" alternative? FUD. CO2 increasing average global temperatures? Uncomfortable truth. A little CO2 might cause the collapse of civilization/end of the world? FUD.
Re: (Score:2)
telemetry communicates back at various settings, the information is all out there for you.
Where? Where is the specific information? The Microsoft Privacy policy is so vague it is laughable.
You have a Donald Trump Level of denialism, coward.
Re: (Score:3)