Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

These days you go to the Microsoft App store and download Ubuntu. It loads up actual bash and comes with everything you'd expect. (ssh being just one of the things). The terminal emulation is improving (there are still a couple of glitches) but pretty much all of my daily tools work exactly correctly.

View on HN

For me, this is a huge thing.

When I bought my first Mac, back in the days of MacOS 10.2, I did so because of the BSD system underneath. Having a Unix system, whether its GNU or BSD, gives me access to tools that I'm familiar with and sometimes prefer to their GUI counterparts (e.g., scp/sftp vs FileZilla).

Now that Windows has this, switching back is something that I'm giving serious consideration to.

"Now that Windows has this, switching back is something that I'm giving serious consideration to."

It's not clear to me that Windows has this ...

I, like you, adopted the MacOS ecosystem because it was UNIX underneath ... but there's a big difference between underneath and alongside.

Although it is not commonly done, you can control and interact with your OSX system with UNIX commands ... there's one single filesystem namespace and you can interact with it from the command prompt as well as kill GUI apps or set preferences or ifconfig, etc.

It's my understanding that the Ubuntu subsystem in recent windows is sort of a parallel environment ... but is not meant to control the system directly or as an alternate path of interaction with Windows, correct ?

> It's my understanding that the Ubuntu subsystem in recent windows is sort of a parallel environment ... but is not meant to control the system directly or as an alternate path of interaction with Windows, correct ?

I am not so sure about this. I think Dustin Kirkland sheds some more light here:

http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.htm...

And he seems to be relatively excited about it so he benched it more recently:

https://www.linux.com/learn/howdy-ubuntu-windows-how-fast-it

It seems more like an inverse Wine than a parallel environment.

Alongside is an apt description. It feels a bit like running Linux in a Docker container.

The Windows Subsystem for Linux (WSL) has it's own directory in the Windows filesystem that corresponds to /. It's uses some NTFS magic to store the Linux file attributes that don't directly correspond to NTFS file attributes.

It also, within the Linux environment, mounts your host drives under /mnt.

For what I generally use the OSX terminal for, WSL probably hits about 80-90% of my use cases. A lot of lower level utilities have weird issues - e.g., 'ip addr' seems to present the Windows network interfaces as though they were typical Linux ones, 'ss -a' gives a bunch of netlink errors, dmesg says "dmesg: read kernel buffer failed: Function not implemented", 'tcpdump' doesn't work, etc. On the other hand, curl, scp, ssh, etc do exactly what you'd expect.

My limited experience with WSL gave me the impression that anything that needed /low level/ packet constructs either wasn't mapped correctly or might have required administrative privilege blessing on the Windows side of the environment ACLs.

I hope that these get filled out, at least with more constructive error returns, at some later date.

For now, I'm happy that they have enough of the low hanging fruit ripened sufficiently to make it possible to do 'normal' things from within WSL. I'd honestly rather they make the local (and network) filesystem more performant and robust; maybe they have.

My use case for WSL is coming around in the calendar year again so I'll be revisiting it soon.

The windows drives are mounted as /mnt/c, /mnt/d, etc...

You can call executables in both directions, even use windows executables in a bash script and pipe its output to awk.

https://docs.microsoft.com/nl-be/windows/wsl/interop#invokin...

One of the interesting things is that if Linux developed support for NTFS ACLs you could probably make it pretty seamless. One of the more convoluted parts of the NetApp filer code was the code that allowed for 'mixed' UNIX and CIFS volumes.

We're working on improving integration between Windows and Linux distros on WSL. Stay tuned for progress. The release notes on the WSL doc site [1] are basically our changelog. Highly recommended for the latest updates.

[1] https://docs.microsoft.com/en-us/windows/wsl/release-notes

Full disclosure, I work at Microsoft on WSL.

In the early days there was less interaction but it's getting pretty seamless now.

It's the same kernel underneath so it's not really two parallel systems.

To be completely fair to both sides though, the ability to tweak MacOS from terminal has always felt like it was opposed by Apple. They don't seem to support it officially in any capacity, and in many respects, actively fight it (i.e. changing the preference keys in every single release of MacOS, for literally no reason).

You can do some things to and with MacOS from CLI. Honestly though, it's all stuff I wouldn't miss awfully.

macOS is Unix. That's the big difference for me.

I've been using WSL + wsltty [1] + Xming [2] for months and didn't encounter major issues. wsltty also added support to the Microsoft Store version recently.

For Xming, simply set DISPLAY in shell and local GUI programs just work, as well as SSH X forwarding.

[1] https://github.com/mintty/wsltty

[2] https://sourceforge.net/projects/xming/

(EDIT: typo)

I tried this, but I found that my Ubuntu subsystem could not access my wifi connection at all, no matter what I tried. I remember reading Microsoft forums where developers from Microsoft acknowledged they were working through the issue. It still hadn't been resolved the last time I checked.

I'm on a Dell XPS 15 9560 if that matters.

> I'm on a Dell XPS 15 9560 if that matters.

It does as I've had no issues personally on as self-built desktop, an ASUS laptop, a MacBook running Bootcamp, and now a Surface Laptop.

Is there any advantages over using Ubuntu itself directly?

The big advantage is that it runs within Windows, so you can use your Windows and Linux tools at the same time. It's also not done as a virtual machine, so the Ubuntu running on Windows can access and manipulate files on your Windows system very easily.

Albeit very slowly. Unless they fixed it recently, writing to a vast amount of files is very slow compared to native Linux. Anyone who has cloned a large repository I'm sure is aware of this.

I felt like file speed sped up quite a bit in the Fall Creators Update, though of course that notion is entirely anecdotal.

Also, the native Windows git is still your best bet for git operations. That's one of the cases where I will have a PowerShell and an Ubuntu bash window side-by-side, working in the same /mnt/d/... | D:\... directory. git operations in PowerShell and Jekyll (or whatever) operations in Ubuntu bash.

Does it make a difference if you run your git operations through cmd from the bash command line? If so, is there a simple way to automatically get the current windows path from pwd? If it's the same speed as native git running in a separate window (I think it should be), it might be worth coming up with some kind of script to do this automatically. Not sure how to get that working with using Linux tools within git, though (editing commit messages, diffing, etc). Also, how does file speed within the Linux environment (/home/username) compare to that outside (/mnt/C/whatever)?

Also, they _really_ chose a poor name for that executable; it should have been wsl.exe or some such, not bash.exe. At least lxss.exe isn't already in use by other software in my path...

I hadn't thought about that (I use PowerShell for most tasks so that is still my "home" shell and it's bash that's the rare one), but I half remembered something to that effect, so I went to the docs:

https://docs.microsoft.com/en-us/windows/wsl/interop

Calling Windows EXEs from bash will automatically retain the current working directory under /mnt/c/*, so it should just work out of the box. Looks like you might be able to get away with just adding native Windows git to your bash path.

Yeah for example I have composer only installed in Windows (EXE) and not within WSL and it works fine within the bash prompt.

We just released a tool to do the right path translation -- wslpath. Unfortunately we haven't added built in usage info yet. Here's a link[1] to usage info in recent Windows Insider flights.

Also, totally fair feedback about the naming. In FCU, we added wsl.exe in addition to bash.exe. It launches into your default shell rather than /bin/bash.

[1] https://github.com/Microsoft/WSL/issues/2715

* I work at Microsoft on WSL

Well not if you aren't using other parts of Windows :-) but if you are constrained to using Windows for other reasons then the advantage is you get all the tools with a much lighter weight system than say running a virtual machine.

There are also some systems where kernel support for the devices is lagging, either because they are proprietary and poorly documented or because they have insufficient market penetration to get someone interested in writing good driver support. For example support for the pen on the Surface Pro 4 line is really horrible (IMHO) on Linux.

So these devices need real kernel drivers? Windows doesn't provide some kind of emulation through its own drivers? I guess that makes sense although it didn't occur to me.

If that's true, will those new drivers also work on a regular non-Windows Linux install? That would be really great news, and pretty ironic, if device manufacturers or even Microsoft itself were suddenly writing more/better drivers for the Linux kernel. :-)

The grandparent is saying that if you run plain Ubuntu directly on a device, Ubuntu (or really, the Linux kernel) might not have drivers that work reasonably well for some hardware on that device, while Windows most certainly does have decent drivers for that hardware.

When you run Ubuntu on top of windows, windows replaces/emulates the Linux kernel - at least the part it needs to run the subset of Ubuntu that windows currently can - this emulation provided to run Ubuntu is done on the interface between the kernel and userspace, it is not done on a device/driver level.

Drivers are OS specific, the drivers in question here are either windows drivers, which works only on windows, or they are linux drivers which work only on linux. (Noone is writing drivers for windows which could also work on linux)

It's not an emulator. The NT kernel really does support the necessary system calls.

Sure, but there's a layer that emulates the linux syscalls. Though perhaps it's more appropriate to call it "translates" instead of emulate.

Its not a layer on top of the NT system call infrastructure. Its brand new NT system calls that do exactly what the equivalent Linux ones do. There is no combination of win32 NT system calls that will get you the behavior of fork().

Aren't the NT system calls also just a personality module above the actual NT kernel? The kernel was originally designed to provide multiple kinds of user spaces so that it could run OS/2 programs alongside Win32 ones.

No. win32 is a personality, the underlying ntdll calls are not part of that.

Of course not! It's quite the opposite. With more and more people ditching 'real' Linux for WSL (which is a 'Linux kernel API layer' for the Windows kernel, there is actually NO Linux kernel involved), support for the relevant hardware is never going to happen in Linux proper.

That you can keep using Windows seamlessly?

I haven't done this yet, thanks for the reminder! I've been curious to try it as I've gone through probably every other bash emulator on Windows and not been overly satisfied.

I would love to hear how it works or doesn't work for you! I have shown it to lots of folks and probably a quarter have some aspect that keeps it from being perfect (generally a terminal issue or the lack of a Microsoft provided X server. For the latter I use xwin32 [1] which works fine but may not be accelerated if your display controller isn't supported.)

[1] https://www.starnet.com/xwin32/

I'm just getting set up yet, but so far so good! I haven't run anything too complex just yet, but it seems really performant and doesn't put a significant load on my system.

Next up is to try running something more taxing, and then look into GPU access from within it.

I'm looking forward to them developing the subsystem further.

That's all fine and dandy until you want to develop Windows applications using Ubuntu on Windows.

There's still a place for windows native tools.

I install OpenSUSE Command line from the Windows Store.

Reply on news.ycombinator.com