Today, we landed a probe about the size of a washing machine on the surface of a comet about the size of the main populated bit of Derby, 500 million km. away. At that distance, the radio signals carrying instructions up and pictures down take 28 minutes each way.
That's pretty freaking awesome.
If you scale the distances down to something more manageable, it's like the equivalent of standing in London and firing a gun and hitting a moving target, 1/20 of the width of a human hair, in Paris.
Meanwhile, some kid watching the news on the TV or Internet is going to be fired up by the sheer freaking awesomeness of it all, and decide right there and then that they want to be a scientist when they grow up because science is so freaking awesome. Hopefully lots of kids. And they'll go to university and get their MScs and their PhDs and end up doing something that will be so even more freaking awesome that it will make landing Philae on P67 look about as impressive as reversing a car into a garage.
This must be the way people were feeling on the day the first human stepped on the Moon, two years and eight days before Yours Truly was born.
(And the real experiment, drilling into the comet and analysing whatever is found in there, hasn't even started yet .....)
Wednesday, 12 November 2014
Tuesday, 2 September 2014
The simple fact is, that manufacturers have been ripping you off.
Let me explain.
A vacuum cleaner turns electricity from the mains into kinetic energy which it imparts to the stream of moving air (which is what you want it to do). It also turns electricity into heat (which you don't want it to do) and sound (which you can't avoid, but it isn't much anyway; a screaming toddler is producing about a watt of sound energy. Yes, loudspeakers really are that inefficient).
You can measure how fast KE is being imparted to the air stream by multiplying the volume flow rate by the pressure change. Assuming you use the fundamental units throughout, you get metres cubed per second, times Newtons per metre squared = Newtons-metres per second = Joules per second = Watts. That figure is all the dirt in your carpet cares about. The difference between air-watts and electrical watts is what is getting wasted.
From the vacuum cleaner manufacturer's point of view, since you already have a moving air stream, you can use this for cooling the motor; so overheating really isn't a huge deal. You can therefore make your motor inefficient -- using copper wire that is too thin, and/or not enough steel to leave any molecules un-magnetised right through the crests and troughs of each cycle of the mains -- so it turns some electricity into heat that otherwise would have been turned into KE. Also from the vacuum cleaner manufacturer's point of view, a bigger number on the advertisement attracts more buyers. So it's actually in the manufacturers' interest to make vacuum cleaners as inefficient as possible, just so as to be able to claim big numbers!
And people have fallen for this hook, line and sinker. I despair.
(My proposed solution would be to require standardised testing of vacuum cleaners, including ability to extract different types of dirt from different surfaces, percentage efficiency as air-watts / electrical watts and expected lifetime of product. Of course this will make additional work for the manufacturers; but we consumers outnumber them, and the law is supposed to work for us .....)
Thursday, 24 July 2014
Anyway. The scenario is this. We have several clients running KDE, and using an NFS share for their home folder. By default, Akonadi wants to run its own MySQL server, as the individual user, with data in the user's home folder. Which means that every time a record needs to be modified, we have to lock a file (to make sure only one process is going to modify it at once); alter it; and then unlock it. This is creating a lot of network traffic, as compared to just sending a query over the network, and it also has potential problems if the timing of all these messages gets messed up.
So the logical conclusion is, we need to have a central MySQL server for every user's Akonadi data, so the traffic is just queries and responses and we aren't relying on locking files on a remote server. (If you read the first part of this story, you'll remember that this particular use case is actually violating assumption #3; this is a more complicated case than a simple home user, and there is someone in charge who ought to know better.)
Saturday, 14 June 2014
1. Database servers are usually configured with their own local disk drives, so they can get the maximum throughput supported by the motherboard, rather than storing data on a remotely-mounted network share. Acquiring and releasing file locks, which is something that databases have to do a lot, is also faster and more reliable using local hardware to which the kernel is talking directly, rather than by sending requests and acknowledgements across the network where it contributes to the overhead.
2. You don't always want to have to think about file formats in too much depth. Sometimes, what you have to store lends itself naturally to a database. Someone else has already done the hard work, implementing the storage engine. All you need to concentrate on is getting the data in and out of the application.
(Database servers also tend to be surprisingly light on resources; because traditionally, they have had no alternative but to have been.)
Using a ready-made database server to store your data can make better sense than devising your own ad-hoc file format that may limit you in future in ways that, by defnition, you haven't thought of.
3. Desktop users shouldn't need to be intimately familiar with the under-bonnet workings of a database merely in order to use their computers. If a database server is used by an application, its configuration should be managed by the application itself. This is especially so if the application makes use of esoteric configuration options.
Starting a specific instance of the database server, just for that one user, with a configuration decided by the application and so specifically suited to it, can make better sense than trying to use an existing system-wide server. (You don't have to be root to run a server, if you listen on a non-privileged port and take care not to write anywhere you aren't allowed.)
4. A network with multiple users running a limited range of desktop applications (mainly a web browser and an e-mail client) would be really, really great if it had the ability for any user to log in at any workstation and have their own home folder. You can rotate more staff than you have workstations, through any combination of shifts; and know that, as long as there are enough workstations for every team member, everyone will be able to access their own home folder.
So, it makes sense in such a situation to use NIS to handle user logins, and mount /home on an NFS share.
Four eminently sensible decisions, taken in isolation. But put them all together and what you get is, multiple databases in users' home folders on the same NFS share.
This only became apparent when I upgraded a bunch of desktops to Debian Wheezy. (I'd resisted Squeeze for long enough already, because of the move to KDE4. KDE3 was good enough for most of what we needed – it's just that awkward "most of" that's the problem.)
Now, Wheezy uses KDE4, as did Squeeze. KDE4 includes Akonadi, which uses a MySQL database to store data. And it starts an instance per user, configured especially to use a data store under that user's home folder. The newer applications in Wheezy make heavier use of Akonadi's database functionality.
But Wheezy also has MySQL 5.5, whose default database engine is InnoDB – as opposed to Squeeze's 5.1 using MyISAM by default.
And this is where the trouble begins; because InnoDB tables don't play nicely over network shares. NFS is too busy locking and unlocking files to serve much data; and very occasionally, messages get out-of-order and a lock or unlock is missed, resulting in slowdown waiting for the lock to timeout or – worse – data corruption if a write occurred while a file was supposed to have been locked.
So when four or five users on the same network share all try to start up their Akonadi servers at exactly the same time, the result is a packet jam not quite of VoIP-degrading proportions, but certainly getting on for it. All because of an unfortunate concatenation of otherwise seemingly-innocuous circumstances.
Fortunately, there is a happy ending. I'll explain all in the next post .....
Wednesday, 26 March 2014
Today is the anniversary of the installation of solar panels at Montoya Mansions!
In my first year, I have generated 1636 kWh. This is comfortably more than the predicted 1400 kWh for my first year's production, and alters the payback threshhold in my favour: if the price of electricity exceeds , my solar setup has cost less than the electricity it will generate over 25 years (accounting for deterioration).
The timing of my feed-in tariff payments has fallen nicely, such that each payment is due almost exactly halfway between an equinox and a solstice; thus, they correspond to the seasons as counted by duration of daylight. My first payment was £117.75 on 3 August; then £73.88 on 3 November. The sun could barely be bothered to rise in Winter, leading to a dire £29.12 on 3 February (although it still more than covered the £1.82 per week standing charge). Come 3 May, I expect to receive another £70 or 80 for the Spring (this payment and the Autumn one should be fairly similar, by symmetry: the graph of day length vs. day of the year is sinusoidal).
When I get my storage batteries and UPS plumbed in, I should be able to save even more, as I won't need to pay for all the electricity I will be using in the evening .....
Sunday, 16 March 2014
The Independent on Sunday have announced a new policy of refusing to review children's books which are aimed only at boys, or only at girls:
Which is A Good Thing. We don't need any more glittery pink books telling girls they should aspire to be princesses or fashion models; nor trashy, dumbed-down books for boys that ultimately only reinforce the idea that reading is for girls.Thanks to Let Toys Be Toys for breaking this news.
Sunday, 16 February 2014
Now I have managed to pick up some batteries. Although they are not the right ones for this UPS, they are "just about" compatible – the right voltage, but the wrong capacity (there would normally be two series chains of four 12 V, 5.5 Ah batteries, in parallel for 48 V / 11 Ah; I have just one series chain of four 12 V, 7 Ah batteries, for 48 V / 7 Ah).
These batteries are rather used, and have a remaining usable capacity somewhat lower than advertised – but they cost nothing, which is always a point in favour.
And of course, having some batteries, we can test out the UPS!
"C20" plug for the UPS output (which can be up to 3000 VA, which is more than the usual "C14" / kettle-type can handle.) The other end goes to .....
I was worried that the microwave would pull down the battery voltage far enough to trip the undervoltage cut-out in the UPS –this was what happened with a 2 kW kettle. Fortunately, the slow-start action of the magnetron filament heating up was enough to allow the UPS batteries to recover.
This is a good sign. And the nice people at http://www.tayna.co.uk/ are very helpful. They certainly know their batteries.