So between a crappy command line and the registry, hacking windows never seems worth the trouble.

Then MS delayed it, split Monad (renamed PowerShell) from the OS-that-is-now-Vista, and sat on the technology for a few more years before quietly launching it as an Exchange Server admin tool. Meanwhile, I found myself using IRb and IPython more and more, and never really got around to setting up that Windows box.

The early demos I saw had hopelessly long names, verbose syntax, and attempted to coalesce data into xml. While xml seems like a more flexible target than plain text, the net result was that it took a foreign set of tools to manipulate xml from one command's output to what the next command wanted.

In the spirit of "Get off of my lawn!": I wish that .vbs had been cultivated into a usable environment for interacting with the computer instead of left to be identified with malware. The language is/was certainly more appropriately sized for typical system automation tasks.

PowerShell is missing QWAN; The linux CLI is the same if you boot to it or boot to a GUI and open a terminal, or SSH in. It has a wide ecosystem of meta-apps which aid using the CLI such as screen and less, and it's been built up over the years with bash/readline keyboard shortcuts. Not to mention that lots of nix programs are CLI programs with GUI wrappers, or configured with text files you can edit in emacs/vim.

The Windows command line window is all there is (you can't boot to 'DOS' anymore, or SSH in without third party software - and if you do it's a different kind of experience). There's nothing much to do as most programs aren't CLI programs and aren't configured with text files and aren't scriptable and you don't really want to poke around in the registry if you have to be typing "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\..." or whatever. There are no emacs keyboard shortcuts and everything is shoved in folders with long names and capital letters and spaces and it's just not as good*. On top of that, PowerShell is a misleading name - since it's not really a shell, it's more like irb or the Python interactive interpreter. Sure you can "change directories" and such, but it's not really a bash competitor, not a shell in that sense.

But on paper, feature for feature? Who knows, they're probably quite close...

However, the most obvious feature its missing is I can't run it on xp or vista. Why do I need to run a server to have a decent shell? I find having a nice shell handy for various day to day development tasks.

edit: whoops, turns out I'm totally wrong, thanks nfg.

http://technet.microsoft.com/en-us/library/cc779522.aspx

It incurs no additional license cost. It's POSIX conformant. It comes with both GCC and an MSVC wrapper for use with traditional UNIX build tools.

In my experience, it's considerably faster than cygwin, but software compatibility isn't as good.

It has been my experience that one is more likely to find portability bugs in software when one tries to build it on Interix/SFU/SUA than when one attempts to build on Cygwin.

There are only two reasons to use SUA:

- Interix/SFU/SUA has the advantage that much of its system calls are implemented in a kernel driver, just like native system calls. Cygwin hits a userspace emulation layer for many calls, and that incurs a performance cost.

- Cygwin is third party. Interix/SFU/SUA comes from Microsoft.

- Interix/SFU/SUA includes some fairly useful NIS/NFS integration stuff. It's not great, but it's better than nothing.

Whether you choose SFU or Cygwin, UNIX software ported to a compatibility layer is generally more pleasant than native hosted software. ActivePerl and native Apache are just a pain in the ass compared to Cygwin/SFU's implementations.

It sounds like what you really mean is that you want Windows to be more like the other Unix-like systems you use. There's no standard for that.

Wide proliferation of various registry "cleaners" and "doctors" didn't happen without a reason.

Moreover, the way registry is used often calls for complex GUIs to configure/backup/restore anything, denying you a reasonable shot of simple automated scripting: a Windows application of average complexity usually consists of a mesh of various DLLs hooked up together via non-trivial pile of registry entries. Replicating non-trivial configuration of a Windows server onto a fresh box has never been easy, whereas on Linux it's never a problem to write a script for nearly everything.

This is why I also consider Gnome config (registry-like turd) to be a major, major issue: various "Gnome hacks" already painfully resemble Windows in their call for idiotic GUIs where I'm supposed to find some obscure branch in a big-ass tree and change some binary value from 1 to 0 just to disable something, as opposed to editing a simple, plain, sane ASCII file, preferably programmatically.

And finally, starting approx. 5 years ago I've noticed a change in tone in Microsoft's own MSDN documentation: slowly but steadily they're discouraging developers from using registry in favor of your own XML/text files in user's home directory to store application configuration, just compare configuration-related classes in MFC (old school) and .NET2+ (new way).

I have some issues with SVCHOST also but the registry issue alone should be enough for one post.

First, there are just as many places to backdoor on a Unix desktop (of comparable functionality) as there are in Windows. The difference is that there's one place to monitor and scan in Win32, and a zillion in Unix --- you literally can't know everything (or even 80%) of what you need to monitor in Unix.

Second, it's not as if the Unix permissions model is any more flexible than the Win32 model. If you can edit files in /etc, you own the box. If you can edit files in ~, you own the user. It's the same scenario in Win32.

Third, the reasons there are "cleaners" and "doctors" for Windows are twofold:

---- (1) Windows users have been sold the bill of goods that they need to keep their registries swept. Unix users don't give a shit. I have Evolution config files from 2000 in my homedir, on my Macbook.

---- (2) Windows users get a disproportionate share of all viruses and trojans, because Windows desktops are more than 90% of the outstanding population of hosts, and are nowhere near tapped out for attackers yet.

As for the rest of it:

* show me a registry subtree on Windows that you think is a bad example of sane, automatable, declarative configuration, and I'll find a comparably bad Unix configuration file.

* every enterprise in the world has a standard Win32 build/replication system that covers the registry, and most of the ones I've seen are homebrew, so all my evidence is that this is a solved problem. On the other hand, a lot of my clients don't have a well-managed automated Solaris build.

My previous post could be shorter: if you want a binary tree-like storage, it already exists and it's called the file system. Each OS has one, and it is standard, comes with a bunch of tools, is familiar to users. Thus I just don't get why Microsoft felt the need for implementing yet another proprietary FS (registry), especially when it's inferior to NTFS or Ext3 in every way, including security, reliability and performance. Perhaps it made sense in FAT/Win16 days.

But I hear you, good tools can be misused and bad ones can be improved upon

Maybe it is harder to notice a breach on Unix, but it is also correspondingly unlikely that the breach will affect all programs and make the system unusable. The closest thing to the frailty of the registry would be something like hacking /etc/ld.so.conf on a Unix system.

If the Unix root user is not enabled, especially for remote access, and assuming you don't have access to the physical device, then it's a question of which Unix accounts and groups you do have access to. Also, technically directory write permission is all that's needed to compromise a Unix file, so all files in the same directory are equally vulnerable. (Even this assumes base permissions and not ACLs, etc.)

Second, the registry is privileged the same way; write access to one part of the registry doesn't give you write access to all of it.

Third, it is notoriously hard to keep permissions straight on configuration files, especially when you're trying to manage multiple roles (for MySQL, qmail, and root, for instance). So most people screw it up.

But I mean, I don't think this is a huge problem. I just think I can knock down a lot of arguments about how the Win32 registry is an abomination. There's a lot not to like about it, but it isn't crazy.

A lot of the more core/necessary configuration files on UNIX have pretty detailed man pages and documentation also. Which is definitely more than you can say for keys in the Windows registry.

I hope I'm not perpetuating a meme ;-)

That's me most of the time and my switch from a dual-boot windows/linux configuration to an OSX laptop several years ago has saved me many hours (although I still have to work around odd OSX weirdness here or there but that is pretty easy to work out). I'm not likely to do Windows-only stuff anytime soon so I don't expect I'll be paying Microsoft anything until their POSIX support is superior to what OSX offers.

However if you're not a developer or if you and your customers mainly work with Microsoft-only proprietary stuff then POSIX won't really matter.

<pengvado> that brings back the memory:

<pengvado> windows is posix compliant

<pengvado> every single posix function returns ENOTIMPLEMENTED, which is one complying implementation :)

Short answer is no, it isn't.