Fuck that noise. 172.16.0.0/12 baby.

If being a terrorist was a job that paid three billion dollars, I think you'd end up creating a lot of terrorists. Supply and demand.

I'm not a patent expert, although I did once watch a very informative video about how patents work. This makes me eminently qualified on the subject by slashdot standards.

The phone's SoC (system on a chip) is coupled to the touch screen. The SoC implements the invention of the patent (in software... yes... so what?). The fact that the CPU also happens to do a lot of other stuff too would not seem to be relevant.

I'm not a patent expert, although I did once watch a very informative video about how patents work. This makes me eminently qualified on the subject by slashdot standards.

Looking at the independent claims, it looks like at least the lock screen as implemented by Samsung (starting at the unlock button, drag a certain distance in any direction to unlock) and possibly other Android phones out there is safe from this patent.

1. A system comprising:

a touch screen upon which a user is to enter, by drawing, a geometric pattern in a specified direction to gain access to the system; and

a processing circuit coupled to the touch screen to compare the user entered geometric pattern to a predefined geometric pattern stored in a memory.

Since the system on Samsung phones works no matter which direction you drag, it looks like the "slide to unlock" implementation in Samsung phones is clear.

However, I think this patent may very well be applicable to the "pattern lock" of android phones.

Is there any evidence that it might? More specifically, does the change in the estimate of the mass of the object suggest this?

Why would a change in mass change the trajectory? Granted, it was a while since I took physics, but from what I remember:

1. The force of gravity follows F = GMm / (r^2) where M and m are the masses of the two objects in consideration. Here I will use m as the mass of the asteroid and M as the mass of any other object that is not the asteroid.

2. F = ma.

3. From this follows that a = (GMm / (r^2)) / m = GM / (r^2). As we can see, m (the mass of the asteroid)

This means means that the accelleration of an object due to gravity is only affected directly by the other object's mass, not by the object's own mass. However, a more massive object *could* attract other objects with a higher accelleration than expected, thus reducing r, thus over time increasing the accelleration, changing the tracjectory of not only the asteroid but also the other object.

Consider for a moment, however, how insignificant such an effect would be:

First imagine an asteroid the size of a football field. Then imagine the moon. Then imagine the earth. Then imagine the sun. Now imagine the mass of an asteroid even moving the moon more than an imperceptible amount due to gravity, let alone the sun.

You could do MCMXVII * LXIV as a calculation quite similar to 1917 * 64.

Just as:

1917 * 64 = 1000*64 + 900*64 + 10*64 + 7 * 64

in a similar way:

MCMXVII * LXIV = MM * LXIV - C * LXIV + X * LXIV + VII * LXIV

Multiplying by X for example is quite simple, you just transform I->X, V->L, X->C, L->D, C->M etc so X*LXIV (10*64) = DCXL (640). This is as an analogue to tacking a zero on the end. A little more complex, yes, but not fundamentally different.

That said, I like the system we all use today a lot better. :-)

Unless I misunderstood your comment, all you need to "balance your checkbook" are positive numbers (zero not required), addition, subtraction and the concept of equality and comparison. You just keep your income and your spendings on seperate tallies and compare them when you're done. You can handle any cases where "you've spent no money" or "you've received no money" as special cases without having to resort to the concept of zero being a number like any other.

It tells us that since autocomplete defaults to on, more people search to turn it off than do to turn it on.

The one does not exclude the other. There's nothing stopping you from doing what Google did - funding development a CUDA accellerated Theora codec if you feel so inclined (and if you have the money). :-)

I guess Google thought Theora on the desktop was "good enough" and wanted to focus on ubiquity rather than perfection - for now.

Non-technical problems, such as H.264 requiring licensing patents.

Patents are specifically intended to restrict usage of technology (to those who are inclined to pay for it).

So - a royalty-free product which produces comparable (if slightly inferior) results *should* become the ubiquitously available option. It is as it should be. :-)

I very much doubt, however, that Apple and Microsoft will include Theora in their web browsers or in the iPhone. I think it is much more likely that the patent-encumbered option is set to become more ubiquitous than the free option, due to corporate politics. (After all, neither Apple's or Microsoft's products support Theora or Vorbis out of the box now.)

Baidu's real spiders obey robots.txt. However there are plenty of malicious spiders out there who pretend to be Baidu in their User-agent string - giving Baidu a bad name in this area.

IPv6 does nothing to protect you against malicious routing updates, as far as I'm aware.

IPsec is a mandatory feature of an IPv6 stack, but nobody's forcing anyone to use it.

This hijack was on the routing level, not the DNS level.

Blacklisting China's IP ranges would do nothing to protect you against bad routing - something you as an end user don't have any control over.