4 ms·

> 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 -

by 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 ago
I 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.
- WayneDB 13y ago
  Wow, that's impressive! I just couldn't imagine working that way, so thanks for clarifying.

by WayneDB 13y ago

barrkel 13y ago

I 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.

WayneDB 13y ago
Wow, that's impressive! I just couldn't imagine working that way, so thanks for clarifying.