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.
I was wondering the same thing. What's the use of this SUA thingy?
"When information is power, privacy is freedom" - Jah-Wren Ryel
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!
I think Cygnus Solutions solved your problem about 20 years ago.
Do you have a credible source stating that it will be removed in the next release? Deprecated usually means that the functionality is being replaced by something new. Your warning for people to make plans for alternate methods seems premature.
Honestly it makes sense to drop support for SUA. Stay native on their own homegrown stuff and let people who need it run full-on linux in Hyper-V.
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?
Commercial customers that require production-quality platforms with enterprise-level support probably will avoid Cygwin.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
Don't worry, UEFI will make sure that's not a solution for much longer...
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/
Except Cygwin was perfectly in enterprise shops I worked in but they were just small shops like Sabre.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
I've never heard of it either. It's prolly Cygwin.
Licenses? cygwin is GPL last time I checked.
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.
We opened a case with Microsoft awhile back regarding this issue. A high level manager called us back and begged us to find another (non-Microsoft) solution. The team is going away and soon.
I don't think so. Even if that is attempted it isn't hardware, it's firmware. Firmware can be updated.
Other than the LDAP extensions SFU/SUA added to the active directory what else was really used from it? It seemed to me that anything else you would use from it would be better handled with a real UNIX or Linux install, either on it's own box or in a VM.
"I use a Mac because I'm just better than you are."
Are you implying that it actually matters or is in any way an "evil" activity?
This stuff isn't used that much anymore on Windows. If the usage isn't there, why continue to support it?
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
But they make it so easy.
Yeah, no one uses it because it never worked well anyway. I've tried a few different versions in the past. Every time after installing it, I'd get frequent BSODs. They went away when I removed it.
If you're bitching about Outlook Web Access, try setting your cookies to a non-paranoid mode. Works perfectly fine in Firefox with normal cookies.
Trying to become famous by taking photos. Visit my homepage please.
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
SUA/SFU/Interix includes some gpl software (gcc, for example).
Do you even lift?
These aren't the 'roids you're looking for.
Yup. My guess is that the person who had issues with OWA and Firefox was using excessively aggressive privacy settings.
retrorocket.o not found, launch anyway?
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.
That post was nice and dramatic and everything, but SUA was a piece of shit that nobody used anyway. If you need to run POSIX applications on Windows there are ways to do it that don't suck. "Hegemony," "rise to power," give me a fucking break dude.
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.
I think that's the whole point of UEFI...that the firmware can't be changed (at least not easily).
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.
I think this is yet another indication that SUA is pants and everyone should be using Cygwin.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.
SUA was once called SFU, which has been replacing STFW (and STFW's predecessor, RTFM) for years now.
It is dangerous to be right when the government is wrong.
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.)
It's the constant drumbeat of uninformed speculation that gets me worn out. Pandering to leet k3wlness rather than fact-based criticism.
The FACTS are probably nothing like what's being asserted here.
One day I feel I'm ahead of the wheel / the next it's rolling over me / I can get back on / I can get back on
I don't think so. Even if that is attempted it isn't hardware, it's firmware. Firmware can be updated.
UEFI cannot be user-updated, that is its whole security model. You can bring it in to Dell and ask them to install Grub on it though, I'm sure.
It is dangerous to be right when the government is wrong.
With software in the state that it is now, why would you run shoe-horned windows, when you can have a proper POSIX system running on your computer?
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
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
Y+Us e missed the point. They are cutting out something people use, and doing it rather quickly.
The fact that it may be a PoS is irrelevant. This is quick even for MS. Deprecated, and then removed in the next release candidate of the same version? Yeah, that's just crappy.
The Kruger Dunning explains most post on
I have another issue with OWA, the version for alternate browsers is a lot different
from the one presented to IE users.
You can't even access certain mail folders
Windows-only shops may tolerate you insisting on SUA, because it's a Microsoft product.
Start talking about CygWin or VMs and their eyes glaze over, they suck their thumbs, and moan "Wasn't on my MCSE, hippies will eat me, wasn't on my MCSE, hippies will eat me."
I know that there's not really any significant difference in support terms (other than not getting the flakey almost-POSIX and BSODs that continue to burden SUA), and that they'd be better off switching to a native POSIX environment anyway, but the man with the ear of the man with the money doesn't want his "skill" set to be devalued overnight. And that's why SUA still has (had) a place.
If you were blocking sigs, you wouldn't have to read this.
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
OWA for Exchange 2010 works much better in Firefox than it does in IE6.
Mainly because SUA is faster, since there's no translation to Win32 - it sits directly on top of the kernel.
DR-DOS, Wordperfect, Ami pro count as direct sabotage in modifying their code to break competitors products. But it could certainly be argued that the entire "embrace, extend, extinguish" plan is ultimately a form of technical sabotage. Their executives emails have specifically mentioned causing competitors products to crash as a primary goal in defeating them. How can you say it wasn't consequential when it is coming from the very top of the company? I agree the sabotage probably wasn't necessary to gain market dominance, but it does demonstrate the complete lack of business ethics.
This is quick even for MS. Deprecated, and then removed in the next release candidate of the same version?
It is quick, but not that quick. Where does it say that it'll be removed in the next release candidate? TFS speaks of "release"; this normally actually means RTM (as in, not a prerelease).
Or is it odd numbered? But like Star Trek movies, every other version of Windows (desktop) is crap:
Win95 - meh
Win98 - not too shabby
WinME - oh my god, no!
Win XP - not half bad
Win Vista - 'nuff sed
Win 7 - okay
Win 8 - it's gonna suck, right?
"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.
why support something that your new os's 'made for' or 'works with' branding program is designed to kill?
The installer for Cygwin is extremely simple and intuitive to use, andmakes remote, unattended installs a breeze,so you'll have no difficulties there.
...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...
photo shop / the adobe CS pack is a big windows and mac app that will not work good with a touch based ui (maybe for a photo shop light), also it has lot's of 3rd party plug ins' (I hear that the MS app store is more open to that then the apple one). Also big screens and dual or more helps with it as well.
AutoCAD is a other high end app that needs a good input, good CPU + GPU, big screen / dual or more screens and there even high end mouses for it http://www.chipchick.com/2007/08/spacepilot_makes_life_easier_for_for_3d_modellers_and_cad_artists.html
Now a touch screen for input (only) for AutoCAD / Photo Shop may work but when it is off to the side and not part of the main screen.
I say if MS fails adobe CS and AutoCAD for Linux as apple is out due to the app store and apples lack of good hardware for Business like no real server. The mini server and mac pro server fail in many ways. Like no dual nic's in the mini. Lack of hot swap hdd's in both and Lack of dual PSU in both.
Also apples desktop hardware is very over priced and the imac screen is not that good for pro work and the hard to get to (vs all other pc systems) HDD in the imac and mini is a no no for some Business. Now the mac pro will be nice at $1000-$1500 with be more up to date come on 1TB HDD and 3 GB RAM at $2500? Can build a i7 system (same cpu power) with more ram and a better video card for about $1000 or less or even get's dells for about $800-$1500 less then apples price.
Maybe when they want a simple ls to take less than 5 minutes to complete on directories with even a moderate number of files? Cygwin is horrible. It's slow, buggy, and in constant flux. I much prefer natively compiling with something like MinGW when I can get away with it.
I read the internet for the articles.
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.
DR-DOS, Wordperfect, Ami pro count as direct sabotage in modifying their code to break competitors products.
What a load of rubbish! A single beta version of Windows didn't work under DR-DOS. To that sounds like they are just eliminating bugs in the was DR-DOS runs Windows from distracting the developers who are trying to find bugs in their own code. Any version of Windows (pre-Win95) that could be purchased would run under DR-DOS.
WordPerfect killed themselves by resisting the move to WYSIWYG and a Windows version. When they finally did it, it was incredibly buggy. How is Microsoft responsible for that?
As for Ami Pro... I give up. What code did microsoft change to break Ami Pro? They did have a shared use of a filename extension, but that sort of thing happened all the time back then. Just because a program competes with a Microsoft product and then fails does not mean that it was due to Microsoft being evil.
Because it's a native subsystem on top of NT kernel as opposed to a windows subsystem dll. This means many things, but first and foremost, integration and access. The filesystem is presented perfectly, all the groups, users, environment, services are presented directly and in a true POSIX way. You get real sudo, real unix paths (/dev/fs/C/), case sensitivity, sticky bits, etc. Secondly, performance. I have installed and compiled applications for SUA, including apache, and it performs at native speed level. Lastly, you get a decent package manager. It also has a package manager. The only downside compared to the ugly hack of a Cygwin, is lack of packages. Anyway, you might not see the value in this native posix subsystem compared to Cygwin, but it exists for those who do, and it's sad that it won't be there.
VMware workstation running one of the many "live" distributions as a mountable .iso image.
I killed da wabbit -Elmer Fudd
I kinda wait for the Metro to arrive at the platform and Bob stepping out of it. (After all, that was their last try at a "non-technical" user interface.)
Parent might be a troll, but it's also somewhat true. Plenty of organizations out there unwilling or at least reluctant to deploy anything open source when there is a Microsoft-supported option. The bias in favor of propriety supported solutions remains even when the open source version is demonstrably better.
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 doubt telling people to "just use Linux" is a reasonable solution though. If it were that simple they wouldn't be bothering with SUA in the first place.
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
Everybody stupid enough to buy Windows 8 should have no truck with UN*X or Linux at all! Thank you, Bill!
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.
SUA was once called SFU, which has been replacing STFW (and STFW's predecessor, RTFM) for years now.
Rumor has it that Windows 8 deprecates SUA in favor of its newer, sexier replacement, OMGWTFBBQ.
You heard it here first.
I am not your blowing wind, I am the lightning.
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.
Commercial customers that require production-quality platforms with enterprise-level support probably will avoid Cygwin.
It would be astonishing if most such customers would not also avoid SUA like the plague.
wha? The idea here is people want to do exactly that - however, if it's hardware locked, that might not be an option for dual-boot.
> 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.
"Commercial customers that require production-quality platforms with enterprise-level support probably will avoid Cygwin"
I believe parent means "Posix Compliant", not that Cygwin is a piece of crap. FreeBSD uses the old cshell instead of bash by default so it can be posix compliant just as an example.
I do know many government contractors need to have Posix compliant on the paperwork and Windows fullfills this (but really not). Linux is not. Solaris is and I do not know if FreeBSD got the certification.
In this day and age though I do not think that is in the paperwork anymore so it is why SUA is being depreciated. The goal was to get government contractors to switch to win32 overtime.
http://saveie6.com/
Is there a real use for it on Windows? I am serious and not trying to be a troll.
The issue I see is that not everything is a file on Windows. Can I grep processes and threads? No. Can I awk, sed, and grep device driver files? No. Can I even parse logs? No, they are xml on Windows. etc.
Sure I can run gcc and maybe xclocks or something, but that is not usefull.
Can I do anything with it? Powershell seems much more integrated and you have .NET and WMI to automate some tasks. It still seems far behind Unix with the utilities though, but I am not an experienced Admin. Windows!= Unix.
http://saveie6.com/
There is a patch for Cygwin which gives it a huge speed improvement but it wasn't accepted because according to Christopher Faylor "The result is good but the patch isn't the way I chose to implement this." http://cygwin.com/ml/cygwin-patches/2011-q3/msg00030.html
Since version 1.7, Cygwin is able to make multiple files that differ only in letter casing. You need to make sure the filesystem is enabled for case-sensitivity though (this is also the case with SUA). See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive
Uh...no?
This is about SUA being booted out of the OS.
The other "issue" wasn't even hinted at by the commenters above you.
Honestly, if you're going to take a completely different track, start a new thread instead of trying to derail the current one?
Removing start menu shortcuts, C:\cygwin, HKLM\Software\Cygwin, and HKCU\Software\Cygwin is so super-hard, right?
Or why not just use Wubi and have a full functional Linux and call it a day? Either Wubi or CoLinux would give him the full Linux bash CLI, all the latest and greatest, and if he has permissions to install SUA then he can install CoLinux or Wubi.
I can see why MSFT is killing it, because in this age of even Sempron CPUs have virtualization support, and you having the choice of Wubi, CoLinux, or the VM of your choice, why would you use the ancient SUA? i bet to the user base for SUA can be counted in the dozens, it just wasn't popular to start with and certainly hasn't gotten more popular as its gotten outdated.
Just let it die already and use one of the modern Linux choices I listed above friend.
ACs don't waste your time replying, your posts are never seen by me.
For DR-DOS: Of course there was no reason for this. Brad Silverberg, the Microsoft exec who finally left the company last week, but who in an earlier life had been responsible for Windows 95, emailed Allchin on 27 September 1991: "after IBM announces support for dr-dos at comdex, it's a small step for them to also announce they will be selling netware lite, maybe sometime soon thereafter. but count on it. We don't know precisely what ibm is going to announce. my best hunch is that they will offer dr-dos as the preferred solution for 286, os 2 2.0 for 386. they will also probably continue to offer msdos at $165 (drdos for $99). drdos has problems running windows today, and I assume will have more problems in the future." Allchin replied: "You should make sure it has problems in the future. :-)", which is clear enough, and it should be noted that the pair were both high level Microsoft executives.
And you say a single beta was nothing, but making it non-functional on their system meant they couldn't do testing to ensure compatibility before release. It was specifically singled out as a technical glitch designed to sabotage their competition in trial, and was conclusively ruled anticompetitive and predatory by the judge.
For WordPerfect, MS supplied faulty API's for Wordperfect to use, while keeping their own hidden calls that actually worked. Windows updates actually broke Wordperfect and made it crash. Sure it is easy enough to assume it was just an unintended bug, but their trials revealed that top leadership was encouraging the engineers to break the system intentionally, which makes the "buggy" explanation a little more suspicious doesn't it?
Ami pro had a beta version of a dll. When using the final version of the dll, their program didn't work right. Again, maybe it was just a coincidence and mistake that they supplied yet another Word competitor with incomplete dll's. It sure seems like a pattern to me.
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.
IBM made $23B in software last year, so apparently they can do just a little bit of software marketing.
The SUA community has been hoping for a while now that Microsoft just open-sources the stack - everything about the NT kernel - and lets the community maintain it rather than actually killing it. Ideally they would open-source it but continue to maintain and update the code, but the truth is that SUA has gotten fairly little love since Vista came out. They add features and fix bugs, but slowly - 64-bit shared libraries from GCC has been in the works for a while, now. The Win7-update of Interix (the SUA "OS" environment) didn't ship until well after Win7 itself was generally available (although you can install Interix 6.0 on SUA 6.1 just fine).
It's actually really interesting what it does and doesn't have. It's available in 64-bit, including utilities, libraries, and build toolchain, but if you're running on 32-bit it still doesn't have the 64-bit extensions that enable things like working with files more than 4GB in size. There's still no support for clone(), which makes a lot of Linux source code not compile on Interix. There's no direct access to physical block devices, which means you can't use Unix disk utilities, and no audio support (though you can use a network-connected sound server that runs on Win32).
Open-sourcing SUA would allow people to fix many of these issues (seriously, how hard can block devices be? Map \\.\PhysicalDisk0 to /dev/sda, and you're much of the way). It would allow resolving the silly little issues, like the poll() implementation being half-baked and therefore requiring a portability library that implements it using select() instead.
Seriously, this is a win-win. MS doesn't have to support it anymore, the people who use it can continue using the MS version or the new community version (or modify the community version for their own purposes), those who want to tinker and hack on it can make improvements, and MS can get some good press for open-sourcing a (fairly low-level, even if rarely used) component of the NT software stack.
There's no place I could be, since I've found Serenity...
While on the face of it, it was an ego thing that they were smart enough to have this compatibility layer. Then when I looked deeper, it turned out they had a bridge between active directory and NIS. But looking even deeper, it only worked with AD as the master and NIS in slave mode. Why am I not surprised. So if you basically had a Unix shop, and was using NIS, you could still consolidate credentials for both the Unix world and the Windows world, but only by making Windows the big dog. Again why am I not surprised?
I've never heard of it either. It's prolly Cygwin.
OK, my turn to make a stupid guess, I think it's...a pink pony!
Clown.
To have a right to do a thing is not at all the same as to be right in doing it
Just never seen or heard of an installation. Every Windows shop I went, when they wanted a UNIX tool they either used a Windows port of it or installed a *NIX machine.
And Microsoft makes more per samsung android handset than Google does, potentially even more than samsung(I don't have hard numbers). Does that mean Microsoft is marketing android phones?
What does that have to do with anything? IBM made $23B selling it's own software. Does Microsoft sell Android phones? No? Then what is the point of your post?
The point of SUA (SFU, Interix, whatever) wasn't to allow you to run "grep" on you "My Documents" folder. If that's what you were using it for, you were doing it wrong.
Karma: Poor (Mostly affected by lame karma-joke sigs)
It is just an example, and it has more to do with the drawbacks of running virtual machines as a replacement to native systems (as pointed by adonoman) than with SUA itself. I knew since the beginning it was a terrible example, though, but I wasn't able to think anything better.
The point is that Microsoft is making money NOT marketing android phones, by that perspective, IBM making 23Billions in software doesn't mean they marketed that software either.
I knew since the beginning it was a terrible example, though, but I wasn't able to think anything better.
That's the problem (and the reason why SFU is going away). There are very, very few legitimate uses for SFU these days. Few enough that it no longer justifies the (likely quite expensive) investment from Microsoft.
Karma: Poor (Mostly affected by lame karma-joke sigs)
You're misinterpreting the email. An equivalent patch was added. It just wasn't done in the manner proposed by the original author.
Really? Does it mean that CVS version of Cygwin is as fast as Cygwin is with jojelino's patch?
In my testing, yes. I just generalized his patch so that it could be used when starting any thread rather than just the specific thread that he found.
jojelino finds some interesting stuff but his implementation often leaves something to be desired.
Hello cgf or Corinna or whoever you are!
I didn't say you don't take the direction of the project seriously. As I said, I love Cygwin; I think the project is one of the main jewels of open source and a vital part of the open source ecosystem's success over the past 15 years. But I do think that you deserve a lot more help than you get and that limited manpower inevitably leads to limited goals and limited vision; it takes enough energy to deal with present difficulties that future huge changes and blue-sky projects have to take a back seat.
As concerns 1.7, you're certainly right that I don't know the internals very well. But I thought I remembered things saying that quite a number of the areas in which 1.7's performance was better than 1.5's were made possible because you no longer had to support 9x.
I don't think you seriously believe that cygwin's performance wouldn't really improve if you had more hands on deck. If what you mean to say is "hey, we're not writing sloppy code here; things done in cygwin take time because there's lots of work that has to be done" then I'm in total agreement. If what you mean to say is "the code we write is so marvelously perfect that even putting a dozen brilliant full-time developers on cygwin for a few years couldn't change performance much" then that's totally laughable.
Your link to the cygwin-cvs logs of course shows that there are people working hard on cygwin. But the fact that the stream of updates turned into a trickle when Corinna went on vacation at the beginning of this month shows that those people are quite few.
Of course you do have a number of committed and active maintainers. But that number is small given the task; I'd wager that a project like Debian has easily a hundred times as many maintainers, and maintaining a Cygwin port and build is often a lot harder than maintaining a package for a linux distro. The loss of a single maintainer is often a keenly felt blow (witness Dave Korn's disappearance from the face of the planet for some months earlier this year).
I am very grateful for your efforts and wish you all the best; it just so happens that my idea of "the best" includes a couple hundred dedicated package maintainers and a dozen core developers to speed your way forward. :)
Can you point me to the relevant changes in CVS?
I did some basic testing using the venerable cygbench and Gergely Szabo's fork benchmark and uploaded the results to pastebin. Looks like the current snapshot really is the fastest. Any idea when Corinna releases 1.7.10?
http://pastebin.com/PLC63ZKi