Preventing VAIO Care recovery on boot

I bought a Sony VAIO Y Series laptop for my wife last Valentine’s Day — how practical, I KNOW — and it’s been working great thus far, except for one niggling thing.

It boots into a recovery mode called VAIO Care every time. This mars the user experience siince the intention is always Windows 7, not VAIO Care!

I’ve copy-pasted the text wholesale, in case the site goes down one day (and mine doesn’t):

  1. Click the Start button and then click All Programs.
  2. In the All Programs menu, click the Accessories folder and then click the System Tools folder.
  3. In the System Tools folder, click Task Scheduler.
  4. In the Task Scheduler window, in the left pane, click Task Scheduler Library.
  5. In the middle pane, click VAIO Care.
  6. In the right pane, under Actions , click Disable.
  7. Close the Task Scheduler window.



Copying your ssh key

Since I’m frequently trying out new OSes courtesy of VirtualBox, my ssh key changes a fair bit. So I keep forgetting the xclip command, and I got tired of Google-ing “git xclip” so I’ve decided to repost snippets of this article here:

$ sudo apt-get install xclip
$ xclip -sel clip < ~/.ssh/

Now use Ctrl+V to paste the (secret) key into your Git hosting provider; e.g. the very excellent Github.

#debian-linux, #git

*updated* Take care when using CakePHP Model->id, Model->del(), Model->find()

Fixed a bug recently in our code base that had happened intermittently enough for me to ignore until recently, when the problem occurred twice in a week. There was this habit of using the ‘id’ attribute of the corresponding model; e.g.

$options = array(); // method params
$this->Foo->id = 'bar';

Now this is a fairly handy syntax, but unexpected results are produced when used in conjunction with find() and del(); e.g.

$options = array('contain' => array());
$this->Foo->id = 'bar';
$this->Foo->find('first', $options)); // BUG: not equivalent to setting the conditions key of $options to array('' => 'bar'). SQL is NOT "select * from foo where id='bar';"

The above find() returns the first (cached?) row is returned, which is incorrect of course.

Now for del():

$this->Foo->id = 'bar';
$this->Foo->del(); // BUG: not equivalent to $this->Foo->del('bar'). SQL is NOT "delete from foo where id='bar';"

Unfortunately, results will vary, depending on the database engine. I suspect that sometimes the first cached(?) row — without any WHERE clause — is returned, and it happens to be ‘bar’, hence delete works correctly. For your reference, we use Oracle 11g Release 2.