6 ms·

Why would I restrict myself to Linux if the tooling I prefer is only available on Mac? I guess if my entire workflow was terminal based then Linux would make se

Why would I restrict myself to Linux if the tooling I prefer is only available on Mac? I guess if my entire workflow was terminal based then Linux would make sense but I'm more productive with Intellij, Kaleidoscope, Tower Git, iTerm, and my iTunes library of music. A vm running centOs and using docker let's me use my favorite tools and still leverage Linux as a deployment environment, how does that not make sense?

antocv 12y ago
Then run Mac in a VM on Linux. IntelliJ, Git, and music-listening developr here. On GNU/Linux. It does not make sense because you stop yourself from knowin the inner workings of what you are targeting in your development efforts - eat your own poison so to say - CentOS - run CentOS. How hard can that be?
- debaserab2 12y ago
  Or just go the other way around and let your toolchain reside on the host and your source code reside on a VM. I've always found that to be a more natural workflow: my VM remains a more pristine true-to-production environment and I'm not stifled by the oddness of doing 90% of my work in a virtual environment.
- jaegerpicker 12y ago
  A. running Mac in a VM on Linux is illegal B. Tower, Kaleidoscope. iTerm, and XCode are all Mac only C. How in Earth do you draw the conclusion that I've stopped myself from knowing anything? I am running CentOS, in the VM. I'm extremely familiar with the inner workings of Linux. If I'm running in a VM or as the main OS has no bearing on how much I know about my deployment target. It's still the same steps to setup a deployment target VM or on my actual laptop. In fact in the case of AWS you could argue that a VM is much closer to my deployment prod servers than laptop hardware would be.
  - josteink 12y ago
    > A. running Mac in a VM on Linux is illegal According to who? Has this been tried in a court of law? If not, it's legal until proven otherwise. This BS by Mac-appologetics has got to stop.
    - jaegerpicker 11y ago
      According to Apple and the License agreement you agree to run Mac OS X. It requires apple hardware to run the OS in the agreement. Perhaps you should read something prior to calling someone else out. 2. Permitted License Uses and Restrictions. A. This License allows you to install and use one copy of the Apple Software on a single Apple-labeled computer at a time. This License does not allow the Apple Software to exist on more than one computer at a time,and you may not make the Apple Software available over a network where it could be used by multiple computers at the same time. You may make one copy of the Apple Software (excluding the Boot ROM code) in machine-readable form for backup purposes only; provided that the backup copy must include all copyright or other proprietary notices contained on the original. from: http://store.apple.com/Catalog/US/Images/MacOSX.htm http://store.apple.com/Catalog/US/Images/MacOSX.htm
- beat 12y ago
  d00d, I was running Slackware on 0.9 kernels in a business environment when half of HN was trying to figure out how to remove their own diapers. I know Linux quite well enough. I use OSX for my desktop because it's the least awful desktop experience. If I'm coding, it's mostly command line tools, and there is no technical difference between running bash on a Linux desktop and running bash via vagrant ssh on my Mac. What is different is that my Vagrant instance configuration is 100% programmable and repeatable. There are no surprises. There are no differences between development environment and production environment, in terms of installed software or patches. I'm not hacking away on some snowflake environment and then trying to grok wtf is wrong with my code when it gets deployed to the next environment. But the original post isn't about this, even... it's about Docker. Dockerized applications are 100% binary-level compatible from environment to environment. I can easily localize from dev to test to production using environment variables - a proper 12 Factor App. Why would I not want to do this in my development environment? Why would I go back to some crude 2003-vintage development model that I know good and well is going to break things later? And it gets worse. Lots of us have to deal with heterogeneous environments. What if I'm building for both CentOS and Debian? With something that's OS patch-sensitive? Do I test in production to see if it survives? No, I use Vagrant to test every platform I want, and Docker to guarantee consistency whenever I can. How hard can it be? It can be much, much harder than a proper, modern Vagrant/Docker environment.
  - josteink 12y ago
    I'm not saying "don't use Docker". I'm saying "use the Linux-based Docker-technology on Linux, instead of hacking it up on Mac, in a VM". I thought that was pretty obvious, but looking at the response I guess not.

antocv 12y ago

Then run Mac in a VM on Linux. IntelliJ, Git, and music-listening developr here. On GNU/Linux. It does not make sense because you stop yourself from knowin the inner workings of what you are targeting in your development efforts - eat your own poison so to say - CentOS - run CentOS. How hard can that be?

debaserab2 12y ago
Or just go the other way around and let your toolchain reside on the host and your source code reside on a VM. I've always found that to be a more natural workflow: my VM remains a more pristine true-to-production environment and I'm not stifled by the oddness of doing 90% of my work in a virtual environment.
jaegerpicker 12y ago
A. running Mac in a VM on Linux is illegal B. Tower, Kaleidoscope. iTerm, and XCode are all Mac only C. How in Earth do you draw the conclusion that I've stopped myself from knowing anything? I am running CentOS, in the VM. I'm extremely familiar with the inner workings of Linux. If I'm running in a VM or as the main OS has no bearing on how much I know about my deployment target. It's still the same steps to setup a deployment target VM or on my actual laptop. In fact in the case of AWS you could argue that a VM is much closer to my deployment prod servers than laptop hardware would be.
- josteink 12y ago
  > A. running Mac in a VM on Linux is illegal According to who? Has this been tried in a court of law? If not, it's legal until proven otherwise. This BS by Mac-appologetics has got to stop.
  - jaegerpicker 11y ago
    According to Apple and the License agreement you agree to run Mac OS X. It requires apple hardware to run the OS in the agreement. Perhaps you should read something prior to calling someone else out. 2. Permitted License Uses and Restrictions. A. This License allows you to install and use one copy of the Apple Software on a single Apple-labeled computer at a time. This License does not allow the Apple Software to exist on more than one computer at a time,and you may not make the Apple Software available over a network where it could be used by multiple computers at the same time. You may make one copy of the Apple Software (excluding the Boot ROM code) in machine-readable form for backup purposes only; provided that the backup copy must include all copyright or other proprietary notices contained on the original. from: http://store.apple.com/Catalog/US/Images/MacOSX.htm http://store.apple.com/Catalog/US/Images/MacOSX.htm
beat 12y ago
d00d, I was running Slackware on 0.9 kernels in a business environment when half of HN was trying to figure out how to remove their own diapers. I know Linux quite well enough. I use OSX for my desktop because it's the least awful desktop experience. If I'm coding, it's mostly command line tools, and there is no technical difference between running bash on a Linux desktop and running bash via vagrant ssh on my Mac. What is different is that my Vagrant instance configuration is 100% programmable and repeatable. There are no surprises. There are no differences between development environment and production environment, in terms of installed software or patches. I'm not hacking away on some snowflake environment and then trying to grok wtf is wrong with my code when it gets deployed to the next environment. But the original post isn't about this, even... it's about Docker. Dockerized applications are 100% binary-level compatible from environment to environment. I can easily localize from dev to test to production using environment variables - a proper 12 Factor App. Why would I not want to do this in my development environment? Why would I go back to some crude 2003-vintage development model that I know good and well is going to break things later? And it gets worse. Lots of us have to deal with heterogeneous environments. What if I'm building for both CentOS and Debian? With something that's OS patch-sensitive? Do I test in production to see if it survives? No, I use Vagrant to test every platform I want, and Docker to guarantee consistency whenever I can. How hard can it be? It can be much, much harder than a proper, modern Vagrant/Docker environment.
- josteink 12y ago
  I'm not saying "don't use Docker". I'm saying "use the Linux-based Docker-technology on Linux, instead of hacking it up on Mac, in a VM". I thought that was pretty obvious, but looking at the response I guess not.