7 ms·

Hey! Writer here. I discuss the software at length in here, but as I point out in the piece I've already covered why WSL and Bash work very well at length, so d

Hey! Writer here. I discuss the software at length in here, but as I point out in the piece I've already covered why WSL and Bash work very well at length, so didn't want to muddy the water too much: 1. How to use Bash on Windows to retain your previous setup: https://char.gd/blog/2017/how-to-set-up-the-perfect-modern-dev-environment-on-windows https://char.gd/blog/2017/how-to-set-up-the-perfect-modern-d... 2. Why WSL/Bash is good enough these days: https://medium.com/charged-tech/why-i-left-mac-for-windows-apple-has-given-up-b48c0eaac64 https://medium.com/charged-tech/why-i-left-mac-for-windows-a...

singularity2001 8y ago
I tried Bash on Windows and it was absolutely not good enough. Not yet.
- fgonzag 8y ago
  What problems did you find it with it? I've been using it for the past 6 months after dual booting and running VMs for a long time and found I haven't found a reason to boot into my VM yet.
  - hackujin 8y ago
    I can't open files in VSCode that live in the WSL virtual file system. Which is a huge problem for setting up the same exact dev environment I have on my Mac. It's honestly dumbfounding. VSCode works great on Mac with the existing terminal but the WSL team can't figure out a good way to allow you to edit WSL files from a normal Windows application.
    - freeone3000 8y ago
      The way you do this is to cd into your Windows system from within WSL. WSL can see files from the Win32 subsystem just fine.
      - hackujin 8y ago
        That is not a solution. I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files. As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops.
        BinaryIdiot 8y ago
        > I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files. No. You don't want this. Linux and Windows are different platforms; if your Windows application could use your packages installed through Linux (and vice versa) then none of the native modules would work without a reinstall. The side effects suck and they can make it better IMO but not sharing dependencies isn't an issue at all IMO. > As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops. Yeah that sucks though for some things like git bash, etc, they use the proper windows home directory. So I end up just keeping those there and straight up copying or aliasing them to the WSL home folder. It's not a great experience but it works.
        hackujin 8y ago
        Of course I want this! Globally installed npm and composer packages live in ~/.npm/ and ~/.composer/ and they both have a global packages.json esque file that I need to occasionally edit. The packages installed in those folders MUST be parsed by VSCode for intelesense to work properly. All I'm saying is I'm not gonna jump through all these hoops. I'd rather just keep working on my mac. Hell I'd rather hackintosh a surface pro rather than deal with these issues. Running VSCode through X is annoying.
        ivan_gammel 8y ago
        npm/node works fine in Windows (and I'm pretty sure it's the same with composer), so why do you want to use it in WSL? Edit: this is a genuine question of an engineer, who uses Git/npm/node for fullstack development on Windows 10 every day. What kind of setup do you have and what UX do you expect, that requires running the tools in WSL?
  - singularity2001 8y ago
    file corruption was the worst, incomplete apt package support second. It says officially: don't edit ubuntu files from windows editors, so it's not their fault. But not ready for work.
  - stefan_ 8y ago
    IO performance is atrocious. git status on a Linux tree takes a 10s of seconds.
    - ivan_gammel 8y ago
      Git works perfectly in PS, why would you need to run it in WSL?
      - squeaky-clean 8y ago
        Not the original commenter, but I do everything else in bash, and zero things in PS. Why would I want to remember which shell runs which program best?
        ivan_gammel 8y ago
        That makes sense, however if you are Windows user, bash is not an obvious choice for primary shell there.
        sigzero 8y ago
        I don't think that is correct. If you install WSL you are not a typical Windows user.
        ivan_gammel 8y ago
        I didn't mention "typical" Windows user. WSL will always be a second-class citizen in Windows, so if you are power user trying to improve your performance, what's the point in choosing a second-class solution after choosing this OS? Learning one more shell, just like learning one more programming language, has some benefits.
        squeaky-clean 8y ago
        Because I like Windows for myself but my company uses Linux based servers and bash as our shell. It's not just about ME switching to PowerShell, but getting 30 other people to do it too. Not gonna happen.
  - oneplane 8y ago
    I have the same problems as most people: it's a separate subsystem, which means you either need special integration or simply can't do what you want to do. The filesystems aren't the same, the devices aren't the same, the networking isn't the same, and all three are pretty much needed for daily work. I suspect that most things that you can do in mingw64 will work the same in WSL, but things you need to do beyond that are basically broken in WSL and sub-optimal in mingw and almost always gets you to a point where you need a VM. At the same time WSL has super limited benefit if you don't need any of the windows stuff, it basically means you are using linux inside windows but not using windows. When you use 'shell oriented workflows' on macOS, it just works, be it with BSD vs. GNU diffrences, which are easy to overcome by either learning or installing GNU versions of the tools you want (using a package manager like brew). In this setup, everything is the same system, what you do in the GUI also exists in the CLI, they interact directly with eachother, maintain state equally well, integrate directly with the rest of the OS, and basically has desktop functionality that isn't in the way of your development capabilities. The only downside you can expect is if you need native windows development or windows-only tools, for everything else, windows doesn't really count anymore in almost all environments where I work (which is mostly retail, ecommerce, FOSS, infra). Only a small subset of things (large in quantity, small in configurations/versions/specific needs) that are managed by MSP's are still embedded windows or enterprise windows. We do have a few people that actually like windows (be it the GUI, long time experience or simply brand affinity), but that's about it.
    - hirsin 8y ago
      Can you provide some examples? I've used the fs and networking without issue, so I'm wondering where you hit issues. I can host a server in WSL and hit it from windows via localhost. I can download a repo in windows and access it from emacs, I can download a repo using Linux git into a windows file system and edit it from either OS. Is it that some parts of Berkley sockets aren't implemented fully (or weren't last time I took it for a spin last year)?
  - qubitcoder 8y ago
    I periodically boot into Windows 10, mainly for join.me calls with customers, and I'm always curious to see how the WSL is progressing. It's clearly come a long ways, and I'm encouraged by the recent support for multiple Linux distributions. But for development purposes, it's doesn't yet come close to replacing a native Linux environment. The performance is frankly terrible by comparison -- for example, running `bundle install` in a moderately complex Rails application will take nearly an order of magnitude longer (not to mention the Windows virus scan process soaking up 30% of your CPU the entire time). Another issue is with background services -- I've had numerous issues running PostgreSQL, Redis, and other services (e.g. some services fail to start, or cannot be cleanly stopped, or I'll encounter strange network errors). However, these issues are all documented extensively in various GitHub issues, so hopefully they'll be resolved going forward. For PostgreSQL, the usual suggestion is to install PostgreSQL in Windows, and then access it from the WSL, but that kind of defeats the purpose. I don't mean to be overly negative, but at least for my purposes, the WSL just isn't quite there in terms of being a viable alternative for daily development work.
- deleted 8y ago
  [deleted]
- voltagex_ 8y ago
  Did you raise any issues on GitHub for the problems you hit?
Pica_soO 8y ago
Have you tryied ignoring the annoyingyang major points of opinion popups with <microsoft-product-placement>? The windows is dead, but the M$ Fish-trap attitude exists on in the Eco-system, being natural opposed to all things open to the source.
jaxn 8y ago
I second the WSL recommendation. I use it every day building a large SaaS product that is Rails (backend and legacy front end), Vuejs, C# (WinForms app for deep system integration on point-of-sale computers).
redial 8y ago
Although WSL is great, having a system that could lock itself and start updating at any moment even ignoring user preferences is unacceptable. Trust is at the core of a lot of complaints against Windows, and Microsoft is not helping by forcing updates or reinstalling applications/ads the user specifically removed.
- Joeri 8y ago
  I use windows 10 on several computers and while I did see that updates-mid-day behavior in the beginning I haven’t seen it in a long time. I’m not sure whether this is a real problem anymore, especially with windows pro where you can defer updates.
mettamage 8y ago
How about stuff like defragmentation, Windows registry issues, malware, adware and all the other stuff I vaguely remember? 10 years ago, I used to be a power user at Windows before that (as a gamer/kid) but really though I forgot what time I needed to put into the laptop just to keep it up to performance.
- ivan_gammel 8y ago
  Defragmentation is something from prehistoric ages of Windows (if I remember correctly, they made it automatic in Vista). Malware, adware etc are the same class of problems as unprotected sex: if you are careful, you are safe and will never see it. It's not a Windows "feature".
  - moate 8y ago
    I've always felt this was just the law of large numbers: The world has more PC users running Windows, so people who are writing malware would be casting the widest net by attacking PCs running Windows and since the bad guy is also likely using/familiar with a PC running Windows. The second the paradigm changes, the value equation changes for everyone involved.
- ufmace 8y ago
  Have you not used a Windows computer in 10+ years? > defragmentation No longer an issue. I'm honestly not up to date on why not, but nobody ever mentions it anymore. > Windows registry issues What issues? I haven't gone into the registry for anything in a long time. > malware, adware Not an issue as long as you run a modern browser and avoid going to sketchy websites and installing random things from them. If you haven't used Windows since early XP, it's really worth another try. It's a whole lot better now.
  - RcouF1uZ4gsC 8y ago
    A point to add about malware. Make sure your user account your use is a standard one and not an Administrator account. That goes a long way towards cutting down on potential malware.
sneak 8y ago
My previous setup was “any modern os except the windows trash fire”. I’m not sure how WSL is going to solve that.
syn_rst 8y ago
That's exactly the problem: they work well enough for some limited applications. Thing is, "well enough" isn't a reason to get people moving to MS's platform - if I already have a great dev environment that runs on Mac or Linux, why would I switch? I already have perfect integration between my CLI tools and the OS, first-class support in a lot of FOSS projects, and a strong community around the platform, all of which I'd lose if I switched. In exchange I'd gain nothing but the numerous headaches (forced updates, spyware, in-OS ads, general cruft and legacy baggage, etc) of Windows. "Good enough" might stop people switching away from the platform, but it's not enough to bring back those who've already left. If Microsoft wants to bring people back to Windows as opposed to just stopping the bleeding, they'll have to deliver an experience that's actually superior to the other platforms. Given the current state of Windows 10, I don't think they'll have an easy time pulling that off.

singularity2001 8y ago

I tried Bash on Windows and it was absolutely not good enough. Not yet.

fgonzag 8y ago
What problems did you find it with it? I've been using it for the past 6 months after dual booting and running VMs for a long time and found I haven't found a reason to boot into my VM yet.
- hackujin 8y ago
  I can't open files in VSCode that live in the WSL virtual file system. Which is a huge problem for setting up the same exact dev environment I have on my Mac. It's honestly dumbfounding. VSCode works great on Mac with the existing terminal but the WSL team can't figure out a good way to allow you to edit WSL files from a normal Windows application.
  - freeone3000 8y ago
    The way you do this is to cd into your Windows system from within WSL. WSL can see files from the Win32 subsystem just fine.
    - hackujin 8y ago
      That is not a solution. I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files. As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops.
      - BinaryIdiot 8y ago
        > I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files. No. You don't want this. Linux and Windows are different platforms; if your Windows application could use your packages installed through Linux (and vice versa) then none of the native modules would work without a reinstall. The side effects suck and they can make it better IMO but not sharing dependencies isn't an issue at all IMO. > As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops. Yeah that sucks though for some things like git bash, etc, they use the proper windows home directory. So I end up just keeping those there and straight up copying or aliasing them to the WSL home folder. It's not a great experience but it works.
        hackujin 8y ago
        Of course I want this! Globally installed npm and composer packages live in ~/.npm/ and ~/.composer/ and they both have a global packages.json esque file that I need to occasionally edit. The packages installed in those folders MUST be parsed by VSCode for intelesense to work properly. All I'm saying is I'm not gonna jump through all these hoops. I'd rather just keep working on my mac. Hell I'd rather hackintosh a surface pro rather than deal with these issues. Running VSCode through X is annoying.
        ivan_gammel 8y ago
        npm/node works fine in Windows (and I'm pretty sure it's the same with composer), so why do you want to use it in WSL? Edit: this is a genuine question of an engineer, who uses Git/npm/node for fullstack development on Windows 10 every day. What kind of setup do you have and what UX do you expect, that requires running the tools in WSL?
- singularity2001 8y ago
  file corruption was the worst, incomplete apt package support second. It says officially: don't edit ubuntu files from windows editors, so it's not their fault. But not ready for work.
- stefan_ 8y ago
  IO performance is atrocious. git status on a Linux tree takes a 10s of seconds.
  - ivan_gammel 8y ago
    Git works perfectly in PS, why would you need to run it in WSL?
    - squeaky-clean 8y ago
      Not the original commenter, but I do everything else in bash, and zero things in PS. Why would I want to remember which shell runs which program best?
      - ivan_gammel 8y ago
        That makes sense, however if you are Windows user, bash is not an obvious choice for primary shell there.
        sigzero 8y ago
        I don't think that is correct. If you install WSL you are not a typical Windows user.
        ivan_gammel 8y ago
        I didn't mention "typical" Windows user. WSL will always be a second-class citizen in Windows, so if you are power user trying to improve your performance, what's the point in choosing a second-class solution after choosing this OS? Learning one more shell, just like learning one more programming language, has some benefits.
        squeaky-clean 8y ago
        Because I like Windows for myself but my company uses Linux based servers and bash as our shell. It's not just about ME switching to PowerShell, but getting 30 other people to do it too. Not gonna happen.
- oneplane 8y ago
  I have the same problems as most people: it's a separate subsystem, which means you either need special integration or simply can't do what you want to do. The filesystems aren't the same, the devices aren't the same, the networking isn't the same, and all three are pretty much needed for daily work. I suspect that most things that you can do in mingw64 will work the same in WSL, but things you need to do beyond that are basically broken in WSL and sub-optimal in mingw and almost always gets you to a point where you need a VM. At the same time WSL has super limited benefit if you don't need any of the windows stuff, it basically means you are using linux inside windows but not using windows. When you use 'shell oriented workflows' on macOS, it just works, be it with BSD vs. GNU diffrences, which are easy to overcome by either learning or installing GNU versions of the tools you want (using a package manager like brew). In this setup, everything is the same system, what you do in the GUI also exists in the CLI, they interact directly with eachother, maintain state equally well, integrate directly with the rest of the OS, and basically has desktop functionality that isn't in the way of your development capabilities. The only downside you can expect is if you need native windows development or windows-only tools, for everything else, windows doesn't really count anymore in almost all environments where I work (which is mostly retail, ecommerce, FOSS, infra). Only a small subset of things (large in quantity, small in configurations/versions/specific needs) that are managed by MSP's are still embedded windows or enterprise windows. We do have a few people that actually like windows (be it the GUI, long time experience or simply brand affinity), but that's about it.
  - hirsin 8y ago
    Can you provide some examples? I've used the fs and networking without issue, so I'm wondering where you hit issues. I can host a server in WSL and hit it from windows via localhost. I can download a repo in windows and access it from emacs, I can download a repo using Linux git into a windows file system and edit it from either OS. Is it that some parts of Berkley sockets aren't implemented fully (or weren't last time I took it for a spin last year)?
- qubitcoder 8y ago
  I periodically boot into Windows 10, mainly for join.me calls with customers, and I'm always curious to see how the WSL is progressing. It's clearly come a long ways, and I'm encouraged by the recent support for multiple Linux distributions. But for development purposes, it's doesn't yet come close to replacing a native Linux environment. The performance is frankly terrible by comparison -- for example, running `bundle install` in a moderately complex Rails application will take nearly an order of magnitude longer (not to mention the Windows virus scan process soaking up 30% of your CPU the entire time). Another issue is with background services -- I've had numerous issues running PostgreSQL, Redis, and other services (e.g. some services fail to start, or cannot be cleanly stopped, or I'll encounter strange network errors). However, these issues are all documented extensively in various GitHub issues, so hopefully they'll be resolved going forward. For PostgreSQL, the usual suggestion is to install PostgreSQL in Windows, and then access it from the WSL, but that kind of defeats the purpose. I don't mean to be overly negative, but at least for my purposes, the WSL just isn't quite there in terms of being a viable alternative for daily development work.
deleted 8y ago
[deleted]
voltagex_ 8y ago
Did you raise any issues on GitHub for the problems you hit?

Pica_soO 8y ago

Have you tryied ignoring the annoyingyang major points of opinion popups with <microsoft-product-placement>? The windows is dead, but the M$ Fish-trap attitude exists on in the Eco-system, being natural opposed to all things open to the source.

jaxn 8y ago

I second the WSL recommendation. I use it every day building a large SaaS product that is Rails (backend and legacy front end), Vuejs, C# (WinForms app for deep system integration on point-of-sale computers).

redial 8y ago

Although WSL is great, having a system that could lock itself and start updating at any moment even ignoring user preferences is unacceptable. Trust is at the core of a lot of complaints against Windows, and Microsoft is not helping by forcing updates or reinstalling applications/ads the user specifically removed.

Joeri 8y ago
I use windows 10 on several computers and while I did see that updates-mid-day behavior in the beginning I haven’t seen it in a long time. I’m not sure whether this is a real problem anymore, especially with windows pro where you can defer updates.

mettamage 8y ago

How about stuff like defragmentation, Windows registry issues, malware, adware and all the other stuff I vaguely remember? 10 years ago, I used to be a power user at Windows before that (as a gamer/kid) but really though I forgot what time I needed to put into the laptop just to keep it up to performance.

ivan_gammel 8y ago
Defragmentation is something from prehistoric ages of Windows (if I remember correctly, they made it automatic in Vista). Malware, adware etc are the same class of problems as unprotected sex: if you are careful, you are safe and will never see it. It's not a Windows "feature".
- moate 8y ago
  I've always felt this was just the law of large numbers: The world has more PC users running Windows, so people who are writing malware would be casting the widest net by attacking PCs running Windows and since the bad guy is also likely using/familiar with a PC running Windows. The second the paradigm changes, the value equation changes for everyone involved.
ufmace 8y ago
Have you not used a Windows computer in 10+ years? > defragmentation No longer an issue. I'm honestly not up to date on why not, but nobody ever mentions it anymore. > Windows registry issues What issues? I haven't gone into the registry for anything in a long time. > malware, adware Not an issue as long as you run a modern browser and avoid going to sketchy websites and installing random things from them. If you haven't used Windows since early XP, it's really worth another try. It's a whole lot better now.
- RcouF1uZ4gsC 8y ago
  A point to add about malware. Make sure your user account your use is a standard one and not an Administrator account. That goes a long way towards cutting down on potential malware.

sneak 8y ago

My previous setup was “any modern os except the windows trash fire”. I’m not sure how WSL is going to solve that.

syn_rst 8y ago

That's exactly the problem: they work well enough for some limited applications. Thing is, "well enough" isn't a reason to get people moving to MS's platform - if I already have a great dev environment that runs on Mac or Linux, why would I switch? I already have perfect integration between my CLI tools and the OS, first-class support in a lot of FOSS projects, and a strong community around the platform, all of which I'd lose if I switched. In exchange I'd gain nothing but the numerous headaches (forced updates, spyware, in-OS ads, general cruft and legacy baggage, etc) of Windows. "Good enough" might stop people switching away from the platform, but it's not enough to bring back those who've already left. If Microsoft wants to bring people back to Windows as opposed to just stopping the bleeding, they'll have to deliver an experience that's actually superior to the other platforms. Given the current state of Windows 10, I don't think they'll have an easy time pulling that off.