Doing some investigation, the claim that the BPG decoder is "small" might not be exactly true. The decoder, even minified, clocks in at 237 kB.

Although this is mitigated since the decoder could be cached in the browser cache, making it so that the decoder could be downloaded just once - at least just once per session. And once per web site, of course, because everyone is going to host their own copy of it. (I imagine at least... would same-origin policy be a problem if you tried to keep it somewhere central/standard?)

Anyone deploying this would be advised to consider if the space savings outweigh that initial cost in space. Then again, it all depends on what you want to acheive. What if you just have a huge archive of seldom-accessed images and want to save on disk space rather than on network bandwidth? Might make sense to store the images as BPG server-side and do decompression server-side if you can take the CPU hit.

As the poll is written, I interpret 'driver' as meaning "the occupant of the vehicle in the front seat on the side customarilly designated the "driver's side". I also interpret "fully autonomous" as meaning "nobody in the car has any direct control of the vehicle's operation, except for destination selection".

As such it makes no sense to require a person sitting in a certain seat to have a permit or a license, or even insurance for that matter. Consider the case of fully autonomous taxis where the owner and operator of the vehicle is not even in the car at the time. Or even private cars which are merely transporting themselves from point A to point B. (For example, from a distant parking lot, or even from the home when the driver decides he needs a car to transport some unexpected cargo.)

For that reason, it should be the *owner* of the car who should be required to operate the vehicle. That sure as hell would need to include some kind of liability insurance, and perhaps a permit in case the car is to be used as a commercial taxi. It would also need to pass regular safety inspections, just like non-autonomous cars do.

In the case where there's an autonomous car that also can be operated in a non-autonomous mode (such as driving off-road or manouvering for towing etc) I think a driver's license should be required in order to operate the car *in that mode*. (Another option might be to make any such operation speed-limited to perhaps 25 kph, and not require any license, analogous to "moped cars".)

This is all of course hinging on the existence of "fully autonomous" cars some time in the future. I think a vehicle fitting that definition is certainly many decades off, even though I think it's possible we'll see "partially autonomous" cars requiring a driver responsible to take over in case of unforseen circumstances, although I suspect people will soon realize that allowing an occupant of the car to take over from the software would cause more accidents than were prevented. (Computers are a lot better at knowing how a car handles than people, especially if the driver ceases to operate the car himself, "forgetting" how the car handles.)

This is what WDM (Wavelength Division Multiplexing) means. (DWDM = Dense Wavelength Division Multiplexing).

The moon isn't always at the night side of the Earth.

To extend the reverse-car analogy, the correct analogy is the use case of wanting to transmit a large movie to a USB stick so you can watch it on your TV. Doesn't matter if you have the best-of-the-best USB stick and USB 3.0 in your computer. The bottleneck is still the internet connection. So what you do is that you set your computer to download that large file while you're out doing whatever it is you're doing all day, and copy it over to your USB stick quickly when you get home. (You could even conceivably automate this process or remote control it from your cell phone.) In this scenario, having USB 3.0 *will* help since it'll cut down on the time on getting the movie from your computer to the USB stick.

Analogously, the way you'd do it for a residential charger, is that you'd have the power grid trickle charging a supercapacitor that you have at your home (ideally under some kind of control from the power company, so that they can manage the load on the electric grid) over the course of a few hours, so that when you need the power, you can just plug it in and almost instantly get your car charged up.

Although while we're on the subject of analogies, a better reverse-car analogy would be that of a flush toilet, slowly building up a reservoir of water to then quickly release it when required.

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.