Chris Game said:
So what's the advantage over, say, Cygwin?
Well, I don't want to get into a competitive analysis (debate?) of SUA vs
Cygwin
They are both useful tools and users should use either of them,
if they meet the specific requirements for a project. But, some "features"
of SUA:
- it's a single-vendor solution, supported by Microsoft. That probably won't
affect individual users, but would be an important consideration for
enterprise customers who may have Premier Support agreements with Microsoft,
not to mention SLAs, formal IT mamangement methodologies, etc.
- performance. This will depend on the specific scenario; but generally, SUA
will be faster than Cygwin. The SUA Subsystem sits directly on top of the NT
Kernel; whereas Cygwin is a Win32 application. Cygwin tools call into
Cygwin.DLL which calls into Win32 subsystem which calls into the NT kernel.
- high degree of POSIX conformance. SUA fully implements POSIX 1003.1 2001.
As a rough generalisation, there's a better chance most packages will build
on SUA than on Cygwin (although this could be debated with example and
counter-example).
- no GPL. Whther this is an advantage or a liability, depends on your
situation
You can always add a GPL to your SUA source code, if you wish.
- in the past Services for Unix (SUA's predecessor) also provided a range of
useful Unix interop tools like NFS, NIS and Pluggable Authentication
Modules. These features are now standard in Windows Server anyway, so a bit
moot.
The biggest *disadvantage* of SUA is that no X Server is included. I
believe Microsoft did not want to offend the X Server vendors by trampling
on their market (incredible but true). So you need to supply a 3rd party X
Server.
I guess the main thing is that SUA is the "normal", default, Unix-like
facility supplied as part of Windows. Why use a third party add-on, when you
can just use something which is built-in to Windows? But, as I say: if you
like Cygwin and it works well for you, then by all means, keep on using it.
