Blackberry outage and iPhone release: Coincidence?

Is it just me, or coincidence that on both releases of the iPhone last year and this year that Blackberry's internet connectivity just happened to be trashed prior to or on the day of the iPhone release?
Is there some fowl play going on somewhere?

• 10th October 2011 - Blackberry suffer a network outage
• 14th October 2011 - iPhone 4s goes on Sale
• 18th September 2012 - Blackberry suffer a network outage
• 21st September 2012 - iPhone 5 goes on sale

Now if that's not a marketing ploy then I don't know what is. If I was Blackberry I'd be looking at who the cause of the outage is rather than what, and I'd find out when Apple plan to release the next iPhone and if it occurs again would draw up a law suit if I was them as this is too close for comfort.

Next time Apple release a new iPhone I will be watching the Blackberry network with anticipation and if another outage occurs (since the rest of the year the network is fine), then it can only be assumed that Apple are causing it to make Blackberry customers think that they should get an iPhone (even though the tech in the iPhone is at least a year old by the time Apple release them).

BASH issues that break the rules

I always thought BASH was too complex for it's own good. Unlike the commercial KornShell, BASH has things that break the rules of a good shell, such as forking a process for a built-in command, or caching commands instead of tracking them as aliases.

As I find some other annoyances with the Bourne Again Shell I'll list them in here and the reasons.

1. Caching commands.
   Instead of tracking aliases to the real command BASH decides to use a different command (built-in) to deal with tracking commands that you have already run.  In the KornShell you would normally run alias -t to see what commands have been tracked when you install a new command and the old version is still running.  However, with BASH you have to use the hash built-in command to identify what commands are being tracked.  The -l or -t option will display a list of the commands tracked, whilst the -r allows you to remove the tracked command(s).
2. Piping a while loop in BASH forces the built-in into a sub-shell, which means that any variables that you create inside the while loop body will be lost after the execution of the loop ends.  In KSH the while loop remains part of the shell process that is running, so you have access to the variables created in the loop once the loop execution ends.  Try the following code in both shells, and notice the major issue that the BASH generates which breaks all the rules on shell built-ins.
   
   cat /etc/passwd | while read line
   do
       if echo $line | grep steve >/dev/null 2>&1
       then
           newvar=$line
       fi
   done
   echo "This will only show in KSH: $newvar"