Ask HN: How important is Posix?
41 comments
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.
So between a crappy command line and the registry, hacking windows never seems worth the trouble.
When the Monad shell was announced (back in the days when Longhorn was going to have a database filesystem, uber-cool widgets, and unicorns that puked rainbows), I actually found myself seriously considering installing Windows on a machine again just to play with it. The idea of a command shell that could be extended in any CLR-hosted language, with pipes that supported structured objects, not just text streams, was pretty damn exciting.
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.
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.
It's just as well. Monad appears to suffer from severe second system effect ( http://en.wikipedia.org/wiki/Second-system_effect ).
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.
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.
The CLI is more than just the shell's capabilities. Microsoft expected people to use PowerShell with the same horrible cmd.exe, and ignore the multi-second startup times.
I completely agree. I thought that MS stripped every cool feature from Longhorn except for Aero.
Can you clarify what features Windows PowerShell http://www.microsoft.com/windowsserver2003/technologies/mana... is missing compared to the shells typically used with Linux?
To say that it's missing features is to imply that they could add features and then it would be as good. That's not the case I see, as a shell is little without the surrounding ecosystem, and Windows doesn't have it.
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...
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...
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.
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.
Yes you can, powershell is available for both XP and Vista. Google it.
I'm not a shell expert, but I wanted something unix like when work dictated that I would be on XP, so I downloaded Windows PS. Maybe I have an old machine, but it was sluggish, it didn't seem to share the same system environment variables to the point of annoyance.
...speaking of slow...
I just found out why my shell was so slow: http://blogs.msdn.com/powershell/archive/2007/11/08/update-g...
posix, it still doesn't support enough posix to make all the tools I use in linux natively available. so long as I need cygwin or msys for git, it won't be good enough.
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.
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.
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?
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.
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.
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.
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.
There are standards. There just not called POSIX. For example the filesystem hierarchy standard.
Which by the way, is fully-documented here:
http://www.pathname.com/fhs/
Yeah, my example wasn't the greatest. I'd have said SUSv03, but I didn't think as many people would be familiar. Also, my desire for POSIX extends beyond command line to basic programming APIs. The deficiency of Windows just seems most readily apparent on the command line.
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.
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.
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.
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.
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.
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
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
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.
Why are INI files deprecated in favor of the registry? - http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907...
If there is one place to monitor on Windows, that's a slight advantage. But, it wouldn't take many edits to that one place to cause permanent damage to the system (i.e. programs are now screwed up, you have to reinstall Windows; good luck).
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.
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.
I think the problem with this logic is that you're thinking about filenames and not credentials. There's one place to go to cripple a Windows box (a parallel filesystem), and there's one set of credentials you need to cripple a Unix box (the capability to write /etc, or /usr/share, or /usr/local/mysql, or ~/Library, or...).
I admit to not knowing how the Windows registry's various parts are protected. But individual files/directories can be protected separately on Unix-like systems (whether they are is another question).
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.)
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.)
First, taking OSX as an example desktop Unix (desktop Linux has the same problem), if you own my UID, you also own my ~/Library, and thus my account and arbitrary code execution under my credentials.
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.
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.
One thing that got in the way with the registry for me was that there's only 1 of them. You can't install 2 variants of anything that uses the registry, unless that thing uses the registry in a multi-tenant way (and a lot of things didn't).
This is an interesting perspective considering the trend these days for creating DSLs. That's really all those different and incompatible config file formats are. Everything old is new again.
The fact that Unix configuration files often resemble crappy programming languages is exactly the problem. Most configuration can and should be declarative.
Can you give an example? Things like the ISC dhcpd.conf are declarative, and the advantage that it "looks" like a programming language is that it's easy to read and see/form dependencies for complex setups--it's not just a big list of key/value pairs. That makes sense for a tool with a lot of capabilities. A quick glance at /etc doesn't reveal anything other than structured declarative files, key/value pairs, or delimited. There's a been a trend to use XML recently, which I find to be overly verbose for a configuration file, but even the XML-esque format that Apache uses is pretty much just a big list of key/value pairs.
sendmail.cf.
You got me there, isn't the sendmail cf syntax turing complete? Sendmail is one of the first things I remove if it gets installed by default. Got a more, for lack of a better word, "modern" example?
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.
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.
What? You mean all of your config files aren't s-expressions?
I hope I'm not perpetuating a meme ;-)
I hope I'm not perpetuating a meme ;-)
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.
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.
[deleted]
i thought windows' command.com was posix (some version) compliant? posix != unix compatible, per se, i don't think
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 :)
<pengvado> that brings back the memory:
<pengvado> windows is posix compliant
<pengvado> every single posix function returns ENOTIMPLEMENTED, which is one complying implementation :)
http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows
Short answer is no, it isn't.
Short answer is no, it isn't.
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.
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 <your_favorite_config_file>", and instantly know something about how the machine is configured bothers me.
Am I abnormal? I feel like Windows 8 could promise Unicorns and Rainbows; if it isn't POSIX compliant, I'm not interested...