Amusingly, that script improperly predicts survival on Windows when running it in ActivePerl 5.8.8, where ctime() returns an empty string if the date is greater than 2147483647 and thus doesn't see "1901".
The lifespan of software is pretty short anyway. A 5-year protection cycle is a huge motivator to get a new product out the door on a regular basis and keep the programmers employed.
...unless it's a 30+ year old COBOL program running on a mainframe - while today's software may not last longer than 5 years, software from many decades ago most certainly did.
under the rules there's no penalty for the 5 day waiting period. The squatters drop them before they pay any money.
Then trick them into thinking the domains are "real". Expand the dictionary-DNS script to keep track of the fake domains it queried and retry them occasionally - if they get registered, then add them to another list and start actively querying the webpages to generate "hits" for them.
For optimum performance, publish both lists (both queried and subsequently registered domains) somewhere online so other people can also participate (and then hope some "savvy" spammer doesn't arrange for the Storm Worm botnet to remove you from the Internet).
Alternatively, trick them into launching a DDoS on a site more than capable of sinking all of the attack with plenty of bandwidth to spare - there's nothing quite like trying to flood an internet backbone. Plus, if it actually did have a noticeable effect, such a massive outage would be more likely encourage appropriate law enforcement agencies (of whatever nations) to get off their collective asses and actually solve the problem at its source.
Not particularly likely to happen, but we can all dream, can't we?
One almost has to wonder if the current 35% "success rate" is for truly successful projects, as opposed to ones where the only criteria for success was completing it. An article from WorseThanFailure (previously TheDailyWTF), originally intended to explain why the site's name had changed, does a nice job of explaining just why "success rates" can be misleading.
Also, it's too obvious. A better solution is to hack apart a cheap phone to put the mouthpiece microphone and the earpiece speaker within about 1 centimeter of each other (I've had a few phones which did this very briefly when hanging up, just due to the shape of the holder), then take it off the hook. The high-pitched squealing of runaway audio feedback will probably catch them off-guard, and it can make for some very amusing scenarios if you explain that you're having phone problems and pretend you're actually interested in whatever they're selling.
When dealing with old-fashioned EPROMs, all bits are "1" when the ROM is erased. When you program it, some of the "1" bits go to "0" in order to represent the data you wanted to write.
Now, it's certainly possible to change additional "1" bits into "0"s into the ROM and change the data further, but it is not possible to change a "0" into a "1" without erasing the entire EPROM (by removing it from whatever device it was in and shining ultraviolet light into window on the top of the chip).
My guess is that something similar is happening here.
I had a similar problem with a rather old 5.25" half height 80MB Quantum SCSI drive in my old Amiga about 10 years ago - after leaving the system dormant for a long time, the drive wouldn't spin up. I had to take out out of the case and shake it gently along its axis (radially) before it would spin up. Evidently, this was caused by the heads parking and then sticking to the disk surface (apparently due to the lubricants breaking down) with such force that not even the motor could overcome it. It always worked fine after shaking, though (at least until I replaced it with a (physically) smaller 230MB drive several years later).
You must be using a European keyboard - US ones don't have "Alt Gr" of any sort.
* What the hell is that back-tick key doing up in the top left anyway? And why does it look so odd paired with a normal quote?
It actually isn't a backwards quote, from what I can tell - it's a grave accent. Why the standard keyboard layout has a lone grave accent key, I have no idea; it probably dates back to typewriters so you could backspace and type the accent on top of an existing character (and ^ for a circumflex and ' for an acute accent, back when it was actually slanted to make it multi-purpose). This is probably also why people still use it for a backward quote in stuff like old man pages, even though ``text'' looks really odd in most modern fonts (there's probably some reason why normal "quotes" can't be used, but I don't know it).
Considering the Japanese language hasn't used the "wi" sound (equivalent to English "we", French "oui", etc.) in native words since the language reforms over 60 years ago (at which point it was dropped down to just "i"), I doubt it.
That's 585MB for the raw page data.
Don't forget, all of the Wikipedia pages are enclosed in in nice pretty HTML documents. A quick test (by taking an HTML snapshot of an article and then removing the article content and all "dynamic" content such as edit/history/etc. links) indicates around 4KB of overhead per page (possibly less given further optimization).
Multiply that by 520794 articles, and that up to around 2 gigabytes.
That's still not including the overhead from cross-wiki links or multimedia...
...there would be some very significant side effects to such modifications:
1. NES audio is generated within the 'RP2A03G' (CPU) chip and is based on clock cycles, so doubling the CPU clock will cause the audio to go up an octave (assuming it even runs). The site mentioned in the article actually pointed this out, so it looks like it's legitimate.
2. Games which use cycle-timed code will no longer work properly - Battletoads is the first that comes to mind.
3. Some NES cartridges only used 250ns PRG ROM chips, which is only good up to 2MHz; go any higher and the game may not run at all.
Damn thing would just cause the Nintendo to do a reset each time. IIRC, the cartiridge came with a note saying that the Action 52 would have to reset 4 or 5 times before it would start working.
Since it wasn't licensed by Nintendo, it didn't have a lockout chip in it (which would normally chatter with a similar chip in the console and stop it from constantly resetting). Instead, it used some messed up hardware (usually consisting of a -5V charge pump) to literally try and stun the console's lockout chip into submission and let the game run.
Obviously, these methods didn't always work; later versions of the frontloading console rendered most of these methods totally useless. The toploading NES can run them fine, though, since Nintendo decided to get rid of the NES lockout chip in the end (since that's what caused dirty carts to blink the screen).
If you absolutely *need* pretty styles in your email messages, why not use something safer, like RTF (Rich Text Format)? MS Outlook [Express?] already supports it, so most of the people you describe should already be able to use it.
The trouble is, [Mike Tyson's] Punch-Out!! uses a rather peculiar memory mapper (the Nintendo MMC2), one that takes a lot of extra processor power to emulate properly (each time it renders one of two particular background/sprite tiles, it needs to *immediately* switch to a different set of character data). Properly emulating the MMC2 would likely not be easy on a system as slow as the GBA, so they probably gave up on Punch-Out!! (the *only* game to use the MMC2).
The clock in many games is based not on an actual clock but the speed of the processor... speed things up and you speed everything in the game up, and that's not very playable.
The CPU speed is usually NOT used for game timing in cases like this (well, in older NES games it was, but usually not for the faster systems). The main source of timing in video games is the video refresh which, on game consoles, is always 60Hz. Increasing the clock speed simply allows the game to get more work done during each frame so it doesn't have to slow the game down to catch up.
Since Linux is mostly used commercially for servers, this would be comparing Linux 699 for Microsoft's Windows Server (ver 2003 is currently 600 for full server). So the difference is rather small.
Yes, except for the fact that the Windows server you mentioned has support for up to FOUR processors, while the Linux 699 is for ONE processor - for 4 processors, SCO wants $2,499.
Slashdot Mirror
Amusingly, that script improperly predicts survival on Windows when running it in ActivePerl 5.8.8, where ctime() returns an empty string if the date is greater than 2147483647 and thus doesn't see "1901".
For optimum performance, publish both lists (both queried and subsequently registered domains) somewhere online so other people can also participate (and then hope some "savvy" spammer doesn't arrange for the Storm Worm botnet to remove you from the Internet).
Alternatively, trick them into launching a DDoS on a site more than capable of sinking all of the attack with plenty of bandwidth to spare - there's nothing quite like trying to flood an internet backbone. Plus, if it actually did have a noticeable effect, such a massive outage would be more likely encourage appropriate law enforcement agencies (of whatever nations) to get off their collective asses and actually solve the problem at its source.
Not particularly likely to happen, but we can all dream, can't we?
Ah, so you're the one that got bitten by The Spider of Doom. Or at least you're another person who got bitten by a variant of it.
One almost has to wonder if the current 35% "success rate" is for truly successful projects, as opposed to ones where the only criteria for success was completing it. An article from WorseThanFailure (previously TheDailyWTF), originally intended to explain why the site's name had changed, does a nice job of explaining just why "success rates" can be misleading.
Presumably, you meant "outside of our solar system", which would probably be a bit more accurate.
When dealing with old-fashioned EPROMs, all bits are "1" when the ROM is erased. When you program it, some of the "1" bits go to "0" in order to represent the data you wanted to write.
Now, it's certainly possible to change additional "1" bits into "0"s into the ROM and change the data further, but it is not possible to change a "0" into a "1" without erasing the entire EPROM (by removing it from whatever device it was in and shining ultraviolet light into window on the top of the chip).
My guess is that something similar is happening here.
I had a similar problem with a rather old 5.25" half height 80MB Quantum SCSI drive in my old Amiga about 10 years ago - after leaving the system dormant for a long time, the drive wouldn't spin up. I had to take out out of the case and shake it gently along its axis (radially) before it would spin up. Evidently, this was caused by the heads parking and then sticking to the disk surface (apparently due to the lubricants breaking down) with such force that not even the motor could overcome it. It always worked fine after shaking, though (at least until I replaced it with a (physically) smaller 230MB drive several years later).
That's 585MB for the raw page data.
Don't forget, all of the Wikipedia pages are enclosed in in nice pretty HTML documents. A quick test (by taking an HTML snapshot of an article and then removing the article content and all "dynamic" content such as edit/history/etc. links) indicates around 4KB of overhead per page (possibly less given further optimization).
Multiply that by 520794 articles, and that up to around 2 gigabytes.
That's still not including the overhead from cross-wiki links or multimedia...
...there would be some very significant side effects to such modifications:
1. NES audio is generated within the 'RP2A03G' (CPU) chip and is based on clock cycles, so doubling the CPU clock will cause the audio to go up an octave (assuming it even runs). The site mentioned in the article actually pointed this out, so it looks like it's legitimate.
2. Games which use cycle-timed code will no longer work properly - Battletoads is the first that comes to mind.
3. Some NES cartridges only used 250ns PRG ROM chips, which is only good up to 2MHz; go any higher and the game may not run at all.
Obviously, these methods didn't always work; later versions of the frontloading console rendered most of these methods totally useless. The toploading NES can run them fine, though, since Nintendo decided to get rid of the NES lockout chip in the end (since that's what caused dirty carts to blink the screen).
Now, if it had been "Word 2005", then it might've been slightly more believable...
The one seen on Red Dwarf: Smegway
If you absolutely *need* pretty styles in your email messages, why not use something safer, like RTF (Rich Text Format)? MS Outlook [Express?] already supports it, so most of the people you describe should already be able to use it.
Actually, I believe XP Professional will support up to 2 CPUs.
You mean aside from the Game Axe (mass produced), or Portendo (someone's personal project), or anything else I probably missed?