Your right, I don't develop with cygwin. I just use it as a user. Anything I install, I install from it's repositories, and so far, it's always worked fine. I have compiled one or two things with it, and that's all just worked like it was a real Unix. This doesn't negate what you are saying, but I'm using it as an isolated environment and not trying to redistribute anything. If I did, I would try to redistrubute through the package management system, so may not hit the issues you have. But perhaps the repositories aren't controled like real Unix ones and I've just been lucky, I've not looked.

I've not found speed an issue for my uses.

I use the Unix like environment because I prefer it (and it has history longer than that session), but the standard console (Window's running cygwin) is terrible. MinTTY is amazing when compared with the standard console. So am I going to use PuTTY to connect to a real Unix environment? No. I'm going to use normal ssh like I was on a Unix environment. I did use PuTTY and normal Windows userland for quite a while, but I found cygwin + MinTTY works best for me. The piping stuff is an example where I can forget I'm on Windows and just do as I would normally. Don't get me wrong, I use PuTTY when on other people's machines, or don't have admin, but if it's a Windows machine that's for me, I'm going to setup and use MinTTY + cygwin because it gives me more than PuTTY.

I just wish it's package management was more like APT. I miss apt-get when on cygwin.

Here here!

I didn't know Powershell still uses the crap default terminal!
Haven't gone near it as I'm happy with cygwin and MinTTY, plus I try and avoid Windows specific stuff.

Then those improvements make all the difference. Plus, you can use it to use normal ssh, normally.

That is how I do still use PuTTY from time to time. When it's not your machine, it's polite to only use PuTTY rather than install anything, and if you don't have admin, it's the only option. But I don't often do this, I use cygwin+mintty as preference, like on my work machine.

I find the PuTTY terminal isn't much better. Mintty is the best I found for Windows. Shame it's not like Guake, but stuff I found to do that on Windows hasn't been functional.

Much nicer console and gives just standard command line ssh, which is all I want/need. I stopped using Putty years ago...
During the heavy snow in the UK, I was regularly checking how bad it was at home with:

ssh user@server "ffmpeg -r 15 -f video4linux2 -i /dev/video0 -f matroska pipe:" | ffplay pipe

Which is exactly what I would have done if my work machine was Linux not Windows. Guess it depends what you want a ssh client on Windows for.

You probably can get more out of it to because it's probably using softfp instead of hardfp. http://www.youtube.com/watch?v=qWUd4TAEqTM

Hehe, I take you know it was Linux having drivers that probably started this.
MS probably hated all those Linux Kinect YouTube videos. :-)

That's the old JIT argument, and while in theory it might have some merit, in the last decade it shown not to. Christ, a great deal of stuff still targets i386 just to ensure it runs on everything, and yet those apps still out perform Java/C# apps. Why? Because the core instructions are still the core instructions and the old RISC rule holds true, most of the work is done using a few key instructions. Plus where the JIT argument breaks down is with things like DLLs. The DLL can be very specific for the computer, and old applications link in that DLL to do the work, and thus the work in question for the old application is done with the latest, computer specific, stuff. If you want speed, use pre-canned stuff, if you want productivity use something like python, if you want both, probably best use a language for each. For instance core logic in C, and GUI stuff in python. Or use C++ and except the complexity that adds. If you want to have both but are willy to compromise to have both, then maybe that is where JIT languages come in.

In Debian (and no doubt other package managers) you can have A and B use different versions of a shared lib, but one uses the "somelib.so" and the other "somelib.1.0.so". Normally a version of lib is standardize as the version of a lib. Other versions are used with version number as part of the name. If there is a conflict, then yes you can have only one or the other, but I don't see how you get out of that. For instance /usr/bin/convert and /usr/local/bin/convert is still a conflict in my book, one (local) overrides the other even if it's not overwritten it. You could hack something up with chroot, but it all starts getting ugly. Unless I'm missing something of course.

I grew up as a RiscOS user, which had this kind of application folder system.
Package management is >much If you are going to have shared blobs of code like shared-objects/DLL you need package management, end of story.
You want one copy of each, or a least one of each version, and you want to update that one file. Even on modern machines, you don't want to statically link everything, even if you did, think about updates. If one of these files need a fix, it's much easier to update that one file, then update every program built statically against it. Use version number as part of the filename and have a sym link without the version number to the latest version. If something needs a specific version, it can be built to link to that not the latest. You can do as many version levels of this as required. Seriously, this is much better centrally managed and updated. You can even list all applications that use the file, even before anything is installed. I wouldn't go back to an application folder system if you paid me to. Windows has some central management with the manifest stuff and add/remove programs, but compared with Debian package management, it's an over-complex mess or a fraction of the power. Other package manager might be as good as Debian's, but so far, none have impressed me as much.

Don't disagree, but the difference in productivity for the loss of speed isn't as good as good as asm to C.

There is a sweet spot though isn't there. Assembler is slow to develop in, but very fast. C can be used almost as a high level assembler, you can be pretty clear about how you want things to compile, yet C is much faster to develop in than assembler. Some languages (say python) are very quick to develop in, but if you care about speed at all, are the wrong choice. I would say C and C++ are the sweet spot where you get most bang for bucks in terms of speed cost and productivity gain. Afterwards, it does seam like diminishing returns, you pay more and more performance, for less and less productivity gain. Assembler to C is the biggest jump at the smallest cost.

Memory is used, even if no application is using it. It's used to cache disk. Free memory is not wasted memory. Bloat is a relative term. If one application, with feature parity with another, uses much less memory than the other, it makes the other seam bloated. If Unity is using much more memory than Gnome3, as there is feature parity, then Gnome3 is bloated. It's an arms race we all win from because our computers get faster for free. :-)

This is why MS are pushing .NET, moves them away from being in a death embrace with x86 (that and it gives a complete platform to lock people into).
I see byte code as a way closed source code can get the "run on anything" of open source, without opening the source.
With open source, you just compile it on the platform in question (ok it is more than that, but can be that).
If you have the source, and it's in the repository specific for a processor (and why not, not that many types of processors), why not just compile to native rather than a byte code indirection?
Thing is about this is that Windows was a slow and fat platform when it was native.... How is it going to compete on ARM when it's byte coded too?