The reality is that the number of "Scientist 1"s is about 100 times greater than the number of "Scientist 2"s. The news media just amplifies the voices of the "Scientist 2"s for the sake of "balance". Most of the scientific debate is within the "Scientist 1" camp regarding the specifics of global warming (how much is human produced, how disruptive will it be down the road, what options do we have for controlling it). However, that doesn't make for a nice, ratings-boosting shouting match on Crossfire.
Fact is that the Earth is, on the whole, warming. Evidence suggests that it's mostly due to human activity (although that's far from proven). It's a strong hunch that a warming Earth will disrupt human activity -- we can be fairly certain that rainfall will shift, which will move food production and cause economic upheaval, although climate is such a chaotic system that we can't really say where the shifts will be. It's a strong hunch that it will result in more frequent hurricanes, more powerful hurricanes, or both (more heat = more ocean evaporation = hurricane fuel), which we might or might not be seeing already. It's a weaker hunch that, once we reach a certain amount of warming, the climate will abruptly swing from its current state to a different one -- evidence shows that historically there have been two climate settings ("hot house" and "ice age", with a 10 C swing between global averages), all of human existence has been in an "ice age" climate, and the swing might be caused by carbon sequestering (which we're currently undoing by pulling fossil fuels out of the ground and burning them).
While it's not impossible to write a given piece of software that's bug-free, it is impossible to know that it's bug-free. You may suspect it, or perhaps even believe it, but you can never know it. Formal software provers can demonstrate that a piece of software obeys a theorem, but it doesn't demonstrate that the theorem is correct (i.e. that it proves what you think it proves). It just moves the task of bughunting one abstraction higher.
mysql_real_escape_string() had the same problem with multibyte characters and certain charsets.
How could that be? The point of mysql_real_escape_string() vs. mysql_escape_string() (or any other PHP quoting function) is that it uses the settings from the DB connection to know the correct encoding.
Assuming it just thunks down to the MySQL client library like the docs imply, that means one or more MySQL programmers need to be taken behind the shed and beaten severely.
The big problem with having any open hole in the skin is infection. For some problems (e.g. kidney dialysis) the risk is worth it, but for everyday use with healthy people, the drawbacks are bigger than the benefits. You might be able to graft the skin into a pocket, like a kangaroo pouch, but that'd be a lot more expensive (and painful) than the 5 minutes it takes to insert a simple subcutaneous implant.
Regardless, what's so bad about carrying around a wireless fob on one's keychain that one needs subcutaneous implants instead? I don't get that.
If you're not aware, the CSS "px" unit is defined in the standard as a specific angle of the viewer's vision. In the case of a user sitting ~18in from a ~90DPI display, that works out to one device pixel per "px", or 3/4 of a point.
Disclaimer: I'm not a kernel programmer and honestly don't know much more than the basics of VM on the x86 architecture. However, I have extensively read Intel's 80386 Programmer's Reference Manual. I also R'dTFA.
Copy on Write saves you real memory, cache memory, and CPU time by pretending that each forked process has a true copy of a memory segment when it in fact is looking at the original. That is, right up until a fork tries to write to that memory location, in which case an exception is handled by making an actual copy to a new location and allowing the write. [...] Do I have that right?
No, you don't have that right. COW during fork() is staying, but that's because fork() is a much bigger operation than a read() or write(), and the kilocycles of pain caused by a TLB flush is worth it for something as big as a fork(). (As I understand, when the first write happens after a fork(), the kernel can pre-emptively "copy-ahead" and thereby coalesce multiple likely page faults into a single page fault.) However, when you're pushing around buffers that are only 4KB (one page) of memory or less, it doesn't make sense to spend many kilocycles on a page fault plus TLB flush in order to avoid ~4 kilocycles of just copying the damn memory. (However, if you're e.g. reading/receiving in a tight loop and not ever writing to the buffer, it can come out a win since the TLB flush doesn't happen on every I/O operation. This is especially likely in artificial benchmarks, which can trick a programmer into falsely concluding that COW is a net win.)
In the case of a multiple-CPU system, you might even have to flush the TLB on multiple processors, which amplifies the damage to far beyond just copying the data. This is especially so if the program doing the I/O is multithreaded (e.g. MySQL).
If you or anyone else reading this is not familiar with a TLB flush, here's an explanation that's as brief as I can make it:
When the OS first boots, it sets up a mapping between VM and physical memory, called the "page table", then calls a special OS-only instruction that tells the processor where to look in physical memory for the page table.
In a simpler world, every time the CPU was asked to read from or write to an address in VM-space, it would look it up by reading the page table entry from physical memory, doing the mapping, then performing the requested read/write on physical memory. In the real world, the CPU has a Translation Lookaside Buffer that caches the most recent page table entries; in typical use, memory latency is halved and memory bandwidth is doubled, so the TLB is a huge win. (The page table is variable in size and can be huge, so having the whole thing on the CPU is impractical.)
The CPU provides a special OS-only instruction that must be called every time the page table changes. When that instruction is called, the CPU throws away the entire TLB, and depending on the design might have to throw away some or all of L1 and L2 cache as well. This costs thousands of cycles, both in the actual cache invalidation and in the refilling of all the emptied caches.
Unfortunately for an OS programmer, one of the pieces of information that has to be cached in the TLB is the read-write-execute permissions of each entry in the page table. Whenever COW is used, the OS marks the COW-shared pages read-only (one TLB flush). When a program writes to a read-only page, the CPU hands control to the OS, an expensive event called a "page fault". The OS notices that the page fault is on a COW page, so it splits the VM copies into physical copies and marks the new one read-write (one page fault plus TLB flush). When the other thread writes to its copy (which is no longer shared but still read-only), the OS notices that the COW is no longer in effect and marks the old one read-write (one page fault plus TLB flush).
This explanation completely glosses over a number of x86 details like segments, the GDT, and the LDT. Go download the manual from Intel for details.
I hate to state the obvious, but ftp.exe isn't part of the TCP/IP stack. While I'm sure MS started off with the BSD stack at the same time they grabbed a copy of the BSD userland utils, I'm also sure the stack's been gutted and replaced in the NT/2000/XP line, even though the userland utils are still largely unchanged. (As 10 minutes with Ethereal and nmap's fingerprinting option can tell you, the NT stack has its own, um, "unique" view of the TCP/IP standards. Not necessarily wrong, mind you... however, the 95/98/ME stack did behave vaguely like an ancient, buggy BSD stack from before people started protecting against TCP spoofing, until MS patched it up by hand around ME.)
Unfortunately, the probability of bacteria mutating to be resistant to several antibiotics may not be simply the product of the probabilities of the individual mutations. Multiple resistance has been observed, although the likelihood of even one bacillus simultaneously undergoing all required mutations with independent probabilities is vanishingly small.
This is rather puzzling. A quantum mechanism has been proposed. I should point out the the author's (McFadden) book is where I learned of these surprising mutations.
Why would you need to drag out a rather farfetched (and IMNSHO sloppy) theory of quantum evolution, when bacteria and other microbes have been known for 10+ years to laterally transfer DNA (even between species) by sharing plasmids?
While I wouldn't be surprised if it does turn out that bacteria have a mechanism for directed mutation (e.g. genes with "breakpoints" that are relatively safe to manipulate), and that bacteria can laterally share the results of that process with other bacteria, shouting "quantum" while waving one's hands about doesn't constitute an explanation of anything (despite what Roger Penrose might believe regarding consciousness).
... the survivors of the Nostromo! (Okay, that was lame, but I'm shocked that I appear to be the first to make reference to the movie.)
Or, you would have if you'd said "Cygnus" instead of "Nostromo". (The Nostromo was the cargo ship that most of Alien took place on. I mean, it was a good movie and all, but it didn't have much to do with black holes.)
I'm sorry it doesn't click for you, but from my perspective, Perl rocks. It's got just about the perfect blend of C syntax (which, as ugly as it is, has proven surprisingly readable -- witness new languages like Java, C#, and PHP still borrowing from it) with LISP power. Now that I've used closures and higher-order functions in serious code, I can never go back. Just about the only LISP things it's still missing are macros and continuations, and both of those are coming in Perl 6. (Oh, and a real garbage collector. I like Perl 5 a lot, but refcounting sucks.)
PHP 5, unfortunately, still doesn't support higher-order programming. Now, I have to hand it to them, it's a much nicer language core than PHP 4 was, but it still looks like Perl on training wheels to me. I might look at it again when array_map() takes a closure instead of a string, but not until then.
The underlying idea is that, if you're Alice and you have a secure quantum link to Bob, then you can use the quantum link to generate shared secrets with Bob as needed. However, unless Bob is in the same building, your quantum link is probably going to have fairly piddly bandwidth, since decoherence rises rapidly the longer your link is. So, while you can wait for the quantum link to generate a one-time pad if you need to be absolutely sure that your message is secure, it's usually more convenient to just use the quantum link as a Blowfish/AES/etc. key generator, send the message to Bob at the full speed of your Internet link, and just re-key as frequently as possible. You can have the quantum link store up shared random bits while you're transmitting with the current key, and by the time you want to re-key, you have enough bits saved up for a fresh key. In this scenario, quantum crypto to share secret keys replaces today's use of public key crypto to share secret keys.
(In modern uses of public key crypto, you're almost never actually encrypting or signing the actual data, which would take a feasable but unreasonably long time to compute. Instead, you're actually encrypting a secret or signing a digest. A symmetric crypto algorithm is used to actually encrypt the data, and a traditional hash algorithm is used to generate the digest.)
As far as anyone knows, QC only breaks public key crypto. Shor's algorithm blows wide open any cryptosystem based on prime numbers (notably RSA), and IIRC opens the door for a polynomial time attack on elliptic curve cryptosystems (El-Gamal and the like). However, secret key crypto is only mildly affected -- a key of complexity O(n) on a classical computer is reduced to O(sqrt n) on a quantum computer, effectively halving the number of bits. So, ignoring surprise developments in cryptoanalysis, Blowfish with a 256-bit key is still secure in a world with widespread quantum computing. That's why quantum cryptography/quantum key distribution is so useful in such a world.
In my experience as an admin, random browser crashes have more to do with your video card drivers than with your browser -- at least under Windows. Upgrading video card drivers (keeping in mind the maxim that, sometimes, "upgrades" are released in reverse chronological order) and stress-testing until you find stable ones has a fair shot of fixing the problem.
Things might've changed since the merger with Nextel, but AFAIK there's nothing keeping you from distributing unsigned Java apps from your own company website. The user's phone will pop up a warning, of course, but it won't stop him/her from downloading and installing your app. Assuming you know all about JAD files and MIDlets, just point the user at the JAD file.
My biggest beef with Sprint is their crappy API support, at least on their older phones (my Sanyo PM-8200 supports only MIDP-1.0, and very few of the optional J2ME APIs).
"It is not good to introduce the concept of the mass of a moving body for which no clear definition can be given. It is better to introduce no other mass concept than the 'rest mass' m. Instead of introducing M it is better to mention the expression for the momentum and energy of a body in motion."
Actually, "relativistic mass" (mass that changes with velocity) is just a mathematical fudge that makes most (but not all) of Newton's equations come out right at relativistic speeds. Unlike length contraction or time dilation, relativistic mass isn't a physical effect. The fully expanded form of E = mc^2 is E^2 = m0^2c^4 + p^2c^2, where m0 is rest mass and p is relativistic momentum (p = [gamma]m0v).
As everyone seems to agree that running general-purpose code (e.g. Linux) on a Cell is going to be unpleasant thanks to the dumbing down of the PowerPC at the core, I was wondering what the odds are of seeing this as an add-on for doing vector-friendly operations. While I don't see people rushing out to install a Cell just for the hell of it, what are the chances that e.g. future crypto-offload accelerators or even 3D video cards might use one of these puppies?
... Speaking of MetroidPrime I don't even consider that very mature, sure you have a big gun, but hardly any story worth to talk about, no characters, no dialog (well, a tiny little bit) and hardly any violence worth to talk about. I really love the 2D Metroids, but Prime never really got me, kind of just bores me, I think it simply didn't went far enough, it basically never was scarry....
I think MP (the first one, at least) was subtle enough that the details flew under your radar. One of the things I loved most about MP was that the world itself was almost a character, telling you its story through the "dialogue" of the scan visor. Wandering through the lush wetlands, the crumbling but majestic ruins, the starkly beautiful snowy mountains, etc., you listen to the planet tell the story of its own fall, and it contrasts itself against the harsh efficiency of the Space Pirate invaders to win you over.
And it's not like MP took away anything from the old-school Metroid games. The Metroid series has never had characters or dialogue; it's always been about Samus exploring the environment. I played a lot of Super Metroid, and consider it one of my favorites for the SNES, but I personally rank Omega Pirate from MP higher for tension-building and scariness than most of the bosses in Super Metroid. The trial-and-error aspect of finding the weakness in Draygon (the Maridia boss) is a bit reminiscent, but (especially on Hard mode) the Omega Pirate battle combines prying apart his weaknesses with a race against time before you run out of energy tanks.
And if you want tension and scariness, that's one of the few places that MP2 Echoes exceeds MP1 in spades. Wandering through the Space Marine base, wading through all the carnage, then suddenly having your perspective yanked out from under you when you realize that what you thought happened to them was actually much, much worse. What's more, once you reach the main thrust of the game, you spend a lot of time running from safe spot to safe spot like a rat scurrying in the shadows. The game also has much more intense boss battles: on hard mode, most boss battles are potentially lethal and many of them are as difficult as Omega Pirate on Hard mode in MP1.
My sister was always the Wario Stadium fanatic, since she could hit the shortcut just after the start line with some consistency. (ObToad: I'm the best!) Usually I got her back with the ol' Lightning Bolt just as she hits the Point-O'-No-Return on the big ramp. *snigger*
I, however, was always partial to Rainbow Road, mostly because I could skip the first 1/4 of the race so long as I had a mushroom (and occasionally using the starting line timed boost). (ObYoshi: *wee-whoo*) If you've never seen that one, you start Rainbow Road on the downslope of a tall hill, and far below and to the left is the track that you're supposed to be on 0:30 seconds into the race or so. Near the start line, use a mushroom or timed boost; cruise near the center of the track, then on a particular rainbow stripe -- can't recall which one, but it's just as the road drops away -- sharply veer left and hit the R-button so you hop over the guardrail. Cross your fingers and hope you didn't over- or undershoot. (Over is better, since you might hit the far guardrail.) Hold the brakes just before you land so you don't bounce right over the far guardrail and waste time with Latiku (although you'll still be ahead). As you land, try to swerve sharply left so that you've made a 180 from your starting direction. If you're on the first lap, there should be a Chain Chomp directly ahead. Dodge him as you get up to speed and you can complete the lap in less than 1:30. (IIRC, my best time trial was something around 4:25 or so for all 3 laps, when the course is normally 6:00.)
If you can hit the shortcut consistently, there's pretty much no way for the rest of the crowd to catch back up. 2nd place will have you just within sights or so as you're hitting the shortcut again. The trickiest part is getting ahold of mushrooms for the boost, which might require deliberately dropping back to 2nd. Makes for a great last-lap surprise if no one else has ever seen the shortcut used.
I have three complaints about the IRC Protocol, all showstoppers for me.
The first is the spanning tree requirement for servers, which means that an IRC network's operators must carefully coordinate the adding and removal of server nodes to/from the spanning tree. This must be done in a centralized manner, or the spanning tree will no longer be a tree and the server-to-server protocol will break.
The second is the horrible security inherent to the protocol. The biggest issue by far is the fact that every server is implicitly trusted to correctly coordinate channel modes and membership. Not only does this result in huge repercussions when buggy server software is used (I've lost track of the number of times a netsplit has failed to heal properly in the channels I've been in), but it also means that the admins and operators of each and every server must be trusted with what is essentially the IRC version of root access. One rogue server can cripple the network.
(The two previous points tie in. Taken together, they make it impossible to have an open-ended IRC network, where untrusted 3rd parties can attach and detach their local servers to/from the network on the fly. Since most users spend 90%+ of their time idling, this would save a lot of resources overall: an ISP could create a private IRC server for their local users, taking the memory load off the network's own IRC servers. One solution to the channel security issue would be to have all channels be ownerless and unmoderated. Another would be to make channels belong to a specific server. Either would eliminate the plague of botwars and DDoS attacks.)
The third point is internationalization. IRC is difficult to use with any character encoding besides Windows CP 1252, since the dominant client (mIRC) defaults to that encoding and the protocol defines no way to coordinate encoding changes. The protocol mandates that channel and user names are localized to the Swedish idea of uppercase/lowercase, which causes no end of confusion for English-speaking programmers (and I can only imagine the confusion of non-Swedish Europeans that actually use more than 7 bits). While UTF-8 and similar ASCII-friendly multibyte encodings can be shoehorned into the protocol without too much difficulty, stateful encodings like Shift-JIS are largely screwed, since (a) 0x20 doesn't necessarily mean whitespace, and (b) the Swedish upper/lower normalization rules change from bizarre to broken. This is largely because the protocol goes beyond being pro-text and strays into outright anti-binary fascism, with no mechanism for escapes. If you use IRC, you're pretty much constrained to scripts based on the Roman alphabet. No Cyrillic in your channel names or Japanese kanji in your nick. Actual message text might work, so long as your encoding never produces 0x0D, 0x0A, or 0x00.
As a small addendum, the DCC protocol is very NAT- and firewall-unfriendly, but that's relatively minor compared to the first 3 points.
While no right to anonymous speech is spelled out in the Constitution or its Amendments, I would imagine that the founding fathers thought that anonymity was trivially implied by "[not] abridging the freedom of speech", since a law requiring "eunymity" of unpopular political speech effectively bans that speech. (Think Communist speech in the McCarthy era. Regardless of where one stands on the idea itself, Communist speech is protected by the First Amendment.)
The Founders themselves made heavy use of the anonymous pen name Publius when writing The Federalist Papers -- essentially an ad campaign for our current Constitution -- so it's easy to see where they stood on the subject when they wrote the Constitution.
Slashdot Mirror
The reality is that the number of "Scientist 1"s is about 100 times greater than the number of "Scientist 2"s. The news media just amplifies the voices of the "Scientist 2"s for the sake of "balance". Most of the scientific debate is within the "Scientist 1" camp regarding the specifics of global warming (how much is human produced, how disruptive will it be down the road, what options do we have for controlling it). However, that doesn't make for a nice, ratings-boosting shouting match on Crossfire.
Fact is that the Earth is, on the whole, warming. Evidence suggests that it's mostly due to human activity (although that's far from proven). It's a strong hunch that a warming Earth will disrupt human activity -- we can be fairly certain that rainfall will shift, which will move food production and cause economic upheaval, although climate is such a chaotic system that we can't really say where the shifts will be. It's a strong hunch that it will result in more frequent hurricanes, more powerful hurricanes, or both (more heat = more ocean evaporation = hurricane fuel), which we might or might not be seeing already. It's a weaker hunch that, once we reach a certain amount of warming, the climate will abruptly swing from its current state to a different one -- evidence shows that historically there have been two climate settings ("hot house" and "ice age", with a 10 C swing between global averages), all of human existence has been in an "ice age" climate, and the swing might be caused by carbon sequestering (which we're currently undoing by pulling fossil fuels out of the ground and burning them).
While it's not impossible to write a given piece of software that's bug-free, it is impossible to know that it's bug-free. You may suspect it, or perhaps even believe it, but you can never know it. Formal software provers can demonstrate that a piece of software obeys a theorem, but it doesn't demonstrate that the theorem is correct (i.e. that it proves what you think it proves). It just moves the task of bughunting one abstraction higher.
How could that be? The point of mysql_real_escape_string() vs. mysql_escape_string() (or any other PHP quoting function) is that it uses the settings from the DB connection to know the correct encoding.
Assuming it just thunks down to the MySQL client library like the docs imply, that means one or more MySQL programmers need to be taken behind the shed and beaten severely.
Um, whois.arin.net and friends. Takes all of 30 seconds, and if you hit the wrong IP registry the first time, it'll tell you which one to go to.
The big problem with having any open hole in the skin is infection. For some problems (e.g. kidney dialysis) the risk is worth it, but for everyday use with healthy people, the drawbacks are bigger than the benefits. You might be able to graft the skin into a pocket, like a kangaroo pouch, but that'd be a lot more expensive (and painful) than the 5 minutes it takes to insert a simple subcutaneous implant.
Regardless, what's so bad about carrying around a wireless fob on one's keychain that one needs subcutaneous implants instead? I don't get that.
They BROKE a continent? I hope it was still under warranty...
If you're not aware, the CSS "px" unit is defined in the standard as a specific angle of the viewer's vision. In the case of a user sitting ~18in from a ~90DPI display, that works out to one device pixel per "px", or 3/4 of a point.
Disclaimer: I'm not a kernel programmer and honestly don't know much more than the basics of VM on the x86 architecture. However, I have extensively read Intel's 80386 Programmer's Reference Manual. I also R'dTFA.
No, you don't have that right. COW during fork() is staying, but that's because fork() is a much bigger operation than a read() or write(), and the kilocycles of pain caused by a TLB flush is worth it for something as big as a fork(). (As I understand, when the first write happens after a fork(), the kernel can pre-emptively "copy-ahead" and thereby coalesce multiple likely page faults into a single page fault.) However, when you're pushing around buffers that are only 4KB (one page) of memory or less, it doesn't make sense to spend many kilocycles on a page fault plus TLB flush in order to avoid ~4 kilocycles of just copying the damn memory. (However, if you're e.g. reading/receiving in a tight loop and not ever writing to the buffer, it can come out a win since the TLB flush doesn't happen on every I/O operation. This is especially likely in artificial benchmarks, which can trick a programmer into falsely concluding that COW is a net win.)
In the case of a multiple-CPU system, you might even have to flush the TLB on multiple processors, which amplifies the damage to far beyond just copying the data. This is especially so if the program doing the I/O is multithreaded (e.g. MySQL).
If you or anyone else reading this is not familiar with a TLB flush, here's an explanation that's as brief as I can make it:
When the OS first boots, it sets up a mapping between VM and physical memory, called the "page table", then calls a special OS-only instruction that tells the processor where to look in physical memory for the page table.
In a simpler world, every time the CPU was asked to read from or write to an address in VM-space, it would look it up by reading the page table entry from physical memory, doing the mapping, then performing the requested read/write on physical memory. In the real world, the CPU has a Translation Lookaside Buffer that caches the most recent page table entries; in typical use, memory latency is halved and memory bandwidth is doubled, so the TLB is a huge win. (The page table is variable in size and can be huge, so having the whole thing on the CPU is impractical.)
The CPU provides a special OS-only instruction that must be called every time the page table changes. When that instruction is called, the CPU throws away the entire TLB, and depending on the design might have to throw away some or all of L1 and L2 cache as well. This costs thousands of cycles, both in the actual cache invalidation and in the refilling of all the emptied caches.
Unfortunately for an OS programmer, one of the pieces of information that has to be cached in the TLB is the read-write-execute permissions of each entry in the page table. Whenever COW is used, the OS marks the COW-shared pages read-only (one TLB flush). When a program writes to a read-only page, the CPU hands control to the OS, an expensive event called a "page fault". The OS notices that the page fault is on a COW page, so it splits the VM copies into physical copies and marks the new one read-write (one page fault plus TLB flush). When the other thread writes to its copy (which is no longer shared but still read-only), the OS notices that the COW is no longer in effect and marks the old one read-write (one page fault plus TLB flush).
This explanation completely glosses over a number of x86 details like segments, the GDT, and the LDT. Go download the manual from Intel for details.
Athena? I... I'm so sorry. Is there anything I can do?
(Damn, makes me sad that Hallmark doesn't make a "Sorry you use Athena widgets" card.)
I hate to state the obvious, but ftp.exe isn't part of the TCP/IP stack. While I'm sure MS started off with the BSD stack at the same time they grabbed a copy of the BSD userland utils, I'm also sure the stack's been gutted and replaced in the NT/2000/XP line, even though the userland utils are still largely unchanged. (As 10 minutes with Ethereal and nmap's fingerprinting option can tell you, the NT stack has its own, um, "unique" view of the TCP/IP standards. Not necessarily wrong, mind you... however, the 95/98/ME stack did behave vaguely like an ancient, buggy BSD stack from before people started protecting against TCP spoofing, until MS patched it up by hand around ME.)
Why would you need to drag out a rather farfetched (and IMNSHO sloppy) theory of quantum evolution, when bacteria and other microbes have been known for 10+ years to laterally transfer DNA (even between species) by sharing plasmids?
While I wouldn't be surprised if it does turn out that bacteria have a mechanism for directed mutation (e.g. genes with "breakpoints" that are relatively safe to manipulate), and that bacteria can laterally share the results of that process with other bacteria, shouting "quantum" while waving one's hands about doesn't constitute an explanation of anything (despite what Roger Penrose might believe regarding consciousness).
Or, you would have if you'd said "Cygnus" instead of "Nostromo". (The Nostromo was the cargo ship that most of Alien took place on. I mean, it was a good movie and all, but it didn't have much to do with black holes.)
I'm sorry it doesn't click for you, but from my perspective, Perl rocks. It's got just about the perfect blend of C syntax (which, as ugly as it is, has proven surprisingly readable -- witness new languages like Java, C#, and PHP still borrowing from it) with LISP power. Now that I've used closures and higher-order functions in serious code, I can never go back. Just about the only LISP things it's still missing are macros and continuations, and both of those are coming in Perl 6. (Oh, and a real garbage collector. I like Perl 5 a lot, but refcounting sucks.)
PHP 5, unfortunately, still doesn't support higher-order programming. Now, I have to hand it to them, it's a much nicer language core than PHP 4 was, but it still looks like Perl on training wheels to me. I might look at it again when array_map() takes a closure instead of a string, but not until then.
The underlying idea is that, if you're Alice and you have a secure quantum link to Bob, then you can use the quantum link to generate shared secrets with Bob as needed. However, unless Bob is in the same building, your quantum link is probably going to have fairly piddly bandwidth, since decoherence rises rapidly the longer your link is. So, while you can wait for the quantum link to generate a one-time pad if you need to be absolutely sure that your message is secure, it's usually more convenient to just use the quantum link as a Blowfish/AES/etc. key generator, send the message to Bob at the full speed of your Internet link, and just re-key as frequently as possible. You can have the quantum link store up shared random bits while you're transmitting with the current key, and by the time you want to re-key, you have enough bits saved up for a fresh key. In this scenario, quantum crypto to share secret keys replaces today's use of public key crypto to share secret keys.
(In modern uses of public key crypto, you're almost never actually encrypting or signing the actual data, which would take a feasable but unreasonably long time to compute. Instead, you're actually encrypting a secret or signing a digest. A symmetric crypto algorithm is used to actually encrypt the data, and a traditional hash algorithm is used to generate the digest.)
As far as anyone knows, QC only breaks public key crypto. Shor's algorithm blows wide open any cryptosystem based on prime numbers (notably RSA), and IIRC opens the door for a polynomial time attack on elliptic curve cryptosystems (El-Gamal and the like). However, secret key crypto is only mildly affected -- a key of complexity O(n) on a classical computer is reduced to O(sqrt n) on a quantum computer, effectively halving the number of bits. So, ignoring surprise developments in cryptoanalysis, Blowfish with a 256-bit key is still secure in a world with widespread quantum computing. That's why quantum cryptography/quantum key distribution is so useful in such a world.
In my experience as an admin, random browser crashes have more to do with your video card drivers than with your browser -- at least under Windows. Upgrading video card drivers (keeping in mind the maxim that, sometimes, "upgrades" are released in reverse chronological order) and stress-testing until you find stable ones has a fair shot of fixing the problem.
Things might've changed since the merger with Nextel, but AFAIK there's nothing keeping you from distributing unsigned Java apps from your own company website. The user's phone will pop up a warning, of course, but it won't stop him/her from downloading and installing your app. Assuming you know all about JAD files and MIDlets, just point the user at the JAD file.
My biggest beef with Sprint is their crappy API support, at least on their older phones (my Sanyo PM-8200 supports only MIDP-1.0, and very few of the optional J2ME APIs).
You've never met a cat, have you?
Hate replying to myself, but I forgot to add a link explaining why relativistic mass is just a (pretty but bad) idea.
Actually, "relativistic mass" (mass that changes with velocity) is just a mathematical fudge that makes most (but not all) of Newton's equations come out right at relativistic speeds. Unlike length contraction or time dilation, relativistic mass isn't a physical effect. The fully expanded form of E = mc^2 is E^2 = m0^2c^4 + p^2c^2, where m0 is rest mass and p is relativistic momentum (p = [gamma]m0v).
As everyone seems to agree that running general-purpose code (e.g. Linux) on a Cell is going to be unpleasant thanks to the dumbing down of the PowerPC at the core, I was wondering what the odds are of seeing this as an add-on for doing vector-friendly operations. While I don't see people rushing out to install a Cell just for the hell of it, what are the chances that e.g. future crypto-offload accelerators or even 3D video cards might use one of these puppies?
I think MP (the first one, at least) was subtle enough that the details flew under your radar. One of the things I loved most about MP was that the world itself was almost a character, telling you its story through the "dialogue" of the scan visor. Wandering through the lush wetlands, the crumbling but majestic ruins, the starkly beautiful snowy mountains, etc., you listen to the planet tell the story of its own fall, and it contrasts itself against the harsh efficiency of the Space Pirate invaders to win you over.
And it's not like MP took away anything from the old-school Metroid games. The Metroid series has never had characters or dialogue; it's always been about Samus exploring the environment. I played a lot of Super Metroid, and consider it one of my favorites for the SNES, but I personally rank Omega Pirate from MP higher for tension-building and scariness than most of the bosses in Super Metroid. The trial-and-error aspect of finding the weakness in Draygon (the Maridia boss) is a bit reminiscent, but (especially on Hard mode) the Omega Pirate battle combines prying apart his weaknesses with a race against time before you run out of energy tanks.
And if you want tension and scariness, that's one of the few places that MP2 Echoes exceeds MP1 in spades. Wandering through the Space Marine base, wading through all the carnage, then suddenly having your perspective yanked out from under you when you realize that what you thought happened to them was actually much, much worse. What's more, once you reach the main thrust of the game, you spend a lot of time running from safe spot to safe spot like a rat scurrying in the shadows. The game also has much more intense boss battles: on hard mode, most boss battles are potentially lethal and many of them are as difficult as Omega Pirate on Hard mode in MP1.
My sister was always the Wario Stadium fanatic, since she could hit the shortcut just after the start line with some consistency. (ObToad: I'm the best!) Usually I got her back with the ol' Lightning Bolt just as she hits the Point-O'-No-Return on the big ramp. *snigger*
I, however, was always partial to Rainbow Road, mostly because I could skip the first 1/4 of the race so long as I had a mushroom (and occasionally using the starting line timed boost). (ObYoshi: *wee-whoo*) If you've never seen that one, you start Rainbow Road on the downslope of a tall hill, and far below and to the left is the track that you're supposed to be on 0:30 seconds into the race or so. Near the start line, use a mushroom or timed boost; cruise near the center of the track, then on a particular rainbow stripe -- can't recall which one, but it's just as the road drops away -- sharply veer left and hit the R-button so you hop over the guardrail. Cross your fingers and hope you didn't over- or undershoot. (Over is better, since you might hit the far guardrail.) Hold the brakes just before you land so you don't bounce right over the far guardrail and waste time with Latiku (although you'll still be ahead). As you land, try to swerve sharply left so that you've made a 180 from your starting direction. If you're on the first lap, there should be a Chain Chomp directly ahead. Dodge him as you get up to speed and you can complete the lap in less than 1:30. (IIRC, my best time trial was something around 4:25 or so for all 3 laps, when the course is normally 6:00.)
If you can hit the shortcut consistently, there's pretty much no way for the rest of the crowd to catch back up. 2nd place will have you just within sights or so as you're hitting the shortcut again. The trickiest part is getting ahold of mushrooms for the boost, which might require deliberately dropping back to 2nd. Makes for a great last-lap surprise if no one else has ever seen the shortcut used.
I have three complaints about the IRC Protocol, all showstoppers for me.
The first is the spanning tree requirement for servers, which means that an IRC network's operators must carefully coordinate the adding and removal of server nodes to/from the spanning tree. This must be done in a centralized manner, or the spanning tree will no longer be a tree and the server-to-server protocol will break.
The second is the horrible security inherent to the protocol. The biggest issue by far is the fact that every server is implicitly trusted to correctly coordinate channel modes and membership. Not only does this result in huge repercussions when buggy server software is used (I've lost track of the number of times a netsplit has failed to heal properly in the channels I've been in), but it also means that the admins and operators of each and every server must be trusted with what is essentially the IRC version of root access. One rogue server can cripple the network.
(The two previous points tie in. Taken together, they make it impossible to have an open-ended IRC network, where untrusted 3rd parties can attach and detach their local servers to/from the network on the fly. Since most users spend 90%+ of their time idling, this would save a lot of resources overall: an ISP could create a private IRC server for their local users, taking the memory load off the network's own IRC servers. One solution to the channel security issue would be to have all channels be ownerless and unmoderated. Another would be to make channels belong to a specific server. Either would eliminate the plague of botwars and DDoS attacks.)
The third point is internationalization. IRC is difficult to use with any character encoding besides Windows CP 1252, since the dominant client (mIRC) defaults to that encoding and the protocol defines no way to coordinate encoding changes. The protocol mandates that channel and user names are localized to the Swedish idea of uppercase/lowercase, which causes no end of confusion for English-speaking programmers (and I can only imagine the confusion of non-Swedish Europeans that actually use more than 7 bits). While UTF-8 and similar ASCII-friendly multibyte encodings can be shoehorned into the protocol without too much difficulty, stateful encodings like Shift-JIS are largely screwed, since (a) 0x20 doesn't necessarily mean whitespace, and (b) the Swedish upper/lower normalization rules change from bizarre to broken. This is largely because the protocol goes beyond being pro-text and strays into outright anti-binary fascism, with no mechanism for escapes. If you use IRC, you're pretty much constrained to scripts based on the Roman alphabet. No Cyrillic in your channel names or Japanese kanji in your nick. Actual message text might work, so long as your encoding never produces 0x0D, 0x0A, or 0x00.
As a small addendum, the DCC protocol is very NAT- and firewall-unfriendly, but that's relatively minor compared to the first 3 points.
While no right to anonymous speech is spelled out in the Constitution or its Amendments, I would imagine that the founding fathers thought that anonymity was trivially implied by "[not] abridging the freedom of speech", since a law requiring "eunymity" of unpopular political speech effectively bans that speech. (Think Communist speech in the McCarthy era. Regardless of where one stands on the idea itself, Communist speech is protected by the First Amendment.)
The Founders themselves made heavy use of the anonymous pen name Publius when writing The Federalist Papers -- essentially an ad campaign for our current Constitution -- so it's easy to see where they stood on the subject when they wrote the Constitution.