4 ms·
I think this lends heavily into the reasons why development on OSX has become so popular. Devs were dying for a functionally attractive alternative to Linux, bu
by ericcholis 13y ago
I think this lends heavily into the reasons why development on OSX has become so popular. Devs were dying for a functionally attractive alternative to Linux, but Windows didn't offer the proper environment.
Heck, as a primary Windows user I've been contemplating switching to OSX for development.
P.S. While Cygwin is nice, I've always felt like it was a clunky alternative that was shoe-horned into Windows.
- maxerickson 13y agoCygwin is strapped on the back of Windows or something. It doesn't try to fit in or play along (which is fine, it's a portability layer). For tools, the stuff from the GnuWin project fits into a cmd shell better than Cygwin (in my experience anyway): http://gnuwin32.sourceforge.net/ http://gnuwin32.sourceforge.net/
- rfnslyr 13y agoI've recently dumped my Windows environment. Switched from a massive powerful tower with multiple monitors to a single Macbook Pro Retina 15". My workflow is much faster now due to gestures and learning hotkeys, much more portable, works better, faster than my desktop. I can work remotely anywhere I want too which is amazing. OS X is great for development. Besides gaming, I really don't see a point to using Windows ever again really. The UI is so much nicer, gestures save me a lot of time (quickly launch an application, view desktop, switch between spaces), combined without having to do any workarounds (working remotely on a Linux server) to get things running. Love having a native terminal as well.
- barrkel 13y agoCygwin is my primary means of interfacing with Windows, and combined with a bunch of shim scripts I've built up over the years, I get a very similar experience across Windows, Linux, OS X and Solaris. I actually prefer a Cygwin terminal on Windows to a Rxvt or similar lightweight terminal in X Window. The biggest pain in Linux is the selection buffer. With Console2 on Windows, selecting text puts it in the clipboard buffer, and you can then select a bunch of text in your IDE and overwrite it with a paste. The same workflow doesn't work at all well in Linux; first you must delete the text in the IDE, then select the text in the console, then very carefully aim where you want the text inserted and fire with the middle mouse button. Even worse, IDEs like RubyMine clobber the selection buffer for common operations like Ctrl+Shift+N (Navigate | File); not only does it clobber the buffer, but it hides the window if it loses focus, so it's actually impossible to copy text from an rxvt terminal into its search box! As a practical web development environment, I think Linux is the way to go to minimize the distance to production. But my preferred means of interacting with Linux is ssh, either to a VM or over the network, from a nicer desktop OS. Which for me is Windows.
- WayneDB 13y ago> Cygwin is my primary means of interfacing with Windows... Could you explain that a little more? For instance - say you want to browse the web or read email - you're doing it in a Cygwin terminal? Do you use it as your launcher to launch Windows apps or do you only run text interface applications? Or, do you just do most of your dev/sysadmin work in Cygwin and use normal Windows apps for the rest?
- barrkel 13y agoI mean I have 7 terminals (many also running screen) open on my desktop - more windows than all other apps combined; and almost all interaction with the OS, by which I mostly mean process and file management, is via the command line. My browser is relegated to a secondary window alongside my service monitoring and ssh terminals. When I write new utilities, they are usually command-line based. If I can get away with it, I'll put together a bash script built out of pipelines of Unix utilities and various others I've written over the years. I'm reluctant to write for-purpose apps; I try to make them fit into a Unix-style paradigm of streams combined with some command-line options. For example, I recently wrote a simple video editor to select clips from my motorbike commuting videos. The only platform-specific bit is the video player, and all it does is respond to keyboard commands to navigate backwards and forwards and mark positions, in response to which it writes out text to standard out. I have other scripts which drive ffmpeg or other utilities as necessary to do the heavy lifting of cutting and composing. And to port it to another OS, all I need write anew is a video-playing component. And things like parallelization for efficiency, process isolation for resilience, and job control to temporarily reduce CPU usage (perhaps to avoid overheating on reencode!) are trivial. For work, all my testing is done from the command-line, much of the code tweaks, all source control, merge resolution, grep / sed / etc. Debugging is usually done with repls like pry for Ruby. Browser at work is primarily used for distraction while having a coffee and waiting for tests to run, or to interact with company web apps. Things like web browsers (Firefox in my case, because of tree-style tabs more than anything else) are invariant across platforms. If you live entirely in the browser, you don't need to deal with, or even know anything about, the machine's OS. So I don't really consider that use case an interaction.
- badman_ting 13y agoAgreed about Cygwin. I used it for years out of necessity, but I don't like when people suggest it as a remedy for Windows's anemic command line. Cygwin adds a tiny amount of what is needed. For one thing, Cygwin can't do anything about the terminal emulator, which is very weak.
- rbanffy 13y agoAre you using MinTTY or the native cmd.exe-like terminal? MinTTY is based on PuTTY code and is quite reasonable (and a major improvement over the standard Windows way.
- yogo 13y agoYep, Cygwin is good if you have no other options, but it's like running Wine on Linux, i.e. some things might work but it's not surprising if they don't work (or work the way they should).