I got the input_value: bad bigarray kind error in Unison. What I did before I got the error was to change some permissions on files on the server. Unison is not picking those up from the laptop, and the process ends with the error and no file transfers.

This makes my last entry somewhat problematic.

I tried the Windows version of Unison once, and it was permissions trouble that kept me from using it. The Unison files in Cygwin are living in a Windows filesystem, and maybe it's still a problem.

tl;dr: The Windows Subsystem for Linux is shiny and new, and its great when your environment has to be exactly like Ubuntu (or whatever distro your WSL is based on), but if your aim is to use Linux tools on Windows files, Cygwin is a better choice.

Cygwin, the Linux environment for Windows, has been around for a very long time, but I've never used it. Until now.

During the year or so that I've been running Windows 10, I tapped into the Windows Subsystem for Linux (aka Bash on Windows, aka Ubuntu on Windows) as my Linux-in-Windows environment so I could have the best of both worlds, or at least all of one world and a great deal of the other.

When I first started with Windows 10 and the WSL, what I thought I would do with Linux on Windows was manage files and do little sysadmin-style tasks like update this blog via Unison (very doable in the WSL) and back up Windows files (NOT doable in the WSL). I thought I could have a Windows computer but do everything in a Linux shell.

It was not meant to be.

Once I realized that my WSL and Windows filesystems were on two different islands and that using one system to edit the other's files was difficult at best and file-destroying at worse, I abandoned my idea of using WSL Linux tools to manage my Windows environment.

As I say above, I used the WSL as my Windows 10 blog-writing and syncing environment, and it has worked very well for that task, except that my files are all in the WSL filesystem, and I have to do all of my writing in the WSL's Bash shell. That's not a hardship per se. I used the opportunity to improve my Vim skills, and I got even better with Vim when I began using it on the Windows side to do my text processing and editing.

Still, having to transfer text files and images from Windows to Bash/WSL was an extra step. I do have a Bash script that does it for me, but it would be easier if the WSL could work with files anywhere on the Windows drive..

Recently something — and I can't remember what that something was — got me thinking about Cygwin. It has LOTS of Linux packages, including the old version of Unison that I had to pin in Ubuntu WSL so my syncing setup would continue working. And it was made to work in the Windows filesystem.

I downloaded and installed Cygwin, and I began building up my environment. I even added X and the Geany text editor just to see how the GUI works. (It's awkward but usable. Unlike X on the WSL, it is supported.

Unfortunately, while I initially got Cygwin's Unison to work with my Linux shared-hosting account, once I changed some file permissions on the server, the file-synching program stopped working. So I'm back to the WSL for my Unison synching needs. I also installed rsync, and I still hope to be able to use it to back up the Windows side of the laptop.

I've already been using Cygwin instead of the Git Bash shell (which I've been using since I discovered it in my Windows right-click menu) to create files and directories in Windows, though Cygwin's failure to run Unison seamlessly with a Linux server on the other end has somewhat tempered my excitement over having yet another Linux alternative in Windows. Today I just right-clicked into Git Bash to create a few files and directories for my morning news production.

You may be thinking, "If he's so comfortable with Linux tools, why use Windows at all?" That's a fair point. I'm not happy about Cygwin's inability to sync with a Linux server, but I still have the WSL, and I recognize its value.

One of the reasons I decided to do much of my daily computing with the Windows 10 operating system that came with my other newer HP laptop is the constant trickle of issues that I'm tired of dealing with in Linux.

I'm running a newly installed Fedora 28 on this 2012-made (and 2013-bought) HP Pavilion g6 -- meaning there has been ample time for all hardware incompatibilities to be resolved. But when returning from suspend/resume, everything works except for the wired networking. WiFi is fine, as is the display, sound, keyboard and mouse.

But wired networking won't work until I reboot.

For the record, the WiFi card is a Qualcomm Atheros AR9485, and the wired Ethernet card is a Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller, both according to lspci.

The "culprit" in this case is the r8169 module, and I tried this 2013-era fix: Fix Network after Resume from suspend in Ubuntu or Linux Mint.

This ancient fix did not work.

While there's a detective/hobbyist aspect to solving these problems in Linux, I'd rather that things just worked. I saw a Fedora bug report on this issue from 2016, and it's fairly obvious that this regression hasn't been resolved. There's even a 2018 update that points this out.

The good part of this bug is that it only affects my Realtek wired interface. The Atheros WiFi interface works fine after suspend/resume, and since I use WiFi most of the time, this issue shouldn't keep me from getting things done. It's still a pain.

Before my Fedora 27-to-28 upgrade failed in a spectacular enough fashion that I had to figure out how to reinstall the operating system while keeping my user files (spoiler alert: I was successful in doing it), I had a system that had been though maybe 10 successful upgrades and had collected plenty of cruft along the way.

This particular laptop, now a 5-year-old HP Pavilion g6, made it through the transitions from yum to dnf and X11 to Wayland and from the time the Catalyst/AMD driver worked to when it didn't (and I didn't need it).

For the F28 upgrade to go wrong was very much out of character for my experience with Fedora, which I began using with F13 (quickly upgraded to F14) on my previous laptop, a 2010-era Lenovo G555, before an upgrade-gone-bad sent me to Debian for the rest of its life. That cheap Lenovo died a quick death in 2013, going to sleep one minute, not waking up, ever again, the next.

There were and are many reasons to run Fedora. But for me, the constant flow of new Linux kernels meant my at-the-time new hardware would be supported much more quickly than in distros that kept the same kernel for the life of the release. And to get that constant newness, all I had to do was make sure the system was updated. That was my No. 1.

Read the rest of this post