I think a better analogy would be: If you can use any random car so long as it's got a wheel, brakes, gas pedal, and automatic transmission, you're just using it. If you can *only* use a Chevordiac Suburbiorer 2007 LE with the quad frobnitz and power frebit -- and you'll *die* if you don't -- you're a derived work, and your author (Your parents? God?) can be sued by Chevordiac for copyright infringement.
(While in some ideal world this might not be copyright infringement, we live in a world where it's been ruled illegal in the US to trade original DVDs for DVDs with the naughty bits edited out, and one where the US doesn't take kindly to countries that don't play ball by its rules. Sucks, I know.)
The only legal question in my mind is the difference between things like GNU Readline, where it's a reasonably sane interface that anyone could follow (even though it was the only implementation at the time), versus proprietary programs that delve into the innards of their own GPL libraries, or even a GPL library with icky Redmondian binary blob passing semantics where the interface and implementation are strongly coupled.
For the rest of my response, I'll follow your lead and truncate your post to soundbites.
...I've never seen it happen in Opera...
If you'd read my post, I said "mostly due to plugins" -- which you conveniently left out, and which affects Opera, Konqueror, and IE just as badly as Firefox. I've never had Firefox lock up hard past 1.0 that wasn't obviously related to a plugin (esp. Macromedia Flash or Adobe Acrobat) crashing the browser while loading/unloading a page. That's about as strong a promise as you can make when your product loads 3rd party native code.
...the problem is probably due to an extension...
There's a vast realm of difference between a plugin (executable native code) crashing the browser vs. an extension (XUL plus Javascript). The former crashing the browser is inevitable. The latter crashing the browser is sloppy, although some leaks are inevitable. (More on that in a bit.)
You said, "My gut says..."
Yup. I'm a programmer, have been since I was a wee one, been using C and C++ for 10 years, played with Object-Oriented Pascal back in the day, coded serious Java and Perl, written the occasional assembly, walked uphill in the snow both ways, etc. My gut is a finely crafted, state-of-the-art early warning system for catching bugs -- especially memory leaks, NULL pointer dereferences, double free() bugs, buffer overflows, yadda, after using C for that long. Like all heuristical systems it's far from perfect, with false positives and negatives both, but as an early warning system it works wonders. I haven't read the Firefox source code from top to bottom, although I'm fairly certain no lone human could, and I haven't even given it a serious skimming, so I don't have anything more than an educated guess to fly by. But I've seen some surprising interactions between "simple" GDI calls and Windows video card drivers, including previous ones where Firefox crashes under one driver version but runs fine after a driver upgrade (or even a downgrade). (This might or might not stem from the fact that, for speed, Firefox stores bitmaps in video texture RAM on Windows, and asks the X server to do the same on Linux.) I also know from past experience that HTML pages with <embed> and <object> tags crash all browsers far more often than HTML pages without, regardless of the browser in use (and not by virtue of the HTML itself, if you catch my drift). Video drivers and plugins are two likely suspects, and they're the first place I'd point gdb if I came across the RAM/CPU bug on my own machine.
...no one on the Mozilla Foundation team has investigated the CPU hogging bug...
Now, my memory may be faulty, but my entire post was based on reading someone's investigation into the RAM/CPU bug a few years back. Unfortunately, I didn't bookmark it and some creative googling hasn't turned it up. However, I did read Bugzilla in-depth to double check that I wasn't missing anything. (More on that in a bit.)
Just to make sure I wasn't missing anything, I did a fairly thorough sniff through Bugzilla. I searched all products for "leak", then personally read all 27 INVALID bugs and all 5 WONTFIX bugs. I didn't see one that wasn't legitimately so.
(Please note that Bugzilla forbids d
Re:Firefox is the most unstable program in common
on
Marketing Mozilla
·
· Score: 1
From what I've heard, the reason the RAM/CPU bugs keep getting shot down as INVALID or WONTFIX is that they cannot be reproduced by the would-be bugfixers. I, for instance, routinely have Firefox running for weeks at a time, have 5-10 tabs as a matter of course and sometimes hit 40+ tabs when going click-crazy in Wikipedia. I've been using Firefox/Mozilla since Milestone 18 (Oct 2000) and I've never hit the RAM/CPU bug (yes, people have reported the bug on the original Mozilla Suite, not just Firefox). I've had the whole browser lock up solid, mostly due to plugins (i.e. Flash and Acrobat), but I've never hit a memory leak or CPU hog bug.
My gut says there's something more to it than just a Firefox issue. Maybe it's plugin-related. Maybe it's a video driver issue -- seems unlikely, since I've heard of it happening under Linux, but given the spaghetti nature of the XFree86 code it's possible. Maybe it's something I'm missing. But it's not present in a default install of Firefox on most people's computers, including the developers, so nobody can fix it since nobody knows what's causing it.
Approaching it from an information science perspective, entropy is information. The flawless operation of the DNA -> DNA copying mechanism adds no information, but a flawed operation that introduces a mutation has novel information and, ipso facto, must drain information entropy out of the local environment and into the DNA. Entropy here acts as a "limiting reagent" of sorts for the "product" of mutation. (This is the same reason that a microprocessor draws more Watts at higher speeds.)
Approaching it from a physics perspective, entropy is energy "wasted" by causing movement along "undesired" degrees of freedom (i.e. heat). Any machine (including one made of enzymes) is more likely to cease functioning as local entropy increases, because a machine has "undesirable" degrees of freedom (i.e. operational tolerances). As entropy within the machine increases, the components migrate along their degrees of freedom until the machine as a whole is outside operational tolerances and no longer performs its intended function. (This is the same reason that a microprocessor, when allowed to run at too high a temperature, will start making errors like bit-flips, and perhaps even be irreparably damaged due to dopant migration.)
Yes, crossover is awesome for us animals, just as plants use polyploidy plus haploidization, and bacteria use plasmids. (Yeast apparently have something freaky and poorly understood that I won't embarrass myself by trying to explain. Ask Belgand.) All these techniques slosh DNA around the gene pool, which is perfect for getting those XP patches out in a timely manner -- er, mixing new mutant alleles into the population -- but none of them creates novel alleles, which was what the OP was complaining about. They reduce the downsides of mutation, but they ultimately depend on it.
As an addendum: Now that I think of it, the macroevolution "problem" only exists because "species" is a fuzzy word without a clear scientific definition. The most commonly spouted one is "capable of interbreeding with fertile offspring", but that would make lions and tigers the same species, which they're obviously not. (There are other exceptions, even more numerous, in the plant world.) However, in ring species, you have individuals that cannot directly interbreed, but can interbreed via an intermediary. (Even Canis lupus familiaris, the domesticated dog, might speciate at some point due to human selection. The wide variety in breed sizes means that small and large dogs are physically incompatible and cannot naturally mate, and purebreeding will just make the problem worse as time goes on.) Even worse, bacteria and archaea don't usually reproduce sexually, and when they do share DNA, they often do so by trading plasmids. Plasmid swapping sometimes happens even between distantly related species -- with some DNA comparisons even suggesting that plasmid exchange happens between eubacteria and archaea, two different kingdoms/domains! There's not really any good way to define an asexual species beyond "Hmm, that one looks different from the others".
Most of the fuzziness is due to the Platonic idea of Forms that's inherent in the word "species" -- the idea that each individual is merely an imperfect implementation of a true, perfect, eternal Form, which we can attach a convenient name to. In evolutionary biology, the concept of Platonic Forms is an outright error; individuals are exactly that, individuals. From the perspective of an individual, the species only matters to the extent that (a) the individual can interbreed with other members of the species, and (b) the individual can cooperate with other members of the species for mutual benefit. Everything else that we attribute to the word "species" has more to do with Plato than reality.
(Medieval scholars so deeply infused Platonic ideas into Western philosophy and Christian theology that Forms are sometimes considered a religious or even fundamental truth, when really it's more of a psychological one -- human brains like to neatly stuff things into orderly pigeonholes with cute labels. Sadly, Platonic thinking has boxed in scholarly thinking in many ways, even among scientists, but there's not an obvious way around it. In some fields, like particle physics, it's not a big deal -- leptons pretty much are Plato's Forms given form *cough* -- but in biology it's an issue that sometimes can't be sidestepped. Even if you discard Forms and throw out labels like "species" and "genus", you need to rebuild a common nomenclature so you can talk about biology with other scientists, which puts you back where you started.)
I'm sorry you haven't been paying attention, but this happens all the time. It's called mutation. You can get point mutations (affects just one base pair), deletions (a chunk of DNA is accidentally removed, and the remaining ends are stitched up), insertions (a new chunk of DNA added where it doesn't belong, sometimes smack in the middle of an existing gene), transpositions (a deletion at one site, and an insertion somewhere else), repeat errors (a segment of DNA trips up the cellular machinery and gets duplicated multiple times, like a skipping record), and many others. Combine these, and the result is new DNA.
Most mutations are generally caused by errors in the cellular machinery, although there can be other causes (radiation, dormant retroviruses, etc.). Machinery errors are caused by entropy, so raising the temperature increases the number of errors. This means it's quite easy to induce mutations in the lab by controlling the temperature of a cell culture. (Incidentally, the temperature-error connection is the reason men have a scrotum. If the testicles are too warm, too many of the resulting sperm cells have lethal mutations, leading to reduced fertility and a higher rate of birth defects. Just ask any fertility doctor. Mutations are an everyday fact of life, even within our own bodies.)
Most mutations do nothing at all. Those that do something are usually harmful. However, as one example, our ability to see the difference between red and green probably came from an insertion mutation (in this case, one gene accidentally turned into two genes for the same protein) followed by a small number of point mutations (leading to two genes for two separate proteins, namely Photopsin I and Photopsin II). The intermediate point mutations would have been harmful if they'd happened to the only copy of the photopsin gene, but they were beneficial when they happened to a spare. Many times, if a gene is duplicated by an insertion, one copy can go on to mutate dramatically while the other copy remains unmolested, sometimes resulting in two very similar genes with nearly unrelated roles. (This is because just a handful of changes in the amino acid chain can radically alter the tertiary and quaternary shape of the protein, and the shape of a protein determines what it does. Unfortunately, computing the folded shape of a protein is fiendishly difficult, which is why massively distributed projects like Folding@Home exist.)
Really, mutations are quite heavily studied and, in contrast with your claims, there's some very direct evidence for them. Even the Creationism/ID folks generally don't argue with microevolution (changes within a species), and mutation is required for microevolution to happen. Your position is really out on a limb. What's more, if you don't accept duplication plus point mutations as DNA "being generated/created", then you're essentially faulting God for not magically snapping His fingers for you and instead doing it the boring, step-by-step way. God has more important things to do than please your sense of aesthetics.
What do you think the "Scripting" in "Cross Site Scripting" refers to? It refers to client-side javascript. Please read some Bugtraq, or at least this FAQ or the Wikipedia article. (The Wikipedia article is the easiest read. In particular, the section on types of XSS problems is edifying.) Your example is a straightforward input validation bug in the browser, and it doesn't involve any scripting at all, cross-site or not, and therefore is not an XSS anything. It's just a malicious input that exploits a browser bug.
In stark contrast with an XSS flaw, your example is not the site's fault, and there's very little that realsite.com can do about it. A smart site that uses a whitelist approach to user-posted URLs might refuse to let a user post such a link, but it's squarely the browser's fault for mishandling a faulty input, not the site's fault for having the link. The smart site refusing to post funky links is merely doing a service to all the stupid programmers out there. Faulty inputs happen all the time in the real world -- typos, human errors, the occasional corrupt file -- and any browser that doesn't say "Whoa! What the heck am I supposed to do with that?" is a buggy browser.
(Sadly, when it comes to malformed HTML, the "buggy" adjective applies to AFAIK all browsers today, including the lowly Lynx. Google for "HTML fuzz" if you're curious. Some hold up better than others, though, and IE is by far the worst of the lot. What's worse, when it comes to malformed URLs, IE itself has historically been a disaster, with about 2-3 times the URL bugs as the Mozilla codebase, and scarily almost all non-browser software that registers third-party URL handlers either (a) can be exploited today, or else (b) has been exploited in the past and survived a brutal trial by fire. I'm thinking of AIM in particular for the latter.)
The article uses an awful example of an XSS exploit. The vast majority of XSS exploits don't have to jump through the hoop of an HTTP POST, so they're mindlessly simple to pull off, and there's no phishing involved. Plus, the fact that he used a proxy to modify his own web browsing is a complete red herring and detracts from the article.
In contrast to phishing (and in contrast to what's been said in most of the posts so far), an XSS exploit is a legitimate link to the target website. No amount of looking at the host part of the URL will tell you that it's a phish, because it truly, honestly isn't. If you take the time to manually browse the GET parameters individually before you click the link, you might catch that it's an XSS exploit (or an attempt at one) if you know some HTML and Javascript.
What's worse, though, is that instead of a clickable link, the exploit could even be the URL of an <iframe> tag. Completely automatic, no clicking required, and AFAIK no modern browser allows the user to disable or manually confirm <iframe> tags. Even worse, XSS attacks on some sites are persistent and shared. For instance, if someone home-rolls their own comment system and forgets some checks, it might be possible to post an XSS exploit in the subject line of the comment, which not only affects everyone who reads the post, but also everyone who even reads a list of new messages.
The important characteristic of an XSS attack is that, unlike most web-based attacks, XSS attacks are exploiting the website itself -- not you, and not your browser. You click the link, the website ships some HTML to your browser, and whaddya know, there's one of them newfangled <script> tags to run.... The injected Javascript code, which the webmaster didn't intend but nonetheless his website actually delivered to your browser, runs with the same permissions as any of his own code, which includes access to the document.cookie property. Since most websites these days stick session IDs or even *groan* username/passwords in cookies, all it takes is for the Javascript to e.g. generate an <img> or <iframe> tag that points to the attacker's website, with '?'+document.cookie tacked onto the end of the GET request. Now the attacker can log in as you, and can explore other, non-XSS exploits that require him to be logged in.
Your only recourse as a user is to disable Javascript. Full stop. You can't even enable it on "trusted" sites, because if you mark them as "trusted", you're saying "I trust that this website will never, ever be hacked so long as I live". One or more of your "trusted" sites might have undiscovered XSS flaws in their backends, and you can't "untrust" them faster than the blackhats can exploit them.
There is nothing, I repeat nothing that you can do as a user or as a browser designer that will simultaneously (a) prevent XSS and other server-side exploits, and (b) allow the features that modern web sites depend on by design. If you think you want a browser that's completely safe from server-side exploits, spend a week browsing the web using strictly Lynx, then see if you're still of the same opinion. (While XSS requires Javascript to pull off, there are other server-side data validation problems on many websites, and those can be exploited by something as innocuous as a CSS stylesheet reference.)
So? While it wouldn't be exactly trivial to create a BitTorrent-like multicast protocol, it'd be fairly straightforward. Hell, if I were to code up a very rough prototype all by myself, I can't see it taking me more than three weeks, and most of that would be protocol design. Once it'd been implemented once, it'd get steamrolled into most of the BitTorrent clients out there in a matter of 3-6 months as an option, just like every other new BT feature. Of course, without a multicast-capable Internet, nobody's going to bother.
Sort of. The binary blob constitutes nVidia's shared driver codebase between Windows and Linux. It exposes some intermediate functionality, which the wrapper layer thunks to. However, the binary blob itself doesn't constitute a driver, for any OS. The wrapper code for the Linux driver, however, falls under the GPL's rule because it legally counts as a derivative work of the Linux kernel. Since a derivative work plus something else is still a derivative work, the final compiled driver is still under the GPL's rule, even though most of the functionality is contained in the proprietary binary blob. And, while there's nothing wrong with doing that as an individual on your own computer (the GPL is a copyright license), you can't distribute the resulting mess legally.
You've got the gist of it, but I just want to clarify for other readers.
The way it works, from a copyright holder's perspective, goes something like the following. By releasing your work under the GPL, you have irrevocably given the permissions listed therein to anyone who receives a copy. As the copyright holder, you can go back and relicense it (whether more or less restrictive), but people will always be able to keep distributing the GPLed copies, since the GPL cannot be revoked.
(Something like this happened with Secure Shell, except the old SSH license was BSD-like. Any free software license will, ipso facto, be irrevocable due to the distribution model, and the GPL is not in any way unique in that regard. That's why Sun doesn't let you redistribute Java after you download it.)
Beyond that, a catch is that the exact wording of the GPL is itself copyrighted by the FSF, and the terms on redistributing the GPL itself read: "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." This means that, if you want a license that works like the GPL but isn't the actual FSF GPL, you (a) have to write it from scratch yourself (or pay your lawyer to do it) to avoid creating a derivative work that violates the license on the GPL, and (b) you can't call it "GPL", since it would be fraud to misrepresent your own custom license as the genuine FSF GPL (although, technically, the FSF doesn't explicitly own a trademark on the name "GNU General Public License").
If you need to, you can get around this by using a disjunction of licenses ("You may distribute this software under ANY of these licenses"). If you really, really need to, some programs have been distributed under a conjunction of licenses ("You may distribute this software only if you meet the terms of ALL of these licenses"), which ended up the case with the OpenSSL license (which is a bit of a trainwreck due to hysterical raisins). And, in very rare cases, you can ask the FSF for permission to modify the GPL (see the Affero license).
I for one have a nvidia binary kernel module loaded which would never have been allowed if RMS ran the project or had any meaningful involvement in it - and I'm fairly sure the new version of the GPL would prohibit that sort of thing.
Actually, the GPLv2 prohibits it, too. It's quite against the letter of the current GPL to distribute nVidia's binary-blob driver with the Linux kernel, as the nVidia driver is clearly a derived work of the Linux kernel (i.e. you need kernel source code to compile the wrapper that turns the binary blob into a driver -- the finished driver doesn't make any sense without a Linux kernel to go with it, so the kernel plus driver equals a derived work). This is why the handful of distros that currently distribute binary blobs are moving away from them, and the smart ones require you to compile the blobs into drivers yourself (albeit with automated wrappers around the process). It's only by the good graces and/or ignorance of various Linux copyright holders that nobody's been sued over it yet.
English isn't so much "sloppy" as it's a medley of rules, cherry-picked from all the parent languages. (Programmers: English is a good example of why Multiple Inheritance is often a Bad Idea.) First, you have the basic German roots that generate most English grammar and syntax, as well as a solid amount of vocabulary. While that German system was evolving to drop inflection (e.g. "the" vs. "der, die, das..."), the Normans invaded England and brought early French with them. French, a Latin language, was itself rapidly evolving to an inflection-free form at the time. On top of that, you had the Church (there only being one at the time) dominating scholarly discussion, which injected some old-school Latin loanwords into the mix. Pouring all those ingredients into one stew is, of course, bound to produce interesting results.
In the aftermath, with the French-speaking Normans solidly established as the ruling class, the Germanic-speaking lower classes sought to imitate them. (This is a recurring theme in history; just look at any celebrity-worship magazine for a modern example.) They started borrowing French loanwords and, more importantly for this discussion, started pronouncing old German words in a more "French-like" manner. In addition to adding lots of silent letters and simplifying all the old German consonant clusters, this process somehow triggered the Great Vowel Shift, which completely threw out the old German-derived spelling rules for vowels, which had been nearly equal to the Latin ones up until then. In the process, most diphthongs (a smooth slide from one vowel into another vowel) turned into monophthongs (a single vowel sound), even though the spellings still had two letters.
When the dust settled and spelling started to renormalize in Shakespeare's time, people started noticing patterns like "i before e" ("-ie-" became a way of spelling what's now called "Long E") "except after c" ("-cei-" is a common pattern in Latin and French words but rare in German ones, and French was considered "more proper" at the time) "or in words with an 'a' like 'neighbor' and 'weigh'" ("-ei-" became a way of spelling "Long A"). The patterns were eventually turned into little rhymes as a mnemonic, which then were taught to children learning to read, helping to establish the new spelling rules.
And that's why we spell "knight" as "nuh aye t" instead of "kuh nee guht". (The snooty Frenchman in Monty Python and the Holy Grail was actually not far off in his pronunciation from actual Old English. The final "-ght" just runs together a lot faster.)
(BTW, EM64T = shameless clone/re-branding of x86-64, which is an open standard created by AMD. A rare case of Intel not succumbing to Not Invented Here syndrome. From here on, I'll lump them both under the name "AMD64".)
FWIW, I have very little hands-on experience (not being a frequent programmer of x86 assembly), but there are two big features of AMD64 that stand out: more registers (which helps compilers especially), and addressing relative to %rip (the 64-bit Instruction Pointer). The former lets you compute more things on-the-fly without reserving stack space for temporary variables, which can cut down on round trips to L2 or main memory -- thus making AMD64 a bit more like a RISC system, while leaving behind the ivory tower "orthogonal" (read: code-bloating) instruction sets that RISC forces on you. The latter lets your code reference constant things like strings (which are generally compiled into the.text section, right alongside the code that uses them) without [PIC] reserving a register for it, or [non-PIC] hardcoding the address. This simplifies the build process for a LOT for programmers.
Quick tutorial on PIC:
Let's say I have a function, void hello() { printf("Hello, World!\n"); }. If I compile and link this code normally, I get something that looks like push $0x80484b8; call printf, where 0x80484b8 is a hard-coded address located in the.text section (or else a section for data constants that can be found relative to.text). If you're building an executable, that's fine, since the location of.text will be known at link-time.
However, if you want to bundle your code into a shared library, that won't do at all. Each program that loads your library will load it at a different address, so.text could be anywhere in memory. On a modern system, you can add a fixup so that the dynamic linker patches your code on the fly, but now your "shared" library has one copy in memory per instance, even if it's all instances of the same program. That's worse than a static library! The solution is called PIC, Position Independent Code, and is invoked with -fPIC when using GCC. On x86, it usually looks something like this: call.Lfixup;.Lfixup: pop %ebx. Since x86 provides relative jump/call instructions, you can call to.Lfixup without knowing the absolute address, which pushes %eip on the stack as the return address. After the pop, %ebx now contains the absolute address of the.Lfixup label at runtime, and you can safely access your constants relative to that. (All that fuss just because you can't use %eip directly.)
On the downside, you've now eaten a register (on the already register-starved x86 architecture) and you've blown away most branch predictors, forcing a pipeline stall. Not a biggie if you just do it once in main() or similar, but since this might be a library function, you have to do it each time the function is called, in each function that needs it. Ew. It works, but it's not elegant, and it eats performance very badly if you call a PIC function from within an inner loop, so a lot of programmers just tell their tools to compile the entire program twice: once with PIC, and again without. (That's what all those *.lo files are from GNU libtool.)
AMD64 allows compilers (and assembly writers) to unify PIC and non-PIC code into a single, efficient path. Instead of jumping through hoops to copy %rip to %rbx and locate your constants relative to %rbx, you can just address your constants relative to %rip directly. There's no longer any penalty for using PIC, so compilers can just turn it on by default, saving the world from millions of tiny hassles that add up to one big Ick. It's probably the single most real-world useful thing they could have possibly added to the x86 instruction set.
"The Reagan years were the worst. And the Bush years. They were the worst, too. The Clinton years I didn't enjoy at all. After that I went into a bit of a decline..."
Don't know why that popped into my head, but it seemed apropos.
How long did it take you to hit 40? At 5 hours a week, you must've been playing for at least 3 months or so. If you'd planned ahead a bit, you could've bought your mount the moment you hit 40, like I did, and without paying the gold farmer tax.
There are plenty of ways to make decent loot using legitimate, in-game avenues. The easiest? Three words: Savory Deviate Delight. The hard part is getting the cooking recipe. Unless you're Alliance on a PvP server, it's easy to fish a 20-stack of Deviates in an hour or less (twice or triple that amount if nobody else is fishing up the schools). On Thrall, that can equal 10 gold on the Alliance or Goblin auction houses, or even more on older servers. Even as little as you play, 90 gold should be easily achievable in less than 2 weeks under worst-case conditions, and you get to relax and watch the scenery while you do it.
I wish I had mod points today. You are exactly correct, people buy gold so they can skip a lot of the game. The reason they do this is because WOW is perhaps the most boring RPG ever created.
I'm sorry, but you've obviously never played any other MMO out there. WoW is, in fact, the least boring MMORPG ever created. Most of the quests aren't very imaginative, true, and it starts to be a grind around 35-40ish, but on the boredom front, it's a breath of fresh air compared to other MMOs.
I previously had the misfortune of playing Dark Age of Camelot. Now that is a boring RPG. In the time I played it, I felt like I hadn't made any progress at all. What little I do remember of quests and the like was exactly the same format as WoW: "Kill 10 of these", "Kill that guy over there", etc., except that WoW at least mixes things up every now and then. However, in stark contrast with DAoC, WoW actually has enough of an interesting story that I have, on a few rare occasions, felt immersed in my character and the gameworld, something that had previously happened for me only in pencil-and-paper RPGs.
And while DAoC is a particularly bad offender in the boredom department, what I've heard from friends that have played them is that most other MMORPGs are much more grind-intensive than WoW, and that WoW was a breath of fresh air for them as well. (If you haven't guessed by now, I've never bought anything from the farmers. I bought my mount the moment I hit 40 with my own hard-earned gold, and you know what? I had fun earning it.)
Now, if you want to take aim at WoW, aim at the endgame content. Once you hit 60, you're pretty much consigned to either PvP or to massive dungeon raids that require a meatspace schedule that will accomodate them. Casual, solo content pretty much evaporates at 60. But don't pin the sins of MMOs as a whole on Blizzard.
The difference between "mind prediction" and "mind reading" is one of definition, not evidence. It's like arguing that "blue" and "orange" might actually be the same color, and that it's up to someone else to prove that "blue" and "orange" are actually different colors.
The No Cloning Theorem is a mathematical proof, not a scientific theory. It proves that either you cannot clone a qubit (and thus cannot communicate via quantum entanglement) OR that you can travel backwards in time. And as fun as it sounds in sci-fi, traveling backwards in time has such drastic implications that it would make the world a downright scary place.
In contrast, nobody ever "proved" that flight was impossible. (If that were true, how do birds fly? Obviously it's possible.) It was instead a question of engineering and materials science, i.e. "with current technology, we believe that human flight is impossible" (or would have said so if they'd been making a scientific statement -- most of the out of hand dismissals were off-the-cuff opinions, not carefully researched statements). Likewise with the sound barrier.
The only way the No Cloning Theorem could apply is if quantum mechanics is all a bad dream and qubits don't exist. (This would be unprecedented in all of science, to have a new theory that says the old theory was outright Wrong. As radical as Relativity is, it reduces to Newton's laws at low speeds. Likewise, quantum mechanics reduces to classical mechanics at large sizes. We've sent qubits, so even if Quantum Mechanics is wrong, any new theory must have qubits -- or else have a really good explanation for why the Bell Inequalities are violated in QM.)
It's concievable that humans have some form of radiation or radio-frequency that we use to communicate, or we could have neurochemicals that become quantum-entangled with those in other brains. And it certainly would use energy -- maybe not hundreds of kilocalories, but something.
WRT radio, that's conceivable, but EM transmission generally requires an antenna (i.e. a continuous conductor of the appropriate length that can handle an alternating current, so nerves don't work). Low frequencies can transmit over long ranges with less power, but require a larger antenna and can hold less data. High frequencies use smaller antennas and can hold more information, but require more power for the same transmission distance. A biological structure being used as an antenna would certainly have shown up on an MRI or the like, if it were long enough for low frequency EM. That means that any EM-based telepathy would have to be very high frequency and thus have exceptionally short range (a couple of feet at most, sort of a "Psychic Bluetooth") or it would cause a massive, measurable dip in blood sugar levels when used. Plus, it seems unlikely that such signals would have escaped detection, as they would probably interfere with MRI scans of the brain.
As far as the other known forces go, the weak force is ruled out (can't be used to transmit, it just doesn't work like that), the strong force is ruled out (it's attracted to itself, so it can't go far, not even between atoms in a molecule), and gravity seems outlandish beyond reason (our best gravity wave detectors are miles in size, and we can't imagine any way to make them in miniature -- gravity is 10^40 times weaker than EM). We have very solid reasons for suspecting that there are no undiscovered forces (why would they affect human brains but nothing else?), and unless you count pheromones as telepathy (why not?), we don't shoot any matter-based particles out of our skin. So, as unlikely as it is, EM is the only obvious candidate.
WRT quantum entanglement, there are two problems. One, entanglement works by entangling two particles, then separating them by physically moving them without touching them. (Touching destroys the coherence, because if an object touches the particle, the object "measures" it in the process. That's the short version.) Human beings don't have fiber optic cables hanging out of their skulls to transmit entangled particles in a quantum-coherent environment (which is how the 10km entanglement experiments work -- photons don't "touch" fiber optics). Two, quantum entanglement has been proven, via the No Cloning Theorem, to be incapable of transmitting information. It's mathematically proven that, if quantum entanglement can transmit information, then time travel is possible. (Worse, it's time travel of the causality-violating sort. Scientists generally discount any theory that would allow the Grandfather Paradox, on the basis that it's a huge, blinking, neon sign that reads "Apply Occam's Razor HERE!" There's absolutely no evidence for it, yet it's something so Earth-shattering that if it were true, there should be oodles of evidence for it, at the subatomic level at least [we should see cosmic rays that traveled backwards in time all across the sky]. It also kicks out from under us the fundamental idea that time has a direction, and the idea that it's possible even in principle to predict what might happen in the future based on what is happening in the present, i.e. science. By definition, that's what "causality" is.)
In reality, quantum entanglement works "faster than light" in the same way that I can swing my flashlight from one star to another "faster than light". Someone at one star can't use my flashlight to transmit information to someone at the other star. Worse, unlike my flashlight analogy, you can't even use quantum coherence to coordinate both parties doing something at the same time.
FWIW, the Universe at the moment of the Big Bang was not simply "a ball of matter", but rather "a ball of spacetime". According to the theory, time and space did not exist until the moment of the big bang, so the notion of "before" is meaningless in this context. (In theology, it's like asking "What existed before God?" or "What did God do before creating the Universe?", or in computing, "What if Microsoft wrote a bug-free version of Windows?")
Sorry, but floppies died when Verbatim and the like pushed the prices on floppies down so low that everyone else had to drop all quality control to compete. Any floppy disk made after 1997 or so will develop bad sectors if you so much as make a rude face at it. Out of necessity, I now treat floppies as write-once media.
Slashdot Mirror
I think a better analogy would be: If you can use any random car so long as it's got a wheel, brakes, gas pedal, and automatic transmission, you're just using it. If you can *only* use a Chevordiac Suburbiorer 2007 LE with the quad frobnitz and power frebit -- and you'll *die* if you don't -- you're a derived work, and your author (Your parents? God?) can be sued by Chevordiac for copyright infringement.
(While in some ideal world this might not be copyright infringement, we live in a world where it's been ruled illegal in the US to trade original DVDs for DVDs with the naughty bits edited out, and one where the US doesn't take kindly to countries that don't play ball by its rules. Sucks, I know.)
The only legal question in my mind is the difference between things like GNU Readline, where it's a reasonably sane interface that anyone could follow (even though it was the only implementation at the time), versus proprietary programs that delve into the innards of their own GPL libraries, or even a GPL library with icky Redmondian binary blob passing semantics where the interface and implementation are strongly coupled.
For the rest of my response, I'll follow your lead and truncate your post to soundbites.
If you'd read my post, I said "mostly due to plugins" -- which you conveniently left out, and which affects Opera, Konqueror, and IE just as badly as Firefox. I've never had Firefox lock up hard past 1.0 that wasn't obviously related to a plugin (esp. Macromedia Flash or Adobe Acrobat) crashing the browser while loading/unloading a page. That's about as strong a promise as you can make when your product loads 3rd party native code.
There's a vast realm of difference between a plugin (executable native code) crashing the browser vs. an extension (XUL plus Javascript). The former crashing the browser is inevitable. The latter crashing the browser is sloppy, although some leaks are inevitable. (More on that in a bit.)
You said, "My gut says..."
Yup. I'm a programmer, have been since I was a wee one, been using C and C++ for 10 years, played with Object-Oriented Pascal back in the day, coded serious Java and Perl, written the occasional assembly, walked uphill in the snow both ways, etc. My gut is a finely crafted, state-of-the-art early warning system for catching bugs -- especially memory leaks, NULL pointer dereferences, double free() bugs, buffer overflows, yadda, after using C for that long. Like all heuristical systems it's far from perfect, with false positives and negatives both, but as an early warning system it works wonders. I haven't read the Firefox source code from top to bottom, although I'm fairly certain no lone human could, and I haven't even given it a serious skimming, so I don't have anything more than an educated guess to fly by. But I've seen some surprising interactions between "simple" GDI calls and Windows video card drivers, including previous ones where Firefox crashes under one driver version but runs fine after a driver upgrade (or even a downgrade). (This might or might not stem from the fact that, for speed, Firefox stores bitmaps in video texture RAM on Windows, and asks the X server to do the same on Linux.) I also know from past experience that HTML pages with <embed> and <object> tags crash all browsers far more often than HTML pages without, regardless of the browser in use (and not by virtue of the HTML itself, if you catch my drift). Video drivers and plugins are two likely suspects, and they're the first place I'd point gdb if I came across the RAM/CPU bug on my own machine.
Now, my memory may be faulty, but my entire post was based on reading someone's investigation into the RAM/CPU bug a few years back. Unfortunately, I didn't bookmark it and some creative googling hasn't turned it up. However, I did read Bugzilla in-depth to double check that I wasn't missing anything. (More on that in a bit.)
Your googling, OTOH, showed me two things: (1) a sizable number of people misinterpret the in-RAM cache and Back/Forward cache as memory leaks, not features; and (2) several extensions do/did cause Javascript memory leaks, but are being rooted out one by one (via debug builds and the Leak Monitor extension).
Just to make sure I wasn't missing anything, I did a fairly thorough sniff through Bugzilla. I searched all products for "leak", then personally read all 27 INVALID bugs and all 5 WONTFIX bugs. I didn't see one that wasn't legitimately so.
(Please note that Bugzilla forbids d
From what I've heard, the reason the RAM/CPU bugs keep getting shot down as INVALID or WONTFIX is that they cannot be reproduced by the would-be bugfixers. I, for instance, routinely have Firefox running for weeks at a time, have 5-10 tabs as a matter of course and sometimes hit 40+ tabs when going click-crazy in Wikipedia. I've been using Firefox/Mozilla since Milestone 18 (Oct 2000) and I've never hit the RAM/CPU bug (yes, people have reported the bug on the original Mozilla Suite, not just Firefox). I've had the whole browser lock up solid, mostly due to plugins (i.e. Flash and Acrobat), but I've never hit a memory leak or CPU hog bug.
My gut says there's something more to it than just a Firefox issue. Maybe it's plugin-related. Maybe it's a video driver issue -- seems unlikely, since I've heard of it happening under Linux, but given the spaghetti nature of the XFree86 code it's possible. Maybe it's something I'm missing. But it's not present in a default install of Firefox on most people's computers, including the developers, so nobody can fix it since nobody knows what's causing it.
Same thing, two approaches:
Approaching it from an information science perspective, entropy is information. The flawless operation of the DNA -> DNA copying mechanism adds no information, but a flawed operation that introduces a mutation has novel information and, ipso facto, must drain information entropy out of the local environment and into the DNA. Entropy here acts as a "limiting reagent" of sorts for the "product" of mutation. (This is the same reason that a microprocessor draws more Watts at higher speeds.)
Approaching it from a physics perspective, entropy is energy "wasted" by causing movement along "undesired" degrees of freedom (i.e. heat). Any machine (including one made of enzymes) is more likely to cease functioning as local entropy increases, because a machine has "undesirable" degrees of freedom (i.e. operational tolerances). As entropy within the machine increases, the components migrate along their degrees of freedom until the machine as a whole is outside operational tolerances and no longer performs its intended function. (This is the same reason that a microprocessor, when allowed to run at too high a temperature, will start making errors like bit-flips, and perhaps even be irreparably damaged due to dopant migration.)
Yes, crossover is awesome for us animals, just as plants use polyploidy plus haploidization, and bacteria use plasmids. (Yeast apparently have something freaky and poorly understood that I won't embarrass myself by trying to explain. Ask Belgand.) All these techniques slosh DNA around the gene pool, which is perfect for getting those XP patches out in a timely manner -- er, mixing new mutant alleles into the population -- but none of them creates novel alleles, which was what the OP was complaining about. They reduce the downsides of mutation, but they ultimately depend on it.
As an addendum: Now that I think of it, the macroevolution "problem" only exists because "species" is a fuzzy word without a clear scientific definition. The most commonly spouted one is "capable of interbreeding with fertile offspring", but that would make lions and tigers the same species, which they're obviously not. (There are other exceptions, even more numerous, in the plant world.) However, in ring species, you have individuals that cannot directly interbreed, but can interbreed via an intermediary. (Even Canis lupus familiaris, the domesticated dog, might speciate at some point due to human selection. The wide variety in breed sizes means that small and large dogs are physically incompatible and cannot naturally mate, and purebreeding will just make the problem worse as time goes on.) Even worse, bacteria and archaea don't usually reproduce sexually, and when they do share DNA, they often do so by trading plasmids. Plasmid swapping sometimes happens even between distantly related species -- with some DNA comparisons even suggesting that plasmid exchange happens between eubacteria and archaea, two different kingdoms/domains! There's not really any good way to define an asexual species beyond "Hmm, that one looks different from the others".
Most of the fuzziness is due to the Platonic idea of Forms that's inherent in the word "species" -- the idea that each individual is merely an imperfect implementation of a true, perfect, eternal Form, which we can attach a convenient name to. In evolutionary biology, the concept of Platonic Forms is an outright error; individuals are exactly that, individuals. From the perspective of an individual, the species only matters to the extent that (a) the individual can interbreed with other members of the species, and (b) the individual can cooperate with other members of the species for mutual benefit. Everything else that we attribute to the word "species" has more to do with Plato than reality.
(Medieval scholars so deeply infused Platonic ideas into Western philosophy and Christian theology that Forms are sometimes considered a religious or even fundamental truth, when really it's more of a psychological one -- human brains like to neatly stuff things into orderly pigeonholes with cute labels. Sadly, Platonic thinking has boxed in scholarly thinking in many ways, even among scientists, but there's not an obvious way around it. In some fields, like particle physics, it's not a big deal -- leptons pretty much are Plato's Forms given form *cough* -- but in biology it's an issue that sometimes can't be sidestepped. Even if you discard Forms and throw out labels like "species" and "genus", you need to rebuild a common nomenclature so you can talk about biology with other scientists, which puts you back where you started.)
Two words: Ring Species. Macroevolution, as it's happening.
I'm sorry you haven't been paying attention, but this happens all the time. It's called mutation. You can get point mutations (affects just one base pair), deletions (a chunk of DNA is accidentally removed, and the remaining ends are stitched up), insertions (a new chunk of DNA added where it doesn't belong, sometimes smack in the middle of an existing gene), transpositions (a deletion at one site, and an insertion somewhere else), repeat errors (a segment of DNA trips up the cellular machinery and gets duplicated multiple times, like a skipping record), and many others. Combine these, and the result is new DNA.
Most mutations are generally caused by errors in the cellular machinery, although there can be other causes (radiation, dormant retroviruses, etc.). Machinery errors are caused by entropy, so raising the temperature increases the number of errors. This means it's quite easy to induce mutations in the lab by controlling the temperature of a cell culture. (Incidentally, the temperature-error connection is the reason men have a scrotum. If the testicles are too warm, too many of the resulting sperm cells have lethal mutations, leading to reduced fertility and a higher rate of birth defects. Just ask any fertility doctor. Mutations are an everyday fact of life, even within our own bodies.)
Most mutations do nothing at all. Those that do something are usually harmful. However, as one example, our ability to see the difference between red and green probably came from an insertion mutation (in this case, one gene accidentally turned into two genes for the same protein) followed by a small number of point mutations (leading to two genes for two separate proteins, namely Photopsin I and Photopsin II). The intermediate point mutations would have been harmful if they'd happened to the only copy of the photopsin gene, but they were beneficial when they happened to a spare. Many times, if a gene is duplicated by an insertion, one copy can go on to mutate dramatically while the other copy remains unmolested, sometimes resulting in two very similar genes with nearly unrelated roles. (This is because just a handful of changes in the amino acid chain can radically alter the tertiary and quaternary shape of the protein, and the shape of a protein determines what it does. Unfortunately, computing the folded shape of a protein is fiendishly difficult, which is why massively distributed projects like Folding@Home exist.)
Really, mutations are quite heavily studied and, in contrast with your claims, there's some very direct evidence for them. Even the Creationism/ID folks generally don't argue with microevolution (changes within a species), and mutation is required for microevolution to happen. Your position is really out on a limb. What's more, if you don't accept duplication plus point mutations as DNA "being generated/created", then you're essentially faulting God for not magically snapping His fingers for you and instead doing it the boring, step-by-step way. God has more important things to do than please your sense of aesthetics.
What do you think the "Scripting" in "Cross Site Scripting" refers to? It refers to client-side javascript. Please read some Bugtraq, or at least this FAQ or the Wikipedia article. (The Wikipedia article is the easiest read. In particular, the section on types of XSS problems is edifying.) Your example is a straightforward input validation bug in the browser, and it doesn't involve any scripting at all, cross-site or not, and therefore is not an XSS anything. It's just a malicious input that exploits a browser bug.
In stark contrast with an XSS flaw, your example is not the site's fault, and there's very little that realsite.com can do about it. A smart site that uses a whitelist approach to user-posted URLs might refuse to let a user post such a link, but it's squarely the browser's fault for mishandling a faulty input, not the site's fault for having the link. The smart site refusing to post funky links is merely doing a service to all the stupid programmers out there. Faulty inputs happen all the time in the real world -- typos, human errors, the occasional corrupt file -- and any browser that doesn't say "Whoa! What the heck am I supposed to do with that?" is a buggy browser.
(Sadly, when it comes to malformed HTML, the "buggy" adjective applies to AFAIK all browsers today, including the lowly Lynx. Google for "HTML fuzz" if you're curious. Some hold up better than others, though, and IE is by far the worst of the lot. What's worse, when it comes to malformed URLs, IE itself has historically been a disaster, with about 2-3 times the URL bugs as the Mozilla codebase, and scarily almost all non-browser software that registers third-party URL handlers either (a) can be exploited today, or else (b) has been exploited in the past and survived a brutal trial by fire. I'm thinking of AIM in particular for the latter.)
The article uses an awful example of an XSS exploit. The vast majority of XSS exploits don't have to jump through the hoop of an HTTP POST, so they're mindlessly simple to pull off, and there's no phishing involved. Plus, the fact that he used a proxy to modify his own web browsing is a complete red herring and detracts from the article.
In contrast to phishing (and in contrast to what's been said in most of the posts so far), an XSS exploit is a legitimate link to the target website. No amount of looking at the host part of the URL will tell you that it's a phish, because it truly, honestly isn't. If you take the time to manually browse the GET parameters individually before you click the link, you might catch that it's an XSS exploit (or an attempt at one) if you know some HTML and Javascript.
What's worse, though, is that instead of a clickable link, the exploit could even be the URL of an <iframe> tag. Completely automatic, no clicking required, and AFAIK no modern browser allows the user to disable or manually confirm <iframe> tags. Even worse, XSS attacks on some sites are persistent and shared. For instance, if someone home-rolls their own comment system and forgets some checks, it might be possible to post an XSS exploit in the subject line of the comment, which not only affects everyone who reads the post, but also everyone who even reads a list of new messages.
The important characteristic of an XSS attack is that, unlike most web-based attacks, XSS attacks are exploiting the website itself -- not you, and not your browser. You click the link, the website ships some HTML to your browser, and whaddya know, there's one of them newfangled <script> tags to run.... The injected Javascript code, which the webmaster didn't intend but nonetheless his website actually delivered to your browser, runs with the same permissions as any of his own code, which includes access to the document.cookie property. Since most websites these days stick session IDs or even *groan* username/passwords in cookies, all it takes is for the Javascript to e.g. generate an <img> or <iframe> tag that points to the attacker's website, with '?'+document.cookie tacked onto the end of the GET request. Now the attacker can log in as you, and can explore other, non-XSS exploits that require him to be logged in.
Your only recourse as a user is to disable Javascript. Full stop. You can't even enable it on "trusted" sites, because if you mark them as "trusted", you're saying "I trust that this website will never, ever be hacked so long as I live". One or more of your "trusted" sites might have undiscovered XSS flaws in their backends, and you can't "untrust" them faster than the blackhats can exploit them.
There is nothing, I repeat nothing that you can do as a user or as a browser designer that will simultaneously (a) prevent XSS and other server-side exploits, and (b) allow the features that modern web sites depend on by design. If you think you want a browser that's completely safe from server-side exploits, spend a week browsing the web using strictly Lynx, then see if you're still of the same opinion. (While XSS requires Javascript to pull off, there are other server-side data validation problems on many websites, and those can be exploited by something as innocuous as a CSS stylesheet reference.)
I think it technically qualifies, much like fingerpainting...
So? While it wouldn't be exactly trivial to create a BitTorrent-like multicast protocol, it'd be fairly straightforward. Hell, if I were to code up a very rough prototype all by myself, I can't see it taking me more than three weeks, and most of that would be protocol design. Once it'd been implemented once, it'd get steamrolled into most of the BitTorrent clients out there in a matter of 3-6 months as an option, just like every other new BT feature. Of course, without a multicast-capable Internet, nobody's going to bother.
Sort of. The binary blob constitutes nVidia's shared driver codebase between Windows and Linux. It exposes some intermediate functionality, which the wrapper layer thunks to. However, the binary blob itself doesn't constitute a driver, for any OS. The wrapper code for the Linux driver, however, falls under the GPL's rule because it legally counts as a derivative work of the Linux kernel. Since a derivative work plus something else is still a derivative work, the final compiled driver is still under the GPL's rule, even though most of the functionality is contained in the proprietary binary blob. And, while there's nothing wrong with doing that as an individual on your own computer (the GPL is a copyright license), you can't distribute the resulting mess legally.
You've got the gist of it, but I just want to clarify for other readers.
The way it works, from a copyright holder's perspective, goes something like the following. By releasing your work under the GPL, you have irrevocably given the permissions listed therein to anyone who receives a copy. As the copyright holder, you can go back and relicense it (whether more or less restrictive), but people will always be able to keep distributing the GPLed copies, since the GPL cannot be revoked.
(Something like this happened with Secure Shell, except the old SSH license was BSD-like. Any free software license will, ipso facto, be irrevocable due to the distribution model, and the GPL is not in any way unique in that regard. That's why Sun doesn't let you redistribute Java after you download it.)
Beyond that, a catch is that the exact wording of the GPL is itself copyrighted by the FSF, and the terms on redistributing the GPL itself read: "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." This means that, if you want a license that works like the GPL but isn't the actual FSF GPL, you (a) have to write it from scratch yourself (or pay your lawyer to do it) to avoid creating a derivative work that violates the license on the GPL, and (b) you can't call it "GPL", since it would be fraud to misrepresent your own custom license as the genuine FSF GPL (although, technically, the FSF doesn't explicitly own a trademark on the name "GNU General Public License").
If you need to, you can get around this by using a disjunction of licenses ("You may distribute this software under ANY of these licenses"). If you really, really need to, some programs have been distributed under a conjunction of licenses ("You may distribute this software only if you meet the terms of ALL of these licenses"), which ended up the case with the OpenSSL license (which is a bit of a trainwreck due to hysterical raisins). And, in very rare cases, you can ask the FSF for permission to modify the GPL (see the Affero license).
I for one have a nvidia binary kernel module loaded which would never have been allowed if RMS ran the project or had any meaningful involvement in it - and I'm fairly sure the new version of the GPL would prohibit that sort of thing.
Actually, the GPLv2 prohibits it, too. It's quite against the letter of the current GPL to distribute nVidia's binary-blob driver with the Linux kernel, as the nVidia driver is clearly a derived work of the Linux kernel (i.e. you need kernel source code to compile the wrapper that turns the binary blob into a driver -- the finished driver doesn't make any sense without a Linux kernel to go with it, so the kernel plus driver equals a derived work). This is why the handful of distros that currently distribute binary blobs are moving away from them, and the smart ones require you to compile the blobs into drivers yourself (albeit with automated wrappers around the process). It's only by the good graces and/or ignorance of various Linux copyright holders that nobody's been sued over it yet.
English isn't so much "sloppy" as it's a medley of rules, cherry-picked from all the parent languages. (Programmers: English is a good example of why Multiple Inheritance is often a Bad Idea.) First, you have the basic German roots that generate most English grammar and syntax, as well as a solid amount of vocabulary. While that German system was evolving to drop inflection (e.g. "the" vs. "der, die, das..."), the Normans invaded England and brought early French with them. French, a Latin language, was itself rapidly evolving to an inflection-free form at the time. On top of that, you had the Church (there only being one at the time) dominating scholarly discussion, which injected some old-school Latin loanwords into the mix. Pouring all those ingredients into one stew is, of course, bound to produce interesting results.
In the aftermath, with the French-speaking Normans solidly established as the ruling class, the Germanic-speaking lower classes sought to imitate them. (This is a recurring theme in history; just look at any celebrity-worship magazine for a modern example.) They started borrowing French loanwords and, more importantly for this discussion, started pronouncing old German words in a more "French-like" manner. In addition to adding lots of silent letters and simplifying all the old German consonant clusters, this process somehow triggered the Great Vowel Shift, which completely threw out the old German-derived spelling rules for vowels, which had been nearly equal to the Latin ones up until then. In the process, most diphthongs (a smooth slide from one vowel into another vowel) turned into monophthongs (a single vowel sound), even though the spellings still had two letters.
When the dust settled and spelling started to renormalize in Shakespeare's time, people started noticing patterns like "i before e" ("-ie-" became a way of spelling what's now called "Long E") "except after c" ("-cei-" is a common pattern in Latin and French words but rare in German ones, and French was considered "more proper" at the time) "or in words with an 'a' like 'neighbor' and 'weigh'" ("-ei-" became a way of spelling "Long A"). The patterns were eventually turned into little rhymes as a mnemonic, which then were taught to children learning to read, helping to establish the new spelling rules.
And that's why we spell "knight" as "nuh aye t" instead of "kuh nee guht". (The snooty Frenchman in Monty Python and the Holy Grail was actually not far off in his pronunciation from actual Old English. The final "-ght" just runs together a lot faster.)
(BTW, EM64T = shameless clone/re-branding of x86-64, which is an open standard created by AMD. A rare case of Intel not succumbing to Not Invented Here syndrome. From here on, I'll lump them both under the name "AMD64".)
FWIW, I have very little hands-on experience (not being a frequent programmer of x86 assembly), but there are two big features of AMD64 that stand out: more registers (which helps compilers especially), and addressing relative to %rip (the 64-bit Instruction Pointer). The former lets you compute more things on-the-fly without reserving stack space for temporary variables, which can cut down on round trips to L2 or main memory -- thus making AMD64 a bit more like a RISC system, while leaving behind the ivory tower "orthogonal" (read: code-bloating) instruction sets that RISC forces on you. The latter lets your code reference constant things like strings (which are generally compiled into the .text section, right alongside the code that uses them) without [PIC] reserving a register for it, or [non-PIC] hardcoding the address. This simplifies the build process for a LOT for programmers.
Quick tutorial on PIC:
Let's say I have a function, void hello() { printf("Hello, World!\n"); }. If I compile and link this code normally, I get something that looks like push $0x80484b8; call printf, where 0x80484b8 is a hard-coded address located in the .text section (or else a section for data constants that can be found relative to .text). If you're building an executable, that's fine, since the location of .text will be known at link-time.
However, if you want to bundle your code into a shared library, that won't do at all. Each program that loads your library will load it at a different address, so .text could be anywhere in memory. On a modern system, you can add a fixup so that the dynamic linker patches your code on the fly, but now your "shared" library has one copy in memory per instance, even if it's all instances of the same program. That's worse than a static library! The solution is called PIC, Position Independent Code, and is invoked with -fPIC when using GCC. On x86, it usually looks something like this: call .Lfixup; .Lfixup: pop %ebx. Since x86 provides relative jump/call instructions, you can call to .Lfixup without knowing the absolute address, which pushes %eip on the stack as the return address. After the pop, %ebx now contains the absolute address of the .Lfixup label at runtime, and you can safely access your constants relative to that. (All that fuss just because you can't use %eip directly.)
On the downside, you've now eaten a register (on the already register-starved x86 architecture) and you've blown away most branch predictors, forcing a pipeline stall. Not a biggie if you just do it once in main() or similar, but since this might be a library function, you have to do it each time the function is called, in each function that needs it. Ew. It works, but it's not elegant, and it eats performance very badly if you call a PIC function from within an inner loop, so a lot of programmers just tell their tools to compile the entire program twice: once with PIC, and again without. (That's what all those *.lo files are from GNU libtool.)
AMD64 allows compilers (and assembly writers) to unify PIC and non-PIC code into a single, efficient path. Instead of jumping through hoops to copy %rip to %rbx and locate your constants relative to %rbx, you can just address your constants relative to %rip directly. There's no longer any penalty for using PIC, so compilers can just turn it on by default, saving the world from millions of tiny hassles that add up to one big Ick. It's probably the single most real-world useful thing they could have possibly added to the x86 instruction set.
"The Reagan years were the worst. And the Bush years. They were the worst, too. The Clinton years I didn't enjoy at all. After that I went into a bit of a decline..."
Don't know why that popped into my head, but it seemed apropos.
How long did it take you to hit 40? At 5 hours a week, you must've been playing for at least 3 months or so. If you'd planned ahead a bit, you could've bought your mount the moment you hit 40, like I did, and without paying the gold farmer tax.
There are plenty of ways to make decent loot using legitimate, in-game avenues. The easiest? Three words: Savory Deviate Delight. The hard part is getting the cooking recipe. Unless you're Alliance on a PvP server, it's easy to fish a 20-stack of Deviates in an hour or less (twice or triple that amount if nobody else is fishing up the schools). On Thrall, that can equal 10 gold on the Alliance or Goblin auction houses, or even more on older servers. Even as little as you play, 90 gold should be easily achievable in less than 2 weeks under worst-case conditions, and you get to relax and watch the scenery while you do it.
I wish I had mod points today. You are exactly correct, people buy gold so they can skip a lot of the game. The reason they do this is because WOW is perhaps the most boring RPG ever created.
I'm sorry, but you've obviously never played any other MMO out there. WoW is, in fact, the least boring MMORPG ever created. Most of the quests aren't very imaginative, true, and it starts to be a grind around 35-40ish, but on the boredom front, it's a breath of fresh air compared to other MMOs.
I previously had the misfortune of playing Dark Age of Camelot. Now that is a boring RPG. In the time I played it, I felt like I hadn't made any progress at all. What little I do remember of quests and the like was exactly the same format as WoW: "Kill 10 of these", "Kill that guy over there", etc., except that WoW at least mixes things up every now and then. However, in stark contrast with DAoC, WoW actually has enough of an interesting story that I have, on a few rare occasions, felt immersed in my character and the gameworld, something that had previously happened for me only in pencil-and-paper RPGs.
And while DAoC is a particularly bad offender in the boredom department, what I've heard from friends that have played them is that most other MMORPGs are much more grind-intensive than WoW, and that WoW was a breath of fresh air for them as well. (If you haven't guessed by now, I've never bought anything from the farmers. I bought my mount the moment I hit 40 with my own hard-earned gold, and you know what? I had fun earning it.)
Now, if you want to take aim at WoW, aim at the endgame content. Once you hit 60, you're pretty much consigned to either PvP or to massive dungeon raids that require a meatspace schedule that will accomodate them. Casual, solo content pretty much evaporates at 60. But don't pin the sins of MMOs as a whole on Blizzard.
[Dushumm on Thrall, a 47 Tauren Druid]
The difference between "mind prediction" and "mind reading" is one of definition, not evidence. It's like arguing that "blue" and "orange" might actually be the same color, and that it's up to someone else to prove that "blue" and "orange" are actually different colors.
The No Cloning Theorem is a mathematical proof, not a scientific theory. It proves that either you cannot clone a qubit (and thus cannot communicate via quantum entanglement) OR that you can travel backwards in time. And as fun as it sounds in sci-fi, traveling backwards in time has such drastic implications that it would make the world a downright scary place.
In contrast, nobody ever "proved" that flight was impossible. (If that were true, how do birds fly? Obviously it's possible.) It was instead a question of engineering and materials science, i.e. "with current technology, we believe that human flight is impossible" (or would have said so if they'd been making a scientific statement -- most of the out of hand dismissals were off-the-cuff opinions, not carefully researched statements). Likewise with the sound barrier.
The only way the No Cloning Theorem could apply is if quantum mechanics is all a bad dream and qubits don't exist. (This would be unprecedented in all of science, to have a new theory that says the old theory was outright Wrong. As radical as Relativity is, it reduces to Newton's laws at low speeds. Likewise, quantum mechanics reduces to classical mechanics at large sizes. We've sent qubits, so even if Quantum Mechanics is wrong, any new theory must have qubits -- or else have a really good explanation for why the Bell Inequalities are violated in QM.)
WRT radio, that's conceivable, but EM transmission generally requires an antenna (i.e. a continuous conductor of the appropriate length that can handle an alternating current, so nerves don't work). Low frequencies can transmit over long ranges with less power, but require a larger antenna and can hold less data. High frequencies use smaller antennas and can hold more information, but require more power for the same transmission distance. A biological structure being used as an antenna would certainly have shown up on an MRI or the like, if it were long enough for low frequency EM. That means that any EM-based telepathy would have to be very high frequency and thus have exceptionally short range (a couple of feet at most, sort of a "Psychic Bluetooth") or it would cause a massive, measurable dip in blood sugar levels when used. Plus, it seems unlikely that such signals would have escaped detection, as they would probably interfere with MRI scans of the brain.
As far as the other known forces go, the weak force is ruled out (can't be used to transmit, it just doesn't work like that), the strong force is ruled out (it's attracted to itself, so it can't go far, not even between atoms in a molecule), and gravity seems outlandish beyond reason (our best gravity wave detectors are miles in size, and we can't imagine any way to make them in miniature -- gravity is 10^40 times weaker than EM). We have very solid reasons for suspecting that there are no undiscovered forces (why would they affect human brains but nothing else?), and unless you count pheromones as telepathy (why not?), we don't shoot any matter-based particles out of our skin. So, as unlikely as it is, EM is the only obvious candidate.
WRT quantum entanglement, there are two problems. One, entanglement works by entangling two particles, then separating them by physically moving them without touching them. (Touching destroys the coherence, because if an object touches the particle, the object "measures" it in the process. That's the short version.) Human beings don't have fiber optic cables hanging out of their skulls to transmit entangled particles in a quantum-coherent environment (which is how the 10km entanglement experiments work -- photons don't "touch" fiber optics). Two, quantum entanglement has been proven, via the No Cloning Theorem, to be incapable of transmitting information. It's mathematically proven that, if quantum entanglement can transmit information, then time travel is possible. (Worse, it's time travel of the causality-violating sort. Scientists generally discount any theory that would allow the Grandfather Paradox, on the basis that it's a huge, blinking, neon sign that reads "Apply Occam's Razor HERE!" There's absolutely no evidence for it, yet it's something so Earth-shattering that if it were true, there should be oodles of evidence for it, at the subatomic level at least [we should see cosmic rays that traveled backwards in time all across the sky]. It also kicks out from under us the fundamental idea that time has a direction, and the idea that it's possible even in principle to predict what might happen in the future based on what is happening in the present, i.e. science. By definition, that's what "causality" is.)
In reality, quantum entanglement works "faster than light" in the same way that I can swing my flashlight from one star to another "faster than light". Someone at one star can't use my flashlight to transmit information to someone at the other star. Worse, unlike my flashlight analogy, you can't even use quantum coherence to coordinate both parties doing something at the same time.
FWIW, the Universe at the moment of the Big Bang was not simply "a ball of matter", but rather "a ball of spacetime". According to the theory, time and space did not exist until the moment of the big bang, so the notion of "before" is meaningless in this context. (In theology, it's like asking "What existed before God?" or "What did God do before creating the Universe?", or in computing, "What if Microsoft wrote a bug-free version of Windows?")
Sorry, but floppies died when Verbatim and the like pushed the prices on floppies down so low that everyone else had to drop all quality control to compete. Any floppy disk made after 1997 or so will develop bad sectors if you so much as make a rude face at it. Out of necessity, I now treat floppies as write-once media.