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.
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.
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.
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.
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.
It's just as likely Victorinox bought some solution from some third party using some kind of snake-oil cryptography, and slapped their brand on it in good faith.
As far as I know, yes - the Pirate Party Australia does not currently hold any seats.
If by "they" you mean the collection Pirate Parties in general, you'll find that Piratpartiet (Sweden) has two Members of European Parliament. That's more than some "established" or "legitimate" political parties in Sweden.;-) Pretty good for a joke.
AS29216 at the right is the AS which I.ROOT-SERVERS.NET is located in. As we can see, it is only reachable through AS8674 (NETNOD-IX).
Which in turn is reachable directly from a few different AS:es, including AS24151 (CNNIC-CRITICAL-AP).
My guess is that Netnod simply started filtering out the routes to AS29216 via AS8674 on the BGP session to AS24151.
The DNS server itself might have been using BGP, it might not have. But in the end every system on the Internet is reachable with some kind of BGP route somewhere.
An important factor is that PNG is technically superior to GIF. The most glaring deficiency in GIF is that it only supports 256 colors.
PNG also brings alpha channel transparency to the plate (though it wasn't supported in IE6.)
The only thing GIF does better than PNG is animations. PNG has a companion format, MNG, for animations, but it is not supported by IE for example, so nobody uses it outside of cute tech demos. So, there's still a niche for GIF out there - lightweight animation without loading a browser plugin or a java appet.
PNG was simply a better solution for lossless compression than GIF ever was. The same cannot be said for Theora vs H.264, unfortunately, so the same situation does not apply.
This is not an issue of the secondary DNS vs the primary DNS. This will occur even on systems with only one DNS server configured.
The faults are intermittent. If you're using a DNS server that's whitelisted by Google (such as Hurricane Electrics nameservers) which return AAAA records for www.google.com - as long as the cache is clear when you ask your web browser to hit it, it'll hit Google over IPv4 most likely, since the A record will come back first.
Unless, of course, you ping6 www.google.com with a clear DNS cache, which will force an AAAA response to be cached. Oh joy. Then you'll get to IPv6 into google until the OS decides to mark the cache as dirty...
I sent a bug report to Apple about this earlier. You might want to see if you can reproduce it if you care.:-)
18-Feb-2010 11:57 PM Per von Zweigbergk: 'getaddrinfo-test.c' was successfully uploaded
18-Feb-2010 11:57 PM Per von Zweigbergk: Summary: getaddrinfo() will sometimes fail to respond with IPv6 information
Steps to Reproduce: 1. Make sure to be on a machine with IPv6 connectivity as well as IPv4 connectivity, with a DNS server configured to respond with AAAA records for www.google.com. Not all are - by default, Google only provides AAAA records to DNS specifically requesting it. Setting up DNS via Hurricane Electric's nameserver at 2001:470:20::2 should acheive the desired result.
2. Flush the DirectoryServices cache using "dscacheutil -flushcache", and then immediately "telnet www.google.com 80". Close the connection after it has been established.
3. Force an AAAA (IPv6 address) lookup of www.google.com by issuing the command "ping6 www.google.com". You may abort the ping as soon as you see that it's performed the name resolution.
4. "telnet www.google.com 80" again. Close the connection after it has been established.
Expected results: Both times, running telnet should connect to google via an IPv6 address.
Actual results: At step 2 (the first time telnet is run), it is very likely that only the IPv4 addresses of www.google.com will be returned to telnet.
Regression: Mac OS X 10.5.6 seems not to be affected by this bug, in casual testing.
Notes: I (and others before me) have tracked this down to somewhere past getaddrinfo() - so it's an OS bug, not a problem with telnet. Other applications are also affected. I first noticed this when running tcpdump to ensure that I am, in fact, getting Google over IPv6 with Safari and Firefox.
I have submitted a demo tool in C which will simply query getaddrinfo() and return the information it returns, to verify that the information it returns is in fact the cause of the exhibited behaviour. This tool may be built simply using gcc and requires no linking with any libraries beyond the standard library, and should build on other platforms as well. (I have tested it on Linux.)
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.
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.
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.
In the area of Swiss army knives, yes.
It's just as likely Victorinox bought some solution from some third party using some kind of snake-oil cryptography, and slapped their brand on it in good faith.
Two seats, not one - ever since the Lisbon Treaty was ratified.
As far as I know, yes - the Pirate Party Australia does not currently hold any seats.
If by "they" you mean the collection Pirate Parties in general, you'll find that Piratpartiet (Sweden) has two Members of European Parliament. That's more than some "established" or "legitimate" political parties in Sweden. ;-) Pretty good for a joke.
Here's a graph of the network structure as seen by BGP.
AS29216 at the right is the AS which I.ROOT-SERVERS.NET is located in. As we can see, it is only reachable through AS8674 (NETNOD-IX).
Which in turn is reachable directly from a few different AS:es, including AS24151 (CNNIC-CRITICAL-AP).
My guess is that Netnod simply started filtering out the routes to AS29216 via AS8674 on the BGP session to AS24151.
The DNS server itself might have been using BGP, it might not have. But in the end every system on the Internet is reachable with some kind of BGP route somewhere.
An important factor is that PNG is technically superior to GIF. The most glaring deficiency in GIF is that it only supports 256 colors.
PNG also brings alpha channel transparency to the plate (though it wasn't supported in IE6.)
The only thing GIF does better than PNG is animations. PNG has a companion format, MNG, for animations, but it is not supported by IE for example, so nobody uses it outside of cute tech demos. So, there's still a niche for GIF out there - lightweight animation without loading a browser plugin or a java appet.
PNG was simply a better solution for lossless compression than GIF ever was. The same cannot be said for Theora vs H.264, unfortunately, so the same situation does not apply.
This is not an issue of the secondary DNS vs the primary DNS. This will occur even on systems with only one DNS server configured.
The faults are intermittent. If you're using a DNS server that's whitelisted by Google (such as Hurricane Electrics nameservers) which return AAAA records for www.google.com - as long as the cache is clear when you ask your web browser to hit it, it'll hit Google over IPv4 most likely, since the A record will come back first.
Unless, of course, you ping6 www.google.com with a clear DNS cache, which will force an AAAA response to be cached. Oh joy. Then you'll get to IPv6 into google until the OS decides to mark the cache as dirty...
I sent a bug report to Apple about this earlier. You might want to see if you can reproduce it if you care. :-)
(I'd post the test application as well, but I have a feeling slashdot will mangle it horribly.)