
Ask HN: How important is Posix? - jballanc
Today I found myself reading through accounts of the Microsoft keynote from CES, and while I'll admit they have some interesting ideas, I still found myself thoroughly unimpressed.<p>Now, I've worked with people who did or do work for Microsoft. A few (Open Source, interestingly enough) projects I've worked with have involved engineers at Microsoft. My general impression of the talent in Redmond is rather good, and yet I'm still completely turned off from Windows.<p>What it comes down to, for me, is the lack of out-of-the-box POSIX compliance as a first-class feature. The fact that I can't sit down at a machine running Windows, open a terminal, "cd /etc", "ls -F", "less &#60;your_favorite_config_file&#62;", and instantly know something about how the machine is configured bothers me.<p>Am I abnormal? I feel like Windows 8 could promise Unicorns and Rainbows; if it isn't POSIX compliant, I'm not interested...
======
arockwell
I think this has less to do with lack of POSIX compliance and more to do with
how unfriendly windows is to hacking in general. The command line is
completely crippled. If the command line had a similar feature set to Linux I
don't think POSIX complaince would matter much.

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

~~~
nradov
Can you clarify what features Windows PowerShell
[http://www.microsoft.com/windowsserver2003/technologies/mana...](http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx)
is missing compared to the shells typically used with Linux?

~~~
arockwell
Sorry I honestly can't, I've never heard of PowerShell, nor have I ever used
win 2003 server.

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.

~~~
nfg
Yes you can, powershell is available for both XP and Vista. Google it.

------
hapless
Windows has had a first party UNIX solution for a very long time: Microsoft
SFU/SUA. It's bundled with Windows 2003R2. On all earlier versions, you have
to go download SFU 3.5 separately.

<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.

~~~
iofthestorm
Wow, I was looking for this recently but didn't remember what it was called.
For me, Windows is good overall, and I'm a gamer, and I started on DOS so I'm
pretty command-line happy, but after using Linux/UNIX for personal use and
school I vastly prefer the _nix command line tools. I have Cygwin installed
and use that somewhat often, and I also have msys so I can use some_ nix
commands in the regular Windows prompt. What does SFU/SUA do that Cygwin/msys
don't? Speed is always nice but what do you mean by software compatibility?

~~~
hapless
UNIX software is not perfectly portable. Portable software is less likely to
run on niche systems. The fewer users that a particular platform has, the less
likely it is that portability issues particular to that platform have been
discovered and fixed.

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.

------
ken
Not very. Most Linux distros aren't POSIX (but oddballs like A/UX, Minix, and
VxWorks are). The /etc tree isn't in POSIX, nor is less(1). POSIX doesn't even
say that useful config data must be stored in text files.

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.

~~~
eru
There are standards. There just not called POSIX. For example the filesystem
hierarchy standard.

~~~
makecheck
Which by the way, is fully-documented here: <http://www.pathname.com/fhs/>

------
tptacek
Everyone I know that does dev work on Win32 just installs cygwin and runs an
xterm. It works fine. Personally, despite being a Unix user since 386bsd, I
think the Registry is a major win over the sprawl of incompatible picky config
files in /etc, /var, /usr/share, and /usr/local. I also think SVCHOST.EXE is a
win over inetd.conf and inittab.

~~~
old-gregg
Registry is the single major source of pain and the biggest security loophole,
because the registry is essentially a secondary/parallel file system with far
inferior performance, inferior security model and most of all, inferior built-
in tools to access it or keep an eye on. This partially explains why
adware/spyware _loves_ registry: registry for adware is what Tora-Bora was for
Taliban.

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.

~~~
tptacek
Well, security is all I do, and I think the superior security of the Unix
config model is a huge myth. And again: I'm a Unix person.

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.

~~~
old-gregg
Thomas, I'm debating the usefulness of registry as a centralized, binary
storage of system/application configuration and I'm much less interested in
yet another Windows vs Unix war.

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

~~~
tptacek
Because there was no API common to all Windows applications that reads and
writes structured key-value configuration, and without a central registry you
have to solve the chicken-and-egg problem of figuring out where to put your
configuration files in the first place. And, obviously, the registry predates
NTFS on mainstream Win32 platforms.

------
bayareaguy
I think it only matters for developers who work with mainstream open source.

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.

------
th0ma5
i thought windows' command.com was posix (some version) compliant? posix !=
unix compatible, per se, i don't think

~~~
DarkShikari
To quote a fellow developer on this topic:

<pengvado> that brings back the memory:

<pengvado> windows is posix compliant

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

