You pay us a $500 bond.

You get it back if you marry someone you *didn't* meet on our dating site, or if you don't marry for 10 years.

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.