Reports are saying the power supply is causing this fault.
That might not be the case. Bright UV light will create electron hole pairs in the gate of transistors turning them all *on*, which will cause the chip to use much much more power since push pull output stages of logic gates will now be shorting the power supply.
Hence, even though it looks like the power supply is failing, it could simply be the power supply is turning off due to overcurrent.
For example, if android is run under a hypervisor that allows 'quick switching' between the OS's, but restricts what android can do or degrades performance, I can see why Google doesn't want to impact the Android brand by releasing something substandard.
If you care about security, you would never host user provided images on your own domain.
Browsers ignore the file extension, and in many cases ignore the mime type when deciding how to process a URL. A malicious user could upload a dodgy swf file, but then rename it.jpg. Then the attacker gets the victim to load the malicious jpg from your domain. The swf can now read your domains cookies (same origin policy) and then return them to the attacker.
Thats why google uses 'Googleusercontent.com'. Most big sites do it. If you care about your users, you would do it too...
You don't have to put special traffic throttling rules in to make the service shoddy. Instead you can simply refuse to upgrade the router connecting your Verizon residential service to Amazon AWS. Since that ancient router is still stuck on a 1Gbit link shared amongst all users, service will suck.
But they can legitimately say "We don't discriminate traffic". Just they do discriminate when deciding which bits of their network to upgrade, and the bit connecting to Amazon isn't being upgraded anytime soon.
If they didn't all happen at once with a software update, probably, yes.
It might be a design fault (ie. whoops you put that chip too near that screw, and they rub on each other and over time the chip eventually falls off), or a manufacturing fault (wrong type of solder used, and as the board expands and contracts, the solder flexes and eventually cracks). But it's probably still a hardware fault.
If HP really cared, they would take back the faulty server, take it to their lab, and remove and test the temperature sensor itself and figure out the *exact* cause of the problem.
Often, those sensors are on the SMI bus (which is (basically) an 8 bit serial bus), and a chip disconnected from the SMI bus returns all binary "1"'s. If they treat that as unsigned, it is 255. If they treat it as sign and magnitude, it's -127.
Either way the problem probably is the chip has been knocked and broken off the motherboard slightly.
Note that these by the way assume you have the engineering time to 'do it properly'. There are lots of ways of making a considerably bigger design, but with much less design effort.
Check out 'Handel c' for example. Its a one click tool that takes C code and produces horribly inefficient hardware, but it works.
First up, most algorithms can't be directly translated to hardware without either changing them or taking a serious performance hit.
Nearly all widespread algorithms (eg. H264 video) are designed specifically with a hardware implementation in mind, and in fact must usually have elements removed that would produce good results simply because it wouldn't be sensible to implement in hardware.
In particular, in hardware, loops that iterate an unknown number of times are generally not allowed.
Steps to make this estimate would probably be to take your code and 'flatten' it (IE. Rewrite it to avoid all use of pointers, except arrays).
For every variable, figure out how many bits wide it needs to be(IE. What is the smallest and largest possible value). You probably want to convert floating point to fixed point.
Next, to make a lower bound of how many gates would be used if you were to design for minimal gate use, take every add and subtract operation and call them 15 gates per bit. For every multiply call it 5 gates per input bit squared. Don't do division (division can be done as a multiplication by the inverse of a number).
For the upper bound, do the same, but multiply by the number of times each loop goes round. That gives you a design with lots more gates but much higher performance.
For the upper bound finally add on 5 gates for every bit of every variable times the number of lines of your input code. This approximates the d type flip flops for storage in a pipeline. Note that if two lines of code operate on entirely different variables, you can call them the same line as far as this metric goes.
For the lower bound, if you got a value greater than 10000 plus 16 times the number of bytes that your program is compiled plus the ram it allocates to run, it would be more gate efficient to put in a tiny processor and keep your algorithm in a ROM. (Lots of complex algorithms are implemented this way when space is at a premium).
Google uses automatic systems to try to detect "abusive" queries. When the system is triggered, you get the message "Our systems have detected unusual traffic from your computer network. Please try your request again later.".
Searching for the same random hex string every day for a week that nobody else in the world has searched for would probably make you stand out from the crowd as some kind of bot. (Bots often use google search looking for random keywords to check for updates to their own code, and the bot-owner can then put the software update anywhere on the internet with the right random keywords and it will be found).
When you have triggered the bot-detect code, it will probably get more sensitive ("look mom, I learned to detect a type of malware, and I'm gonna make sure it never gets through again!").
Hence, I have a suspicion that the entire content of this post could have happened without any interaction on the part of Google Engineers. And if thats the case, they really shouldn't get blamed for screwing over a little guy, but instead praise for making such a smart system that it can detect a little guy doing something evil and block him all automatically.
Thats like saying "If everyone bought their house using pennies, we wouldn't have enough pennies!". 18650 cells are ideal for laptops, but for cars, one uses bigger batteries, for which there is more production volume.
My guess is Glenn Greewald's PC suddenly suffers some corruption and the few most secret pages of those documents mysteriously get corrupted or turn to blank...
Normally obfuscation is bad in cryptography - it means that the system is theoretically broken, but that the way to break it is quite well hidden.
This refers to cryptographically secure obfuscation. This is an entirely new field, and hasn't been possible till now. This paper doesn't prove how to do it, but proves that it is possible for a certain subset of operations.
Basicly it boils down to the fact it is possible to make a computer program that, for a given set of inputs a) generates a set of outputs b) in such a way that it wouldn't be possible to modify the program to make it generate a particular output without doing an exhaustive search (ie. try every possible input).
It's similar in principle to a "designer" hash algorithm - ie. I can choose the output for a given input, but after compilation it will not be possible to find out the mapping without knowing the input.
This type of algorithm could enable things people hate (DRM), but also many other new fields of computing, in particular doing computation on untrusted processors.
Bear in mind, this particular method is just a way to quickly do a large number of convolutions and get statistically fairly accurate results for the most activated convolution kernels.
This isn't incompatible with deep neural network models. This method can be combined with them and provide the same speedup there.
When the BBC implemented this clock, they were pushing forward technology by being the first large website to use HTML5 canvas. Yes, thats right, there is no flash in that clock...
They didn't make a big fanfare about it, they just implemented it.
Now that canvas is widespread, I would prefer they go push other bits of technology forward.
So this tech seems to use doppler shift of signals.
While I am sure some wifi hardware measures doppler shift to try to correct for it and get better reception in moving vehicles, none that I know of makes this info available to the driver, let alone exposes it to any program running on the router/laptop/phone.
This is about right. MLC flash normally is rated for between 1k and 10k cycles. Newer flash is generally less as transistor sizes are shrunk to fit in more gbytes in the same die area.
A home PC will only write a couple of gigs a day under typical workloads, which turns out to about 5 full writes a year for even the small sizes. That would last you 4000 years assuming ideal wear leveling...
Basically, what they're saying is this will be absolutely fine for everything except outgoing mail servers and a few other specialist things.
The capacitor backup and write cache make wear leveling much much easier, since all frequently written to cells can be cached in ram, and only written once on shutdown, and the capacitor backup means even an unclean shutdown will save your data.
Having shipped something once, if your container happens to end up on the top of the ship, it can get _very_ hot.
One of the devices I shipped had a thermometer in, and it got to 83 C (181 F). Lots of things melted, and all the rubber seals became all sticky and useless. Lots of other bits of plastic became hard and cracked. Lots of bottled products either expanded and split or evaporated. Lots of batteries split and broke the things they were in. The shipping company didn't care...
I'd say, make sure you have some kind of data logger in there logging at the very least pressure, temperature, and wetness, and then if they drop your container in the sea you at least know what happened to it...
When someone buys a design from ARM, they buy one of two things:
1. A Hard macro block. This is like an mspaint version of a cpu. it looks just like the photos here. The CPU has been laid out partially by hand by ARM engineers. The buyer must use it exactly as supplied - changing it would be neigh-on impossible. In the software world, it's the equivalent of giving an exe file.
2. Source Code. This can be compiled by the buyer. Most buyers make minor changes, like adjusting the memory controller or caches, or adding custom FPU-like things. They then compile themselves. Most use a standard compiler rather than hand-laying out the stuff, and performance is therefore lower.
The articles assertion that hand layout hasn't been done for years outside intel as far as I know is codswallop. Elements of hand layout, from gate design to designing memory cells and cache blocks have been present in ARM hard blocks since the very first arm processors. Go look in the lobby at ARM HQ in Cambridge UK and you can see the meticulous hand layout of their first cpu, and it's so simple you can see every wire!
Apple has probably collaborated with ARM to get a hand layout done with apples chosen modifications. I can't see anything new or innovative here.
Slashdot Mirror
Reports are saying the power supply is causing this fault.
That might not be the case. Bright UV light will create electron hole pairs in the gate of transistors turning them all *on*, which will cause the chip to use much much more power since push pull output stages of logic gates will now be shorting the power supply.
Hence, even though it looks like the power supply is failing, it could simply be the power supply is turning off due to overcurrent.
Google gets chrome to randomly send back certificates, and they then analyse them.
Yes, the return certs could be modified in transit, or blocked, but that's tricky.
No escaping proprietary firmware now. I would hazard a guess that a laptop purchased today has firmware or firmware libraries from over 1000 teams.
You don't see them, because most are stored in roms and flash, and your OS doesn't need to know about them...
For example, if android is run under a hypervisor that allows 'quick switching' between the OS's, but restricts what android can do or degrades performance, I can see why Google doesn't want to impact the Android brand by releasing something substandard.
If you care about security, you would never host user provided images on your own domain.
Browsers ignore the file extension, and in many cases ignore the mime type when deciding how to process a URL. A malicious user could upload a dodgy swf file, but then rename it .jpg. Then the attacker gets the victim to load the malicious jpg from your domain. The swf can now read your domains cookies (same origin policy) and then return them to the attacker.
Thats why google uses 'Googleusercontent.com'. Most big sites do it. If you care about your users, you would do it too...
You don't have to put special traffic throttling rules in to make the service shoddy. Instead you can simply refuse to upgrade the router connecting your Verizon residential service to Amazon AWS. Since that ancient router is still stuck on a 1Gbit link shared amongst all users, service will suck.
But they can legitimately say "We don't discriminate traffic". Just they do discriminate when deciding which bits of their network to upgrade, and the bit connecting to Amazon isn't being upgraded anytime soon.
And they want you to code without libraries to keep things low-memory and speedy.
That or they're looking for a weak reason to reject your app because they have an internal app which does the same as yours shortly to be released.
If they didn't all happen at once with a software update, probably, yes.
It might be a design fault (ie. whoops you put that chip too near that screw, and they rub on each other and over time the chip eventually falls off), or a manufacturing fault (wrong type of solder used, and as the board expands and contracts, the solder flexes and eventually cracks). But it's probably still a hardware fault.
If HP really cared, they would take back the faulty server, take it to their lab, and remove and test the temperature sensor itself and figure out the *exact* cause of the problem.
To be honest, it probably was a hardware issue...
Often, those sensors are on the SMI bus (which is (basically) an 8 bit serial bus), and a chip disconnected from the SMI bus returns all binary "1"'s. If they treat that as unsigned, it is 255. If they treat it as sign and magnitude, it's -127.
Either way the problem probably is the chip has been knocked and broken off the motherboard slightly.
Note that these by the way assume you have the engineering time to 'do it properly'. There are lots of ways of making a considerably bigger design, but with much less design effort.
Check out 'Handel c' for example. Its a one click tool that takes C code and produces horribly inefficient hardware, but it works.
I shall give it a go.
First up, most algorithms can't be directly translated to hardware without either changing them or taking a serious performance hit.
Nearly all widespread algorithms (eg. H264 video) are designed specifically with a hardware implementation in mind, and in fact must usually have elements removed that would produce good results simply because it wouldn't be sensible to implement in hardware.
In particular, in hardware, loops that iterate an unknown number of times are generally not allowed.
Steps to make this estimate would probably be to take your code and 'flatten' it (IE. Rewrite it to avoid all use of pointers, except arrays).
For every variable, figure out how many bits wide it needs to be(IE. What is the smallest and largest possible value). You probably want to convert floating point to fixed point.
Next, to make a lower bound of how many gates would be used if you were to design for minimal gate use, take every add and subtract operation and call them 15 gates per bit. For every multiply call it 5 gates per input bit squared. Don't do division (division can be done as a multiplication by the inverse of a number).
For the upper bound, do the same, but multiply by the number of times each loop goes round. That gives you a design with lots more gates but much higher performance.
For the upper bound finally add on 5 gates for every bit of every variable times the number of lines of your input code. This approximates the d type flip flops for storage in a pipeline. Note that if two lines of code operate on entirely different variables, you can call them the same line as far as this metric goes.
For the lower bound, if you got a value greater than 10000 plus 16 times the number of bytes that your program is compiled plus the ram it allocates to run, it would be more gate efficient to put in a tiny processor and keep your algorithm in a ROM. (Lots of complex algorithms are implemented this way when space is at a premium).
Want your own currency. Look no further:
http://coingen.io/
Google uses automatic systems to try to detect "abusive" queries. When the system is triggered, you get the message "Our systems have detected unusual traffic from your computer network. Please try your request again later.".
Searching for the same random hex string every day for a week that nobody else in the world has searched for would probably make you stand out from the crowd as some kind of bot. (Bots often use google search looking for random keywords to check for updates to their own code, and the bot-owner can then put the software update anywhere on the internet with the right random keywords and it will be found).
When you have triggered the bot-detect code, it will probably get more sensitive ("look mom, I learned to detect a type of malware, and I'm gonna make sure it never gets through again!").
Hence, I have a suspicion that the entire content of this post could have happened without any interaction on the part of Google Engineers. And if thats the case, they really shouldn't get blamed for screwing over a little guy, but instead praise for making such a smart system that it can detect a little guy doing something evil and block him all automatically.
18650 cells?
Thats like saying "If everyone bought their house using pennies, we wouldn't have enough pennies!". 18650 cells are ideal for laptops, but for cars, one uses bigger batteries, for which there is more production volume.
My guess is Glenn Greewald's PC suddenly suffers some corruption and the few most secret pages of those documents mysteriously get corrupted or turn to blank...
My mistake - it is in http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state.cc?revision=107993&view=markup&pathrev=107993
and only enabled for google, twitter, tor, and a handful of other sites.
I believe functionality like this is already in HSTS and already used by google and chrome
Normally obfuscation is bad in cryptography - it means that the system is theoretically broken, but that the way to break it is quite well hidden.
This refers to cryptographically secure obfuscation. This is an entirely new field, and hasn't been possible till now. This paper doesn't prove how to do it, but proves that it is possible for a certain subset of operations.
Basicly it boils down to the fact it is possible to make a computer program that, for a given set of inputs a) generates a set of outputs b) in such a way that it wouldn't be possible to modify the program to make it generate a particular output without doing an exhaustive search (ie. try every possible input).
It's similar in principle to a "designer" hash algorithm - ie. I can choose the output for a given input, but after compilation it will not be possible to find out the mapping without knowing the input.
This type of algorithm could enable things people hate (DRM), but also many other new fields of computing, in particular doing computation on untrusted processors.
You know a "simple XOR" of the data with a one time pad key is theoretically unbreakable...
What matters is how you generate the keystream, not how you apply it to the data.
Bear in mind, this particular method is just a way to quickly do a large number of convolutions and get statistically fairly accurate results for the most activated convolution kernels.
This isn't incompatible with deep neural network models. This method can be combined with them and provide the same speedup there.
When the BBC implemented this clock, they were pushing forward technology by being the first large website to use HTML5 canvas. Yes, thats right, there is no flash in that clock...
They didn't make a big fanfare about it, they just implemented it.
Now that canvas is widespread, I would prefer they go push other bits of technology forward.
So this tech seems to use doppler shift of signals.
While I am sure some wifi hardware measures doppler shift to try to correct for it and get better reception in moving vehicles, none that I know of makes this info available to the driver, let alone exposes it to any program running on the router/laptop/phone.
So how does this work?
This is about right. MLC flash normally is rated for between 1k and 10k cycles. Newer flash is generally less as transistor sizes are shrunk to fit in more gbytes in the same die area.
A home PC will only write a couple of gigs a day under typical workloads, which turns out to about 5 full writes a year for even the small sizes. That would last you 4000 years assuming ideal wear leveling...
Basically, what they're saying is this will be absolutely fine for everything except outgoing mail servers and a few other specialist things.
The capacitor backup and write cache make wear leveling much much easier, since all frequently written to cells can be cached in ram, and only written once on shutdown, and the capacitor backup means even an unclean shutdown will save your data.
Having shipped something once, if your container happens to end up on the top of the ship, it can get _very_ hot.
One of the devices I shipped had a thermometer in, and it got to 83 C (181 F). Lots of things melted, and all the rubber seals became all sticky and useless. Lots of other bits of plastic became hard and cracked. Lots of bottled products either expanded and split or evaporated. Lots of batteries split and broke the things they were in. The shipping company didn't care...
I'd say, make sure you have some kind of data logger in there logging at the very least pressure, temperature, and wetness, and then if they drop your container in the sea you at least know what happened to it...
When someone buys a design from ARM, they buy one of two things:
1. A Hard macro block. This is like an mspaint version of a cpu. it looks just like the photos here. The CPU has been laid out partially by hand by ARM engineers. The buyer must use it exactly as supplied - changing it would be neigh-on impossible. In the software world, it's the equivalent of giving an exe file.
2. Source Code. This can be compiled by the buyer. Most buyers make minor changes, like adjusting the memory controller or caches, or adding custom FPU-like things. They then compile themselves. Most use a standard compiler rather than hand-laying out the stuff, and performance is therefore lower.
The articles assertion that hand layout hasn't been done for years outside intel as far as I know is codswallop. Elements of hand layout, from gate design to designing memory cells and cache blocks have been present in ARM hard blocks since the very first arm processors. Go look in the lobby at ARM HQ in Cambridge UK and you can see the meticulous hand layout of their first cpu, and it's so simple you can see every wire!
Apple has probably collaborated with ARM to get a hand layout done with apples chosen modifications. I can't see anything new or innovative here.
Evidence: http://www.arm.com/images/A9-osprey-hres.jpg (this is a layout for an ARM Cortex A9)