I came up with a different answer, based on the summary's wording.

Firstly, the sex of the second child is not determined by the first. Whatever one child is, the other will always be 50% chance of being either.

What we can deduce from the wording is that his other child is not a son born on a tuesday.

We draw a two column, 7 row matrix. The rows are days of the week, and the columns are boy/girl. Write a tick in each cell if that is a valid sex and day for the child. We are left with 14 possibilities. 7 of those are girls (a girl can be born on any day), but only 6 are boys (as according to the wording, only ONE is a son born on tuesday...if the other is a son, it cannot be a tuesday, so we are left with 6 days if it's a boy. We give that probability to the girl column.

Thus we are left with 8 out of 14 chances being a girl, and 6 out of 14 being a boy. In decimal:

Girl: 0.57
Boy: 0.43

QED.

Whilst Android does not have this, since version 2.0 they have vastly improved background process behaviour.

Previous to 2.0, a service (ie background app) could request foreground priority, oblivious to the user. This would flag it as important enough such that it would not be killed when the system needed resources. The intention is things like music players needing to always keep playing the music.

Unfortunately human nature rolled in and every developer felt that _their_ app was the most important one on the system, so had useless crap always running (updates, lots of network polling, etc) and so with many apps installed, the system could become sluggish even if there was only one visible app in the foreground.

Since 2.0, the old system call for this (setForeground()) has been turned into a No-Op, and apps wishing to retain high priority privileges in the background are now forced to display a notification in the status bar. Result? Apps cannot quietly hog system resources, but now must inform the user, which has generally resulted in much less resource hungry apps, snappier performance, and better battery life.

Flying Sydney, Australia to California is similar. There have been numerous times when I departed Sydney after lunch on Saturday, spend 14 hours in a plane, then land at San Francisco in time for breakfast on _the same day_.

Amusing chat over IM with a friend one such day:

Them: How's your Saturday?
Me: Good, had lunch in Sydney then breakfast in San Francisco after that.
Them: wtf???

Does that mean that I could be sued for taking a shit after eating a Malay curry, on the basis that I'm making a "derivative work"?

Aren't hard disk prices always at an all time low? Have they ever gone up in price?

http://android-target.googlecode.com/ should be the correct one.

There are ~3500 android apps out there now, virtually every one of them written assuming HTC Dream hardware.

It will be very interesting to see how they all cope when run on emerging hardware with vastly different characteristics and screens to the opening device.

My own Android game is not exempt and will need better adaptability (yeah, hypocrite).

Already possible, alas you need an unlocked G1 for the tethering:

- Wifi, already there

- Sip: http://code.google.com/p/sipdroid/

- Bluetooth tether: http://code.google.com/p/android-wifi-tether/

Brain: Without it, im dead and wont care.
Hearth: Ditto.
Eyes: Can work around blindness ok.
Ears: Ditto.
Genitalia: Easy to be a nerd without.
Fingers: Cant code without fingers..aaaaah!

You can test and test all you want outside of production, and any respectable shop will have every piece of code thoroughly unit tested and will test "significant" changes against simulated (for changes that load can affect) and limited users.

But, for an environment with huge infrastructure, it becomes literally impossible to test every scenario against real user loads with real user patterns ("random" requests is not real).

When your test scripts get timeouts, they gently retry after $TIMEOUT. People arent like that. Never underestimate the power of $BIGNUM users clicking 'reload' every coupla seconds....

I put debian on my Dev G1. Zero problems.

It's safe - all it does is run a chroot environment from your SD card, thus you are unable to break your existing system (/dev hacks aside). No kernel is booted, it lives off the running system kernel.

This means two things:

- Resources are only consumed by actual running debian processes you initiate. No mysterious background daemons. I run a bash shell, and the only extra process on the phone is one bash shell.

- Aside from memory/cpu resources (not really scarce on a 192Mb phone), zero impact on the rest of the phone (I can compile a kernel whilst making a call at the same time).

I can now install and run any debian app. With a $12 4Gb micro-sd, I can install a *lot*. Access either via keyboard or network (ssh).

python and perl on my phone - w00t!

All I'm waiting on now is someone to create python modules to interface with the phone's GUI. And/or an X server.