Comment by godot | Hacker News Reader

Comment by godot | Hacker News Reader

I've used it a bit but not seriously/professionally. My biggest issue was that after installing NVM and node, startup of the terminal took literally seconds. It was so bad that I had to move the NVM init lines from bashrc to an alias and I only run it when I know I'm working on node stuff. Not sure if it was just me or everyone else too.

Other gripes include relatively little customization for the terminal window. You can customize colors and fonts. But I don't remember it even supporting tabs.

Also the disk volume of your Linux subsystem is relatively separate from Windows, so if you wanna have an IDE edit code in a folder and run such code in the Linux terminal, you have to cd into some strange volume path to get there. Can work around it by creating a symlink from your home dir.

Ultimately my opinion is if you want Windows/Linux and not buy into the Mac ecosystem, it's better to just dual boot Win/Linux and only boot into Windows if you need to use some software not on Linux.

I am a big fan of WSL. It is fast, and you can run many different Linux distros side-by-side. There were some quirks in the past, but it almost always just works. I see it as a serious alternative to using a Mac or Linux machine.

In all fairness to the points above:

- The Linux shell starts immediately without NVM. As mentioned, this isn't only a Windows issue. (Alternatively, you can only load NVM when needed.)

- The home directory can be permanently changed with just a few Linux commands. (I agree that the default should have been your Windows home directory.)

- Many excellent third-party Windows terminals exist. (Window's default terminal is not user-friendly.)

The NVM init slowness issue isn't specific to WSL - see https://github.com/creationix/nvm/issues/1277. I also had to sandbox the NVM init lines (on macOS) as timing my .bashrc revealed it as the worst offender.

On the topic of speeding up terminal startup, I can recommend https://github.com/benvan/sandboxd for managing various shell initialization scripts to only be run or sourced at the point where they are needed.

Notably, I have NVM setup to auto init on a work MBP and two personal Linux laptops before, on Antergos (Arch) and CentOS (on a very old and slow laptop even), and terminal startup time is still near instant in all cases. Issue was definitely isolated to WSL in my experience.

I use WSL with ConEmu professionally. ConEmu has all the usual terminal bells and whistles.

Overrall it works pretty well, I'm rarely reminded that this isn't Linux or a Mac (as long as I'm just looking at the terminal). I still prefer working on a Mac (pre-crazy-keyboard), but this is a serviceable replacement for working on your standard web frontend stack. Once in a blue moon NPM will produce some esoteric WSL-only error that will take hours to debug, but that's rare.

> Ultimately my opinion is if you want Windows/Linux and not buy into the Mac ecosystem, it's better to just dual boot Win/Linux

This was my first impression, but after seeing this really streamlined option available, I thought I'd give it a go. Haven't tried to go too in-depth as of yet. If this route doesn't prove viable then I'll probably go the dual boot route.

I'm not OP, but thanks for writing this. I just bought my first PC in ages last weekend and was thinking of installing the Linux subsystem. I appreciate your review and the advice at the end.

Also where can I find the dir for this Linux subsystem? (still a Windows noob)

Be careful what you mess with in Windows regarding these folders. The WSL does not react as one might expect to changes made to its files using Windows (ie you can easily screw it up and have to in reinstall if you make changes to important WSL files via Windows).

The folder for WSL Ubuntu is usually here:

C:\Users\<username>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState

Your root directory should be here:

C:\Users\<username>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs

In short ... DON'T!

Assume that your distro's are locked away behind a one-way wall - Linux can see Windows files, but Windows cannot (safely) use Linux files. More details here: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...

And yes, we're working to close this gap in future releases, so stay tuned!

Reply on news.ycombinator.com