LinLog

Minor annoyance: For some reason, WSL GUI windows like to hide themselves.  I'm not sure why.

I see this all the time on my Windows 10 work laptop, where I use WSL extensively.  It usually happens after my laptop has gone to sleep.  I come back in the morning, log in, and all of my open WSL gVim windows are just gone.  The processes are still running, they're just not displayed and they're MIA from the Windows taskbar.

Fortunately, this is easily fixed by just starting a new WSL GUI app.  So I generally just pop up my Windows Terminal and start a new gVim instance, and then the running instances pop back into existence and they're fine until the system sleeps again.

I have no idea why that happens, nor if it's specific to Windows 10 or anything else.  It's just one of those things that's annoying but not a big deal.  Rant over.

Note to self: Sometimes, it seems that WSL needs to be updated.  I mean, yes, obviously it does.  But apparently sometimes Windows updates will break it and you need to manually intervene.

I saw this the other day.  At some point, something got updated and when I tried to open a new WSL terminal, it would always fail with the message Error code: Wsl/Service/0x80040326.  Oddly enough, the WSL shells and processes I already had running still worked, I just couldn't start any new ones.

Luckily, the fix is pretty simple.  You just have to open up a Powershell instance run wsl --update to update WSL and then wsl --shutdown to reboot it.  That's it.  It's just annoying because that's a manual process - you still need to manually run the update, even if you reboot your computer.

I had a workflow revelation on my work machine the other week: Corporate IT pushed a Windows 10 update that brought me up to a version that actually supports running Linux GUI apps under WSL!

I've WSL GUI apps on my home Win11 system for a while, but having that on my work machine is huge.  I use WSL extensively there.  See, we've been standardizing our dev environment setup using Lando, which is basically a convenience layer on top of docker-compose.  It's a handy tool, but the relevant thing to note here is that it works by directly mounting your project code directory inside the Docker container.  This is convenient for Mac and Linux users, but is kind of a problem for Windows users.

As you may (or may not) know, WSL2 is great and out-performs WSL1 in every way except one: cross-filesystem performance.  As long as you keep everything inside the WSL filesystem, you're golden and everything is fast.  But as soon as you try to cross from the Windows filesystem to the Linux one, or vice versa, performance just falls off a cliff.  Sure, it's not a big deal if you just want to edit a file or something like that, but anything that does any remotely significant amount of filesystem access (e.g. running an npm install) is just painful.  In my experience, it's not unheard of for the performance penalty to be on the order of 10x. 

Clearly that's not something you want to endure as part of your normal workflow.  The simple fix is to do all your work inside WSL, which for me means installing Lando in WSL and hosting my code inside WSL.  The only problem is managing the code.  If you want to do that in Windows, you need to do it over a network share, which works, but isn't exactly a great experience.  It also causes various permissions and file ownership issues for apps like Git that actually care about that.

That's where the WSL GUI apps come in.  Rather than dealing with the network share hassle, you can just install your favorite GUI tools inside WSL and run them just like you're on native Linux.  Problem solved!

Well, mostly solved.  Sadly, not everything runs on Linux.  In particular, there's no Linux port of SourceTree, which is currently my graphical Git client of choice.  But it's not that I particularly like SourceTree - it's just that I hate it less than all the other Git clients I've tried.  So I was forced to try some other options.

This part did not go well.  I tried a few different options, including GitFiend (which was nice, but would randomly crash under WSL) and Git-Cola, which was also decent, but which I had to drop because if left alone it would occasionally lock up and then somehow take down the entire system if I tried to close it.  I have no idea how it managed to do that (presumably some bug in WSL's GUI layer), but that's a different problem.  I also attempted to try Gittyup, but I couldn't, because it only offered Flatpak packages.  And, of course, the Flatpak daemon (or whatever it's called) won't install on WSL because it's missing some of the system-level stuff that it uses.  But that's a different post.

Eventually, I declared GUI bankruptcy and decided to actually learn how to use Fugitive, the Git plugin for Vim.  Turns out that Fugitive is actually pretty good and figuring it out was easier than finding a good graphical Git client.  But that's also a story for another post.

In any event, having WSL GUI apps is pretty nice.  Now I can do all my work in WSL, and still have both GVim and PHPStorm, if I need it, without having to pay the cross-OS performance price.  So I can have nice things and good performance.  Yay!

The other week I tried to install PHPStorm under WSL2.  Because that's a thing you can do now (especially since Linux GUI apps now work in recent Windows 10 updates).  The installation process itself was pretty simple.

• Download PHPStorm for Linux from JetBrains website.
• Now extract the tarball and run the bin/phpstorm.sh script.
• PHPStorm should start up.

The next step is to configure your license.  In my case, I was using a corporate license server.  The issue with this is that you need to log into JetBrains' website using a special link to activate the license.  Unfortunately:

• By default, WSL doesn't have a browser installed.
• Firefox can't be installed because the default build uses a snap image, and WSL apparently doesn't support snap.
• PHPStorm doesn't appear to be able to properly deal with activating via a Windows browser (I tried pointing it to the Windows Chrome executable and got an error page that points to a port on localhost).

So how do we get around this?  Well, we need to install a browser in WSL and configure PHPStorm to use it.  So here's what we do:

• Skip the registration for now by starting a trial license.
• Download the Vivaldi for Linux DEB package from Vivaldi's website.  You could use a different browser, but I like Vivaldi and it offers a convenient DEB package, so I used that.
• Install the Vivaldi DEB.  WSL will be missing some packages, so you have to run apt install --fix-broken after installing it.
• Go into the PHPStorm settings and configure your web browsers to include Vivaldi and set it as the default browser.
• Go back to the registration dialog and try again.  This time, PHPStorm should start up Vivaldi and direct you to the appropriate link.
• Log into your JetBrains account and follow the instructions.  The web-based portion should succeed and registration should complete when you click "activate" in PHPStorm again.

There we go - PHPStorm is registered and works.  Mildly annoying setup, but not actually that bad.

Last summer, I started playing with the DuoLingo app.  My wife originally started looking at it as a resource for teaching our son a foreign language (which is going to be part of his curriculum this year), and I thought I'd check it out.  After all, I figured we had an upcoming vacation in Mexico and it couldn't hurt to brush up on my Spanish, right?  (Turned out it wasn't really necessary - we spent the whole time on the resort and nearly everybody spoke enough English to communicate.  But that's not the point.)

Turns out it's kind of a fun little app.  Sure, the presentation is very cartoonish and oriented toward children, but not distractingly so.  More importantly, it offers enough gamification to keep it interesting and allows you to do lessons in very small bites.

I subscribed to the premium package (since I figured it would be a family thing), so I haven't really messed with the free version much.  I'm not sure how much of a difference that makes to the user experience, so caveat emptor.

The exercises cover a good range of capabilities.  They include basic written translation exercises, where you read a sentence in one language and translate it to the other, either though free-form typing or a pick-a-word interface; fill-in-the-blank exercises where you have to complete a sentence; listening exercises where you type back what you hear; speaking exercises where you read/repeat a sentence; and stories that you listen to and then answer comprehension questions.  For most exercises, the interface allows you to tap a word to get the definition, which is handy.  There are also tips that you can access and which get displayed if you get a question wrong too many times.

The gamification aspect is what I find interesting and enjoyable.  There are a number of aspects to it, so you can go as deep as you want.  These include daily challenges, like completing 12 listening exercises; long-term challenges, like learning a certain number of new words; levels to progress through; various streaks to establish and maintain; leagues to compete in; and even "friend quests" to work with another user to collectively reach a goal, like a certain number of lessons completed in a week.  You can earn "points" for leagues and challenges by completing lessons and "gems" that can be used to buy power-ups by completing challenges.  You can also buy gems with cash, if you're so inclined, but they're really only used to buy "streak freezes" or "time boosts", which you don't really need.

The thing that really helps me stay with the app, though, is the lesson sizes.  They're very short.  It varies, of course, depending on what type of lesson you're doing, but it's not a big time commitment at all.  The fastest can be as short as one minute, up to maybe 6 or 7 minutes.  Sure, you're not going to learn all that much in 5 minutes, but reinforcement helps.  Smaller lessons give you lots of opportunity for review, so you can pick up new stuff slowly and get comfortable using it.  And most importantly, if you're busy, you're more likely to actually do small lessons on a regular basis.  Is that the path to rapid fluency?  Clearly not.  But it's still a way to improve your skill with a language.