He has sort of a point there, if you ask me. If you are the type who only uses their laptop plugged into something, a new iMac is almost a reasonable substitute. All the power of a modern desktop with a bit more portability than a modern desktop. Just allow someone to pop off the base for easier transportation, make a bag that's a little bigger with space for your keyboard and mouse, and you've got something you can drag to your hotel room whenever you're on a business trip.
Home-schooling seems to be a better and better idea all of the time, as long as someone is able to take off time from work to look after the kids. The only problems I've seen are finding good textbooks to work from, as most of the home-schooling texts out there tend to be from a conservative Christian point of view. So if you're interested in teaching your child evolution, it's going to be a bit more difficult to do so than it would otherwise be.
"In the beginning, the gods created the Heavens and the Earth." The difficulty in properly translating the Bible is that you have to maintain orthodoxy in addition to keeping the general meaning the same. I gave about as close of a translation of the first line of Bereshit (Which translates roughly to "in the beginning") as most scholars would agree upon, but if you noticed, the original Hebrew really refers to the gods in the plural. This, according to church teachings refers to the three parts of the one God, and not some pantheon.
A machine translator, no matter how sophisticated isn't going to be able to perform the secondary purpose of any translation of the Bible, which is to help support the translator's opinions and views on the Bible. If you want to cement the Bible as the plain and infallible source of all church teachings (some Protestant groups), yous translation is going to look profoundly different than one which shows the Bible as a mysterious and sometimes opaque text that sometimes requires training to understand its mysteries (the Catholic Church's official position).
In GPUs, they don't have multiple cores, per se, but they do have multiple rendering pipelines. Modern graphics cards can have anywhere from 1-16 pipelines, with each pipeline doing one pixel at a time, as long as RAM is sufficient. Each pipeline is like a core, but not exactly; a core can run its own instructions on its own data, while a pipeline runs the same instructions as all the other pipelines do. In computer architecture, a plain old CPU is single-instruction-single-data (SISD), a multicore chip is multi-instruction-multi-data (MIMD), and a GPU is single-instruction-multi-data (SIMD). Mixing things up is the fact that after the Pentium MMX, all Pentiums are capable of doing SIMD on integer arrays, but can't do it on floating point numbers. (In fact, IIRC they can't even do regular floating-point math at the same time they are using the SIMD instructions)
Multiple pipelines at a time allows you to increase the rendering speed almost linearly, as long as you accept the trivial restriction that you must get the same image as an output no matter what order you render the pixels in. It's the opposite of the CPU business. In CPUs, they started adding multiple chips first, and in the GPU side of things, they added multiple cores (or their equivalent) first. This is partly because it's easier to only decode one instruction at a time and send the decoded signal to every pipeline than it is to decode multiple instructions and send them to the correct cores. This isn't to say that it's impossible, but a couple million more transistors are enough to make you think twice about whether you really want two cores.
They can probably increase the efficiency and the size, but you probably wouldn't want anything too large, unless you could turn it off. There are 4184 joules per food Calorie, so one of these cells would burn one joule every 5000 seconds, or a Calorie every ~240 days. Now, crank it up to 20 watts, and you've got 20 joules per second, or one Calorie about every 210 seconds. That's 410 Calories a day, and certainly enough to change your diet.
Well, you can slow it down and make things much more difficult, but it's not impossible. The words that you've typed are close to the words that you meant to type. But what's close? Any string of finite length can be transformed into any other string of finite length by adding, subtracting, and substituting characters. Two strings have a distance defined by the minimum number of additions, subtractions and substitutions that it takes to transform one into the other. This is called the Levenshtein distance, or for those who can't pronounce it, the edit distance. It's incidentally how most spellcheckers work, and if you run your text through one, it will be more readable by just about everyone. Now, consider using a SOM, or self-organizing map, a type of neural network. It can classify similar objects into single groups most similar to eachother. You can use this to find instances of possible manglings of uranium, plutonium, and most other words, given a large enough sample. Incidentally, just running your post through a spellchecker (Thunderbird's) and picking the default options on everything made the phrase 'dirty bombs' appear normally. So, it helps, but it's not perfect.
Better filtering has to be on the network level, so that individuals don't have to opt in. The people who know how to set up effective filtering won't likely buy anything from spamvertisers in the first place, meaning that, while it makes those peoples' lives easier, it doesn't affect the spammers' bottom line much.
I mean, really? Every time they find a new one, the things just keep getting smaller. What's next, a piece of ejecta from another moon the size and shape of a '74 Chevy Impala? Might as well start naming the debris in the rings.
This seems to be part of a long line of great ideas where we push the risks towards the bottom while keeping the reward distribution the same. Frankly recent college graduates can move back into their parents' houses, but it doesn't take much for that to happen. Paul Graham said that it's possible to start a company for $10,000, and get rich off of it. If the recent grad fails to do so, or even to recoup the costs, then they're likely completely out of money, and if their parents won't let them move back in, they're on the street. On the other hand, an established programmer can just keep his old car an extra 5 years and be able to take time off on a project and if it doesn't work out, they've at least got experience from an old job helping them get a new one. A major company would be best capable of handling the risk, with a one-person project setting them back aa miniscule amount a year with a possibility for much greater returns.
Hence, it would seem logical to encourage the largest players to take risks, since they can not only manage the risk, but can best press the advantage. But we've got the current system where Microsoft is just sitting on piles of cash, and recent undergrads and grad students are risking their life savings to innovate. Frankly something is screwed up here.
Any schmuck can make a HashMap, but getting it so that you can take a HashMap from your VM, serialize it, send it to another VM, and then it read it without the values changing around is nontrivial unless you can use the same source code as the other person. As far as the open documentation we've got says, it magically creates a hash value for every object, and every object is magically turned into a serialized form, with the JVM turning them back just as magically. "It just happens." is not really helpful for making a new binary-compatible system.
When someone says that you should think carefully about what you already did, then they really don't care if you think about it at all as long as you come to the 'correct' conclusion, which is that you should never break compatibility, ever, unless you're the leading OS manufacturer.
The thing I found that made making orthogonal functions easier was to take a page from Lisp's playbook. No function should have any side effects other than what it absolutely must, and if it does, that should be obvious from the function name, like closePrintStream(). If you find yourself unable to name the function from its side-effect, there's likely some problem hidden within the design. That means that each function should have at most one side effect. Furthermore, label all functions that call functions that have a side effect, even if it seems trivial. This extends to methods of objects, of course, and try to avoid side effects traveling over object boundaries, and for the love of God, don't have two different objects trying to handle the same responsibility at the same time! If object foo opens a file to read, then object bar had better not be able to close it, or even read from it without opening that file itself (after foo is finished, of course). It's better to do the right thing slowly than the wrong thing fast.
Conversion factors and significant digits
on
Exploding Toads
·
· Score: 2, Insightful
Yanno, mentioning that the guts were propelled 3.2 feet into the air sounds kinda like someone had nothing better to do than to measure the size of the splats with more precision than most people would consider sane. Now, I've had my suspicions about the Germans, but this is worse than anything I've previously read.
I wouldn't trust that Fermat really had a proof, much less one under 150 pages. He was a smart guy, but he's gotten a reputation for saying something is solved when it isn't. For instance, take the numbers 2**2**n+1. The first few are prime, so he threw in the towel after 65537 and said the whole damn lot is prime. Unfortunately, we haven't found one Fermat prime past the ones he listed, and some people have wondered if he found all of them. Looking at it a different way, after he formulated his 'proof', he wrote several proofs for specific cases of n=3,4,5.... This is like coming up with an elegant proof of the Pythagorean Theorem for n dimensions (not tough) and then going on to publish a different proof for the two-dimensional case. What's the point? I'm guessing that he finished with the book, thought about it for a bit, saw a gaping flaw in his 'proof' and didn't bother to go back and rescrawl his marginalia.
If there's one thing that mathematicians like, it's generalizing proofs to as wide of an area as possible. If a proof hasn't been generalized as much as humanly possible, it's a very good sign that the author of the proof couldn't come up with a way to make it more general. One thing to remember in math is even if it sounds simple, there's no gurarantee that it is simple. For instance, given an interval (a,b) tell how many prime numbers are within that interval. Trivial to state, but computationally nasty to say the least. There's an 'obvious' solution, to count up all of the prime numbers between the two, but if you're looking for something elegant, sorry but it isn't there, that we really know of.
There are two types of theorems. Trivial and unproven. The proof of the Shimura-Taniyama conjecture (now theorem) is trivial since it's been done. Given enough time, I know a few math profs who might dump one of those on a Sophomore level Proof Structures class.
If you've got a computer in your car, you'd only want it to run when the car's alternator is running, for obvious reasons, so it only starts when the engine is cranked. Waiting a couple of minutes just to play some music shows why you would want a quick boot time. In fact, if you've got the OS itself on flash, booting in a couple of seconds would be the best case scenario, IMO.
I open it in a new tab, post as quickly as possible, and then close the tab, just like everyone else. I don't even have to let it render, I just close it without even lookingl. You should try it.
Re:Computing a hash requires reading every byte
on
SHA-1 Broken
·
· Score: 1
Well, yeah, now that you mention it, you only need to twiddle a couple thousand bytes at the end to possibly change the hash, and you can do things much quicker. I really should stop posting as stream-of-consciousness, but the things you'll do to hit 50 karma... OK, having looked through everything more thoroughly, you can do it in a very small fraction of a second by your method. However, I was a bit wrong about how quickly their method works. It requires 2^69 attempts, on average, compared to my altogether too low 2^32. So, if it takes maybe a tad less than 2ms to calculate a hash (2^-9 s), then you'd need about 2^60 CPU seconds to crack a hash like that. Any password that is more vulnerable to an attack on the SHA-1 hashing algorithm than to just guessing the damn thing is indistinguishable from line noise. (Unfortunately too long for a sig, dammit)
Re:Damn it
on
SHA-1 Broken
·
· Score: 5, Informative
It's still not really practically breakable unless this is something bigger than what I'm guessing. SHA-0 was broken a few months ago, and MD5 a while before that. What does it mean for you? Not much.
Some attacker would have to be REALLY dedicated to use this vulnerability to harm you, and they would still require hideous amounts of processor time to mount an effective attack. Digests are a quick and easy way to verify that some message or file is correct. If the hash is signed as well, then you can verify the sender, too. When you download something like a Linux ISO, there is often another file on the server containing the hashes of the files, so you can verify that everything downloaded correctly. If you want to make sure that nobody other than a trusted person modified the files, then that trusted person could encrypt the digest with their private key, allowing anybody with their public key to verify that everything's correct.
A person can, with a broken hash, create another ISO file, perhaps with malicious code inserted, that has the same digest, meaning you can no longer trust the signed digest. Let's say that this vulnerability reduces the average time needed to find a collision from 2^48 tries via the Birthday paradox (If this isn't a 96-bit hash, then I really need to get more sleep) to 2^32 tries. That's over 65,000 times faster, but you know why I'm not worried? That's still over 4,000,000,000 ISO files that the attacker would have to try before hitting on one that's got the wanted characteristics and the correct digest to boot, and if it requires equivalent memory usage to its time usage, then I'd expect it to use at least 48 gigabytes of memory to store all of the previous attempted hashes. If it takes 15 seconds to compute one digest, then you're looking at a mere 2,000 processor years to find a vulnerability, compared to the much more comfortable 130,000,000 processor years that it would have required using the brute force method.
Feel better now? If I really got mixed up, and was wrong about the size, then just multiply all the listed times by 2^32, and wake me in 8 trillion AD.
Time to start a panic
on
SHA-1 Broken
·
· Score: 4, Funny
If you don't switch to the newest, latest hashing algorithm, you will die horribly when your corrupted emacs RPM performs malicious code!!! Everyone, delete everything and log off of the Internets now!!! We're all gonna die!!! HELP!!!
Slashdot Mirror
He has sort of a point there, if you ask me. If you are the type who only uses their laptop plugged into something, a new iMac is almost a reasonable substitute. All the power of a modern desktop with a bit more portability than a modern desktop. Just allow someone to pop off the base for easier transportation, make a bag that's a little bigger with space for your keyboard and mouse, and you've got something you can drag to your hotel room whenever you're on a business trip.
Home-schooling seems to be a better and better idea all of the time, as long as someone is able to take off time from work to look after the kids. The only problems I've seen are finding good textbooks to work from, as most of the home-schooling texts out there tend to be from a conservative Christian point of view. So if you're interested in teaching your child evolution, it's going to be a bit more difficult to do so than it would otherwise be.
A machine translator, no matter how sophisticated isn't going to be able to perform the secondary purpose of any translation of the Bible, which is to help support the translator's opinions and views on the Bible. If you want to cement the Bible as the plain and infallible source of all church teachings (some Protestant groups), yous translation is going to look profoundly different than one which shows the Bible as a mysterious and sometimes opaque text that sometimes requires training to understand its mysteries (the Catholic Church's official position).
Multiple pipelines at a time allows you to increase the rendering speed almost linearly, as long as you accept the trivial restriction that you must get the same image as an output no matter what order you render the pixels in. It's the opposite of the CPU business. In CPUs, they started adding multiple chips first, and in the GPU side of things, they added multiple cores (or their equivalent) first. This is partly because it's easier to only decode one instruction at a time and send the decoded signal to every pipeline than it is to decode multiple instructions and send them to the correct cores. This isn't to say that it's impossible, but a couple million more transistors are enough to make you think twice about whether you really want two cores.
I think Episodes 7-9 are specifically mentioned by name in the UN Convention on Torture and Inhumane Treatment.
They can probably increase the efficiency and the size, but you probably wouldn't want anything too large, unless you could turn it off. There are 4184 joules per food Calorie, so one of these cells would burn one joule every 5000 seconds, or a Calorie every ~240 days. Now, crank it up to 20 watts, and you've got 20 joules per second, or one Calorie about every 210 seconds. That's 410 Calories a day, and certainly enough to change your diet.
Well, you can slow it down and make things much more difficult, but it's not impossible. The words that you've typed are close to the words that you meant to type. But what's close? Any string of finite length can be transformed into any other string of finite length by adding, subtracting, and substituting characters. Two strings have a distance defined by the minimum number of additions, subtractions and substitutions that it takes to transform one into the other. This is called the Levenshtein distance, or for those who can't pronounce it, the edit distance. It's incidentally how most spellcheckers work, and if you run your text through one, it will be more readable by just about everyone. Now, consider using a SOM, or self-organizing map, a type of neural network. It can classify similar objects into single groups most similar to eachother. You can use this to find instances of possible manglings of uranium, plutonium, and most other words, given a large enough sample. Incidentally, just running your post through a spellchecker (Thunderbird's) and picking the default options on everything made the phrase 'dirty bombs' appear normally. So, it helps, but it's not perfect.
Better filtering has to be on the network level, so that individuals don't have to opt in. The people who know how to set up effective filtering won't likely buy anything from spamvertisers in the first place, meaning that, while it makes those peoples' lives easier, it doesn't affect the spammers' bottom line much.
Changed for clarity.
I mean, really? Every time they find a new one, the things just keep getting smaller. What's next, a piece of ejecta from another moon the size and shape of a '74 Chevy Impala? Might as well start naming the debris in the rings.
It's the sig equivalent of "Nuke the gay unborn baby whales for Jesus Christ"
Hence, it would seem logical to encourage the largest players to take risks, since they can not only manage the risk, but can best press the advantage. But we've got the current system where Microsoft is just sitting on piles of cash, and recent undergrads and grad students are risking their life savings to innovate. Frankly something is screwed up here.
The char, int, long, double, byte, etc. types are all primitives, and none of them are objects.
Any schmuck can make a HashMap, but getting it so that you can take a HashMap from your VM, serialize it, send it to another VM, and then it read it without the values changing around is nontrivial unless you can use the same source code as the other person. As far as the open documentation we've got says, it magically creates a hash value for every object, and every object is magically turned into a serialized form, with the JVM turning them back just as magically. "It just happens." is not really helpful for making a new binary-compatible system.
When someone says that you should think carefully about what you already did, then they really don't care if you think about it at all as long as you come to the 'correct' conclusion, which is that you should never break compatibility, ever, unless you're the leading OS manufacturer.
The thing I found that made making orthogonal functions easier was to take a page from Lisp's playbook. No function should have any side effects other than what it absolutely must, and if it does, that should be obvious from the function name, like closePrintStream(). If you find yourself unable to name the function from its side-effect, there's likely some problem hidden within the design. That means that each function should have at most one side effect. Furthermore, label all functions that call functions that have a side effect, even if it seems trivial. This extends to methods of objects, of course, and try to avoid side effects traveling over object boundaries, and for the love of God, don't have two different objects trying to handle the same responsibility at the same time! If object foo opens a file to read, then object bar had better not be able to close it, or even read from it without opening that file itself (after foo is finished, of course). It's better to do the right thing slowly than the wrong thing fast.
Yanno, mentioning that the guts were propelled 3.2 feet into the air sounds kinda like someone had nothing better to do than to measure the size of the splats with more precision than most people would consider sane. Now, I've had my suspicions about the Germans, but this is worse than anything I've previously read.
If there's one thing that mathematicians like, it's generalizing proofs to as wide of an area as possible. If a proof hasn't been generalized as much as humanly possible, it's a very good sign that the author of the proof couldn't come up with a way to make it more general. One thing to remember in math is even if it sounds simple, there's no gurarantee that it is simple. For instance, given an interval (a,b) tell how many prime numbers are within that interval. Trivial to state, but computationally nasty to say the least. There's an 'obvious' solution, to count up all of the prime numbers between the two, but if you're looking for something elegant, sorry but it isn't there, that we really know of.
There are two types of theorems. Trivial and unproven. The proof of the Shimura-Taniyama conjecture (now theorem) is trivial since it's been done. Given enough time, I know a few math profs who might dump one of those on a Sophomore level Proof Structures class.
If you've got a computer in your car, you'd only want it to run when the car's alternator is running, for obvious reasons, so it only starts when the engine is cranked. Waiting a couple of minutes just to play some music shows why you would want a quick boot time. In fact, if you've got the OS itself on flash, booting in a couple of seconds would be the best case scenario, IMO.
I open it in a new tab, post as quickly as possible, and then close the tab, just like everyone else. I don't even have to let it render, I just close it without even lookingl. You should try it.
Well, yeah, now that you mention it, you only need to twiddle a couple thousand bytes at the end to possibly change the hash, and you can do things much quicker. I really should stop posting as stream-of-consciousness, but the things you'll do to hit 50 karma... OK, having looked through everything more thoroughly, you can do it in a very small fraction of a second by your method. However, I was a bit wrong about how quickly their method works. It requires 2^69 attempts, on average, compared to my altogether too low 2^32. So, if it takes maybe a tad less than 2ms to calculate a hash (2^-9 s), then you'd need about 2^60 CPU seconds to crack a hash like that. Any password that is more vulnerable to an attack on the SHA-1 hashing algorithm than to just guessing the damn thing is indistinguishable from line noise. (Unfortunately too long for a sig, dammit)
Some attacker would have to be REALLY dedicated to use this vulnerability to harm you, and they would still require hideous amounts of processor time to mount an effective attack. Digests are a quick and easy way to verify that some message or file is correct. If the hash is signed as well, then you can verify the sender, too. When you download something like a Linux ISO, there is often another file on the server containing the hashes of the files, so you can verify that everything downloaded correctly. If you want to make sure that nobody other than a trusted person modified the files, then that trusted person could encrypt the digest with their private key, allowing anybody with their public key to verify that everything's correct.
A person can, with a broken hash, create another ISO file, perhaps with malicious code inserted, that has the same digest, meaning you can no longer trust the signed digest. Let's say that this vulnerability reduces the average time needed to find a collision from 2^48 tries via the Birthday paradox (If this isn't a 96-bit hash, then I really need to get more sleep) to 2^32 tries. That's over 65,000 times faster, but you know why I'm not worried? That's still over 4,000,000,000 ISO files that the attacker would have to try before hitting on one that's got the wanted characteristics and the correct digest to boot, and if it requires equivalent memory usage to its time usage, then I'd expect it to use at least 48 gigabytes of memory to store all of the previous attempted hashes. If it takes 15 seconds to compute one digest, then you're looking at a mere 2,000 processor years to find a vulnerability, compared to the much more comfortable 130,000,000 processor years that it would have required using the brute force method.
Feel better now? If I really got mixed up, and was wrong about the size, then just multiply all the listed times by 2^32, and wake me in 8 trillion AD.
If you don't switch to the newest, latest hashing algorithm, you will die horribly when your corrupted emacs RPM performs malicious code!!! Everyone, delete everything and log off of the Internets now!!! We're all gonna die!!! HELP!!!
How the mighty have fallen! I'd never expect to see Andrew Tanenbaum trolling Slashdot as AC.