Basically, if you don't like these movies you are not intellectual enough. This was the same defense offered by many Matrix "fans" to people who didn't like Reloaded. By the way, Reloaded was a dreadful movie, just because somebody doesn't like it doesn't mean their dumb or unsophisticated.
There's a difference between a dreadful movie and a dreadful story. I can forgive a dreadful movie if there is no other version of the story, and the story is good, or at the least, interesting. Reloaded was a good story - especially if you watch the original Matrix, and then Reloaded. A lot of the open plot points (how can the Oracle predict the future?) were addressed in an extremely clever way (She doesn't predict the future. She controls it). The story itself seemed a bit contrived (good guys go on quest, must find keymaker, must unlock door - it felt like a video game) - but it then explained the contrivance - it WAS contrived. Purposefully.
It was a bad movie, though. The fight scene with Smith was meaningless, other than to give Smith more screen time because he's actually the most important point in the series (he's "what's different" this iteration that makes it special, not Neo). Bane's acting was awful, as was Kid's, and Locke's. The dance scene in Zion was overdone.
Unfortunately, getting "story" reviews from people who don't like the movie generally is nigh-impossible - it's very difficult for people to separate the two. So, when a lot of times you hear "you're not sophisticated enough", what I translate that into is "the story's good - the movie sucks". This is the main reason I don't like reading bad reviews for movies - people who hate a movie are generally very unforgiving about its positive points.
Movies are very rarely as bad as the bad reviews make them out to be. Go through rottentomatoes.com for movies you consider very good, and read the 'bad' reviews: they're just plain awful.
One thing that perplexes me is why VLIW is not more popular. Think about it. Spend a ton of energy *once* at compile time to schedule/optimize the code then just run the parallel ops. Why should the CPU do the work of a compiler at runtime?
Because the CPU has more information than the compiler does - i.e., the Halting problem.
The best example that one could give would be interrupt handlers: how could a compiler ever know when an Ethernet interrupt is going to happen? It can't. Nor can it know the code execution path of anything that checks hardware registers, etc.
Yes, the CPU can't know when an interrupt handler will occur, either. But to it, all it's getting is code. It just tries to schedule it as best it can, and so it *is* going to parallelize some things that a compiler can't.
Look at the space consumed by the VLIW core of the Itanium versus the space consumed by the P4's x86 core, minus the common parts (like the execution engines). Yah, the x86 core is bigger, but it's such a trivial amount of transistors compared to the rest of the chip that it's not that big a deal.
It should also be noted that noting high cycle multiplies and then complaining about core efficiency are two totally different things - the high cycle count for certain instructions is a RISC-ism (it's a 'CISC' instruction, that needs to get broken down), which deals with the instruction set itself (or, in this case, the microarchitectural instruction set), and efficiency is complaining about the combination of code+scheduling logic+parallellization hardware.
The P4 is actually heavily optimized for efficiency, since it's such a high clock speed, and crap like pipeline bubbles really hurt you - hence HyperThreading, for example.
I'd really like to know what the net efficiency (that is, how full does the processor's pipeline stay) of the P4 versus the VLIW designs. I don't think I've seen that anywhere.
Do you know how the old lever systems worked? At all? I don't. Not at all. But I would have trusted them, simply because the machinery is quite simple. I could tell that something is happening, with each vote.
This is all you need. Hell, the main reason embedded systems (real embedded systems, like Diebold's crap) 'look' vulnerable is because they've got all this extra crap, that people know has to be useless.
Quite frankly, people are willing to use technology because they now know that paper ballots are error-prone, too, and technology looks like magic, so it seems less error prone. What I'm saying is that we give them something that's like magic. The Diebold crap isn't magic. It's software kludged together to 'kindof' work.
(And incidentally, what I'm suggesting is not an embedded system. An embedded system is a microprocessor system embedded inside a device: hence, embedded system. What I'm suggesting is a discrete system - pure logic, no software.)
A blind man can't verify that a paper ballot says the right thing, but he can trust that thousands of other people can see that it says the right thing.
Each individual voter doesn't have to verify every vote. There just has to be a system for vote verification. Not that hard.
I don't know if the problem is really that the software needs to be open source, or simply the fact that there is software at all.
I mean, think about it. What do you really want the system to do?
State: Waiting for User State: Present User with Options State: Ask User to Confirm State: Record User Choice
Four states. That's all you've got. Four states. Why, precisely, are they using cheap hardware for something that a pair of dual flip-flops could handle?
Honestly - think about this. The only reason there are "security concerns" at all is because they were too cheap to design a dedicated system, no software, just pure logic, that can be run on a logic checking system looking for races, possible vulnerabilities, etc.
Paper trail? Well, paper's not exactly THAT good (it does burn, and as Florida proved, it's not always verifiably correct). What about a write-once, read-many device? Like, I don't know, a CD-R, with packet-based writing?
Embedded systems are becoming so much more popular over discretes because hardware is cheap, and bad software is cheaper. But in a case like this, I don't understand it. An idiot could design dedicated hardware voting terminals, which don't even have the possibility of tampering. It's just incompetence.
(P.S.: Sounds like a decent business plan, doesn't it? "Tamper-proof Voting Terminals" - "No more software crashes, no more unreliable messes - works the same way, every time, guaranteed.")
Yes, I know things are a bit more complicated than I'm pointing out here. But it is still correct: E-Voting doesn't HAVE to be fundamentally flawed. It just is when they use cheap hardware. C'mon. Haven't they seen the i-Opener BBSes? Hardware based on the "limit possibilities by creative software" is screaming to be hacked.
He meant "accurate". Precision is the repeatability of the experiment, and the degree to which it varies. It's a flaw in the experiment, not in agreement with theory. When you're talking about an experiment agreeing with theory, you're talking about accuracy.
As for the "accuracy" of the measurements, of course we know whether or not they're accurate. What you do is you take one constant ("alpha", the fine structure constant, in the case of QED) and let the experiment determine it, rather than it determining the experiment. Since the same theory explains all sorts of different predictions, the degree to which the experiments agree with each other on the value of "alpha" tells you how accurate your theory is.
Currently, with QED, I think that's about 10 or 11 decimal places. (alpha is about 1/137, so that's about 9 orders of magnitude accuracy).
I don't get this. Theoretically, as far as I can tell, it's not just deniable, it's provably wrong, for the same reason that the Halting problem is unsolvable - you cannot determine how a program will execute before it actually runs. You simply do not have sufficient information.
Hell, imagine driver code : you don't know how often an interrupt is going to occur in hardware, so you functionally have no way of knowing what the best case for parallelism is, because you have no idea what the execution path is going to be. Functionally, anything that doesn't execute in a purely deterministic code space (i.e. anything that interacts with anything else - with RAM, with devices, with other computers) cannot have as much information at compiletime as runtime. With the case of interrupt handlers, this is definitely true, as it inserts code into the program path.
Some combination of the EPIC design and the standard superscalar OOO execution models is almost definitely the correct way to go. I've never understood why some people fervently support EPIC - just like with the RISC v CISC debate, middle ground almost always proves best between two extremes.
Er? QED is arguably the most accurate theory - something like what, 11 different measurements of alpha yield the same result to 10 digits or so? (I want to say that this is in Peskin & Schroeder's Quantum Field Theory, but I could be wrong). However, for one, that's only QED, not quantum mechanics in general. It's not like QCD is well tested - at all.
And, for two, it depends on what you mean by "accurate". Certain portions of GR - for instance, the equivalence principle - have been tested ridiculously accurate - 1 part in 10^12, or something like that. Plus, if memory serves, the binary pulsar measurement was ridiculously good in agreement.
QED is by far the more accurately tested theory of the two. By *far*. But if you group all quantum field theories together, then it's not so good (because strong strong interactions are just as hard as gravity), and "quantum field theories in general" start to look about as accurate as general relativity.
I think the basic idea is that QM and GR are fundamentally different theories. You look at them, and it sounds like you're talking about two different Universes, with two different physical laws. And the problem is, that within the domain of their accuracy (GR is large-scale, 'strong' gravity, QFTs are generally short-range 'weak' interactions, but only because the long range stuff is classical) they're both extremely accurate - about as accurate as the measurement can make. And the main problem is that no one has a friggin' clue how to unify the two.
Well, they have a clue. It's just that most of the time, that clue makes the universe look like a complete disaster. It's like in the 1930s, during the revolution in particle physics: "who ordered THAT?"
No you just claimed that, probably so you could knock down a straw man.
Do you read your own posts? And I quote:
Not a good thing. If Drivers are written for windows and then emulated to other OS's it will give Windows a permanent performance advantage.
You're claiming that using emulated drivers on other OS's (emulation running on one implementation) will run slower than on Windows (native running on another implementation).
How is that different than what I claimed that you claimed? A straw man argument is when someone makes an analogy that's a severe stretch from the original statement. This is definitely not that case.
And your point is ? Are you trying to imply they will be faster ?
s/will/must. Some, certainly, can be faster. Hell, if you simply reimplement the Windows driver API, there's actually no reason it'd be slower, as that's not an emulator, it's a simulator (which is really what this will be, most likely).
But even a true emulator in Linux doesn't have to be slower than under Windows, because you're still not at bare metal, and the syscalls don't take the same time. If you've seen the recent benchmarks of Linux vs. the various BSDs in network performance, you can see that system call latency varies massively between operating systems.
PLUS, in addition, a driver is only one layer in the whole thing. A network driver from Windows, emulated on Linux, may still give better performance than in Windows, because the latency for, say, socket(), bind(), etc. may be lower in Linux than in Windows, and so while the Windows driver spends less time in the driver code, the overall amount of time for the socket(), etc. call can still be less under Linux.
Native drivers are better, of course. But it's completely idiotic to claim that emulated drivers on one OS must result in lower performance than the native operating system, which is what you were claiming. (Go ahead, try to argue that you didn't claim this: it's pretty much verbatim what you said).
Yes you will, theres a funny reason for this windows is its own emulator. If you have old win16 calls they are passed through a Thunking layer translating them to win32 calls.
Yah. And? You don't think there are similar performance bottlenecks in the driver API as well that would be alleviated by running on a different platform that doesn't have those bottlenecks?
There is one creature capable of changing this trend, and that is us.
Ah, human hubris. Nothing we can do will stop the Sun dying - nothing. And when it does die, this planet dies a slow, cold death.
Now, if you're talking about saving life on this planet, okay... then...
Nature evolved a creature that has the potential to survive the lifeless vacuum and spread life throughout the universe.
Yah, she did, and that creature is called "a bacterium" and "spores".
If you just look at statistics, the chance that humans are going to eventually go to another star system is really small. The chance that a bacterium from Earth may eventually make it to another star system is equally small.
If you're talking about spreading Earth life throughout the galaxy, honestly, bacteria and spores are a better bet than we are - we're notoriously fragile. Can't even spend a couple of hours up in our own exosphere. Yeesh.
We might give those bacteria and spores a bit of a lift, but they'll probably be the ones that spread Earth life the farthest.
Being the first intelligent species on this planet and being proud of that fact is not hubris and it isn't arrogant.
You don't know that humans are the first intelligent species on the planet. Humans have been around, at most, 2 million years, and I doubt that you'd claim that australopithecus was intelligent. Complex life has been around for on the order of several hundred million years.
It might be better to say that we're the first intelligent species to mess around with the planet enough that future species can't possibly miss the fact that we existed. Then again, the others might've just cleaned up more before they left.
Emulation is a catchall phrase for several things. WINE, for instance, means "Wine is Not an Emulator", because it isn't.
Emulation, by necessity, must involve a performance hit, because you have to have a lookup table in there between when you examine the operation and when you perform it. Fundamentally, "emulation", the true meaning of the word, has to be slower than a native implementation of the same thing.
However, what you claimed is that emulation must be slower than a completely different implementation of the same thing, which is just nonsense.
So, to recap:
TRUE: Windows drivers emulated on Linux will be slower than native Linux drivers.
FALSE: Windows drivers emulated on Linux will be slower than those same Windows drivers on Windows.
If you want examples, just go through Google and search for WINE performance. You'll find plenty of examples where WINE improved performance because the lower layers were faster.
Ha! You're kidding, right? In general, if you have good documentation on the chip you're working on, and maybe SOME info from the manufacturer, you're going to write better drivers than the manufacturer. Most Win32 drivers are written like crap, and are very hodgepodge. See, for instance, wireless drivers, which before WinXP, all used their own proprietary program to interact with the card (and in some cases, the WinXP program doesn't work, like the Cisco wireless cards), whereas under Linux, everyone just uses the iwconfig interface, including the proprietary drivers, like the ADM8211 based cards.
The name isn't that weird: "NCR" is a company, now Symbios, and tons of integrated circuits use the ##letter#####... pattern. The letter usually stands for the chip family, in this case CMOS. The first two digits are the family, the letter is the chip technology (lacking one means it's ancient TTL) and the last digits are the chip function.
A hobbyist trying to get a chip to work will more often than not stick closer to the specifications than the manufacturer, and usually build more stable drivers.
But anyway, there are plenty of native company-made Linux drivers out there. Browse the *actual* source of the drivers, and a lot of times you'll find, wow, amazingly enough, the company wrote the driver. (But not with the NCR53C875, which was written for BSD, though there is a plethora of information out there from LSI/Symbios/etc.).
Any significant amount of oxygen is almost certainly from something like photosynthesis. Oxygen's too reactive to stay in the atmosphere for any significant amount of time without something constantly generating it, and that's likely to be life.
Now, before everyone jumps down my throat saying "You don't need oxygen for life! Oxygen is poison! It's extremely dangerous!" - they'd be right, and wrong (as many people are...). Oxygen IS very reactive and corrosive - but that's why life wants it around. Oxygen generates a lot of chemical activity and a lot of chemical potential, allowing for complicated reactions to happen. This isn't "Earth-centric", it's basic chemistry.
And yes, even life in the ocean would likely generate oxygen in the atmosphere, and yes, it is possible to have life in the ocean WITHOUT oxygen in the atmosphere, but unless there's no solar insolation there at all, organisms that use sunlight will beat out those that don't virtually everywhere, and photosynthesis works best with oxygen involved in the process (to generate the many, many different oxidation potentials needed).
very high altitiude ballons (USAF project manhigh).
Ballons aren't going 17,000 mph with respect to the surface. They'd need more than a fire extinguisher for retrorockets - they'd need a compound that doesn't (and can't) exist. It's too much velocity to burn off any other way besides aerobraking.
Plus the stresses required to brake that much would kill a person instantly.
If you built something that the human could survive inside to withstand the stresses, congratulations, you've just rebuilt the shuttle.
It's not just "a lot" of heat. It's a metric ton of heat. It's several Library of Congresses of heat. No chance. No way.
Consider the ultimate extreme - a computer capable of analyzing the full search space of chess in 1 second (probably not possible to engineer using all the matter in the universe). This computer simply cannot lose against any player who isn't capable of doing the same. The program doesn't need to recognize patterns, it just picks the best route to victory under the current conditions, and adjusts it after each human move.
This is known as "solving chess". The important thing to realize is that a computer isn't the only way to do it. There's no reason a "perfect human" couldn't do it too, exactly the same way that humans do it now - by memorizing all significant patterns that could occur.
The problem with that method is that the concept of "significant patterns" requires intelligence (or better mathematics than simply 'I win') to determine whether or not a state is 'better' than another one. With the hypothetical "perfect computer", the route for solving is already known - it's "I win." vs "I lose." So, it's easier to get close to the "perfect computer" than a "perfect human".
This is exactly analogous to computers vs. humans in modern mathematics. Sure, a computer can calculate the next prime number by brute force and can do it much faster than a human. However, if a human develops a new algorithm to calculate the next prime number in a sequence, he'll arrive at some prime number much faster than a brute force method. The only question is does the algorithm exist, and how long does it take to find it?
Obviously this will never happen, but suppose you have a computer capable of fully searching 30 moves. I'd argue that no human could beat that either - while not a full game ahead it is close enough. Now consider 20 moves - we're still probably unbeatable. At this point we're just arguing degree - eventually a computer will come out capable of searching deep enough to beat a human.
C'mon, you're talking about memorization here. Humans now might not be able to beat the computer, but humans 20 years from now, after playing against these chess programs for 20 years, will easily be able to see just as far as the programs do, because it's all a matter of patterns, and the computers will value the same patterns (because that's what they're programmed to do), unless you believe that computer programs today are perfect, and there is no method of beating them (i.e. "chess is solved"), which I don't agree with. No computer has ever shut out a human, and remember, regardless of what some people might say, a human can't beat a computer "by luck", because the computer doesn't make mistakes. The fact that humans still draw computer programs tells me that the programmers are very smart, but there are still some portions of the game they (and probably the Grandmasters as well) don't understand.
Remember, the computers playing chess these days rely more on smarter software than brute force. They don't represent the state of the art in CPU power or storage. I'd argue that the best computers today running the best software would do even better than what we presently see, and eventually Moore's law will win out on humans.
They rely on smart software because it's the only way to solve the problem. Brute forcing it simply won't work, because you can't brute force to the only "tangible" solution: "I win" vs "I lose", so you have to make up a bunch of "intangibles" like king safety, piece mobility, and position. By valuing those intangibles, you're eliminating portions of the move tree, and opening yourself up to a pattern-recognizing human who may see a portion of the move tree you've eliminated as "bad".
Honestly, you're contradicting yourself here: the best software would not run tremendously better on better hardware, because it's still constrained by its own limitations - the "smarter software" part. No one in their right mind starts with the "brute force" method - they start with an opening playbook, and so long as they start with that, they've limited themselves.
i heard all of Kasparov's rant. he is well known in chess circles for a big mouth. The point is that he lost. He will lose again today. Period.
Kasparov? Kasparov wasn't the main one "ranting" - the main people "ranting" were the people who created OTHER chess programs, because when they competed, they were actually contributing to the field, whereas Deep Blue was simply a media event.
Think whatever you want about Kasparov, but the Deep Blue vs. Kasparov match will always have a mark next to it. You couldn't see the output of the program, you couldn't see the operators, you couldn't inspect the hardware or the software, and the hardware gets dismantled right afterwards.
But, if you run Deep Junior strength program on a cluster, there is no doubt that kasparov, kramnik and anand sitting togehter can draw against it.
What the heck? Why do you keep making the assumption that increased processing power = better chess program. Increasing the processing speed of a computer only improves traversing the move tree, and that part isn't the part that needs to be strengthened most significantly - it's the tree pruning logic and the "intangibles". Processing power won't make a brute-force approach computer realize "oh, wait, I really DO want to have control over the center of the board early in the game" until you're able to brute force a significant portion of the move tree.
Deep Junior will NOT get magically "super-better" when run on better hardware. It's the software, not the hardware. The authors themselves have already stated this.
No, I am not wrong. Look at the game where the human lost. It's all about probability, risk, and previous plays. Taking all those into consideration and making a partial tree of the "foreseeable future" will almost guarantee the computer a victory.
Will almost guarantee. The problem is that the computer can't think - it can just run what it was programmed to do. When a human sees that the computer is reacting to something, he changes his/her strategy - something the computer cannot do, if the human stepped outside the bounds of the programmed "forseeable future". That turns your almost guarantee into the episode of Star Trek where Data plays a strategy game perfectly against a human, and loses. When the human realizes the program's boundaries, the human has an advantage.
Your solution will only work when computers can reprogram themselves.
Look at the games where the human won. It wasn't because the computer ran out of time, or was under time pressure. It was because the human outplayed the computer - the human pushed the computer outside where it had pruned the move tree.
In several games the human operator had to offer to resign for the program, because the program hadn't realized that it had lost. Apparently its program didn't look down the portion of the move tree that was obvious to a human watching.
What we're comparing are two different methods to solving a problem: pattern recognition, and trial and error. Trial and error is impossible, because the state space is too large, as has been established, so programmers use tricks to trim the state space. The problem is if their tricks aren't perfect, pattern recognition can always win, because there exists a winning solution outside of the trimmed state space.
The original parent said that faster hardware => a guaranteed computer victory. This is plainly false: faster hardware will not eliminate the flaws in trimming the state space, and a good enough human player will be able to find the flaws.
Maybe someone will eventually write the "perfect chess program", which trims the state space perfectly into something manageable. But we're not there yet - no way.
Why do you think Kasparov lost to deep blue? Because they used more powerful hardware!! That was in last decade. If you spend the same amount of money today, you will get a computer so powerful that humans can dream of a draw againt that machine.
I'm guessing you didn't hear about any of the contraversy regarding Deep Blue vs. Kasparov. Deep Blue seemed like a computer built and programmed to beat Kasparov, not a general purpose chess program. There are other concerns (they didn't open up the source, etc.) - it's a longstanding controversy in chess programming.
and come up with a couple of novelties.
If you can have a computer do that, you've just solved the hard AI problem. The only known way for computers to play "good chess" is to brute force the move tree. If you want them to do better than that, you prune the tree, and program in a bit of logic. Logic doesn't improve with processor speed. Only brute forcing the move tree improves with processor speed, and we've already established that brute forcing the move tree is futile.
Look, the simple counterargument is that if computing power led to chess playing power, then the computing power of computers should be growing as processing speed, and it's not - computers haven't won a match vs a Grandmaster since Deep Blue, and see above regarding the controversy regarding Deep Blue, which is definitely well-founded. In fact, they've tied every match since what, 2000? And computing power has increased by how much since then?
It's not the hardware, it's the software. No one's repeated Deep Blue yet, so you can't "definitively" say that hardware wins.
Who knows, Deep Junior could've beaten Deep Blue. The controversy is that we'll never know, so your argument is all speculation that Deep Blue was super-ultra-mega-computer.
None of the modern computers even considers brute-forcing the move tree - it's impossible. The search space is far too big, and considering some moves/board configurations can loop back on themselves, it's nearly infinite. Brute-forcing the move tree is simply useless.
That being said, all the major chess programs nowadays are not limited by hardware, but by software. Throw better hardware at them, and they will not play better chess.
Finally, Inflation Cosmology predicts that the Universe must have enough mass to keep it from flying apart forever, and that is even more mass.
Inflation cosmology predicts that omega = 1 - that is, there's exactly the critical density in the universe. It does not predict that it's all matter, or what it is at all.
Hence the reason we've got 70% dark energy, and 30% normal matter. Exactly the critical density, but it doesn't mean that we won't fly apart forever - if dark energy continues its wonderful negative-pressure inducing fun, we most decidedly will fly apart forever. That being said, not having a damned clue what the hell dark energy is, we can't predict anything at all.
The $60,000 dollar question is whether cold dark matter exists -- particles much more massive than a neutrino so they aren't zinging around so much that they can congregate in galaxies, but non-baryonic (i.e. some form of matter unknown to physics) but also weakly interacting like neutrinos (really hard to detect).
The parent's statement (massive neutrino) is not totally nuts. In fact, it's actually quite possible. We know that there are 3 neutrinos, and only 3 neutrinos (there are experiments in particle physics which directly give the # of neutrinos), but as far as I know, that's energy-range dependent- you have to conserve lepton number (and family lepton number) so if there is a "super-tau-neutrino", it wouldn't appear in particle accelerators until they could generate the energy of a "super-tau". If there's a 4th generation of matter, and that neutrino is ridiculously heavy (MeV-ish), that could make up all the lost matter.
That being said, it'd take a bit to figure out exactly *how* you make it so that it doesn't oscillate into other neutrinos, but the CKM matrix is a bit ad-hoc, so it's possible, I guess. Just not likely, at the moment. Besides, everyone loves axions and supersymmetric particles. Stuff like "gauginos" and "neutralinos" are too fun to say.
Yah, someone with one letter difference in name. That's quite frightening.
Actually, you're correct, and incorrect.
If the spins are antiparallel, the half-life is 10^-10 seconds (because they have a higher wavefunction overlap, since the total spin is 0). If the spins are parallel, the half-life is 10^-7 seconds (less overlap, so the phase space is smaller).
Actually, it's a meteoroid until it hits the atmosphere, a meteor in the sky, and a meteorite after that.
Asteroids are "large" rocks in space, with a poor distinction on what's "large" and what's not. It's unclear whether or not an object is a meteoroid or an asteroid, and unclear as to whether an asteroid entering Earth's atmosphere would be a meteor (then again, we'd be screaming for help, so it wouldn't much matter).
Finally, have you talked to your university's legal department? Is there any way that this project could belong to the Uni? Are you sure about that?
There's actually more than that, and I hope this comment (and yours!) gets noticed:
If he's an undergrad, or even a grad working at the University's campus, he may not be legally allowed to earn money for a project he's working on if he's using the University's resources. That means the ever-so-wonderful "massively fat pipe" that the University provides. You need to be very careful about doing things correctly with universities. Hell, I know for me (I'm a grad student), I'm not allowed to take another job (without explicit permission) - it's in my contract.
Universities are terrible at paying attention to legal details. You'll get away with absolute tons, for the most part. Every once in a while, though, someone jumps up and notices something, and tries to capitalize on it. You need to be very careful, because a lot of times, there is a lot of fine print.
As I have stated previously, SCO may have a case here.
Oh, yeah, SCO has a wonderful case. They've shown that malloc() and now, according to SGI, atoi() may have been copied from SysV.
For crying out loud, give me a break - we're talking about functions that companies ask prospective employees to pseudocode to prove that they know how to program! No court in this decade would possibly find for SCO.
I'd love to hear SCO come out and say "Yes, they've stolen our brilliant and amazing atoi() code! They never would have been able to come up with atoi() on their own!"
Somehow I think atoi(), malloc(), and even ate_utils are going to fall under the "who the hell cares??" category. SCO can't possibly win a case based on code like that. There's far too much precedence that they didn't defend it in other cases. Until they show code that a half-blind monkey with one hand couldn't generate, they're posturing, and nothing else.
It has a half-life of 0.1 uS. It's a relatively standard physics problem at the graduate school level to ask what the binding energy of positronium is.
If it ever comes up, it's (1/2) the binding energy of a hydrogen atom. The reasoning is simple - a positron and a proton have the same charge, but a positron and an electron have the same mass, so the "reduced mass factor" is 1/2, rather than 1. (M_p/(m_e+m_p) ~= 1) vs (M_e/(m_e+m_e) = 1/2).
Slashdot Mirror
Basically, if you don't like these movies you are not intellectual enough. This was the same defense offered by many Matrix "fans" to people who didn't like Reloaded. By the way, Reloaded was a dreadful movie, just because somebody doesn't like it doesn't mean their dumb or unsophisticated.
There's a difference between a dreadful movie and a dreadful story. I can forgive a dreadful movie if there is no other version of the story, and the story is good, or at the least, interesting. Reloaded was a good story - especially if you watch the original Matrix, and then Reloaded. A lot of the open plot points (how can the Oracle predict the future?) were addressed in an extremely clever way (She doesn't predict the future. She controls it). The story itself seemed a bit contrived (good guys go on quest, must find keymaker, must unlock door - it felt like a video game) - but it then explained the contrivance - it WAS contrived. Purposefully.
It was a bad movie, though. The fight scene with Smith was meaningless, other than to give Smith more screen time because he's actually the most important point in the series (he's "what's different" this iteration that makes it special, not Neo). Bane's acting was awful, as was Kid's, and Locke's. The dance scene in Zion was overdone.
Unfortunately, getting "story" reviews from people who don't like the movie generally is nigh-impossible - it's very difficult for people to separate the two. So, when a lot of times you hear "you're not sophisticated enough", what I translate that into is "the story's good - the movie sucks". This is the main reason I don't like reading bad reviews for movies - people who hate a movie are generally very unforgiving about its positive points.
Movies are very rarely as bad as the bad reviews make them out to be. Go through rottentomatoes.com for movies you consider very good, and read the 'bad' reviews: they're just plain awful.
One thing that perplexes me is why VLIW is not more popular. Think about it. Spend a ton of energy *once* at compile time to schedule/optimize the code then just run the parallel ops. Why should the CPU do the work of a compiler at runtime?
Because the CPU has more information than the compiler does - i.e., the Halting problem.
The best example that one could give would be interrupt handlers: how could a compiler ever know when an Ethernet interrupt is going to happen? It can't. Nor can it know the code execution path of anything that checks hardware registers, etc.
Yes, the CPU can't know when an interrupt handler will occur, either. But to it, all it's getting is code. It just tries to schedule it as best it can, and so it *is* going to parallelize some things that a compiler can't.
Look at the space consumed by the VLIW core of the Itanium versus the space consumed by the P4's x86 core, minus the common parts (like the execution engines). Yah, the x86 core is bigger, but it's such a trivial amount of transistors compared to the rest of the chip that it's not that big a deal.
It should also be noted that noting high cycle multiplies and then complaining about core efficiency are two totally different things - the high cycle count for certain instructions is a RISC-ism (it's a 'CISC' instruction, that needs to get broken down), which deals with the instruction set itself (or, in this case, the microarchitectural instruction set), and efficiency is complaining about the combination of code+scheduling logic+parallellization hardware.
The P4 is actually heavily optimized for efficiency, since it's such a high clock speed, and crap like pipeline bubbles really hurt you - hence HyperThreading, for example.
I'd really like to know what the net efficiency (that is, how full does the processor's pipeline stay) of the P4 versus the VLIW designs. I don't think I've seen that anywhere.
Do you know how the old lever systems worked? At all? I don't. Not at all. But I would have trusted them, simply because the machinery is quite simple. I could tell that something is happening, with each vote.
This is all you need. Hell, the main reason embedded systems (real embedded systems, like Diebold's crap) 'look' vulnerable is because they've got all this extra crap, that people know has to be useless.
Quite frankly, people are willing to use technology because they now know that paper ballots are error-prone, too, and technology looks like magic, so it seems less error prone. What I'm saying is that we give them something that's like magic. The Diebold crap isn't magic. It's software kludged together to 'kindof' work.
(And incidentally, what I'm suggesting is not an embedded system. An embedded system is a microprocessor system embedded inside a device: hence, embedded system. What I'm suggesting is a discrete system - pure logic, no software.)
A blind man can't verify that a paper ballot says the right thing, but he can trust that thousands of other people can see that it says the right thing.
Each individual voter doesn't have to verify every vote. There just has to be a system for vote verification. Not that hard.
I don't know if the problem is really that the software needs to be open source, or simply the fact that there is software at all.
I mean, think about it. What do you really want the system to do?
State: Waiting for User
State: Present User with Options
State: Ask User to Confirm
State: Record User Choice
Four states. That's all you've got. Four states. Why, precisely, are they using cheap hardware for something that a pair of dual flip-flops could handle?
Honestly - think about this. The only reason there are "security concerns" at all is because they were too cheap to design a dedicated system, no software, just pure logic, that can be run on a logic checking system looking for races, possible vulnerabilities, etc.
Paper trail? Well, paper's not exactly THAT good (it does burn, and as Florida proved, it's not always verifiably correct). What about a write-once, read-many device? Like, I don't know, a CD-R, with packet-based writing?
Embedded systems are becoming so much more popular over discretes because hardware is cheap, and bad software is cheaper. But in a case like this, I don't understand it. An idiot could design dedicated hardware voting terminals, which don't even have the possibility of tampering. It's just incompetence.
(P.S.: Sounds like a decent business plan, doesn't it? "Tamper-proof Voting Terminals" - "No more software crashes, no more unreliable messes - works the same way, every time, guaranteed.")
Yes, I know things are a bit more complicated than I'm pointing out here. But it is still correct: E-Voting doesn't HAVE to be fundamentally flawed. It just is when they use cheap hardware. C'mon. Haven't they seen the i-Opener BBSes? Hardware based on the "limit possibilities by creative software" is screaming to be hacked.
He meant "accurate". Precision is the repeatability of the experiment, and the degree to which it varies. It's a flaw in the experiment, not in agreement with theory. When you're talking about an experiment agreeing with theory, you're talking about accuracy.
As for the "accuracy" of the measurements, of course we know whether or not they're accurate. What you do is you take one constant ("alpha", the fine structure constant, in the case of QED) and let the experiment determine it, rather than it determining the experiment. Since the same theory explains all sorts of different predictions, the degree to which the experiments agree with each other on the value of "alpha" tells you how accurate your theory is.
Currently, with QED, I think that's about 10 or 11 decimal places. (alpha is about 1/137, so that's about 9 orders of magnitude accuracy).
I don't get this. Theoretically, as far as I can tell, it's not just deniable, it's provably wrong, for the same reason that the Halting problem is unsolvable - you cannot determine how a program will execute before it actually runs. You simply do not have sufficient information.
Hell, imagine driver code : you don't know how often an interrupt is going to occur in hardware, so you functionally have no way of knowing what the best case for parallelism is, because you have no idea what the execution path is going to be. Functionally, anything that doesn't execute in a purely deterministic code space (i.e. anything that interacts with anything else - with RAM, with devices, with other computers) cannot have as much information at compiletime as runtime. With the case of interrupt handlers, this is definitely true, as it inserts code into the program path.
Some combination of the EPIC design and the standard superscalar OOO execution models is almost definitely the correct way to go. I've never understood why some people fervently support EPIC - just like with the RISC v CISC debate, middle ground almost always proves best between two extremes.
Er? QED is arguably the most accurate theory - something like what, 11 different measurements of alpha yield the same result to 10 digits or so? (I want to say that this is in Peskin & Schroeder's Quantum Field Theory, but I could be wrong). However, for one, that's only QED, not quantum mechanics in general. It's not like QCD is well tested - at all.
And, for two, it depends on what you mean by "accurate". Certain portions of GR - for instance, the equivalence principle - have been tested ridiculously accurate - 1 part in 10^12, or something like that. Plus, if memory serves, the binary pulsar measurement was ridiculously good in agreement.
QED is by far the more accurately tested theory of the two. By *far*. But if you group all quantum field theories together, then it's not so good (because strong strong interactions are just as hard as gravity), and "quantum field theories in general" start to look about as accurate as general relativity.
I think the basic idea is that QM and GR are fundamentally different theories. You look at them, and it sounds like you're talking about two different Universes, with two different physical laws. And the problem is, that within the domain of their accuracy (GR is large-scale, 'strong' gravity, QFTs are generally short-range 'weak' interactions, but only because the long range stuff is classical) they're both extremely accurate - about as accurate as the measurement can make. And the main problem is that no one has a friggin' clue how to unify the two.
Well, they have a clue. It's just that most of the time, that clue makes the universe look like a complete disaster. It's like in the 1930s, during the revolution in particle physics: "who ordered THAT?"
No you just claimed that, probably so you could knock down a straw man.
Do you read your own posts? And I quote:
Not a good thing. If Drivers are written for windows and then emulated to other OS's it will give Windows a permanent performance advantage.
You're claiming that using emulated drivers on other OS's (emulation running on one implementation) will run slower than on Windows (native running on another implementation).
How is that different than what I claimed that you claimed? A straw man argument is when someone makes an analogy that's a severe stretch from the original statement. This is definitely not that case.
And your point is ? Are you trying to imply they will be faster ?
s/will/must. Some, certainly, can be faster. Hell, if you simply reimplement the Windows driver API, there's actually no reason it'd be slower, as that's not an emulator, it's a simulator (which is really what this will be, most likely).
But even a true emulator in Linux doesn't have to be slower than under Windows, because you're still not at bare metal, and the syscalls don't take the same time. If you've seen the recent benchmarks of Linux vs. the various BSDs in network performance, you can see that system call latency varies massively between operating systems.
PLUS, in addition, a driver is only one layer in the whole thing. A network driver from Windows, emulated on Linux, may still give better performance than in Windows, because the latency for, say, socket(), bind(), etc. may be lower in Linux than in Windows, and so while the Windows driver spends less time in the driver code, the overall amount of time for the socket(), etc. call can still be less under Linux.
Native drivers are better, of course. But it's completely idiotic to claim that emulated drivers on one OS must result in lower performance than the native operating system, which is what you were claiming. (Go ahead, try to argue that you didn't claim this: it's pretty much verbatim what you said).
Yes you will, theres a funny reason for this windows is its own emulator. If you have old win16 calls they are passed through a Thunking layer translating them to win32 calls.
Yah. And? You don't think there are similar performance bottlenecks in the driver API as well that would be alleviated by running on a different platform that doesn't have those bottlenecks?
There is one creature capable of changing this trend, and that is us.
Ah, human hubris. Nothing we can do will stop the Sun dying - nothing. And when it does die, this planet dies a slow, cold death.
Now, if you're talking about saving life on this planet, okay... then...
Nature evolved a creature that has the potential to survive the lifeless vacuum and spread life throughout the universe.
Yah, she did, and that creature is called "a bacterium" and "spores".
If you just look at statistics, the chance that humans are going to eventually go to another star system is really small. The chance that a bacterium from Earth may eventually make it to another star system is equally small.
If you're talking about spreading Earth life throughout the galaxy, honestly, bacteria and spores are a better bet than we are - we're notoriously fragile. Can't even spend a couple of hours up in our own exosphere. Yeesh.
We might give those bacteria and spores a bit of a lift, but they'll probably be the ones that spread Earth life the farthest.
Being the first intelligent species on this planet and being proud of that fact is not hubris and it isn't arrogant.
You don't know that humans are the first intelligent species on the planet. Humans have been around, at most, 2 million years, and I doubt that you'd claim that australopithecus was intelligent. Complex life has been around for on the order of several hundred million years.
It might be better to say that we're the first intelligent species to mess around with the planet enough that future species can't possibly miss the fact that we existed. Then again, the others might've just cleaned up more before they left.
Emulation is a catchall phrase for several things. WINE, for instance, means "Wine is Not an Emulator", because it isn't.
Emulation, by necessity, must involve a performance hit, because you have to have a lookup table in there between when you examine the operation and when you perform it. Fundamentally, "emulation", the true meaning of the word, has to be slower than a native implementation of the same thing.
However, what you claimed is that emulation must be slower than a completely different implementation of the same thing, which is just nonsense.
So, to recap:
TRUE: Windows drivers emulated on Linux will be slower than native Linux drivers.
FALSE: Windows drivers emulated on Linux will be slower than those same Windows drivers on Windows.
If you want examples, just go through Google and search for WINE performance. You'll find plenty of examples where WINE improved performance because the lower layers were faster.
Ha! You're kidding, right? In general, if you have good documentation on the chip you're working on, and maybe SOME info from the manufacturer, you're going to write better drivers than the manufacturer. Most Win32 drivers are written like crap, and are very hodgepodge. See, for instance, wireless drivers, which before WinXP, all used their own proprietary program to interact with the card (and in some cases, the WinXP program doesn't work, like the Cisco wireless cards), whereas under Linux, everyone just uses the iwconfig interface, including the proprietary drivers, like the ADM8211 based cards.
The name isn't that weird: "NCR" is a company, now Symbios, and tons of integrated circuits use the ##letter#####... pattern. The letter usually stands for the chip family, in this case CMOS. The first two digits are the family, the letter is the chip technology (lacking one means it's ancient TTL) and the last digits are the chip function.
A hobbyist trying to get a chip to work will more often than not stick closer to the specifications than the manufacturer, and usually build more stable drivers.
But anyway, there are plenty of native company-made Linux drivers out there. Browse the *actual* source of the drivers, and a lot of times you'll find, wow, amazingly enough, the company wrote the driver. (But not with the NCR53C875, which was written for BSD, though there is a plethora of information out there from LSI/Symbios/etc.).
Oxygen in the atmosphere.
Any significant amount of oxygen is almost certainly from something like photosynthesis. Oxygen's too reactive to stay in the atmosphere for any significant amount of time without something constantly generating it, and that's likely to be life.
Now, before everyone jumps down my throat saying "You don't need oxygen for life! Oxygen is poison! It's extremely dangerous!" - they'd be right, and wrong (as many people are...). Oxygen IS very reactive and corrosive - but that's why life wants it around. Oxygen generates a lot of chemical activity and a lot of chemical potential, allowing for complicated reactions to happen. This isn't "Earth-centric", it's basic chemistry.
And yes, even life in the ocean would likely generate oxygen in the atmosphere, and yes, it is possible to have life in the ocean WITHOUT oxygen in the atmosphere, but unless there's no solar insolation there at all, organisms that use sunlight will beat out those that don't virtually everywhere, and photosynthesis works best with oxygen involved in the process (to generate the many, many different oxidation potentials needed).
very high altitiude ballons (USAF project manhigh).
Ballons aren't going 17,000 mph with respect to the surface. They'd need more than a fire extinguisher for retrorockets - they'd need a compound that doesn't (and can't) exist. It's too much velocity to burn off any other way besides aerobraking.
Plus the stresses required to brake that much would kill a person instantly.
If you built something that the human could survive inside to withstand the stresses, congratulations, you've just rebuilt the shuttle.
It's not just "a lot" of heat. It's a metric ton of heat. It's several Library of Congresses of heat. No chance. No way.
Consider the ultimate extreme - a computer capable of analyzing the full search space of chess in 1 second (probably not possible to engineer using all the matter in the universe). This computer simply cannot lose against any player who isn't capable of doing the same. The program doesn't need to recognize patterns, it just picks the best route to victory under the current conditions, and adjusts it after each human move.
This is known as "solving chess". The important thing to realize is that a computer isn't the only way to do it. There's no reason a "perfect human" couldn't do it too, exactly the same way that humans do it now - by memorizing all significant patterns that could occur.
The problem with that method is that the concept of "significant patterns" requires intelligence (or better mathematics than simply 'I win') to determine whether or not a state is 'better' than another one. With the hypothetical "perfect computer", the route for solving is already known - it's "I win." vs "I lose." So, it's easier to get close to the "perfect computer" than a "perfect human".
This is exactly analogous to computers vs. humans in modern mathematics. Sure, a computer can calculate the next prime number by brute force and can do it much faster than a human. However, if a human develops a new algorithm to calculate the next prime number in a sequence, he'll arrive at some prime number much faster than a brute force method. The only question is does the algorithm exist, and how long does it take to find it?
Obviously this will never happen, but suppose you have a computer capable of fully searching 30 moves. I'd argue that no human could beat that either - while not a full game ahead it is close enough. Now consider 20 moves - we're still probably unbeatable. At this point we're just arguing degree - eventually a computer will come out capable of searching deep enough to beat a human.
C'mon, you're talking about memorization here. Humans now might not be able to beat the computer, but humans 20 years from now, after playing against these chess programs for 20 years, will easily be able to see just as far as the programs do, because it's all a matter of patterns, and the computers will value the same patterns (because that's what they're programmed to do), unless you believe that computer programs today are perfect, and there is no method of beating them (i.e. "chess is solved"), which I don't agree with. No computer has ever shut out a human, and remember, regardless of what some people might say, a human can't beat a computer "by luck", because the computer doesn't make mistakes. The fact that humans still draw computer programs tells me that the programmers are very smart, but there are still some portions of the game they (and probably the Grandmasters as well) don't understand.
Remember, the computers playing chess these days rely more on smarter software than brute force. They don't represent the state of the art in CPU power or storage. I'd argue that the best computers today running the best software would do even better than what we presently see, and eventually Moore's law will win out on humans.
They rely on smart software because it's the only way to solve the problem. Brute forcing it simply won't work, because you can't brute force to the only "tangible" solution: "I win" vs "I lose", so you have to make up a bunch of "intangibles" like king safety, piece mobility, and position. By valuing those intangibles, you're eliminating portions of the move tree, and opening yourself up to a pattern-recognizing human who may see a portion of the move tree you've eliminated as "bad".
Honestly, you're contradicting yourself here: the best software would not run tremendously better on better hardware, because it's still constrained by its own limitations - the "smarter software" part. No one in their right mind starts with the "brute force" method - they start with an opening playbook, and so long as they start with that, they've limited themselves.
i heard all of Kasparov's rant. he is well known in chess circles for a big mouth. The point is that he lost. He will lose again today. Period.
Kasparov? Kasparov wasn't the main one "ranting" - the main people "ranting" were the people who created OTHER chess programs, because when they competed, they were actually contributing to the field, whereas Deep Blue was simply a media event.
Think whatever you want about Kasparov, but the Deep Blue vs. Kasparov match will always have a mark next to it. You couldn't see the output of the program, you couldn't see the operators, you couldn't inspect the hardware or the software, and the hardware gets dismantled right afterwards.
But, if you run Deep Junior strength program on a cluster, there is no doubt that kasparov, kramnik and anand sitting togehter can draw against it.
What the heck? Why do you keep making the assumption that increased processing power = better chess program. Increasing the processing speed of a computer only improves traversing the move tree, and that part isn't the part that needs to be strengthened most significantly - it's the tree pruning logic and the "intangibles". Processing power won't make a brute-force approach computer realize "oh, wait, I really DO want to have control over the center of the board early in the game" until you're able to brute force a significant portion of the move tree.
Deep Junior will NOT get magically "super-better" when run on better hardware. It's the software, not the hardware. The authors themselves have already stated this.
No, I am not wrong. Look at the game where the human lost. It's all about probability, risk, and previous plays. Taking all those into consideration and making a partial tree of the "foreseeable future" will almost guarantee the computer a victory.
Will almost guarantee. The problem is that the computer can't think - it can just run what it was programmed to do. When a human sees that the computer is reacting to something, he changes his/her strategy - something the computer cannot do, if the human stepped outside the bounds of the programmed "forseeable future". That turns your almost guarantee into the episode of Star Trek where Data plays a strategy game perfectly against a human, and loses. When the human realizes the program's boundaries, the human has an advantage.
Your solution will only work when computers can reprogram themselves.
Look at the games where the human won. It wasn't because the computer ran out of time, or was under time pressure. It was because the human outplayed the computer - the human pushed the computer outside where it had pruned the move tree.
In several games the human operator had to offer to resign for the program, because the program hadn't realized that it had lost. Apparently its program didn't look down the portion of the move tree that was obvious to a human watching.
What we're comparing are two different methods to solving a problem: pattern recognition, and trial and error. Trial and error is impossible, because the state space is too large, as has been established, so programmers use tricks to trim the state space. The problem is if their tricks aren't perfect, pattern recognition can always win, because there exists a winning solution outside of the trimmed state space.
The original parent said that faster hardware => a guaranteed computer victory. This is plainly false: faster hardware will not eliminate the flaws in trimming the state space, and a good enough human player will be able to find the flaws.
Maybe someone will eventually write the "perfect chess program", which trims the state space perfectly into something manageable. But we're not there yet - no way.
Why do you think Kasparov lost to deep blue? Because they used more powerful hardware!! That was in last decade. If you spend the same amount of money today, you will get a computer so powerful that humans can dream of a draw againt that machine.
I'm guessing you didn't hear about any of the contraversy regarding Deep Blue vs. Kasparov. Deep Blue seemed like a computer built and programmed to beat Kasparov, not a general purpose chess program. There are other concerns (they didn't open up the source, etc.) - it's a longstanding controversy in chess programming.
and come up with a couple of novelties.
If you can have a computer do that, you've just solved the hard AI problem. The only known way for computers to play "good chess" is to brute force the move tree. If you want them to do better than that, you prune the tree, and program in a bit of logic. Logic doesn't improve with processor speed. Only brute forcing the move tree improves with processor speed, and we've already established that brute forcing the move tree is futile.
Look, the simple counterargument is that if computing power led to chess playing power, then the computing power of computers should be growing as processing speed, and it's not - computers haven't won a match vs a Grandmaster since Deep Blue, and see above regarding the controversy regarding Deep Blue, which is definitely well-founded. In fact, they've tied every match since what, 2000? And computing power has increased by how much since then?
It's not the hardware, it's the software. No one's repeated Deep Blue yet, so you can't "definitively" say that hardware wins.
Who knows, Deep Junior could've beaten Deep Blue. The controversy is that we'll never know, so your argument is all speculation that Deep Blue was super-ultra-mega-computer.
You're wrong.
None of the modern computers even considers brute-forcing the move tree - it's impossible. The search space is far too big, and considering some moves/board configurations can loop back on themselves, it's nearly infinite. Brute-forcing the move tree is simply useless.
That being said, all the major chess programs nowadays are not limited by hardware, but by software. Throw better hardware at them, and they will not play better chess.
Finally, Inflation Cosmology predicts that the Universe must have enough mass to keep it from flying apart forever, and that is even more mass.
Inflation cosmology predicts that omega = 1 - that is, there's exactly the critical density in the universe. It does not predict that it's all matter, or what it is at all.
Hence the reason we've got 70% dark energy, and 30% normal matter. Exactly the critical density, but it doesn't mean that we won't fly apart forever - if dark energy continues its wonderful negative-pressure inducing fun, we most decidedly will fly apart forever. That being said, not having a damned clue what the hell dark energy is, we can't predict anything at all.
The $60,000 dollar question is whether cold dark matter exists -- particles much more massive than a neutrino so they aren't zinging around so much that they can congregate in galaxies, but non-baryonic (i.e. some form of matter unknown to physics) but also weakly interacting like neutrinos (really hard to detect).
The parent's statement (massive neutrino) is not totally nuts. In fact, it's actually quite possible. We know that there are 3 neutrinos, and only 3 neutrinos (there are experiments in particle physics which directly give the # of neutrinos), but as far as I know, that's energy-range dependent- you have to conserve lepton number (and family lepton number) so if there is a "super-tau-neutrino", it wouldn't appear in particle accelerators until they could generate the energy of a "super-tau". If there's a 4th generation of matter, and that neutrino is ridiculously heavy (MeV-ish), that could make up all the lost matter.
That being said, it'd take a bit to figure out exactly *how* you make it so that it doesn't oscillate into other neutrinos, but the CKM matrix is a bit ad-hoc, so it's possible, I guess. Just not likely, at the moment. Besides, everyone loves axions and supersymmetric particles. Stuff like "gauginos" and "neutralinos" are too fun to say.
Yah, someone with one letter difference in name. That's quite frightening.
Actually, you're correct, and incorrect.
If the spins are antiparallel, the half-life is 10^-10 seconds (because they have a higher wavefunction overlap, since the total spin is 0). If the spins are parallel, the half-life is 10^-7 seconds (less overlap, so the phase space is smaller).
Actually, it's a meteoroid until it hits the atmosphere, a meteor in the sky, and a meteorite after that.
Asteroids are "large" rocks in space, with a poor distinction on what's "large" and what's not. It's unclear whether or not an object is a meteoroid or an asteroid, and unclear as to whether an asteroid entering Earth's atmosphere would be a meteor (then again, we'd be screaming for help, so it wouldn't much matter).
Finally, have you talked to your university's legal department? Is there any way that this project could belong to the Uni? Are you sure about that?
There's actually more than that, and I hope this comment (and yours!) gets noticed:
If he's an undergrad, or even a grad working at the University's campus, he may not be legally allowed to earn money for a project he's working on if he's using the University's resources. That means the ever-so-wonderful "massively fat pipe" that the University provides. You need to be very careful about doing things correctly with universities. Hell, I know for me (I'm a grad student), I'm not allowed to take another job (without explicit permission) - it's in my contract.
Universities are terrible at paying attention to legal details. You'll get away with absolute tons, for the most part. Every once in a while, though, someone jumps up and notices something, and tries to capitalize on it. You need to be very careful, because a lot of times, there is a lot of fine print.
As I have stated previously, SCO may have a case here.
Oh, yeah, SCO has a wonderful case. They've shown that malloc() and now, according to SGI, atoi() may have been copied from SysV.
For crying out loud, give me a break - we're talking about functions that companies ask prospective employees to pseudocode to prove that they know how to program! No court in this decade would possibly find for SCO.
I'd love to hear SCO come out and say "Yes, they've stolen our brilliant and amazing atoi() code! They never would have been able to come up with atoi() on their own!"
Somehow I think atoi(), malloc(), and even ate_utils are going to fall under the "who the hell cares??" category. SCO can't possibly win a case based on code like that. There's far too much precedence that they didn't defend it in other cases. Until they show code that a half-blind monkey with one hand couldn't generate, they're posturing, and nothing else.
Positronium.
It has a half-life of 0.1 uS. It's a relatively standard physics problem at the graduate school level to ask what the binding energy of positronium is.
If it ever comes up, it's (1/2) the binding energy of a hydrogen atom. The reasoning is simple - a positron and a proton have the same charge, but a positron and an electron have the same mass, so the "reduced mass factor" is 1/2, rather than 1. (M_p/(m_e+m_p) ~= 1) vs (M_e/(m_e+m_e) = 1/2).