Archive for the ‘Tech’ Category

Google Motorola Mobility Purchase Explained

Tuesday, August 23rd, 2011

It does make sense, people understand parts of it, but no one seems to get it right.  Let me explain.

Personal Tidbit: Kent’s Market Manipulation

Looking at a down-market, thinking this was a buying opportunity, I bought a few shares of Google. A few days later it fell on the Motorola news.  No, I wasn’t annoyed with myself (I didn’t have any inside information, and wouldn’t trade on it if I did).

Rather I am annoyed that the market doesn’t seem to understand what Google is up to. I need to explain so my stock can go back up.

Google wants Android to succeed.

Google’s Android “partners” don’t particularly care about Android succeeding, they want their own tablets and smartphones to sell.  So they tart up their versions of Android to try to catch an eye (“Hey, big guy! Wanna..touch my tablet…?”).  The other day I was talking to someone who was considering getting an Iphone.  No, I didn’t say “Get an Android!”, I kept my mouth shut because the Android market is a mess, I have no idea what Android phone is good right now.  I think Google is going to tell Motorola to make clean versions of Android.  Like the Nexus One (which I bought).  Once they do that I can recommend people buy a Motorola Android.  People will still be tempted by the trollops from the other “partners” and that is a matter between consenting adults, but at least there will be a clean and respectable baseline you can bring home to mom.

Google wants Android phones and tablets to innovate.

God knows what it took to get Samsung to put a near field communications radio (NFC) in the Nexus S, but I bet there are some cool things Google wants to do but no “partner” wants to bother with.  Google will tell Motorola to add new features.

Google “partners” need not quake.

Much has been said about how the “partners” won’t like Google being in the handset and tablet business, but if Google forces Motorola to do things the “partners” don’t think is smart…well, that might be just the kind of competition they could use: either ineffectual (no problem) or truly innovative (serves them right).  Google is no Apple, they don’t have an “all mine” utopian (dystopian!) vision, they aren’t interested in crushing LG or HTC. They want to sell ads.

Google has a really nice cash cow in their ad business. They aren’t interested in the low-margin hardware business for any reason other than to keep their ad business healthy. Their fundamental interest here is different from that of other Android hardware manufacturers.

Google has patent battles to fight.

Speaking of Apple and Android “partners”, Steve is doing his best to crush the entire Android ecosystem in the courts, some recent decisions out of Europe should have them all deeply scared.  Google to the rescue: Motorola has a lot of patents, many are probably even wireless-related. (What was the Nortel portfolio mix like?)  Motorola, unlike a patent trollhouse, and being a hardware business, might even have legitimate patents.  (I think software patents should be very rare and noteworthy, and that all the other SW patents are garbage.)  By measuring patents by the count, people miss the fact of these might include legitimate and topical patents.

Google is interested in big screens, too.

Google TV hasn’t done much so far, but they haven’t given up.  Motorola Mobility also includes set-top boxes in living rooms.  As much as we all like to poke at our phones, we also like being couch potatoes, sitting in front of a big TV, poking at our phones.  Google wants access to our TVs, Motorola Mobility gives them that.

Sitting on tons of cash is a waste.

Google can afford to buy Motorola Mobility. We now know they are serious about Android and will do what it takes to make it succeed.

Apple is not going to manage to drive a lawyer-hewn stake through Android’s heart. Android is here to stay.  Long live Android!

-kb, the Kent who thinks it all makes great sense and GOOG should go up now.

©2011 Kent Borg

Android Phones Won’t Keep Time Precisely

Wednesday, August 17th, 2011

Google should use the GPS receiver. They should use NTP. But they trust the cell carrier.

Recently I have been in awe of what an amazing thing my Nexus One is.

For example, with few instances of a little 2×1 widget called myUTC Clock, one of my home screens turns into an 8-timezone pocket watch.  A read-in-the-dark, self-setting, 8-timezone pocket watch.

I am old enough that such a thing would once have been very expensive if possible at all.  Yet I can add it to my phone for free.

So cool.  It must be time to start complaining.

My Android Nexus One isn’t reliable about how it keeps time.  Sure, it is good enough for prosaic purposes, but it could do much better.

In the Settings I have two choices, either “Automatic Use network-provided values” or I can set it manually.

I have it set to use network-provided values.  This means to take the time from the local cellphone network.  Unfortunately, the cell provider is sometimes quite wrong.  There is a lonely roaming section of highway I drive frequently where my phone clock is off by almost two minutes.  At home, on T-Mobile in the big city, my phone clock is set within a second or so.  That seems sloppy and random and prone to wild errors if some technician makes a typo.

My other option is to manually set the time.  I did this yesterday afternoon, and this morning my phone was off by over 20-seconds.  That’s enough to start missing airplanes if not reset frequently.

There are two other options that are not available without rooting my phone and customizing the software:

1. Use time from the GPS receiver.  Yes, the GPS receiver is not always turned on, but when it is it is an exceedingly good source of time.  Pretty much “gold standard” where time still has a “gold standard”.

2. Use time from the internet.  The Network Time Protocol (NTP) works over wireless connections, uses very little data, and can set time very precisely.

In both cases, once the Linux kernel inside my Android knows the correct time it is willing to faithfully honor it to very small intervals.

Google: Please make Android keep decent time.  Possibly someone has already done this nicely and you could just pickup the code, examine it some, and make it part of the official version.

Android phones have the ability to keep excellent and time, it is just a simple matter of programming.

-kb, the Kent who has been a time geek for years, who knows that time is very complicated because of the conflicting expectations we have about time, and who still misses airplanes.

P.S.  One of the complications that Google tries to avoid by taking local phone system time is that of timezones and daylight savings/summer time.  Okay, so it is tricky, but there is detailed timezone data available for Linux, you have location data (from the GPS and, ironically, from the local phone system), the result could still have problems, but they will likely still be better than blindly trusting the local phone system.

©2011 Kent Borg

Sony Passwords: Now do you believe you should not reuse passwords on different sites?

Friday, June 3rd, 2011

Sony has been cracked.  Multiple times.  It seems Sony employs nerds who know nothing about security.  Now, sonypictures.com has had a million username and passwords (and other information: DoB, e-mail) scooped up and made public.

Are you on that list?

The Playstation breaks would have been even more users.  It hasn’t been posted public, are you on that list?

Are you an X-Factor wannabe?  That database was also grabbed by the same crackers.

And these are just the public breaches.  The real bad guys–the ones who want to steal money instead of making a political point–are breaking in quietly, grabbing passwords, and moving on to see what other doors these keys will open.

What is the lesson here?  That companies have terrible security?  Yes, they do.  But that isn’t what should keep you up at night.

You should toss and turn if you are one of those people who reuse one password on multiple web sites.  If one site is broken into, then the bad guys have the keys to any other sites you have given that same password to.

Don’t reuse passwords.  Use a different password on every account you have.  And how should you keep track of all these passwords?  Write them down.

Yes.  Write down your passwords.  The advice about not writing down your password comes from way olden days when the number of computer accounts a person had was either zero or one.  It is obsolete.  Write down your passwords.

-kb, the Kent who used to use three different passwords for everything, until he discovered a machine on which he had an account, one he used the “good” password on, was broken into.

©2011 Kent Borg

Python Command Line Arguments

Wednesday, May 18th, 2011

For quite some time I have thought I shouldn’t parse my own command line arguments in Python, but each time I looked for the “right” way to do it, I turned back.

Today, I decided to persist.

Now I know why I turned back, the libraries were terrible.

I want to have:

mycleverprog.py mycommand --nifty-option

Where the command is to do one thing or do the opposite.  It is a required thing to say which.

The standard library argparse is a little obscure at first, but with a little reading it starts to make sense.  Cool.

Oh, dang!  It is new in Python 2.7, and I am running 2.6.  Okay, so let’s look at the deprecated optparse, it looks really similar, I’ll convert my embryonic code…

Horrors!  I don’t know the history of the project, but it looks like some “little minds” have been at work on this library.  Because it is called “optparse” it doesn’t support “required options” because the term is self-contradictory.  Come on!  A very common use case is to type a command with a required parameter following on the command line.  Think Unix commands like “rm” or “mkdir” or “touch”, or …, you get the idea.  These commands also have “options” that are optional.  So someone built a library that handles the “options” but makes a point of not handling a required parameter, just because of an unfortunate name for the library!?!  They even waste effort pontificating on why options should be optional?

Bosch!

They do talk about “positional arguments” being required, but it isn’t clear whether they even support that.

My solution?  Download

http://argparse.googlecode.com/files/argparse-1.2.1.tar.gz

put argparse.py in

/usr/local/lib/python2.6/dist-packages

and use argparse.  My little utility will just be for personal use–at least for now. By the time I give it to anyone else, newer versions of Python will be standard.  Or I can include a copy of argparse.py.

-kb, the Kent who is slowly getting better and better at Python.

©2011 Kent Borg

Android Pattern Unlock Insecure

Tuesday, May 10th, 2011

When I first saw the pattern unlock feature in Android phones I thought: Cool!

And I used it on my Nexus One.  Until I realized that it is a really stupid idea if I want my phone to be secure.  Don’t do it.

The problem is that the phone screen gets smudged.  And when you unlock your phone you will leave a new smudge trail revealing your pattern.

Here is how to read it: With the phone turned off hold it up to a bright light, but angle it so that so that it reflects something dark.  The smudges will be obvious.

Turn the phone on, note where the pattern dots are, turn it off and see what smudges align with the pattern dots.  Turn in on, turn it off, and you will be able to see the pattern.  (At least if the phone wasn’t used much with dragging gestures on top of the pattern area.)

New smudges will write on top of old smudges, they will be “in front”, so to reproduce the pattern in the right order start with the smudges that are “behind”, and trace towards the “front”.

It is tempting to wipe off the screen to clear the smudges of your unlock pattern, but beware: A clean screen is even easier to read than a dirty screen, so if you ever forget to wipe it after entering your pattern, your unlock pattern will be very readable.

This doesn’t mean your pattern lock is completely insecure always.  If you unlock your phone and then use it a lot with plenty of dragging gestures in the pattern area, then turn it off, your unlock pattern will be very hard to read.  But do you ever turn on your phone, maybe just to check the date, and then turn it off?  If so, your lock pattern is not hard to read at all.

So the unlock pattern is cool, but a bad idea.  Instead you should use a unlock code number.

“But wait!” I hear you say.  “Can’t those smudges be read too?”

Yes.  But they are taps not drags, so the order is hard to read.  And, this means a 4-digit PIN is not so good.  If someone can figure out what the 4-digits are, there are not that many combinations to try.  Only 24 (4×3x2×1, or 4 factorial).  Increase your PIN to 5-digits and the number of combinations are 57, not great, but a lot better.

I suggest you make up a truly random PIN of, say, 6-digits.  (Have a spinner from a board game?  Maybe use that.) then fill in the other digits in, say, left-to-right, top-to-bottom order.  If the person who finds your phone can see your PIN uses all ten digits (with no repeats), that narrows it down to 3,628,800.  Because your phone limits how fast PINs can be tried, that is pretty good, and you only have will have a PIN that is pretty easy to remember.  A PIN with repeated digits is cool, but the smudges might show which digit is repeated, diminishing its value somewhat.

The only catch is that it takes a moment to enter a long PIN each time you turn on your phone.

If, however, more and more of your life is in your phone, it might be worth it.

-kb, the Kent who tried to figure out how to photograph the smudges of an unlock pattern lock, but it is tricky to get the lighting right.

©2011 Kent Borg

Falling Cats

Saturday, January 8th, 2011

I get behind on my podcast listening, but last night I listened to the recent Radio Lab short (http://www.radiolab.org/blogs/radiolab-blog/2010/nov/29/vertigo/) that brought up that old claim that cats which fall from New York apartments have minor injuries if they fall from low floors, do not fair well from higher floors, and did well again if they fell from very high floors.

First, Neil deGrasse Tyson is right that the data set is flawed.  Lots of things could confuse the issue.  For example, maybe those cats falling from fancy penthouses have personal trainers, are very fit, and are better able to survive a fall, whereas those complacent 6th floor cats might be overweight and are not so suited to falling into the street.

That said, I can’t resist guessing.

I think it mostly comes to velocity on impact.  (What the cat hits also would matter–more on this below.)  Higher velocity is bad.  So falling from a low floor doesn’t offer enough time to get moving fast.  Fall from a higher floor and the cat will be traveling faster on impact.  So what about those very interesting cats falling from very high up?

They are offered a few seconds to try to learn to fly–and motivation to get it right.  I bet that if they hold their front legs just right that under-arm skin can be stretched to catch more wind resistance.   Maybe there is something similar that can be done with the back legs.  Some focused high altitude cats will even learn to steer and avoid landing on, say, the spiked fence out front.

In another nod to Neil, some of the penthouse cats maybe live in buildings with fancy doormen and canvas walkways to the sidewalk–that might be a good thing to aim for.

-kb, the Kent who has never thrown a cat from a window.

©2011 Kent Borg

Nexus One and LM961 Bluetooth Bracelet

Thursday, January 6th, 2011

I recently got an LM961 Bluetooth bracelet to use with my Nexus One phone.

Pretty cool, here are some observations:

  • The diameter of the metal bracelet is big.  I couldn’t figure out how to take out extra links, so I brought it to a local watch repair shop just before closing and asked them to make it smaller.  $10 later, and, um, they were having problems, too, and asked me if I could come back tomorrow.  Okay, I came back, they figured it out, it was still a little big, they took out one more link while I waited (now they had learned the trick), and now it fits.
  • It likes to lose connection to my phone…and then reconnect happily.  I moved it to the other wrist, to make it closer to the hip where I keep the phone, and maybe that helps, but it still loses connection.  I think it doesn’t like being close to a wifi access point.  (They are in the same band.)
  • The US model I got from Thinkgeek at the end of 2010 has a little wall-wart power supply, with a permanently connected cable.  Unlike a British model I have seen pictured: it had a cable that has a tiny coax power connector one end and a USB connection on the other–plus a wall-wart to plug that into.  I wish my model were like that, then I could charge it from any USB jack.
  • Biggest gripe seems to be that it is a Bluetooth “headset”, that is, when a call comes it, I grab the phone to answer, I say “Hello?”, the person on the other end starts to talk, then s/he goes away…and if I look at the phone I see that the “Bluetooth” button is activated in the Phone application.  I tap the button and the audio comes back.  This is a problem.  Possibly this is why the instructions say a short(er) button press answers the phone.  I wondered why I wouldn’t want to just answer the phone on the phone.  Maybe this is why.  I’ll have to get another phone call and update…

I am hoping that Openwatch support for the LM960/LM961 would fix this.

-kb, the Kent who doesn’t like a loud phone, but whose wife doesn’t like when he doesn’t get her call.

UPDATE: I never got it to do anything useful. Dang.

©2011 Kent Borg