1. How to use Bash on Windows to retain your previous setup: 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-a...
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.
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.
As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops.
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.
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.
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?
Windows command prompt compared to bash is simply horrible. I personally find Powershell to be just as bad. The console app in windows is still light years behind Terminal in OS X. In fact VSCode's built in terminal wrapper is orders of magnitude better.
Things like wkhtmltopdf to generate PDFs or ffmpeg to work with videos should run as they do in Linux on the production server. In OS X I can use brew to set things up. In windows I have to hunt down binaries, put them in the right place, and set the path manually via an OS level GUI many clicks down in Advanced Settings.
The extra work I need to do to make all those tools work in windows makes setting up a windows dev environment cumbersome and annoying. The way it's laid out in OS X gives me way cleaner interoperability with the way the code actually runs in a Linux environment.
It's one of the reasons I love WSL! Finally I can have a ~/.ssh/config in Windows! But I still can't edit the file from a Windows text editor.
Finally if I'm on a team where the production environment relies on some of these linux binaries being available I don't want to waste work hours researching and writing on boarding documentation for the one dev that feels like working in windows when the rest of us are on macs.
Unless i'm misunderstanding the issue
For this reason, it is recommended to only edit files outside this directory from both subsystems (not to say this isn't issue-free, but it's relatively reliable.)
It says officially: don't edit ubuntu files from windows editors, so it's not their fault. But not ready for 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.
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.
The second the paradigm changes, the value equation changes for everyone involved.
> 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.
SSDs, primarily. Depending on who you ask, defragging an SSD ranges between only slightly beneficial, totally pointless, and actively harmful.
Fragmentation will slow down your SSD. For non-server workloads, the SSD is very likely still plenty fast. Running a hard drive defragging program on your SSD will only address one of the two forms of fragmentation that SSDs are subject to, and thus will not help performance much. It will also unnecessarily burn through some of the SSD's limited write endurance, but that is almost never worth worrying about.
"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.
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.