not to be too snarky, but perhaps "looking backward" would be a better title =)
(don't get me wrong, I love my ssh and am glad to see msft supporting it for real)
Looking Forward: Support for Secure Shell
111–120 of 404 posts
Re: Looking Forward: Support for Secure Shell
#112Finally! PowerShell Remoting just plain sucks, at least it has for me. I've always wondered why the PowerShell developer(s?) would do something so needlessly contrived when SSH has been around for, like, twenty years or so. This will definitely make my job easier! Or at least more convenient.
"I've always wondered why the PowerShell developers ..." Think about the beginning of that sentence. They invented a new console language, when bash has been around forever and C# is a better programming language generally and can be run as a scripted language with a little finagling. I don't think the PS team is bad (or PS itself for that matter), I just think there was a lot of re-inventing of the wheel for no reas…
This a good point. The internal incentives of the previous ranking model used by HR there create these behaviors.
More here: https://news.ycombinator.com/item?id=9598015
Re: Looking Forward: Support for Secure Shell
#113Finally! PowerShell Remoting just plain sucks, at least it has for me. I've always wondered why the PowerShell developer(s?) would do something so needlessly contrived when SSH has been around for, like, twenty years or so. This will definitely make my job easier! Or at least more convenient.
"I've always wondered why the PowerShell developers ..." Think about the beginning of that sentence. They invented a new console language, when bash has been around forever and C# is a better programming language generally and can be run as a scripted language with a little finagling. I don't think the PS team is bad (or PS itself for that matter), I just think there was a lot of re-inventing of the wheel for no reas…
Well, either way, I'm glad they have finally decided to go for SSH.
I'm still not sure I really like PowerShell, but whether one likes it or not, it has become too useful to ignore. And even on days when I really dislike it, it is still a huge improvement on cmd and vbs. I still do a lot of my Windows scripting in Perl, mostly because I am familiar with it, CPAN still rules, and I am not sure I want to learn the .Net framework just so I can do some admin-type scripting. But it's good to have options.
Re: Looking Forward: Support for Secure Shell
#114I'm looking forward to MS just dropping their OS entirely and using linux as their back-end. Basically, Microsoft might be better off creating their own linux distribution running a "microsoft windows" windows manager.
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 lower level APIs look horrible. (And the CP/M / DOS era files stuff – drive letters, file extensions that actually matter – makes me very unhappy.)
Jails, ZFS, DTrace, FUSE, netmap, PAM, pf – that's good stuff!
Re: Looking Forward: Support for Secure Shell
#115Earlier quoted context omitted.
Isn't ISE pretty ok? At least it has decent enough copy and paste...
What is ISE? A link would be nice too (please?)
Powershell ISE?
Re: Looking Forward: Support for Secure Shell
#116Earlier quoted context omitted.
A VPN with sshd exposed only inside the private network is a much smarter way of handling remote access. (But it's initially harder, so lots of people don't do it.)
You're just trading sshd bugs for VPN bugs, in that case. Which are more likely? From what I know, I think I'll put my lot in with sshd. Perhaps I'm not well informed, though. Also, sshd + fwknop (port knocking) is a very secure combo, IMO.
sshd would still be authenticated. It's defense in depth.
Re: Looking Forward: Support for Secure Shell
#117http://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 based. If you are at home on BSD, it is like going back in time.
netcat, tmux, emacs, etc. you would have compile yourself. Maybe OpenSSH would compile and run. I have not tried.
Perhaps an alternative to Cygwin, etc. Not "better" but different. It generally "seems" faster and I find it's more difficult to "break" than Cygwin which in my experience can be very "delicate". The SUA White Paper says SUA comes to within 10% of the speed of native Windows.
The main advantage though, for me, is that this is not "unauthorized third party software" to the extent it comes with Windows and the SDK download comes from Microsoft's Akamai account.
Re: Looking Forward: Support for Secure Shell
#118Earlier quoted context omitted.
Cygwin has all of those things and ssh server support.
I don't know many sysadmins who would use Cygwin to handle remote access to production servers.
A while back when I was responsible for windows boxes they ran ssh and RDP, there were plenty of times when machines were un-RDP-able but I could still SSH in and fix the saddness.
Re: Looking Forward: Support for Secure Shell
#119Earlier quoted context omitted.
Ballmer has a BAD case of "Not invented here". I remember reading a story about him calling out and mocking an employee in a meeting b/c they has an iPhone (this was around 2008 I think). First off it's a VERY GOOD IDEA to use your competitors products if only to see how they stack up (Spoiler: They blew away MS's mobile offerings in 2008 and still do to this day). Second, what a way to make all of your employees yes…
I moved away in 1999 to the Mac, and because of the incredible expensive Macs nowadays, I'm probably going to make another move, to Ubuntu. Still, Steve Jobs was not an easy guy either. I don't know if he would mock an employee for having an Android phone? Not unlikely given how anti-Android he was.
VERY good point and honestly one that I hadn't thought of. I'm not aware of any publicised cases of Jobs calling out an Android phone but I would believe it, he was an asshole. IIRC he was so anti-android b/c he saw Android as a blatant rip-off of iOS (not weighing in here on either side).
As far as cost of macs I think it's still worth it even if you want to run Ubuntu as your OS b/c they hold their value better than any other laptop I've seen on the market. They also resell FAST which is very nice.
Re: Looking Forward: Support for Secure Shell
#120Earlier quoted context omitted.
Could you expand why you find ISE clunky and awkward compared to standard terminal? I mean you can just type in stuff and get answers back with fairly minimal interference as far as I can tell, just like a regular terminal.
I would suggest you go look at iTerm2, because an example is worth all the words in the world. tmux integration, multiple panes in a window as well as tabs, easy buffer search, instant startup, everything. A shell host should open and do its absolute utmost to get out of my way. ISE does not do this. It's just...it's what I expect 2008 Microsoft to think a terminal should be, lacking empathy for me as a user. And may…
Those sound nice-to-have features, but (personally) I don't think the lack of those makes something "super clunky and awkward to use", especially in comparison to standard terminals. Do you think xterm is too super clunky because it lacks all the bells and whistles?
I still do not see where the lack of empathy and tastelessness is apparent in ISE.