Hacker News Reader

Comment by lessthunk | Hacker News Reader

why use MSFT in the first place? Really, it is 2015.

Because many of us have to deal with required software that only runs on Windows, and there is no current alternative. It's 2015 and the Microsoft ecosystem is still very strong.

Well at this point, with OSX and their shitty graphics drivers (and I mean so shitty you install Windows and perf goes up), if you want to do any GPU intensive application, Windows still dominants. DirectX >>> OpenGL (although I'm looking forward to vulkan).

Are the OS X drivers really that bad in comparison to the windows drivers? Instinctively, I have a hard time believing that if only because the Linux drivers are so much worse than the OS X ones. :(

The proprietary linux drivers are not worse than the OSX ones. Only the open source ones (for obvious reasons. They have less insight into how the device hardware is architected).

If OSX let hardware vendors write drivers for OSX, they would be in much better shape. But Apple OS internals are pretty much nonsense as far as I'm concerned.

What reason do you have to avoid Microsoft? its 2015. Their past is behind them.

Windows is still Windows. SSH support is a step in the right direction, but they've got a mountain to climb:

* The Registry. * Drive letters and associated anachronisms. * A sane service manager. * The Windows API in general.

Aah, the registry. Isn't it nice not having everything in a MySQL database with a PHP interface which regenerates configure files over your hand edited hanged? Or GUIs like network manager that make config files that can't be edited because they can't track manual edits?

A registry which gives a central place for configuration and enables group policies and central management?

A registry which allows ACLs on individual keys and sub trees, not just at the level of files.

A registry which has some notion of types.

Isn't it also nice that MS moved on a bit from the notion of drive letters with powershell providers, allowing you to console edit registry locations, active directory OUs, certificate service paths, and whatever you want in a FUSE style pluggable way, while keeping the usefulness of drive letters and unc paths and not trying to pretend a network drive is a subset of / on a local computer.

Linux environments don't even have a stable place to put SSL certificates or a stable format for them. Packages might use individual files, or a single concatenated file, or a Mozilla NSS database, might look in somewhere in /etc or need their own path configuring.

It's a mess, even if it was standard and all the files were base64 text versions, it would still be useless for human editing with text tools because humans can't process big chunks of base64 usefully. A certificate store and a PSdrive provider for it. Neat.

There are some things that have better standardization in Windows, but for every thing they get right, there's a half dozen that are horribly, horribly wrong.

They need to start setting fire to legacy "features" and moving into the future. Windows is great because of backwards compatibility, but it's also hobbled because of it.

Unless they want to be an OS for organizations that fear change and upgrade slowly, reluctantly, then they'll need to start cutting some of that baggage loose.

Let's just parse and pray in bash, like it's 1989.

"parse-and-pray" is a problem that only exists in the imaginations of Windows programmers.

Way to not ad-hominem, dude.

Not sure what you are getting at, there's no ad hominem involved. Windows commands have noisy output, so people who are only familiar with Windows anticipate that Unix users would have the same problems that they would, which simply isn't the case.

Well, if it's a problem which Windows programers have, then it's not in their imagination, right? But that's nitpicking.

The original article is about Powershell. So I could, for example, say that people who are only familiar with bash (etc.) wouldn't know that Powershell doesn't pipe text, but rather .NET objects. Hence one could go and do something awesome like

    > ps | where { $_.PM -gt 10240 } | sort PM -Descending

... and get all the running processes that take up more than 10MB of physical memory and are neatly sorted by one of the columns. And not even once did I grep.

Your argument is basically that Unix is better, because Unix shells aren't CMD.EXE, which is absolutely true.

Shockingly, Powershell isn't CMD.EXE also.

I may have erred on the exact name of the logical fallacy, but it doesn't mean that there is no fallacy: valid views discarded based on the blind assumption of Unix's infallibility. Feels like it's 1999.

You said parse and pray in bash, don't be a jackass. Similarly, why even say that my argument is that Unix is better because it's not CMD.EXE when you know that's not remotely true, or that I assume Unix's infallibility (ridiculous). You're dishonest and not interested in a real discussion, so continue to enjoy your reinvented Smalltalk machine in peace (there's a reason nobody uses them even though they did more nifty tricks than Powershell ever dreamed of).

How could I be interested in any kind of discussion, when you don't care to see the difference between Unix and Unix shells?

And I don't see how you in anyway progressed the comparison of bash and Powershell with your comment. But go ahead, call me a jackass some more. Maybe that will help?

Reply on news.ycombinator.com