3 ms·

> This removes one of the major reasons to use a Mac for Linux development I find it hard to believe many people using a Mac for Linux development, will (want|

> This removes one of the major reasons to use a Mac for Linux development I find it hard to believe many people using a Mac for Linux development, will (want|be able) to use this the same way. Anything that needs to simulate prod-ish environments for developers, will be using a VM (and if you're not, you should be) often via Vagrant. This also limits you specifically to Ubuntu, so it's automatically going to be invalid for a lot of things that either a) are tested/built for multiple distros anyway or b) targeted at a specific distro that isn't Ubuntu. Edit: additionally, using a Mac means you (via VM's) run any OS (or Browser, if it's a web project) you need, to test the software.

gpvos 9y ago
As the article states, SUSE and Redhat will be available in a week or two. WSL should be able to support other distros or self-built Linux too, although I wouldn't know how to go about that.
- sapphire_tomb 9y ago
  I've been using Arch as my WSL image for about a year I think. I used this tool to get it going : https://github.com/RoliSoft/WSL-Distribution-Switcher https://github.com/RoliSoft/WSL-Distribution-Switcher
staofbur 9y ago
Definitely agree with vagrant. Vagrant incidentally is monumentally horrible on windows as well.
- stephenr 9y ago
  I've heard that Git was (maybe is) not fantastic on Windows either (to the point it has to ship its own bundled version of Bash!?)
  - staofbur 9y ago
    It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other shell tools in place which windows didn't have. There are some powershell wrappers that make it better.
    - jhasse 9y ago
      > It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other shell tools in place which windows didn't have. For me, that's Windows' fault.
      - staofbur 9y ago
        Not really. You could write a git client for windows that didn't have these issues.
        jhasse 9y ago
        Yes, I would call those changes workarounds for Windows' bugs (incase-sensitive filesystem, no ssh infrastructure, ...). One of the reasons Git is slower on Windows, is that spawning processes is a lot slower than on Linux. Wouldn't you call that a bug?
        pjmlp 9y ago
        No, because Windows wasn't designed to make Git fast. It is a bug on Git side if it fails to be platform independent and requires POSIX semantics to function properly.
        jhasse 9y ago
        I wouldn't call "spawning processes isn't slow" or a fast filesystem POSIX semantics.
microcolonel 9y ago
> Anything that needs to simulate prod-ish environments for developers, will be using a VM (and if you're not, you should be) often via Vagrant. I know this not to be the case, and I disagree that it should be. I don't see why I should have to spin up a separate kernel and init just to run my application during development. I wouldn't use a Mac for it, but I've seen people develop portable software which happens to work quite well on Mac and Linux dev boxes for Linux production boxes. There's a lot to be said for debugging on your home turf.
- stephenr 9y ago
  > I don't see why I should have to spin up a separate kernel and init just to run my application during development. So that you know it.. you know.. works in that environment? Edit: additionally, using a VM (and particularly using a tool like Vagrant) means that the scripts/etc to setup a working dev environment need to be done ONCE, and then any developer can work on the project, on any host environment - you can use your windows machine, I can use my Mac, Fred can use his Linux box with whatever distro he wants. It doesn't matter: we all run vagrant and a provider (usually a VM hypervisor) (doesn't even need to be the same provider - you can use HyperV, I'll use Parallels, Fred can use VirtualBox, or heck even LXC), and the application runs exactly the same in that environment, with exactly the same setup. You can destroy your machine, walk to a band new one, clone the repo, run `vagrant up` and you'll have exactly the same dev environment as me again. Even if you don't use Linux for your prod environments, this type of setup is a must if you don't want developer productivity to sink to zero every time something happens that affects their host OS (OS updates breaking libs. New hardware. New software. New OS release. Switched machines. etc) > There's a lot to be said for debugging on your home turf. The whole point of tools like Vagrant is to allow you to run the application inside a VM, but work on it (i.e. write/debug the code) on your host machine.
  - noway421 9y ago
    Not to diminish your point, but there are cases where running application development is very easy on a mac, and linux comes as first and subsequent stages of the CI pipeline. > working dev environment need to be done ONCE good point, I personally would rather integrate everything into the development platform (i.e. front end http server would be just another npm package/middleware, but not NGINX, everything gonna end up under a load balancer anyway on prod/test). In regard to different machines/OSes, issuing everyone a mac really takes away a lot of headache for organisation, at a relatively small (compared to engineering hours) cost.

gpvos 9y ago

As the article states, SUSE and Redhat will be available in a week or two. WSL should be able to support other distros or self-built Linux too, although I wouldn't know how to go about that.

sapphire_tomb 9y ago
I've been using Arch as my WSL image for about a year I think. I used this tool to get it going : https://github.com/RoliSoft/WSL-Distribution-Switcher https://github.com/RoliSoft/WSL-Distribution-Switcher

staofbur 9y ago

Definitely agree with vagrant. Vagrant incidentally is monumentally horrible on windows as well.

stephenr 9y ago
I've heard that Git was (maybe is) not fantastic on Windows either (to the point it has to ship its own bundled version of Bash!?)
- staofbur 9y ago
  It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other shell tools in place which windows didn't have. There are some powershell wrappers that make it better.
  - jhasse 9y ago
    > It's actually pretty horrible but that's not windows' fault. It was designed for case sensitive unix systems with the appropriate ssh infrastructure and other shell tools in place which windows didn't have. For me, that's Windows' fault.
    - staofbur 9y ago
      Not really. You could write a git client for windows that didn't have these issues.
      - jhasse 9y ago
        Yes, I would call those changes workarounds for Windows' bugs (incase-sensitive filesystem, no ssh infrastructure, ...). One of the reasons Git is slower on Windows, is that spawning processes is a lot slower than on Linux. Wouldn't you call that a bug?
        pjmlp 9y ago
        No, because Windows wasn't designed to make Git fast. It is a bug on Git side if it fails to be platform independent and requires POSIX semantics to function properly.
        jhasse 9y ago
        I wouldn't call "spawning processes isn't slow" or a fast filesystem POSIX semantics.

microcolonel 9y ago

> Anything that needs to simulate prod-ish environments for developers, will be using a VM (and if you're not, you should be) often via Vagrant. I know this not to be the case, and I disagree that it should be. I don't see why I should have to spin up a separate kernel and init just to run my application during development. I wouldn't use a Mac for it, but I've seen people develop portable software which happens to work quite well on Mac and Linux dev boxes for Linux production boxes. There's a lot to be said for debugging on your home turf.

stephenr 9y ago
> I don't see why I should have to spin up a separate kernel and init just to run my application during development. So that you know it.. you know.. works in that environment? Edit: additionally, using a VM (and particularly using a tool like Vagrant) means that the scripts/etc to setup a working dev environment need to be done ONCE, and then any developer can work on the project, on any host environment - you can use your windows machine, I can use my Mac, Fred can use his Linux box with whatever distro he wants. It doesn't matter: we all run vagrant and a provider (usually a VM hypervisor) (doesn't even need to be the same provider - you can use HyperV, I'll use Parallels, Fred can use VirtualBox, or heck even LXC), and the application runs exactly the same in that environment, with exactly the same setup. You can destroy your machine, walk to a band new one, clone the repo, run `vagrant up` and you'll have exactly the same dev environment as me again. Even if you don't use Linux for your prod environments, this type of setup is a must if you don't want developer productivity to sink to zero every time something happens that affects their host OS (OS updates breaking libs. New hardware. New software. New OS release. Switched machines. etc) > There's a lot to be said for debugging on your home turf. The whole point of tools like Vagrant is to allow you to run the application inside a VM, but work on it (i.e. write/debug the code) on your host machine.
- noway421 9y ago
  Not to diminish your point, but there are cases where running application development is very easy on a mac, and linux comes as first and subsequent stages of the CI pipeline. > working dev environment need to be done ONCE good point, I personally would rather integrate everything into the development platform (i.e. front end http server would be just another npm package/middleware, but not NGINX, everything gonna end up under a load balancer anyway on prod/test). In regard to different machines/OSes, issuing everyone a mac really takes away a lot of headache for organisation, at a relatively small (compared to engineering hours) cost.