The problem for users of Windows laptops using the Conexant audio driver that makes Conexant's Flow.exe program eat large amounts of CPU when the Firefox web browser is running has not been solved by "conventional" means.

And in order to be part of the "solution," should one ever come, I filed a bug with Mozilla on the issue.

There have been many fixes proposed for this problem, which only seems to manifest itself on my HP Envy laptop while running Firefox. You hear the fan rev up almost immediately and then can see both Firefox and Flow.exe climb in the amount of CPU they are taking, combining for a total of about 60% on my laptop.

This has been going on for many months, and a couple of days ago I got tired of being forced to run Chrome. It's not right that I can't use the privacy-loving Firefox on my Windows 10 laptop.

So I went back to one of the "fixes" that works:

To keep Flow.exe from running constantly and stealing excessive CPU while you are using Firefox or any other program, just change the name Flow.exe to something like _Flow.exe (I just added an underscore) so the Conexant audio system can no longer "find" it. Trust me, sound works fine without it. Why it's there at all is a mystery.

You can find Flow.exe in this folder: C:\Program Files\CONEXANT\Flow. Just rename Flow.exe as _Flow.exe (or whatever you want; changing its name is enough to keep it from running). I'm not sure whether or not you need to reboot after this, but it couldn't hurt.

Once you rename Flow.exe, You will get a popup every time you restart the PC warning you that you need to reinstall your Conexant audio software because Flow.exe is missing. Ignore this nagging box. I'd like to send Conexant a few popups, or maybe I should send my good wishes to Logitech, the company that bought Conexant a few years ago. Both are garbage. They're certainly not seeing what I'm saying about them on Twitter and consequently falling all over me to fix anything. No, it's radio silence. F&^% 'em.

tl;dr: Take care of Flow.exe problems, especially with Firefox, by renaming Flow.exe so Conexant can't find it.

I've been dealing with problems caused by the Conexant audio driver in Windows 10 while running Firefox for the entire year, and turning off services in the Windows configuration no longer works.

What happens, for those not following along, is that the Conexant "SmartAudio" driver has a program called Flow.exe that somehow helps it figure out what kind of audio you "need" at any given moment. It somehow can't figure out what to do with the Firefox web browser, and when you run that browser in Windows 10, Flow.exe runs all the time and take a substantial portion of available CPU, causing the fan to run high and the computer to work sluggishly.

Originally I was able to turn off whatever service was triggering Flow.exe. Recently that hasn't worked, so I turned to another solution I found on the internet: Renaming Flow.exe so the Conexant software can't find it and can't run it. By the way, doing this breaks nothing. Audio works fine.

To do this on your system, just change the name of Flow.exe. I changed mine to _Flow.exe. You can find Flow.exe here: C:\Program Files\CONEXANT\Flow\Flow.exe.

Before I did this, my Task Manager (which you can see with ctrl-shift-esc) output looked like this:

After renaming Flow.exe, I'm getting a message in the HP Support Assistant to update my Conexant driver, which I'm NOT doing and won't do until they get yet another new version. I also get this popup whenever I reboot:

Despite these two "nags," from Windows, everything is working.

Update on May 29, 2019: After continual nagging about the Conexant audio service not working, I finally relented and installed the latest version of the driver. My problems with Firefox and Conexant's Flow.exe returned immediately (super-high CPU all the time).

I decided to try a different hack from the HP forum: "Tricking" Flow.exe into ignoring Firefox by changing the reference to firefox to fyrefox in C:\Program Files\CONEXANT\Flow\data.sqlite, which is just a text file (that's the kind of database that SQLite is). I started PowerShell as an administrator, navigated to the file, opened it in Vim, searched for firefox and deliberately misspelled it.

I rebooted the laptop. I restarted Firefox. It DIDN'T work. I tried it so you don't have to.

This is a mess. Bang & Olfusen is the licensee for the sound on this laptop, and this association with such poor technology doesn't make me think fondly of B&O. Other companies that have failed users include HP and Conexant.

Here is yet another thing to try, courtesy of another frustrated user in the HP forum: Use PowerShell to kill Flow.exe dead.

When a device driver kills your computer's performance, but only when run in conjunction with a certain web browser, and that certain web browser is not Google Chrome, good luck with getting your problem fixed.

That's what's happening to my HP Envy 15 as133cl laptop. Running Google Chrome poses no problems.

But when I run Mozilla Firefox, the laptop's Conexant audio driver has a program called Flow that does something related to figuring out what kind of audio your PC might want to play. And when Firefox is running, Flow can't seem to figure out what is going on and runs all the time, taking a large percentage of available CPU along with it.

I solved this problem with an Internet search. It was easy and painless.

After I installed the new driver, the problem returned. I'm lazy enough that all I did was bring up the Windows Task Manager (ctrl-alt-delete, then select it) and kill Flow from there. I haven't rebooted since, Flow hasn't returned, and I'm having zero issues with audio on the computer.

Update: It's annoying that killing those two processes doesn't stop Flow from killing laptop performance. There is a third Conexant process that I should kill to see if it takes care of the Flow problem. Why it's STILL a problem, I don't know. If it affected Chrome, it would cause a major uproar and be fixed in a week or less.

I've been using the Windows command line's copy command to create empty files, but there's another easy way to do the same thing using Git for Windows.

Once you install Git in Windows, every time you're in a folder, a right-click of the mouse gives you the choices Git GUI here and Git Bash here.

If you then left-click on Git Bash here, a Linux/Unix-like terminal will open at the path of your folder, and you can use any number of Bash commands.

To create a file, use the Unix/Linux stalwart touch:

$ touch filename

This will give you a file named filename. Substitute the file name you really want.

Then close the terminal. That's all there is to it.

The Windows file manager lets you create all kinds of new, empty files as long as they either have a .txt extension or are of a Microsoft file type.

I just wanted to create empty files with no extension that I can later open in Gvim.

Basically I want the Windows equivalent of the Unix/Linux command touch.

There's a complicated Stack Overflow page on this topic, and the easiest method by far is this one that uses the Windows command line:

C:\Users\name\your\path> copy nul filename

Substitute the filename you want for filename, and you're good to go.

I've seen ways of turning this into a batch file and then somehow right-clicking to invoke it, but for now I'll just open the Windows terminal and use it that way.

I turned the laptop off and only booted once from Puppy Linux's Xenialpup over the weekend. When I turned on the laptop (2017 HP Envy) to start working in Windows 10, today, for some reason the desktop remembered that I had at least one Google Chrome tab and a few apps open.

I also started a new Chrome window for my "main" work, and the laptop was aggressively swapping for maybe a half-hour, during which time things barely worked, or were just slow as hell -- whatever you want to call it.

Now that I've been working for a couple of hours, everything is working well, but this just serves as a point of evidence that Windows 10, right when it starts up, isn't exactly ready for "vigorous computing."

The Windows Subsystem for Linux - which is no longer being referred to officially as "Bash on Windows" - has grown up.

You no longer need to put your Windows 10 system into Developer Mode to use the WSL.

And now there are three different WSLs: Ubuntu, openSUSE and SUSE Linux Enterprise Server. Fedora is supposed to be on the way, but I haven't heard anything about progress toward that happening in a long time.

According to Microsoft, you can copy your current Ubuntu files to /mnt/c/tmp/WSL-backup, or a similar directory, and then use lxrun /install from the Windows command line to remove the old WSL. Then you can install a new WSL and move your files back after that.

Fellow Redditors suggested that I create a tar archive of my files, stow it anywhere, and then unpack it in my new /home directory when I remove the old WSL and install the new one via the Windows Store.

The only thing keeping me from doing it is what always keeps me from switching Linux distros: The need to re-install all of my packages.

The other thing keeping me from making this move is that my laptop hasn't yet received the Windows 10 Fall Creators Update. To successfully install the new WSL, your Windows build needs to be 16215.0 or higher. According to my About Windows 10 page, I'm on 15063.674. So not only can I wait, unless I opt to get the updates early (and I'm sure there is a way to do this), I must wait. And honestly, that doesn't bother me one bit.

Update: (July 4, 2018): Here is my Independence Day update to these instructions. The "original" instructions should work fine, but the "new" ones are better:

The original instructions

Originally I created the tar archive of my home directory in my home directory:

$ tar -zcvf steven.tar.gz /home/steven
$ cp steven.tar.gz /mnt/c/Users/steve/OneDrive/Documents/linux_backup/

And to open it up when your new WSL is set up, go to your home directory:

$ tar -zxvf /path/to/steven.tar.gz

Then you'll have a home directory within your home directory (i.e. for me /home/steven/steven, and you can copy what you want from one to the other). It's better not to overwrite everything in your "new" Linux /home directory because it might handle things in your dot files differently, and I can see conflicts arising from npm modules, ruby gems and whatever else you happened to install in the course of working in your Windows box's Linux side.

I'm not sure how much of a problem it is, but creating the tar archive while in your home directory causes tar to throw the following error:

tar: Removing leading `/' from member names
... (lots of output)
tar: Exiting with failure status due to previous errors

There are explanations of what this error message means on the Internet, but they didn't really help me understand it.

So I did things a different way. If you just want to know how to make the backup and restore it, start here:

The new instructions

First, on the Windows side, create a directory in which to hold this backup. I created one called linux_backup in my OneDrive Documents directory.

Then go into your WSL, which will put you in your home directory on the Linux side (which for me is /home/steven).

From there, to avoid the error message I go up one directory and do the tar operation from there. I use pwd a couple of times to confirm where I am in the filesystem, and I use chown to make sure the restored archive belongs to my Linux user and group.

Note: in all of these instructions, things after a $ are things you type at the command line. Lines that don't begin with a $ represent output in the terminal (and you don't have to type them).

Here is what my terminal session looks like:

$ pwd
/home/steven
$ cd ..
$ pwd
/home
$ sudo tar -zcvf steven.tar.gz steven
$ ls
steven steven.tar.gz
$ chown steven:steven steven.tar.gz
$ sudo cp steven.tar.gz /mnt/c/Users/steve/OneDrive/Documents/linux_backup/

Now you have your tar archive on the Windows side.

After you set up your "new" WSL, you can copy the tar archive from the Windows side into your new Linux /home directory. As before, I use a couple of pwd command to confirm where I am in the Linux filesystem. (And remember, use YOUR home directory and Windows path to your tar archive, not mine):

$ pwd
/home/steven
$ sudo cp /mnt/c/Users/steve/OneDrive/Documents/linux_backup/steven.tar.gz steven.tar.gz
$ sudo chown steven:steven steven.tar.gz
$ tar -zxvf steven.tar.gz
$ ls
steven
$ cd steven
$ pwd
/home/steven/steven

Now you have your "new" home directory at /home/steven, and your "old" files at /home/steven/steven. Copy what you want from old to new, and you should be ready to go.

Once you confirm that all your files are in there, you can blow away the old WSL and use your new one. And you should still have a copy of the tar archive on your Windows filesystem if anything goes wrong.

Before going forward, it's a good idea to read up on how to make a tar.gz archive.

My question (and maybe yours): Why do this from the Ubuntu/WSL shell when you could just copy/paste from the Windows file manager, or why not just copy the files via the Ubuntu shell to the Windows portion of the disk?

Answer (and I did test this): In both cases, even when using Bash to do the recursive cp of all the files, you lose your Linux file permissions. In my case, all of my rw-r--r-- files turned into rwxrwxrwx, which is NOT what you (or I) want.

Update on 4/23/18: This entry was written last October but not published until now. It kind of got lost, and I just found and finished it. Though the new WSL is out, and you can now install Debian (which I would) or SUSE (probably not), I'm leaning toward sticking with Ubuntu because it's working so well, though I'm a longtime Debian fan and user (though not so much lately).

Whatever I do, I probably need to move to the "new" WSL, though I haven't done it yet. Everything is working, so it's hard to muster the motivation to mess with what until now has been a successful installation of Ubuntu in Windows 10.

Update on 7/4/18: The new instructions for making an archive of the /home directory are more detailed and a little more roundabout. But they should work, and tar won't throw any errors.

Also, I still haven't moved to a new WSL. The current Ubuntu WSL is still on 16.04 LTS, and that's the same version as my "old" WSL. When the Ubuntu WSL moves to 18.04 LTS, then it'll be time to make the change.

Microsoft is ticking all of the right boxes with the Windows Subsystem for Linux, announcing that it will be bringing Fedora and OpenSUSE to the WSL as well as offering installation via the Windows Store.

There will also be the option of installing the Ubuntu, Fedora and SUSE version of the WSL at the same time, though it is unclear if they will have separate filesystems, and/or the option of sharing a single Linux filesystem.

I'm not a SUSE user but am a longtime Fedora user, and having the option of Fedora is a very attractive one because it's that much easier to get newer versions of things like Node, Ruby, Java, etc., in this developer-centric distribution that is a lot more stable than you'd think.

As far as installation goes, the current way you get the Ubuntu-powered WSL on your Windows 10 system is more than a little bit hacky, and the use of the Windows Store will make it easier and more inviting for new developers as well as "new" Windows "power users" coming over from years of desktop Linux (like me).

There isn't much in the way of announcements on adding graphical capabilities to the Windows Subsystem for Linux, though Microsoft isn't discouraging those who are already adding an X server to their WSL, but I figure official support for Linux GUI software in the WSL is somewhere on the roadmap.

For now I'm happy to be using a Ubuntu-based system for the first time in a long time (after the aforementioned years of Fedora). As I've written previously, the move from 14.04 to 16.04 was pretty crucial because I was able to get away from the super-old Node.js in 14.04, though the newer Unison required me to pin the old Unison from 14.04 to maintain compatibility with the Unison on my server.

While I've been happy to learn that you can pretty much download a Ubuntu package from the archive and install it with dpkg, I haven't yet experimented with PPAs in the WSL. Might be time for that.

Changing the directory: Since the WSL is rapidly going from a Ubuntu-only offering to one that will offer Fedora and SUSE, I'm changing this directory's name from ubuntu_on_windows to linux_on_windows.

I decided to give the new Microsoft Edge browser a try in Windows 10. When I open it, I get this page that says Google Chrome is 5 percent slower than Edge, and Mozilla Firefox is 9 percent slower.

Four things:

• From my use, I would figure that Chrome is at least 25 percent faster than Firefox.
• The scores are based on Google Octane, which is being mothballed because everybody is cheating with it.
• I'm supposed to get excited about a 5 percent speed improvement? Sharing bookmarks and passwords across Google Chrome instances on Windows 10, Windows 7, Linux and Android is more important than a small speed improvement that may not even be real.
• The more I look at this, saying Chrome is 5 percent slower than Edge doesn't mean that Edge is 5 percent faster than Chrome. Am I right, math and statistics experts? According to my calculations, if Chrome is 5 percent slower than Edge, that means Edge is 19 percent faster than Chrome. Why doesn't Microsoft tout that statistic, which sounds a whole lot better?

Nonetheless, I'm giving the browser a tryout while I'm still using Windows 10.

I am using the unison in Ubuntu 14.04 (Unison 2.40) in my Windows Subsystem for Linux-supplied Ubuntu 16.04 (which updated the package to Unison 2.48) because my server is running Unison 2.40, and I forgot that an apt upgrade will replace the .deb I downloaded from the 14.04 repository with whatever is in 16.04.

When I tried to do a unison sync, I got an error.

How do you put a package "on hold" in Ubuntu? It's easy.

First I removed the "new" unison:

$ sudo apt remove unison

Then I installed my "old" one (which I had previously downloaded from the Ubuntu archive):

$ sudo dpkg -i unison_2.40.102-2ubuntu1_amd64.deb

Now I put the package "on hold":

$ sudo apt-mark hold unison

That's it.

Here is the output now for sudo apt update:

$ sudo apt upgrade
[sudo] password for steven:
Reading package lists... Done
[sudo] password for steven:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  unison
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.