Pico Process Overview – Linux binaries on Windows | Hacker News Reader

Pico Process Overview – Linux binaries on Windows

blogs.msdn.microsoft.com

83 pointsmicrotonal23 comments

Compare to the way Cygwin does things: https://www.cygwin.com/faq.html#faq.api.fork

That link contains some fascinating insight into the machinations required to get POSIX-like behavior on a Win32 backend. Thanks for posting.

Instead, MS should create a properly supported Win ABI for Linux. That might actually be useful.

WINE and ndiswrapper are doing just fine.

I don't know when the last time you used Wine was but there's a ton of incompatibility still. A properly supported compatibility layer from Microsoft would remedy a lot of problems.

Not useful for MS Shareholders. You'd have half of MS users worldwide (that dont require ActiveDirectory) moving to CentOS tomorrow if they could run their old VB apps, MS office, etc.

I realized I was constantly programming services that would be run on Linux servers, through a Linux container dev environment, running on a Linux VM running on Windows. I finally just cut out the middle man and installed Linux (Fedora w/ GNOME3) and it was the best decision I ever made.

I might try "bash on windows" but there have been compatibility layers like this for years and there are always drawbacks. For instance it'll be years before this can be considered stable for production, so this is purely for developers. As most developers know, when you go to deploy on a production machine things don't always work the way you expected them to because the production environment is slightly different than your development environment. If your development environment is a frankenstein OS with different parts sewn together to make it work then it's going to just add further complication to the process (Will a Linux service interface with a windows service?).

My workflow involves spinning up containers (usually gentoo) on a remote server for each new project and just sshing into them and using vim and other cli tools to build projects. This has been the most superior workflow I've found. I can use a light laptop for pretty much everything because a remote server does all the hard work.

I know many developers who use this workflow and for large projects that require powerful computational resources this is essential.

The only reason I see to use Windows for development is if you were developing Windows desktop apps and I don't know anyone who's building new windows desktop apps, most people are targeting mobile. Those who do work on Windows desktop apps are usually maintaining something that's been around for years. There are a few other reason to use Windows over a unix or unix-like OS but most of them come down to Microsoft and other companies releasing proprietary software which is locked into their ecosystem, and I'd like to avoid software like that.

Also I'd just like to add that I never realized how bad fonts were on Windows until I tried other operating systems. If MS wants to attract developers they need to fix their fonts. IMO this is even more important than a Linux compatibility layer because all I do is stare at text all day.

> I don't know anyone who's building new windows desktop apps

You don't know any game developers?

In fairness with steam putting a big emphasis on linux Windows time as the OS of choice for gaming might be coming to an end.

Have you seen the Linux NVIDIA drivers‽

Have you tried win10? It's font rendering for modern app is fucking disaster, and I really mean it.

After they switched from cleartype to directwrite it is fucking disaster for display lower than 2k. I have double 1080p and it is fucking hurt my eyes to look at Microsoft edge or any UWP app text.

Mac is very popular in developers, while not being used on servers. Reason? You get high end laptops with drivers and a linux like command line. But the applications and frameworks are all different, osx and linux have separate binaries for node, java etc.

Luckily that doesn't matter, most of the programming and testing is done at a high level, where base OS doesn't matter. This is the market they are after.

As someone who has done (Unixoid) web development on all 3 systems, I'd say OSX was the best experience. On Windows it's really weird to use command line tools, even with Cygwin. There's no package manager for dev tools. Linux is fine but I occasionally had problems with UI quirks, driver issues and so on. It feels "hacky" at times. Once you've installed homebrew on OSX you have the best of both worlds. A stable Unix system with a nice UI (Though the stable part was recently lacking).

>Mac is very popular in developers, while not being used on servers. Reason?

Linux is free ?

UNIX utilities on Win32/64 still feel weird. You don't really have forward-slash paths adopted everywhere, and you have weird volume drive mounts. Writing a Windows app means you have to deal with the realities of Win specifics (e.g file systems) and the fact that you can't link to a UNIX-shared library like you can with OS X. Windows line-endings have screwed me over with running bash scripts (easy to fix with git settings). Have to deal with cmd as default shell. Windows out of the box loves the wchar_t type and std::wstring, a 2-byte character which doesn't even really encapsulate Unicode (UTF-8 is used just about every other operating system).

While OS X binaries aren't compatible with Linux, it's usually just a recompile. Sometimes there's a little more to it. But generally a lot less work than Win32/Cygwin. Yet to be seen with Ubuntu on Win32/64, but apps written in Windows Linux subsystem have been said not to be fork able from Win32/64 apps.

However, Mac's file system HFS+ is terrible. That's a good reason not to use it for servers on top of parts of it being proprietary.

You know you have countries where Microsoft still has a de facto monopoly, right? Try convincing the average Danish company there is something outside Windows.

The video in the post is worth a watch, very informative whiteboarding.

This is part of the 'drawbridge project', I wonder if the idea is to pull up the bridge at some point. Embrace, extend and extinguish.

Describe how the "extinguish" process would work.

Well, occasionally MS will deprecate an API and remove it from Windows. https://brianreiter.org/2011/09/15/sua-deprecated-in-windows...

Hypothetically, it comes after the "extend" phase, during which Microsoft alters, extends or replaces the functionality of GNU tooling in attractive ways under non-free licenses so that, over the course of several years, users end up building their applications on non-free foundations that Microsoft has made available both in windows and in linux distributions.

When moving to the "extinguish" phase, Microsoft uses their non-free licenses to unilaterally retract support for linux, leaving windows server as the only option.

There's no concrete evidence that this technique is what's going to happen, but Microsoft has a history of it and everyone who invests in this platform should be aware that even if that is not the plan right now, it is possible for the plan to change at any point down the track. I recommend maintaining a healthy level of suspicion for the next few years.

Except nobody is migrating to Windows, not on servers where it counts. It's an attempt to prevent developers from migrating to OS X, because OS X is and soon won't be (if Microsoft doesn't fumble this) more interoperable with Linux ecosystem.

Well for now their top priority is to make a binary compatible way to run pre-existing (parts of) Linux distro, and it works quite well for beta software (I would not have said the same if it was released software in the same state, but they seem to very actively be working on it and fixing bugs, and progress is shown between builds)

Some technical console details are far from perfect IMO, but already good enough for common scenarios and given the context they are in its quite impressive (even if shortcuts are taken in regard with Windows interop)

What will come after will largely depend upon the reception on the first release, I guess. Loads of people already want to at least be able to spawn Windows processes from the WSL env, but that's quite understandable and present no serious risk of extinguishing the GNU/Linux ecosystem by some kind of miracle. I would not see any point of MS going further; they have their own complete ecosystem which in some aspect is technically far more advanced and/or has far more potential than competing solutions (UWP is all about convergence and unless they reboot once again, which I think they have no reason to do anymore, they will eventually get it right on mobile, now maybe from a time to market point of view this will be too late but I highly doubt that the android subsystem will be resuscitated so I don't see what WSL could bring to that story anyway), most people are not even going to want to run WSL in production for server workloads (and would have not wanted to even if MS told them it's OK, which they did not).

The dev target is a very good choice and the approach solve 90% of the issues previous attempts (Posix subsys, SUA) had (not used enough, separate target with small ecosystem, eventually buggy because of that), and for some other applications Cygwin is already available right now and good enough for what it does and how it does it. The Posix subsys had actually been instrumental for MS to a wide take over of US public markets in an impressive bad faith stunt (and that actually was the only reason for its very presence), but the situation is radically different now and the expectation have moved to higher layers, so if they manage to use it like that again I think it will only be in anecdotal proportions.

Reply on news.ycombinator.com