Lol @ Dangerous machining

We all know the hazards of DIY. Anyone who’s ever done any sanding knows that a lot of that stuff ends up in your nose. It collects. It really bulks up those bogeys.

But machining metals is another ball game. Metal shards up the nose is one thing for a start.

But in machine shops, you’d be told not to allow the chaff to build up anywhere. You’d be told to keep the floor, work surfaces and machines free of build-ups. This is important when dealing with aluminium and steel. But there’s something they never tell you:

Iron Oxide + Aluminium + Bogeys —–> Thermite bogeys

You have been warned.


Grenfell: Hillsborough v2.0

One thing is worse than tragedy: an avoidable tragedy. Worse still: a cover-up.

What a mess our United Kingdom is in.

Public confidence at an all time low with voters chose their lesser evil. Few believe austerity has been a success. The NHS is at its knees.

And now Grenfell happens. Few believe the death toll being reported. Assumptions rise, remnants of trust crumble.

So many questions. And therein lies the problem. Any catastrophy has more than one cause. How could we let so many accumulate for this to happen? How many more are on the horizon with our infrastructure apparently so critically weak?

Does Grenfell symbolise the UK in its current state? We can’t let it. But that doesn’t warrant a cover-up.


How to understand something backwards: teach!

The process of learning something involves starting with simplest topics and building on them.

When teaching, the process is reversed. You aim to have taught the student up to some advanced topic. But to get to that point, you have to know what the prerequisites are.

But it’s more thoroughly backwards than that implies. In some certificate, such as a mathematics undergraduate degree, each module has prerequisite modules. But so do the smallest of progressions of knowledge. To know how to add three numbers together, you must first know how to add two.

While that seems obvious and insignificant at improving one’s own understanding, consider how many times you have been asked a question about a topic you understand advanced concepts – but have been unable to explain simple questions, like “But why?”

“But why”. You have failed to explain the reasoning – the prerequisites to a conclusion. You have forgotten all about the “why”, because you have for a long time only practiced the “how”, and progressively expanded upon it.

So by teaching,  you are re-learning the “why”. You are literally learning it backwards – for the first time!

So to learn something backwards, teach. Reminding ourselves of the “why” opens doorways to new understandings. It gives us greater confidence, greater certainty, greater agility of mind.

However, we could simply always ask ourselves “why” – and sometimes that’s wise to do – so why teach? Students have the advantage on the mentor. They know when the “why” is an assumption, a prerequisite, unintuitive, or perhaps just wrong.

Trolls are breaking the Stack Exchange system: part 1

If a question is popular and gets a lot of attention, but is on a slightly off-kilter topic, what will happen? Enough users will look at it, misinterpret it and vote to close it. It just takes 5 users over any length of time. But then to get it re-opened, it’s near impossible. It takes 5 users over a short time. Yes, there’s a time limit, but only for reopening. And of course, once a question’s closed, views plummet because the SE system makes it so. So that question is then dead. A valuable question which brings a challenging concept [to some] … is permanently dead.

And what if you delete and start again? You get penalised. You can even get banned. What happens if you ask it a second time? It gets marked as a duplicate.

This is just one way  in which the SE system is broken. And it is trolls that are breaking it.

Rant over. For now.



Turn RaspberryPi-UA-NetInst into a NodeJS server

Rather than reduce Raspbian by uninstalling packages and hacking down services run at boot-up to give a minimal system that runs NodeJS, I thought I’d try starting with a minimal system using RaspberryPi-UA-NetInst and just adding what’s needed.

That link gives an excellent tutorial on getting started. But before you install it, there are tweaks to be made before installing it that will get a lot of stuff set up on installing, rather than afterwards. This is a great bonus because if you ever have to reinstall, you don’t have to reconfigure the system each time. Simply format the SD card, place your modified installer files on the card, put it in the RPi and boot up, cross fingers and it’ll all be installed in under 30 minutes. And it can all be done over WiFi without touching a network cable!

So simple! Just follow Method#1 in this previous tutorial of mine, but replace the contents of with the following:

You might want to tweak the installer to create a user besides root, it seems to be a preferred way of doing things! But I’ll leave that to you. From here you can test out your new NodeJS server, check out this NodeJS tutorial.

This can be taken a few steps further still though! What if you want your entire NodeJS Pi server set up un an unattended fashion, right up to downloading your NodeJS source code from GitHub and running the server? And configuring systemd so it starts up automatically every time? No problem! Tutorial coming soon! 😉


NodeJS web server bits and pieces

Disadvantages of NodeJs:

Avoid asynchronous hell with Node Fibers:

Web framework for NodeJs:

GPIO access with NodeJs:

Customise Raspbian-Ua-NetInst – beyond post-install.txt

Want a bare-bones Raspbian distribution? Start with this one:

  • Raspbian-Ua-NetInst (Smaller installer)
  • RaspberryPi-Ua-NetInst (Firstly, it installs over wifi and gives faster boot time – 10 seconds! but mainly it lets you “Bring your own” files, which we’ll need for method 1 below.)

But what if you want to make a custom installer which comes with more? With either of the above, there are two ways you can do this:

  1. Add package names to installer-configure.txt as per the instructions on those links. Easy!
  2. Add scripts to post-install.txt  to manipulate what’s been installed.

The problem is the former does not give scope for configuration, and the latter is somewhat of a black art. For example, in post-install.txt you cannot simply include commands like this:

Instead you need to do this:

And if you want to manipulate files that will appear on the final installation, God help you. I have had mixed success with this. YMMV!

This brings me to the greatest resource for moving forward:

There are three options it hints at:

  1. Add a script which executes on first login using /root/.bashrc. ,using systemd to log in automatically on first boot to run it.
  2. Use  post-install.txt to install your own custom repository.
  3. Cron: set up a cronjob to run a script on boot-up
  4. Use chef or similar, like this guy did

I will explore them in that order as I find the time, but in the meantime here’s my personal favourite below; in my opinion, the easiest:

Method 1:

This assumes that you’ll be using the Pi’s UART via a USB-serial console, rather than using SSH to log in.

First, get a copy of the raspbian-ua-netinst installer, and follow the instructions, all from here: RaspberryPi-Ua-NetInst.

Everything we need to do will involve adding and changing files they provide that will be going onto your SD card before you put it in your Pi.

They way this method works is first we will configure the installer by making a configuration file in the root of the SD card called installer-config.txt . Put the following in it to make output go to the UART:

Once the installer has done most of the installing, we will tack on a few things for it to do by adding a file at the root of the SD card called post-install.txt . It will run these commands before the installer after it’s done the installing, but before it reboots.

The final feature of the installer that we will use, is it allows us to bundle any files we want onto the SD card, and tell it where it should place them on the final system. We do this by placing them in /config/files/ , and listing them in /config/my-files.txt  as per the instructions.

Putting it all together, we will use these features of the installer to firstly make the system automatically log in once the installer reboots, then to have the system run a script we’ll make once it’s logged in.

We will adapt this tutorial which shows how to make the Pi log in automatically when boot up after installation, using systemd, which we will configure to do so simply by adding a file we’ll call  serial-getty@ttyAMA0.service  into two places within /config/files .

Secondly, when the system is installed and boots and automatically logs-in for the first time, we’ll get the system to run our commands by putting a little something into the .bashrc file in root’s home directory. Here’s how:

In the installer files that you copy on to the SD card, edit /config/my-files.list  and add these lines:

Create this directory structure:

Make two files, both called  serial-getty@ttyAMA0.service , in the following locations:

With the following in each:

Then make a file called  in this location:

With the following contents:

Make another file in /config/files/root,  add.bashrc , with the following:

And make yet another file at /config/files/root called post-install.txt  and put this in it:

And that’s it! Now you have what you need to easily set up your system post-installation without any attention required – it will do the entire thing without any input, just insert the SD card, power-up and wait 20 minutes! Just put your post-installation commands in  .

Lol @ linux

Why is Linux so hard? You have to do a lot of rooting around.

(Sorry… worst joke yet)

Installing Node.JS v4.0 on RPi

As usual, tutorials on Linux become out of date quickly. And as usual, linux tutorials always need fiddling to get working on any setup different to that of the author’s. So here is how I got node v4.0 installed on the RPi version B with Raspbian:

First, from this tutorial:

Then, from this tutorial:

Then edit ~/.bashrc:

Add this line  at the end:

Then edit ~/.profile:

Add this line at the end:


Finally you can get on with actually using it!

But if you want a slimmed-down Raspbian, try my tutorial on getting RaspberryPi-Ua-NetInst working with NodeJs.

This tutorial has a great introduction to using Node.JS. It requires NodeJS v4.0 which you should now have. Plus you now have nvm , the node version manager, which it also requires.


My love-hate relationship with Linux

I have been programming for about 20 years. Within that, about a solid year has been fiddling with Linux. Yet I wonder how much I’ve been able to remember. When ever I try to set something up in Linux, I quickly start swearing like a trooper, and end up Googling things like “I f****ing hate Linux”. Or “Why is Linux so f***ing obscure”. It’s reassuring to know I’m not alone.

But why do I keep going back? Because it has its place. While I think it is unfit as a desktop OS for 99.9% of cases, (stats don’t lie. How many people actually use it for that?) The fact is it is beyond widespread on servers, and frequently used for embedded systems and systems like the Raspberry Pi. If you know what you’re doing, (if you *really* know what you’re doing), you can butcher it, configure it and extend it to your heart’s content. Oh, and it’s free. That’s why I love it.

You just need to read through the comments on this blog post to see plenty of reasons Linux is hated. But I’m going to add a couple. I’m fiddling with an RPi at the moment, so I will have plenty of reminders for what to say on this matter.

The truth is that whenever I try something remotely ambitious in Linux, I end up throwing in the towel. We shall see how this goes.

Have you tried understanding entries in /etc/inittab  ? Even once you know how it works, there’s no denying that the syntax is cryptic compared to how modern programming languages might specify the same configurations. It’s hardly as ubiquitous as JSON.

Why is it so hard to get things working on Linux? The problem is threefold:

  1. Those very comfortable with Linux who write tutorials assume that readers know everything but the tip of the problem, so skip on the details.
  2. Those not comfortable will have spent so much time and tried so many commands to try to get it to work that by the time they write the tutorial they’ve lost track of 95% of the things they had to try first.
  3. Because of the wild permutations of possible distros, versions, configurations and hardware, very rarely are two people’s situations the same.
  4. Combine reason 1 and 3: those in the know can’t, without huge effort, write a tutorial or make a script to, for example, make WiFi work. So many possible combinations, software always changing, it wouldn’t work for long.