3 ms·

> realized it was cheaper to just hand all the developers Mac Books than to either train them on installing Unix tool chains on Windows, or on "properly" using

• kenshaw 12y ago
  Unless it has changed, Cmder is just simply a VTTY for Windows, similar to/replacing cmd.exe from Microsoft. I don't believe it includes, out-of-the-box support for Unix tool chains. You would need to install Cygwin tools, or similar, to accomplish that. If you've ever tried to administer large groups of systems with Cygwin installed, then you've shared my pain. The quickest, fastest way that I know to get the Unix shell commands/stuff up on Windows is to use the packaged Git installation (which I referenced in my previous post), but the issue then is that if you have ever dealt with semi-large code bases that involve one or two separate programming languages, then every developer has to track down all the various packages (if they exist), build them, or otherwise install / get them to work. This is often why in companies Windows devs are just given a shell account on a central Linux server to run their unit tests, or runs them inside a VM on Windows. Windows doesn't have any kind of central package manager akin to apt / yum / port for Unix systems that would allow for easy and quick installation of widely used open source software. While they are trying to push their own package manager on Windows, I don't see that as being successful anytime soon. And, ultimately this approach (of installing Unix toolchains on Windows) is just a hackish workaround, and doesn't address the root issue that the most powerful automation toolsets in the world are all written / developed on / designed for Unix-like systems, and they simply do not run natively on Windows. If Microsoft genuinely wants to join the modern development ecosystem, they will provide cross platform versions of their browser and keep them synced and up to date across platforms, so that they can be plugged into the existing infrastructure (and thus investment) companies have made in their development environments, automated testing, and continuous integration/deployment. Microsoft can not ignore (by virtue of exclusion) Linux / OSX (and other Unix-es) if they want wide-spread adoption of this new Spartan browser, simply because they want to push the Windows platform. That strategy may have worked in the late 90s, early 2000s when there was no other options for a readily usable, simple user experience desktop platform , but that's not the case any more.
  • Encosia 12y ago
    You can choose either Cmder by itself or a bundled installer that includes msysgit. I set my default "new console" to that bundled bash and things work pretty great. Start + "cmd" and I'm at a bash prompt in a fairly nice console emulator. Most people install a better terminal emulator to replace OS X's default terminal app anyway, so we're all installing something to get a nice experience. I really haven't missed any of my Mac's command line friendliness when on my Windows machines using Cmder. Chocolatey is a fairly popular apt/yum equivalent on Windows. Most anything built on Node, like npm, bower, or jspm, works fine too. Could things be better? Sure. Every platform has room for improvement in areas. As a developer primarily using Windows here, my day-to-day experience just doesn't seem anywhere nearly as bleak as you're describing though.
    • kenshaw 12y ago
      I didn't say it was bleak. The difference is that on Linux/OSX you don't need to install extra tools like mysysgit/cgywin or a different terminal emulator (ie, Cmndr or other 'Terminal' replacement on OSX), because the toolset is already there (bash, awk, sed, etc). Also, the thing here is that it's not optimal, and there's also non-trivial licensing costs when building large continuous integration/deployment systems. Additionally, I don't believe you would be very supportive of the experience on Windows if you were more familiar with what is possible on Linux, OSX or any other Unix, and if you had strong understanding/knowledge/command of the toolsets available on those ecosystems. There is nothing fundamentally wrong with using Windows as a regular desktop environment (I'm forced to almost every day). It's actually a fairly good experience (from a desktop perspective), but it doesn't give developers and system admins true, powerful out of the box toolsets. For instance, installing PostgreSQL/MySQL/Apache/Nginx/or whatever on Windows is extremely painful, cumbersome, and not standardized across systems. Conversely, compare this: (yum|apt-get|port) install (postgresql|mysql|apache|nginx). To do proper automation on large sets of Windows systems, you need Windows Server, Active Directory, and Domains properly setup configured, and licensed, especially if you have any kind of security policy and need to push / control updates from a central server and keep strict control of / standardized versions across systems (for instance, in a strict, actually PCI compliant environment). Why bother with any of that when all of that mess / problem is taken care of by your distribution (OSX/Linux/etc), as one would expect it to be. There's no dependency graphs with large sets of Unix-likes, unlike in the Windows ecosystem -- and that really is the main issue here.