But I think that was his point. If you're using Perl you should be using CGI.pm, if you're using PHP you just use $_FILES, $_GET, and $_PUT. All of these abstract away most of the nitty gritty. You don't need to know whether the response used Chunked transfer-encoding or whether the browser enabled keep-alives. With abstractions, you just know the $_FILES["foo"] represents the uploaded file and that $_POST["bar"] corresponds to the "bar" element in your form.
I agree completely. The problem this article brings up is due completely to the fact that People Just Don't Understand Statistics.
I would be willing to hazard a guess that if you did a poll of "average guy on the street"-types, you would come to the conclusion that the prevailing conception of "one in a million chance" is that it's "something that kinda hardly ever happens but every once in a while it does happen to someone." They are confused because they're told lotteries have a "60 million to 1" chance of winning, for example, and yet there's always some poor slob every so often on TV that wins that jackpot. So "one in a million" comes to mean "not likely but it does happen."
The problem with this misconception is that if you repeat ANYTHING often enough you will start to accumulate positives, regardless of how uncommon that result is. The lottery may have a 100-million-to-1 chance of paying out, but when tens or hundreds of millions of people are playing it, you eventually expect a lot of winners.
Compare that to the case of a million-to-one chance of an asteriod striking on a certain date. It doesn't matter how many people are involved, since they're all observing the same event. Even if there are 6 billion people in the world, the chances of the asteroid striking are STILL one million to one, which is vanishingly small. It's not like the case of the lottery at all.
I think no matter what scale is chosen, reporters and scientists should somehow figure out a way to get word across without any actual statistical language. In other words, if you tell someone: "this has a vanishingly small chance of happening, there is no reason to be remotely concerned" then hopefully they will get the idea. But if you say "The chance of this happening is a mere million to one" they might think: "gee, million to one... that's better than the lottery, and people win that all the time. Holy crap, I'm off to get flashlights and fresh water!"
So what you're saying is "write a program to determine if a picture is kiddy porn." Have you any idea what you are asking for? I don't think that is at all possible. Image recognition currently only works when you have very controlled and well-known parameters, such as camera angles, lighting, subject matter, etc. To write a program that would take any picture and be able to determine "this is kiddie porn" would be close to impossible. And remember, to be useful it's got to have a very low false-positive rate, otherwise it's just going to waste a lot of someone's time and end up achieving nothing. See the facial-recognition quagmire for how this works (or rather, doesn't work at all.) And facial recognition is light years easier than what you're advocating, since all that needs to be done is compare a target face to a list of known faces and see if features match.
There is a lot of porn out there, and to have a computer deal with the sheer number of variations is just unrealistic. Heck, you couldn't do this with a HUMAN, let alone a program. I bet you could show a person a borderline porn image and they wouldn't be able to tell you whether the actors are underage or not. The porn industry tries very hard to blur that line, to make legal actors look illegal. If a human cannot make this distinction with any accuracy, a computer never will be able to, since such a decision relies on very subtle human abilities to recognise facial features and other cues. Hell, I bet you'd have great difficulty writing a program to tell whether a picture contains a male or a female (or both), let alone trying to determine their ages.
No, everyone is not root and everyone cannot make changes to system resource files. At least, if setup properly. If you always login as Administrator then you might have the false impression that this is true. But on a system installed by an administrator that has a clue, it is certainly possible for users to not be able to read or write parts of the registry, files, etc. Just because you don't know how to do this doesn't mean it's not possible. Everyone is NOT root!
...and now thanks to the likes of SoBig, you get to contribute to the problem of filling up random people's inboxes with meaningless junk. If you're going to do this, you should also implement a rule to ignore or delete known email worms, otherwise you're just part of the problem.
And I object to the word "story" used to describe either.
What do we have here? Someone noticed that blogs.yahoo.com redirects to groups.google.com. There's also a link to a korean yahoo site that makes no sense to me whatsoever. How is this a story? Why was this accepted? It makes no sense. I would say that this submission is pure speculation but I don't want to even go that far.
Why is everyone so quick to mention BitTorrent? It's totally inappropriate for this. Here's why: in order to make something available for download with the BitTorrent protocol, you have to create the.torrent metadata file which contains SHA1 hashes of all of the segments of the file. In other words, you need to download the dataset from the source server first before you can share it w/BT. Now, the whole point here is that within the organization BW is plentiful and abundant -- the part that he wants to avoid is hitting the origin server unless it's really necessary. So if he were to use BT he'd have to setup a cron job or something to automatically fetch the data and run it through btmakemetafile.py. This means that they data will necessarily be available inside his organization, where BW is basically "free", so what's the point of using BT on the internal network? You might as well just ftp/scp the file from one server to another, no need to go to all the trouble of running a BT server and making a new metafile every time the data file changes.
Additionally using BT would turn out to be -more- wasteful, for two reasons: One, because to make the data available you'd have to automatically retrieve it from the origin server, regardless of if there is a demand for it or not. Secondly, BT is still a somewhat of a niche protocol and so there's a good chance that there would be people that say "screw this, I don't want to instll Python and wxWindows just to get this file that I can download with Mozilla in about 3 seconds."...And these people would just download it directly from the source, increasing the load on the origin server and completely missing the point.
I'm with the person that said setup a caching proxy server. Squid will do this perfectly, and it doesn't involve making the users change at all -- it's all behind the scenes if you set it up as a transparent proxy. There will be no wasteful cron-job downloading since Squid will simply cache whatever the users are requesting -- if no one needs data for some period there's no point in wasting the weather site's bandwidth on some cron job ftp thing.
Please don't be so fast to suggest something like BitTorrent just because it's trendy.
When I see things like the program time going from 39m 08s to 11m 21s (when all that was changed was a minor version number) that just screams -bad testing-.
You should repeat every one of the tests a number of times, and make sure that you get the same (or similar) results each time. You should not NEVER expect a 4:1 ratio of performace doing the exact same task on identical hardware. Bells should be going off that say "casual testing" when you see something like that.
Besides, there are so many variables that have to be kept the same between the different installs - which services are running, how they are configured, what kernel options are set, what patches have been applied to the kernel, which modules are loaded... If you pick up Redhat 9 and do a "kitchen sink" install, you will hardly have the same amount of free RAM for caching, etc. compared to doing the "regular" install of some other distro that leaves out things. Hopefully it's obvious that such a comparison that would not be fair at all.
In short, you should take a given kernel source, with a fixed set of patches, options, settings, modules, etc., and complile it with the default i386 options and then a second time with all the fancy optimizaions, then compare those. LEAVE EVERYTHING ELSE THE SAME! Repeat with glibc.
The results in this article are just pathetic. They vary all over the place and are crying out for more rigorous testing methods and procedures. Making a good test is really a science, you have to design the test to specifically measure what it is that you're interested in. For all we know one of those tests could have already had a majority of the libraries loaded into the disk cache, resulting in the huge performance differences.
This is misleading. While true, it only applies to BOXED RETAIL CPUs from AMD. Their reasoning is that if you buy a retail CPU and use it with -anything- but the supplied fan, heat sink, or phase-change thermal material, you void your warranty. That's a pretty straightforward situation, you have to use the supplied combo to qualify for a warranty. They are concerned about the conductivity of some metal-bearing pastes, and the thermal pump-out issue. Go try to get warranty service for an engine-related issue from Ford or GM after installing an aftermarket intake and see how far you get.
Most of us don't buy retail CPUs because of the price premium (and rather pedestrian heat sink/fan) and hence this is not an issue at all. For OEM CPUs, your warranty is with your vendor, not AMD, and most vendors are pretty sane about honoring their stated warranty (be that 14 days, 30 days, whatever) regardless of what thermal paste you use, as long as you didn't do damage to the chip installing it. And in the vast majority of cases, if a chip is going to fail because of a defect it will fail in the initial burn-in period which would fall under most vendors' warranty. Barring cooling/power supply failures, if it makes it past the first week it's probably going to last until you decide to upgrade it.
All good points. There are even methods described in the literature (I'm told) that involve exotic processes such as etching away the face of the silicon die and then exposing it to a high-powered photoflash, to cause a latch-up condition and allow the contents of memory to be probed; or subjecting the sample to corner-case conditions of temperature/voltage/clocking or otherwise fiddling with the clock rate so as to inspect the contents of memory. We're even into the realm of James Bond-esque devices that self destruct when their casing is breached, and other anti-tampering methods. It seems that most anything is vulnerable if the stakes are high enough.
I also submit that the reason Circuit City's DIVX was never cracked was because the reponsible parties folded and quit approximately 8 months after the rollout. Also, the resistance of Warner and Columbia (accounting for 40% of the rental market at the time) meant that none of their content was available in DIVX format. This might have caused a lesser appeal to hackers, compared to a format that had universal backing (standard DVD / CSS.)
If each camera has to be uniquely stamped with a individual public key, then you've just lost one of the major cost advatages of these things: that they can be mass produced cheaply. One common way around this might be to use flash/eeprom so that a unique key could be installed via automation, or by a worker trained simply to "place camera in cradle for programming." However, now you leave yourself open to the possibility of someone figuring out how to reflash the stored key with their own public key, so that they can decrypt the pictures. You then might be tempted then to use something like an EPROM, where fuses are permanently blown or connections otherwise severed to create the key's image... But if someone is determined they will figure out a way to create a new public/private keypair based on the stored public key such that this new public key can be installed simply by severing some of the remaining intact fuses.
This doesn't even begin to address the attack methods that involve stealing/obtaining the hardware from one of the thousands of processing locations that communicates to the home base; or hacking the central server directly; or strategically tapping the interconnects between the main ASIC and the key-storage device, and injecting your own public key; or analyzing the power/current vs. time plot of the ASIC during the encryption phase; or any of a number of other existing methods that have been developed to break smartcards / iButtons / embedded crypto.
My point is not that your plan wouldn't be fairly secure. Rather, I take specific issue with your subject line "PKI = unhackable" because given enough motivation, there are heaps of ways to break such a system. I would dare say that no system can possibly be "unhackable" given sufficient motivation from the attacker.
Okay, this article is a thinly veiled promo for ActiveState. This so-called field guide contains a handful of tricks that are mostly obvious to anyone that knows a little bit about HTML or MIME-Encoding. You would be much better off combing through SpamAssassin's extensive list of heuristics rathen then reading a boring rehash of "Hey! you can hide stuff in HTML comments! Betcha didn't know that! (Subscribe to our newsletter, thanks.)"
If the files are text files, you could probably do worse than RCS -- you know, the Revision Control System?
Say you have a file foo.txt. Start a repository by running ci -l foo.txt. This should ask you for a description of the file and will create foo.txt,v Now send your file to your peers, have them make changes and send the file back to you. When you receive their file, check it in with ci and give it a ChangeLog-type description. Then you can see what changes they made with rcsdiff, maintain your own branch of revisions (just like with source code), check out someone's version for inspection, etc. This would really only work well if one central person maintains the repository, or it's in a common directory somewhere.
This would be more straightforward with CVS, except that CVS requires either a pserver setup or a shared directory that everyone can access r/w, as well as the CVS client software. With RCS it's a little more work but you can pass the files around as regular files rather than having CVS maintain the repository. I suppose you could even pass around the,v file -- have the person check in his changes and mail it out to everyone else. But that's kind of clunky, really.
I suggest a few changes to your perl "oneliner" on your page.
First, you can use -0777 to enable slurp mode. Add -n to automatically read. Finally, for god's sake, use some character OTHER THAN / for your re-delimiter (aka leaning toothpick syndrome)
So the final command could be simplified to:
perl -0777ne 'print m!regexp!g;' file.c
I can't actually include the regexp because of slashdot's lameness filter, but you don't have to escape forward slashes in it.
And I don't know why you have the outermost set of parens anyway.
More precisely, every one of these systems sold is a linux user for about 30 minutes, until the buyer realizes they have to pay some yearly fee (such as Lindows' Click-n-Run) or can't run any games. Then the hard drive is wiped and that warez version of windows is installed.
And none of them will allow a zone transfer (AXFR), so this entire thread is incorrect.
To actually get the com/net/org zone files, you have to sign and return this big nasty thing promising not to spam or otherwise abuse the data. After processing you are assigned a username and password with which you can FTP the zone files.
You dork, Go Daddy is the registrar not the registrant. Please learn to read. It's registered to a "Jerry Ferguson" who has it parked, meaning he's probably a squatter. Registrant: None
400 N University Ave.
Apt. 505
Little Rock, Arkansas 72205
United States Registered through: Go Daddy Software (http://www.godaddy.com)
Domain Name: MSNBOT.COM
Created on: 12-Apr-02
Expires on: 12-Apr-04
Last Updated on: 29-Jan-03
Administrative Contact:
Ferguson, Jerry ferguson_jerry@hotmail.com
None
400 N University Ave.
Apt. 505
Little Rock, Arkansas 72205
United States
(501)-666-0626
Technical Contact:
Ferguson, Jerry ferguson_jerry@hotmail.com
None
400 N University Ave.
Apt. 505
Little Rock, Arkansas 72205
United States
(501)-666-0626
Domain servers in listed order:
PARK3.SECURESERVER.NET
PARK4.SECURESERVER.NET
Aside from the general tinfoil-hat paranoia, there are two large problems:
It's not as reliable as you'd think. There was a slashdot story a while ago about a study of the most common fingerprint readers on the market and the conclusions were quite horrifying. For one thing, it was found that the majority of them could be easily faked with easy-to-obtain materials like gummy bears and scotch tape.
If someone were to lift your prints off something you touched, and then commit identity theft, there's no easy way for you to get new fingerprints. I know this doesn't directly apply to the case of fingerprint readers in cop cars, but the point is that if that were to happen then law enforcement would become even more dependent on prints, moreso than they are now...perhaps to the point where they are solely dependent. If the ONLY ID you have is your fingerprints (as opposed to a passport, drivers license, etc.) then your life becomes significantly more complicated when identity theft or fraud is involoved.
As I'm sure others have pointed out, the armada of recent Mars missions is due to its orbit lining up with Earth's such that the two are particularly close to each other. This happens about every 50,000 years, so I suppose it's good to take advantage of it while we can. Not like we'll be around for the next one...
It would have no effect on metal detectors. The metal detectors work by sensing the rather distinct change in magnetic permeability of the space near the coil that occurs when something containing ferromagnetic elements (iron, nickel, cobalt) is present.
By the way, did anyone else think that guy mentioned in the article who died because he failed to mention his pacemaker (even when asked several times) should be nominated for a Darwin award?
Slashdot Mirror
But I think that was his point. If you're using Perl you should be using CGI.pm, if you're using PHP you just use $_FILES, $_GET, and $_PUT. All of these abstract away most of the nitty gritty. You don't need to know whether the response used Chunked transfer-encoding or whether the browser enabled keep-alives. With abstractions, you just know the $_FILES["foo"] represents the uploaded file and that $_POST["bar"] corresponds to the "bar" element in your form.
I see your "graphic design principles" and raise you "a grammar and style reference."
I agree completely. The problem this article brings up is due completely to the fact that People Just Don't Understand Statistics.
I would be willing to hazard a guess that if you did a poll of "average guy on the street"-types, you would come to the conclusion that the prevailing conception of "one in a million chance" is that it's "something that kinda hardly ever happens but every once in a while it does happen to someone." They are confused because they're told lotteries have a "60 million to 1" chance of winning, for example, and yet there's always some poor slob every so often on TV that wins that jackpot. So "one in a million" comes to mean "not likely but it does happen."
The problem with this misconception is that if you repeat ANYTHING often enough you will start to accumulate positives, regardless of how uncommon that result is. The lottery may have a 100-million-to-1 chance of paying out, but when tens or hundreds of millions of people are playing it, you eventually expect a lot of winners.
Compare that to the case of a million-to-one chance of an asteriod striking on a certain date. It doesn't matter how many people are involved, since they're all observing the same event. Even if there are 6 billion people in the world, the chances of the asteroid striking are STILL one million to one, which is vanishingly small. It's not like the case of the lottery at all.
I think no matter what scale is chosen, reporters and scientists should somehow figure out a way to get word across without any actual statistical language. In other words, if you tell someone: "this has a vanishingly small chance of happening, there is no reason to be remotely concerned" then hopefully they will get the idea. But if you say "The chance of this happening is a mere million to one" they might think: "gee, million to one... that's better than the lottery, and people win that all the time. Holy crap, I'm off to get flashlights and fresh water!"
So what you're saying is "write a program to determine if a picture is kiddy porn." Have you any idea what you are asking for? I don't think that is at all possible. Image recognition currently only works when you have very controlled and well-known parameters, such as camera angles, lighting, subject matter, etc. To write a program that would take any picture and be able to determine "this is kiddie porn" would be close to impossible. And remember, to be useful it's got to have a very low false-positive rate, otherwise it's just going to waste a lot of someone's time and end up achieving nothing. See the facial-recognition quagmire for how this works (or rather, doesn't work at all.) And facial recognition is light years easier than what you're advocating, since all that needs to be done is compare a target face to a list of known faces and see if features match.
There is a lot of porn out there, and to have a computer deal with the sheer number of variations is just unrealistic. Heck, you couldn't do this with a HUMAN, let alone a program. I bet you could show a person a borderline porn image and they wouldn't be able to tell you whether the actors are underage or not. The porn industry tries very hard to blur that line, to make legal actors look illegal. If a human cannot make this distinction with any accuracy, a computer never will be able to, since such a decision relies on very subtle human abilities to recognise facial features and other cues. Hell, I bet you'd have great difficulty writing a program to tell whether a picture contains a male or a female (or both), let alone trying to determine their ages.
Please try a dose of reality.
I will personally bludgeon to death anyone who posts a "Beuwulf cluster" joke to this story. Let's just get that out of the way...
...and Farscape is declared a national treasure, and the "Trekker's Rights" movement gets a sudden infusion of legitimacy..
No, everyone is not root and everyone cannot make changes to system resource files. At least, if setup properly. If you always login as Administrator then you might have the false impression that this is true. But on a system installed by an administrator that has a clue, it is certainly possible for users to not be able to read or write parts of the registry, files, etc. Just because you don't know how to do this doesn't mean it's not possible. Everyone is NOT root!
...and now thanks to the likes of SoBig, you get to contribute to the problem of filling up random people's inboxes with meaningless junk. If you're going to do this, you should also implement a rule to ignore or delete known email worms, otherwise you're just part of the problem.
And I object to the word "story" used to describe either.
What do we have here? Someone noticed that blogs.yahoo.com redirects to groups.google.com. There's also a link to a korean yahoo site that makes no sense to me whatsoever. How is this a story? Why was this accepted? It makes no sense. I would say that this submission is pure speculation but I don't want to even go that far.
Why is everyone so quick to mention BitTorrent? It's totally inappropriate for this. Here's why: in order to make something available for download with the BitTorrent protocol, you have to create the .torrent metadata file which contains SHA1 hashes of all of the segments of the file. In other words, you need to download the dataset from the source server first before you can share it w/BT. Now, the whole point here is that within the organization BW is plentiful and abundant -- the part that he wants to avoid is hitting the origin server unless it's really necessary. So if he were to use BT he'd have to setup a cron job or something to automatically fetch the data and run it through btmakemetafile.py. This means that they data will necessarily be available inside his organization, where BW is basically "free", so what's the point of using BT on the internal network? You might as well just ftp/scp the file from one server to another, no need to go to all the trouble of running a BT server and making a new metafile every time the data file changes.
...And these people would just download it directly from the source, increasing the load on the origin server and completely missing the point.
Additionally using BT would turn out to be -more- wasteful, for two reasons: One, because to make the data available you'd have to automatically retrieve it from the origin server, regardless of if there is a demand for it or not. Secondly, BT is still a somewhat of a niche protocol and so there's a good chance that there would be people that say "screw this, I don't want to instll Python and wxWindows just to get this file that I can download with Mozilla in about 3 seconds."
I'm with the person that said setup a caching proxy server. Squid will do this perfectly, and it doesn't involve making the users change at all -- it's all behind the scenes if you set it up as a transparent proxy. There will be no wasteful cron-job downloading since Squid will simply cache whatever the users are requesting -- if no one needs data for some period there's no point in wasting the weather site's bandwidth on some cron job ftp thing.
Please don't be so fast to suggest something like BitTorrent just because it's trendy.
When I see things like the program time going from 39m 08s to 11m 21s (when all that was changed was a minor version number) that just screams -bad testing-.
You should repeat every one of the tests a number of times, and make sure that you get the same (or similar) results each time. You should not NEVER expect a 4:1 ratio of performace doing the exact same task on identical hardware. Bells should be going off that say "casual testing" when you see something like that.
Besides, there are so many variables that have to be kept the same between the different installs - which services are running, how they are configured, what kernel options are set, what patches have been applied to the kernel, which modules are loaded... If you pick up Redhat 9 and do a "kitchen sink" install, you will hardly have the same amount of free RAM for caching, etc. compared to doing the "regular" install of some other distro that leaves out things. Hopefully it's obvious that such a comparison that would not be fair at all.
In short, you should take a given kernel source, with a fixed set of patches, options, settings, modules, etc., and complile it with the default i386 options and then a second time with all the fancy optimizaions, then compare those. LEAVE EVERYTHING ELSE THE SAME! Repeat with glibc.
The results in this article are just pathetic. They vary all over the place and are crying out for more rigorous testing methods and procedures. Making a good test is really a science, you have to design the test to specifically measure what it is that you're interested in. For all we know one of those tests could have already had a majority of the libraries loaded into the disk cache, resulting in the huge performance differences.
This is misleading. While true, it only applies to BOXED RETAIL CPUs from AMD. Their reasoning is that if you buy a retail CPU and use it with -anything- but the supplied fan, heat sink, or phase-change thermal material, you void your warranty. That's a pretty straightforward situation, you have to use the supplied combo to qualify for a warranty. They are concerned about the conductivity of some metal-bearing pastes, and the thermal pump-out issue. Go try to get warranty service for an engine-related issue from Ford or GM after installing an aftermarket intake and see how far you get.
Most of us don't buy retail CPUs because of the price premium (and rather pedestrian heat sink/fan) and hence this is not an issue at all. For OEM CPUs, your warranty is with your vendor, not AMD, and most vendors are pretty sane about honoring their stated warranty (be that 14 days, 30 days, whatever) regardless of what thermal paste you use, as long as you didn't do damage to the chip installing it. And in the vast majority of cases, if a chip is going to fail because of a defect it will fail in the initial burn-in period which would fall under most vendors' warranty. Barring cooling/power supply failures, if it makes it past the first week it's probably going to last until you decide to upgrade it.
All good points. There are even methods described in the literature (I'm told) that involve exotic processes such as etching away the face of the silicon die and then exposing it to a high-powered photoflash, to cause a latch-up condition and allow the contents of memory to be probed; or subjecting the sample to corner-case conditions of temperature/voltage/clocking or otherwise fiddling with the clock rate so as to inspect the contents of memory. We're even into the realm of James Bond-esque devices that self destruct when their casing is breached, and other anti-tampering methods. It seems that most anything is vulnerable if the stakes are high enough.
I also submit that the reason Circuit City's DIVX was never cracked was because the reponsible parties folded and quit approximately 8 months after the rollout. Also, the resistance of Warner and Columbia (accounting for 40% of the rental market at the time) meant that none of their content was available in DIVX format. This might have caused a lesser appeal to hackers, compared to a format that had universal backing (standard DVD / CSS.)
If each camera has to be uniquely stamped with a individual public key, then you've just lost one of the major cost advatages of these things: that they can be mass produced cheaply. One common way around this might be to use flash/eeprom so that a unique key could be installed via automation, or by a worker trained simply to "place camera in cradle for programming." However, now you leave yourself open to the possibility of someone figuring out how to reflash the stored key with their own public key, so that they can decrypt the pictures. You then might be tempted then to use something like an EPROM, where fuses are permanently blown or connections otherwise severed to create the key's image... But if someone is determined they will figure out a way to create a new public/private keypair based on the stored public key such that this new public key can be installed simply by severing some of the remaining intact fuses.
This doesn't even begin to address the attack methods that involve stealing/obtaining the hardware from one of the thousands of processing locations that communicates to the home base; or hacking the central server directly; or strategically tapping the interconnects between the main ASIC and the key-storage device, and injecting your own public key; or analyzing the power/current vs. time plot of the ASIC during the encryption phase; or any of a number of other existing methods that have been developed to break smartcards / iButtons / embedded crypto.
My point is not that your plan wouldn't be fairly secure. Rather, I take specific issue with your subject line "PKI = unhackable" because given enough motivation, there are heaps of ways to break such a system. I would dare say that no system can possibly be "unhackable" given sufficient motivation from the attacker.
Okay, this article is a thinly veiled promo for ActiveState. This so-called field guide contains a handful of tricks that are mostly obvious to anyone that knows a little bit about HTML or MIME-Encoding. You would be much better off combing through SpamAssassin's extensive list of heuristics rathen then reading a boring rehash of "Hey! you can hide stuff in HTML comments! Betcha didn't know that! (Subscribe to our newsletter, thanks.)"
If the files are text files, you could probably do worse than RCS -- you know, the Revision Control System?
,v file -- have the person check in his changes and mail it out to everyone else. But that's kind of clunky, really.
Say you have a file foo.txt. Start a repository by running ci -l foo.txt. This should ask you for a description of the file and will create foo.txt,v Now send your file to your peers, have them make changes and send the file back to you. When you receive their file, check it in with ci and give it a ChangeLog-type description. Then you can see what changes they made with rcsdiff, maintain your own branch of revisions (just like with source code), check out someone's version for inspection, etc. This would really only work well if one central person maintains the repository, or it's in a common directory somewhere.
This would be more straightforward with CVS, except that CVS requires either a pserver setup or a shared directory that everyone can access r/w, as well as the CVS client software. With RCS it's a little more work but you can pass the files around as regular files rather than having CVS maintain the repository. I suppose you could even pass around the
This just in: Mensa Test Shown To Effectively Test For Ability To Take Mensa Tests, Not Much Else.
I suggest a few changes to your perl "oneliner" on your page.
First, you can use -0777 to enable slurp mode. Add -n to automatically read. Finally, for god's sake, use some character OTHER THAN / for your re-delimiter (aka leaning toothpick syndrome)
So the final command could be simplified to:
perl -0777ne 'print m!regexp!g;' file.c
I can't actually include the regexp because of slashdot's lameness filter, but you don't have to escape forward slashes in it.
And I don't know why you have the outermost set of parens anyway.
More precisely, every one of these systems sold is a linux user for about 30 minutes, until the buyer realizes they have to pay some yearly fee (such as Lindows' Click-n-Run) or can't run any games. Then the hard drive is wiped and that warez version of windows is installed.
And none of them will allow a zone transfer (AXFR), so this entire thread is incorrect.
To actually get the com/net/org zone files, you have to sign and return this big nasty thing promising not to spam or otherwise abuse the data. After processing you are assigned a username and password with which you can FTP the zone files.
You dork, Go Daddy is the registrar not the registrant. Please learn to read. It's registered to a "Jerry Ferguson" who has it parked, meaning he's probably a squatter.
Registrant: None
400 N University Ave.
Apt. 505
Little Rock, Arkansas 72205
United States
Registered through: Go Daddy Software (http://www.godaddy.com)
Domain Name: MSNBOT.COM
Created on: 12-Apr-02
Expires on: 12-Apr-04
Last Updated on: 29-Jan-03
Administrative Contact:
Ferguson, Jerry ferguson_jerry@hotmail.com
None
400 N University Ave.
Apt. 505
Little Rock, Arkansas 72205
United States
(501)-666-0626
Technical Contact:
Ferguson, Jerry ferguson_jerry@hotmail.com
None
400 N University Ave.
Apt. 505
Little Rock, Arkansas 72205
United States
(501)-666-0626
Domain servers in listed order:
PARK3.SECURESERVER.NET
PARK4.SECURESERVER.NET
And when that day comes, slashdot will be there, providing a link with pictures...that will probably stop responding 5 minutes after it's posted.
</The-Daily-Show Announcer Voice>
As I'm sure others have pointed out, the armada of recent Mars missions is due to its orbit lining up with Earth's such that the two are particularly close to each other. This happens about every 50,000 years, so I suppose it's good to take advantage of it while we can. Not like we'll be around for the next one...
It would have no effect on metal detectors. The metal detectors work by sensing the rather distinct change in magnetic permeability of the space near the coil that occurs when something containing ferromagnetic elements (iron, nickel, cobalt) is present.
By the way, did anyone else think that guy mentioned in the article who died because he failed to mention his pacemaker (even when asked several times) should be nominated for a Darwin award?