why I didn’t upgrade

I’m a software developer. I just upgraded my “dev” environment from Ubuntu 14 to Ubuntu 16, both LTS.

Ubuntu 14 was supported till April of 2019. I delayed upgrading until the last possible minute.

I have a lot of services installed and configured for several different side projects that I work on. After I upgraded, almost all of them were broken. I just spent about an hour fixing a few, and I anticipate that it will take a few more hours, maybe even a day, to get everything working again.

I’m lucky that I have the time to do this (although, I really don’t!). Many people who work on side projects only have an hour or two to work on them every week. Which would you rather do: spend an hour this week making progress on adding features and functionality to your side project? Or spend that time fixing newly broken services?

Being a developer, I am loathe to sit in my chair twiddling with config files. Usually, I’m very happy using Linux. But there are times when I long for a system that doesn’t break after every upgrade. This is one of them. And this experience is the reason that I always postpone upgrading for as long as possible – I just know that it’s likely everything will suddenly stop working when I do!

forget version control?

I’ve been noticing this ad for Google’s G Suite for a while now. It says “Get G Suite. Forget Version Control.” I’m just posting it here for posterity. Aren’t there already too many people who use email and word docs for tracking changes? Oy. Words fail me 🙂

(For anyone who is concerned, that’s a screenshot of the ad below, not the actual ad!)

Javascript Object keys cannot be Objects

TL;DR – Javascript Object keys may be strings or symbols, and nothing else. So be careful when setting key/value pairs on an Object.

In Javascript, if you use an Object as another Object‘s key, you will have problems. You will not see an error, but you will be producing a bug. I ran this code sample in the node REPL to demonstrate what goes wrong.

First, I create two completely different Objects, obj1 and obj2:

> var obj1 = { a : "a" };

> var obj2 = { b : "b" };

> obj1
{ a: 'a' }
> obj2
{ b: 'b' }

Next, I create an empty Object:

> var obj3 = {};

Finally, I set two different properties on obj3. One is set on the key obj1, and the other is set on the key obj2. Since these two Objects are different, you might be fooled into thinking that obj3 will now have two keys. But watch!


> obj3[obj1] = "test1";
'test1'
> obj3
{ '[object Object]': 'test1' }
> obj3[obj2] = "test2";
'test2'
> obj3
{ '[object Object]': 'test2' }

As you can see, both the obj1 and obj2 keys have been coerced into their string values (obj1.toString() is '[object Object]', as is obj2.toString()) when the property was added. So obj3 has only one key/value pair. The first one that was added was obliterated when the second one was set.

For anyone who is more used to working with a strongly typed language, such as Java, this can be a “gotcha!” in Javascript. I certainly made this mistake, myself, when I first started coding in Javascript, years ago. If you want your keys to be less restrictive, consider using Javascript’s Map.

how to get out of a git detached head state

I got into a “detached HEAD state” in git the other day. Here’s what happened, and how I solved it.

I had fixed a bug by making a code change to a single file. I committed the change to git. Then, I decided I didn’t like my fix. I wanted to start over from the previous commit, and redo it.

There are nicer ways to do this, and I guess you could say I did the wrong thing. What I did was to checkout the previous commit, and make my changes there. Then when I committed my changes, I saw the worrisome “You are in ‘detached HEAD’ state” message from git.

I searched around the internets and found a solution at stackoverflow as usual: create a branch, checkout master, and merge your branch into master.

Here’s a very simple example of how it went (I’m in Linux, YMMV). I start with a completely new git repository for demo purposes:

mkdir /tmp/git
cd /tmp/git
echo "Initial commit" > README
git init

Initialised empty Git repository in /tmp/git/.git/

git add README
git commit -a -m "Initial commit."

[master (root-commit) 9dee938] Initial commit.
1 file changed, 1 insertion(+)
create mode 100644 README

echo "A wrong thing" >> README
git commit -a -m "This is wrong."

[master 4ec7b1a] This is wrong.
1 file changed, 1 insertion(+)


[Oops! I want to ignore this wrong change that
I just made. So I check out the previous commit.]

git checkout 9dee938

Note: checking out '9dee938bcd5b575775f5461a383e2b6f010e0866'.

You are in 'detached HEAD' state.
You can look around, make experimental
changes and commit them, and you can
discard any commits you make in this
state without impacting any branches
by performing another checkout.

If you want to create a new branch to
retain commits you create, you may
do so (now or later) by using -b with
the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at 9dee938... Initial commit.


[Now I'm thinking "oh git!"]

echo "The right thing" >> README
git commit -a -m "What I really wanted!"

[detached HEAD 1ababcd] What I really wanted!
1 file changed, 1 insertion(+)


[Search around for solution... Got it!]

git branch temp
git checkout temp
git status

On branch temp
nothing to commit, working directory clean

git checkout master
Switched to branch 'master'
git merge temp

Auto-merging README
CONFLICT (content): Merge conflict in README


[Edit README to merge the conflicts]

git commit -a -m "fixed!"
git status

On branch master
nothing to commit, working directory clean

At this point, the problem is fixed and my new commit is checked in.

You probably want to delete your temp branch, that is what I did: git branch -d temp

term does not start in linux mint

A friend of mine just experienced a very strange issue. He uses linux mint (I use Ubuntu, and I don’t know if the same problem occurs in Ubuntu).

He tried to run term from the menu, and nothing happened. He tried running term in numerous ways (CTRL-SHIFT-T e.g.), and again, nothing happened.

Fortunately, xterm could start, so we had a toehold. The first thing we did was to take a look at the logs (/var/log). However, we did not see anything informative there, nor did we find anything useful by running dmesg.

Then we tried running uxterm, another application which we thought might work. It failed by opening with a small window containing an error message that said something like “gnome terminal locale not supported” – together with my friend’s user password, shown in the clear! That was a bit scary – it looked as if his system had been hacked in some way.

An internet search of “gnome terminal locale not supported” turned up a forum link which described a problem with locale. My friend typed in locale -a, as suggested in that thread, and saw his user password appear on many of the output lines – also alarming!

So far as we could tell, locale gets its information from environment variables like LC_TIME and LANG. Where were these being set? At this point, it seemed most likely that some environment variables might have been set incorrectly in some bash script. A quick search of my friend’s home directory (we grepped for the password in all files) turned up the culprit – the corrupt setting was in the .dmrc file. My friend had not knowingly changed this file. Somehow, though, it had been edited so that Language was set to his user password.

He edited the file to switch the Language line back to its correct setting, like this:

[Desktop]
Session=gnome
Language=us_EN.utf8

After a reboot of the system just to be extra safe, he was now able to open a terminal using term again.

I hope this helps anyone who might have a similar problem. I found a forum post from someone who appeared to have the exact same problem in linux mint, but the thread was locked, otherwise I would have posted the solution there.