4 ms·

In my personal experience, Windows development is absolutely awful. Nothing about it is ergonomic, and the management of the development environment is just pai

In my personal experience, Windows development is absolutely awful. Nothing about it is ergonomic, and the management of the development environment is just painful. Obviously you don't always have a choice, but creating a nice development experience is clearly not a priority for Microsoft. One really basic example: I was deploying files to a Windows Server box using scp, but my internet connection died midway through the transfer. All subsequent deployments would fail until I could connect via RDP to kill the old SSH process holding an open file handle. Another example: I bought into the WSL hype, hoping it would solve all my problems. But you can't easily interact with files on the system outside of Linux subsystem, which made it more or less useless for my purposes. If I wanted to interact only with Linux files, I would have used a Linux-based server. Maybe I could get better at Powershell, but it felt overly verbose while also being less composable / powerful. The simple posix shell primitives were sorely missed. Running things on startup was also insane. I think I needed to add a triggered job that ran on user log in, and then configure the host to login a specific user when the host starts. Very crazy...

judge2020 5y ago
> But you can't easily interact with files on the system outside of Linux subsystem, which made it more or less useless for my purposes. It’s possible in file explorer via \\wsl$, but that is not always supported by applications so it’s not 100%.
- somejerk 5y ago
  ls /mnt/c Oh, hey, there's the C drive in WSL! ;) ln -s /mnt/c/Users/Somejerk/Documents ~/documents Oh, man, a shared documents folder! Granted, access to those files is slow as dirt because of the Plan9 filesystem, and there are some weird bugs where a process sometimes loses access to $cwd if it's not a native wsl filesystem (also a Plan9 bug reported to MS over a year ago). But it's tolerable when interoperability is necessary. It also facilitates using the same filesystem under multiple WSL instances.
malkia 5y ago
I love unix tools (grep, sed, cut, etc.), and while there are some good sub-systems (msys2, cygwin), they might be bit heavey. For that the windows version of busybox - https://frippery.org/busybox/ https://frippery.org/busybox/ - and then I make sure my scripts are not using too powerful features of said tools (grep especially), such that the version in busybox works. Great, and also possible to port some of that back to linux (but I mostly use it to build something, or extract some data but want to share the .bat file with others - one day when I get better in PowerShell I'll try there more).
- pid-1 5y ago
  I use scoop to install this sort of tool in Windows. iwr -useb get.scoop.sh | iex # install scoop scoop install coreutils vim nano [...] # yay
  - malkia 5y ago
    Nice! I'll try it out tomorrow finally.. after giving up on choco, and possibly on winget. But in my case I wanted to leave something small (and busybox.exe is that small) /portable - for others to use (without the requirement to install scoop).
    - malkia 5y ago
      So scoop is awesome so far - the only thing I'm missing (right now) is to be able to specify specific bucket for some actions (but found workarounds).
pjmlp 5y ago
Usually it helps by adopting Windows development practices instead of trying to cram UNIX workflows into it. Who on their right mind uses ssh/scp on Windows development other than connecting to UNIX boxes?
- maccard 5y ago
  > Who on their right mind uses ssh/scp on Windows development other than connecting to UNIX boxes? Exactly. That's like complaining that I can't RDP into a linux box to install the toolchain!
- simulate-me 5y ago
  What’s the alternative? I was deploying from a Mac, so connecting to a Unix box is exactly what I was doing.
  - pjmlp 5y ago
    A possible alternative. https://support.apple.com/guide/mac-help/share-mac-files-with-windows-users-mchlp1657/mac https://support.apple.com/guide/mac-help/share-mac-files-wit... https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-mac https://docs.microsoft.com/en-us/windows-server/remote/remot... Another alternative, https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/running-remote-commands https://docs.microsoft.com/en-us/powershell/scripting/learn/...
    - simulate-me 5y ago
      I was deploying to a fleet of servers. Having every engineer add every server via the macOS sharing UI or using RDP to manually connect to each host doesn’t seem scalable. Maybe remote power shell sessions would work, but I’m not even sure if there is a power shell client for Mac, and it’s also not clear if remote power shell sessions would fix the open file handle issue. Experienced Windows devs I talked to said they used Packer from Hashicorp to entirely recreate their server image whenever they wanted to deploy. This process takes hours, but that was the best I found.

judge2020 5y ago

> But you can't easily interact with files on the system outside of Linux subsystem, which made it more or less useless for my purposes. It’s possible in file explorer via \\wsl$, but that is not always supported by applications so it’s not 100%.

somejerk 5y ago
ls /mnt/c Oh, hey, there's the C drive in WSL! ;) ln -s /mnt/c/Users/Somejerk/Documents ~/documents Oh, man, a shared documents folder! Granted, access to those files is slow as dirt because of the Plan9 filesystem, and there are some weird bugs where a process sometimes loses access to $cwd if it's not a native wsl filesystem (also a Plan9 bug reported to MS over a year ago). But it's tolerable when interoperability is necessary. It also facilitates using the same filesystem under multiple WSL instances.

malkia 5y ago

I love unix tools (grep, sed, cut, etc.), and while there are some good sub-systems (msys2, cygwin), they might be bit heavey. For that the windows version of busybox - https://frippery.org/busybox/ https://frippery.org/busybox/ - and then I make sure my scripts are not using too powerful features of said tools (grep especially), such that the version in busybox works. Great, and also possible to port some of that back to linux (but I mostly use it to build something, or extract some data but want to share the .bat file with others - one day when I get better in PowerShell I'll try there more).

pid-1 5y ago
I use scoop to install this sort of tool in Windows. iwr -useb get.scoop.sh | iex # install scoop scoop install coreutils vim nano [...] # yay
- malkia 5y ago
  Nice! I'll try it out tomorrow finally.. after giving up on choco, and possibly on winget. But in my case I wanted to leave something small (and busybox.exe is that small) /portable - for others to use (without the requirement to install scoop).
  - malkia 5y ago
    So scoop is awesome so far - the only thing I'm missing (right now) is to be able to specify specific bucket for some actions (but found workarounds).

pjmlp 5y ago

Usually it helps by adopting Windows development practices instead of trying to cram UNIX workflows into it. Who on their right mind uses ssh/scp on Windows development other than connecting to UNIX boxes?

maccard 5y ago
> Who on their right mind uses ssh/scp on Windows development other than connecting to UNIX boxes? Exactly. That's like complaining that I can't RDP into a linux box to install the toolchain!
simulate-me 5y ago
What’s the alternative? I was deploying from a Mac, so connecting to a Unix box is exactly what I was doing.
- pjmlp 5y ago
  A possible alternative. https://support.apple.com/guide/mac-help/share-mac-files-with-windows-users-mchlp1657/mac https://support.apple.com/guide/mac-help/share-mac-files-wit... https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-mac https://docs.microsoft.com/en-us/windows-server/remote/remot... Another alternative, https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/running-remote-commands https://docs.microsoft.com/en-us/powershell/scripting/learn/...
  - simulate-me 5y ago
    I was deploying to a fleet of servers. Having every engineer add every server via the macOS sharing UI or using RDP to manually connect to each host doesn’t seem scalable. Maybe remote power shell sessions would work, but I’m not even sure if there is a power shell client for Mac, and it’s also not clear if remote power shell sessions would fix the open file handle issue. Experienced Windows devs I talked to said they used Packer from Hashicorp to entirely recreate their server image whenever they wanted to deploy. This process takes hours, but that was the best I found.