SUA Deprecated In Windows 8? 226
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.'"
Who uses that anyway? (Score:4, Informative)
Cygwin or UnxUtils [sourceforge.net] work great.
Re:Cygwin (Score:2, Informative)
How about this? http://www.redhat.com/services/custom/cygwin/
Re:Cygwin? (Score:4, Informative)
Have you ever actually tried to use Cygwin as a *nix-compatibility layer in a production environment. The word "kludge" doesn't seem to begin describe it.
Re:Cygwin (Score:4, Informative)
Reaching back a bit, I think the use was that it meant that Windows NT and successors could tick the "Posix compliant" tick box that was required by some (mainly publice sector) contracts.
Perhaps Posix is no longer on so many checklists.
SUA vs Cygwin (Re:Cygwin) (Score:5, Informative)
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.
Re:Who uses that anyway? (Score:4, Informative)
Re:Cygwin (Score:4, Informative)
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.)
Yep, fork() on Interix (SUA) works much more efficiently. The NT kernel has supported what's essentially fork() since at least NT 4.0. The problem until Interix - and the reason why Cygwin's fork() sucks - is that the Win32 DLLs don't react well to being fork()ed. kernel32.dll gets confused, and simple things like console output stop working. Interix doesn't use the Win32 API, instead using a custom POSIX API and the NT API directly. The NT API has been updated to work in the event of a fork().
The NT API function NtCreateProcess [ntinternals.net] spawns a new process. The SectionHandle parameter takes a handle to the image section (IE, CreateFileMapping with SEC_IMAGE) representing the EXE you want the new process to run. If you pass NULL for SectionHandle, you will instead be creating a copy of the parent process's address space, the main part of fork().
Re:Cygwin (Score:4, Informative)
Look, I love Cygwin and have been using it since forever. But it's pretty slow at a lot of crucial operations, making it unsuitable for a large class of things folks use SUA for.
More importantly, it suffers from a serious lack of manpower and direction. For a project which is so vast and so important to open source, it has alarmingly few active maintainers. The lack of maintainers is made worse by the fact that a considerable amount of maintainer effort is duplicated between cygports and the official cygwin distribution.
Everybody uses cygwin but as far as I can tell very few people pay RH for cygwin support, and thus there are AFAIK only three people who are paid for their work on cygwin.
The lack of manpower really shows. Crucial packages go for long periods without important bugfixes, and new releases take a long time to get ported&integrated from upstream. Development on the cygwin core is fairly slow. NT-based versions of Windows offered quite considerable benefits over Win9x (lots of additional capabilities and much less of a mismatch with POSIX -> better security and performance), but the first version to really take advantage of these benefits was 1.7, released for Christmas 2009 [slashdot.org]- 7 years after the majority of users (much less the majority of technical users likely to use cygwin) had made the switch. The developers had their first serious discussion about the possibility of a 64-bit version of Cygwin in June of this year; it will likely be quite a while before a 64-bit version is released. A lot of cygwin's performance problems could be fixed if the core developers weren't already overburdened as it is.
Unless cygwin can attract a lot of new developers I don't think the project can stay up-to-date enough to continue to support the uses we all already rely on it for, much less be in a position to give SUA emigres a soft landing.