1) Linux has won the server (web) market. Developers would like to use a Unix box to work on their server code so they typically move to OS X. This could prevent that switch because they can still use Windows to developer their Linux server software.

2) Many projects start out as Linux and stay Linux and are only ported after much time and effort to Windows. Enterprises when faced with a tool that they want to use will also look to switch off Windows. Now rather than the cost of switching they only have to pay to upgrade their windows boxes to use the tool.

3) There is now a major incentive for developers to only build Linux binaries because it will work more places. This might cause a faster drain of developers as they eventually remove all windows specific code and can more easily migrate elsewhere. This feels eerily similar to the OS2 story and no doubt in the next week I expect to see more than a few articles discussing this very thing.

4) It will be much easier for Microsoft to bring much loved Linux tools to Windows so you can expect to see a more rapid increase of tools announced that now work for Windows.

5) Games: What about the graphical layer? Can I write the majority of my game as a Linux binary and only have the rendering bit left over to separately implement for Linux/Windows? Will this spur an increase of cross platform games?

I would most likely switch back to Windows as my primary/only machine (because I also like to play video games sometimes) if I had the same kind of unix-like command line environment that I get in OS X.

Right now I basically need 2 computers at home to meet all my needs, but this would allow me to reduce it to one, so I could get a much better one (instead of the 2 mid-range ones I have now).

Out of curiosity, why would you not just go with a Linux desktop for that?

Before you ask, yes I do have a Linux laptop (Acer C720P ChromeBook, unlocked with Debian + Gnome), and with all the sudden issues that pop out of seemingly nowhere (my latest dragon is a recurrent kernel module crash that can fill my disk up with .core files in 10 minutes), I've switched back to a 13" rMBP. Though, I have heard that 2016 is going to be the year of the Linux Desktop...

I just got tired of fixing sound issues, trying to make a scanner work or investigating CPU states to fix heat and battery draining issues on yet another laptop. Ultimately, I think, all of this is a result of the unresolved issue of who should write and test device drivers.

It doesn't help that I disagree profoundly with the prevailing package management philosophy of Linux distributions, but that is a comparably superficial problem that can be worked around.

Sure, that's what this whole thread is about. But I'm afraid that there is causality involved that we know about without collecting any sample data at all.

Developers of Linux device drivers for consumer devices quite often do not have access to all the hardware and information they need. And hardware makers quite often do not make high quality Linux device drivers for their consumer devices. For most consumer laptops, the vendor will not do integration testing to make sure everything works well together on Linux.

I don't think the right response to that is to deny that the average laptop or peripheral will work better with Windows. The right response is to make it clear that you have to make very deliberate hardware choices if you plan to use Linux and accept that much of the hardware you can use is always going to be slightly dated. And that is in fact what many Linux advocates are saying.

Choosing a Mac also restricts your hardware choices quite dramatically after all, so if a broad selection of hardware is your goal, Windows is the only game in town.

It's not the best desktop environment out there, but apart from desktop, linux is the most popular system at every step from small embedded systems to the most powerful supercomputers. That wouldn't be the case if it couldn't make hardware available in a reliable and efficient manner.

More specifically, it's the state of Linux device drivers and integration testing for laptops and consumer peripherals I'm complaining about. That's not a result of any inherent deficiency of the Linux kernel or its design. It's ultimately an economics issue.

Android certainly doesn't have the userland that is typically (incorrectly) called Linux.

But if you want to talk about userland, then you need to buy supported equipment. OSX doesn't work with a ton of equipment out there - as that equipment does not come with OSX drivers. Windows also works like shit when it doesn't have the drivers - anyone who has had to install XP regularly will quite happily attest to just how terrible it is at supporting network cards before you install drivers.

Then, of course, there's the bonus of the AMD Catalyst driver installer program for windows: at least as recently as win7, if you didn't have drivers for video, it fell back to VGA graphics. The Catalyst driver installer was too large to be seen on VGA - you couldn't see the bottom of the installer window to see what was going on, and couldn't drag the window high enough without a hard-to-discover key chord. :)

The argument to "buy stuff your operating system supports" sounds like a cop-out, but it really isn't. OSX, for example, is difficult to make run on things other than Apple-designed computers, but if you complained about it, people would write you off as an idiot.

The reasons were 1) it ran the unixy stuff I needed for university AND modern games at the same time, and 2) it was boring and conservative. In a time where Linux and Windows were changing and breaking (Windows 8, Gnome 3, ...) it was nice to use something stable, well-tested, and polished.

I always use Linux for desktops., I see no reason not to.

I would never go back to windows but would happily move back to linux if I had to

EDIT: I should note I didn't expect to like my Macbook air so much (fantastic machine)

For my laptops... always had linux laptop problems. Sometimes have gotten really close to all the way working.. but then maybe I will find out my battery drains in 2 hours because some power saving feature is broke in my kernel and I cannot be arsed to go fix it, rather just buy a macbook.

Now for this vs macbook.. it depends how next macbook line looks. I need a 32GB ram laptop. If Apple skips that ship again, this will start to look pretty dang appealing.

There, now we're even. Let's get back to EEE, and the real porblems and advantages with this news.

And also because the user experience of OS X (and the "just works" aspects of the OS in general) is far above that of any Linux desktop.

https://news.ycombinator.com/newsguidelines.html

Well, I guess it'll be easier to port roguelikes which use ncurses.

Is this not helpful?

https://wiki.documentfoundation.org/Development/BuildingOnWi...

LibreOffice has official Windows builds, so I would expect that they can already build the software on Windows.

I'd rather use a toolchain I know better. In fact, I'd love to use clang on Windows.

I mean, sure, but (unless things have changed dramatically in the many years since I was a Windows dev) you don't have to do anything more than install VS. The compilers and nmake can be used without opening the GUI. IIRC, you can feed a VS project file (or -I'm pretty sure- a solution file) to nmake and get the same result you'd get from loading the GUI and pressing build.

[0] I do know that they are both parts of the VS build tooling. ;)

Can't find any substantial writings on this, but it seems likely.

This will have been quite a bit more work than just a POSIX layer, IMO; POSIX defines a bunch of low-level functions that lie just under the C runtime library, but Linux defines a bunch more that expect a certain view of the world - things like clone(2), which lets you selectively choose what the forked process gets to inherit. POSIX only specifies fork(2). Linux implements fork(2) in terms of clone(2). And POSIX defines the API at the level of C; this will have had to implement the Linux ABI, where it differs from Win64. A minor detail of a bunch of assembly stubs, but work nonetheless.

In my experience the differing perception of pleasure, certainly with the Interix-derived Windows NT POSIX subsystem rather than the original one, is usually a result of the toolset being BSD rather than GNU. I don't have much trouble with the BSD toolset, myself, especially when switching between Windows and an actual BSD. (-:

In addition to the fact that a number of the "Does this new subsystem ...?" questions are answerable as "No; but the old POSIX subsystem did." (https://news.ycombinator.com/item?id=11416392) the POSIX subsystem has some stuff that we're simply not going to get with a Linux subsystem that has vanilla Linux binaries including libraries right down to the system call level. There are things that only come by adjusting libraries and binaries, because they are above the raw system call level. The POSIX subsystem integrates the user account database access library routines with the Windows SAM, for example. So "ls -l" shows the actual Windows usernames. The POSIX subsystem also comes with a "service" command that understands and can work with the SCM, for another example.

I'd like to see the POSIX subsystem reintroduced. It's a major reason not to use Windows 10.

SUA is based on an old version of BSD, not GNU. tcsh, csh and sh. The compiler works. There is an old version of lex. For some of the userland, Windows binaries are provided, such as vi. It's better than nothing.

Why did MS remove SUA from Windows 10? What harm would it do to remain an optional add-in as it was in Windows 7?

Why do users have to upgrade to Windows 10 to use Linux binaries? Seems like Microsoft will do _anything_ to get users to upgrade. What are the privacy implications of Windows 10? Microsoft is very untrustworthy.

Will users be able to run their own Linux binaries on Windows?

Windows has never been a "pleasant experience". It's the unpleasantness of it that makes the alternative, UNIX, so appealing.

... but is too outdated to be capable of bootstrapping clang. There's very probably a long chain of bootstraps that would achieve it, but there's not a direct route.

> Will users be able to run their own Linux binaries on Windows?

The answer to that is easily determined from the demo video that Microsoft published. In it, Russ Alexander compiles a program with (Ubuntu binary) GCC and and runs it.

Its implicit int in the declaration of main() was jarring. (-:

Well, it's not like Microsoft made much of an effort to remind people. It was discontinued as a separate project after about Windows XP. It continued to be part of Windows Server[1], but AFAIK, it was no longer present in the client versions.

[1] at least until 2008 or 2008 R2, I didn't check later versions.

Thanks for the info!

If they just implemented all Linux syscalls on top of NT, that would replace a Linux kernel. There would be no Linux kernel running on top. But in that case they would also need to emulate stuff like /proc. (This is the "reverse Wine" scenario.)

So I personally think it is either: - There is no new subsystem, this is just a linux.exe running the Linux kernel as a process, like CoLinux does or - There is a new subsystem. One way to do this is to port Linux to a new "architecture", namely the NT HAL. You'd call into the NT native API from the linux kernel, which would mean you'd have to put the headers with the native APIs you use under the GPL.

Armchair kernel development is fun :-)

    $ grep DESC /etc/lsb-release
    DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"
    $ uname -a
    Linux kappa 3.13.0 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux
    $ wc -l /proc/cpuinfo
    608 /proc/cpuinfo
    $ /native/usr/bin/uname -a
    SunOS kappa 5.11 joyent_20160204T173314Z i86pc i386 i86pc

They don't run the linux kernel at all. That /proc/cpuinfo is a part of a limited subset from what procfs usually offers. They enter their linux compatible "subsystem" via a bash binary, which could probably be any linux elf binary, since they run them unmodified. So, it looks like they actually implemented most of the syscalls with some of them emulating necessary parts of linux environment, like procfs.

[1] https://sec.ch9.ms/ch9/5db6/8ee786b7-9fc5-45bf-94d0-16ea9176...

It's a lot easier to emulate syscalls than it is to do something like CoLinux. Additionally, I can't imagine Microsoft would EVER let GPL'd Linux code into their kernel.

And this seems to be implemented as an NT subsystem, which makes tons of sense.

I wonder if this Unix filesystem layer will be able to break the Windows legacy path length limit. If so, the Linux version of Node.js will suddenly become much more useful than the Windows version.

> It remains to be seen if this is better (more performant) or worse

Sounds like performance, at least, will be better. TFA says "it's totally shit hot! The sysbench utility is showing nearly equivalent cpu, memory, and io performance." I'll reserve judgment until I see the fork() benchmarks. :)

Depending on what version ranges dependencies are locked to, you could still end up with a pathological situation which breaks the path length limit, but I've only had that happen once since switching to npm 3, and it was easy to resolve.

The problem is that the Win32 user mode system will fight you every step of the way: CSRSS will not understand what you just did, for example. It's not generally worth it.

MAX_PATH in Windows = 260

Path to Linux file system root from Windows user space:

"C:\Users\<user>\AppData\Local\Lxss\rootfs\" - about 45 chars

Max depth reachable from Windows user space = 260 - 45 = 215

  /home/user/dev/my-proj/node_modules/concurrently/node_modules/chalk/node_modules/has-ansi/node_modules/ansi-regex

Windows also has mountpoints. When I use a Windows system, I pretend that C: is the only drive, and mount external volumes under the root, Unix-style. I then install Cygwin in the C:\ root, creating the illusion of a fairly Unix-ish filesystem layout.

The only place that / as a directory separator doesn't work is when interpreted by cmd, as it's then ambiguous with DOS-style switches. And even then, modern cmd tries to understand / properly when possible. Most of the time it works as long as it is not the first character of a path (which you would not frequently see in Windows anyway), as there's then no way to tell it apart from a switch with a long name.

The canonical representation of paths in Windows uses a backslash, but 95% of the time the slashes are interchangeable.

I can confirm that from personal memory.

At the time, the biggest vendor of UNIX-like systems was Microsoft (Xenix), so compatibility was a benefit. They soon sold that product off, though.

They can also of course load DLLs, and there are APIs for moving your app Windows around (with some limitations).

That said, I do not know exactly what they're doing here, and it may be using some new capabilities being added to the system in the rs1 release.

One of the good things about using "newer" languages than C for building cross-platform utilities[0] is that things like that come baked in[1].

[0] - https://github.com/EricLagergren/go-coreutils [1] - https://golang.org/pkg/path/filepath/#IsAbs

How do these ubuntu tools interact with the rest of the windows system that they are running on ?

Can I 'kill -9 explorer.exe' ?

Can I touch a file in /mnt/c/(whatever)/Desktop ... and have that file actually show up on my windows desktop ?

I think the command that you meant to say was killall :) `kill` will only kill pids, not process names.

* https://technet.microsoft.com/en-gb/library/bb463219.aspx#EH...

* https://technet.microsoft.com/en-gb/magazine/2005.05.interop...