Anything under 12V is undervolted. As it happens, I'm using a different undervolting adapter than the one provided with the unit for space and asthetics reasons.
Well done. I'm lamenting the fact that, due to a desire to play Oblivion, I now have two fans in my system instead of one. (The system fan is undervolted Nexus 120 mm - very quite. I've replaced the heatsink on my 6600GT GPU with a Zalman VF700 and undervolted the fan, but its still the loudest thing in my system. Previous GPU used a passive Zalman heatsink.)
It is good to have people like you around - it makes me feel that I'm not obsessive.:-)
Well done, and thank you. I acknowledge your claim for a lunch.
I was aware of the extra newlines um, "suboptimal feature" and I appreciate the fix. (Version 1 has a different suboptimal feature: it gives each solution (10-n)! times, where n is the number of unique characters in the problem.)
I accept the dropping of "\d" as legitimate.
Unfortunately, Finland is a very long way from me, and your trip will take you even further. (You're getting closer to Spain, which is antipodial to me.) If you wish to persue your claim for a later date, should one of us travel half way around the world, send me e-mail. My work account name is m.d.woodhams and I work at massey.ac.nz.
If you just want to get the byte count down at the expense of readability (as I have done) there are a few obvious tricks to apply: "foreach" and "for" are synonymous. (8 bytes in your example) for/foreach loops can sometimes be made shorter with "map" (Useful with, e.g. "1..10" which returns a list of numbers 1 to 10.) You can replace "\n" with quotes around a real newline (one byte) Don't put in any newlines anywhere except where they are used directly (as above) or whitespace is syntactically needed. (Often leads to horribly long lines) (3 bytes in your example) Consider the ternary conditional (condition?result1:result2) and || and && operators to replace "if" statements. Eliminate parenthesis around argument lists wherever possible. Use $_, @_ default arguments lots. Use multiple assignments ($a=$b=$c=0).
One extreme action I've seen (a very compressed deCSS in Perl): where you have sufficiently repetitive bits of code (e.g. you use "print" 10 times) put your code into a string, replace the repetitive code with a single char, do a substitution and exec it. A trivial (and inefficient) example: $_='p"hello world\n"';s/p/print/;exec
I just noticed that some/. comment preprocessing mangled a bit of version 1. Here is the correct last line with extra whitespace around &&: ",eval"y,$a,@_,",/\b0/)||eval && print;pop}a
No, there is a newline in the string. I could have written $_="$b\n" except I used a real newline instead of \n to save a byte. (None of the newlines in either version are optional, although in one case any whitespace char would do.)
They are brute-force alphametics solvers. Save either into a file (say "s") then: $ perl s send+more==money 9567+1085==10652 9567+1085==10652
If anyone can shorten either of these programs (even by one byte) please let me know. If you do, and you're geographically close enough, I'll buy you lunch. (Watch for bugs with numbers with leading zeros.)
Version 1 is 133 bytes, version 2 is 103 bytes. Version 1 is almost entirely my own work, and contains a nifty recursive permutation generator. Version 2 was produced by someone else in response to my challenge, and then further compressed a bit by me.
Unfortunately, the Obfuscated Perl Contest has disappeared (although these are principally compressed rather than obfuscated.)
The fine article appears slashdotted, so I don't know if they cover this. The application which leaps to my mind for this detector is astronomy. Astronomers will pay big money for a better detector - I've seen a US$200k chip (2k x 2k pixels in about 1990, for use in the Sloan Digital Sky Survey camera.) Even at these prices, it is cheaper to get the same quality upgrade by improving your detector than by building a bigger telescope.
Astronomers run their CCDs at liquid nitrogen temperatures (to reduce thermal noise), and for UV astronomy they use "thinned" chips (etch/grind away the back of the chip so you can illuminate it from that side - otherwise too many photons are lost before reaching the light sensitive volume.) I'm not sure what other features astronomical CCDs require which might not be present in this chip. Pixel size shouldn't matter too much (except in its effect on noise) as you can design your camera to scale the image to suit the detector.
I'd definitely rather see my tax dollars spent on a project to deter meteorites as opposed to seeing money thrown around with people crying "Al Qaeda" anytime.
Me too, but Imagine if what hit the moon hit a major city...
First, as others have pointed out, it wouldn't reach the ground. Second, we're talking about an explosion of 4 tonnes of TNT. I'm not greatly familiar with bomb sizes, but I think this is a few large conventional bomb, a large car bomb or small truck bomb. Unless the aim was unlucky, you're only talking a few casualties. Third, no proposed anti-meteorite system would detect anything this small, by a few orders of magnitude.
The cargo door was not a minor oversight. The failure had occured in pre-flight testing, and an engineer wrote a memo to say that if the design went into production, there would be a failure in flight which would almost certainly crash the airplane. Then there really was a failure in flight, but due to lucky circumstances and exceptional airmanship, the plane was saved. ("The Windsor Incident") Then McD made un utterly inadequate fix, in which the safety of the plane depended on a baggage handler (probably a minimum wage worker) looking through some small windows and correctly interpreting what they saw.
Only after 346 people died near Paris did it get fixed properly.
(The situation was not helped by a Nixon appointed head of the FAA who had a "business knows best" ideology. The FAA did not force a proper fix prior to the Paris crash, despite the NTSB pleading for it.)
The P150 drive cage can take 4 drives screwed in, or 3 drives with elastic band suspension. This is what I was thinking of.
I don't have a P180 or P150, but when I went from screws-with-rubber-grommets to home-brewed-elastic-suspension mounting, the difference was substantial. (But only if you've already aggresively silenced the rest of your system.) Possibly the P180 has better rubber grommets than I had.
Unless I was building some ~US$3000 SLI monstrosity*, I'd go for the P150 instead. It is quite a bit smaller, and has hard-drive suspension (for noise suppression) as a built in option.
* I.e. something that actually *needs* a >300W power supply, unlike 95%** of the computers fitted with >500W PSUs.
"He programmed RFDump with the ability to place cookies on RFID tags the same way Web sites put cookies on browsers to track returning customers. With this, a stalker could, say, place a cookie on his target's E-ZPass, then return to it a few days later to see which toll plazas the car had crossed (and when). Private citizens and the government could likewise place cookies on library books to monitor who's checking them out."
This makes no sense. Either he has to get access to the library/E-ZPass data (in which case no cookie is needed) or the library needs to be writing to the tag - which it doesn't do.
Can anyone invert the ignorant-reporter-transform which has been applied to this paragraph?
* Basic hardware - e.g. the difference between RAM, hard drive, optical disk. Open a computer and talk to them about the main bits. * OS - what does an OS do, why are there many of them (including versions of Windows), what is and is not compatable between OSs. Admin and user accounts. * Upgrades. How to install new software or (simple) hardware. How does your OS react when it detects new hardware. * Filesystems - how to use folders, distinction between data and application, how the OS knows which application to use on which file. Backup. What to do when you run out of disk space. * Network - ways of connecting your computer (modems, ethernet, wireless), configuring to connect to your ISP, using network resources (printers, non-local disk) * Malware and scams. Virus protection and recovery, trojan avoidance, phishing, rich Nigerian widows. * Major internet resouces - Google, Wikipedia etc. Search engine technique. * E-mail netequette. (Don't send a 50Mb file to dial-up user. Don't propagate bogus virus warnings. Craig Sherman has enough postcards.) * The most basic software packages - e-mail, browser, word processor, possibly calendar, spreadsheet, presentation, media player (depending on the audience.)
Back-of-the-envelope: Assume 100W difference per server, when active, no difference when idle, and active 50% of the time means 50W per server average. 2000 servers = 100KW difference in total draw. Wild guess electricity costs $0.10/KWhr (I'm in a different country and don't get commercial pricing) so that is $10/hr. *24*365 = $88000/yr. I haven't taken into account the airconditioning to get rid of this heat - say electricity plus capital for airconditioning is about half as much again, so around $130,000/yr, or $400,000 over 3 years. That is about $200 per server. (But, unlike hardware costs, it is spread over 3 years rather than up-front.)
Would anyone care to repeat the calculation with less wild guessing?
From the fine article: "The scientists also identified 4,500 new SNPs -- single nucleotide polymorphisms -- which are the variations in human DNA that make people unique."
There are other variations which make us unique. Alternate alleles* Indels (insertions/deletions) Variable numbers of repeats.*
The genetic code uses 4 letters, but I'll use English for explaination. A SNP is a single letter which has different values in different individuals: "The cat and the dog" vs "the hat and the dog". An indel is where letters have been inserted into one sequence or deleted from another (without additional data, we can't distinguish these possibilities.) "The cat and the dog" vs "the cat and the big dog". In alternate alleles there are a bunch of changes which always stick together, e.g. we observe "the cat and the big dog" and "the cat and the small mouse", but never (or exceedingly rarely) "the cat and the big mouse" or "the cat and the small dog." Variable repeats are a special case of indels, but common enough to warrant a category of their own. "The cat and and and the dog" vs "the cat and and and and and the dog".
This is worthwile research, but it seems well short of supporting the claim that dolphins are using names. My summary would be that each dolphin has a signature call, they react to the signature calls of friends/relations, and (the new bit in this research) they react to calls which are similar but not identical to the signature calls of friends/relations.
To support a claim of using names, I'd want evidence of dolphin Alice vocalizing dolphin Bob's signature call to gain Bob's attention.
I suppose it comes down to an argument about what constitutes a "name". But the small step from the reacting to signature calls to the reacting to sythesized signature calls seems a strange place to draw the line between "name" and "not name".
It sounds easy to defeat to me. The proxies will have a distinctive profile in traffic analysis: * Communicates on port 443 (SSL) * Only a few Chinese computers ever connect to the foreign proxy * Those that do connect, tend to do so extensively.
So the Chinese see this pattern and block the proxy or worse.
As an alternative countermeasure, would it be feasible for the Great Wall to act as a man-in-the-middle on all SSL connections which cross it?
Slashdot Mirror
Anything under 12V is undervolted. As it happens, I'm using a different undervolting adapter than the one provided with the unit for space and asthetics reasons.
Well done. I'm lamenting the fact that, due to a desire to play Oblivion, I now have two fans in my system instead of one. (The system fan is undervolted Nexus 120 mm - very quite. I've replaced the heatsink on my 6600GT GPU with a Zalman VF700 and undervolted the fan, but its still the loudest thing in my system. Previous GPU used a passive Zalman heatsink.)
:-)
It is good to have people like you around - it makes me feel that I'm not obsessive.
I was going to say that.
One good place to look for people's experiences with these cards is the Silent PC Review GPU forum.
Well done, and thank you. I acknowledge your claim for a lunch.
I was aware of the extra newlines um, "suboptimal feature" and I appreciate the fix. (Version 1 has a different suboptimal feature: it gives each solution (10-n)! times, where n is the number of unique characters in the problem.)
I accept the dropping of "\d" as legitimate.
Unfortunately, Finland is a very long way from me, and your trip will take you even further. (You're getting closer to Spain, which is antipodial to me.) If you wish to persue your claim for a later date, should one of us travel half way around the world, send me e-mail. My work account name is m.d.woodhams and I work at massey.ac.nz.
If you just want to get the byte count down at the expense of readability (as I have done) there are a few obvious tricks to apply:
"foreach" and "for" are synonymous. (8 bytes in your example)
for/foreach loops can sometimes be made shorter with "map" (Useful with, e.g. "1..10" which returns a list of numbers 1 to 10.)
You can replace "\n" with quotes around a real newline (one byte)
Don't put in any newlines anywhere except where they are used directly (as above) or whitespace is syntactically needed. (Often leads to horribly long lines) (3 bytes in your example)
Consider the ternary conditional (condition?result1:result2) and || and && operators to replace "if" statements.
Eliminate parenthesis around argument lists wherever possible.
Use $_, @_ default arguments lots.
Use multiple assignments ($a=$b=$c=0).
One extreme action I've seen (a very compressed deCSS in Perl): where you have sufficiently repetitive bits of code (e.g. you use "print" 10 times) put your code into a string, replace the repetitive code with a single char, do a substitution and exec it. A trivial (and inefficient) example:
$_='p"hello world\n"';s/p/print/;exec
I just noticed that some /. comment preprocessing mangled a bit of version 1. Here is the correct last line with extra whitespace around &&:
",eval"y,$a,@_,",/\b0/)||eval && print;pop}a
No, there is a newline in the string. I could have written
$_="$b\n"
except I used a real newline instead of \n to save a byte. (None of the newlines in either version are optional, although in one case any whitespace char would do.)
They are brute-force alphametics solvers. Save either into a file (say "s") then:
$ perl s send+more==money
9567+1085==10652
9567+1085==10652
If anyone can shorten either of these programs (even by one byte) please let me know. If you do, and you're geographically close enough, I'll buy you lunch. (Watch for bugs with numbers with leading zeros.)
Version 1 is 133 bytes, version 2 is 103 bytes. Version 1 is almost entirely my own work, and contains a nifty recursive permutation generator. Version 2 was produced by someone else in response to my challenge, and then further compressed a bit by me.
Unfortunately, the Obfuscated Perl Contest has disappeared (although these are principally compressed rather than obfuscated.)
Version 1:
g ;$a!~/$_/&&push@ARGV,"$t
@a{($b=pop)=~/\w/g}=@a=0..9;$a="@{[keys%a]}";sub
a{@a?map@a=(a(@_,pop@a),@a),1..@a:($_="$b
",eval"y,$a,@_,",/\b0/)||eval&pop}a
Version 2:
while($_=$a=pop){/([a-z])/i?map{($t=$a)=~s/$1/$_/
"}0..9:/\b0\d/||eval&&print}
They do the same thing. I'll post what that is in a follow-up, for the sake of any masochists who want to figure it out for themselves.
Kent doesn't exactly have an "image". They are just another college in the Midwest that no one cares about.
They most certainly do have an image. It won a Pulitzer Prize in 1971.
The fine article appears slashdotted, so I don't know if they cover this. The application which leaps to my mind for this detector is astronomy. Astronomers will pay big money for a better detector - I've seen a US$200k chip (2k x 2k pixels in about 1990, for use in the Sloan Digital Sky Survey camera.) Even at these prices, it is cheaper to get the same quality upgrade by improving your detector than by building a bigger telescope.
Astronomers run their CCDs at liquid nitrogen temperatures (to reduce thermal noise), and for UV astronomy they use "thinned" chips (etch/grind away the back of the chip so you can illuminate it from that side - otherwise too many photons are lost before reaching the light sensitive volume.) I'm not sure what other features astronomical CCDs require which might not be present in this chip. Pixel size shouldn't matter too much (except in its effect on noise) as you can design your camera to scale the image to suit the detector.
I'd definitely rather see my tax dollars spent on a project to deter meteorites as opposed to seeing money thrown around with people crying "Al Qaeda" anytime.
Me too, but
Imagine if what hit the moon hit a major city...
First, as others have pointed out, it wouldn't reach the ground.
Second, we're talking about an explosion of 4 tonnes of TNT. I'm not greatly familiar with bomb sizes, but I think this is a few large conventional bomb, a large car bomb or small truck bomb. Unless the aim was unlucky, you're only talking a few casualties.
Third, no proposed anti-meteorite system would detect anything this small, by a few orders of magnitude.
The cargo door was not a minor oversight. The failure had occured in pre-flight testing, and an engineer wrote a memo to say that if the design went into production, there would be a failure in flight which would almost certainly crash the airplane. Then there really was a failure in flight, but due to lucky circumstances and exceptional airmanship, the plane was saved. ("The Windsor Incident") Then McD made un utterly inadequate fix, in which the safety of the plane depended on a baggage handler (probably a minimum wage worker) looking through some small windows and correctly interpreting what they saw.
Only after 346 people died near Paris did it get fixed properly.
(The situation was not helped by a Nixon appointed head of the FAA who had a "business knows best" ideology. The FAA did not force a proper fix prior to the Paris crash, despite the NTSB pleading for it.)
The P150 drive cage can take 4 drives screwed in, or 3 drives with elastic band suspension. This is what I was thinking of.
I don't have a P180 or P150, but when I went from screws-with-rubber-grommets to home-brewed-elastic-suspension mounting, the difference was substantial. (But only if you've already aggresively silenced the rest of your system.) Possibly the P180 has better rubber grommets than I had.
Unless I was building some ~US$3000 SLI monstrosity*, I'd go for the P150 instead. It is quite a bit smaller, and has hard-drive suspension (for noise suppression) as a built in option.
* I.e. something that actually *needs* a >300W power supply, unlike 95%** of the computers fitted with >500W PSUs.
** 43.8% of statistics are just made up.
Noise
Ease of access to internals
Size
Durability
Upgradability
Appearance
Weight
Portability
Ability to cool high power internals
All these are heavily influenced by your case. Also, a good case takes about twice as long to become obsolete as your internal hardware.
The above list is my particular order of priority. I care alot about choice of case, yet appearance is well down my list.
"He programmed RFDump with the ability to place cookies on RFID tags the same way Web sites put cookies on browsers to track returning customers. With this, a stalker could, say, place a cookie on his target's E-ZPass, then return to it a few days later to see which toll plazas the car had crossed (and when). Private citizens and the government could likewise place cookies on library books to monitor who's checking them out."
This makes no sense. Either he has to get access to the library/E-ZPass data (in which case no cookie is needed) or the library needs to be writing to the tag - which it doesn't do.
Can anyone invert the ignorant-reporter-transform which has been applied to this paragraph?
* Basic hardware - e.g. the difference between RAM, hard drive, optical disk. Open a computer and talk to them about the main bits.
* OS - what does an OS do, why are there many of them (including versions of Windows), what is and is not compatable between OSs. Admin and user accounts.
* Upgrades. How to install new software or (simple) hardware. How does your OS react when it detects new hardware.
* Filesystems - how to use folders, distinction between data and application, how the OS knows which application to use on which file. Backup. What to do when you run out of disk space.
* Network - ways of connecting your computer (modems, ethernet, wireless), configuring to connect to your ISP, using network resources (printers, non-local disk)
* Malware and scams. Virus protection and recovery, trojan avoidance, phishing, rich Nigerian widows.
* Major internet resouces - Google, Wikipedia etc. Search engine technique.
* E-mail netequette. (Don't send a 50Mb file to dial-up user. Don't propagate bogus virus warnings. Craig Sherman has enough postcards.)
* The most basic software packages - e-mail, browser, word processor, possibly calendar, spreadsheet, presentation, media player (depending on the audience.)
That was my thought to.
Back-of-the-envelope:
Assume 100W difference per server, when active, no difference when idle, and active 50% of the time means 50W per server average. 2000 servers = 100KW difference in total draw. Wild guess electricity costs $0.10/KWhr (I'm in a different country and don't get commercial pricing) so that is $10/hr. *24*365 = $88000/yr. I haven't taken into account the airconditioning to get rid of this heat - say electricity plus capital for airconditioning is about half as much again, so around $130,000/yr, or $400,000 over 3 years. That is about $200 per server. (But, unlike hardware costs, it is spread over 3 years rather than up-front.)
Would anyone care to repeat the calculation with less wild guessing?
I was unaware of that - thanks.
There are also pathological cases, such as an extra copy of a chromosome (e.g. Down syndrome.)
From the fine article:
"The scientists also identified 4,500 new SNPs -- single nucleotide polymorphisms -- which are the variations in human DNA that make people unique."
There are other variations which make us unique.
Alternate alleles*
Indels (insertions/deletions)
Variable numbers of repeats.*
The genetic code uses 4 letters, but I'll use English for explaination.
A SNP is a single letter which has different values in different individuals: "The cat and the dog" vs "the hat and the dog".
An indel is where letters have been inserted into one sequence or deleted from another (without additional data, we can't distinguish these possibilities.)
"The cat and the dog" vs "the cat and the big dog".
In alternate alleles there are a bunch of changes which always stick together, e.g. we observe "the cat and the big dog" and "the cat and the small mouse", but never (or exceedingly rarely) "the cat and the big mouse" or "the cat and the small dog."
Variable repeats are a special case of indels, but common enough to warrant a category of their own. "The cat and and and the dog" vs "the cat and and and and and the dog".
Commercial fusion power generation is 20 years from fruition. This has been the state of affairs for the last 50 years, and likely always will be.
By comparison, BPL is maturing much faster - all the timescales are a tenth of those for fusion.
This is worthwile research, but it seems well short of supporting the claim that dolphins are using names. My summary would be that each dolphin has a signature call, they react to the signature calls of friends/relations, and (the new bit in this research) they react to calls which are similar but not identical to the signature calls of friends/relations.
To support a claim of using names, I'd want evidence of dolphin Alice vocalizing dolphin Bob's signature call to gain Bob's attention.
I suppose it comes down to an argument about what constitutes a "name". But the small step from the reacting to signature calls to the reacting to sythesized signature calls seems a strange place to draw the line between "name" and "not name".
Note that in this case the man in the middle doesn't really need to hide their presence.
It sounds easy to defeat to me. The proxies will have a distinctive profile in traffic analysis:
* Communicates on port 443 (SSL)
* Only a few Chinese computers ever connect to the foreign proxy
* Those that do connect, tend to do so extensively.
So the Chinese see this pattern and block the proxy or worse.
As an alternative countermeasure, would it be feasible for the Great Wall to act as a man-in-the-middle on all SSL connections which cross it?