This kind of thing's more common than a lot of people realize. A while back, I was in the OS group for on of the earlier SMP vendors. The chip we were using at the time was the Motorola 68040, and I discovered that there were serious differences between different chip revisions. For example, one revision would push a six-byte frame onto the stack for a particular floating-point exception, and another would push a ten-byte frame. Run code written for one revision on the other and you'd trash your stack. What we had to do was extract the chip revision at startup (somewhat of an interesting hack in itself, IIRC) and use it in our exception handlers to figure out where stuff was. Ick.
No comparison. The work for which he was awarded the Nobel prize was verifiably original. Nobody's found a paper containing those exact same ideas published twenty years earlier, at any rate, and yet that's pretty much exactly the case for Hex.
Thanks for playing. Now get back under your bridge.
Actually, Hex was first invented by Piet Hein, who is perhaps better known for the Soma cube. Nash claims to've invented the game independently, but somehow I just find that hard to believe.
I've often meditated about the guild parallel too. One aspect that particularly intrigues me is the idea of a guild house as a social/developmental/contact-making focus. Right now, people try to use their employer (or possibly their body shop) in that role, and it's a role in which those other-directed organizations are destined to fail.
In a slightly different vein, I wrote an article a while ago about yet another way to reason about developer capabilities and inclinations. It's mostly orthogonal to the guild approach, or perhaps even irreconcilable with it, but it might be interesting nonetheless.
I just noticed that Slashdot is treating the three parts of this one interview as three different stories, with three different sets of replies, etc. Yeah, that's really going to facilitate discussion, when half of the responses to question #1 appear in the first story and half in the third story from when people are done reading the whole set. Brilliant.
There are several others - HighRoad, SANergy, QVFS, etc. Also, let's not forget that DEC pretty much beat us all to the punch with work they did on VAXclusters.
I'm not trying to be an asshole, but my point is this happens all the time and it's rather easy with the proper drivers installed.
If you're not trying to be an asshole, what's with all the sarcasm? While it would be tempting to say that you can be an asshole without even trying, the more likely conclusion is that you really are trying and just want to leave yourself some wiggle room.
The problem is that caching occurs above the disk-driver level. Depending on the system, this might occur in the buffer cache, page cache, or within the filesystem itself, and that's just for data; there are usually things like inode/directory caches present as well. Writes directly through the driver or below - in this case directly to storage from another machine entirely - will result in those cached copies being stale without the filesystem knowing it.
If you still think drivers will save the day, it's easy enough to do an experiment and see how wrong you are. Write one program to access a file through the filesystem and all of the usual caches, while another figures out the actual on-disk location of that file's data and modifies it through the raw disk interface (bypassing everything above the disk driver). It shouldn't take you too long to see some stale data. For extra credit, try having the raw-disk program modify something other than a data block and see what happens.
As for your point about network filesystems, note that the ones you mention all funnel I/O through one machine. Usually, this means that the right cache interactions do occur on that machine, but I have actually seen implementations of NFS in particular where the server could not safely access the served volume for precisely these reasons. True shared-storage filesystems are very rare because it's such a pain, and I should know because I was co-architect for one of the few that ever made it to market. Believe me, I've wished that drivers solved these problems, but they simply don't.
...not after this observation I made last year. No, it's not proof of anything at all. It's just one more tiny piece of some puzzle; decide for yourself what you think it means.
The idea of using a distributed/replicated data store such as MojoNation or OceanStore for backup seems cool on the surface, and from a near-term customer-acceptance standpoint it definitely has advantages, but from a long-term technical standpoint one question does arise. If you have such a data store available to you, with appropriate performance and security characteristics, why would you store stuff locally (except for cached copies, which are evanescent rather than authoritative) at all? The ultimate goal of research in this area is not to facilitate backups but to make them unnecessary; what this project is doing is really a sort of "side trip" from that goal.
But how complex was the 8600? I can't find a specific number, but some sources say the later 9000 was still shy of a million gates. Researchers have already built async versions of MIPS and ARM cores more complex than that, and still seem leery of applying the same tools to anything on the order of a modern (superscalar, speculating, branch-predicting) CPU or 3D graphics chip.
Also, why is it that people who write about the history of asynchronous logic mention lots of other projects but not the 8600? Was it truly async, as the term would be understood today, or were there still synchronous aspects of the design? Perhaps you could elucidate by describing your equivalents of rendezvous or micro-pipeline structures.
Re:Small scale, and then larger
on
Clockless Computing
·
· Score: 4, Informative
You've hit the nail right on the head. Async circuits aren't harder to design; they're harder to verify and debug. Historically the tools just haven't been up to it and, despite some recent breakthroughs, I'm not sure they are now. Check out the work at CalTech, Manchester, and Theseus Logic for the current state of the art.
OK, asshole. How about we start with Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems presented at USENIX 2000? The first three authors should need no introduction, so I think it satisfies the "well known" requirement; in fact, one could hardly find a group of six people more qualified to comment on the matter. Even in the abstract, the authors clearly state the similarity between goals of journaling and soft updates:
In this paper, we explore the two most commonly used approaches for improving the performance of meta-data operations and recovery
The similarity is mentioned repeatedly elsewhere in the paper, all the way to the conclusion, but I'll let you do your homework this time.
Anybody who knows anything about filesytems - and I've been working on them for over a decade - recognizes the similarity in goals between journaling, soft updates, and phase trees. Usually it's considered too obvious even to require comment, unless an ignorant troll like you comes along demanding that the obvious be spelled out.
And as an experienced UNIX programmer, exactly what have you done to fix these problems you find in Linux?
I already addressed that issue, but apparently you need things spelled out even more clearly. I have other things that I want to do, some of which even benefit the open-source community in other areas. It's not in anyone's best interest for me to take time away from other projects to make up for a basic lack of diligence by the people who write video or hardware-monitoring drivers. It's far more efficient if I concentrate on doing my stuff right and those people concentrate on doing their stuff right, if not for our mutual benefit then maybe because doing stuff right is good in and of itself.
This isn't about the sorts of bugs that "just happen" despite reasonable development and testing procedures. This is about bugs that happened because a developer didn't even try to do a decent job, and deliberately chose to dump an inferior half-done piece of junk on users. Even that might be OK, if the thing they released were clearly labeled as experimental unfinished code, but relatively few open-source developers are that honest. Most deliberately claim that their stuff is just as feature-complete and just as stable and just as usable as commercial equivalents, when examples like these show that's not the case. It's not the reality of rough-around-the edges geek-only software that bothers me; it's the marketing of it as something else.
Admittedly, UNIX falls short of other OSes in some ways...What if Christopher Columbus had said, "You know what? Italy is alright, and besides, going over to the New World will be such a hassle."?
That's exactly the admission that most open-source advocates are unwilling to make. Going back to your analogy, their behavior is like Columbus claiming that he'd found America before he even set sail. Too many people are declaring victory for Linux on the desktop when there are plenty of battles still to be fought, and that's the false claim I addressed with my earlier post.
Why isn't Salamander trying to work on these problems?
Because I have plenty of other projects in the pipeline already, and can make more progress on those other projects by avoiding the platform where they occur than by fixing them. Were either not the case, things might be very different. As it is, I do try to help out here and there on open-source projects as time and talent allow, but I'm not about to abandon my own projects to become a near-full-time Linux bug-fixer.
Of course, lots of other people feel approximately the same way, and that's part of the problem. There's little incentive to do grunt work in open source, like there is in the commercial world where supply and demand can create lucrative opportunities for people willing to hold their noses. If it's no fun, and the pay's the same, why do it? Maybe what we need is some kind of barter system, so that people with complementary skills and problems can make arrangements so that each performs the (personally) least odious task and gets their (personally) most severe problem fixed. Sort of "you scratch my back, I'll scratch yours" instead of everyone doing contortions trying to scratch their own.
My reasons for not using Linux on the desktop are similar to this guy's, and I'd be willing to bet that very few of the people reading this are more technically able than I am so maybe it's another interesting data point. I was in the kernel group hacking the guys of a sophisticated SMP UNIX ten years ago and nowadays I write distributed filesystems for a living. I hack all day at work, then I go home and often hack some more. Conventional wisdom says I should love Linux, but it - and XFree86, which for all intents and purposes is part of the same package - has always been a big pain in the ass for me. Some examples:
Video support. Not too long ago I got a Shuttle SV24 bare-bones computer and got Linux running on it pretty quickly...but I could never get XFree86 4.x to work properly with the built-in graphics (fortunately 3.3.x works well enough). I tried the suggestions at XFree86.org, at the vendor's site, at a third-party driver maintainer's site. All had complex installs, plus extra hacking I had to figure out on my own; none yielded anything better than a system hung hard.
Hardware monitoring. Ever tried to install lm_sensors? It wouldn't even build properly (as modules) without hacking, the auto-detection didn't work at all, and the docs were a joke. After over an hour experimenting with different drivers I did find the combination of four or five that actually works, and put together my own startup script.
Backup. The "standard tools" are stone age. The very best Linux backup programs are comparable to the built-in backup program on Windows, assuming that you have CD-writing software that works (if that's your preferred medium) and don't mind adding cron jobs yourself.
OK, let's compare how Windows did in these areas.
The video card was recognized automatically and set up immediately. The driver has been updated at least once since then, without a hitch.
Within half an hour of when I went looking, I'd found a half-dozen temperature/fan monitor programs. Every one installed easily and worked just fine right away.
Backup. Even though the built-in backup program was really quite adequate, I went looking for something a little better wrt incremental-backup behavior. Half an hour later I'd evaluated several alternatives, downloaded and installed the one that looked best, and started my backup.
Pretty stark comparison, isn't it? Now, the point isn't to say that Windows is all that great. As an OS professional I can recognize some of the very serious design mistakes they made, and their business practices deserve plenty of condemnation. It's also not my point that Linux is bad technically, although I have to say it's nowhere near as cutting-edge as its proponents would have you believe. The point is that one OS lets me add capabilities quickly and painlessly, while the other forces me to waste hours on broken builds, broken installs, and general dicking around with stuff that in my own professional life I'd barely even dignify by calling it a prototype.
As a result of all this, I don't consider Linux suitable as a user environment. When I'm doing development I prefer to do it on Linux...by logging into a Linux box remotely from my Windows desktop. It's not because I'm stupid, or lazy; as I said, I love to hack. It's because when I sit down at a computer I have a task in mind other than babysitting my OS. Maybe some people enjoy doing that for its own sake, but I went through that phase a long time ago and I have very little patience for it now. Windows simply wastes less of my time.
their are dozens of manafactures of Access points and customer premise equipment that looks exactly like that
(1) You meant "there". (2) Looks aren't everything.
The Musenki system doesn't look at all comparable. As for TechsPlanet, you might want to check your math. The system you reference is designed for 500 users total. The $30K Canopy system includes 6 APs supporting 200 users each for a total of 1200. Also, the 30-mile radius you claim is very highly questionable even with a directional antenna; it's totally out of the question with the antennas specified in the document you linked to. Lastly, both Musenki and TechsPlanet make quite a point of the fact that their installations involve custom design and installation, instead of being out-of-the-box capable.
You might very well be right that this is not significantly superior to a properly designed 802.11b setup. That ceased to be the point a while ago, if it ever was. The fact of this technology's commoditization is still newsworthy even if similar capabilities were already available in custom form, and your habit of trying to make what might be a valid point with BS and misinformation is simply annoying.
So basically you're comparing business-grade 802.11b, further enhanced with extra antennas that aren't standard even for that class of equipment, with highly questionable outside-deployment characteristics, vs. Canopy out of the box. That hardly makes your point, and BTW "10-15" doesn't sound EXACTLY [sic] like "20" to me.
I'll try to help you answer your own question. What's the range on 802.11b? What's the range on Canopy? Answer those two questions and you should be able to figure out why Canopy might be interesting to people.
Each node might not know where the root of the tree is, but they do know who their parent is. If the RIAA said "tell us who your parent is or we'll assume you're the root", iteratively, they'd find the root PDQ. This contrasts with a network like Freenet, which is designed so that each node really doesn't know where content came from and therefore isn't of much help identifying its real origin. Mesh-structured networks in general also avoid the fragility inherent in tree-structured networks.
Streamer is not just reinventing the wheel; it's reinventing square wheels when round ones already exist.
I don't think you need to be quite so anal about it. Comments or variable names that are uninformative are bad, whether they're intended to be funny or not. Comments or variable names that are informative are good, and making a dreary chore out of anything discourages people from doing it. I'll take good comments with bad humor over no comments at all any day.
If the goal here is really to eliminate the "Slashdot Effect" a much more effective solution would be to set up a network of load-balanced caching proxies on geographically distributed fat pipes.
Who pays for all that equipment and bandwidth? The idea here is not to solve problems by throwing resources at a problem, but rather to solve them by using existing resources as effectively as possible. The technology involved can be applied to any resource base. The technology-intensive approach using almost-zero-cost resources might well make significant headway against the Slashdot Effect, even if you still think your capital-intensive approach based on older technology is even better.
Another factor you seem to've overlooked is that software like CAW or BitTorrent are distributed for reasons beyond scalability. For example, consider the inherent attack-resistance characteristics of a highly distributed P2P network, vs. your centrally-administered servers. There are other goals as well, such as avoiding legal culpability or financial dependence on corporate benefactors to provide the systems and bandwidth. Whether you agree or disagree with those goals, the fact remains that many people believe in them. Networks like you describe are old hat, dozens have been deployed already, and yet a lot of people still want something different. You've proposed a solution to a different problem than the one Onion Networks et al seek to solve. There's a term for that; we call it missing the point.
It's probably worth pointing out that the solution to this problem is really orthogonal to the use of content-based addressing. Also, while signatures etc. can be used to verify the integrity and provenance of the delivered data, there's a whole separate problem of ensuring that it's current or consistent.
Slashdot Mirror
This kind of thing's more common than a lot of people realize. A while back, I was in the OS group for on of the earlier SMP vendors. The chip we were using at the time was the Motorola 68040, and I discovered that there were serious differences between different chip revisions. For example, one revision would push a six-byte frame onto the stack for a particular floating-point exception, and another would push a ten-byte frame. Run code written for one revision on the other and you'd trash your stack. What we had to do was extract the chip revision at startup (somewhat of an interesting hack in itself, IIRC) and use it in our exception handlers to figure out where stuff was. Ick.
No comparison. The work for which he was awarded the Nobel prize was verifiably original. Nobody's found a paper containing those exact same ideas published twenty years earlier, at any rate, and yet that's pretty much exactly the case for Hex.
Thanks for playing. Now get back under your bridge.
Actually, Hex was first invented by Piet Hein, who is perhaps better known for the Soma cube. Nash claims to've invented the game independently, but somehow I just find that hard to believe.
I've often meditated about the guild parallel too. One aspect that particularly intrigues me is the idea of a guild house as a social/developmental/contact-making focus. Right now, people try to use their employer (or possibly their body shop) in that role, and it's a role in which those other-directed organizations are destined to fail.
In a slightly different vein, I wrote an article a while ago about yet another way to reason about developer capabilities and inclinations. It's mostly orthogonal to the guild approach, or perhaps even irreconcilable with it, but it might be interesting nonetheless.
I just noticed that Slashdot is treating the three parts of this one interview as three different stories, with three different sets of replies, etc. Yeah, that's really going to facilitate discussion, when half of the responses to question #1 appear in the first story and half in the third story from when people are done reading the whole set. Brilliant.
This guy gives "artificial intelligence" a whole new meaning, doesn't he?
There are several others - HighRoad, SANergy, QVFS, etc. Also, let's not forget that DEC pretty much beat us all to the punch with work they did on VAXclusters.
If you're not trying to be an asshole, what's with all the sarcasm? While it would be tempting to say that you can be an asshole without even trying, the more likely conclusion is that you really are trying and just want to leave yourself some wiggle room.
The problem is that caching occurs above the disk-driver level. Depending on the system, this might occur in the buffer cache, page cache, or within the filesystem itself, and that's just for data; there are usually things like inode/directory caches present as well. Writes directly through the driver or below - in this case directly to storage from another machine entirely - will result in those cached copies being stale without the filesystem knowing it.
If you still think drivers will save the day, it's easy enough to do an experiment and see how wrong you are. Write one program to access a file through the filesystem and all of the usual caches, while another figures out the actual on-disk location of that file's data and modifies it through the raw disk interface (bypassing everything above the disk driver). It shouldn't take you too long to see some stale data. For extra credit, try having the raw-disk program modify something other than a data block and see what happens.
As for your point about network filesystems, note that the ones you mention all funnel I/O through one machine. Usually, this means that the right cache interactions do occur on that machine, but I have actually seen implementations of NFS in particular where the server could not safely access the served volume for precisely these reasons. True shared-storage filesystems are very rare because it's such a pain, and I should know because I was co-architect for one of the few that ever made it to market. Believe me, I've wished that drivers solved these problems, but they simply don't.
The idea of using a distributed/replicated data store such as MojoNation or OceanStore for backup seems cool on the surface, and from a near-term customer-acceptance standpoint it definitely has advantages, but from a long-term technical standpoint one question does arise. If you have such a data store available to you, with appropriate performance and security characteristics, why would you store stuff locally (except for cached copies, which are evanescent rather than authoritative) at all? The ultimate goal of research in this area is not to facilitate backups but to make them unnecessary; what this project is doing is really a sort of "side trip" from that goal.
But how complex was the 8600? I can't find a specific number, but some sources say the later 9000 was still shy of a million gates. Researchers have already built async versions of MIPS and ARM cores more complex than that, and still seem leery of applying the same tools to anything on the order of a modern (superscalar, speculating, branch-predicting) CPU or 3D graphics chip.
Also, why is it that people who write about the history of asynchronous logic mention lots of other projects but not the 8600? Was it truly async, as the term would be understood today, or were there still synchronous aspects of the design? Perhaps you could elucidate by describing your equivalents of rendezvous or micro-pipeline structures.
You've hit the nail right on the head. Async circuits aren't harder to design; they're harder to verify and debug. Historically the tools just haven't been up to it and, despite some recent breakthroughs, I'm not sure they are now. Check out the work at CalTech, Manchester, and Theseus Logic for the current state of the art.
OK, asshole. How about we start with Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems presented at USENIX 2000? The first three authors should need no introduction, so I think it satisfies the "well known" requirement; in fact, one could hardly find a group of six people more qualified to comment on the matter. Even in the abstract, the authors clearly state the similarity between goals of journaling and soft updates:
The similarity is mentioned repeatedly elsewhere in the paper, all the way to the conclusion, but I'll let you do your homework this time.
Anybody who knows anything about filesytems - and I've been working on them for over a decade - recognizes the similarity in goals between journaling, soft updates, and phase trees. Usually it's considered too obvious even to require comment, unless an ignorant troll like you comes along demanding that the obvious be spelled out.
I already addressed that issue, but apparently you need things spelled out even more clearly. I have other things that I want to do, some of which even benefit the open-source community in other areas. It's not in anyone's best interest for me to take time away from other projects to make up for a basic lack of diligence by the people who write video or hardware-monitoring drivers. It's far more efficient if I concentrate on doing my stuff right and those people concentrate on doing their stuff right, if not for our mutual benefit then maybe because doing stuff right is good in and of itself.
This isn't about the sorts of bugs that "just happen" despite reasonable development and testing procedures. This is about bugs that happened because a developer didn't even try to do a decent job, and deliberately chose to dump an inferior half-done piece of junk on users. Even that might be OK, if the thing they released were clearly labeled as experimental unfinished code, but relatively few open-source developers are that honest. Most deliberately claim that their stuff is just as feature-complete and just as stable and just as usable as commercial equivalents, when examples like these show that's not the case. It's not the reality of rough-around-the edges geek-only software that bothers me; it's the marketing of it as something else.
That's exactly the admission that most open-source advocates are unwilling to make. Going back to your analogy, their behavior is like Columbus claiming that he'd found America before he even set sail. Too many people are declaring victory for Linux on the desktop when there are plenty of battles still to be fought, and that's the false claim I addressed with my earlier post.
Because I have plenty of other projects in the pipeline already, and can make more progress on those other projects by avoiding the platform where they occur than by fixing them. Were either not the case, things might be very different. As it is, I do try to help out here and there on open-source projects as time and talent allow, but I'm not about to abandon my own projects to become a near-full-time Linux bug-fixer.
Of course, lots of other people feel approximately the same way, and that's part of the problem. There's little incentive to do grunt work in open source, like there is in the commercial world where supply and demand can create lucrative opportunities for people willing to hold their noses. If it's no fun, and the pay's the same, why do it? Maybe what we need is some kind of barter system, so that people with complementary skills and problems can make arrangements so that each performs the (personally) least odious task and gets their (personally) most severe problem fixed. Sort of "you scratch my back, I'll scratch yours" instead of everyone doing contortions trying to scratch their own.
My reasons for not using Linux on the desktop are similar to this guy's, and I'd be willing to bet that very few of the people reading this are more technically able than I am so maybe it's another interesting data point. I was in the kernel group hacking the guys of a sophisticated SMP UNIX ten years ago and nowadays I write distributed filesystems for a living. I hack all day at work, then I go home and often hack some more. Conventional wisdom says I should love Linux, but it - and XFree86, which for all intents and purposes is part of the same package - has always been a big pain in the ass for me. Some examples:
OK, let's compare how Windows did in these areas.
Pretty stark comparison, isn't it? Now, the point isn't to say that Windows is all that great. As an OS professional I can recognize some of the very serious design mistakes they made, and their business practices deserve plenty of condemnation. It's also not my point that Linux is bad technically, although I have to say it's nowhere near as cutting-edge as its proponents would have you believe. The point is that one OS lets me add capabilities quickly and painlessly, while the other forces me to waste hours on broken builds, broken installs, and general dicking around with stuff that in my own professional life I'd barely even dignify by calling it a prototype.
As a result of all this, I don't consider Linux suitable as a user environment. When I'm doing development I prefer to do it on Linux...by logging into a Linux box remotely from my Windows desktop. It's not because I'm stupid, or lazy; as I said, I love to hack. It's because when I sit down at a computer I have a task in mind other than babysitting my OS. Maybe some people enjoy doing that for its own sake, but I went through that phase a long time ago and I have very little patience for it now. Windows simply wastes less of my time.
(1) You meant "there". (2) Looks aren't everything.
The Musenki system doesn't look at all comparable. As for TechsPlanet, you might want to check your math. The system you reference is designed for 500 users total. The $30K Canopy system includes 6 APs supporting 200 users each for a total of 1200. Also, the 30-mile radius you claim is very highly questionable even with a directional antenna; it's totally out of the question with the antennas specified in the document you linked to. Lastly, both Musenki and TechsPlanet make quite a point of the fact that their installations involve custom design and installation, instead of being out-of-the-box capable.
You might very well be right that this is not significantly superior to a properly designed 802.11b setup. That ceased to be the point a while ago, if it ever was. The fact of this technology's commoditization is still newsworthy even if similar capabilities were already available in custom form, and your habit of trying to make what might be a valid point with BS and misinformation is simply annoying.
BTW, "a lot" is two words. Get literate.
So basically you're comparing business-grade 802.11b, further enhanced with extra antennas that aren't standard even for that class of equipment, with highly questionable outside-deployment characteristics, vs. Canopy out of the box. That hardly makes your point, and BTW "10-15" doesn't sound EXACTLY [sic] like "20" to me.
I'll try to help you answer your own question. What's the range on 802.11b? What's the range on Canopy? Answer those two questions and you should be able to figure out why Canopy might be interesting to people.
Each node might not know where the root of the tree is, but they do know who their parent is. If the RIAA said "tell us who your parent is or we'll assume you're the root", iteratively, they'd find the root PDQ. This contrasts with a network like Freenet, which is designed so that each node really doesn't know where content came from and therefore isn't of much help identifying its real origin. Mesh-structured networks in general also avoid the fragility inherent in tree-structured networks.
Streamer is not just reinventing the wheel; it's reinventing square wheels when round ones already exist.
Swarmcast is cool, but it sounds like you're talking about BitTorrent.
I don't think you need to be quite so anal about it. Comments or variable names that are uninformative are bad, whether they're intended to be funny or not. Comments or variable names that are informative are good, and making a dreary chore out of anything discourages people from doing it. I'll take good comments with bad humor over no comments at all any day.
Who pays for all that equipment and bandwidth? The idea here is not to solve problems by throwing resources at a problem, but rather to solve them by using existing resources as effectively as possible. The technology involved can be applied to any resource base. The technology-intensive approach using almost-zero-cost resources might well make significant headway against the Slashdot Effect, even if you still think your capital-intensive approach based on older technology is even better.
Another factor you seem to've overlooked is that software like CAW or BitTorrent are distributed for reasons beyond scalability. For example, consider the inherent attack-resistance characteristics of a highly distributed P2P network, vs. your centrally-administered servers. There are other goals as well, such as avoiding legal culpability or financial dependence on corporate benefactors to provide the systems and bandwidth. Whether you agree or disagree with those goals, the fact remains that many people believe in them. Networks like you describe are old hat, dozens have been deployed already, and yet a lot of people still want something different. You've proposed a solution to a different problem than the one Onion Networks et al seek to solve. There's a term for that; we call it missing the point.
It's probably worth pointing out that the solution to this problem is really orthogonal to the use of content-based addressing. Also, while signatures etc. can be used to verify the integrity and provenance of the delivered data, there's a whole separate problem of ensuring that it's current or consistent.
Sniping software is part of the problem (of why web auctions suck), not part of the solution.