Live data from Hacker News

Looking Forward: Support for Secure Shell

blogs.msdn.com

401–404 of 404 posts

Re: Looking Forward: Support for Secure Shell

#401
post #128
post #60

For 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.

"the only remaining viable non-Unix platform"

Why do you think that is? As in, why is everyone else on unix (like toolchains)? Why do you think pretty much the entire tech-stack of mobile and web companies has moved to Linux or BSD as the default choice.

The reason is clear. The unix "small tools connected by text based pipes" philosophy has won. Whether disaffected powershell users find it clunky or not is not the point. Unix tools are the lingua-franca of developers everywhere.

There are many reasons for this but the most important is that the commandline toolset for managing a machine from a remote terminal has always been the most important UI for unix over the last forty years. You can call it "dated". The industry calls it "the standard".

The irony here is that Microsoft itself has come to the realization that they have to follow where the developer ecosystem is inexorably marching en mass. There will of course be a certain percent of holdouts clinging to their powershells. But now they'll be fighting against not only the linux'er and BSD'rs. But Microsoft management itself.

Re: Looking Forward: Support for Secure Shell

#402

Earlier quoted context omitted.

Out of interest, what's wrong with MSVC runtimes? Plenty of software has been written using it. Doesn't Wine basically implement MSVC runtimes?

And said software is typicaly bloated and buggy relative to its Unix counterparts. The MVSC runtimes are popular solely because Windows is popular. Wine is a stopgap for software that's still reliant on Windows. The preferred approach would be for that software to instead be properly ported, which would include using a proper libc and executable package format (like ELF). That said, my opinions aren't representative…

So are you saying the C++ STL under Windows is poorly implemented and causes sudden executable growth? (Admittedly, std::max has performance problems under VC2010 but that's kind of old)

Software bloat has nothing to do with the runtimes. It's how people use the runtimes that's the problem. Saying that the runtimes cause software bloat is a massive generalisation.

When I use the MSVC runtimes my software isn't bloated. I compile the same code under OSX and Linux and it also isn't bloated there. In fact, under OSX it uses far more RAM, and I have to bundle along dylibs with the executable inside the .app itself in order for it to be usable. This makes my OSX app far far larger than my Windows binary, which just relies on the MSVC runtimes.

Interestingly, my software doesn't crash either. If the MSVC runtimes were "bloated and buggy" then I would be crashing all the time, but my programs don't....

The executable format under Windows was originally designed to be portable - hence PE (portable executable). Just because they abandoned the other platforms (outside Intel land) does not make the binary unportable.

Re: Looking Forward: Support for Secure Shell

#403

Earlier quoted context omitted.

Why? I assume that "private VLAN" means it isn't exposed to potential external attack.

http://en.wikipedia.org/wiki/VLAN_hopping

I've seen this in older units, but has any recent switch been vulnerable to this?

Re: Looking Forward: Support for Secure Shell

#404
post #117

http://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…

I just download GnuWin which gives you most Unix tools compiled natively for Win32. Includes OpenSSH too. http://gnuwin32.sourceforge.net/

from the look of the website, GnuWin is terribly out of date and packages like OpenSSL (I don't seen OpenSSH listed) will have lots of known security vulnerabilities..
Post reply on HN