With the new play.google.com domain, my Netmask Calculator has a new home on the more general web, at https://play.google.com/store/apps/details?id=com.sgpit.netmaskcalculator.
It's free, uses no special features (it can't touch your contacts, SMS, internet, etc - why would it need to?) and just does what it says on the tin. It calculates netmasks
The BBC have posted an article entitled Go figure: Does efficiency always save money?. The article makes few direct claims, but it does say that we are spending 63% more on IT now than in 1997. We are getting much more than 63% more use out of our IT than we did 15 years ago, too, so the fact that we spend more is not really the relevant factor.
I have taken figures from the graph on the BBC website; I might not have it quite right, but they suggest that we spent around £3,800 million in 1997, and £6,200 million in 2010. (I've gone out to 2011 for convenience, as Moore's law works in 24-month chunks). That is a higher spend, but we're spending more on it because we're getting more out of it.
If you had a £1 lottery ticket guaranteed to pay out £1.05 for every £1 you put in, from an initial budget of £1.00, after 20 weeks you'd be able to spend £2 and buy two tickets. Of course you would - you'd be making a 10% profit each week instead of a 5% profit. 10 weeks later, you'd be able to buy 3 tickets a week, for a 15% profit.
Moore's Law is even better than that. The BBC article claims that Moore's Law claims "Every two years you can buy twice the processing power for half the price." Actually, it's that you can buy twice the power for the same price. But it's still pretty good.
If we liked our £2,000 PC in 1997, with Windows 3.1 and MS Office 4.3, we really like our laptop, netbook, phone and maybe even a tablet now; the least powerful of these cost a fraction of that 1997 PC, and is far more powerful, and makes us far more efficient.
That is why we are spending more on technology - the more of it we have (up to a certain limit, I'm sure), the more effective we are.
From the figures above, even if our spending stayed at 1997 levels, we'd have IT power 12 times more than we had then. By spending more on increasingly efficient technology, we've actually got 77 times more power than we did 15 years ago.
So - just because we're spending more on something does not mean that it is less efficient than it appears. Rather the opposite - the more useful something is, the more likely we are to keep on using more of it.
People often comment on the speed (if not accuracy!) of my typing. http://keybr.com/ is a typing tutor of sorts which has a reasonably easy interface, and shows your effective WPM.
The Technical University of Dresden has a Java applet modelling various types of traffic flow at http://vwisb7.vkw.tu-dresden.de/~treiber/MicroApplet/. Fascinating to someone who spends 20+ hours a week on motorways; boring to someone who drives 2 hours a week on minor roads. As someone who spends 8-10 hours a week on motorways, I find this an interesting and educational toy.
It's interesting to play with the different scenarios; for example, http://vwisb7.vkw.tu-dresden.de/~treiber/MicroApplet/OnRamp.html tells us that "At 1600 veh./h, no breakdown occurs, but an existing jam will not dissolve" - so once there is a jam, you need to reduce the number of vehicles entering the affected system. I'm not aware of any measures (other than Radio and SatNav telling drivers to avoid the area) trying to control this.
Like Willem van Schaik did back in 2006, I too have just been fighting with w3c-libwww. It has a configure script which creates (amongst other things) a libtool shell script.
This is a particularly badly structured shell script; it has statements like this:
if test $pic_mode = no && test "$deplibs_check_method" != pass_all
Which is fine, if the
pic_modevariable gets set. However (on my Solaris 10 SPARC system at least) it does not get set, so the script falls over with cryptic statements like
../../../libtool: test: argument expected
The code above expands to
if test = no && ....which is invalid syntax. If there's a possibility that a variable could expand to the empty string (or be unset), quotes around the variable name are required (as
libtooldid for the
deplibs_check_methodvariable in the same line!)
In my particular case, defining the following variables in my shell allowed the compilation to complete:
Your PATH requirements may vary; I had to add /usr/ccs/bin because
configurenever checked that I had a valid
arin the PATH.
If you include an
eval `ssh-agent` in an X session startup, in your
~/.profile, or just run it interactively when logged in to a server, you could end up with quite a few unused
ssh-agent processes over time, because your shell disowns them and they are reparented by the
init process. This does no real harm, but it can make the
ps output messier than it needs to be.
Adding this to
~/.bash_logout would kill off your no-longer-needed
SSHPID=`pgrep -x -u $UID ssh-agent | grep $SSH_AGENT_PID`
[ ! -z "$SSHPID" ] && pkill -9 $SSH_PID
I think that this should also be secure;
$UIDis read-only, and if somebody tricks you into setting
$SSH_AGENT_PIDto something malicious (
"1234;rm -rf ~"perhaps), the
pgrepcommand will only output integer PIDs of
ssh-agentprocesses owned by yourself.
pgrep ssh-agent| grep "1234;rm -rf ~"will simply fail to match the pattern and output an empty string.
It is a shame that
testdoes not have simple test to check whether or not a variable is purely numeric. There is a workaround at http://steve-parker.org/sh/test.shtml (look for "Sorry, wanted a number"), so a simpler alternative to the above would be:
echo $SSH_AGENT_PID | grep "[^0-9]" > /dev/null || kill -9 $SSH_AGENT_PID