Earlier quoted context omitted.
> Try this with Linux. Seriously. Sit down and do the equivalent: many servers in parallel On my phone so not going to type the full command line out ostensibly it would be: xargs ssh ‘ps process-name’ I’d need to pull the man pages up to double check which flags you’ve specifically requested. But the above is the general gist of it. —— I think it’s pointless to compare such granular features side by side though. For…
> But the above is the general gist of it. It's not even remotely the gist of it. The output of that is formatted (pretty-printed) text, not CSV. You won't know which computer the output came from. You can't use this output in any meaningful way. It's not useful to the business . ssh can't connect to multiple servers at once (other tools like multissh can). However, most such tools aren't designed for and aren't capa…
You can add all of that easily. Printing hostnames or turning text to CSV isnt a hard job on any computer. I was doing this in the 90s on Windows, years before Powershell. And on pre-OSX macs (think System 8 and 9) connected via AppleTalk. So modern Linux systems are clearly not going to struggle in that regard.
And you’re now just doing exactly what you criticised the author for: making up bullshit requirements based on what you’re familiar with and then using that as some lame excuse to call everything else garbage.
> ssh can't connect to multiple servers at once (other tools like multissh can). However, most such tools aren't designed for and aren't capable of scaling up to a thousand or more servers.
You’re making distinction that doesn’t exist. It doesn’t matter if you’re spinning up multiple SSH sessions from one program, or multiple programs each with a singular SSH session. It’s still the same number of outbound network connections (and likely same number of processes too).
What matters is how those connections are managed. And the code I exampled does run those connections in parallel.
> Windows PowerShell and WinRM can
Bash can. It just needs to call a process. Just as PowerShell is calling a process to do it.
Saying SSH cannot whereas Powershell can is comparing apples to oranges. SSH isn’t itself a shell, it’s a secure client/server protocol that allows you to run remote code inside a pseudo-TTY. Generally that would be a shell, but it doesn’t have to be.
(Source: I’ve written multiple shells for both Windows and Linux over the years)
> yet people like you just blindly dismiss it,
That’s not what I did. You’re now making assumptions about me. Ironically “blindly dismissing” my comments in the process.
> assuming that it "must" be worse than Unix/Linux,
I dont need to make assumptions. I have a hell of a lot of experience managing Windows systems. 25+ years in fact.
I’ve also written plenty of server side software for Windows too. And network enabled Windows malware (pre-NT4 college network. I mostly just used it to siphon off other peoples quotas from the college ISDN line. But it taught me enough to earn a career in IT)
> since everyone knows that Windows doesn't even have a shell!
Literally no one said that outside of the article.
Windows clearly has several shells: explorer.exe, cmd.exe, Powershell. Plus lots of frontends for remote services via RPC.
I also credited RDP as being excellent too.
> To quote the original article: "there was nothing to lean back on: no shell"
I’m not the author of that article so I don’t really understand why you’re using that to prove a point about my own ignorance.
> Windows has a shell, the author of the article just wasn't aware of its existence, let alone its comparative feature set.
We aren’t talking about the article though. We were talking about your generalised point that Windows is easier to administer than UNIX-like platforms.
If truth be told, I stopped reading the article after about 3 paragraphs because it was pretty obvious that it wasn’t a well thought out piece. But that doesn’t mean I agree with you any more than the author. You’re both at the extreme opposite ends of reality.