SUA Deprecated In Windows 8?
An anonymous reader writes "I just tried to install Subsystem for UNIX-based Applications (SUA) on Windows 8 Preview and found that it's marked as DEPRECATED: 'Subsystem for UNIX-based Applications (SUA) is a source-compatibility subsystem for compiling and running custom UNIX-based applications and scripts on a computer running Windows operating system. WARNING: SUA is deprecated starting with this release and will be completely removed in the next release. You should begin planning now to employ alternate methods for any applications, code, or usage that depend on this feature.'"
Why would someone use SUA, which is only contains very old versions of the software it bundles? There is Cygwin, which is a much much better alternative. Sometimes, even MinGW is a valid alternative because it generates a native application (though it requires some porting effort, which may be unacceptable in many cases).
Or maybe no one is using it, and its not worth the support headaches. As others have, and will continue to suggest throughout the comments in this article, cygwin, mingwsys, UnxUtils or even a full blown unix VM are fine substitutes for SUA. Now, if you are actually using SUA in production, and this negatively effects you, that would be interesting to hear about.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
Is this a shock to anyone after The Week of Windows 8 Hype? If there was a theme running through all of the stories it was this: Windows as you have known it is deprecated, a traditional Windows desktop will be available (certainly on x86, perhaps on arm) for those who are determined enough to figure out how to reenable it but don't expect it to last much longer. If Windows and native Win32 executables themselves are on the chopping block why would they have any interest in maintaining a UNIX command line layer?
Win32 (and UNIX more so) isn't going to lend itself to the sort of app store lockdown Microsoft is moving to. If you have a choice of buy Win32 apps/games at Walmart/Gamestop and Microsoft gets no taste of the action or buy everything at the App Store and give Microsoft 30%, which do you think they are going to 'nudge' you toward? And by 'nudge' I mean turn your PC into an iPhone with hard crypto locks and remove all options that do not let them rake off their 30 points.
Democrat delenda est
If you look at the kind of work Microsoft has put into the Linux kernel recently relating to Hyper-V...
https://lwn.net/Articles/451243/
One might gather that it's not worth the trouble for NT to ape Unix anymore. Chances are pretty good Linux is the new SUA and virtualization will be the new supported solution to this problem. I mean, why should Microsoft bother maintaining its own Unix tools when they're actively maintained elsewhere? Given the work they've done on both virtualization and linux integration I would say that there's no great conspiracy here.
So, many people keep wondering why use SUA vs Cygwin?
Well, first off the basic thing is speed. SUA has kernel hooks for syscall translation. It's able to do many of the POSIX syscalls in a much quicker fashion than Cygwin. Cygwin, on the other hand, does *everything* for POSIX syscalls in userland, causing it to be slow (for example, a fork, at times can take *seconds* to complete).
So, SUA is much better this way... problem is, it's tricky to get things to compile for it, I never did get things building reliably for it. Cygwin has a full suite of programs already built, and it's much easier to build existing Linux/UNIX/POSIX programs for than SUA.
Being a Windows user who needs *NIX tools for many processing tasks, what do I use? Cygwin. Easier to set up and get running. The speed drives me insane, though. My login script, which runs many programs before bringing up my bash prompt will take 5-6 seconds.
Ideal solution: Hyper-V or some other VM software running a VM in the background that I can get a terminal to, that has filesystem access to my system drives too.
It's not Cygwin. It's an implementation of the POSIX APIs that goes directly to the NT APIs instead of through Win32.
I can't comment much on the tradeoffs except to say that I think it solves the problem of Cygwin's fork() being terrible. (SUA also provides a route to get multiple files with the same case-folded name but different case-sensitive names, which I don't think you can do with Cygwin since it goes through the Win32 API.)
100% agreed. The commercial alternative - MKS Toolkit - integrates seamlessly with Windows, and is both more complete and faster than Cygin. Yes, it costs money, and no, it is not open source - but if you need to do Unix-like stuff on Windows, it actually makes life tolerable.