Friday, August 22, 2025

PluralSight: Am I Being Scammed?

Well, that's fucking dandy…

I've had a multi-year account with CloudGuru. It was useful when seeking new AWS certifications or brushing up for my re-sits. However, after they got bought by PluralSight, I set my account to not auto-renew as the content under the new site was not nearly as good as what had originally been available through CloudGuru, nor was it as good as what was available through Coursera or the CSP vendors' own learning-systems.

This morning, I get an email from PluralSight saying "You’ve renewed your subscription". Given that I'd set my CloudGuru account to not auto-renew and never set up new billing under PluralSight, this came as a bit of a shock. So, I clicked on the link in the email expecting it to allow me to view my account. I was presented with a login page for which I had no credentials. Similarly, hitting the "forgot my password" button never resulted in the promised password-reset email arriving.

Next, I checked the credit card account I previously had bound to my CloudGuru account. Unsurprisingly, I found a pending-charge from PluralSight. Contacted the phone number listed on the (pending) charge. Got dumped into a call-tree (naturally). Navigated the call-tree to sort out this billing "mistake". Got dumped into a hold-queue for nearly 15 minutes. Finally, the hold music ended and I was dumped over to a "there's no one available to answer your call: would you like to leave a message" automated-response. Uh... You couldn't have just dumped me straight to that if there's no one answering calls??? At any rate, I left a message. However, at this point, this all REALLY feels like a scam (or yet another private-equity enshittification cum cash-grab). I guess the best way that entities like PluralSight can make money off their acquisitions is to ignore the acquired companies' customers' wishes and just "convert"/renew them any way.

Fuck those guys.

Wednesday, August 20, 2025

WSL Space Recovery

Recently, the backup client I use for my laptop started popping up, "operation aborted: out of space" messages. I'd been confused because, the last time I'd looked — just a few days prior — I had over 100GiB of free space in my boot-drive. Yet, when I looked at my disk-utilization, I only had a few tens of MiB free. WHAT??

So, I began the process of tracking down what was suddenly chewing up all my disk-space. Ultimately, I found a nearly 70GiB "ext4.vhdx" buried deep within my Windows home-directory's "AppData" hierarchy.

Did a quick web search and found that what I was seeing was the virtual hard disk for my WSL2 instance. This confused me because I'd been pretty scrupulous in keeping my WSL2 instance's storage in check. In fact, when I checked, my WSL instances visible storage was only 23GiB, nowhere near the 70GiB+ of the "ext4.vhdx" file that was backing that 23GiB of visible storage-usage.

Further Googling turned up that WSL doesn't really reclaim freed storage. So, that differential between visible storage an the size of ext4.vhdx" file was effectively wastage. Presumably my virtual hard drive was significantly sparse.

Next thing I looked up was "how to reclaim wasted space in a WSL drive." Ultimately discovered that I needed to:

  1. Stop my WSL instance
  2. Back up my WSL instance
  3. "Optimize" my instance's hard drive
  4. Restart my WSL instance

The first step was dead easy: just fire up a command.exe (or PowerShell session), then issue a `wsl --shutdown`.

Second step was also fairly easy, as it was something I was doing every few months, any way: while my backup client should be backing up the virtual hard disk, I don't trust that those backups are anything beyond "crash consistent". At any rate, I took the opportunity to do a:

wsl --export <WSL_DISTRO> G:\WSL_Backups\<WSL_DISTRO>\backup-$( date '+%Y%m%d' ).tar

Once I found articles on the subject, the VHD compression was also pretty straight-forward (and, thus far, no need for the backups):

  1. Open a PowerShell window (the optimization-command is a PowerShell commandlet) 
  2. Navigate to the directory hosting the VHD file 
  3. Execute Optimize-VHD -Path .\ext4.vhdx -Mode full.

The optimization crushed the VHD file back down to a hair larger than the (internal to the instance) disk-size. 

Restarting my WSL instance is just going into my Search box and typing in the name of my instance, then clicking on the menu-item that appears.

Situation fixed, my next problem was, "why the hell did I end up with such a huge disk-image in the first place". The answer to that didn't really come until a few days later when my VHD blew up again.

I primarily use my WSL instance for work-related stuff. Recently, I'd been using podman to do some — a bunch, actually — container work. Worse, some of that Podman-based container-work was resulting in Buildah images getting generated. Whenever I would run `podman system prune --all --volumes && podman system prune --external`, the tool would tell me I'd recovered 5-20GiB of space (particularly the --external runs). 

Those space-recovery numbers made it occurr to me, "are my podman activities blowing my disk up?" So, after a fresh `… Optimize-VHD …` run, I decided to see if I could intentionally provoke a "VHD is multiples of my visible-use" situation. And, yes, I could.

Moral of the story: while you can use WSL instances with things like Podman, doing so will likely make it so you'll need to habituate to doing more system cleanup activities.