Live data from Hacker News

Looking Forward: Support for Secure Shell

blogs.msdn.com

361–370 of 404 posts

Re: Looking Forward: Support for Secure Shell

#361

Earlier quoted context omitted.

Yes, they even had a slogan "Windows NT is a better UNIX than UNIX". Which never rang really true, but NT had promise.

Could you be mixing this up? There was a heavil-used phrase, "OS/2 is a better Windows than Windows" during the Windows 3.0 era, because the OS/2 Windows subsystem was far more stable than Microsoft's Windows (and also - as it happens - a good deal more stable than the rest of OS/2 also).

I'm not making it up; if you google the phrase "better Unix than Unix" you'll find a number of references to these words. However, it probably wasn't a direct quote by Bill Gates, as was claimed.

http://www.uniforum.org/publications/ufm/aug96/unix-nt.html

https://books.google.fi/books?id=g0CPF6MEFcUC&pg=PA1&lpg=PA1...

Re: Looking Forward: Support for Secure Shell

#362

Earlier quoted context omitted.

> And if I never have to parse the output of ls -l using cut again, I will be a happy person. Try stat instead, e.g. $ stat -c 'NAME: %n; OWNER: %U, SIZE: %s' * also supports --printf (see man stat).

It's not standard enough --- coreutils and OSX's work differently.

Yeah, same with the find -printf (at least macports can install coreutils and give you "gstat"). Portability is hard :-/ http://mywiki.wooledge.org/ParsingLs

Re: Looking Forward: Support for Secure Shell

#363

Earlier quoted context omitted.

Could you be mixing this up? There was a heavil-used phrase, "OS/2 is a better Windows than Windows" during the Windows 3.0 era, because the OS/2 Windows subsystem was far more stable than Microsoft's Windows (and also - as it happens - a good deal more stable than the rest of OS/2 also).

I'm not making it up; if you google the phrase "better Unix than Unix" you'll find a number of references to these words. However, it probably wasn't a direct quote by Bill Gates, as was claimed. http://www.uniforum.org/publications/ufm/aug96/unix-nt.html https://books.google.fi/books?id=g0CPF6MEFcUC&pg=PA1&lpg=PA1...

Thanks. Bizarre.

Re: Looking Forward: Support for Secure Shell

#364
post #316

Earlier quoted context omitted.

> You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration. That's an interesting way of putting it. I strongly prefer the Unix way then,(just avoid turing complete config languages).

After coding for several years, the two aren't all that different. I'm not saying that I think that the UNIX WAY is ever going to go away...but I do think that extreme scale makes the programmatic approach to configuration make more sense. Instead of treating every system as a "system" you treat it as a simple programmable node among thousands of others. You are already starting to see Linux go this way with systemD.…

That's quite the most carefully hedged "please don't kill me" comment I've read in a long time :)

I suspect there's a scaling issue in here as well. Tools optimised for large numbers of systems are always going to look clunky and overdesigned when used on a single system.

With regard to APIs, I think this is one area where the availability of source is quite critical. "Control Panel" is clearly a tool that manipulates some API, as are all the snap-ins, but because I can't see the source

(I recently had to fix a WinCE issue by trawling the source to find the right registry key. While Windows has a power user community, WinCE really doesn't, and is subtly different in enough places to cause problems. Google sometimes makes me feel like I'm the only person using CE 7)

Re: Looking Forward: Support for Secure Shell

#365

Earlier quoted context omitted.

How can two lines of code be earning you shit tons of cash? Can you show it if you swapped out specific details with generic placeholders (which page you're parsing, which endpoint you're hitting)?

It merely exploits some fundamental differences on how humans operate between two markets and turns that into real-time information for me on which I can make trade decisions. This isn't stocks, shares, futures etc for ref either. I don't want to say any more nor post any code as it's unique and a good earner at the moment.

> It merely exploits some fundamental differences on how humans operate between two markets and turns that into real-time information for me on which I can make trade decisions

Let me guess: arbitrage applied to sports gambling. Wink my way if I'm on the right track.

Re: Looking Forward: Support for Secure Shell

#366

Earlier quoted context omitted.

Couldn't agree more. As a die hard Unix guy and ex Slashdot-esque zealot (colloquially a bit of a twat). Yet I'm knocking out PowerShell all the time now and dread having to log into the pile of CentOS kit I have lying around. It is arcane. Even after 15 years I spend most of my time in the manpages or working out another damn config format. Literally did a two liner to scrape a web page, parse it and call a REST end…

> Literally did a two liner to scrape a web page, parse it and call a REST endpoint with the parsed data as JSON in PowerShell. This sounds cool. Can you recommend terse resources for getting to know PowerShell? Is MSDN the best place to look for docs or are there better places to go?

Powershell in Depth is the best book about PS there is:

http://www.manning.com/jones6/

Re: Looking Forward: Support for Secure Shell

#367

Earlier quoted context omitted.

From what I know, you can use Microsoft RPC to pull event logs or you can install a syslog forwarder, or you can do a combination of these two things (have a Windows syslog forwarder that is not a DC that can pull logs from a DC through RPC). The problem with the last option is, adding another Windows server costs an additional license. Installing a client on the DC doesn't. And there are limitations, so in a huge Wi…

Secureworks was the vendor I was referring to... Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller. Its not just RPC. That's the thing I've noticed about a lot of security people... they don't even really pretend to take windows seriously despite its insanely large f…

>Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller.

You'd be surprised at how many organizations will have the management spend $1.5m on a SIEM but the engineers refuse to use another Windows license.

There are ways to collect Windows logs. It's just not as easy as collecting syslog. And syslog doesn't need a user account to collect logs.

Re: Looking Forward: Support for Secure Shell

#369
post #186
post #106

Earlier quoted context omitted.

Powershell doesn't support interactive console apps (those that want user input), so it's really not much of a cmd.exe replacement. http://powershell.com/cs/blogs/tips/archive/2012/12/12/block...

To be clear - the ISE (powershell_ise.exe) doesn't support interactive console apps. powershell.exe supports them just fine.

Yes I see you are right, thanks for the clarification. The base Powershell.exe with a better window wrapper like cmdr actually should make a nice combination.

It's really too bad the limitation on the nicer ISE though. It does make a bad first impression coming from Linux, when trying to compile and run a simple interactive console app, trying to use ISE as a cmd.exe replacement.

Re: Looking Forward: Support for Secure Shell

#370
post #347
post #321

Earlier quoted context omitted.

> They could do more, sure, but I never felt like they were getting in the way. If you would try to ship OpenGL game you'll find out that Windows 8+ shipped with crippled AMD Legacy driver (HD2XXX-4XXX) that don't have OpenGL support in it and can't be really replaced using AMD Catalyst installer until user manually install new driver via Device Manager using extremely tricky way. There was also crippled Intel driver…

You'd have to take that up with the hardware manufacturers, I guess. It's not like Microsoft writes said drivers and if AMD chooses to submit a DirectX-only driver for inclusion in the OS then where's MS's fault?

Actually, drivers when you're talking about companies like these are developed with Microsoft involved nearly every step of the way. If they cared about OpenGL on Windows, it would've been avoided quite likely.
Post reply on HN