Slashdot Mirror
Windows Services For Unix Now Free Of Charge
pole writes "Version 3.5 of Services for Unix will be free. Previously, it was $99. This article at Information Week has the details. It contains an NFS client and server in addition to POSIX libraries and utilities including pthreads. Aside from the NFS utilities, how does the environment compare to Cygwin?" An anonymous reader adds links to coverage at News.com and at geek.com, writing "The reviews for these tools have been highly favorable. It looks like the next volley has been fired in the struggle between Windows and Linux."
They include gcc, but most of the other utilities are from OpenBSD or other non-GPL sources (there are about 40 different licenses included). ActiveState perl is also included, though you can get that free anyhow.
Do you even lift?
These aren't the 'roids you're looking for.
I guess it depends on what you use it for. But as I have to do development work in Windows, I thought I'd try it out. Searching through the million line source tree our company has took about 10 times as long with 'grep' that came with "Services for UNIX" as it did with 'grep' that came with a now ancient version of MKS. Both of these were slower that current GNU grep on a Linux box, but the difference between GNU and MKS grep is not dramatic.
The lesson stays, however. If you expect to basically start with all the power of your Linux box, you'll be sorely dissappointed, just as someone expected the ease of use of Windows coming to Linux will be sorely dissappointed.
I really can't remember any glitches using it for 2+ years against Solaris 2.6 boxes.
Microsoft based this product upon OpenBSD: http://www.deadly.org/article.php3?sid=20030927090 008
This was speculated on in an article at Groklaw, that this was the intent (aside from financing the anti-Linux FUD campaign) in M$ paying SCO for a license.
Any technology distinguishable from magic is insufficiently advanced. - Geek's corollary to Clarke's law
Interix used OpenBSD as is evidenced at deadly.org
So like 95% of it is just OpenBSD, mostly pulled from theh 3.0 release tree.
http://tinyurl.com/4ny52
As you can see.
1) WSFU is faster (IO/API/...)
2) WSFU is better integrated with win32 architecture (OLE/ODBC/...)
3) WSFU make a lot of things easier than cygwin with windows
BUT, i wouldnt trade cygwin for it, note that i have both installed here. I just isolated what i needed from WSFU and was better than cygwin and added them last in my path. I dont have any preferences, but cygwin is waaay more complete, and you have the +/- the same versions of the application that runs on linux. Same config files work fine, same behaviours (which isnt the case with WSFU), etc.
For me, WSFU is just a little + to cygwin.
-- search the web
Look again.
Operating System:
Microsoft Windows NT(R) Workstation 4.0, Windows NT Server 4.0 with Service Pack 6a or later, Windows 2000 Professional, Windows 2000 Server, Windows XP Professional, or Windows Server 2003
When you lose something irreplaceable, you don't mourn for the thing you lost, you mourn for yourself. - Harpo Marx
There's a more important architectual difference.
Cygwin is built on top of the Win32 APIs on top of the NT kernel core.
SFU is built straight on top of the core kernel; Win32 API variances (which have caused headaches for the Cygwin implementors of years) are no longer factored in.
Moreover, the core state information (such as process listings and various other things) come straight from the core. It is perfectly possible to send a SIGSTOP or a SIGKILL to Word.exe (a Win32 app) from the SFU universe and watch Word stop dead or die, respectively.
As well as NFS mounting and export capabilities, SFU also supports NIS and can do various user mappings between the Windows and Unix worlds.
Beware the default password set for some of these options.
Memo to self: no service that requires a password for security should be enabled by default with a standard initial passphrase.
I'm confused. Are you saying that Microsoft's POSIX layer has no multithreading? Because not only does the article say otherwise, but it says right there in the writeup:
... POSIX libraries and utilities including pthreads.
It contains
I've used both, SFU more extensively than Cygwin, though. SFU's NFS stuff is flaky. That's just the bottom line. I would much rather export shares to Windows clients with Samba than NFS. (I suppose it doesn't help that I'm not a big fan of NFS, either, but that's just full disclosure. It's the only thing I've seen that can reliably lock up a *nix machine. Now, of course, there are circumstances where you want this, but usually not.) Also, if you want all the features of their command line, you'll have to switch your Windows machine into a case-sensitive mode. It made me nervous to change something so fundamental to Windows. Maybe they'll fix that in this upcoming version; I dunno. On the other hand, using Cygwin is nice, but it's like a big tease. Most of it works like you want. It's just that if you're used to using Linux and ALL of it's tools, you're going to hit the wall pretty quick. (I just ran into this a couple weeks ago, and I've already forgotten what it was I was wanting.)
Acts 17:28, "For in Him we live, and move, and have our being."
By way of some background:
/net sort of mapping within the Interix/POSIX subsystem, which is nice but fairly slow (though I note that this was particularly apparent to me because I was working remotely over DSL; I suspect there was a fair amount of roundtripping).
/net and it might not handle symlinks nicely. I remember benchmarking a version of the software prior to it being integrated in SFU, and it was about 3x faster than Samba in a LAN setting. [Kind of a an informal metrics: I was compiling a large project with network-based sources.]
The NFS client as of 3.0 is an improvement over the prior version in that it transparently conveys perms and ownership (according to whatever mapping has been established). It has support for a
In general, however, I think that NFS client access by way of the Win32 subsystem (i.e., not in the Interix POSIX subsystem) is pretty fast, though you might lose some of the perms transparency and there is no
It will be interesting to see if the performance within the POSIX has improved with the new version (3.5).
Here's some features that would have excited me, but I didn't find in SFU.
As an example, you can change all registry entries pointing to a user's home directory by running
A Usenix technical conference paper describes the tools and a number of applications.#include "/dev/tty"