Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror

Comment: The delay is almost certainly on technical grounds (Score 4, Insightful) 194

by Wierdy1024 (#46439821) Attached to: Google Blocking Asus's Android-Windows "Duet"?

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.

Comment: Never host user images on your domain... (Score 3, Insightful) 28

by Wierdy1024 (#46211521) Attached to: Comparing Cloud-Based Image Services For Developers

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...

Comment: "Treat all traffic equally" might be right. (Score 1) 298

by Wierdy1024 (#46174971) Attached to: Is Verizon Already Slowing Netflix Down?

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.

Comment: Re:oh well (Score 1) 385

by Wierdy1024 (#46168455) Attached to: HP To Charge For Service Packs and Firmware For Out-of-Warranty Customers

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.

Comment: Re:oh well (Score 4, Insightful) 385

by Wierdy1024 (#46162151) Attached to: HP To Charge For Service Packs and Firmware For Out-of-Warranty Customers

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.

Comment: Re: Since nobody else here is prividing much help. (Score 1) 365

by Wierdy1024 (#45905231) Attached to: Ask Slashdot: How Many (Electronics) Gates Is That Software Algorithm?

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.

Comment: Since nobody else here is prividing much help... (Score 2) 365

by Wierdy1024 (#45905221) Attached to: Ask Slashdot: How Many (Electronics) Gates Is That Software Algorithm?

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).

Comment: It is possible Google hasnt changed anything (Score 2) 127

by Wierdy1024 (#45676007) Attached to: Google Fixes Credit Card Security Hole, But Snubs Discoverer

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.

If mathematically you end up with the wrong answer, try multiplying by the page number.

Working...