You see that tiny little upward spike at the Norwich charge point? That's where he plugged it in to charge, and it looks about right for an hour's charge at 240V because 240V charging is really, really slow - it apparently takes about 10-12 hours to fully charge a Model S from a 240V charge point. (And remember, this is with a dedicated electric vehicle charging point almost exactly like the one Tesla owners get installed at home!) That's good enough for overnight charging but not much help if you're standing around in the cold waiting for it to finish so you can continue your journey. The nearest high-speed charging point was probably the Tesla Supercharger he was trying to get to when the car died on him.
The part where the graphs (not raw logs!) basically confirm everything he said, especially the part that's most damaging to Tesla - the drop in range remaining from 90 miles to 25 miles overnight, unexpectedly leaving him without enough range to reach the nearest Supercharger. (Look at the vertical drop in range at the 400-mile mark. It's hard to see what actually happened because Tesla have carefully avoided releasing any graphs of range against time, or any raw logs of the same.)
In fact, Elon Musk is being really disingenous here when he accuses Broder of lying about the car falling short of its predicted range. Yes, it did predict 31 miles - after it'd already lost most of its predicted range overnight, forcing him to delay his journey and use a far slower Level 2 charger. (Which probably has rather more to do with why he charged to 28% rather than the full 90% than Elon's conspiracy theories. A full 90% charge would have taken around 10 hours - not that you could figure that out from Elon's blog post - adding a whole additional day to his two-day trip. Does Elon Musk really think that having to stand around in the cold for 10 long freezing hours and turn a two-day trip into a three-day one would really paint his $100,000 car in a good light? I honestly doubt it - if he had fully charged, we'd be seeing a blog post from Elon about how if he'd just charged enough to get to the Supercharger the article was meant to be about he could've made the trip in far less time, and how the journalist was intentionally trying to discredit Tesla by charging fully at a slower charger.)
As the attempt of charging at Norwich shows, the low voltage charging is barely enough to compensate the self-discharge.
Yeah, and that's with a dedicated 240V charging point too - 120V may well have left the battery less full than when he started, especially judging from some of the comments on the Tesla forums about it!
Well, that's what Tesla want you to assume anyway. The detour, going above the speed limit etc. were apparently on the first leg of the journey which was hairy but not really the problem. The real problem was that he then went and gave the car enough charge to make the planned next leg with some to spare if it wasn't for the car losing the majority of its charge overnight, an issue Tesla Motors apparently neglected to mention. That left him unexpectedly stranded with insufficient charge to reach a recharging point...
With patents, small inventors are even more screwed. Patents do you no good unless you have the money to enforce them in court, and they don't. Worse still, since no invention happens in a vacuum they almost certainly infringe on patents held by their larger competitors who can afford to sue over them - and even if they don't, the bigger companies can drag out the lawsuit for long enough to bankrupt the smaller one through legal fees and buy it up on the cheap. (See for example Creative and Aureal.)
The only way for smaller inventors to "benefit" from patents is through patent trolling, where they just sit on their patents until someone else independently invents something similar then sue them into submission. Even then it's usually the company funding the patent lawsuits who benefits the most, not the inventor.
Not that timely. This has already been proven wrong:
A piece of JavaScript coming from a trusted, 2048-bit HTTPS server is verifying additional pieces of JavaScript coming from untrusted, HTTP/1024-bit HTTPS servers. This basically enables us to host the extremely integrity-sensitive static content on a large number of geographically diverse servers without worrying about security.
The MAC they're using to verify the "extremely integrity-sensitive static content" is not in fact a cryptographically-secure hash. Anyone with the associated key (which has to be included in plain text in the page source in order for the verification code to be able to check the MAC is correct) can easily create arbitrary files with arbitrary malicious content that have the same MAC and pass the integrity checks.
Apps know there's NAT, and cannot assume end-to-end connectivity. With IPv6, determining if there's end to end connectivity is much hardware because firewalls are transparent - you may be able to establish a partial link, but not a full one because the firewall lets some of the packets through.
They don't know what kind of NAT though, which matters for most applications that care about end-to-end connectivity because there's a good chance the system on the other end is NATted too. Is it full-cone, restricted-cone, symmetric? Does this depend on whether the application is speaking UDP or TCP? What about the other end? Will we have to let the other system initiate the connection because they're behind a symmetric NAT and can't holepunch, or vice-versa, or will we have to give up on peer-to-peer communications altogether and go through a central server?
Standard NAT holepunching techniques work just fine with firewalls. They do not work reliably with NAT, and especially not with carrier-grade NAT.
A couple of years ago, Facebook decided to make everyone's interests public. Not just public by default either - there's no longer any way of restricting who can view your interests, or your hometown, or your work and education history, or which pages you've liked. All of that is now unconditionally public, and all of it is now searchable too.
They do more than look for things that are "virus like". At least in the case of Avast!, they now block any application that's new or obscure just in case it might be zero-day malware, and I believe other antivirus companies do the same thing. This means they're 100% effective against new malware at the cost of having a 100% false positive rate on new or exotic software. Doesn't even have to be that obscure either - I've had Avast block a moderately well-known game off Steam because not enough people run it to be sure it's safe.
In pratice, I expect most users either just click "Yes" reflexively or turn off that part of the scanner altogether, so it provides very little actual protection against threats - but it sure looks good in the benchmarks.
Guess there's not much of a market for it. Some of the A10-based boards do have SATA, including the Cubieboard, but not all of them and boards based on other SoC are harder to add SATA support to because there's no support for it on the SoC. (Most of them don't have PCIe support so there's not even anywhere to connect a SATA controller to.)
NAT holepunching only works on NATs that map all UDP traffic coming from the same IP and port within the NAT to have the same source IP and port outside of the NAT, no matter what their destination (so-called full cone or restricted cone NAT). Without this property there's no way for the other system to know what port incoming packets will be coming from, and therefore no way for it to punch the appropriate hole in its own NAT to let them in. NAT on home routers almost always has this property but carrier-grade NAT generally doesn't because there just aren't enough ports available to make it work. So NAT holepunching solutions don't actually work on carrier-grade NAT.
The general reckoning over there seems to be that someone's been intentionally removing it from the front page for some weird reason. There have been a whole bunch of posts that have been highly upvoted, most of them just got pulled.
Also, that wouldn't help much anyway - most the barite mined goes to oil and gas drilling, so sooner or later we'd run into problems getting enough new barium for medical purposes to replenish the stuff lost, and reusing the medical barium wouldn't help delay that by much.
The government didn't just charge interest, they also got equity in the company that massively diluted existing shareholders. Effectively, it's as though the government confiscated 90% of every single AIG shareholder's shares in exchange for giving AIG a loan - with interest - that it promptly paid out to other companies that'd basically swindled them. The shareholders might well argue that they'd have been better off if the company had gone insolvent, especially since it had more than enough assets to cover all its liabilities and they'd get the remainder, whereas now their portion of the company has been diluted by Government intervention.
Of course, there's no reason to believe that girls are naturally any better than boys at interpersonal stuff, or that boys are naturally better than girls at analyzing problems, but it doesn't matter - the argument works just as well if any gender differences are solely a result of them being socialized to think in different ways.
The X server is full-fat, but the graphics driver is about the most rudimentary X driver there is - no acceleration, no mode setting, just a framebuffer.
You're confused as hell, Bubba. Google for "gold standard". Theoretically, a nation on a gold standard has gold in a vault somewhere that is equal in value to all the currency it has in circulation.
Well yes, that's the problem. There is absolutely no reason why the total value of the economy should have any particular relationship with the total value of all of the gold in existence, which leads to all kinds of fun when the economy expands and you have to somehow convice everyone that gold is now worth more not because it's actually more useful for anything (it isn't) but because we need it to be worth more in order to have enough currency in circulation to support the actual value of the parts of the economy that are genuinely worth more.
From what I can tell, the patch was intended to change the behavior userspace sees from the driver, so it wasn't immediately clear whether this was an intentional change or not. More importantly, it also wasn't clear whether other drivers which Mauro was also responsible for maintaining also behaved in the same way. Mauro provides some context here - basically there are a whole bunch of different webcam drivers which each implement the V4L2 API slightly differently, which means that often applications only work properly with certain webcams. The patch was part of an attempt to clean this up. Linus seems to think that any change to userspace APIs that might break existing applications is wrong and fixing up compatibility is no excuse, so it looks like webcams will remain a mess on Linux for a while...
No. The actual analogy would be if Bill said. "Errrm, hang on, the existing beads which are in equally important structural areas are just as dodgy, should we fix those too" and his boss yelled at him to shut up and stop trying to make excuses, they haven't failed yet so they're fine. Then a few weeks later the whole thing falls down and kills someone because one of the older welds fails.
His argument is that it's a bug with pulseaudio because there are already quite a lot of existing drivers that behave in exactly the same way, and PulseAudio broke here it's already going to be broken with all of them. Subtle difference.
In addition, the MK802 runs the "source available, but developed in secret" Android OS, while the RPi runs the truly open source Debian by default and a zillion other true open source Linux distros with easy download.
That's not quite right. The standard option for RPi these days is Raspbian, which is actually a clone of Debian developed and maintained by Raspberry Pi users. So you don't have the support of al the actual Debian infrastructure like their package archives, download mirrors, etc. Meanwhile the MK802 can run either Ubuntu or Debian (or various other OSes). You need a custom kernel just like on the Pi but nearly everything else is standard Debian/Ubuntu. (Ubuntu can't actually run on the Pi at all because the ARM processor's too old.)
Slashdot Mirror
You see that tiny little upward spike at the Norwich charge point? That's where he plugged it in to charge, and it looks about right for an hour's charge at 240V because 240V charging is really, really slow - it apparently takes about 10-12 hours to fully charge a Model S from a 240V charge point. (And remember, this is with a dedicated electric vehicle charging point almost exactly like the one Tesla owners get installed at home!) That's good enough for overnight charging but not much help if you're standing around in the cold waiting for it to finish so you can continue your journey. The nearest high-speed charging point was probably the Tesla Supercharger he was trying to get to when the car died on him.
The part where the graphs (not raw logs!) basically confirm everything he said, especially the part that's most damaging to Tesla - the drop in range remaining from 90 miles to 25 miles overnight, unexpectedly leaving him without enough range to reach the nearest Supercharger. (Look at the vertical drop in range at the 400-mile mark. It's hard to see what actually happened because Tesla have carefully avoided releasing any graphs of range against time, or any raw logs of the same.)
In fact, Elon Musk is being really disingenous here when he accuses Broder of lying about the car falling short of its predicted range. Yes, it did predict 31 miles - after it'd already lost most of its predicted range overnight, forcing him to delay his journey and use a far slower Level 2 charger. (Which probably has rather more to do with why he charged to 28% rather than the full 90% than Elon's conspiracy theories. A full 90% charge would have taken around 10 hours - not that you could figure that out from Elon's blog post - adding a whole additional day to his two-day trip. Does Elon Musk really think that having to stand around in the cold for 10 long freezing hours and turn a two-day trip into a three-day one would really paint his $100,000 car in a good light? I honestly doubt it - if he had fully charged, we'd be seeing a blog post from Elon about how if he'd just charged enough to get to the Supercharger the article was meant to be about he could've made the trip in far less time, and how the journalist was intentionally trying to discredit Tesla by charging fully at a slower charger.)
As the attempt of charging at Norwich shows, the low voltage charging is barely enough to compensate the self-discharge.
Yeah, and that's with a dedicated 240V charging point too - 120V may well have left the battery less full than when he started, especially judging from some of the comments on the Tesla forums about it!
Well, that's what Tesla want you to assume anyway. The detour, going above the speed limit etc. were apparently on the first leg of the journey which was hairy but not really the problem. The real problem was that he then went and gave the car enough charge to make the planned next leg with some to spare if it wasn't for the car losing the majority of its charge overnight, an issue Tesla Motors apparently neglected to mention. That left him unexpectedly stranded with insufficient charge to reach a recharging point...
That's the theory. In practice, every update breaks some drivers which are badly-written and make dubious assumptions, on both Windows and Android.
With patents, small inventors are even more screwed. Patents do you no good unless you have the money to enforce them in court, and they don't. Worse still, since no invention happens in a vacuum they almost certainly infringe on patents held by their larger competitors who can afford to sue over them - and even if they don't, the bigger companies can drag out the lawsuit for long enough to bankrupt the smaller one through legal fees and buy it up on the cheap. (See for example Creative and Aureal.)
The only way for smaller inventors to "benefit" from patents is through patent trolling, where they just sit on their patents until someone else independently invents something similar then sue them into submission. Even then it's usually the company funding the patent lawsuits who benefits the most, not the inventor.
Not that timely. This has already been proven wrong:
A piece of JavaScript coming from a trusted, 2048-bit HTTPS server is verifying additional pieces of JavaScript coming from untrusted, HTTP/1024-bit HTTPS servers. This basically enables us to host the extremely integrity-sensitive static content on a large number of geographically diverse servers without worrying about security.
The MAC they're using to verify the "extremely integrity-sensitive static content" is not in fact a cryptographically-secure hash. Anyone with the associated key (which has to be included in plain text in the page source in order for the verification code to be able to check the MAC is correct) can easily create arbitrary files with arbitrary malicious content that have the same MAC and pass the integrity checks.
Apps know there's NAT, and cannot assume end-to-end connectivity. With IPv6, determining if there's end to end connectivity is much hardware because firewalls are transparent - you may be able to establish a partial link, but not a full one because the firewall lets some of the packets through.
They don't know what kind of NAT though, which matters for most applications that care about end-to-end connectivity because there's a good chance the system on the other end is NATted too. Is it full-cone, restricted-cone, symmetric? Does this depend on whether the application is speaking UDP or TCP? What about the other end? Will we have to let the other system initiate the connection because they're behind a symmetric NAT and can't holepunch, or vice-versa, or will we have to give up on peer-to-peer communications altogether and go through a central server?
Standard NAT holepunching techniques work just fine with firewalls. They do not work reliably with NAT, and especially not with carrier-grade NAT.
A couple of years ago, Facebook decided to make everyone's interests public. Not just public by default either - there's no longer any way of restricting who can view your interests, or your hometown, or your work and education history, or which pages you've liked. All of that is now unconditionally public, and all of it is now searchable too.
They do more than look for things that are "virus like". At least in the case of Avast!, they now block any application that's new or obscure just in case it might be zero-day malware, and I believe other antivirus companies do the same thing. This means they're 100% effective against new malware at the cost of having a 100% false positive rate on new or exotic software. Doesn't even have to be that obscure either - I've had Avast block a moderately well-known game off Steam because not enough people run it to be sure it's safe.
In pratice, I expect most users either just click "Yes" reflexively or turn off that part of the scanner altogether, so it provides very little actual protection against threats - but it sure looks good in the benchmarks.
Guess there's not much of a market for it. Some of the A10-based boards do have SATA, including the Cubieboard, but not all of them and boards based on other SoC are harder to add SATA support to because there's no support for it on the SoC. (Most of them don't have PCIe support so there's not even anywhere to connect a SATA controller to.)
NAT holepunching only works on NATs that map all UDP traffic coming from the same IP and port within the NAT to have the same source IP and port outside of the NAT, no matter what their destination (so-called full cone or restricted cone NAT). Without this property there's no way for the other system to know what port incoming packets will be coming from, and therefore no way for it to punch the appropriate hole in its own NAT to let them in. NAT on home routers almost always has this property but carrier-grade NAT generally doesn't because there just aren't enough ports available to make it work. So NAT holepunching solutions don't actually work on carrier-grade NAT.
Aren't spark-gap transmitters forbidden by international treaty? I doubt you could find many places that allow them.
The general reckoning over there seems to be that someone's been intentionally removing it from the front page for some weird reason. There have been a whole bunch of posts that have been highly upvoted, most of them just got pulled.
Also, that wouldn't help much anyway - most the barite mined goes to oil and gas drilling, so sooner or later we'd run into problems getting enough new barium for medical purposes to replenish the stuff lost, and reusing the medical barium wouldn't help delay that by much.
The government didn't just charge interest, they also got equity in the company that massively diluted existing shareholders. Effectively, it's as though the government confiscated 90% of every single AIG shareholder's shares in exchange for giving AIG a loan - with interest - that it promptly paid out to other companies that'd basically swindled them. The shareholders might well argue that they'd have been better off if the company had gone insolvent, especially since it had more than enough assets to cover all its liabilities and they'd get the remainder, whereas now their portion of the company has been diluted by Government intervention.
VOIP needs to be low latency, though, otherwise people get confused and try to talk over each other.
Of course, there's no reason to believe that girls are naturally any better than boys at interpersonal stuff, or that boys are naturally better than girls at analyzing problems, but it doesn't matter - the argument works just as well if any gender differences are solely a result of them being socialized to think in different ways.
The X server is full-fat, but the graphics driver is about the most rudimentary X driver there is - no acceleration, no mode setting, just a framebuffer.
You're confused as hell, Bubba. Google for "gold standard". Theoretically, a nation on a gold standard has gold in a vault somewhere that is equal in value to all the currency it has in circulation.
Well yes, that's the problem. There is absolutely no reason why the total value of the economy should have any particular relationship with the total value of all of the gold in existence, which leads to all kinds of fun when the economy expands and you have to somehow convice everyone that gold is now worth more not because it's actually more useful for anything (it isn't) but because we need it to be worth more in order to have enough currency in circulation to support the actual value of the parts of the economy that are genuinely worth more.
With a completely seperate rendering engine with different quirks, too, at least in the case of the Mac version.
From what I can tell, the patch was intended to change the behavior userspace sees from the driver, so it wasn't immediately clear whether this was an intentional change or not. More importantly, it also wasn't clear whether other drivers which Mauro was also responsible for maintaining also behaved in the same way. Mauro provides some context here - basically there are a whole bunch of different webcam drivers which each implement the V4L2 API slightly differently, which means that often applications only work properly with certain webcams. The patch was part of an attempt to clean this up. Linus seems to think that any change to userspace APIs that might break existing applications is wrong and fixing up compatibility is no excuse, so it looks like webcams will remain a mess on Linux for a while...
No. The actual analogy would be if Bill said. "Errrm, hang on, the existing beads which are in equally important structural areas are just as dodgy, should we fix those too" and his boss yelled at him to shut up and stop trying to make excuses, they haven't failed yet so they're fine. Then a few weeks later the whole thing falls down and kills someone because one of the older welds fails.
His argument is that it's a bug with pulseaudio because there are already quite a lot of existing drivers that behave in exactly the same way, and PulseAudio broke here it's already going to be broken with all of them. Subtle difference.
In addition, the MK802 runs the "source available, but developed in secret" Android OS, while the RPi runs the truly open source Debian by default and a zillion other true open source Linux distros with easy download.
That's not quite right. The standard option for RPi these days is Raspbian, which is actually a clone of Debian developed and maintained by Raspberry Pi users. So you don't have the support of al the actual Debian infrastructure like their package archives, download mirrors, etc. Meanwhile the MK802 can run either Ubuntu or Debian (or various other OSes). You need a custom kernel just like on the Pi but nearly everything else is standard Debian/Ubuntu. (Ubuntu can't actually run on the Pi at all because the ARM processor's too old.)