What you'd need is a directory filled with virtual files, where each virtual file's contents is generated by a driver that builds the ISO corresponding to that file and streams the output to the torrent. The length of the ISO would be fixed and padded as necessary, so that the torrent reported and used the correct values. The filename would be an encoding of what set of files you wanted to download and with what sort of options.
Anyone who downloaded the image could then torrent that image (with that set of options) or use some sort of script to re-virtualize it.
Either way, this would be a pain to torrent, but it could be done.
I used to do my own custom system, using SLS as the initial platform but replacing everything in it within the first few days. (Hey, it took a while to compile things, back then!:) Having pushed both RPM and ebuild well past their capacity, not having a package manager at all has definite appeal to me. I don't believe the existing systems are robust enough or adequately architectured. The first problem is that you get filename clashes. You can't install all of Fedora Core 6, for example - a multitude of packages try to write to the same filename. This is OK with Fedora, as it traps it, but with roll-your-owns, you run into problems unless EVERY package is in a unique namespace. Which is possible, but violates the LSB and makes the filepaths horrible.
The second problem is that dependencies are rarely obvious and almost never documented. The first time you find out what is really needed is when the compile fails. This isn't terrible, but it is painfully slow.
The third problem is that some packages have broken, brain-dead or merely horribly horribly bad build systems. Any system that takes longer than 24 hours for a professional software engineer just to configure the compile options - not actually compile, just set up the options necessary to get it to compile - should either be the best damn software this side of the Andromeda Galaxy or be subject to being ripped apart, bit by bit, slowly, with the Barney song on continuous loop in the background.
I've not been impressed with the dependency checking in Rawhide, so maybe that's no big loss.:) Seriously, I'll take a look for some of those scripts, or maybe roll up a few of my own. It shouldn't be hard to do well - either at source level or binary level - and although building an ISO image is nowhere near as fast as it should be, I think it should be easy enough to do better than alright.
...something along the lines of SLS or Slackware, where you have logical collections grouped together spread over as many disks as necessary. That way, you wouldn't need three different install spins - you could have just one - and all packages would be extensions. This has many advantages (fewer CDs for special-purpose uses, each collection can be updated independently, you can handle more permutations of install options, and so on) at the not unreasonable cost of having more CDs if you want absolutely everything.
However, I feel that there are enough packages where the number of permutations of compile-time options is large and where the number of dependencies between package types is unpredictable that the "ideal" would be to have a web interface that let you roll your own set of ISOs online with just the stuff you want with the options that you want. (This is more restrictive than, say, gentoo, but it would be about the same to QA as the current Fedora with less overhead for the admin than Fedora and less install time than gentoo.)
British social education of all kinds is primitive, pathetic, a good 300 years behind the times, and frankly stinks. American social education is taught by the Puritans the British kicked out 300 years ago for being primitive, pathetic, 300 years behind the times, and stinky.
None of this is necessary. The understanding of what makes for good education in both countries excels that of almost any other nation on Earth. The time spent in education in both nations is fantastic. Both have a thorough understanding of the dire consequences of failing - first-hand and in recent times. Both have sufficient surplus cash to invest in bringing the average skills and awareness of their citizens to levels far above the current top 1%, and could do so very easily.
As far as the video is concerned, the entire mess is caused BY a lack of education. If the Americans (and British) had better social education, then you'd get fewer paparazzi and fewer abuses of privacy. There simply wouldn't be the demand for scandal. The demand only exists because there are enough people too brain-dead to realize they only want the scandal because they've been told to. If the Brazilians had better education, they'd take better care of their privacy, wouldn't resort to stupid and pointless measures, and wouldn't go around obnoxiously pretending to do something useful when all they're really doing is creating far more interest than would otherwise have existed.
Politicians spend so much money on bribes and control - can't they afford just a little on acquiring a little knowledge? (Yeah, yeah, I know, they're acquiring as little as they can.)
But never underestimate the power of insanity.:) Yes, it takes X amount of time to move data from A to B. If you move that data twice over the same path at the same time, then the total is 2X, right? Well, not if you multicast. You can transmit to a million end-points the same data and take up exactly the same space on the wire. This means that you reduce the volume of what you move and the amount you have to interleave. Which is cool, because the backbones all have multicast enabled as standard. (Pity about the ISPs, but we can deal with such evil banditry later.)
Ok, so if we reduce the volume/mass of what we are moving, we can move it faster and with fewer hiccups. Are there any other things we can do? Oh, sure! Distance is a HUGE problem, but why move the data the full distance? Europe is smothered in web caches and America could be if it pulled its collective finger out and STFU'ed those who complain caching is a copyright violation. If you cached common bulk traffic transparently (so no having to figure out which cache is where - everything Just Works, novel a concept as that is) - most of that will be FTP and HTTP, but I'd cache Gopher as well just to sicken the old-timers like myself who still remember fast network service.
So, we've cut bulk, we've cut distance. What else can be saved? Well, the data paths are sickeningly contorted and designed to provide as close to a pared-down tree as possible. That means that data has to travel MUCH greater distances than mere geography suggests. Easy fix - light up a few more dark fibers and turn the US and Europe into super-sized meshes. Slash the logical distances, reduce the strain on the existing low-bandwidth lines and provide vastly superior coverage areas. All in one.
Next up, protocol. The laws of physics limit how fast a router can process a header and search through volumes of entries in a lookup table. Even a fast n-ary search takes time to go through a few million entries. Switch to IPv6 and both header complexity and router table complexity are eliminated. Utterly. It also gives you proper mobility without having to bounce everything through a home station.
These don't mean you can travel faster than light. What they do mean is that you can travel more effectively and with reduced baggage.
I favour ISO/IEC 13568:2002, although that would come as a shock to my former lecturers.:)
You made one major error in your interpretation of what I outlined, in assuming it was unit testing. It is integrated testing that uses some unit testing methodology. In order to test correctly, you must test EVERYTHING below the point in the code structure you are interested in. The structure is a fundamental part of the code and must be tested in conjunction with that code. No exceptions and no shortcuts. And, yes, it would have caught that error you outlined. Let me illustrate how:
You have the function itself, which would be roughly drawn up as:
Function preconditions, including that semaphore is unlocked
Lock semaphore
Lock semaphore postcondition (ie: semaphore is locked)
Do a task
Check semaphore is still locked (that is the invariant in this code block)
Unlock semaphore
Unlock semaphore postcondition (ie: semaphore is unlocked)
Buggy call goes here
If our formal spec requires the buggy call finish with the semaphore still locked, this gets tested here
Postconditions for the function, including that the semaphore is unlocked
Now, remember that each call still validates its pre- and post-conditions in the methodology I described, along with all invariants. You don't exhaustively exercise them, but the checks are still there. Now, let's get into the buggy function call...
Buggy call's preconditions (which, if a lock is called for, damn well should include checking the lock - NO skipping steps and NO shortcuts are acceptable when doing rigorous testing)
Buggy call's code
Buggy call's postcondition (which, since the semaphore is left locked, MUST include the fact that the lock is there)
Ok. We run the code. It gets to the buggy function call and hits the precondition. It fails and barfs on the lock test. We comment out the call to the function but leave the invariant check in place. (Since the function call shouldn't alter anything that's invariant - duh! - then the check must be valid whether the call is made or not.) The check fails, because the lock component of the invariant isn't true.
The invariant is incorrect, so that rules out the call itself being incorrect (which would make the precondition fail but the invariant succeed). However, it does say that the function call is being run under the wrong conditions. We therefore establish the nature of the bug and the scope of the bug. From there, you can inspect the postconditions at the end of each scoping block to see where the conditions no longer satisfy the invariant. Ah! When we perform the unlock, we violate the conditions! Ergo, the call must be moved to before this point.
You move that section of code back, the invariant is satisfied. Good. You uncomment the call. The precondition and postcondition are now also satisfied. Our code block structure is now correct.
Some Software Engineers and Computer Scientists take shortcuts - testing individual procedures in complete isolation. This is invalid. I don't care if you use Jackson Structured Diagrams, Abstract State Machines, Z Formal Notation, Backus-Normal Form, or the back of an envelope. If you don't include the structure, the whole structure, and nothing but the structure, then all you have is meaningless scribble. Syntax alone says nothing without the semantics. Testing one and not the other is an exercise in futility.
I completely agree with what you say, with one caveat. There are some excellent special-purpose languages that are not "programmer-proof" in the least within that special-purpose but which should never be used outside of the field for which they are intended. Because they are not general-purpose languages, they can trap conditions that are just plain stupid for that purpose, preferably by crashing rather than to out-program the programmer. "Smart" languages generally aren't.
(LOGO is great for controlling plotters or other simple X/Y-based robots - but I wouldn't write a wordprocessor in it.)
Heh! No, it's not brave of me at all. It's just called Formal Methods and it's only an "elite" group because people prefer to have crappy results now over superior results later. (Actually, it's not that "elite". I'd say that virtually all European universities teach Formal Methods.)
The point of Formal Methods is that there is no such thing as a case you haven't thought of. Formal Methods define the complete set of valid cases and (by definition) also the complete set of invalid cases. You explicitly define every boundary and can therefore test every boundary condition, but if you have followed the methodology correctly, there should be nothing much to test for.
First, you draw up a specification. You define the preconditions of each and every function - those things that absolutely MUST be true on entry to that function. You define the postconditions of each and every function - those things that absolutely MUST be true when you apply the intended operations to the preconditions. You define the invariants which MUST hold true after external functions have been called or data has been loaded. You do not care at this point how the program is implemented, you are only concerned with what must hold true at any time that there is the potential for such a requirement to be invalid.
Specifications should always be derived from the top down and should NEVER be skimped on. If the spec calls for a string of six characters and a null terminator to be placed in a dynamic buffer of seven bytes, you make damn sure that ONLY six characters are added AND that there is a null at the end AND that the malloc() function records that the structure is exactly seven bytes long.
Second, and this has become fashionable with "Extreme Programming", you develop a test harness for each function, starting from the bottom and working up. Test harnesses should attempt to violate each of the conditions given, as well as test for every boundary condition identified and some valid cases.
Third, you program to the combination of specification and test harness, again from the bottom up. It is a good idea to use assert() statements to ensure that the specification is totally adhered to. If a module meets all the specification requirements AND passes all the defined tests, then it is essentially free of defects for valid inputs.
You build up a trust hierarchy which matches the program hierarchy. If X is called by Y and X is OK if passed valid data and Y will always generate valid data, then there is no circumstance in which X can ever be invalid, even if theoretical defects exists. You don't have to prove the non-existence of defects that cannot be exposed, although the above mechanism will have eliminated most such issues. You don't have to test every permutation of conditions - once X is verified as correct, you only have to prove Y is valid. You do not need to prove the pair of Y and X, other than to ensure invariants are adhered to on return from X. This means that the test requirements are superlinear, not exponential. Exponential complexities are not good. Superlinear isn't great, but it is well within the limits of what can be achieved.
Once you have reached the point of showing that each module in the hierarchy is valid if the one(s) above are correct, up to the main program entry point, then provided you validate the parameters on startup, the program is as close to free of defects as has any meaning.
None of this requires arcane wizardry (Ai! Ai! Cthulhu!). It only requires that you know what you are doing before you try to do anything, and to understand what the implications are.
ATM is widely used in DSL and has found uses in metropolitan-area networks such as GMING. The main drawback of ATM is that it is point-to-point. It has no support for many-to-many. The payloads are also extremely small, which is great for streaming (which is where ATM excels above all other network types) and for rapid error recovery, but does place limitations on the bandwidth available - and bandwidth is just as important as latency.
Well, talking to some InfiniBand engineers, the next big push will be in wide-area networks running over InfiniBand, not ethernet. They think they've cracked the issues involved in wide-area communications and I would not be surprised if they have. If so, I would expect LAN parties in the later half of the year to be InfiniBand based, or using some other high-speed fabric. (If IB is going that way, you seriously imagine the others will want to be put out of business? No. We can expect a lot of the really high-end fabrics to start generalizing.)
I expect chip manufacturers to stop wasting time building more cores, more threads, etc. That doesn't scale linearly and gets horribly convoluted after a while. It is getting back to the level of complexity that caused RISC to evolve. AMD are already looking into building many specialist cores and this is a sensible way to go about things in many ways. 2007 may well spell the end of the "microprocessor" in favor of building a large number of specialist cores, producing a distributed processing unit, not a central one. Along with this, I also expect "Processor In Memory" to be revived as a technique - stuff that is small enough to be added to the RAM directly may as well be done entirely within RAM. There have been attempts at using this to reduce network latency - have the network stack within the memory itself. No bus traffic, so none of the problems of offload engines. Based on Cray's paper in this field, I'm guessing that you can cut latencies by 90% by this method, for stacks small enough to cram into memory.
Provided development goes well and we can eliminate the infighting, political intrigue and backstabbing, an organization I am connected with should have a major piece of disruptive technology out this year. If it doesn't go well, then it might easily be another twenty years before anything is produced at all. Just remember, you didn't hear it here first.
I see what you are saying. I guess my point is that if you were to ask a mathematician if 1+1=2 and did not specify the natural numbers, the real numbers, or some other well-defined set, then the answer the mathematician gives will depend entirely on what set they are assuming you mean. Now, you are correct that mathematicians are realists and I have no dispute with the claim that mathematicians look at numbers as somehow metaphysical. (I swear one of my former maths lecturers looked like a druid.) My line of thought is that in any exact field, assumptions can be tricky buggers, particularly when psychologists are framing the questions and psychologists are very unlikely to have sufficient background in the hard sciences to understand when questions are bad purely because they don't have any clearly-defined meaning within that hard science.
(Insofar as you can prove a mathematical system complete, you cannot prove it correct. Insofar as you can prove it correct, you cannot prove it complete. It is therefore possible to do one or the other, but never both. So if asked if one is possible - answer yes - and then asked if the other is possible - answer yes - a person who does NOT comprehend mathematics would inevitably reach entirely the wrong conclusion.)
Well, yeah. It would be relatively simple to provide a fiber-to-the-home network that was based on a hierarchical arrangement of meshes. We do this with roads, we do this with electricity, we mostly do this with water (although some areas use wells). There are cable-laying robots that run lines through pre-existing pipes (of which there are plenty) and if you're really cheap, you can run waterproofed cables alongside the railway lines.
I've posted before that we need fairly uniform coverage, not just metropolitan networks. Why? Civilizations have always built at the convergence of networks. Road networks, river networks, rail networks, whatever. People seem to have this idea that people build a city and add roads. No. People build roads and the cities condense around them. If you build information networks that only supply the cities that already exist, you merely accelerate what already exists and information - which is geographically-independent - gets trapped in archaic constructs that serve no useful purpose in an information age.
No, the bridge in Alaska would have done nothing useful. That wasn't going to intersect with anything and served no practical porpoise. I'm talking about something about as far removed from such white elephants as the Silk Road is removed from Hampton Court Maze.
Yes, I want gigabit to each house - ESPECIALLY rural houses. The more rural, the better the connection should be, as they're the ones who currently have the least access to information and would benefit the most from any incremental improvement.
Isn't that expensive? Possibly. But accountants are the ones who know the price of everything and the value of nothing. The benefit to industry and commerce, the reduction in wastage, the improvement in communication and the expansion of possibility would each individually pay for the whole project in short order. Together, the potential economic impact would make the cost of the project so utterly insignificant as to barely register. And, going back to my point at the start, a sizeable portion of what's needed would be insignificant. Jam a huge cable spool on the back of an Amtrak or a goods train and half the work is done for you. Walk along later, splice in some switches and power lines, and you've got yourself a network of whatever speed you feel like having. After that, you run lines through storm drains or some other largely useless pipe, and you'll be in spitting distance of anyone likely to be interested.
...the number of programmers like ourselves who learned how to code correctly is vanishingly small in comparison to the number of coders who assume that if it doesn't crash, it's good enough. Whether you validate the inputs against the constraints, engineer the program such that constraints must always be met, or force a module to crash when something is invalid so that you can trap and handle it by controlled means - the method is irrelevant. What matters is less that you're using a method than you remember to use a method.
Even assuming nobody wants to go to all that trouble, there are solutions. ElectricFence and dmalloc are hardly new and far from obscure. If a developer can't be bothered to link against a debugging malloc before testing then you can't expect their software to be immune to such absurd defects. A few runs whilst using memprof isn't a bad idea, either.
This assumes you're using a language like C, which is not a trivial language to write correct software in. For many programs, you are better off with a language like Occam (provided for Unix/Linux/Windows via KROC) where the combination of language and compiler heavily limits the errors you can introduce. Yes, languages this strict are a pain to write in, but the increase in the initial pain is vastly outweighed by the incredible reduction in agony when debugging - if there's any debugging at all.
I do not expect anyone to re-write glibc in Occam or any other nearly bug-proof language. It would be helpful, but it's not going to happen.
You assume that he thinks that the inadmissability in court is why it is not scientific, as opposed to it not being admissable because it is unscientific. It is important to consider which is the cause and which is the effect.
The reality is that polygraphs are just a mixture of suggestion and stress as measured by a change in dielectric properties. If you are not particularly suggestible, if your stress levels remain constant, or if your physiology is such that the variation in sweat level from stress is not significantly greater than the normal background noise levels, then polygraphs will detect nothing. On the other hand, if you are extremely suggestible, if your stress levels fluctuate wildly, or if you are prone to second-guessing yourself, the polygraph will show you as lying no matter what you say.
This leaves aside the small problem of this "truth" thing. Scientists tend to be skeptical as to there being "a truth". They have opinions, which they test (if they're any good), but yes/no answers don't hold up to such folk. It is impossible to frame a general question that can only ever have a "yes" or "no" answer. 1+1=2 only for number bases strictly greater than 2, on a number line or ring in which a 2 exists and where the + operator maps 1+1 onto 2. So any mathematician who says "yes" to "does 1+1=2?" is either not a very good mathematician OR will be shown as lying, as they'll know damn well that it doesn't for all cases. (You seriously imagine that these tests produce questions formalized well enough that quibbling is impossible? Odds are, most are unimaginably wooly - "are you a Democrat?" could mean almost anything, depending on who is asking and who is being asked. "Do you know any foreign secret agents?" should always produce a "no", as if you know they are, they are no longer a secret to you.)
Ok, fairy nuff. In which case, I have to confess I'm out of ideas.
You don't need to know every complete path, so the number of possible permutations is something you can work around. Think of the tables used by the nudes for routing as one gigantic divided secret. It is possible to prove that for a divided secret, you need only know one part more than 1/3 of all the parts before the secret is weak enough to be considered compromised. The question, then, is purely one of how to gain access to these tables.
If you can guesstimate a range for the number of nodes, then only certain values for that range will produce a series of simultaneous equations which correspond 1:N with the terms in the simultaneous equations produced when attempting to cover the maximum number of routes possible in the system. Of those, one will be a minimum and the rest will be that minimum with terms that can only be reflections.
However, from all the replies I've received so far, I'm willing to accept that Tor is immune to attacks that rely on the Byzantine class of problems - that even if you actually have enough data, knowing that you do is an NP-complete problem. (To be totally secure, it must be possible to prove that even obtaining sufficient information is NP-complete, which may be the case here but that's a much much higher standard.)
This is a common complaint amongst Internet 2 users and is even to be heard from facilities on the European-wide gigabit network. And these are far from being as network-intensive as MMORGs would be if you had comparable screen resolution and frame rates.
So we're looking at 10 gigabits/second minimum, for the kind of really heavy-duty traffic we're talking about, for any reasonable number of servers on that network. There's plenty of dark fiber around and I believe that the record for 200+ mile distances over fiber is in the order of around 4 or 5 petabytes/second. The backbone isn't going to be a technological problem, then. It would be damn expensive to light up enough to cover even as small a region as the United States, but it isn't impossible.
But that's the backbone. How do you get that traffic into people's homes? We're barely at the point of getting people to pay for single gigabit connections, never mind ten gigabit ethernet drops. The NICs are not exactly cheap either. And it's not just any old PC that can sustain a data stream through the PCI bus at those kinds of rates. You're looking at a fairly expensive piece of machinery, and one that is to be used not just solely for games (gaming machines are always expensive) but solely for games on that network. The more you use it for anything else, the less return you get for your investment.
Do I think this is a hoax? Yes. Because it's impossible? No, it could be done. But either it won't be done well enough to be worth having a new network for it, OR it will be too expensive for gamers.
On the other hand, a high-performance VR network for the scientific community, an order or two in magnitude faster than anything currently out there, could be done tomorrow and you're damn right that DARPA, CERN and the other Really Big League users could afford to pay the connection charges. Compared to the cost of the LHA in Switzerland, a ten gig drop per office in these labs that went to a secure petabyte trans-atlantic backbone would look like chump change.
Lying about the time works to a degree, but you can only lie in a positive direction. Eventually, with enough tries, it may be possible to figure out that there is a value you NEVER go below. That is the maximum the real time can be. If it's too much below that, however, anything that is time-order dependent risks getting screwed up.
Now, this isn't to say you can't seriously screw with the network's perception of time. For example, you could channel bond multiple VPN connections into a single super-VPN connection, fragment the packet, and use load-balancing to have each fragment sent by a different path. You need something a little fancier on the receiving end, as the fragments may come in out of order, but it's very doable. The delay for that link then appears to be the time taken to deliver the slowest fragment plus the time for fragmenting and rebuilding. As the MTUs for each channel can be randomly varied with every fragment, it would be impossible to infer the speed of any link as it would be impossible to know how much data had been sent by it.
(Well, OK, not truly "impossible", but the number of permutations skyrockets, as you now have every possible permutation of paths from a node multiplied by every possible state that path can be in for that fragment multiplied by the factorial of the number of differently-sized fragments. My saturation attack only works if each line has a well-defined characteristic with limited random noise - it doesn't work if you create an essentially infinite number of virtual lines with a non-deterministic characteristic.)
In the end, mathematical attacks of any kind rely on being able to expose some finite number of invariants (however trivial they may be) which can be correlated to some finite number of nodes (whether or not it is the number of actual nodes), where you can then minimize the map to produce the most likely arrangement.
When there are no invariants, it is impossible to do any further analysis. You can't isolate individual members, you can't isolate groups, you can't compare any two objects, you can't use induction to build associations, you can't do anything.
Probing a theoretically ideal anonymous P2P network can be done if certain conditions are met. Step through the following and see what you think.
If you connect to each and every R in the set of R' (the total number of edge-connected nodes in the network) and cache-flood prior to making your standard test query, and repeat the process R'/3 times, then the mean value of M over all these tests will be the maximum possible radius of the topology. It doesn't matter what test query you use or where in the topology the query is located.
The minimum possible radius of the network is the square root of R'.
The total latency from the edge to any server can not be less than the strict sum of the latencies of all intermediate hops. We therefore have one inequality for each of our R'/3 queries from our R' starting points with two terms for each of the transitions (Mx to My) in the list of M we have for that query. (One term for the actual latency generated, one term for whatever delay is introduced to conceal the path.)
We do not (yet) know how this table matches up. What we do is we start with the smallest radius and work our way up. The maximum area occurs with a circle, so area = pi * r^2, round up to the nearest whole node. The entire matrix above will fit if and only if the radius we are estimating is equal to or greater to the actual radius.
The additional concealment latency cannot be too great or the network is useless, so the concealment latency for a path has to be significantly smaller than the total latency of that same path.
There will be exactly one minimal fit for these conditions and this will be the topology of the network.
...if a cow has three heads and seven legs, has a sponge for a brain and eats from its left ear, it will NOT enter the food chain. At least, not legally. So, if we clone a perfectly good cow and the clone (because we've mashed up the DNA) now has three heads, seven legs, a sponge brain and eats from its left ear, we should regard that animal as unfit for human consumption no matter how good the original was.
The FDA's ruling essentially states that if the original is OK, then all clones are automatically OK, even if they make Frankenstein's monster look like a pinup model. That simply is not acceptable. Because the risk of genetic defects is hundreds, if not thousands, of times greater than normal, then tests for the suitability of those animals should equally be hundreds, if not thousands, of times stricter to catch defects that are hazardous to human health. (We learned the dangers through the spread of prion-based diseases. With increased risk, you MUST have increased vigilance.)
I have no objection to genetically-verified clones entering the food chain, but sufficient tests to determine that the meat is safe would cost as much as the animal itself, and cloning is always going to be more expensive than locking male and female animals in a field together. In the end, the only way to make cloning a cost-effective method is to eliminate not only the validation of successful cloning but to also eliminate all safeguards currently in place in the industry.
In other words, it can be safe, it can be practical, it CAN'T be both. Not yet. Maybe someday, but not yet.
Perfectly true, which is why cloned cats have different fur coloration, different personalities, and are in every way but genetically, a wholly different animal. Such things prove that genetic cloning does not produce a clone in the sci-fi sense - and even in sci-fi they often question the reliability of cloning insofar as producing a facsimilie is concerned. I'm glad you brought that up, though, as there seems to be an assumption that clones are 3D photocopies of the original. They are not. Not even close.
I tried to steer a little clear of that part of the debate, as not being a facsimilie doesn't mean it's not "safe" as a food source, it merely means that genetics won't give you a true clone. My argument was not merely that the cloning is imperfect but that it is so imperfect that there is an excellent reason to believe that a very high risk exists as to food safety. It may well be that most of the appearance and personality differences can be worked out faster than this one, producing clones of cats and dogs that are truly identical to the original in all ways, shapes and forms, but where a cloned cow would still have an extremely high risk of being deadly to humans.
(In fact, this is not an unreasonable theory. We know a lot about how genes get expressed and the interplay between environment and genetic attributes. Fixing clones of pets to truly be identical to the original should be easy - time-consuming but easy. DNA damage is much harder, as we don't really understand repair mechanisms very well, the "junk" DNA doesn't transcribe readily to anything we know, which makes it hard to understand what "repairing" it really means, we can't do bugger all with the mitochondrial DNA and it's not easy to figure out what energy it can produce, making it hard to know if the cell to be used is correctly powered, overpowered or underpowered, and so on)
Cloning will be perfected. Eventually. It might even be improved on - if you're transplanting DNA, you can fix defects in it directly after extraction. This eliminates the need to use retroviruses to implant corrected chromosomes - a process that is highly risky and prone to causing cancer. You can also tweak the repair mechanisms and other characteristics to make best use of the power the mitochondria will generate, and even tweak the mitochondrial DNA to produce an idealized level of power. Not a clone? Technically it is, these don't change the fundamental nature of what the DNA will express, they merely change the rate of cewll aging and the energy the cell has available for carrying out its tasks. The life created would be identical, it would merely age better and live easier.
Ultimately, though, cloning for food is a stupid waste of time. You want to make lots of food, really really fast? It's easy. Get some stem cells from the animal (or plant) in question, then block the receptors to differentiate. The stem cells will undergo a massive growth spurt, no different from any malignant tumour. It'll continue growing as large as you like. You can split the mass up and each mass will grow independently. When you get bored, you pick a mass, isolate it, unblock the receptors and tell it what sort of cells you want it to be made of. Once it has differentiated, you zap it with radiation to kill the cells off. It will have no texture to speak of and probably taste ghastly, but that's no different from any other American food. But it will be genuine meat, which is more than can be said of MacDonald's or other fast-food chains.
First, if the computer is sensibly cooled (ie: not by convection currents) then heating will be minimal.
Second, if you use a high-precision clock-chip, the chip will be tens or hundreds of times more accurate than the system time, so the drift will be entirely absorbed through the loss of accuracy.
Third, a defender worried about such an attack would use an oven-controlled oscillator for the clock, which means the temperature is whatever you want it to be. You can deliberately vary it to produce errors, or compensate for external temperature changes. Either way, you can be quite invisible to this method.
Fourth, the TOR network should be using an external time source (eg: NTP) that is not included in the TOR tunnel - ie: it's out-of-band - which means that the computers can automagically correct drift. If the computers are REALLY good, they'd correct drift on a second-order or third-order basis, rather than as a constant, so that you adapt how you read the clock to the shift in drift.
The idea of using some sort of timing attack against such a network is interesting. There are probably better methods, though.
One idea that springs to mind is that such P2P systems use caches. If you could generate enough requests to flood the cache system, you can force any computer to query nearby computers, where the latency will be roughly equal to the number of hops along the critical path. It then becomes similar to the game of "Black Box", where you try to map particles by throwing rays in and seeing what happens. If you have a sufficiently large latency map from a sufficiently large number of entrance points, you should be able to derive the whole of the exposed topology of the P2P network and be able to identify which of those servers carry what data.
(Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)
...cloning currently isn't. The animal is NOT an exact copy, as they do NOT use both the nucleic DNA and mitochondrial DNA, the DNA is frequently so damaged in the transfer that only a tiny fraction of the "clones" are viable - of those that survive long enough to be born, the vast majority die within a matter of days. And even those that do survive suffer accelerated aging and other known conditions relating to genetic illnesses.
If cloning was anywhere near the point of producing a genetically stable animal, this might be a fair ruling. The fact is, cloning introduces measureable defects. Most of those defects will impact the animal's health, rather than the safety of the meat. Some, and there's currently no way to know how many, will produce meat that is hazardous to humans. If geneticists aren't even sure why such defects exist at all, then you cannot ask them to quantify how many would be hazardous. How on earth could they possibly know?
Cloning might well be safe, once more of the variables have been quantified and the techniques refined to the point of being reliable. Once we are at that point, if the science showed that the risks to human health were comparable to the risks from non-cloned animals, the FDA would have a case. As it stands, this is a political decision that has zero credibility and should be reversed. You shouldn't try to run before you can crawl. (Walk? Stand up? We're nowhere close to those points.) The fact that labelling is to not require any mention of cloning is proof of that. If the market cannot overcome the objections of consumers except by lying to them, then the market has no goddamn business selling the time of day, never mind products where safety is critical.
(Personally, I'd prefer looser rules on what can be sold, tied to clearer markings on what is being sold. By play-pretending rigorous standards that really don't exist, and denying the information required to obtain any quantification of that risk, the consumer relies entirely on absolute trust in the divine wisdom of the FDA theocracy. Yes, it is a theocracy - it is driven entirely by faith, not facts from the ground or accountability from those affected. The FDA's methods are dubious - they were recently questioned with regards performing illegal human experiments on Africans - and their underlying principle seems to be one of worshipping themselves as Gods. The entire department should be closed as a hazard to human health.)
Slashdot Mirror
Anyone who downloaded the image could then torrent that image (with that set of options) or use some sort of script to re-virtualize it.
Either way, this would be a pain to torrent, but it could be done.
The second problem is that dependencies are rarely obvious and almost never documented. The first time you find out what is really needed is when the compile fails. This isn't terrible, but it is painfully slow.
The third problem is that some packages have broken, brain-dead or merely horribly horribly bad build systems. Any system that takes longer than 24 hours for a professional software engineer just to configure the compile options - not actually compile, just set up the options necessary to get it to compile - should either be the best damn software this side of the Andromeda Galaxy or be subject to being ripped apart, bit by bit, slowly, with the Barney song on continuous loop in the background.
I've not been impressed with the dependency checking in Rawhide, so maybe that's no big loss. :) Seriously, I'll take a look for some of those scripts, or maybe roll up a few of my own. It shouldn't be hard to do well - either at source level or binary level - and although building an ISO image is nowhere near as fast as it should be, I think it should be easy enough to do better than alright.
However, I feel that there are enough packages where the number of permutations of compile-time options is large and where the number of dependencies between package types is unpredictable that the "ideal" would be to have a web interface that let you roll your own set of ISOs online with just the stuff you want with the options that you want. (This is more restrictive than, say, gentoo, but it would be about the same to QA as the current Fedora with less overhead for the admin than Fedora and less install time than gentoo.)
None of this is necessary. The understanding of what makes for good education in both countries excels that of almost any other nation on Earth. The time spent in education in both nations is fantastic. Both have a thorough understanding of the dire consequences of failing - first-hand and in recent times. Both have sufficient surplus cash to invest in bringing the average skills and awareness of their citizens to levels far above the current top 1%, and could do so very easily.
As far as the video is concerned, the entire mess is caused BY a lack of education. If the Americans (and British) had better social education, then you'd get fewer paparazzi and fewer abuses of privacy. There simply wouldn't be the demand for scandal. The demand only exists because there are enough people too brain-dead to realize they only want the scandal because they've been told to. If the Brazilians had better education, they'd take better care of their privacy, wouldn't resort to stupid and pointless measures, and wouldn't go around obnoxiously pretending to do something useful when all they're really doing is creating far more interest than would otherwise have existed.
Politicians spend so much money on bribes and control - can't they afford just a little on acquiring a little knowledge? (Yeah, yeah, I know, they're acquiring as little as they can.)
Ok, so if we reduce the volume/mass of what we are moving, we can move it faster and with fewer hiccups. Are there any other things we can do? Oh, sure! Distance is a HUGE problem, but why move the data the full distance? Europe is smothered in web caches and America could be if it pulled its collective finger out and STFU'ed those who complain caching is a copyright violation. If you cached common bulk traffic transparently (so no having to figure out which cache is where - everything Just Works, novel a concept as that is) - most of that will be FTP and HTTP, but I'd cache Gopher as well just to sicken the old-timers like myself who still remember fast network service.
So, we've cut bulk, we've cut distance. What else can be saved? Well, the data paths are sickeningly contorted and designed to provide as close to a pared-down tree as possible. That means that data has to travel MUCH greater distances than mere geography suggests. Easy fix - light up a few more dark fibers and turn the US and Europe into super-sized meshes. Slash the logical distances, reduce the strain on the existing low-bandwidth lines and provide vastly superior coverage areas. All in one.
Next up, protocol. The laws of physics limit how fast a router can process a header and search through volumes of entries in a lookup table. Even a fast n-ary search takes time to go through a few million entries. Switch to IPv6 and both header complexity and router table complexity are eliminated. Utterly. It also gives you proper mobility without having to bounce everything through a home station.
These don't mean you can travel faster than light. What they do mean is that you can travel more effectively and with reduced baggage.
You made one major error in your interpretation of what I outlined, in assuming it was unit testing. It is integrated testing that uses some unit testing methodology. In order to test correctly, you must test EVERYTHING below the point in the code structure you are interested in. The structure is a fundamental part of the code and must be tested in conjunction with that code. No exceptions and no shortcuts. And, yes, it would have caught that error you outlined. Let me illustrate how:
You have the function itself, which would be roughly drawn up as:
Now, remember that each call still validates its pre- and post-conditions in the methodology I described, along with all invariants. You don't exhaustively exercise them, but the checks are still there. Now, let's get into the buggy function call...
Ok. We run the code. It gets to the buggy function call and hits the precondition. It fails and barfs on the lock test. We comment out the call to the function but leave the invariant check in place. (Since the function call shouldn't alter anything that's invariant - duh! - then the check must be valid whether the call is made or not.) The check fails, because the lock component of the invariant isn't true.
The invariant is incorrect, so that rules out the call itself being incorrect (which would make the precondition fail but the invariant succeed). However, it does say that the function call is being run under the wrong conditions. We therefore establish the nature of the bug and the scope of the bug. From there, you can inspect the postconditions at the end of each scoping block to see where the conditions no longer satisfy the invariant. Ah! When we perform the unlock, we violate the conditions! Ergo, the call must be moved to before this point.
You move that section of code back, the invariant is satisfied. Good. You uncomment the call. The precondition and postcondition are now also satisfied. Our code block structure is now correct.
Some Software Engineers and Computer Scientists take shortcuts - testing individual procedures in complete isolation. This is invalid. I don't care if you use Jackson Structured Diagrams, Abstract State Machines, Z Formal Notation, Backus-Normal Form, or the back of an envelope. If you don't include the structure, the whole structure, and nothing but the structure, then all you have is meaningless scribble. Syntax alone says nothing without the semantics. Testing one and not the other is an exercise in futility.
(LOGO is great for controlling plotters or other simple X/Y-based robots - but I wouldn't write a wordprocessor in it.)
The point of Formal Methods is that there is no such thing as a case you haven't thought of. Formal Methods define the complete set of valid cases and (by definition) also the complete set of invalid cases. You explicitly define every boundary and can therefore test every boundary condition, but if you have followed the methodology correctly, there should be nothing much to test for.
First, you draw up a specification. You define the preconditions of each and every function - those things that absolutely MUST be true on entry to that function. You define the postconditions of each and every function - those things that absolutely MUST be true when you apply the intended operations to the preconditions. You define the invariants which MUST hold true after external functions have been called or data has been loaded. You do not care at this point how the program is implemented, you are only concerned with what must hold true at any time that there is the potential for such a requirement to be invalid.
Specifications should always be derived from the top down and should NEVER be skimped on. If the spec calls for a string of six characters and a null terminator to be placed in a dynamic buffer of seven bytes, you make damn sure that ONLY six characters are added AND that there is a null at the end AND that the malloc() function records that the structure is exactly seven bytes long.
Second, and this has become fashionable with "Extreme Programming", you develop a test harness for each function, starting from the bottom and working up. Test harnesses should attempt to violate each of the conditions given, as well as test for every boundary condition identified and some valid cases.
Third, you program to the combination of specification and test harness, again from the bottom up. It is a good idea to use assert() statements to ensure that the specification is totally adhered to. If a module meets all the specification requirements AND passes all the defined tests, then it is essentially free of defects for valid inputs.
You build up a trust hierarchy which matches the program hierarchy. If X is called by Y and X is OK if passed valid data and Y will always generate valid data, then there is no circumstance in which X can ever be invalid, even if theoretical defects exists. You don't have to prove the non-existence of defects that cannot be exposed, although the above mechanism will have eliminated most such issues. You don't have to test every permutation of conditions - once X is verified as correct, you only have to prove Y is valid. You do not need to prove the pair of Y and X, other than to ensure invariants are adhered to on return from X. This means that the test requirements are superlinear, not exponential. Exponential complexities are not good. Superlinear isn't great, but it is well within the limits of what can be achieved.
Once you have reached the point of showing that each module in the hierarchy is valid if the one(s) above are correct, up to the main program entry point, then provided you validate the parameters on startup, the program is as close to free of defects as has any meaning.
None of this requires arcane wizardry (Ai! Ai! Cthulhu!). It only requires that you know what you are doing before you try to do anything, and to understand what the implications are.
ATM is widely used in DSL and has found uses in metropolitan-area networks such as GMING. The main drawback of ATM is that it is point-to-point. It has no support for many-to-many. The payloads are also extremely small, which is great for streaming (which is where ATM excels above all other network types) and for rapid error recovery, but does place limitations on the bandwidth available - and bandwidth is just as important as latency.
I expect chip manufacturers to stop wasting time building more cores, more threads, etc. That doesn't scale linearly and gets horribly convoluted after a while. It is getting back to the level of complexity that caused RISC to evolve. AMD are already looking into building many specialist cores and this is a sensible way to go about things in many ways. 2007 may well spell the end of the "microprocessor" in favor of building a large number of specialist cores, producing a distributed processing unit, not a central one. Along with this, I also expect "Processor In Memory" to be revived as a technique - stuff that is small enough to be added to the RAM directly may as well be done entirely within RAM. There have been attempts at using this to reduce network latency - have the network stack within the memory itself. No bus traffic, so none of the problems of offload engines. Based on Cray's paper in this field, I'm guessing that you can cut latencies by 90% by this method, for stacks small enough to cram into memory.
Provided development goes well and we can eliminate the infighting, political intrigue and backstabbing, an organization I am connected with should have a major piece of disruptive technology out this year. If it doesn't go well, then it might easily be another twenty years before anything is produced at all. Just remember, you didn't hear it here first.
(Insofar as you can prove a mathematical system complete, you cannot prove it correct. Insofar as you can prove it correct, you cannot prove it complete. It is therefore possible to do one or the other, but never both. So if asked if one is possible - answer yes - and then asked if the other is possible - answer yes - a person who does NOT comprehend mathematics would inevitably reach entirely the wrong conclusion.)
I've posted before that we need fairly uniform coverage, not just metropolitan networks. Why? Civilizations have always built at the convergence of networks. Road networks, river networks, rail networks, whatever. People seem to have this idea that people build a city and add roads. No. People build roads and the cities condense around them. If you build information networks that only supply the cities that already exist, you merely accelerate what already exists and information - which is geographically-independent - gets trapped in archaic constructs that serve no useful purpose in an information age.
No, the bridge in Alaska would have done nothing useful. That wasn't going to intersect with anything and served no practical porpoise. I'm talking about something about as far removed from such white elephants as the Silk Road is removed from Hampton Court Maze.
Yes, I want gigabit to each house - ESPECIALLY rural houses. The more rural, the better the connection should be, as they're the ones who currently have the least access to information and would benefit the most from any incremental improvement.
Isn't that expensive? Possibly. But accountants are the ones who know the price of everything and the value of nothing. The benefit to industry and commerce, the reduction in wastage, the improvement in communication and the expansion of possibility would each individually pay for the whole project in short order. Together, the potential economic impact would make the cost of the project so utterly insignificant as to barely register. And, going back to my point at the start, a sizeable portion of what's needed would be insignificant. Jam a huge cable spool on the back of an Amtrak or a goods train and half the work is done for you. Walk along later, splice in some switches and power lines, and you've got yourself a network of whatever speed you feel like having. After that, you run lines through storm drains or some other largely useless pipe, and you'll be in spitting distance of anyone likely to be interested.
Even assuming nobody wants to go to all that trouble, there are solutions. ElectricFence and dmalloc are hardly new and far from obscure. If a developer can't be bothered to link against a debugging malloc before testing then you can't expect their software to be immune to such absurd defects. A few runs whilst using memprof isn't a bad idea, either.
This assumes you're using a language like C, which is not a trivial language to write correct software in. For many programs, you are better off with a language like Occam (provided for Unix/Linux/Windows via KROC) where the combination of language and compiler heavily limits the errors you can introduce. Yes, languages this strict are a pain to write in, but the increase in the initial pain is vastly outweighed by the incredible reduction in agony when debugging - if there's any debugging at all.
I do not expect anyone to re-write glibc in Occam or any other nearly bug-proof language. It would be helpful, but it's not going to happen.
w and Y are GUIs. Z is an ISO-ratified specification language - and a damn good one at that.
The reality is that polygraphs are just a mixture of suggestion and stress as measured by a change in dielectric properties. If you are not particularly suggestible, if your stress levels remain constant, or if your physiology is such that the variation in sweat level from stress is not significantly greater than the normal background noise levels, then polygraphs will detect nothing. On the other hand, if you are extremely suggestible, if your stress levels fluctuate wildly, or if you are prone to second-guessing yourself, the polygraph will show you as lying no matter what you say.
This leaves aside the small problem of this "truth" thing. Scientists tend to be skeptical as to there being "a truth". They have opinions, which they test (if they're any good), but yes/no answers don't hold up to such folk. It is impossible to frame a general question that can only ever have a "yes" or "no" answer. 1+1=2 only for number bases strictly greater than 2, on a number line or ring in which a 2 exists and where the + operator maps 1+1 onto 2. So any mathematician who says "yes" to "does 1+1=2?" is either not a very good mathematician OR will be shown as lying, as they'll know damn well that it doesn't for all cases. (You seriously imagine that these tests produce questions formalized well enough that quibbling is impossible? Odds are, most are unimaginably wooly - "are you a Democrat?" could mean almost anything, depending on who is asking and who is being asked. "Do you know any foreign secret agents?" should always produce a "no", as if you know they are, they are no longer a secret to you.)
You don't need to know every complete path, so the number of possible permutations is something you can work around. Think of the tables used by the nudes for routing as one gigantic divided secret. It is possible to prove that for a divided secret, you need only know one part more than 1/3 of all the parts before the secret is weak enough to be considered compromised. The question, then, is purely one of how to gain access to these tables.
If you can guesstimate a range for the number of nodes, then only certain values for that range will produce a series of simultaneous equations which correspond 1:N with the terms in the simultaneous equations produced when attempting to cover the maximum number of routes possible in the system. Of those, one will be a minimum and the rest will be that minimum with terms that can only be reflections.
However, from all the replies I've received so far, I'm willing to accept that Tor is immune to attacks that rely on the Byzantine class of problems - that even if you actually have enough data, knowing that you do is an NP-complete problem. (To be totally secure, it must be possible to prove that even obtaining sufficient information is NP-complete, which may be the case here but that's a much much higher standard.)
So we're looking at 10 gigabits/second minimum, for the kind of really heavy-duty traffic we're talking about, for any reasonable number of servers on that network. There's plenty of dark fiber around and I believe that the record for 200+ mile distances over fiber is in the order of around 4 or 5 petabytes/second. The backbone isn't going to be a technological problem, then. It would be damn expensive to light up enough to cover even as small a region as the United States, but it isn't impossible.
But that's the backbone. How do you get that traffic into people's homes? We're barely at the point of getting people to pay for single gigabit connections, never mind ten gigabit ethernet drops. The NICs are not exactly cheap either. And it's not just any old PC that can sustain a data stream through the PCI bus at those kinds of rates. You're looking at a fairly expensive piece of machinery, and one that is to be used not just solely for games (gaming machines are always expensive) but solely for games on that network. The more you use it for anything else, the less return you get for your investment.
Do I think this is a hoax? Yes. Because it's impossible? No, it could be done. But either it won't be done well enough to be worth having a new network for it, OR it will be too expensive for gamers.
On the other hand, a high-performance VR network for the scientific community, an order or two in magnitude faster than anything currently out there, could be done tomorrow and you're damn right that DARPA, CERN and the other Really Big League users could afford to pay the connection charges. Compared to the cost of the LHA in Switzerland, a ten gig drop per office in these labs that went to a secure petabyte trans-atlantic backbone would look like chump change.
Now, this isn't to say you can't seriously screw with the network's perception of time. For example, you could channel bond multiple VPN connections into a single super-VPN connection, fragment the packet, and use load-balancing to have each fragment sent by a different path. You need something a little fancier on the receiving end, as the fragments may come in out of order, but it's very doable. The delay for that link then appears to be the time taken to deliver the slowest fragment plus the time for fragmenting and rebuilding. As the MTUs for each channel can be randomly varied with every fragment, it would be impossible to infer the speed of any link as it would be impossible to know how much data had been sent by it.
(Well, OK, not truly "impossible", but the number of permutations skyrockets, as you now have every possible permutation of paths from a node multiplied by every possible state that path can be in for that fragment multiplied by the factorial of the number of differently-sized fragments. My saturation attack only works if each line has a well-defined characteristic with limited random noise - it doesn't work if you create an essentially infinite number of virtual lines with a non-deterministic characteristic.)
In the end, mathematical attacks of any kind rely on being able to expose some finite number of invariants (however trivial they may be) which can be correlated to some finite number of nodes (whether or not it is the number of actual nodes), where you can then minimize the map to produce the most likely arrangement.
When there are no invariants, it is impossible to do any further analysis. You can't isolate individual members, you can't isolate groups, you can't compare any two objects, you can't use induction to build associations, you can't do anything.
...makes perfect sense. The respective locations are where the execs plan on getting drunk and laid when the complaints in the US reach critical mass.
The FDA's ruling essentially states that if the original is OK, then all clones are automatically OK, even if they make Frankenstein's monster look like a pinup model. That simply is not acceptable. Because the risk of genetic defects is hundreds, if not thousands, of times greater than normal, then tests for the suitability of those animals should equally be hundreds, if not thousands, of times stricter to catch defects that are hazardous to human health. (We learned the dangers through the spread of prion-based diseases. With increased risk, you MUST have increased vigilance.)
I have no objection to genetically-verified clones entering the food chain, but sufficient tests to determine that the meat is safe would cost as much as the animal itself, and cloning is always going to be more expensive than locking male and female animals in a field together. In the end, the only way to make cloning a cost-effective method is to eliminate not only the validation of successful cloning but to also eliminate all safeguards currently in place in the industry.
In other words, it can be safe, it can be practical, it CAN'T be both. Not yet. Maybe someday, but not yet.
I tried to steer a little clear of that part of the debate, as not being a facsimilie doesn't mean it's not "safe" as a food source, it merely means that genetics won't give you a true clone. My argument was not merely that the cloning is imperfect but that it is so imperfect that there is an excellent reason to believe that a very high risk exists as to food safety. It may well be that most of the appearance and personality differences can be worked out faster than this one, producing clones of cats and dogs that are truly identical to the original in all ways, shapes and forms, but where a cloned cow would still have an extremely high risk of being deadly to humans.
(In fact, this is not an unreasonable theory. We know a lot about how genes get expressed and the interplay between environment and genetic attributes. Fixing clones of pets to truly be identical to the original should be easy - time-consuming but easy. DNA damage is much harder, as we don't really understand repair mechanisms very well, the "junk" DNA doesn't transcribe readily to anything we know, which makes it hard to understand what "repairing" it really means, we can't do bugger all with the mitochondrial DNA and it's not easy to figure out what energy it can produce, making it hard to know if the cell to be used is correctly powered, overpowered or underpowered, and so on)
Cloning will be perfected. Eventually. It might even be improved on - if you're transplanting DNA, you can fix defects in it directly after extraction. This eliminates the need to use retroviruses to implant corrected chromosomes - a process that is highly risky and prone to causing cancer. You can also tweak the repair mechanisms and other characteristics to make best use of the power the mitochondria will generate, and even tweak the mitochondrial DNA to produce an idealized level of power. Not a clone? Technically it is, these don't change the fundamental nature of what the DNA will express, they merely change the rate of cewll aging and the energy the cell has available for carrying out its tasks. The life created would be identical, it would merely age better and live easier.
Ultimately, though, cloning for food is a stupid waste of time. You want to make lots of food, really really fast? It's easy. Get some stem cells from the animal (or plant) in question, then block the receptors to differentiate. The stem cells will undergo a massive growth spurt, no different from any malignant tumour. It'll continue growing as large as you like. You can split the mass up and each mass will grow independently. When you get bored, you pick a mass, isolate it, unblock the receptors and tell it what sort of cells you want it to be made of. Once it has differentiated, you zap it with radiation to kill the cells off. It will have no texture to speak of and probably taste ghastly, but that's no different from any other American food. But it will be genuine meat, which is more than can be said of MacDonald's or other fast-food chains.
The idea of using some sort of timing attack against such a network is interesting. There are probably better methods, though.
One idea that springs to mind is that such P2P systems use caches. If you could generate enough requests to flood the cache system, you can force any computer to query nearby computers, where the latency will be roughly equal to the number of hops along the critical path. It then becomes similar to the game of "Black Box", where you try to map particles by throwing rays in and seeing what happens. If you have a sufficiently large latency map from a sufficiently large number of entrance points, you should be able to derive the whole of the exposed topology of the P2P network and be able to identify which of those servers carry what data.
(Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)
If cloning was anywhere near the point of producing a genetically stable animal, this might be a fair ruling. The fact is, cloning introduces measureable defects. Most of those defects will impact the animal's health, rather than the safety of the meat. Some, and there's currently no way to know how many, will produce meat that is hazardous to humans. If geneticists aren't even sure why such defects exist at all, then you cannot ask them to quantify how many would be hazardous. How on earth could they possibly know?
Cloning might well be safe, once more of the variables have been quantified and the techniques refined to the point of being reliable. Once we are at that point, if the science showed that the risks to human health were comparable to the risks from non-cloned animals, the FDA would have a case. As it stands, this is a political decision that has zero credibility and should be reversed. You shouldn't try to run before you can crawl. (Walk? Stand up? We're nowhere close to those points.) The fact that labelling is to not require any mention of cloning is proof of that. If the market cannot overcome the objections of consumers except by lying to them, then the market has no goddamn business selling the time of day, never mind products where safety is critical.
(Personally, I'd prefer looser rules on what can be sold, tied to clearer markings on what is being sold. By play-pretending rigorous standards that really don't exist, and denying the information required to obtain any quantification of that risk, the consumer relies entirely on absolute trust in the divine wisdom of the FDA theocracy. Yes, it is a theocracy - it is driven entirely by faith, not facts from the ground or accountability from those affected. The FDA's methods are dubious - they were recently questioned with regards performing illegal human experiments on Africans - and their underlying principle seems to be one of worshipping themselves as Gods. The entire department should be closed as a hazard to human health.)