To all those (sanctimonious) posters who say "gosh, those guys claim that they are nature loving, but then they condone cutting down trees to make computer parts" :
Well what renewable resource is your computer case made of?
Well, they have to remove entire mountains from the ground to get metal, and I can't say that the petrol industry (you know, plastics!) is too "nature friendly."
So come back when you're typing on keyboards assembled from windfall wood and bones of animals that died of natural causes. Otherwise I really don't want to hear about it.
Don't use BLAST or SHRED. Better methods exist!
on
More on SCO Code Snippets
·
· Score: 5, Informative
Arrg!
No, BLAST won't work. ESR's SHRED won't work. These are, at heart, text matching algorithms, which are easily defeated and of little relevance. Let me explain.
Any simple code obfuscation techniques (changing variable names, adding/removing comments, inserting newlines, changing for loops to while loops, etc.) will totally defeat SHRED and will likely give BLAST a hard time, if not break it entirely.
Why? SHRED searches for lines with identical MD5 sums. If every/most line of purloined code has been changed, even slightly, SHRED fails. BLAST works by finding "seed" regions of identity and then growing those regions out to "near matches." Unfortunately, the idea of a "near match" is a lot more clear cut in DNA/protein than in code, and the initial seeding breaks if the code has been obfuscated at all.
SCO would (wisely) never accept a negative SHRED or BLAST result as proof for just these reasons.
What is necessary is a comparison of the code structure, NOT the simple text of the code. Stanford's, for example (and many other) CS department detects cheating by chewing through source files and turning them into an intermediate representation (think: parse tree) which describe directly the STRUCTURE and FUNCTION of a bit of code in a way that is completely divorced from the text of that code. To find out if people cheated, they compare the parse trees from their code -- not the text of the code.
In this way, they can easily detect (with a surprisingly low false positive rate) when two pieces of textually different code actually stemmed from the same source (but one was then obfuscated to cover up the cheating.)
This is the way to compare code fragments. Not borrowing text-matching (or near-matching) from unrelated disciplines.
I have a beige G3 266 and it works fine with Jag. Sure, there are annoying slowdowns at times, but for the large part I find it tolerable to do most things.
Illustrator and Photoshop open at the same time? Works just fine. Playing MP3s and working with the same? Fine.
So, my suggestions for what to add?
(1) More RAM, like everyone said. (2) A better video card. There's no hardware OpenGL support for the rage pro (or worse, rage II) that's in your machine. I had a ATI Radeon PCI card that I got on ebay and it worked great. (3) Don't bother with a faster hard drive/ATA controller unless you're really hurting. The stock kit is pretty OK unless you're doing disk intensive things. (4) You can get a cheapo no-name 10/100 ethernet card for like $5-10. Many generic cards use a RealTek 8139 chipset for which you can download OS X drivers. (5) The beige G3's were the most overclockable Macs Apple ever made. Many of the chips can easily be bumped to 300 or 333, and the jumper configuration to do so is dead simple. You can also juice up the FSB nicely to eke out a bit more bandwidth. If you want, slap a better heatsink on the chip (486 heatsinks work well) or just some thermal paste, but that's not necessary.
Check out xlr8yourmac.com for all of the details about overclocking and otherwise modifying Beige G3s (and other macs). They provide the best info hands down.
In sum: Keep with it! Beige G3s are great workhorse machines, and run Jaguar just fine.
The question asked was about (1) possible problems with a totally ad-hoc communication model, and (2) what solutions to those problems may be.
Typically, everyone immediately leapt all over the problems, but nobody seems to have any interest in the solutions.
Well, here are some ideas about what you would need to make this work and to deal with the problems.
Problem 1: Freeloaders.
Well, you could design a tit-for-tat protocol where you never rebroadcast packets from a freeloader. Think Bittorrent, where if you don't share, you don't get good download badnwidth. The game-theoretic knowledge is there to design an ad hoc protocol where the Nash equilibrium behavior is to not freeload.
Problem 2: Long Hops.
OK, so long distance pipes cost money. And they won't go away soon, because some, posibly large, fraction of traffic needs them. So let the operators of the pipes charge tolls. You could have a whole ad hoc marketplace where some people let you use their hardware for free, and others charge. You tell your computer how much money and what QoS you want, and it tries to route effectively.
There are problems here, of course. One is how to establish trust -- how to do billing in an anonymous ad hoc system? Some sort of self-signed certs might be made to work... or maybe we'd need a palladium-ish technology? Either of these solutions can also help with the problem of needing end-to-end encryption on everything.
So there. I've thrown out some solutions. They may have problems, but at least its a start, instead of grousing about the original question.
Slashdot Mirror
To all those (sanctimonious) posters who say "gosh, those guys claim that they are nature loving, but then they condone cutting down trees to make computer parts" :
Well what renewable resource is your computer case made of?
Well, they have to remove entire mountains from the ground to get metal, and I can't say that the petrol industry (you know, plastics!) is too "nature friendly." So come back when you're typing on keyboards assembled from windfall wood and bones of animals that died of natural causes. Otherwise I really don't want to hear about it.
Arrg!
No, BLAST won't work. ESR's SHRED won't work. These are, at heart, text matching algorithms, which are easily defeated and of little relevance. Let me explain.
Any simple code obfuscation techniques (changing variable names, adding/removing comments, inserting newlines, changing for loops to while loops, etc.) will totally defeat SHRED and will likely give BLAST a hard time, if not break it entirely.
Why? SHRED searches for lines with identical MD5 sums. If every/most line of purloined code has been changed, even slightly, SHRED fails. BLAST works by finding "seed" regions of identity and then growing those regions out to "near matches." Unfortunately, the idea of a "near match" is a lot more clear cut in DNA/protein than in code, and the initial seeding breaks if the code has been obfuscated at all.
SCO would (wisely) never accept a negative SHRED or BLAST result as proof for just these reasons.
What is necessary is a comparison of the code structure, NOT the simple text of the code. Stanford's, for example (and many other) CS department detects cheating by chewing through source files and turning them into an intermediate representation (think: parse tree) which describe directly the STRUCTURE and FUNCTION of a bit of code in a way that is completely divorced from the text of that code. To find out if people cheated, they compare the parse trees from their code -- not the text of the code.
In this way, they can easily detect (with a surprisingly low false positive rate) when two pieces of textually different code actually stemmed from the same source (but one was then obfuscated to cover up the cheating.)
This is the way to compare code fragments. Not borrowing text-matching (or near-matching) from unrelated disciplines.
I have a beige G3 266 and it works fine with Jag. Sure, there are annoying slowdowns at times, but for the large part I find it tolerable to do most things.
Illustrator and Photoshop open at the same time? Works just fine. Playing MP3s and working with the same? Fine.
So, my suggestions for what to add?
(1) More RAM, like everyone said.
(2) A better video card. There's no hardware OpenGL support for the rage pro (or worse, rage II) that's in your machine. I had a ATI Radeon PCI card that I got on ebay and it worked great.
(3) Don't bother with a faster hard drive/ATA controller unless you're really hurting. The stock kit is pretty OK unless you're doing disk intensive things.
(4) You can get a cheapo no-name 10/100 ethernet card for like $5-10. Many generic cards use a RealTek 8139 chipset for which you can download OS X drivers.
(5) The beige G3's were the most overclockable Macs Apple ever made. Many of the chips can easily be bumped to 300 or 333, and the jumper configuration to do so is dead simple. You can also juice up the FSB nicely to eke out a bit more bandwidth. If you want, slap a better heatsink on the chip (486 heatsinks work well) or just some thermal paste, but that's not necessary.
Check out xlr8yourmac.com for all of the details about overclocking and otherwise modifying Beige G3s (and other macs). They provide the best info hands down.
In sum: Keep with it! Beige G3s are great workhorse machines, and run Jaguar just fine.
Zach
Well, here are some ideas about what you would need to make this work and to deal with the problems.
Problem 1: Freeloaders. Well, you could design a tit-for-tat protocol where you never rebroadcast packets from a freeloader. Think Bittorrent, where if you don't share, you don't get good download badnwidth. The game-theoretic knowledge is there to design an ad hoc protocol where the Nash equilibrium behavior is to not freeload.
Problem 2: Long Hops. OK, so long distance pipes cost money. And they won't go away soon, because some, posibly large, fraction of traffic needs them. So let the operators of the pipes charge tolls. You could have a whole ad hoc marketplace where some people let you use their hardware for free, and others charge. You tell your computer how much money and what QoS you want, and it tries to route effectively.
There are problems here, of course. One is how to establish trust -- how to do billing in an anonymous ad hoc system? Some sort of self-signed certs might be made to work... or maybe we'd need a palladium-ish technology? Either of these solutions can also help with the problem of needing end-to-end encryption on everything.
So there. I've thrown out some solutions. They may have problems, but at least its a start, instead of grousing about the original question.