[piggycurse]

Why is this blog post so negative? Microsoft are trying and giving all of the developers the tools to help affect the project along the way.

The Terminal project was only announced 1 year ago[0]. As I understand it, they had to more or less split how the whole conhost.exe work in order to allow Terminal to even exist. The settings UI is far from sexy, but they're working on it[1]. I think it's impressive to know that 6 people did that in a year[2].

Regarding the slow startup of WSL2, yes it is slow to start, but would you rather have to wait 5x for a git clone command[3]? They even have a deep dive into how files are save in WSL1 which can be related to how it works in WSL2[4]

I completely disagree with the conclusion of performance is not Microsoft's concern. The comparison is to GNOME3 which was released in 2011. 9 years of development compared to 1 year. "The polish just isn't there"

[0]: https://devblogs.microsoft.com/commandline/introducing-windo...

[1]: https://github.com/microsoft/terminal/issues/1564

[2]: https://devblogs.microsoft.com/commandline/windows-terminal-...

[3]: https://devblogs.microsoft.com/commandline/announcing-wsl-2/

[4]: https://devblogs.microsoft.com/commandline/a-deep-dive-into-...

[WorldMaker]

Regarding the Windows Terminal settings interface, the default editor is VSCode if VSCode is installed. Given the mention of VSCode later in the article I'm surprised that VSCode was not installed on this user's machine prior to attempting to edit the Settings.

(Also yes, it is unintuitive that you may want to install VSCode first in order to edit Windows Terminal settings, but is it that much of a stretch that Microsoft would imagine early adopter power users to have VSCode lying around already on their machines? As you said, they are working on a "proper" UI for Settings still, but as a first "get it out the door MVP release", especially with all the under the hood work that took to get them there, it still seems a reasonable play.)

[Zardoz84]

I don't know your experience, but on my experience W10 it's painfull slow compared to a native Linux install. I don't talking about WSL1 or WSL2 its slow compared to a native Linux. I say that the whole W10 is slow, to the point that barely is usable if you not have it installed on a SSD.

[dleslie]

I switched from WSL2 back to WSL1 because the git action times on the NTFS shared drive were _minutes_ long in WSL2.

I didn't use WSL2 for too long and so I wonder: are processes in WSL2 manageable by Task Manager and Windows Defender as in WSL1? That integration with Windows tooling made WSL1 killer for deploying tools to non-programmers; give them a powershell script and they can run the app and manage it in a familiar way.

[munchbunny]

are processes in WSL2 manageable by Task Manager and Windows Defender as in WSL1?

I haven't tried (just installed Windows 10 v1909 last night) but I don't think so, given that WSL2 sits in a VM, which WSL1 didn't.

I liked WSL1, but it had a lot of the same drawbacks that Cygwin had, which was that Windows and Linux are different enough under the hood that you start running into issues with file system performance and containers, and WSL2 fixes that at the cost of being clumsier with file management.

The solution I recall for WSL2 is to put the shared files inside the Linux instance instead of putting it in NTFS.

[dleslie]

Putting the shared files inside the Linux instance is a non-starter for me.

[munchbunny]

Putting the shared files inside the Linux instance is a non-starter for me.

What requirement do you have that has to be managed without going over to the Linux side of the system?

[dleslie]

Unity and its suite of tools. Anything that slows access to disk IO can add significant time to my large-project build turnaround.

[munchbunny]

In the case of Unity, why do you need Linux crossover? I can see also having a Unity development setup in bare-metal Linux if you plan to target Linux gaming, but WSL currently doesn't give you graphics.

The game development scenario feels to me like a case where a Windows based toolchain is going to be more coherent. I might be missing something though.

[genr8]

M$ will only open source things that don't make them their money, while at the same time, tricking developers that they care by appropriating the communities work and extracting as much value out of Linux for free as possible, for their own benefit. Providing second rate hybrids masquerading as innovations, is all they can really do, to keep people locked into Windows. I stayed on Windows desktop for 20 years even while using linux for servers, and just gave it up this year. Linux has its own problems but if I disagree with the status quo of programs, I can either switch to another distro, mod the open source code myself, or file a bug report so a real person actually does something about it. This is too little, too late, from Microsoft, and accepting it now will just lead to the demise of Linux.

[munchbunny]

I have trouble believing that Linux's demise is remotely possible at this point. Too many huge tech companies have made their beds with it for Microsoft to be able to change that.

Linux desktop has the opposite problem: it's always been niche for mainstream users because its app ecosystem has never been good enough and it's often finicky to set up, even if its support for developers has been great.

[pjmlp]

Just like Apple and Google, the love childs from communities like HN.

[juliand]

I feel like the author is nitpicking over small issues just because it's Microsoft.

They already admitted that they were wrong about Open Source and even though there is room for improvement, I'm happy that they are supporting power users more and more.

[pjmlp]

Yep, if it was Apple or Google it would have been written in another tone most likely.

[jonnypotty]

I can't belive that a shitty slow terminal impresses you as the work for 6 people for a year.

Go and look up how long it took one guy to create Unix.