Bash and Windows Subsystem for Linux Demo [video]
channel9.msdn.com
channel9.msdn.com
- 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/2017/01/09/bash...
From reading that blog, and also: https://github.com/Microsoft/BashOnWindows/issues/111#issuec... it sounds as if the Windows console (separate from bash, openssh, powershell etc) is being entirely refactored for creators update. So those fixes should also help powershell, ConEmu and a bunch of other common windows command line stuff.
People of a certain age remembered well the power and simplicity of using DOS and its "console" to effectively develop code and debug, even without typing 'win' to get into "GUI mode".
But at this event a very senior engineer/architect in the Windows group (no longer with Microsoft) responded to my question of command line support with a very snarky response which was something along the lines of "It is called Windows not relic from the 70's so no, we really don't care if you can't use it like a time sharing system any more." And that was the way it was, anything you could do on the command line you could do in a GUI window with radio buttons and various text boxes.
And what was why I switched to MacOS as my daily driver because my personal style had me so much more productive in "terminal" mode than in "gui" mode, I preferred it.
Now you have Microsoft investing real time and effort to create credible command line type tools in their system and it is a remarkably good thing. I use WLS every day and its getting better and better. I have suggested they implement a local network service equivalent of the USB over Ethernet service so that you can easily share USB devices between the Windows side and the Linux side, the up coming visual fixes will address many of the minor annoyances. That is a really huge shift for Microsoft.
While one can do at least as much, if not more, via a variety of command-line tools, the integrated build & debug workflow of a good IDE is invaluable to many. Esp. for those for whom learning a multitude of command-line tools, and syntaxes to drive gdb, profilers, etc. as a little costly/cumbersome.
First VS Core, now VS proper. Impressive!
(going back to my ddd window on Linux, crying a bit inside).
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.
But they really need to fix notepad so it supports unix style line endings. That part of the demo was a bit embarrassing.
I was already a fan of colinux back then but this has te potential of being infinitely better.
An alternative approach would be to call it Winbuntu, Winux, or simply Ubuntu for <windows subsystem architecture>. Then aggressively maintain a list of known compatibility issues, and stay on top of fixing them. Maybe even open source it?! A close sourced, not-quite-what-I-wanted solution is simply less interesting to me.
The speed at which they can push new builds to people who aren't on Windows Insider is a bit unfortunate, though.
You need to handle this anyways, as it's unlikely that your target deploy platform will always be ubuntu. In any case, you can just use docker like most OSX folks do now.
So I can basically do `code .` from inside bash and it will open VS Code in the linux sub-system folder? That's amazing!
It has worked well for me to make a symlink under ~ to /mnt/c/Users/myaccount/, and that way anything under that symlinked folder is visible to WSL and Windows programs.
If you just want to type `code <filespec>` (without the .exe), then you can create an alias that resolves to code.exe.
Same for Notepad, etc. :)
Hey Rich, can you (or colleagues) tell us any news on console? I get the vibe from Michael Niksa back in August [1] [2] there's a big changes happening that will fix readline-type stuff and I'd love to know more about this - I use ConEmu / Win32 SSH on Windows and it, was well as bash, seem to occasionally suffer from terminal-corrupting weirdnesses.
I'd love to know more about the causes, the fixes, whether the fixes will make it into Creators Update, etc.
[1] https://github.com/Microsoft/BashOnWindows/issues/111#issuec...
[2] https://github.com/Microsoft/BashOnWindows/issues/111#issuec...
It's important to remember that the Console was one of the first things Cutler & team implemented when they started NT itself, and it's been updated, patched, partially-enhanced and modified quite a few times in the last 30+ years! ;)
We're in the process of modularizing much of the Console's internals, replacing particularly archaic parts with shiny new modern C++ collections, etc., removing unnecessary cruft, etc. ... while trying not to break anyone!
Much of the work we're doing right now will result in Maximus5 & the Console2 / ConsoleZ / etc. teams having to jump through far fewer hoops to implement decent terminals on Windows.
And while we're doing this, we're also enhancing the console to support *NIX VT sequences, adding 24-bit color, etc., working with several other teams around Microsoft who need Console changes to make their things work.
This week, we are planning & building features for the NEXT OS release!
As you can imagine, it takes considerable effort and care to do this and we've got a great team with Michael, Paul, Mike2 & Austin beavering away as I type.
Actually; small lie - Niksa is on vacation this week re-charging his fuel cells before I chain him to his desk again ;)
We'll be writing a series of blog posts in the coming weeks, summarizing what's new in Bash & Console in Creators Update, and will have some cool stuff to show off at Build 2017!
I'll also be speaking at OSCON 2017 in Austin (same week as Build!!), so stop-by if you're in TX and want to chat about Bash / Console :)
https://conferences.oreilly.com/oscon/oscon-tx/public/schedu...
Regarding future work, are there any plans to make the emulated Linux filesystem usable in the rest of Windows e.g. via a drive mapping?
We are keen to smooth out some of the filesystem interop challenges. There's a reason we've not yet removed the Beta label ;)
For example, using windows explorer to edit linux sub-system files would be a big no-no.
However, it's fine to modify files stored in your Windows filesystem from within Bash, so if you were in `/mnt/c/dev/project/` and launched `code.exe ./`, Code would open the current (Windows-accessible) folder.
There is some weirdness with the recommended file system sharing. Git on WSL sees files as modified after they have been checked in from Windows. It means I either use Git from the IDE or from the terminal, but not both.
Excited to see how this continues to improve.
What you're seeing with git is likely to be caused by line ending differences. You've probably got "Convert line endings to Windows" configured in your Git on Windows, but "Checkout Linux line endings on Linux". Either way, both should match otherwise all your files will look different because ... well ... they will be ;)
HTH
EDIT: Actually, since I am doing that as well, I just tested it. And yes, it all works!
In the Cygnal project (http://www.kylheku.com/cygnal) I made a few fixes to this code.
With Cygnal you can write a terminal-oriented application using termios and VT100 escape sequences (or a library like ncurses if you wish). You just package it with the cygnal DLL, and any other DLL's. It will run fine in the console window.
For a demo of this, download the Windows installer for the TXR language.
https://bintray.com/kazinator/Binaries/TXR/txr-169
The txr.exe executable happily runs out of the cmd.exe console window with history, multi-line editing, etc. There is not a shred of Win32 code in TXR: it's just (a much enhanced fork of) the Linenoise library which uses termios and ANSI codes. Not a single #ifdef WIN32 in there.
I've loved the idea of bash-on-windows but it was missing just enough that it wasn't worth it moving away from my current love affair with the "git bash" system I'm using.
With these changes, it looks like I'll be jumping ship when it comes to stable!
Great work to everyone involved!
I can finally ping, do ifconfig etc.
Even htop runs. I am amazed! http://imgur.com/7P2J64h
We are, however, continuing to work on solving these and several other networking issues to close the gap in our networking support.
As a work-around, you could always call Windows' tracert.exe via the interop feature ;)
An if you're just using standard sockets technologies (e.g. HTTP, TLS, FTP, SSH, etc.) all should be good.
Think of it the other way. Why would you use wine if you could just run Windows in a VM? :)
is it really? last time I read tests WSL was slower than VMs
It would be nice to work from Windows but build for Linux that way, for other languages too.
The article was talking about Windows Subsystem for Linux, and my comment was that VS can do C/C++ for Linux. I thought that was implied by the context.
Anyways, I know VS has done C/C++ for forever. :)
Does this mean tmux will work?
Now, there are many, MANY, improvements required of Windows' Console which is currently receiving its biggest overhaul in > 30 years! Bear with us while we give the Console some much needed TLC and start to re-shape it into a clean Console infrastructure that supports modern Console demands.
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 actually a good native windows distribution of Python and Julia.
Cortana + voice recognition is actually pretty cool, I'm looking forward to hacking on it when MS releases the dev kit.
So far, windows seems to be an acceptable Linux. I will probably stick with it for a while, assuming I don't run into any crazy new blockers.
(I've been on Linux exclusively since 2001 except for a brief attempt to use OS X around 2009. That experiment was less than successful: https://news.ycombinator.com/item?id=1786930#1787411 )
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? :)
I'd like to play with Urbit - Yarvin and his goals are interesting enough that I'm willing to spend a few hours playing around.
https://www.reddit.com/r/emacs/comments/598iot/on_windows_em...
https://sourceforge.net/projects/emacsbinw64/files/release/
It's worked for me fairly well.
Once the latest build filters out to Windows Update, I will probably only invoke the Windows build of emacsclientw, but it would be nice to have something habitable in WSL on occasion.
That's much easier on the eyes. org-mode folding doesn't seem to like it, but it should be no problem sticking to Windows Emacs for that.
Most gui programs seem to work ok as well, though you do need an X-server running on Windows (e.g. the one in MobaXTerm does the job)
I was able to do stuff like watch cat videos on youtube with sound at full speed (though presumably not hardware accelerated).
The big feature I'm missing is network file systems.
Do you use spacemacs by any chance? I tried emacs with WSL when the Anniversary Update was released and ran into this issue:
https://github.com/Microsoft/BashOnWindows/issues/639
I'll try it again when Creators Update is available and hope for the best.
Edit: NM, just saw below, after I posted this message that you're using the Windows emacs build.
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 true till the end of time. Does your dev work depend on bug fixes or certain syscall implementations? Well, either run an OS that may or may not work at any given time or wait several months for the next release.
A couple weeks back I tried to give WSL a try but everything was broken. Inotify prevents hot reloading, which really makes my life just dandy, so I tried to transition to the insider program in order to get my fix. To my chagrin, this caused Node to up and break on me. Like, full stop doesn't work anymore.
I ended up going back to Linux. I really hope that developing on Windows becomes something other than 'awful' - for me at least - but I don't think it's quite there yet.
A good example of this is the work we've been doing with the networking team to add additional network socket mode support to the NT kernel's networking stack so that we can create the correct socket semantics that Linux apps expect. We're also working with the NTFS team, process & scheduling team, management infrastructure, etc.
At the end of the day, however, I really hate writing code on Windows. I don't write much Java or C#, instead sticking to Elixir, Ruby, Python, Node, and Golang. Every time I try to use Windows I just get super frustrated. I remember showing up to a Code for San Francisco meeting with a Windows laptop and being the only person there without a Mac. I mean, go check out node-gyp's 500 comment 'windows users arent happy' issue to see how deep the rabbit hole goes.
WSL makes an impact on a lot of the issues that frustrate me. Knowing I have a tool chain that can actually compile C extensions matters. I'll never, ever bet my career on Windows but I might one day use it as hobbyist development platform.
While I have you here, will the Windows console ever 'get better?' Rendering console text on Windows is... pretty awful, I'm not going to lie. Going from Linux to Windows is fairly painful; when I `cat` a large file in Windows it then takes seven years for all the text to render. Day to day usage just feels sluggish and awkward in comparison to a Linux terminal. Even if WSL was a flawless piece of engineering, the 'terminal experience' on Windows could do with some TLC. Are there any internal plans to make improvements?
Ooh! That's nice.
I was slightly disappointed I couldn't SSH tunnel or do too much with network tools when I gave it a try not long ago. I am definitely looking forward to that.
It is unfortunate that Microsoft couldn't figure out how to write this in a less kernel-attached way, but this is adding some powerful new functionality at many levels of the kernel, that will hopefully provide long-term benefits.
However, as a developer, I want a development environment that is stable and easy to setup. Windows has always been a huge mess to develop on and is the red headed step child as far as support for every open source project out there and the WSL implementation solves 90% of associated problems.
That being said... both MacOS and Linux are easier to code on. From compiling C extensions to file path parsing, UNIX-based operating systems have just turned out to be better development platforms. From my perspective, at least.
To emphasize, I have less of a problem with the work-in-progress nature of the project as I do with the release cycle. If the operating system stands in the way of getting work done, then the end user shouldn't have to face the dichotomy of whether or not to sacrifice core system stability in order to achieve his or her goals.
"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.
What do you mean when you say your node is "broken"?
And I don't follow re. your Arch install on another drive?
`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
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 reliable statistics be found on this? HN isn't exactly indicative of developers in general.
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.
Here's data:
https://stackoverflow.com/research/developer-survey-2016#tec...
~50% Windows, 26% OSX, 22% Linux, for the average "developer-who-fills-a-survey-on-stackoverflow".
And I doubt anybody will argue that the masses of developers who don't frequent StackOverflow are less likely to run Windows.
That's apparently the school of journalism...
Devs who write native apps for an OS (e.g. DirectX games for Windows) will of course use that OS.
In general, I see Linux native used as often as Mac native, and Linux VMs used on Windows all the time. POSIX has little to do with it.
That said, it depends on the kind of work; obviously, .NET developers almost exclusively use Windows, and I've noticed that sysadmins and system engineers are a little more likely to use Linux.
On top of it, the Ubuntu userland should be freely upgradable - I think.
Correct, it's currently a 'technology preview'.
That said, WSL is now far, FAR more compatible with the majority of mainstream dev tools than it was in Anniversary Update or early Insider builds.
Don't take my word for it - I am biased ;) - but if you've not taken a look at WSL in 2017, you might be surprised by how much now works very well :)
I hope/pray that readline and/or editline work correctly on bash et al?
Do Windows CI services like Appveyor support WSL? If so I would hope that deploying to windows for lots of high level software is relatively painless.
Head scratcher from the video:
> What if I want to open this file in notepad?
> ... <demonstrates opening notepad from bash>
> audience applauds
Ugh, the only thing worth applause here would be if instead he had said "and we finally taught notepad how to work with different line-endings" or "and we finally deleted notepad". The demo clearly shows the shebang line mashed in with the rest of the file contents. "This was a very popular ask" -- from whom‽ To present things as a dichotomy between vim and notepad is not honest.
EDIT: comments below have clarified: the feature refers to launching Windows processes from linux ones, not notepad specifically.
For a while, it was impossible for windows programs and WSL content to mix (and if you could somwehow do it, it was highly discouraged).
But that's no longer the case. Notepad is just an example to prove this point.
It truly is a Notepad. It launches quickly and has a non-nonsense interface.
It's not meant to be a programmer's editor. It never was, it never will be.
Anyone running Win10 who wants to see Notepad support NIX file endings, PLEASE submit feedback via the feedback app - that way Notepad's owners get to see your pleas ;)
I suppose I could temporarily change the setting just to give line ending feedback for notepad.
This had nothing specifically to do with Notepad, I would bet they just used it as a simple example.
Basically this: http://stackoverflow.com/questions/38920710/how-can-a-run-wi...
Demoer specifically comments that it's broken (obvously CR/LF differences) and they're fixing it.
Also VS Code for Windows might have been a better example than Notepad but you get how this could be useful.
Plus it nicely demonstrates one of Notepad's key weaknesses to help drive awareness with the Notepad team ;)
I think visual studio code is what you're looking for.
i'll admit i'm super duper happy about this, can't wait for $WORK OS upgrade.
Well, yeah, Windows has been in the dollar milking phase for quite some time now (at least a decade).
It's no longer about delighting the user (yes, even Microsoft used to do that!). Or even just keeping them happy. It's just about keeping them not unhappy enough to switch to the alternatives.
Windows 7 was a clear and undeniable update over XP and Vista while 10 refines a lot of Windows' weak spots (such as lack of virtual desktops).
Edit:
idobai, I can't reply because your account is banned, but last I tried Wine and Crossover do not work for the apps I am trying to use.
Edit 2: cyloneyes, you're banned too. But "They" would be Microsoft. They are the only ones who could really do it.
Please define "seamless" in this context.
If you mean that you want to have the running Windows apps appear as window in your Linux environment, VirtualBox has a Seamless mode that will do that. I haven't tried it, but what I find with Google seems to say it works as expected. VMware Fusion (on the Mac) has a similar mode called Unity. The VMware one seems to work well enough, but I haven't tried it extensively.
If you want to be able to open files in Windows applications from your Linux environment, I'm not sure if this is possible. VMware Fusion (on the Mac) has this - I can right-click on files in the Mac and see various Windows programs on the "Open With" list. I don't know if this feature exists on VMware for Linux, but it would be worth investigating. I'm not aware of an equivalent with VirtualBox.
Combined, these two features would probably give you the closest thing to a seamless environment that you can get.
If you just want to run Windows on Linux and are willing to put up with the friction of using a VM, VirtualBox does a decent job and makes it fairly painless.
As a matter of fact, people are moving away since some time, either to Linux, macOS ooooor iOS/Android (haha). I guess even by economical means removing that lock-in may make sense.
https://www.reddit.com/r/bashonubuntuonwindows/comments/5ece... - My last check.
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.
You can now also compile using the gcc toolchain if you have WSL installed.
- 24 bit color support added.
- lots of work to support more programs
- launch windows programs from bash (notepad.exe for instance)
- file change notification support (to allow for automatically rebuilding a website on file change for instance)
- can build a C++ project in Visual Studio and deploy it to your local WSL env, so you can run it directly from the local bash. (Visual Studio generates real linux binaries : ELF 64 bit lsb executable)
- Remote GDB Debugger: Can use visual studio debug engine to debug linux executables (It looks like this was possible before for remote machines [1], but now it can be done locally on a program running in WSL.)
[1] https://blogs.msdn.microsoft.com/vcblog/2015/11/18/announcin...
Who knows, in 3 years i might be able to ditch OSX for Windows, because some of the Surface devices actually look decent (no idea how true it is tho).
Old Interix required retargeting and recompiling binaries, similar to how you would need to recompile to target the differences between Linux and BSD. WSL runs Linux binaries without the need to retarget or recompile specifically for Windows.
This also means that the long tail ecosystem of Ubuntu PPAs and custom binary download sites all mostly work, too.
Ah okay. Shame that calling this "GNU/NT 10.0" would not be proper then.
The Subsystem for Linux is essentially an implementation of the Linux ABI, which is distinct from UNIX and provides true binary compatibility.
The ironic thing is that WSL itself is deliberately not Linux; the only similarity is the user-space ABI.
Unfortunately, I've met very few developers (admittedly interacting mostly with students) who have any understanding of what is Linux vs. GNU utilities vs. UNIX, vs. Ubuntu. "macOS is basically Linux right? Its because of the Terminal". screams
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 ;)
Via SSH? Sure.
Via Samba? Yep: https://www.samba.org/~garming/
If you mean MOUNT network drives, then, not yet, alas. But yes we're keen to build that support when we can.
Those are two things with very different goals.
Rebuilding the code is the norm in the GNU/Linux landscape.
Is Ubuntu x86_64 built from Fedora x86_64 packages? Etc.
The requirement "I want to run Linux stuff on Windows without rebuilding" is basically stupid, because you normally don't even run stuff from Linux distro A on Linux distro B without rebuilding.
It sort of works for programs that have minimal, reasonably old dependencies.
Ubuntu users do not pull down Fedora packages, right?
* No, it is not an emulation. The win10 kernel + compatibility layer just happens to be able to also run ELF binaries. Yes, these show up as standard processes, and can be interacted with using normal windows tools (eg taskmgr).
In another twist to this, this dynamic then might 'incentivize' users of those packages to upgrade to 10 when they wouldn't have otherwise (or switch to Linux for good ;)
You might be interested in some of these videos and posts: https://blogs.msdn.microsoft.com/commandline/learn-about-bas...
Cygwin, which allows you to run bash among many things, has been available for TWENTY TWO YEARS now. However it required such software to be ported and recompiled specifically for its use with Cygwin.
The difference this time is being able to run unmodified Linux software on Windows, through an application binary interface called Windows Subsystem for Linux or WSL.
"Bash on Windows" is the least tech-savvy way to describe what is going on.
https://blogs.msdn.microsoft.com/vcblog/2017/02/08/targeting...
Btw. any reason you are not running those bash scripts in WSL now?
Planning to give WSL a shot soon.
A lot of people like to also develop in an environment they are going to deploy in. In my case I have some linux specific path in my code.
I am also running now Gogland Linux version through WSL.
At this point, I believe the terminal emulation is pretty close to complete, so if you notice any other shortcomings, make sure to take a look at or GH page for issue reporting:
I know it's not that hard to keep your stuff in /mnt/c or wherever, but I wonder if there is any plan (or if it's even possible) to eliminate this last bit of incompatibility.
Is it possible to run a GUI version of the Linux version of VSCode on WSL?
1. https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...
My PC has a super loud fan system that requires software support to control to get it quiet. Under my Linux install this was turning into a configuration nightmare, trying to find the right incantations -- under Windows it is working nicely. As are the video drivers.
So I am doing my development in the Windows version of CLion, but doing the actual compiles and git usage etc. in the Linux subsystem. It's working really nicely. And for the few GUI I need, apps I run Xming and set my DISPLAY and it works perfectly.
My computer usage tends to be as a dumb terminal for SSH, and in that regard, I'm not having any trouble with WSL
The Windows Subsystem for Linux felt incomplete to me the last time I tried it. I guess that is one of the advantages that macOS has in running Bash. macOS IS Unix, so Bash just fits, rather than being a bolted on service, the way it is in Windows. Hopefully things are much smoother now. It is certainly nice to see Windows finally get a good, cross-platform shell.
EDIT: Oops! It looks like Erlang 19 still isn't quite there...
I won't switch from Mac anytime soon, but competition is always good. Can't wait to see how Apple will respond to latest Microsoft actions (WSL, Surface Book and Surface Studio).
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 :(
Maybe there are some others features of sshd you are talking about that I may not know about.
https://github.com/Microsoft/BashOnWindows/issues/1150
There are ways to hack around that but they're not pretty:
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 the functionality for Windows only. Let's keep them honest and make sure they don't do that again!
Why is this dead? It even has a name.
https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
1) I also like games
2) I hate dual booting
3) PCI passthrough of GPU to VM was a bit annoying
So WSL is kind of a nice middle of the two worlds. I don't need to run a Linux VM now for development, for example.
This is of course not the first time Microsoft has done something like this. Historically, step two is where they extend the functionality for Windows only. Let's keep them honest and make sure they don't do that again!
http://www.theverge.com/2017/1/2/14146182/microsoft-windows-...
There are a few last remaining things we need to enhance & modify before we feel comfortable before taking off the beta label.
Now does it support SECCOMP yet?
I was just saying maybe WSL shouldn't be advertised as ready for prime time without SECCOMP-BPF support implemented, e.g: for OpenSSH pre-auth sandbox. At least not in roles where security is paramount.
Also, remember that our primary goal for WSL right now is to provide a local development environment in which you can build, run, and test *NIX code.
Here's a better quality video on Channel9:
https://channel9.msdn.com/events/Windows/Windows-Developer-D...
Same start time of ~17:00 mins in.
I want to believe. I'd go fucking apeshit if Windows dropped the NT kernel for Linux or BSD.
So it's about a decade more advanced than UNIX. Put like that, moving to UNIX would be a regression, but not a huge one.
The Linux kernel is of about the same vintage as NT, though. And it's had a lot more work and public review done on it.
Well, that explains the PowerShell syntax.
Personally, I wonder how long it takes before redmond realizes that they are wasting shareholder money by maintaining/developing a proprietary kernel. It's not like they could not sell windows/linux as a perfectly good OS with copyrighted components on top of the kernel.
Or then I have missed something significant.