Hacker News Reader

Comment by y4mi | Hacker News Reader

I'm forced to use Windows at work and am so looking forward to wsl2.

Starting a new terminal with wsl1 takes so long and I'm less than happy with all terminal emulators.

ConEmu has broken copy paste, alacrity doesn't have proper tiling... Heck, I've started using hyper of all things.

I realize that I probably never be happy on Windows when I can actually use i3wm at home, but if it could just suck less I'd be so ecstatic.

View on HN

The new Windows Terminal is looking very nice so far:

https://github.com/microsoft/terminal

You still have to build it from source in VS 2017 or 2019, and there are a few rough edges (currently only middle click for copy/paste), but it's a great start. They should have some official binaries up pretty soon.

You can grab build artifacts from builds of the master branch off their CI. You need to enable developer mode to allow the loading of an unsigned binary.

https://dev.azure.com/ms/Terminal/_build/results?buildId=203...

As far as I know, it's not possible to install these binary artifacts as of now, as they don't have any certificates with the msix package. You'd just get an error `error 0x800B0100: The app package must be digitally signed for signature validation.`

It's easy. unzip the appx, and run Add-AppxPackage -Register AppxManifest.xml.

This way you are registering the app directly instead of installing the appx.

They just released an early preview build in the Windows Store:

https://www.microsoft.com/en-us/p/windows-terminal-preview/9...

Interesting, I've never had an issue with WSL1 startup time. Meanwhile WSL2 startup time is supposed to be strictly greater due to its use of a VM. Maybe you have a configuration issue?

I would hope it is not a new VM each time?

I would think not, but the point is that it has to be booted at some point (whereas that wasn't a concern with WSL1)

It boot pretty fast, just 2 seconds here.

I just got WSL2 from the Windows Insider updates and it is great so far. Things like git are way faster and I can run docker on Linux.

If you're using Docker on Linux in WSL2, how well are volume mounts to the host OS? I try not to use them in Docker Desktop as, for example, a sqlite3 file in the host and the guest access will eventually corrupt the file in my experience. MSSQL in docker also performs at about 1/100th the throughput if I put the data files in a volume.

I've hence been avoiding volumes for things other than static files or backup/restore directories.

From TFA:

> Also, bind mounts from [Docker on WSL2] will support inotify events and have nearly identical I/O performance as on a native Linux machine, which will solve one of the major Docker Desktop pain points with I/O-heavy toolchains.

Oh god yes, git status finally works in less then 10 seconds. That's actually the only thing I wanted from Microsoft.

Finally there's progress on this front. I've been spoiled by Magit and using git any other way takes a lot of effort, but it's a non-starter on Windows when it takes 2 minutes to do magit-commit because of the number of git subprocesses it runs. I almost thought it would be unfixable due to the different process model of Windows. The official docs[0] on this issue also depressed me for a time...

[0] https://magit.vc/manual/magit/Microsoft-Windows-Performance....

I'm still stuck with Cmder/ConEmu, but it does something worse for me than breaking copy/paste: Breaking arrow-keys in insert mode in VI. I'm only a very light VI user, but it's still very bothersome.

This might help you:

https://github.com/cmderdev/cmder/issues/1832

Thanks, but it's not quite my issue - arrows work everywhere else but not in vi. Also, cmd.exe doesn't have that same problem. So far no .vimrc setting has helped me. I've resigned to just wait for Microsoft's new cmd.exe.

Are you opening vi with `vi` or `vim`? And does it behave the same whichever you use?

both the same. pressing left arrow in insert mode shows "E388: Couldn't find definition", but only in Cmder. Same WSL with cmd.exe - vi works fine.

I am also pretty happy with WSL, but I'm even happier that I was able to get a mac at work lol.

Although I admit, sometimes the BSD toolchain poses some rather hilarious speedbumps. At that point WSL can be smoother? Weird.

I switched from Mac to WSL last year and yes, in some ways it is smoother. Having for example apt-get on top of the NT kernel is better than Homebrew on Darwin. It's worse in other ways that are slowly getting fixed, such as the sad state of terminal emulators on Windows. At least one thing will probably always be better on Mac: Settings/Defaults system with Plist files vs. Windows settings and the Registry. But to me that doesn't justify the lack of good laptop hardware choices anymore - PC laptops are so much better nowadays.

> Having for example apt-get on top of the NT kernel is better than Homebrew on Darwin

Can you go into more detail about why that's the case — package selection, versioning policies, etc.? The main thing I've typically found is testing version-matched deployments and Docker has made me care about that a lot less.

Sure, we're heavily docker based too, but for development toolchain it's really valuable to have such a well supported package manager as apt. It's not just about package availability but community support - you have the same tooling locally that is widely used server side, so lots more documentation exists for it. Same goes for Linux userland vs. BSD.

So, why don't people just install native Linux in VMware or something instead of keep fighting with the host OS?

It's not easy for most... In the past I'd run a headless linux in a VM, do a network mount to my host environment, to edit local and run in the VM over SSH. It works, but setup is a pain.

Do you mean as a personal pain when you're not used to setting up a Linux environment?

If the IT department prepared a pre setup image, all you need to do is boot it up.

I mean setting up file sharing and getting the mounts working properly inside/outside the container so you can use a GUI editor on the actual desktop, while running programs in the VM... it's not something easily setup ahead of time.

Just install coreutils, findutils, and gnu-sed from Homebrew. Your muscle memory will thank you.

Have you tried the mintty solution for WSL?

https://github.com/mintty/wsltty

I've found it to be the most consistent and performant. Still not the same as being in a native Linux environment, of course, but it's the closest I've been able to get in Windows.

My main issue with ConEmu was output performance. Paging through files in Vim over SSH was painfully slow. I recently switched the wsltty [0] and after changing some display prefences (Font: Consolas 9pt, Theme: dracula, Cursor: blinking block) I'm really satisfied with it as a terminal. Vim paging performance is greatly improved, and it's smaller and faster than Hyper.

Also, copy/paste works perfectly and I found that fewer of the default keybindings conflict with those in my shell, tmux and vim.

[0] https://github.com/mintty/wsltty

Try mobaxterm. T works great on it's own, but will also hook into your wsl.

Starting a new terminal with wsl1 takes so long? It takes less than 2 seconds on my machine. I guess if you have some file-intensive process, such as starting a rub/python interpreter to run a script that would slow things down due to the slow file access.

I use wsltty for the terminal, it's pretty minimal, but better than the windows terminal.

I'm curious, how is copy paste broken? I've been using Cmder for a while and haven't had any issues

The middle of the copy pasted string is sometimes missing. So if I copy `echo hi && cat /etc/hostname` it's gonna paste `echo hitc/hostname`

It has 4 different paste methods in the settings, I encountered the bug on all at work. I've used it without encountering the bug before though, but I haven't figured out what causes it.

Could you just install a full-fat Linux desktop VM on your Windows workstation and live in it?

I use Ubuntu inside Virtualbox at work, but it has caused almost everyone on my team issues at some point - the whole thing freezing and needing to be restarted, very laggy GUI (scrolling in VS Code gets ugly), network connectivity issues when switching WiFi hotspots (also doesn't work with Starbucks), running out of hard disk space if you didn't allocate enough to begin with, to name a few. Sure, there are always workarounds, but the time and productivity it has costed my team would have easily justified getting a Mac, which IT thinks is too expensive :shrug:.

First, VirtualBox's performance has never been great, you'd want to use something like VMware.

Second, why use a cross platform app inside VM? Using the VM only for command line interface through SSH will get rid of any lag. You can share the host OS file system inside the VM and use GUI app on the host OS against native file system and you won't have to worry about filling up VM disk.

Connecting some $1k MacBook Air to an external monitor + keyboard would get you a decent desktop experience which you can even take it out. Not sure how that is any expensive.

VMWare or Hyper-V should perform better... though, why not go headless and just mount your linux filesystem in Windows, or vice-versa over a local network share, and edit in windows, run in an ssh prompt? That's how I've done it in the past... lately I've just gotten used to the windows-isms in git bash and Docker Desktop... looking forward to the WSL2 based release though.

That's basically what VSCode does, except without all the setup hassle [0].

[0] https://code.visualstudio.com/docs/remote/remote-overview

In the meantime, have you checked out MSYS2? It's the best option I've found for a *nix toolchain until WSL2 arrives. :)

WSL2 is dependent on hyper-v, though.

Reply on news.ycombinator.com