Sambal

I really like my idea of what philosophy is supposed to be. Unfortunately this doesn’t seem to align with what philosophy is to other people. Notably, I took two philosophy courses in undergrad and earned a D in the first and a D+ in the second.

But now I’m taking a sabbatical, and I am going to use my sabbatical to read, write, think, and discuss philosophy, and maybe figure out what feels discordant between my idea of philosophy vs. the general meaning.

To kick this off, I decided to read Philosophy: A Very Short Introduction, to get an overview of the topic.

But my friend recently reminded me of the existence of Gell-Mann Amnesia, so before I read that book, I first read Chemistry: A Very Short Introduction. That book, by Peter Atkins, turned out to be very good — I highly recommend it, if anyone wants a very short introduction to one of my favourite things.

So now, I am partway through the Philosophy book, and enjoying it quite a bit; enough to expand what I think my idea of philosophy is, and how it separates from modern academic philosophy.

I was thinking some more about the new game “Shadow of Mordor” (read the review by Carolyn Petit here). I can’t really add anything to her review — she makes it sound like the plot of God of War was transplanted into an Assassin’s Creed game set among some of Tolkien’s ideas — not truly in the Tolkien universe.

I wanted to criticize Christopher Tolkien and the literary estate for allowing this to happen, but then I read this article about the Tolkien Estate’s battles with Warner over digital content, and I saw that the Estate had accepted a percentage of the net film proceeds — which is incredible to me. Everybody knows that films don’t make money on net, and if you want to get paid you need a piece of the gross. This is not news.

So I started thinking about CT’s age; he sounds pretty sharp in the interview, but the guy was born in 1924, and he licensed the films in something like 2004, so he was 80 then and he’s 90 now. So I’m now I’m just feeling down about the whole thing.

I bet when CT dies, Warner will execute their option to dig up the remains of JRR Tolkien, hang him, and then burn him, like the royalists did with Oliver Cromwell.

I have an old stable internal server that’s running CentOS 5.10 which I want to use a staging/development server for modern node.js applications.

The problem is, current prebuilt versions of node.js can’t be installed on CentOS5, since CentOS5 has GNU libc 2.5 and the prebuilt node.js RPMs are only for Fedora/RedHat/CentOS 6, and are linked against libc 2.7.

Fortunately you can still build from source, as follows:

Install Python 2.7 on CentOS5

Node requires Python 2.6 or 2.7 to build; CentOS 5 comes with Python 2.4, and we need to keep that because yum depends on it.
So we first install Python 2.7 as an alternate version of Python:

$ cd ~/code
$ wget https://www.python.org/ftp/python/2.7.6/Python-2.7.6.tgz
$ tar xzf Python-2.7.6.tar.gz
$ cd Python-2.7.6
$ ./configure; make -j
$ sudo make altinstall

It’s very important to do make altinstall and not a regular install, because yum depends on Python 2.4. make altinstall will install Python 2.7 as /usr/local/bin/python2.7

Check out latest stable node source

$ cd ~/github
$ git clone git://github.com/joyent/node.git
$ cd node
$ git checkout 0.10.28
$ PYTHON=python2.7 $PYTHON configure
$ make
$ make test

I had a few failing tests. The very first test fails, and takes many seconds to timeout. This is test-abort-fatal-error.js, which seems to be testing the system’s ability to apply resource limits via ulimit. Another test that fails, near the end, is tls-test-server-verify. This sounds ominous, but since I am not planning to use this server in production, I decided to continue.

$ sudo make install

Test node and npm

$ node --version
v0.10.28
$ node
> console.log('Hello, world');
Hello, world
undefined
> ^D

Then create a directory to test npm

$ mkdir test && cd test
$ npm i --save mocha
$ PYTHON=python2.7 npm i --save inchi

Note the explicit setting of the PYTHON environment variable. When installing an npm module that requires compilation (that executes node-gyp), npm will return an error if it runs with the default system python (2.4), since node-gyp requires at least python 2.7. If you install a lot of compiled packages, or it’s painful to remember to set the environment variable PYTHON every time, you can add export PYTHON=python2.7 to your ~/.bash_profile. It doesn’t seem to bother yum.

Inchi, by the way, is an international chemical identifier; specifically, the npm inchi package is javascript interface to the InChI Trust’s C library for converting between structures and InChI codes. Here I’m using it as an example of an npm module that requires compilation and linking to work.

I also noticed that when node-gyp was building

Known Limitations

There are several limitations to this approach.

1. Test failures making this node 0.10 unsuitable for production

   The ulimit, tls, and flooding tests failed. I would not use this node on a production server that is exposed to DOS attacks.

2. No support for nvm

   On my production server I use nvm to manage the version of node I’m using. Since nvm downloads prebuilt binaries which link against glibc 2.7, this doesn’t work on CentOS 5

3. Must rebuild node to get bugfixes / new versions

   Just like in the 1990s, in order to get the next stable version of node, you need to pull the sources and rebuild. This is much easier now, and can even be automated, but it’s a substantial effort that only makes sense if you have no better alternative.

If I can get the tests to build cleanly, I’d be willing to package this up as an RPM for anyone who’s interested.

EDIT: Here’s another approach, written for node 0.8, but will probably work with 0.10. Note that they use EPEL to find and download an RPM for Python 2.6, and a symbolic link from ~/bin/python to /usr/local/bin/python2.6.

I’m starting a week-long work block today — that is, I’m planning to work from 5AM to 5PM straight every day, like a “normal person”. Danielle has graciously consented to spend one week of her vacation doing everything else that needs to get done.

Since last week we had a “stay-cation” where we went out to all the Edmonton sights and attractions and ate out at fancy restaurants, I have dubbed this my “work-cation” – which is not pronounced “work cat ion”, for the chemists out there. That would just be anion– err, annoying.

Here’s my day 1 setup:

]1 I moved the mac into the guest room for my workcation. That’s ~1L of coffee on the right there, in my homemade skull mug and Contigo travel mug.

And here are the materials I brought along:

]2 Notes, books, flashcards, papers for my 2014 March work-cation.

I was chatting with someone on #node.js who wanted his script to pass a command-line option to node, so that his script was run in a particular node environment. The problem is that under linux you get to pass exactly one argument on the shebang (#!) line. If you use #!/usr/bin/env node, you’ve already used your one argument. When I suggested he use the “-x” hack, we discovered that node didn’t have this hack. So I made a pull request complete with a TL;DR justification for why -x is necessary.

Turns out there’s a tidier hack that doesn’t require any changes to node, which relies on the interaction between bash and node.  Here’s an example, lifted from pm2 and lightly modified for clarity:

#!/bin/sh 
":" //# comment; exec /usr/bin/env node --noharmony "$0" "$@"

console.log('javascript');

Here’s how it works:

1. The #!/bin/sh causes the script to be identified as a shell script, and passed to /bin/sh for execution. /bin/sh reads and executes scripts one line at a time, and we’re taking advantage of that below.

2. The second line, as interpreted by the shell, consists of two commands.

   2a. The first command is ":", which is the quoted version of the rarely-used bash command :, which means “expand arguments and no-op”. The only argument to : is //, which is a valid path. The following # is a bash comment, which is valid until the command separator ;.

   2b. The second command is exec /usr/bin/env node --noharmony "$0" "$@" which executes the node interpreter with the desired arguments and passes argument 0 (this script file) and the rest of the arguments to the bash script ("$@")

3. The exec causes the bash process to be replaced by the node process, so bash does not attempt to process any further lines.

Now we’re running under node, with the desired command line arguments set. Unlike bash, node wants to read and parse the whole file. So let’s see what node sees:

1. The #!/bin/sh line is ignored due to a special one-off in node – when loading a module, the contents of the first line will be ignored from #! up to the first \n.
2. The second line contains a string constant, the quoted string ":", followed by a Javascript comment introduced with //. Automatic semicolon insertion happens so the constant is interpreted as a string in a statement context. Then the comment is parsed, and everything up to the end of the line is ignored by node.

This won’t lint clean. jslint and jshint both complain:

$ jslint test
test:2:1: Expected an assignment or function call and instead saw an expression.
test:2:4: Expected ';' and instead saw 'console'.
$ jshint test
test: line 2, col 1, Missing semicolon.

1 error

But it works right now, as a hack-around for the Linux one-argument shebang problem.

Note that there’s a spot in the line where you can insert a comment (as long as it doesn’t contain anything that bash interprets, notably ;). What to put there? I recommend a link to a web page (such as the one you’re reading now, https://sambal.org/?p=1014) that explains WTF this weird-looking line is all about. For example:

#!/bin/sh 
":" //# https://sambal.org/?p=1014 ; exec /usr/bin/env node --noharmony "$0" "$@"

console.log('javascript');

Happy hacking!