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.
Just for reference, I've been doing this for a few months now. I'm not sure what's changed, but you'll need ubuntu 16 (you can uninstall 14 and reinstall WSL to get it) in WSL to do it.
You don't HAVE to nuke & reinstall your Linux environment to get up to 16.04 - we also support in-place upgrades too ... so long as you're running a Windows Insider build >= 14951
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.
First, I switched from OSX to Windows b/c WSL made it possible.
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.
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 ;)
First, I switched from OSX to Windows b/c WSL made it possible.
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.
Almost. `code.exe .` will do what you expect IF you are in a folder that's visible from the Windows side. If you're in a WSL folder, the Windows program will be run in C:\Windows\System32.
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.
Hi - yes, we register the '.exe' extension with binfmt that then triggers WSL whenever a .exe is launched, allowing us to go find and spawn the requested Win32 process.
If you just want to type `code <filespec>` (without the .exe), then you can create an alias that resolves to code.exe.
(HN: bitcrazed is Rich, the person presenting in the video)
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.
Yes, we're essentially giving the Windows Console its biggest overhaul in > 30 years!
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 :)
I'm a big fan of this new feature, enough that I wrote and released some open source code to launch applications before this was possible. Mine's a hack, pure and simple but it worked to fill in the gap but I'm glad to not need it anymore. Thanks! https://github.com/jaegerpicker/Rockhopper
CLion is pretty spiffy IMO, though it uses CMake as the underlying build tool which may or may-not be your thing (I prefer scons.. but nothing's perfect).
A properly configured and well-curated collection of packages will yield an exceptional experience using emacs - if you're into that kind of thing. Add in some custom elisp and you're well on your way to a fully customizable development environment.
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!
Agreed... I tried it for about a day, then went back to git bash. Will probably give it a try again after it goes to release. For now, I've been sshing into a linux vm, and using samba/cifs to mount my linux ~/ so I can edit in windows, but better integration would be nice.
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.
Why wouldn't getting as close to 100% compatibility as possible be the aim? WSL is currently beta. The installation documentation has a big warning at the top that functionality is currently incomplete.
All I can say is that the first two things I tried on the Windows Linux Subsystem didn't work, mainly running Elixir and Debootstrap. It's okay that they aren't (yet?) supported, but something that looks & smells like Ubuntu, yet isn't, doesn't inspire confidence that it can be trusted to act like Ubuntu.
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.
I'm not sure a public-facing curated list of specific compatibility issues would be practical at this stage of the project's life; it's changing fairly rapidly. FWIW, the bug tracker is public, and the team seems to be fairly responsive; a UPX Compression bug I ran into was tagged fixinbound within a couple weeks. https://github.com/Microsoft/BashOnWindows
The speed at which they can push new builds to people who aren't on Windows Insider is a bit unfortunate, though.
> All I can say is that the first two things I tried on the Windows Linux Subsystem didn't work, mainly running Elixir and Debootstrap. It's okay that they aren't (yet?) supported, but something that looks & smells like Ubuntu, yet isn't, doesn't inspire confidence that it can be trusted to act like Ubuntu.
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.
I don't think they can open source WSL in any useful capacity because it's signed as part of the kernel itself - afaict this is also why an update to WSL is an update to the Windows build itself.
I'm not familiar with Elixir or Debootstrap (I'm guessing web-oriented)? But, I've had great success with using WSL for C++ oriented projects, building with both g++ & clang. Only issue in that regard I've had is that the emulated syscalls cannot currently enumerate ethernet devices. The calls are implemented, but fail at runtime currently. I've not yet filed a bug report, because I don't know how it should perform.
Bash and Windows Subsystem for Linux is a band-aid solution for a fundamental problem for Microsoft: Linux tooling and kernel are IT industry standards.
They are for one part of the tech industry (which I count myself in) but it's pretty obvious that for many others, Microsoft-based tech (which now runs everywhere) is a standard. Why not persue both?
People have been developing on OS X outside a VM for a while now, and OS X is most definitely not linux. If they can get WSL to be as linuxy as OS X (and arguably it's already close), Windows will be as good a dev platform for linux development as OS X.
But they really need to fix notepad so it supports unix style line endings. That part of the demo was a bit embarrassing.
I agree with this. OS X is a flavor of BSD. I've learned that it's often more helpful to search for "<thing I want to do> bash BSD" than it is to search for "<thing I want to do> bash OS X".
Making "Winbuntu" a fully compatible Ubuntu sounds like a really lofty goal, especially when it comes to things that expect a Linux file system.
I guess for me, it's easier to reason about Linux in a VM (or maybe a container), with all the limitations of that approach, than it is to wonder what surprise might occur as a result of trying to run something on Winbuntu. At some point maybe that will shift. It's not like VMs are exactly like bare metal.
Keeping trying hard Microsoft! I like Winbuntu enough that I bought a Windows 10 laptop just to play with it! Emphasis on play, not seriously use.
I've been using WSL since it was released to the fast insider ring. It's pretty slick. There have been some warts and growing pains, but the team has been very responsive to bug reports. I've seen responses as quickly as 2 public build cycles (about a week) to get a fix for an issue reported on their github site.
You can actually manage/control Docker for Windows (upon which you can run Windows & Linux containers) from your Docker client running in Bash (or Windows) on the same box.
I love watching people developing on OS X, targeting Linux, without proper tests forgetting that Linux's FS's are by default case-sensitive in regards to file names, and completely forgetting that OS-X is case-insensitive, by default (and recommended to remain so, because most OS-X software is not developed with case-sensitive file-system awareness.)
>OS-X is case-insensitive, by default (and recommended to remain so, because most OS-X software is not developed with case-sensitive file-system awareness.)
A few years back, following my previous laptop which had been a flimsy Acer running Ubuntu which became unusable following malfunction of the fan, I was looking for a more sturdy laptop and ended up buying a mid-2012 15" MacBook Pro which came with OS X Mountain Lion I think it was. Being used to case-sensitivity from various Linux distros and on my FreeBSD servers, I decided to enable case-sensitivity for the system drive. That turned out to be quite a mistake indeed. Several pieces of software were unable to find the files they needed, so I ended up reinstalling the whole system shortly after, this time without case-sensitivity.
Following that I had a hardware problem that the Apple authorized repairshops I went to were unable to fix three times in a row so I ended up demanding a refund (Norwegian customer protection laws are good in this regard), and while I still think OS X is an impressive system I lost a bit of my respect for Apple after that experience. (I enjoy my iPod touch though.) Anyway, the reason I mention this is just to say, I don't know if case-sensitivity remains problematic in macOS. I find it highly likely that it still is though.
Yeah, to be clear here: We worked with the networking team to enable Linux Ping to open a raw socket, but we've not enabled carte blanche raw-socket support for all Linux processes.
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.
Any chance we'll see a first-party X11 server at some point? XMing, VCXsrv, and Cygwin/X all have some warts when it comes to stuff like windows previewing, copy/paste, acceleration, and fonts. OS X has shipped with an optional X11 server forever, and it would be great to see that feature parity in Windows.
We're working on traceroute for a future release. In the meantime, you can run `tracert.exe <ip>` from within Bash which will invoke the Windows trace-route command-line tool to do the same thing ;)
Uh.... VS has always been able to do C/C++ compilation. Like... for decades now? Just not with the standard Linux toolchain, but you've always been able to build C/C++ projects on Windows.
Thanks for the downvote guys. I wasn't born under a rock.
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.
VS not only could build C and C++ since I can remember, but was a pioneer in the recent C++ revival. Btw VS 2015 installer offers Python tooling install if I remember correctly. See also: https://github.com/Microsoft/PTVS
In case the context didn't make it obvious... I know that VS is based on, and can do compilation for C/C++. I was saying basically, "Oh cool. You can do VS compilation of C/C++ for Linux now. Do you plan in introducing it for other higher-level languages too? (Ruby, Python, et. al.)"
tmux should have already worked quite well in Anniversary Update (14393). There are some specific feature enhancements, such as 256/24bit color support (although tmux doesn't support 24bit color by default) and mouse mode support that should make tmux much more usable.
The OP asked if TMux worked on WSL, which it does.
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.
It's less overhead and better integrated into the system as a whole. After all a VM is still a separate entity in its own environment. WSL is jumping over the fence and runs Linux stuff in a Windows environment.
Think of it the other way. Why would you use wine if you could just run Windows in a VM? :)
I don't know if I would call it better or worse, it's more about preferred workflow. I'm typing this on a MBP and I have a fleet of VMs specifically because I'm tired of playing the platform game. I can configure a VM specific to an app's needs faster than hosing my host OS with a very specific configuration that may not match production environments. Even with version managers like rvm or nvm/n there is just a lot to get wrong. It may be faster or less resource intensive to not have to spin up a VM but I've been in .NET land with desktop apps and now various web platforms enough to prefer this workflow. For someone like me, this would be for personal usage versus job related activities but I do see the benefit of having the choice. I just hope I'm strong enough to resist the temptation because my personal win10 laptop is a graveyard of rails installer and a few other various barely-supported toys.
It isn't clear how much people can appreciate this sort of thing without context. Back in the mid 2000's I was at a very high level Microsoft Developer event and got to ask about waning support for command line tools.
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.
It's funny you mention switching from Windows to MacOS for the command line tools. I booted up a pre-NeXT Mac (an iBook with OS9) the other day, and was blown away to learn that there is no terminal at all! How quickly things changed after that.
Absolutely. My background was that I was Sun for years and on a "workstation" the most common window open for a software developer was an xterm not some IDE. That said, for people who "grew up" knowing nothing but visual studio and delphi, telling them that everything they are trying to do is easily done in the command line doesn't resonate.
Even though I am a huge command-line fan, I am not sure that "everything they are trying to do [in an IDE] is easily done in the command line" is entirely true ;)
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.
ISTR from my days when I was a primary school kid playing around with my grandmother's Mac running System 7 that there were some (fairly lame) third party tools that attempted to implement a DOS-style CLI.
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.
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.
With Visual Studio Code, Microsoft is making Windows 10 really appealing to developers. I personally won't jump any time soon, I am really satisfied with my work environment on macOS (and Linux inside VM) (unless I got locked down into Microsoft stack for work, in that case I will gladly switch, but it's not like I will have any other option). But anyway, I recognize and appreciate the change at Microsoft's direction of thinking, it's awesome! I wouldn't believe if somebody told me this 10 years ago...
VCpkg (and ofcourse CMake support, without it I don't use VS honestly) made me to make that switch ! it is awesome, it is one thing as C++ dev I always dreamed of
VCpkg is so much better in my opinion than installing library devel packages on linux. Makes it a pain to keep track of them. Also the code completion and refactoring capabilities are itself worth it.
You can now also compile using the gcc toolchain if you have WSL installed.
Not since Windows 2000 have I been so interested in an upgrade to a new Windows release. Only at work do I have to suffer through Windows, but this would make things much nicer there.
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.
> Not since Windows 2000 have I been so interested in an upgrade to a new Windows release.
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.
Agree 1000%! Was waiting for a comment like yours to help drive the case for some updates to Notepad to support NIX file endings, etc. ;)
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 think it's available since the most recent stable Windows update - there's an app literally called "Feedback" you can use to report and upvote issues.
I was so split as to whether to show Notepad or Code, but figured that more people were aware of Notepad and would grok what I was trying to demo so went that way.
Plus it nicely demonstrates one of Notepad's key weaknesses to help drive awareness with the Notepad team ;)
Yea, fedora user at home, stuck on Windows 7 at work. I've actually started to pick up some Powershell for some light scripting. Have had a request in to the Vogons in IT to install python for windows for about 3 weeks now and I'm still waiting...
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.
Xming works, but it does have some warts (at least, on my machine YMMV). The three things that bug me most about it:
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 :(
That's not the `file` command, it's tools for working with files: chgrp, chmod, mv, rm, etc. These have all been folded into coreutils these days, which also does not contain the `file` utility. Ubuntu and practically all other Linux distros ship BSD's file utility.
Newb question, does this "Winbash" run Linux/posix/unixy binaries that wouldn't otherwise run or does it assume the actual Windows dists/builds for (Elixir / Go / PostgreSQL / MySQL / GHC / etcpp)?
* Yes, these are native, ELF binaries. Yes, you can compile it on your linux server, cp it across to windows, and run it.
* 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).
I see, thanks, this curiously "mildy" (or perhaps, increasingly/incrementally) incentivizes most of these linux/posix/unix-"native" FOSS projects to no longer provide separate "Windows builds": simplifies code-bases, deployment, documentation, support, everything. But if they still continue to do, they have just another "support/bug dimension" to deal with in addition to "OS" --- the old "Windows build" plus also now "X-ish build under Winbash".
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 ;)
Erm ... that's exactly what WSL does. Not quite sure how we'd be able to run ELF64 Linux binaries without building a comprehensive Linux ABI compatible layer.
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).
if it responds. apple looks more and more like a luxury goods company and the things you mention aren't that. (not saying it won't, but i'm pretty sure 'how' isn't a certainty.)
The 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 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.
Yes, the Ubuntu userland is upgradable using exactly the tools you would expect. (The system even includes a Scheduled Task that does security updates every week.)
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.
My impression is that most devs who write POSIX software these days use macOS (with possibly Linux running in a VM.) AFAIK, that's more to do with preferring Apple hardware, and then Linux not having 100% support for said hardware (e.g. touchpad multitouch / "force touch".)
Devs who write native apps for an OS (e.g. DirectX games for Windows) will of course use that OS.
See, that's not really what I see in my experience. About half of my friends that hack around use macOS, another half use Linux, and then a couple use Windows.
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.
I've interviewed at a couple local companies with 50+ devs each (mostly web dev positions), and almost everyone uses a Mac. This is anecdote of course, but I very rarely see devs using Linux professionally (natively, not in a VM).
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.
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.
I think you are being too harsh -- this is an in-development feature. Once it gets stable things should "just work", and you'll get an update in a few months, like most pieces of software. At the moment you wouldn't want to rely on the beta version for anything important -- some betas are fairly broken (as you would expect with betas).
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.
You could very well be right. I really don't want to take away from the fantastic work that the WSL team has done.
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.
@OhSoHumble: We totally hear you. We'd love to ship WSL builds uncoupled from the rest of the OS, but at the moment, we're developing WSL at a breakneck pace alongside several other critical kernel feature changes which all have to ship in lock-step.
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.
That's good to know. Maybe I'll try to use Windows as a development platform when it has another major release. I'm really impressed that WSL exists at all. I didn't think Microsoft had it in them to allow such a project to flourish.
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?
As far as the console "getting better" - it's getting better with every release. This last release we focused on enabling full 256color/24 bit color support, and enabling VT mouse mode, to better support terminal applications. Not only that, but we've also been working constantly on performance enhancements under the hood. IIRC, before AU, we would try to repaint the frame every character, now they're aggregated to 60 FPS. It's getting better, not terribly quickly, but we're getting there :)
> 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.
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.
My main project is a Rails/Ember.js application to help people find affordable housing in the bay area.
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.
I think "bash on Windows" is not a valid way of describing what it is.
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.
> Bash on Windows or Bash/WSL got the most votes in early polling while we were choosing a descriptive name for this unusual feature, especially compared to WSRPGLB (Windows Subsystem for Running POSIX, GNU, Linux Binaries) which felt a little cumbersome
A basic thing, but glad they updated console to support more colors and basic vt sequences. Currently I just have X11 server on startup and through some scripting have a shortcut to launch an xfce4-terminal instead of the native console.
How is the file system performance going with this? The latest release version runs Rails worse than shared folders on VMWare which is slow in bad way. Running MySQL on top of it might "work" but is it fast?
I think they mean network drives mounted or accessed in Windows. For example, from WSL I can't access files on my network share (in windows it's \\pc-name\\shared, where pc-name is running Samba under Linux). Mapping a drive letter to it doesn't work either - the only thing that shows up in /mnt is c. This is quite a pain.
Yep - that was the mount thing I mentioned in my prev' reply: We've not yet got around to mount support, but it is on our backlog and we're keen to get to it when priorities allow ;)
Even if they optimize to the point of native Windows speed it will still be slower than native Linux. Its a well known fact some heavy IO programs run faster under Wine than native.
With something called Cygnal, you can make native Windows applications, while taking avantage of all the POSIX interfaces in Cygwin. No special subsystem required, just some DLL's.
Which drawbacks are those? (One is performance, unfortunately).
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.
People like to use package managers to install thing in a Linux distro. Supporting binary compatibility means that they can just use apt instead of building something new, and rely on Canonical for creating packages.
If you're using Ubuntu and relying on Ubuntu packages, that's not "binary compatibility". That's using Ubuntu binaries on Ubuntu. Ok, it's the trivial base case of binary compatibility: A is compatible with A.
Ubuntu users do not pull down Fedora packages, right?
I'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 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.
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.
Would you mind elaborating on what emacs in particular you're using? I use and love emacs but unfortunately the times I've tried to use it on windows it's been extremely unresponsive.
Indeed that's the one that I used. For some reason, even just moving the cursor around the buffer was extremely unresponsive, it would take seconds for it to register a cursor movement. I'll have to figure out if it's some package I'm using.
Woah I tried it again and it seems like it's working perfectly! It seems like the initial release for windows wasn't compiled with optimizations, so perhaps that's the issue I was observing.
What do you use for colors/theme in emacs in WSL? I ran emacs with the default settings the other day and there was a lot of unreadable blue on black.
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.
I'm pretty happy with it too. For the things that are implemented, it works better than MacOS did as a casual Unix for me. Mostly because I prefer the Ubuntu tools. I'm still using a genuine Linux box for real work though.
The big feature I'm missing is network file systems.
We're looking into it. No guarantees yet as there are several challenges and security / management obstacles to overcome, but we are keen to make daemons work if possible.
It is good to hear that both Ruby and Elixir work now. I had issues with both when I first tried Bash on Windows.
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...
Dumb 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.
The big difference is that it isn't just POSIX compatible, it is a full out "bug-for-bug" emulation of the Linux kernel specifically with an eye towards binary compatibility. Out of the box, the userland here isn't just GNU, it is entirely the same binaries as shipped by Canonical in Ubuntu.
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.
There's still enough GNU there that you could call it that if that amuses you to do so. (Though I bet RMS will happily throw a fit in your direction if you do. ;)
The old stuff provided source-level compatibility with UNIX via posix compliance.
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
I've been sing the Linux subsystem in my new Windows install for the last couple weeks, after buying my first new PC and first Windows machine in ten years. It's actually very impressive, and I like it.
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.
I couldn't spend more time with that. But my overall experience with WSL is positive at least I don't need to install cygwin just to get basic tools. Windows fs is mounted on /mnt/c which is easy to type. I assume most of important syscalls are already implemented to translate. Even though sometimes bash.exe stops responding and maybe more enter key works. But bash is working like a jailed process, WSL does not report Windows processes that run to it. Which is a deal breaker. Frustrating maybe even more than running without dbus.
315 comments
[ 3.5 ms ] story [ 369 ms ] thread- 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.
So I can basically do `code .` from inside bash and it will open VS Code in the linux sub-system folder? That's amazing!
EDIT: Actually, since I am doing that as well, I just tested it. And yes, it all works!
HTH
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 ;)
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.
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 ;)
First VS Core, now VS proper. Impressive!
(going back to my ddd window on Linux, crying a bit inside).
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!
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.
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.
But they really need to fix notepad so it supports unix style line endings. That part of the demo was a bit embarrassing.
Making "Winbuntu" a fully compatible Ubuntu sounds like a really lofty goal, especially when it comes to things that expect a Linux file system.
I guess for me, it's easier to reason about Linux in a VM (or maybe a container), with all the limitations of that approach, than it is to wonder what surprise might occur as a result of trying to run something on Winbuntu. At some point maybe that will shift. It's not like VMs are exactly like bare metal.
Keeping trying hard Microsoft! I like Winbuntu enough that I bought a Windows 10 laptop just to play with it! Emphasis on play, not seriously use.
I was already a fan of colinux back then but this has te potential of being infinitely better.
Inception ... noitpecnI ;)
A few years back, following my previous laptop which had been a flimsy Acer running Ubuntu which became unusable following malfunction of the fan, I was looking for a more sturdy laptop and ended up buying a mid-2012 15" MacBook Pro which came with OS X Mountain Lion I think it was. Being used to case-sensitivity from various Linux distros and on my FreeBSD servers, I decided to enable case-sensitivity for the system drive. That turned out to be quite a mistake indeed. Several pieces of software were unable to find the files they needed, so I ended up reinstalling the whole system shortly after, this time without case-sensitivity.
Following that I had a hardware problem that the Apple authorized repairshops I went to were unable to fix three times in a row so I ended up demanding a refund (Norwegian customer protection laws are good in this regard), and while I still think OS X is an impressive system I lost a bit of my respect for Apple after that experience. (I enjoy my iPod touch though.) Anyway, the reason I mention this is just to say, I don't know if case-sensitivity remains problematic in macOS. I find it highly likely that it still is though.
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.
I can finally ping, do ifconfig etc.
Even htop runs. I am amazed! http://imgur.com/7P2J64h
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?
https://github.com/mintty/wsltty
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.
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
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.
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.
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.
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.
You can now also compile using the gcc toolchain if you have WSL installed.
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.
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...
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.
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).
i'll admit i'm super duper happy about this, can't wait for $WORK OS upgrade.
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.
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.
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:
https://wsl-forum.qztc.io/viewtopic.php?f=6&t=10
* 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...
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).
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.
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 :)
`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.
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.
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...
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 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.
"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?
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...
My computer usage tends to be as a dumb terminal for SSH, and in that regard, I'm not having any trouble with WSL
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).
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.
http://www.kylheku.com/cygnal/
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?
http://www.kylheku.com/cygnal/
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://sourceforge.net/projects/emacsbinw64/files/release/
It's worked for me fairly well.
https://www.gnu.org/software/emacs/download.html#windows
https://www.reddit.com/r/emacs/comments/598iot/on_windows_em...
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.
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.
The big feature I'm missing is network file systems.
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 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...
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 ;)
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.