A tweet from the OpenSSH developers:
Looking Forward: Support for Secure Shell
281–290 of 404 posts
Re: Looking Forward: Support for Secure Shell
#282http://www.microsoft.com/en-us/download/details.aspx?id=2391 If I am forced to use Windows in an Enterprise setting, then I just go to Control Panel and enable the POSIX layer ("SUA"), then download the SDK and install. With some minor changes to the %Path, it just works. SUA has older versions of tcsh, ksh, vi and many other utilities, including an older Perl and an old GCC toolchain that does work. It is 4.2BSD bas…
SUA was deprecated in Windows Server 2012 and Windows 8, and MS actually recommends using cygwin or mingw as alternatives to it.
Re: Looking Forward: Support for Secure Shell
#283Earlier quoted context omitted.
FYI: http://www.hanselman.com/blog/Console2ABetterWindowsCommandP... Will happily run a cmd window, or other command you supply (e.g. I run a cygwin zsh)
I recommend checking out ConsoleZ which is a fork that looks very promising and has a github repo that has more traffic than the sourceforge console2 project.
For anyone looking for old and mature options, xterm on a rootless Cygwin X server works quite well.
Re: Looking Forward: Support for Secure Shell
#284Earlier quoted context omitted.
Come back to us when you've found a way to implement the good stuff that Windows has, such as IOCPs: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... And no, epoll isn't enough.
If I remember correctly, the node.js team needed a lot of help from experienced Windows developers (even from Microsoft itself??) to add IOCP support to libuv. I think kqueue is the best (well I guess I'm a BSD fan :D) but in general: app developers generally don't care about this, they just use libuv or libevent or something like that. Does Windows really have "good stuff" for developers? .NET is excellent, but the…
Yes, even Windows has good stuff under all that legacy crap, and IOCPs are one of those things. The actual low-level APIs - and I'm talking kernel-level stuff here - aren't that bad. The bad stuff is what's layered on top of that, such as the Win32 APIs, which are genuinely crap.
I also really like kqueue (and unsurprisingly FreeBSD is also my OS of choice) and it's better in general than epoll, but it has its limitations. For instance, directory and file change notifications are less than awesome as kqueue needs file handles. inotify on Linux works better for this stuff, IOCPs just work for this stuff.
My point was that dismissing everything in Windows like jadeddrag did is shortsighted and dumb. It's not as if Unix-like OSs don't have plenty of misfeatures: nobody in their right mind is going to say that sockets couldn't have been designed much better (see how Plan 9 implements them for a better designed API), or that audio on Linux isn't a godawful mess, or that X isn't a monstrosity.
You're right, all that stuff is great, but as they saying goes, "why worry about a speck in the other guy's eye when you've a log in your own?"
Re: Looking Forward: Support for Secure Shell
#285Earlier quoted context omitted.
If I remember correctly, the node.js team needed a lot of help from experienced Windows developers (even from Microsoft itself??) to add IOCP support to libuv. I think kqueue is the best (well I guess I'm a BSD fan :D) but in general: app developers generally don't care about this, they just use libuv or libevent or something like that. Does Windows really have "good stuff" for developers? .NET is excellent, but the…
That doesn't make IOCP worse than epoll, it's just not the same as epoll. Look at PyParallel: https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...
Exactly! And that's an excellent presentation that outlines what's really cool about IOCPs.
Re: Looking Forward: Support for Secure Shell
#286Earlier quoted context omitted.
Yeah, I would genuinely like to know what all is considered to be bloat within the Unix space. If anyone could point to some information about this I'd be curious.
X11, KDE, GNOME, GCC, Emacs, Mozilla? Any huge project I guess. The GNU command line tools are not as lean as the BSD ones but so what?
They also generally have more (useful) features than the BSD ones.
Re: Looking Forward: Support for Secure Shell
#287Earlier quoted context omitted.
Even better don't use default ports. Or have a second ssh that doesn't except any IP address at port 22 and than have your non-standard port with keys and limited user names and if possible a white list of your IP addresses.
Not using default ports will mildly confuse automated scans and do absolutely nothing to a determined attacker. Or somebody with nmap, which is not the same thing. If you're whitelisting IPs, you may as well run it on port 22.
One small benefit of using a non default port is that it keeps down the noise from automated scans. So any "real" suspicious activity will now stand out as it is not drowned out by the noise anymore.
Re: Looking Forward: Support for Secure Shell
#288For all Balmer's thing of dancing on a stage and chanting "developers", there was no point under Gates or he at which Microsoft felt like a pro-developer company. That has completely changed in the last eighteen months. Each time I think "wouldn't it be cool if" I'm finding a few weeks later that someone at Microsoft is well ahead of me. How much easier it will be to ship my sucky roguelikes to Windows users in this…
>Wishlist: tmux, emacs, vi, netcat, shell option for vi-mode, rc-file with preferences, ncurses library, something simpler than curses, zip and unzip No thankyou. I can certainly understand including SSH support, but I don't want what is pretty much the only remaining viable non-Unix platform to start bundling horribly dated and clunky Unix-like commands and bloated GNU tools.
Powershell will need some kind of text editor though, even if it's just something as simple as nano.
Re: Looking Forward: Support for Secure Shell
#289http://www.microsoft.com/en-us/download/details.aspx?id=2391 If I am forced to use Windows in an Enterprise setting, then I just go to Control Panel and enable the POSIX layer ("SUA"), then download the SDK and install. With some minor changes to the %Path, it just works. SUA has older versions of tcsh, ksh, vi and many other utilities, including an older Perl and an old GCC toolchain that does work. It is 4.2BSD bas…
SUA was deprecated in Windows Server 2012 and Windows 8, and MS actually recommends using cygwin or mingw as alternatives to it.
I will keep using it as long as it is there.
I hate using Windows and I have never been one to follow MS "recomendations". Are you kidding? I do not work in an IT department.
I used MSYS and Cygwin for many years. Now I use SUA.
The less I have to use Windows the better. It dulls the mind.
Re: Looking Forward: Support for Secure Shell
#290Earlier quoted context omitted.
CalDAV and CardDAV are supported on Windows Phone 8 since GDR2 as the method to sync Gmail accounts. OneDrive supports ODF via Office Online. OpenGL runs fine on Windows and is less relevant now than ever thanks to Metal and DirectX 12, etc. Oh and the new Outlook app for iOS and Android also has broad support for competitors and open standards. Sure, it's through the cloud, but it works. If you want to punish compan…
> OpenGL runs fine on Windows and is less relevant now than ever thanks to Metal and DirectX 12, etc. I have to express strong disagreement with this entire sentence. OpenGL on Windows desktop continues to suffer greatly from Microsoft's lack of support. OpenGL is more relevant now than ever before due to the dominance of OpenGL ES on mobile and web. Microsoft is starting to support it themselves with WebGL in IE11 a…
> OpenGL on Windows desktop continues to suffer greatly from Microsoft's lack of support
In what way? I write graphics code for a living and from what I've seen opengl is basically fine on windows. They could do more, sure, but I never felt like they were getting in the way.
I have mixed feelings on the directx thing. In principle I'm not a fan of directx, but in terms of API quality it's vastly better than opengl. Admittedly that's not saying much: opengl's design kind of sucks. State management when almost every state you set is global is a nightmare.