Monthly Archives: June 2013

Google’s acquisition of Waze

I am worried about what Google will do to Waze. Waze involves users directly. Google does not like direct user input. Google likes crunching gobs of data on user behavior. Google trusts aggregate data more than people. While that might allow Google to correctly guess what I meant to search for (because 99% of the time, other people made the same typo), it may actually degrade route calculation. Google calculates the best route from A to B based on speed, distance and traffic. Plus Google knows that 99% of people take that route even if it is not the best route. But, 1% of people know a faster/easier route (and that benefits the 1%). Will Google allow that 1% to override the 99%? Waze has learned my shortcuts (that are consistently faster than Google’s or Waze’s calculated routes) and now presents them as the default route.

Related, Waze allows normal people to instantly alert others of an accident, construction, etc. Google relies on public sources like Caltrans, CHP etc, which are once removed from the source data. A minor accident which causes a major local backup but is never reported to CHP would not show up in Google Navigation, but could in Waze. Google may show the reduced speed but not the cause.  How will Google integrate Waze’s crowd-sourced data?

Update 20130614: @TechCrunch With Waze, Google Gets Access To Social Mapping Data — And Possible Patent Legal Heat From Nokia

Google Navigation vs. Waze

Funny, I started writing this the day before the possible purchase made the news.

I have been using Waze for 3 years. Whenever I am on the road, I run Google Navigation on my Droid 4 and Waze on my iPhone 4S. Google used to give incredibly accurate (to-the-minute) ETAs but something changed in the last few months, their ETAs have been increasingly wrong (optimistic). Google clearly has more speed data than Waze (unless you opt-out, every Android phone constantly uploads position and speed information) and yet, Google seems to have forgotten how to factor in delays caused by traffic jams enroute. Waze never did this well either so now they’re about the same ETA-wise.

Both are frighteningly good at predicting my next destination. Normally, both ask if I am going home from daycare. But Google has learned that Wednesday is usually pizza night and asks if I am going to Costco instead. Google presents a sorted list so I can easily select the top entry. Waze asks if I am going to X and automatically routes to X if I do not press anything for 10 seconds.

Google pluses:

  • One button toggle between display of entire route and local (navigation) view.
  • One button display of alternate routes with distance and drive time for each.
  • Usually more accurate display of traffic speed (compared to Waze).
  • Usually better route calculation (compared to Waze).

Google minuses:

  • No user-reporting of incidents. Far too often, Google will think the freeway is clear when it is actually a parking lot due to a stalled vehicle. But there is no way for me to warn other people.
  • Refuses to consider surface streets as an alternate route.
  • Refuses to use carpool/express/HOV/HOT lanes. In fact, Google does not seem to know how to handle them at all because while I am in the carpool lane, Google constantly suggests ludicrous routes to exit it.

Waze pluses:

  • Cleaner local (navigation) view with useful info: speedometer, ETA, miles to go, remaining drive time.
  • Rapidly reported, accurate, crowd-sourced incident and traffic information (compared to Google’s reliance on Caltrans / CHP). Crowd-sourcing is obviously better if there are many active Waze users in your area.  Also, I often send alerts with photos.
  • Prettier interface.

Waze minuses:

  • Occasionally faulty route calculation. Sometimes Waze knows an alternate route is slower (ETA is later) but still displays that route.  Sometimes the detour is obviously slower to an experienced driver because it involves multiple left turns at uncontrolled intersections.
  • Needs single-button entire route display like Google.

I took screenshots of both Google and Waze on a typical drive to daycare.  At startup, Waze guesses I am driving to daycare and presents some useful information – ETA, distance and traffic on route summary:


Once on our way, Google’s presentation of street and freeway traffic conditions showed a large segment of surface street without speed data (grey) and moderate traffic on the freeway:


Waze’s presentation shows Wazer-entered traffic alerts and two absolute speeds, which are different from (and more accurate than) Google’s:


Waze’s distinguishing feature are Wazer alerts which are usually very accurate:


Both Google and Waze occasionally suggest a “better” route that is actually worse.  Here Waze suggests a “better” route that has an ETA of 08:47 while the ETA for the current route is 08:46.


Google’s entire route view presents much more useful information than Waze.  Here, Google thinks traffic is slow ahead while Waze shows no data. I have to click on the Wazer alerts to see their content.  They may warn that the freeway is slow but I should not have to click on them while driving at 57mph to find out.



But later, Google mistakenly thinks the freeway is completely clear while Waze correctly says it is not:



Photo showing actual traffic:IMG_2858c

Google’s alternate route display is much better:


than Waze’s default:


Clicking on Map brings up a much more useful display, though I still have to pinch-zoom to enlarge:


And another example of Google vs. Waze alternate route calculation.  Waze correctly suggests the carpool lane which is the faster route.



And an example of Waze’s incorrect “detour” routing. It wants me to make a left turn (controlled) at a very busy intersection, right turn onto a side street with stop signs, then left turn (again controlled) back onto the same street. Local drivers are smarter than the algorithm, we know this would be far slower.


I am hoping that Google assimilates some of Waze’s better features: user reporting, surface street routing and carpool lane awareness.

Adobe and case-sensitive filesystems

My Mac has multiple filesystems.  Non-system partitions are formatted Case-sensitive, Journaled while past experience with Adobe has taught me that the OS partition must be formatted Case-insensitive, Journaled.  The global Applications folder and the admin account’s home dir live on OS partition.  My non-privileged account’s home dir lives on a case-sensitive partition.

I  tried to install InDesign CS6 as myself via Adobe Application Manager download.  Very early on in the process, it threw up this error:

Screen Shot 2013-06-03 at 12.43.45 PM

Googling for that error code, A12E1, returned nothing useful.  I downloaded the full installation dmg, then ran the installer.  Different error:

Screen Shot 2013-06-03 at 12.48.42 PM

Which is frustrating because the partition I was trying to install on is case-insensitive.  Also, the installer does not allow you to select a different partition.  I saw many complaints in various forums about this decade-old bug.

Solution: Log in as admin (home dir on case-insensitive partition), run ID6 installer from downloaded dmg, log out of admin, log back in as myself, and run ID6.  The installer checks the active user’s home partition for case-sensitivity which does not make sense since the legacy stuff lives on the case-insensitive OS partition.

Castle – S05E24 – Watershed

Screen Shot 2013-05-15 at 00.15.03

I have never seen a security/firewall system like this.  On the left, I see emacs or some variant of, the status line says “edit code: mySysScan.c“.  And the middle bottom window says “*shell*“.  The lower right is some code that I cannot make out.  The rest looks familiar but I cannot identify it.

But the bigger question is, if they were looking into how somebody broke into a system, wouldn’t either/both the Security Scan or Firewall Protection Scan have alerted when the incursion occurred?  And if they did not, why would a post mortem scan produce a different result?

The Following – S01E04 – Mad Love

Screen Shot 2013-02-11 at 23.36.24

There are so many things wrong with this.

  • Once again, the window on the left is source code, because we always have source code up.  The code is unp.h from
    /* OSF/1 actually disables recv() and send() in <sys/socket.h> */
    #ifdef	__osf__
    #undef	recv
    #undef	send
    #define	recv(a,b,c,d)	recvfrom(a,b,c,d,0,0)
    #define	send(a,b,c,d)	sendto(a,b,c,d,0,0)
  • North Korea does not have a gigabit uplink to the rest of the world.
  • While none of the IP addresses are (understandably) valid (all have one octet > 255), the last few hops are multicast addresses which are not traceable.  See Wikipedia – Multicast address.
  • The real command is “traceroute” (or “tracert” in Windows land) and it shows you the path from the computer you are running it on to another IP address.  You can trace back to a mail/web/ftp/etc. server ( if it actually existed), but not to an email address.  Some mail servers add a header line that shows the client IP, which you can trace back to.
  • If the recipient of the message was at Host A (126.55.341.66), and the sender was Host B (, an investigator at Host C (shown above) cannot run a traceroute to see how Host A would talk to Host B.
  • The hop times are simply replicated, 160ms/240ms 174ms/436ms alternating.
  • The normal traceroute does not show the type of device, ie., wifi router, satellite, etc.  It is possible to determine the type of device from its MAC address, but only the next/previous hop sees the MAC address, and it is not passed along.
  • Traffic going through a satellite would be layer 1 (the satellite does not have an IP on the customer traffic side) and thus the satellite would not show up as a hop.  This article is from 2008 but still valid – Identifying undersea fibre and satellite links with traceroute.
  • Why would traffic bounce through 10 satellites?
  • traceroute does not show the local computer’s network card as the first hop.
  • Why would every window have a WiFi menu?

A real traceroute looks like this:

Screen Shot 2013-06-09 at 16.04.25