I ran Fedora from F18 through 25 and never had a problem getting my laptop to boot and run. But in my first month as a Windows 10 user, an upgrade has already hosed my laptop, causing me to restore it to its original state and reinstall my applications.

I'm not sure what the update was supposed to do, only that it was big and would require a lot of time and a number of reboots.

After a bunch of those reboots and a lot of time, I was left with a black screen and a cursor. That's it.

I could ctrl-alt-del and get a prompt to shut down, but I couldn't do anything else. I think the updates "broke" the video driver.

So since I only had a month "invested" in the OS, I could have wiped the entire thing and put Fedora on the laptop. But I decided to give Windows 10 another chance. I liked having the Ubuntu command line, even though it was the ancient 14.04 instead of 16.04. And I had my blog set up to deploy from that Bash command line.

I opted to reinstall the system and keep my user files, which is one of the options available on this HP Envy laptop. I assume it's the same (or nearly so) on most PCs. There is a "restore" partition that contains a copy of the original OS files, and that is what is used to reinstall the system software.

That operation took a long time, but at the end of it I had a working Windows 10 laptop once again. All of my user files were intact. But as promised, my applications were all gone. I did get a handy HTML list of them, mostly with links to the project web sites. However, I did have the install files for all of them in my Downloads file, and all I had to do was reinstall.

I did lose lots of configuration files.

I still have Vim and Gvim WITH configuration files because I elected to use the binaries from my Downloads file and not "install" them the usual Windows way. So when my laptop came back, the only application icons on my desktop were vim and gvim.

In a more grim note, the Windows Subsystem for Linux, aka the Ubuntu command line, aka the Bash command line, is NOT in any user account, nor are the files I created in Bash. That means when I did the reinstall I lost the WSL and everything in it. Pro tip: Back up your WSL files!!

I can re-create what I did in the WSL, though I won't be happy about it. And I have no idea if the laptop now has the update that broke it yesterday, or if it's coming down the pike in the days or weeks ahead. I'm certainly not going to go to the Windows Update screen and click anything that reads "update now," or whatever it says.

I have heard about this black screen issue here and there, but it doesn't seem to be widespread enough to cause any kind of massive panic. And while I'm sure there is some slick way to fix what was broken, I couldn't figure that out, and doing the restore (while keeping my user files) was the quickest, easiest way to get going.

And to elaborate on what I say at the top, if you "keep your nose clean" in Linux, meaning not try to use proprietary video drivers or do anything stupid with dodgy packages, it's pretty hard to unknowingly kill a working Linux installation. I thought the same was true for Windows, but now I know otherwise.

Update: I reinstalled the Windows Subsystem for Linux, and this time I got Ubuntu 16.04 and along with it a much newer node.js (good because 14.04's hella old) and a newer Unison (not so good because now I have to find this same version for the CentOS server I use to host this site). The Unix gods, they giveth, they taketh.

Caveat Emptor: Windows 10 is not a beta, but the Windows Subsystem for Linux is. Back up everything. All the time.

Windows Subsystem for Linux and Unison update: My "old" WSL was Ubuntu 14.04, which has Unison 2.40.102 in its repository. I have Unison 2.40.102 on my CentOS server, so that worked out. Unison requires the same version on both "sides" (i.e both servers/computers) to work. My "new" WSL is Ubuntu 16.04, and that offers Unison 2.48.3.

My choices were to a) get Unison 2.48.3 for CentOS 6, or attempt to compile it on the server (or a CentOS 6 desktop, which I don't have) or b) find Unison 2.40.102 for Ubuntu 14.04.

I thought that it would be easier to compile on the server. I got the source of Unison 2.48.3, but I ran into problems pretty quickly because I needed a newer ocaml. I was already getting in the weeds.

So I switched gears. Could I download a .deb package from the Ubuntu repository into the WSL and install it?

I got the Unison 2.40.102 from the Ubuntu 14.04 repository. Then I used apt to remove the Ubuntu 16.04 version of Unison.

Then I used dpkg -i to install the .deb. I ran unison -version. It was working, and provided the output I wanted: Unison 2.40.102.

$ wget http://mirrors.kernel.org/ubuntu/pool/universe/u/unison/unison_2.40.102-2ubuntu1_amd64.deb
$ sudo apt remove unison
$ sudo dpkg -i unison_2.40.102-2ubuntu1_amd64.deb
$ sudo apt-mark hold unison
$ unison -version

I had already restored my .prf file in the .unison directory (I call it ode.prf to sync this blog), and I ran the command I use for the first sync when all the files are on the server and none on my laptop:

$ unison ode -batch

The -batch switch lets unison sync all of the files without asking you to OK every single one.

I love that I can get a new computer, or start a new directory and use Unison to mirror what's on the server. More on Unison in my next post.

I want to run Node, so I figured that I would install the package from the Ubuntu LTS in the Windows Subsystem for Linux and just use it from the Ubuntu commmand line in Windows 10.

But I soon learned that the nodejs in the WSL is v0.10.25. That is hella old. Early 2014 old. No ES6 old.

I don't want to mess with the WSL environment too much, and I have no idea what kinds of binaries from outside the WSL will even work (if any of them will). But I wanted a newer -- a much newer -- Node.

So I installed the Windows version of Node -- the Current version -- which is v7.9.0.

That is a lot newer.

I'm not building major web applications with Node. I'm mostly using it to learn Javascript and even do some traditional scripting that I might otherwise do in Ruby or Bash.

Now I'll be doing that in the Windows command line and not the Windows Subsystem for Linux (until I can no longer hold out without a full, "modern" Linux distribution like Fedora on this laptop).

Update: Node v.0.10.25 in the Ubuntu Trusty LTS is super, super old. For comparison's sake:

Ubuntu Trusty: Node v0.10.25
Ubuntu Xenial (newer LTS): Node v4.2.6
Ubuntu Zesty: Node v.4.7.2
Debian Jessie: Node v0.10.29
Debian Stretch: Node v4.7.2
Debian Sid: Node v4.8.2
Fedora 25 and 26: Node v6.10.2

Even Debian Jessie has a slightly newer nodejs than the Ubuntu LTS in the Windows 10 WSL. There is a way to update the Ubuntu in the WSL from 14.04 to 16.04. Might be worth a look for me.

Update: After a Windows 10 upgrade hosed the laptop, I restored Windows and reinstalled the Windows Subsystem for Linux after that. My user files were preserved, but I lost all of the files I created in the WSL.

Moral of this story: Back up your Linux files. You can back them up in your Windows user files. I would recommend making a habit of using the WSL/Ubuntu command line not in the WSL's traditional /home directory but in your Windows user area. However, things that are complicated (and particularly which involve setting Unix-style permissions) cannot be done successfully on the Windows side. Among these "complicated" things are the use of Unison to sync two filesystems on different computers. The Ubuntu/WSL version of Unison works great in the WSL but throws errors aplenty when used on the Windows side. (One solution is to use the Windows version of Unison, but I'm a whole lot of hacking away from getting ssh working on the Windows command line in a way that Windows Unison finds acceptable; It's not as easy as subbing PuTTY's plink command-line tool.)

My new WSL turned out to be 16.04, not 14.04: This "solved" my Node problem, as I got 4.2.6 instead of 0.10.25, but I also got a newer version of Unison (and had to download, install and "hold" the 14.04 version).

The newer Node in Windows: So I could make better use of Node in Windows, I installed the Windows version of Vim, making sure the console version was included and .bat files were created so I could use Vim to edit files for Node from the Windows command line, which is somewhat of a mystery to me as I've barely used it (and many years ago at that).

As I experiment with the Windows Subsystem for Linux (aka the Bash shell provided by Ubuntu for Windows 10), I am trying to figure exactly what I can and can't do.

To that end, I created a file with Vim in the WSL. Then I tried to open it with a text editor in Windows. I get this popup that says I can't do it:

In case you're not seeing the image above (and because Google), the Error dialog reads:

Error saving file. Error renaming temporary file: Permission denied

The file on disk may not be truncated!

I also tried to use the Windows file manager to drop the above image, created in Windows, into the WSL portion of the disk. That file "shows" in the Windows file manager, but it doesn't appear at all in the Bash shell. I had to use Bash to copy it from the Windows side to the WSL/Linux side: That's what works, in case you were wondering.

I really need an easy drag/drop between Windows and the WSL ...

Update: This issue is addressed in a very interesting bug report with a lot of links I need to explore.

Also, in the image file I copied from Windows into Bash on Windows (as Microsoft seems to like to call it), the .jpg file was too wide open on permissions. It was 777, and I wanted 644. I made the change in Bash and am syncing with the server.

Update: While it seems fairly easy and routine to create and edit files on the Windows side of the filesystem using both Windows and WSL/Linux applications, when I tried to use the WSL-based Unison to sync files onto the Windows filesystem, I got a ton of permission errors and a failed sync. So the "dream" of maintaining a Windows system with WSL utilities probably won't happen. The two solutions for this particular problem are a) use Windows utilities on the Windows side and b) use Linux utilities on the WSL side.

The original entry begins here:

Now that I have my new HP Envy 15-as133cl laptop running Windows 10 and have added the Windows Subsystem for Linux, I'm exploring just how many of my regular Linux tasks I can do in this Ubuntu-supplied Bash shell, what I can do with similar programs compiled for Windows, and what really needs a dedicated Linux partition (or full computer).

Chief among these tasks is updating/syncing/backing up my Ode-generated blog (the one you're reading right now).

The first thing I learned about the Windows Subsystem for Linux (WSL for short) is that you can access the files you create in the WSL via the Windows file manager, but any modifications you make on the Windows side will not, I repeat WILL NOT be reflected in what you can see on the Linux side.

Read the rest of this post