6 ms·

Ask HN: Developing on windows stack with a non-windows OS

1 points by vonadz 2y ago

We've recently acquired a company that uses windows for a lot of their development (C#, Visual Studio, Azure, etc). Most of us use mac or linux, which has caused some issues with trying to set up local dev environments for the windows dependent stack. I've tried finding open-source alternatives, but it ended up being easier to just install a windows vm locally and do development on that. Unfortunately, even with 12 cpus and 16 gb of RAM allocated for the VM, it's pretty slow and laggy. Other than getting a windows dedicated machine, does anyone have any recommendations for good setups to develop on a windows-dependent stack on linux / mac?

solardev 2y ago
You can get Windows cloud VMs to use as dev environments. We're basically back to the dumb terminal days, lol. For your Macs, you can also try using Parallels with Windows ARM, which might be less laggy than emulating x86 in a VM. Many apps will then go through Microsoft's own x86 emulation layer inside Windows ARM. Sometimes that's faster? Worth a shot. But nothing beats developing and testing on real Windows hardware. Doesn't that company have those machines already? You can run them as RDP servers (better than VNC) and just connect to them remotely. And for your Linux machines, you can just dual boot into real Windows. They're still x86, aren't they? Edit: Oh, and have you already tried WINE? That virtualizes system calls instead of emulating them. If it works, it should be much faster.
- vonadz 2y ago
  Thanks for this! I considered doing Windows cloud VMs, but just seemed like a hassle. I'll try out Windows ARM with Parallels. In this case we didn't acquire their hardware. Yeah dual booting was the solution I was hoping to avoid, mostly because it's inconvenient to transfer information between the two systems on one machine, but it seems that's the most viable solution. I looked at WINE, but read that specifically Visual Studio doesn't work very well on it.
  - solardev 2y ago
    You're using Visual Studio, not VSCode, right? It looked like Microsoft had at one point experimented with a hosted dev space for it under the name "Visual Studio Online": https://news.ycombinator.com/item?id=21442088 https://news.ycombinator.com/item?id=21442088 or https://devblogs.microsoft.com/visualstudio/announcing-visual-studio-online-public-preview/ https://devblogs.microsoft.com/visualstudio/announcing-visua..., but somehow it became merged/confused with Github Codespaces, which only supports VScode and not the regular Visual Studio. Their messaging is really confusing and all the old links just redirect to the unrelated Codespaces now :( Maybe you can reach out to @lostintangent to ask what happened? I think the closest thing now is an Azure Microsoft Dev Box: https://azure.microsoft.com/en-us/products/dev-box https://azure.microsoft.com/en-us/products/dev-box. It should be simpler to manage & roll out than raw VMs (i.e., it's a hosted dev space preconfigured by IT, not a whole VM that each dev has to individually manage). Their product page is really vague, but here's a video that shows it working: https://youtu.be/kyeuSpR74W4?si=qK5IavNIPNIxi-Bp&t=310 https://youtu.be/kyeuSpR74W4?si=qK5IavNIPNIxi-Bp&t=310 IMHO doing something like that would make the developer experience less painful than every developer having to manage their own Parallels, Windows install, filesystem, networking, credentials, etc. all before they even touch the actual code. If you set up the hosted dev boxes beforehand, each dev should just be able to click a button and jump right into coding, from whatever their existing laptop is, without needing to alter their local stack. Otherwise, if the Windows stack is something they only occasionally touch (vs their regular work in the Mac/Linux worlds), I think it's very likely that each individual dev's local VMs will quickly get out of sync with each other's and with whatever the "master" source of truth is. Sure, you can containerize it and share the containers instead, but at that point you're basically recreating Microsoft Dev Boxes... and without any real x86 hardware, to boot =/ I guess if you really want to do this self-hosted and stream it locally, you can get an high-powered Windows machine (probably a cheap server or a high-end gaming/workstation desktop with lots of RAM and CPUs will suffice), install Windows server stuff on it and use it to host RDS: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-services-overview https://learn.microsoft.com/en-us/windows-server/remote/remo... One way or another, I guess the choice is between "buy licenses and have each individual dev configure their own work env" or "buy a server or a cloud subscription and let them manage the envs and stream to the devs".

1 points by vonadz 2y ago

solardev 2y ago

You can get Windows cloud VMs to use as dev environments. We're basically back to the dumb terminal days, lol. For your Macs, you can also try using Parallels with Windows ARM, which might be less laggy than emulating x86 in a VM. Many apps will then go through Microsoft's own x86 emulation layer inside Windows ARM. Sometimes that's faster? Worth a shot. But nothing beats developing and testing on real Windows hardware. Doesn't that company have those machines already? You can run them as RDP servers (better than VNC) and just connect to them remotely. And for your Linux machines, you can just dual boot into real Windows. They're still x86, aren't they? Edit: Oh, and have you already tried WINE? That virtualizes system calls instead of emulating them. If it works, it should be much faster.

vonadz 2y ago
Thanks for this! I considered doing Windows cloud VMs, but just seemed like a hassle. I'll try out Windows ARM with Parallels. In this case we didn't acquire their hardware. Yeah dual booting was the solution I was hoping to avoid, mostly because it's inconvenient to transfer information between the two systems on one machine, but it seems that's the most viable solution. I looked at WINE, but read that specifically Visual Studio doesn't work very well on it.
- solardev 2y ago
  You're using Visual Studio, not VSCode, right? It looked like Microsoft had at one point experimented with a hosted dev space for it under the name "Visual Studio Online": https://news.ycombinator.com/item?id=21442088 https://news.ycombinator.com/item?id=21442088 or https://devblogs.microsoft.com/visualstudio/announcing-visual-studio-online-public-preview/ https://devblogs.microsoft.com/visualstudio/announcing-visua..., but somehow it became merged/confused with Github Codespaces, which only supports VScode and not the regular Visual Studio. Their messaging is really confusing and all the old links just redirect to the unrelated Codespaces now :( Maybe you can reach out to @lostintangent to ask what happened? I think the closest thing now is an Azure Microsoft Dev Box: https://azure.microsoft.com/en-us/products/dev-box https://azure.microsoft.com/en-us/products/dev-box. It should be simpler to manage & roll out than raw VMs (i.e., it's a hosted dev space preconfigured by IT, not a whole VM that each dev has to individually manage). Their product page is really vague, but here's a video that shows it working: https://youtu.be/kyeuSpR74W4?si=qK5IavNIPNIxi-Bp&t=310 https://youtu.be/kyeuSpR74W4?si=qK5IavNIPNIxi-Bp&t=310 IMHO doing something like that would make the developer experience less painful than every developer having to manage their own Parallels, Windows install, filesystem, networking, credentials, etc. all before they even touch the actual code. If you set up the hosted dev boxes beforehand, each dev should just be able to click a button and jump right into coding, from whatever their existing laptop is, without needing to alter their local stack. Otherwise, if the Windows stack is something they only occasionally touch (vs their regular work in the Mac/Linux worlds), I think it's very likely that each individual dev's local VMs will quickly get out of sync with each other's and with whatever the "master" source of truth is. Sure, you can containerize it and share the containers instead, but at that point you're basically recreating Microsoft Dev Boxes... and without any real x86 hardware, to boot =/ I guess if you really want to do this self-hosted and stream it locally, you can get an high-powered Windows machine (probably a cheap server or a high-end gaming/workstation desktop with lots of RAM and CPUs will suffice), install Windows server stuff on it and use it to host RDS: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-services-overview https://learn.microsoft.com/en-us/windows-server/remote/remo... One way or another, I guess the choice is between "buy licenses and have each individual dev configure their own work env" or "buy a server or a cloud subscription and let them manage the envs and stream to the devs".