Monday, 26 September 2011

Returning to Windows: Part I

This series will run through how I've moved from being a full-time Linux desktop user to using Windows full-time. First up, a little about me.

I've been in the IT industry professionally for about 15 years, but I've always had something to do with computers. I started at around 7 learning BASIC and writing a few programs on my Sony Hit-Bit MSX.

(MSX is a whole other topic for another post, so I won't go into detail here.) 

After that I worked in Technical Support for a UK computer manufacturer before moving into R&D and finally into Linux system administration. During my time in R&D I had a lot to do with Microsoft and Windows in particular, developing PC builds and configurations around Windows from ME to Media Centre. I got to know them very well and didn't like the way either Microsoft, or Windows, worked.

So I changed my home desktop computers to Linux. Mandrake Linux at first as it was extremely user-friendly and attractive. It may look a little dated now, but against Windows 98 it was amazing.


I then moved onto Ubuntu as of Breezy Badger (5.10, released April 2005) and continued to make my protest against the Microsoft wheel corruption racket that I'd experienced when dealing with them.

So fast forward until now. Ubuntu was fantastic at the start, it promised so much, but as of Natty Narwhal (11.04) it's delivered so little. When I first started I always needed a decent video editor for my family videos. KDEnlive, Cinellera and later PiTiVi were video editors which were always halfway there, threatening to become the all-purpose easy editing suite that Windows Movie Maker had become. But 5 years later, it hasn't happened for one reason or another. A few weeks ago I simply couldn't hold out any longer, I installed Windows 7 on my main computer, stopped being a martyr and took the easy life again. My experiences since then have been mixed, but now I'm in the position where I can provide the fairly rare insight of an experienced Linux user discovering the pitfalls of being a newbie Windows user. In all honesty, I know what to expect, it's not that different to where I left it, but I still have a fresh view on most of it.

The next part of this series will be how the installation differed to what I'm used to. How easy is Windows 7 to set up and get ready to use compared to Ubuntu?

Monday, 1 August 2011

On the Origin of Cars and Human Beings

From my moderately recent uptake of running to attempt a Marathon in October it's struck me just how incredibly close the mechanics of motor vehicle engines are to the mechanics of Humans. A Heart Surgeon recently described to me that opening up the chest cavity and looking inside as "it's just mechanics". That got me thinking about just how right he is. Perhaps it's no accident that the two are so close in the way they work either; we've now had just over 100 years' of enhancement and refinement of car engines, so the natural process should follow the best formula for working with physics, proving that evolution is the ultimately the best judge. I'll try and explain how I think the two things match each other, and how they differ. By comparing them we can actually have a good guess about how cars will 'evolve' in the future, by looking at how the Human Body is better than an internal combustion engine.

Combustion
When exercising, you draw air into your lungs to react with food in your stomach, to be carried around the blood stream to your muscles. To help this process work, you need water. Without water you effectively dry up and grind to a halt. It's very easy to perceive this happening when you're dehydrating while exercising; you feel muscles tighten, your blood thickens and saliva turns very thick. This is very similar to how an engine will draw air in to the combustion chambers (lungs), combine the air with fuel (food) and use the chemical reaction to create energy. Also very similar is how lubrication is required. The engine requires oil to lubricate the workings otherwise it will dry up in the same way as your muscles and joints will dry up without water.

So the way the car engine produces energy is very similar to how we produce energy. What else is similar?

Tuning
When trying to get more performance out of your engine, it's a simple principle. More air and fuel in equals more energy generated. It's also remarkably similar with the human body. You exercise to increase your aerobic and anaerobic threshold by increasing the size of the energy pathways to your muscles. You exercise to make your heart and lungs more efficient to be able to make better use of the oxygen you can draw in and more efficient at using the energy. This is the equivalent of boring out your engine by making the cylinders bigger and holding more air, and increasing your engine's volumetric efficiency by allowing as much air to be drawn in on every stroke (breath) as possible by porting, polishing and general head work.
You can increase the fuel pump size, the fuel line size, the fuel regulator and the injectors / carburettor. This is the same principle as the size of your veins increasing to allow more fuel for your muscles to be carried. Most tuners will be familiar with the term 'Italian Tune-up' where giving an engine a blast will remove old deposits and scale and effectively allow your engine to perform better. The exact same thing happens with your body.

The Future
I firmly believe that any advances in the technology of the internal combustion engine have so closely imitated the mechanics of the human body that it's a fairly easy conclusion to come to that future advances will go down the same route. Where can we expect to see engine technology go next, if it does mimic human biology?

Well, the body's ability to self-heal and adapt to load is a great advantage. It makes it able to last, literally, a lifetime. As you ask your body to do more and more demanding things, your physique and attributes change to allow greater abilities at these tasks. Some modern cars have the ability to change the air and fuelling pattern depending on how it learns your driving style, so we can see some of that already. Even some technologies such as variable valve timing are also evidence that this is starting to happen, so I think we'll see engines able to adapt better to different driving conditions, demands and styles in future. We may also see more advancements in the way that engines are able to heal themselves by making use of modern materials.

It's no surprise that engines and the human body closely model each other, as both are intended to do the same thing; convert chemical energy into kinetic energy and deal with any associated wear and tear in the course of things. The human body has had quite a head start, but we're pushing transportation devices forward faster than evolution could manage, to the point where we could very well merge.

Can you see this trend continuing? Where will it go?

Wednesday, 9 February 2011

Making BASH Scripts HA Compatible - Daemonising BASH

Quite a few times on our clusters we've needed to make a cron job, or a shell script HA compatible. We'd like the cluster to be able to start and stop it, so it can failover with other resources if required.


It's actually a lot easier than it seems. The easiest way is making a while true loop with a sleep in the middle, then in each iteration check the current time against the run time of the script. It's kind of replacing cron, but needs must.


This is how I did it.

Stage 1 - Make a standard LSB compatible init script carcass


#!/bin/sh                                                
# description: Start or stop your res name
#                                                        
### BEGIN INIT INFO                                      
# Provides: your_res_name                     
# Required-Start: $network $syslog                       
# Required-Stop: $network                                
# Default-Start: 3                                       
# Default-Stop: 0                                        
# Description: Start or stop your res name      
### END INIT INFO    

RUNFILE="/var/run/your_res_name"


NAME="YourResName"
case "$1" in
'start')
        CHECKSTATUS
        [ "$RUNNING" ] && echo "$0 is already running" && exit 0
        echo $"Starting $0"
        touch $RUNFILE
        MAINLOOP &
        ;;
'stop')
        [ -f "$RUNFILE" ] && rm $RUNFILE
        pkill -f "$NAME "
        echo "$NAME"
        ;;
'restart')
        $0 stop
        sleep 5
        $0 start
        ;;
'status')
        CHECKSTATUS
        [ "$RUNNING" ] && echo "$NAME is running" && exit 0 || echo "$NAME is stopped" && exit 3;;
*)
        echo
        echo $"Usage: $0 {start|stop}"
        echo
        exit 1;;
esac

There's no CHECKSTATUS or MAINLOOP functions yet, we need to add those next.

MAINLOOP


You need a while true ; do ; done loop to sit there running through the stuff you want to check and then to do stuff at the appropriate times.


RUNTIME="000300" # 00:30:00
MAINLOOP() {


LOG="/var/log/$NAME.log"


while true
do
# Check for permission to run.
[ ! -f "$RUNFILE" ] && exit 0


# Check if we've already run today
if [ ! -f "$OUTPUTFILE" ]
then
# Or if we're still running
NUMPROCS=`pgrep -f "$NAME " | wc -l`
                if [ $NUMPROCS -lt 1 ]
                then
THETIME=`date +%H%M%S` # Get a numerically comparable time. 
if [ $THETIME -gt $RUNTIME ]
then
echo -e "\nApparently $THETIME is greater than $RUNTIME so it's time to do our thang" >> $LOG
echo -e "------------------------" >> $LOG
echo -e "\n*** Starting process.***\nThe time : $THETIME" >> $LOG
echo -e "\nNumber of existing processes : $NUMPROCS" >> $LOG
echo -e "\nLet's GO!\n" >> $LOG
RUN_OUTPUT
fi
fi
fi
sleep 1m
done
}


CHECKSTATUS


You can just use something simple like check for the run file and the background process running on this



CHECKSTATUS () {


if [ -f "$RUNFILE" ]
then
if [ `pgrep -f "mi_data_extract start" | wc -l` -gt 0 ]
then
RUNNING="yes"
else
unset $RUNNING
fi
fi


}


That's pretty much it. Check each operation of the init script with echoing out the return code from every state. e.g.


/etc/init.d/your_res start ; echo $? # from stopped, should be 0
/etc/init.d/your_res start ; echo $? # from started, should be 0
/etc/init.d/your_res stop ; echo $? # from started, should be 0
/etc/init.d/your_res stop ; echo $? # from stopped, should be 0
/etc/init.d/your_res status ; echo $? # from started, should be 0
/etc/init.d/your_res status ; echo $? # from stopped, should be 3


Once this is done, you can just add it to the cluster as a primitive LSB resource, add a monitor on it and let the cluster take care of your script.