This is coming to Windows stable in April: - vt sequences fixed (so stuff like colored output, midnight commander, etc work and the terminal doesn't screw up) - Elixir and Go work - Also Postgres and MySQL - You can launch Windows apps from bash. - inotify works - Visual Studio can compile with GNU/Linux C/C++ tools, gdb, linker etc There's some recent fast ring info on: https://blogs.msdn.microsoft.com/commandline/2…
> - vt sequences fixed (so stuff like colored output, midnight commander, etc work and the terminal doesn't screw up) Does this mean tmux will work?
Bash and Windows Subsystem for Linux Demo [video]
161–170 of 316 posts
Re: Bash and Windows Subsystem for Linux Demo [video]
#162Just a note to anyone looking to go down this road: IO performance is still pretty awful last I checked. If your workflow is IO intensive (non trivial Rails app, let's say), proceed w/ caution. https://www.reddit.com/r/bashonubuntuonwindows/comments/5ece... - My last check.
(Addendum) I did a Fast Ring update on a separate machine and did not see substantial performance improvements, but the comparison is not valid between the machine linked and the machine I tested on, so I'd be hesitant to say that the performance hasn't improved at all, just that IO performance is definitely a weak point to WSL.
We have some improvements coming in Creator's Update and more substantial improvements planned in future releases, once we've completed some work with the NT kernel filesystem team.
Re: Bash and Windows Subsystem for Linux Demo [video]
#163Now all we need is a first-party X server...
Any particular issues you've got with the existing third-party ones? I don't honestly use them often (I just work on the Windows side for 99%+ of the GUI stuff I need to do), but I've not had any issues with Xming, even on a HiDPI display.
1. Copy/Paste between Windows and XMing is pretty dicey. Sometimes I have to do 2-3 copy or paste attempts before one will go through. I got into the habit of hitting SHIFT+CTRL+C (or CTRL+INSERT) 3-4 times in every XMing window under the hope that one would take.
2. XMing's window previewing is kind of messed up. if you have multiple overlapping XMing application windows, the ALT+TAB and taskbar previews show the overlapped union of both windows, which makes it really hard to tell which one is wich if you have multiple terminals open or something.
3. On some applications, the DPI detection seems kind of wonky.
I even bought the paid version thinking it would fix this stuff, but it didn't :(
Re: Bash and Windows Subsystem for Linux Demo [video]
#164Dumb question: Why did they name this "Subsystem for Linux"? (Old name was Interix, subsystem for UNIX-based applications , or "SUA".) Does marketing/users believe there is a distinction between Linux as a kernel and GNU as a source for a userland? Irrelevant? Curious what others think.
Agreed. The name is backasswards; it should be "Linux Subsystem for Windows".
You'd be amazed how complex and difficult product naming can be ;)
Just be glad we didn't call it WSRPGLCB - Windows Subsystem for Running POSIX, GNU and Linux Compatible Binaries ;)
Re: Bash and Windows Subsystem for Linux Demo [video]
#165I've been running windows (using WSL for most of my development) for a few months and overall I'm very happy with it. Every non-GUI linux program I want to run works just fine on WSL, with the sole exception of (beta software) Urbit. I do miss Xmonad-like window management, but windows does have shortcut keys that do a good enough job. Emacs works perfectly well. And Anaconda ( https://www.continuum.io/downloads ) is…
Emacs has one flaw for me under WSL: the janky Windows console doesn't pass C-SPC. Meaning I have to bind set-mark-command to something else (like M-SPC), or download and use wsltty (fork of mintty). But other than that Emacs is fine, and a lot of Linux stuff (Node, mongo, etc.) works great. Who cares if Urbit doesn't work? :)
Re: Bash and Windows Subsystem for Linux Demo [video]
#166Earlier quoted context omitted.
Output from `bash --version` on macOS: `GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16) Copyright (C) 2007 Free Software Foundation, Inc.` that's a 10yr old bash and there's barely any shell magic that you can do on Linux that won't work on macOS. And since by far most devs use macOS, most binaries support at least the macOS version of bash. All in all, no need to worry :p
> by far most devs use macOS I'm not sure about this - that seems too extreme of a statement. If there is any winner, it's going to be Windows. IMO, Linux and macOS will be within 5 percentage points of each other. From what I've seen at university, it's something like 60% Windows, ~20% macOS, ~20% Linux (usually Ubuntu). Much more Linux/Mac in the "hackier" courses, usually with a slight majority to Macs. Where can…
That's all I need to say about that.
As for the reasons.. Devs want a POSIX (macOS, Linux or BSD) system because many of the utilities used are written for that, and much of the infrastructure you will be working with in the future will also be POSIX. Of all the POSIXes, macOS is by far the most capable and stable laptop OS. Macbooks are still unrivaled, with only the Dell XPS range coming somewhat close.
They are also the only company with both a solid phone and computer product, meaning you get lots of ecosystem goodies (verify iCloud logins with a push notification on your iPhone, Wi-Fi passwords entered on your MacBook instantly work on your phone, 'instant hotspot', AirPods intelligent multi-pairing, etc)
And that may seem like I'm drinking the Apple kool-aid, but I'm not. The audio quality on the AirPods is terrible. In fact, Apple has never produced anything but mediocre audio gear. The $200 price bump on the MBP 2016 is unjustified. Removing the headphone jack on the iPhone is utterly insane, even if they did use USB-C (maybe in 10 years when all audio-out ports on everything everywhere also uses USB-C it would have made sense). macOS stripping out all GPL tools because they don't want to use GPLv3 stuff, etc. etc. etc.
Re: Bash and Windows Subsystem for Linux Demo [video]
#167Earlier quoted context omitted.
Reposting a dead comment on this parent, because it's entirely reasonable. No, I believe they're not really after the enthusiasts. I think they're after the fence sitters. Implementing these tools on Windows removes motivation for casual dissenters from building intertia and leaving their platform. This is of course not the first time Microsoft has done something like this. Historically, step two is where they extend…
In the future, please vouch for comments you think should be visible to revive it. (link where the "flag" link would be on a non-dead comment)
Re: Bash and Windows Subsystem for Linux Demo [video]
#168The biggest problem I have with the WSL is that it is intrinsically tied to stable Windows releases; there is no way to get incremental updates for Bash on Windows unless you subscribe to the Windows Insider program, which is a way of running prerelease versions of Windows. So in order to get Linux features like inotify working you have to sacrifice the stability of your operating system. This looks like it'll be tru…
@OhSoHumble: Second Point: "A couple weeks back I tried to give WSL a try but everything was broken" Did you run an Insider build? 14986 completed a batch of inotify related syscall improvements since we first added inotify support in 14328 (Details here: https://msdn.microsoft.com/commandline/wsl/release_notes )
My problem was that the CLI built to help glue the two together didn't work on Windows so I tried it out in the WSL. Because of missing inotify support, hot reloading was broken. I found that I really missed that functionality so I moved to the fast ring of insider builds. After an update, node was completely broken. I didn't know how to switch to the slow ring to get a build that may have worked so I switched to developing to the Arch install I have on another drive.
Re: Bash and Windows Subsystem for Linux Demo [video]
#169Earlier quoted context omitted.
Re: Elixir The Erlang/OTP 19.x releases are still broken because of some missing system calls. They seem to have an incoming fix though: https://github.com/Microsoft/BashOnWindows/issues/613 It's great that they keep open conversations like this for issue tracking and hopefully April will be working 100% by then.
For this reason, whenever I try to develop anything on Windows, especially systems related stuff, I will do so in a VM. I may develop a test suite and try running it on Windows, but the Windows Linux Subsystem will never be reliable to me, until it aims to guarantee 100% compatibly.
Re: Bash and Windows Subsystem for Linux Demo [video]
#170This is coming to Windows stable in April: - vt sequences fixed (so stuff like colored output, midnight commander, etc work and the terminal doesn't screw up) - Elixir and Go work - Also Postgres and MySQL - You can launch Windows apps from bash. - inotify works - Visual Studio can compile with GNU/Linux C/C++ tools, gdb, linker etc There's some recent fast ring info on: https://blogs.msdn.microsoft.com/commandline/2…
> - vt sequences fixed (so stuff like colored output, midnight commander, etc work and the terminal doesn't screw up) Does this mean tmux will work?