/usr/bin/env: node: No such file or directory

The Problem

You have installed npm or nodejs and the second you go to use it you receive an error message:

/usr/bin/env: node: No such file or directory

The Cause

Package managers. *sigh* What is normally named node is named nodejs.

$ which nodejs
/usr/bin/nodejs

The Solution

[ -d ~/bin ] || mkdir ~/bin
ln -s $(which nodejs) ~/bin/node
This will allow your system to find node.

There must be some reason behind the package maintainers renaming node to nodejs, probably to avoid a conflict, so you don't really want to be renaming files, or making the changes system-wide (/usr/local/bin) unless you know what you are doing.

$ node --help
Usage: node [options] [ -e script | script.js ] [arguments]
node debug script.js [arguments]

Options:
-v, --version print node's version
-e, --eval script evaluate script
-p, --print evaluate script and print result
-i, --interactive always enter the REPL even if stdin
does not appear to be a terminal
--no-deprecation silence deprecation warnings
--trace-deprecation show stack traces on deprecations
--v8-options print v8 command line options
--max-stack-size=val set max v8 stack size (bytes)

Environment variables:
NODE_PATH ':'-separated list of directories
prefixed to the module search path.
NODE_MODULE_CONTEXTS Set to 1 to load modules in their own
global contexts.
NODE_DISABLE_COLORS Set to 1 to disable colors in the REPL

Documentation can be found at http://nodejs.org/

Great stuff!

References:
https://github.com/nodejs/node-v0.x-archive/issues/3911#issuecomment-8956154

Throttling CPU usage with Linux cgroups

There are a number of reasons you may want to throttle rather than limit a process's CPU usage on your system. One very good reason is to keep the CPU temperature down or to simply reduce the amount of energy a certain process uses.

Limiting versus throttling

The term "limit" is nearly always used where throttling is actually required. A good example of why the two are not interchangeable would be the current ISP industry:

Example 1: Sally signs up for super fast broadband (100 Mbps) but hasn't read the small print: she can only download 10 GB of data before her connection is terminated and she has to wait for the next month before she can continue to use her service. Sally's service is not throttled but it is limited.

Example 2: Tony signs up for a basic package (1 Mbps) as he doesn't need to use the Internet a great deal. However he had the good sense to use an unlimited package so that he doesn't hit any usage caps. His router syncs at 100 Mbps but he only receives a 1 Mbps service. The ISPs equipment is throttling his service, but not limiting it.

Example 3: Benedict has signed up for some deal without reading any of the details. He receives a 20 Mbps service and is happy with the speeds. Unfortunately for him after downloading 5 GB of data his download rate drops to 1 Mbps. He has limits on his service which has led to it being throttled.

There are many instances where you may wish to both limit and throttle CPU usage. The former is very easy and well documented, the latter not so much.

Installing Wine on Ubuntu Saucy

This is a very short post because it is very simple, if not immediately obvious.

Symptom:

You are trying to install or build Wine from either the official Ubuntu repositories or from the PPA and are constantly receiving dependency errors.

Cause:

Multiarch is supposedly working on Ubuntu now so you should see everything work! You won't.

Solution:

$ sudo dpkg --add-architecture i386
$ sudo apt-get update
$ sudo install wine

Apt will now pull the FULL dependency list. The same is true for apt-get build-dep.

Resetting the Rhythmbox music database

Months and months and months ago my Rhythmbox decided that it needed to duplicate its database. Every song was repeated. The result being if I put an album on, I got the bloody song played twice.

At the time I searched and searched and searched for a solution, and then I gave up. All I could find was the usual utter bollocks from people who have no idea what they're talking about. Warnings about how removing the music database will leave the whole application in an unusable state. What a load of crap. I gave up because I couldn't be arsed with this chew. Well, it's annoying me again.

Logically: a new user running Rhythmbox doesn't have a music database; it has to be created. Therefore I should be able to remove the database and a new one will be created.

Solution:

 $ mv ~/.local/share/rhythmbox/rhythmdb.xml ~/.local/share/rhythmbox/rhythmdb.xml.old

Easy!!!

Predictably, the new database is half the size of the old one.

Silencing rtkit-daemon in the syslog

If you're running Ubuntu and use applications that call for realtime priority then you have probably noticed your syslog filling up with garbage:

Jan  8 18:26:18 aspire rtkit-daemon[1955]: Supervising 6 threads of 2 processes of 1 users.
Jan  8 18:26:18 aspire rtkit-daemon[1955]: Successfully made thread 31761 of process 31676 (n/a) owned by '1000' RT at priority 2.
Jan  8 18:26:18 aspire rtkit-daemon[1955]: Supervising 6 threads of 2 processes of 1 users.
Jan  8 18:26:18 aspire rtkit-daemon[1955]: Successfully made thread 31761 of process 31676 (n/a) owned by '1000' RT at priority 2.
Jan  8 18:26:18 aspire rtkit-daemon[1955]: Supervising 6 threads of 2 processes of 1 users.
Jan  8 18:26:19 aspire rtkit-daemon[1955]: Successfully made thread 31761 of process 31676 (n/a) owned by '1000' RT at priority 2.

I have, anyway! Thousands of lines obscuring the "interesting" parts of the system log.

Solving this little problem is not immediately obvious and certainly not well documented. It can be solved in three relatively easy steps. You do need root access.

Step 1: Create the configuration file for rsyslog.
Step 2: Reload rsyslogd.
Step 3: Reload rtkit-daemon.

 $ sudo cat > /etc/rsyslog.d/20-rtkit-daemon.conf <<EOF
if \$programname == 'rtkit-daemon' then /var/log/rtkit-daemon.log
& ~
EOF
sudo service rsyslogd restart
sudo rtkitctl -k

Notes:

• Tell rsyslogd to restart, reloading doesn't work.
• rtkitctl -k should kill rtkit-daemon and then allow it to automatically re-spawn. If not you will also need to issue sudo rtkitctl --start.
• See https://bugs.launchpad.net/ubuntu/+source/rtkit/+bug/1267212.
• I used a number before 50-default.conf (i.e. 20-rtkit-daemon.conf) because otherwise the logs are duplicated in both the syslog and rtkit-daemon.log [20 < 50].
• The \$ is needed if you are copying the above exactly into your command shell.

Compiling a Wine WoW64 build on Ubuntu Precise AMD64

If the title of this post doesn't mean anything to you, you should probably stop reading.

I'm going to start by assuming you know what Wine is, and pretty much everything else I talk about throughout the post. This is simply intended to be instructional and not educational.

I noticed that there isn't really a full instruction set in the Wine Wiki for how to build a full WoW64 setup within Ubuntu 12.04 64-bit, so I thought I should try and figure these things out for myself. I don't consider this post suitable to be added to the Wiki as it's a bit of a jumble, but I may look into it later. (Feel free to give a helping hand!) It may take a few glances to realise what is being done and why.

The first steps are:

1. Install all the build requirements on your machine.
2. Install an i386 chroot (I used Precise again). A fakeroot installation failed miserably but you might have more luck.
3. Install all the build requirements in the chroot.

Next, you should build Wine64 outside of the chroot.

The 32/64 build will require access to both 32- and 64-bit libraries. This is why it fails in the first place: Ubuntu have screwed up their multilib. You can copy all the files into their respective folder inside the chroot but this will use up more space, and they won't be updated when needed. Soft links won't work and hard links might create problems when running an update. Bind is your answer.

You will need to create the relevant directories inside your chroot:

(Some directories may already exist and be empty - that's fine).

mkdir /usr/lib/x86_64-linux-gnu

mkdir /lib64

mkdir /lib/x86_64-linux-gnu

mkdir ~/wine64

mkdir ~/wine3264

You then need to bind these directories so that the chroot can see them.

(In some cases it would be prudent to bind a directory read-only, unfortunately that fails and you have to mount -o remount,ro /foo/bar if you feel this necessary).

mount -B ~/wine-git /path/to/chroot/~/wine-git

mount -B /usr/lib/x86_64-linux-gnu /path/to/chroot/usr/lib/x86_64-linux-gnu

mount -B /lib64 /path/to/chroot/lib64

mount -B /lib/x86_64-linux-gnu /path/to/chroot/lib/x86_64-linux-gnu

mount -B ~/wine64 /path/to/chroot/~/wine64

mount -B /path/to/chroot/~/wine3264 ~/wine3264

Where you will need to expand the ~ to point to the correct directories.

The final mount being so that you can access the build from your host environment.

I also mounted /tmp as the /tmp inside the chroot will not be cleared on reboot.

mount -B /tmp /path/to/chroot/tmp

Now you can build the WoW64 Wine.

Inside the chroot:

cd ~/wine3264

~/wine-git/configure --with-wine64=$HOME/wine64

make

Remember to add any other options you wish to add.

Once compiled you can run the whole setup from your host environment from the build tree (which has been bind-mounted), or make install and run that way. I highly recommend that you script as much as you can. If you're planning on rebuilding or running regression tests then you will spend a lot of time typing in the same commands over and over.

Similarly, you should consider ccache and distcc. You should read up on how to share your .ccache, and make sure that the distcc servers have the relevant libs too (you could use sshfs mount to work around any missing dependencies).

Also I have added the above mounts to my /etc/fstab so that I don't have to worry about mounting them all the time.

You should now have a working WoW64 build of Wine.

As I have said, this is a quickly thrown together instructional post, so if you get stuck then feel free to ask for help. I highly recommend using irc://irc.freenode.net/#winehq as the people on there are extremely knowledgeable on the subject. If the problem is a little more involved you should probably use the forums.

References:
1. https://www.winehq.org/pipermail/wine-devel/2009-December/080375.html