Slashdot Mirror
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.'"
I guess they want to come out with a new "metro"-version.
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).
Cygwin or UnxUtils work great.
Give me Classic Slashdot or give me death!
Well, I actually failed to find a project that would really depend on SUA. Anyone knows about anything that would be harmed by this change?
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.
How about this? http://www.redhat.com/services/custom/cygwin/
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
This is how it is with microsoft. You cant rely on ANYthing from them - they can just shut down or bail out on you (bcentral, silverlight, soon .net), and you will have to spend a lot of time and funds to go around the pain they cause you.
Read radical news here
Commercial customers that require production-quality platforms with enterprise-level support are probably already using *nix.
Jesus, did you even read TFS? "WARNING: SUA is deprecated starting with this release and will be completely removed in the next release." Or do you not trust what Microsoft themselves tells you about their products (hmmm, can I get back to you on that one ...)?
a full blown unix VM
That's the key right there. With virtualization software in the state that it is now, why would you run POSIX applications shoe-horned into windows, when you can have a proper POSIX system running in a VM.
SUA was once called SFU (Services For UNIX), and it replaces the built-in POSIX subsystem which has been an integral part of NT since NT 3.1.
The built-in POSIX subsystem alone was basically useless as shipped, since it came without many command line utilities, but SFU (now SUA) upgraded it to a more or less useful configuration, including a series of commands built to use the API; in some ways it accomplished the same thing as Cygwin, but in a different way.
In my opinion, Cygwin is vastly better since it contains more utilities, is more aggressively maintained and updates are more frequent.
"No matter how cynical you get, it is impossible to keep up." -- Lily Tomlin
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
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.
The problem is that VMs consequently bring an isolation level that doesn't allow you, for example, to work at the native filesystem. You cannot easily grep something in your "My Documents" folder, as far as I know and, even if you can, you'll be consuming way more resources than needed, which may bring consequences as bigger execution times. They're a great solution for a lot of problems, though, don't get me wrong.
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.)
What FUD? This is an actual story about actual facts involving MS. That is NOT FUD.
What Fear? What uncertainty? what doubt?
The Kruger Dunning explains most post on
They've killed it by only supporting the features necessary to re-share existing NFS services using SMB and AD. Integration of Windows with non-AD LDAP and Kerberos is virtually non-existent and requires a ton of work and 3rd party utilities to get it working. I don't think NFSv4 is even supported.
Custom electronics and digital signage for your business: www.evcircuits.com
"Should be a rule that you dont' create a model that depends on Microsoft."
If you make an application that runs on Windows, then it depends on MS. How many people had their Netscape installations disabled by MS updates of IE? How many application vendors were unable to compete because MS was the only one with access to undocumented APIs? You do remember that the DOJ eventually found them guilty of unfair trade practices because of these tactics.
Or what about workalike operating systems like DR-DOS. MS applications had explicit code to disable them if the user tried to run them under a competing vendor's OS.
"All of the above would have happened without Microsoft's sabotage. I'm far from denying that any of the sabotage happened. I'm just saying that it wasn't very consequential. It was just stupid and immature in my view."
Yes, your honor, I shot those people and they died. It's OK though, because they were weak and they would have died anyway. I didn't murder them. They committed suicide.
MS should be shut down completely. Their unfair trade practices have taken a huge toll on both consumers and vendors. Now that they have completed their "slap on the wrist" sentence, they're right back out there, as bold as ever, mugging everyone they can.
The installer for Cygwin is extremely simple and intuitive to use, andmakes remote, unattended installs a breeze,so you'll have no difficulties there.
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.
...Which can be seen by viewing SUA based process in Windows's Task Manager.
Do this:
1. Install SUA
2. Run KSH (the command line shell that SUA installs)
3. Open Task Manager
4. Change the columns so that 'command line' is showing.
You will notice that the SUA processes have _wrong_ (corrupted?) information displayed. This is based on the fact SUA is a different _subsystem_ and stores process based information (specifically, command line information) in memory in a _different_ format than the _Win32_ subsystem.
So when a Win32 process tries to access a SUA process...and there's no checking for a process' system type...
Troll much? But let's take a refresher course, ten years later.
1-800-what-model-is-that? I worked in the 1980s on Chinese, Japanese, and Korean input methods. CJK input was a time-limited product, completely dependent on Microsoft, so of course we got eaten when they folded CJK fonts and IME into the operating system.
Your sentiment really pissed me off, because a lot of people gave blood to bring Microsoft down a peg or two in the 1990s so that in this day and age young people might suppose you actually know what you're talking about (other models existing, as they do now) when you spout nonsense like that.
Watcom C/C++ was a superior compiler, but it got eaten alive by Visual C++, a product which set the C++ language back by almost five years by pretending to support standard features, but then only implemented namespaces one level deep, and cutting ever other corner in the template system a harried reviewer would miss on the first day (that was policy in all of their development plans).
It was as if Visual C++ promised support for K&R C 100% except that nesting of curly braces was only permitted in main(). Nesting braces aren't very important, there are work-arounds. We'll get to it in a future release. Meanwhile: 1) Put your entire program in main(); Cry baby. 2) the comma operator is your friend; 3) assign variables within the expression of first use; 4) write your program in FORTH and cross-compile; achieve code re-use through the use of the #define facility; use VBASIC instead, it has no pretense to scale, and can't hurt you.
Until Microsoft, nobody dreamed what you could do with the CPP in a pinch. If Google Code had existed in the late nineties, #ifdef _MSC_VER would have made the Google Zeitgeist.
There's no denying the colossal stupidity of many of Microsoft's main competitors. I've even read comments by Microsoft execs who basically said "we were amazed to watch our competitors blow themselves up". So true.
They never said that about Netscape. But what's one set of Nixon tapes among friends, anyhow, or forged video tapes submitted to the U.S. Justice Department?
You need to bone up on game theory. After destroying a well-managed competitor funded on a world record IPO through a multitude of dirty tricks, a lot of smart people wandered around in a daze dialing 1-800-what-model-is-that?
Top three fatal flaws in a 1990s era business model if your potential competitor was Microsoft:
1. Revenue
2. Market share
3. Profit
I recall it was the shops who were most dependent on Microsoft who made out best. Visio was an extremely well behaved ISV and they were ultimately rewarded for their OLE monstrosity. Is that what you had in mind? The independence of toady-hood?
I have never seen one instance of this actually being used in any environment from small up to very large enterprise.
That's the key right there. With virtualization software in the state that it is now, why would you run POSIX applications shoe-horned into windows, when you can have a proper POSIX system running in a VM.
I agree that SUA is pretty bad, but running Cygwin allows me to run commands like:
sort -o /dev/clipboard /dev/clipboard
This sorts the data on the Windows clipboard. Having the whole *nix user land plus access to Windows features/drives/data makes the command line in Windows much less painful than before. A VM won't really solve that.
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 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().
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
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- 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.
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.
But Unix-like stuff itself is not tolerable, which is why it has to be reimplemented with GNU, Linux, Cygwin and other free software.
For instance, how does the vi editor in MKS stack up to Vim? If the following link gives a more or less complete manual, it's freaking pitiful:
http://www.mkssoftware.com/docs/man1/vi.1.asp
Why would I pay money for that stuff if I would end up compiling GNU coreutils, bash, and other packages?
> Win 8 - it's gonna suck, right?
Yep. It's inevitable. I think the even/odd thing is that in release (a) we try new stuff, and in release (b) we fix/withdraw it, and then in release (c) we try new stuff again, so it tends to devolve into even=suck odd=less_suck. Or the other way around, depending on if they start at "1" or "0".
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
I thought it was being replaced with STFU... to truly tell the users how they feel. ;)
Of course, there's also the new service used for background downloading images called "NSFW" that was planned for Metro.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
You can map a VM drive to a user folder and tell Windows (quite easily now) to store your documents on that drive.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
All I really use Cygwin for is a bash script interpreter. It's done a fine job of that, though it does take an abominable amount of time to start a console window.
It lets me write cross-platform database installation scripts for *nix and Windows, but to be honest, that's about all the use I have for it at this time.
I haven't even bothered updating the install in over a year. Why bother? It works.
I do not fail; I succeed at finding out what does not work.