Windows Subsystem for Linux is out of beta

I own a Surface Pro 3 and a Surface Book. Both have only been improved through firmware updates after release. There was actually some pain points on the SP3 right around release that caused some headaches.

It depends which Mac you feel is most comparable to the Surface Laptop, what value is placed on Touchbar (if any), what value is placed on a touchscreen (if any), how much value you place on a slightly faster integrated GPU or a slightly faster CPU (Macbook Pro 13" or Surface Laptop respectively), and numerous other metrics.

Broadly speaking I'd likely say, "similar," but there might also be a $200 saving buying the Surface Laptop relative to a similarly spec-ed Macbook Pro 13". I don't consider that a significant saving when we're discussion laptops costing over $1200, but the savings grow as price increases.

What kind of specs/graphics/resolution do you get on that for games?

Absolutely zero reports of problems. None.

This makes absolutely no sense since the only buyers of Surface products are as of now pretty much only "pro" users.

Did they solve long file/path name issue? Remember Windows 7 slow FS with large file count and npm/js breaking everything due to long, nested paths.

.. and:

* Freedom.[3]

* Privacy, security and transparency.

* Peace of mind, never be forced to upgrade your hardware or software. Your hardware is yours and you can use it until it literally breaks. You control your computer and not the other way around.

?

Some things may exist (e.g. Chocolatey), but why not use a better package manager?

Docker on Windows is not native, it runs on a VM and uses Linux under the hood.

> Chocolatey is a great package manager. Others also exist.

Chocolatey is a step in the right direction, but it probably doesn't integrate as well as apt or dnf, you still have the Windows Store to update separately, and the Windows Store is what Microsoft wants you to use.

Chocolatey is more like a bandaid solution that was made by the community to deal with the limitations of software installation on Windows.

So I think Linux does package management much better than Windows, but this isn't to say that Chocolatey is bad, it's just that Microsoft has total control over everything on Windows.

I also like how Linux distros share a common file system hierarchy and share libraries between programs, while minimizing disk space and reducing security issues.

> You can use most GNU tools.

Yes, that's because those GNU programs are cross platform, which is good.

Free software also allows others to port programs to other platforms, which is also a very good thing.

> You can use any hardware you want

This isn't completely true, you cannot take your existing Windows drive and just plug it into another computer and expect everything to work, but you can do this just fine with Linux.

An existing Windows install and its license is associated to the machine where you have it installed.

Also, Windows won't run on other architectures other than x86 and I think ARM? Linux is known to work with ~20 different architectures or more.

Another advantage with Linux is that the drivers are built into the Linux kernel, so when a driver is added to the Linux kernel, it will be maintained and improved as part of the kernel, so your hardware will be supported for a very long time / forever.

This is unlike Windows where hardware vendors will release a blob for Windows and won't provide updates after the hardware is EOLed or for the next version of Windows.

I still have old printers that still work fine with Linux but the same printer doesn't have drivers for the current version of Windows anymore.

Linux is the only OS kernel with more hardware support than any other OS out there.

> Performance is good on Windows

Performance tends to vary depending on what you are doing and what you are comparing against.

So this is debatable, and one would need to run benchmarks to be sure.

That said, I find Windows to always be slower than Linux, running Linux on the same machine tends to be faster for the things I do, and Windows tends to slow over time whereas Linux doesn't.

> Freedom, i.e. FOSS is ubiquitous on Windows too (not as much as on Linux for sure tho).

You don't have freedom with Windows, you cannot give a copy of Windows to your friends, and you cannot inspect the Windows source code to learn and/or to modify it or fix anything in it.

> Privacy and security is good on Windows 10. Linux desktops are honestly not that safe.

[citation needed]

Do you have any sources to back this claim? There are a lot of security/privacy concerns with Windows 10, especially with the likes of telemetry and backdoors.

> Powershell is way better shell then anything Linux has to offer.

How is PowerShell better than the many different shells we have on Linux? I don't think this is true.

There is also PowerShell on Linux.

> Games still work better and there are more supported.

Linux has Steam now and many games are being released with Linux support every day, Vulkan is also taking off on Linux.

> More commercial tools are available for Windows.

There are many commercial tools coming out for Linux too, and this is only going to increase.

> Honestly, the only difference now is the culture around it.

It's not just about the culture, GNU/Linux and Windows are different operating systems with different ideas, purposes and design.

Windows is merely a company's product.

GNU/Linux is about freedom.

Happened right around the switch to systemd with Debian Sid on my old T410, which by that point was probably 5 years old. IIRC, the system would resume from sleep or hibernate but the console would not recover properly, so you had to force a VT switch to get the video to reinitialize. Just a huge PITA.

I agree, it had been stable for some time up to that point, but when it broken again, that was the last straw for me, and as a consequence I've stuck with Windows 10 on my Carbon.

These days tlp gives power management on Linux a good set of defaults. Powertop tweaking should not be necessary as long as you use a distro that supports tlp.

Could be. But I'm happy with Windows 10 on my Carbon and have no intention of switching.

It used to be that Linux was on balance the better choice for my use case, being more stable (as in, fewer crashes) and more transparent, with a superior dev experience. Yes, it was always a platform for tweakers... things never seemed to consistently work quite right (hell, back around 2010, it was a miracle if sleep or hibernate worked at all). But since you could open up the hood and mess around, I was willing to live with that given the benefits. As a result, for 20 years Linux was the operating system I ran on every piece of hardware I owned. I even built a 3-tuner MythTV backend and two front-end systems for my home back when I still had cable... you can't imagine all the tweaking!

But over the years the gap has closed considerably.

Windows has become substantially faster and more stable, and tools like WSL have made it a much nicer dev platform. Linux is still far more transparent, obviously, but the stability of Windows 10 means that just doesn't matter that much.

Meanwhile, with Linux, in my experience the need to continuously tweak and deal with random breakages continues to be a fact of life, while distros have become far less transparent through the switch to systemd, making tweaking and fixing things substantially harder (trying to diagnose those issues I described earlier was basically impossible).

As a result, Linux simply doesn't offer enough value for me, at this point, to motivate the hassle.

Of course, as always, YMMV. Some people have a higher threshold for this stuff (certainly I used to be a lot more willing to put up with Linux's idiosyncrasies), and different hardware, distros, etc, perform differently. So I'm not going to claim my experiences are universal. But they are my experiences.

If you like Windows apps, why run WSL?

Symlink ~/code to /mnt/c/Users/jamie/code, run whatever editor I want in windows to edit the code, and run my app from linux-land in the console. Hasn't given me a hiccup yet, even with a local sqlite database and such.

If you just treat your linux homedir as a spot for dotfiles and symlinks out to windows, it shouldn't give you much trouble unless you're doing stuff that relies heavily on owner/write permissions.

I have to maintain a separate build system for Windows, all the win32 specific code, and also test under Windows... and most of this requires a Windows license

if I can rip all of that out by outsourcing the compatibility testing to Microsoft: all the better, even if I have to add a line to the documentation requiring users to check a checkbox once in some control panel somewhere

Shouldn't you be happy that WSL will enable F/OSS devs to write cross-platform software much easier by not having to keep two sets of code?

WINE originally stood for "WINdows Emulator". It was several years later that it became "WINE Is Not an Emulator". The change was for marketing reasons, not technical reasons, since nothing had actually changed in how WINE worked.

The first time anyone suggested "WINE Is Not an Emulator", as far as I've been able to track down, was late August, 1993, over concern that Microsoft might win its trademark case over "Windows" and come after WINE. Someone suggested WINE become WAW, for "WINE Ain't Windows", and someone else responded to that suggesting "Wine Is Not an Emulator".

Soon fear of the trademark issues abated and nothing happened for quite a while.

By 1997, the "not an emulator" usage had become an acceptable alternative. The Wine FAQ late that year said:

> The word Wine stands for one of two things: WINdows Emulator, or Wine Is Not an Emulator. Both are right. Use whichever one you like best.

The dropping of saying WINE was an emulator came in late 1998. The 981108 release notes said:

> This is release 981108 of Wine, the MS Windows emulator.

The 981211 release notes said:

> This is release 981211 of Wine, a free implementation of Windows on Unix.

From what I was able to find, it seems there were a couple reasons for dropping calling it an emulator.

One was that it could be used for more than just running a Windows binary on Unix via emulation. It could also be used as a library that you could link with code compiled on Unix. This provided a way to provide a native port of you Windows program to Unix instead of running the Windows binary in emulation.

Calling it an emulator unnecessarily pigeon holed it.

Another was that emulators that emulated hardware were getting popular. People were making emulators that emulated x86 hardware on RISC systems. They were making emulators that emulated older personal computers, like C64 and Apple II. They were making emulators that emulated console gaming systems like NES.

One thing all of those emulators had in common was that they were very slow, in the sense that emulating one instruction of the emulated machine took many instructions on the host machine. For emulating the old gaming consoles, or the old 8-bit personal computers, where the host machine was running two or three orders of magnitude faster, that was not a problem--the emulation could run as fast or faster than the original machine actually ran. But when emulating something more contemporary, such as emulating an x86 PC at the hardware level to run Windows on it, they were very slow.

Since hardware emulators like these were the only kinds of emulators most people encountered, people tended to see "emulator" and read "ridiculously slow". If they kept calling WINE an emulator, many people would think that means it is ridiculously slow and avoid it, so they stopped calling it an emulator.

It's kinda funny: the Windows NT kernel (and Executive, the actual native API) are a single-root object hierarchy where everything gets mounted - much like unix - only even moreso. Mutexes, Registry Keys, etc are all objects mounted in the root filesystem.

I guess everything old is new again. Microsoft used to have a server product called Services for Unix that replaced the built-in POSIX 1.0 subsystem with a legit Unix environment but it was always a neglected product that only existed to get people to port server apps to Windows. This time they're doing the integration on end-user desktops and have spent more time getting Win API integration working smoothly.

You purposefully installed a pre-release version in which they heavily mentioned there would be major bugs and other unfinished things in it.

I'm not sure what you expected here but unless you're talking about the release version I don't think you're being fair at all.

> They did. My point was that I just don't want to encounter bugs.

What an awful response. If that's the problem you have then the solution is that you don't run beta software. You're not really making a sensible point by citing bugs in explicitly-marked-as-beta software as a reason to avoid release software that has already fixed those bugs. I would give the final version a try before complaining about nonexistent bugs.

Try the Mac trackpad, I think you will love it.