If I am reading you correctly, you become part of the swarm at the instant you make the connection. If you never ask for any blocks, you will be disconnected at timeout but all evidence will show you to be in the swarm until that time, so if any node you connect to has infinite timeout you would remain part of the swarm forever even if you have sent nothing and transmitted nothing, merely connected.
If I'm wrong on that, please say. If I'm right in that interpretation, there would surely need to be evidence of intent as academics particularly (but DDoSers, security auditors, and indeed copyright auditors) would need to connect this way and they would not be guilty by association.
Let's say you were in a conference call on VoIP, with your microphone and speaker turned off. You are still in the conference but you receive nothing and transmit nothing.
Or if you send the "join" command to join a multicast group, but never send or receive packets. All you do is join and remain active as a node (thus never pruned).
In the case of BitTorrent, it's a bit harder to argue, but there are still cases. An academic researcher who desires not what is being shared but a knowledge of how many people send vs receive and how numbers vary with time would need to have a probe connected to the swarm but if it transmitted OR received it would alter the system it was observing and that would violate the purpose of any such research. It would have to be a passive observer. This is not something Joe Average could argue, but I'd say that any sociologist "caught" in such a dragnet would be able to cast reasonable doubt.
I don't see why that could not be done. Sun released a large percentage of their T1/T2 processor designs as open-source, so it's not like high-end commercial operators have never gone that path. (Indeed, Sun seems to have been very supportive of that approach, as several other open-source cores - both a space-rated version of the SPARC and an asynchronous version were open-sourced, and IIRC Sun was involved in both.)
An open-sourced Alpha, PA-RISC and maybe even a StrongARM (IIRC ARM has abandoned that line to go with the more basic line) from the owners of the IP would surely be to the benefit of the industry and can't hurt the manufacturers (there's no sales of a product that isn't made). An open-sourced iWarp wouldn't hurt either. Don't recall who was working on "content-addressable memory", but again a product that has no value and no market cannot negatively impact anyone by being open-sourced but it might help engineers and scientists understand complexity problems better and it would certainly help enthusiasts generate soft cores.
(And if enthusiasts can build truly compatible soft cores, they can write/compile/debug software for them. Never hurts those markets that do exist - even in "obsolete" platforms - if there's software for them.)
Yes, the only way to do cumulative jamming would be to shadow the drone with a second drone. If the total flight is a few hundred miles and the average speed is low, you could imagine the error that could be introduced could be very substantial. You're absolutely right that this would take time, so this is the only realistic way you could get that time.
The use of a compass is essentially the same as the one I suggested - although a compass is a 2D magnetic sensor rather than a 3D. 3D has the benefit of giving you altitude, so letting you check every parameter. Yes it can be done. I looked into such sensors relatively recently (I was interested in whether I could make an electric guitar that used magnetic, rather than electric, fields and that could determine the direction the string was vibrating in - IMHO, a much more interesting problem than drones, but there ya go).
I agree that it is plausible to add sufficient redundancy, but my experience with drone technology is that the drone manufacturers LOVE to bolt things together with incredibly heavy modules. The modules I worked with were the CPU modules. PC104, running ****BLEAGH**** Windows CE. An OLD version at that. Actually, that might be the problem right there -- running Windows!
Given that ILS was first developed in the mid 1930s, there's really no reason why any small aircraft build after about 1970 should not have had it included as standard or why any earlier aircraft could not have it retrofitted at minimal expense.
The FAA has become a joke. Radar operators fall asleep on duty on a regular basis because of understaffing. The equipment is old and poorly maintained. It is a testament to the skill of pilots that there are as few crashes as there are, but it is only a matter of time before luck and pilot skill prove insufficient.
Ah, but -accessing- it is. That's why we have the Slashdot Effect. Once you access it, and thus help melt the server, reading is neither required nor advised.
1. Drones were unquestionably being flown over the area. 2. The US stated that the drone could not have crashed or shot down as photographs suggested it was highly intact, attempting to falsify the claim on that basis. 3. It would be possible to force the drone to land if it did not use INS but used unencrypted GPS
Note that I do not include the Iranians actually capturing a US military drone as a fact. It is not. It is a claim. It might have been a mock-up (as the US claimed) or it could have been a civilian drone of similar type run by one of the many militant and terrorist groups in the region - the US has been known to sell arms to Iranian groups in the past, so cannot be assumed to have not sold "civilian" drones in the present.
Nor do I include the US using encrypted GPS as a fact - it is not. It is also a claim, the US is very good at overstating such arguments. Groups such as SPAWAR do get exemption certificates for not complying with standards from time to time, so although such a standard may be in place, it requires one piece of paper in some dusty filing cabinet to render it ineffective.
In theory, the fewer clients you have, the better the design will be because you can use optimizations that won't apply in a more general case.
In practice, however, you are correct, often because when you get into those situations, those few clients are not terribly concerned with quality and there aren't any alternatives if they were.
In this case, and in all times in the past, sure. I'll buy that.
In the future? Not so sure. Not many key change algorithms are approved for military use, and any encryption algorithm that uses primes (eg: RSA) will become vulnerable in the foreseeable future. A war in 20-30 years time should be considered against an opponent that can break any algorithm of that type well within the 24 hours required. Since technology developed now will take a decade or so to develop and test, and needs the same in lifetime to be worth the costs, any technology developed today should assume any problem of similar complexity to be a solved problem for any enemy.
INS would be good, yes, but how to identify when a spoofed signal is just a little off what you expect, then increasingly different? Since INS has cumulative error, you can stay within the estimated error bounds and yet totally deceive the drone.
Answer: Radio direction finders. 1930s technology. If the signal is below you and at 300 yards, it's probably not a satellite above you and at 6000 miles. (Marconi, the company, developed the technique of using two RDFs offset from each other to triangulate and therefore give range as well as direction.)
Can you supplement INS using this same technique? Once GPS is marked as out-of-action, those RDFs can be used to triangulate on any radio source, after all. Not if all frequencies are jammed.
Ok, are there any other sensors that could be used? 3-way magnetic sensors (provided they're wired the right way up) could give you some information, provided there were no strong magnetic fields AND you had a magnetic map of the area. The first an enemy can arrange, the second is unlikely in unfriendly territory.
What about terrain-following radar? If you know what the terrain looks like, you can arguably use that with other dead-reckoning techniques to pinpoint your location. I'll give that a maybe, but remember that every added component subtracts from payload and subtracts from the value of using a drone vs a manned vehicle.
I'd consider it credible of -some- event (where said event could range from the consumption of mushrooms to an actual celestial event). Any supporting material (eg: petroglyphs by pre-writing peoples) would be extremely helpful, but ancient sites are not always well-recorded and are frequently poorly-preserved, making that kind of data hard to find.
A supernova? Maybe, but I still see nothing in the evidence to suggest that it was specifically that. I would imagine a GRB within a narrow range of distances could produce a similar result in Japan and England, although I'm open to any actual physicists telling me why that wouldn't work. Instead of a supernova, would a sufficiently close regular nova (much more common and much less visible to the naked eye) have a similar effect?
What about the tree-riing data? How many countries does it cover? How does the C14 data vary between geographic regions? (ie: is there a specific hotspot or track that can be inferred from available data?)
If you know how the C14 varies, you know what would have been visible in England and can rationally test the theory that this is an observation of a supernova.
Ending a headline in a question mark merely means they're writing in a language that is younger than Latin and has borrowed the shorthand notation developed by barbarians unwilling to write the questions out in full.
I agree that the damage to PA-RISC, Alpha and MIPS is unpardonable. Some of these architectures may want to be revisited and re-engineered with current knowledge. I am very much against homogeneous cultures in computing, a heterogeneous environment where the best suited gets to do the best job (where "best suited" factors in the latency of passing the data) will always give the best performance. A slight compromise on performance will give the best bang for the buck, but that sweet-point is almost never going to be the tedious uniformity we see at present. (Why do you think computers secretly rock out to Pink Floyd?:)
...was discussed on Slashdot many years ago. The original idea, IIRC, was that they'd shoot a UV beam to actually ionize the air between the shooter and the target - the lighting would then travel down this path as it would be the path of least resistance. I guess either the UV wasn't ionizing enough or they felt the lensing effect would be better.
If you factor in that Comcast is likely to impact more people than any individual, it might be closer to a tenth of a cent fine.
For something like this, I'd argue that fines should be proportional to impact per person per unit time. $800m would seem more reasonable, on that basis. The EU's fine on Microsoft was much closer to the figures corporations on that scale need to face before they'll pay much heed.
To be fair to Inmos, the Transputer was really only competing with big iron - no, I do not take the Transputer module for the Amiga seriously.
Even if it had simply evolved into a networking chip (rather than a DVD processor, which is what actually happened), the modern world spends a couple of grand on individual high-end SCI interconnects (which are essentially ptp serial links), which are distributed over an entire PCI card rather than being a system-on-a-chip. Being able to replace four such boards with one wafer would seem extremely desirable. It should certainly be faster, since all variables are the same bar the one of the Transputer being on a single die. The same goes for the iWarp.
If you want to compare apples with something that is still vaguely apple-shaped and within the category of fruit-like, then look at the sheer difficulty anyone has had superscaling the Intel processors. SGI managed it and went bust. Other than that, not many vendors have ever gone beyond sixteen-way. In comparison, Cambridge Computers were chucking thousands of Transputers into a single crate. IIRC, this was a Clive "people want washing-machine-motor cars" Sinclair operation we're talking about, which means it has to have been easy enough for him to comprehend. That's........not terribly demanding on the gray-cells. (He's in MENSA, but I can only imagine it's because they were using a Sinclair-made watch to time the test.)
Agreed, the actual T400 and T800 had architectural flaws and the iWarp had problems, but modern clusters are merely the same concept done over multiple motherboards with MPI-2.1's ghastly API to handle most of the data transfer. There's no intrinsic reason why a SoC version could not be the equal or superior, it merely requires a slightly larger die and a slightly better design.
Ok, what about the general case for virtual cores? Well, the reasoning is that applications place different demands on the CPU. Skype, Tor and Firefox are not equal in their needs, for example. People tend to run a mishmash of programs, it's actually quite rare to run many programs that happen to have identical needs. So rare even in games consoles that IBM opted for a hybrid architecture in their Cell design rather than try to make multiple cores that could do everything well.
In big iron, people tend to write SIMD code because you can't do MIMD on a heterogeneous cluster very well. With virtual cores, it would be the other way round - you'd be able to do MIMD far better than SIMD, since you could divide the processor elements up into more groups. So the question then becomes whether real-world problems are SIMD or MIMD. Since both still fall under the category of Turing-Complete, either can do the problems of both, so it's no use asking what people use. The question is what would be more efficient. Given that people DO use MPI and PVM, I'm less than convinced that people have looked into efficiency when scaling up will work.
Well, yeah. Anyone doing FPU-intensive work on a database (especially an Oracle one) is in the wrong line of business and probably needs considerable therapy. Certainly for database work, you WANT to have as much of the CPU dedicated to running large numbers of relatively basic threads - something the UltraSPARCs and successors do BRILLIANTLY. Hell, if you scaled a StrongARM to handle that many cores and threads, I'd take that over a number-crunching chip for database work.
Oracle RAC is the clustered version of their database (IIRC) but to take advantage of it you need a network card that'll do kernel bypass. By definition, that doesn't involve the CPU beyond the CPU allowing something else to control the bus. After that, it's ALL down to bus speeds and how many independent channels you can run.
I mean, the ones from Mars only need a recording of Tom Jones to defeat them, but you need three juvenile delinquents to defeat The Tripods. Everyone knows that.
Yes, which is the whole point. Zombies just aren't any good at fighting space aliens - it's just way too easy for the space aliens to get hold of a witch doctor or shaman and seize control.
They ARE bonobo chimps. The channels have been doing these wildlife crossovers for years! (After Pink and The Brain retired from starring in cartoons, they went on to scriptwrite for CSPAN. The Family Guy is actually directed by Flipper the dophin. Fox News is not named such by accident.)
Slashdot Mirror
That's why I prefer my discussions shaken, not stirred.
Given that we're talking about lawyers changing definitions to suit them, talking about shooting is probably inadvisable.
If I am reading you correctly, you become part of the swarm at the instant you make the connection. If you never ask for any blocks, you will be disconnected at timeout but all evidence will show you to be in the swarm until that time, so if any node you connect to has infinite timeout you would remain part of the swarm forever even if you have sent nothing and transmitted nothing, merely connected.
If I'm wrong on that, please say. If I'm right in that interpretation, there would surely need to be evidence of intent as academics particularly (but DDoSers, security auditors, and indeed copyright auditors) would need to connect this way and they would not be guilty by association.
Let's say you were in a conference call on VoIP, with your microphone and speaker turned off. You are still in the conference but you receive nothing and transmit nothing.
Or if you send the "join" command to join a multicast group, but never send or receive packets. All you do is join and remain active as a node (thus never pruned).
In the case of BitTorrent, it's a bit harder to argue, but there are still cases. An academic researcher who desires not what is being shared but a knowledge of how many people send vs receive and how numbers vary with time would need to have a probe connected to the swarm but if it transmitted OR received it would alter the system it was observing and that would violate the purpose of any such research. It would have to be a passive observer. This is not something Joe Average could argue, but I'd say that any sociologist "caught" in such a dragnet would be able to cast reasonable doubt.
I don't see why that could not be done. Sun released a large percentage of their T1/T2 processor designs as open-source, so it's not like high-end commercial operators have never gone that path. (Indeed, Sun seems to have been very supportive of that approach, as several other open-source cores - both a space-rated version of the SPARC and an asynchronous version were open-sourced, and IIRC Sun was involved in both.)
An open-sourced Alpha, PA-RISC and maybe even a StrongARM (IIRC ARM has abandoned that line to go with the more basic line) from the owners of the IP would surely be to the benefit of the industry and can't hurt the manufacturers (there's no sales of a product that isn't made). An open-sourced iWarp wouldn't hurt either. Don't recall who was working on "content-addressable memory", but again a product that has no value and no market cannot negatively impact anyone by being open-sourced but it might help engineers and scientists understand complexity problems better and it would certainly help enthusiasts generate soft cores.
(And if enthusiasts can build truly compatible soft cores, they can write/compile/debug software for them. Never hurts those markets that do exist - even in "obsolete" platforms - if there's software for them.)
Yes, the only way to do cumulative jamming would be to shadow the drone with a second drone. If the total flight is a few hundred miles and the average speed is low, you could imagine the error that could be introduced could be very substantial. You're absolutely right that this would take time, so this is the only realistic way you could get that time.
The use of a compass is essentially the same as the one I suggested - although a compass is a 2D magnetic sensor rather than a 3D. 3D has the benefit of giving you altitude, so letting you check every parameter. Yes it can be done. I looked into such sensors relatively recently (I was interested in whether I could make an electric guitar that used magnetic, rather than electric, fields and that could determine the direction the string was vibrating in - IMHO, a much more interesting problem than drones, but there ya go).
I agree that it is plausible to add sufficient redundancy, but my experience with drone technology is that the drone manufacturers LOVE to bolt things together with incredibly heavy modules. The modules I worked with were the CPU modules. PC104, running ****BLEAGH**** Windows CE. An OLD version at that. Actually, that might be the problem right there -- running Windows!
Given that ILS was first developed in the mid 1930s, there's really no reason why any small aircraft build after about 1970 should not have had it included as standard or why any earlier aircraft could not have it retrofitted at minimal expense.
The FAA has become a joke. Radar operators fall asleep on duty on a regular basis because of understaffing. The equipment is old and poorly maintained. It is a testament to the skill of pilots that there are as few crashes as there are, but it is only a matter of time before luck and pilot skill prove insufficient.
Nobody expects the Skynet Inquisition!
Ah, but -accessing- it is. That's why we have the Slashdot Effect. Once you access it, and thus help melt the server, reading is neither required nor advised.
An ounce of fact is worth many tonnes of theory.
The facts as we know them:
1. Drones were unquestionably being flown over the area.
2. The US stated that the drone could not have crashed or shot down as photographs suggested it was highly intact, attempting to falsify the claim on that basis.
3. It would be possible to force the drone to land if it did not use INS but used unencrypted GPS
Note that I do not include the Iranians actually capturing a US military drone as a fact. It is not. It is a claim. It might have been a mock-up (as the US claimed) or it could have been a civilian drone of similar type run by one of the many militant and terrorist groups in the region - the US has been known to sell arms to Iranian groups in the past, so cannot be assumed to have not sold "civilian" drones in the present.
Nor do I include the US using encrypted GPS as a fact - it is not. It is also a claim, the US is very good at overstating such arguments. Groups such as SPAWAR do get exemption certificates for not complying with standards from time to time, so although such a standard may be in place, it requires one piece of paper in some dusty filing cabinet to render it ineffective.
In theory, the fewer clients you have, the better the design will be because you can use optimizations that won't apply in a more general case.
In practice, however, you are correct, often because when you get into those situations, those few clients are not terribly concerned with quality and there aren't any alternatives if they were.
In this case, and in all times in the past, sure. I'll buy that.
In the future? Not so sure. Not many key change algorithms are approved for military use, and any encryption algorithm that uses primes (eg: RSA) will become vulnerable in the foreseeable future. A war in 20-30 years time should be considered against an opponent that can break any algorithm of that type well within the 24 hours required. Since technology developed now will take a decade or so to develop and test, and needs the same in lifetime to be worth the costs, any technology developed today should assume any problem of similar complexity to be a solved problem for any enemy.
INS would be good, yes, but how to identify when a spoofed signal is just a little off what you expect, then increasingly different? Since INS has cumulative error, you can stay within the estimated error bounds and yet totally deceive the drone.
Answer: Radio direction finders. 1930s technology. If the signal is below you and at 300 yards, it's probably not a satellite above you and at 6000 miles. (Marconi, the company, developed the technique of using two RDFs offset from each other to triangulate and therefore give range as well as direction.)
Can you supplement INS using this same technique? Once GPS is marked as out-of-action, those RDFs can be used to triangulate on any radio source, after all. Not if all frequencies are jammed.
Ok, are there any other sensors that could be used? 3-way magnetic sensors (provided they're wired the right way up) could give you some information, provided there were no strong magnetic fields AND you had a magnetic map of the area. The first an enemy can arrange, the second is unlikely in unfriendly territory.
What about terrain-following radar? If you know what the terrain looks like, you can arguably use that with other dead-reckoning techniques to pinpoint your location. I'll give that a maybe, but remember that every added component subtracts from payload and subtracts from the value of using a drone vs a manned vehicle.
I'd consider it credible of -some- event (where said event could range from the consumption of mushrooms to an actual celestial event). Any supporting material (eg: petroglyphs by pre-writing peoples) would be extremely helpful, but ancient sites are not always well-recorded and are frequently poorly-preserved, making that kind of data hard to find.
A supernova? Maybe, but I still see nothing in the evidence to suggest that it was specifically that. I would imagine a GRB within a narrow range of distances could produce a similar result in Japan and England, although I'm open to any actual physicists telling me why that wouldn't work. Instead of a supernova, would a sufficiently close regular nova (much more common and much less visible to the naked eye) have a similar effect?
What about the tree-riing data? How many countries does it cover? How does the C14 data vary between geographic regions? (ie: is there a specific hotspot or track that can be inferred from available data?)
If you know how the C14 varies, you know what would have been visible in England and can rationally test the theory that this is an observation of a supernova.
Ending a headline in a question mark merely means they're writing in a language that is younger than Latin and has borrowed the shorthand notation developed by barbarians unwilling to write the questions out in full.
I agree that the damage to PA-RISC, Alpha and MIPS is unpardonable. Some of these architectures may want to be revisited and re-engineered with current knowledge. I am very much against homogeneous cultures in computing, a heterogeneous environment where the best suited gets to do the best job (where "best suited" factors in the latency of passing the data) will always give the best performance. A slight compromise on performance will give the best bang for the buck, but that sweet-point is almost never going to be the tedious uniformity we see at present. (Why do you think computers secretly rock out to Pink Floyd? :)
"Damn you, Pinky! Can't you even look after your own name!"
"Zoinks! Sorry, Brain!"
...was discussed on Slashdot many years ago. The original idea, IIRC, was that they'd shoot a UV beam to actually ionize the air between the shooter and the target - the lighting would then travel down this path as it would be the path of least resistance. I guess either the UV wasn't ionizing enough or they felt the lensing effect would be better.
If you factor in that Comcast is likely to impact more people than any individual, it might be closer to a tenth of a cent fine.
For something like this, I'd argue that fines should be proportional to impact per person per unit time. $800m would seem more reasonable, on that basis. The EU's fine on Microsoft was much closer to the figures corporations on that scale need to face before they'll pay much heed.
To be fair to Inmos, the Transputer was really only competing with big iron - no, I do not take the Transputer module for the Amiga seriously.
Even if it had simply evolved into a networking chip (rather than a DVD processor, which is what actually happened), the modern world spends a couple of grand on individual high-end SCI interconnects (which are essentially ptp serial links), which are distributed over an entire PCI card rather than being a system-on-a-chip. Being able to replace four such boards with one wafer would seem extremely desirable. It should certainly be faster, since all variables are the same bar the one of the Transputer being on a single die. The same goes for the iWarp.
If you want to compare apples with something that is still vaguely apple-shaped and within the category of fruit-like, then look at the sheer difficulty anyone has had superscaling the Intel processors. SGI managed it and went bust. Other than that, not many vendors have ever gone beyond sixteen-way. In comparison, Cambridge Computers were chucking thousands of Transputers into a single crate. IIRC, this was a Clive "people want washing-machine-motor cars" Sinclair operation we're talking about, which means it has to have been easy enough for him to comprehend. That's.... ....not terribly demanding on the gray-cells. (He's in MENSA, but I can only imagine it's because they were using a Sinclair-made watch to time the test.)
Agreed, the actual T400 and T800 had architectural flaws and the iWarp had problems, but modern clusters are merely the same concept done over multiple motherboards with MPI-2.1's ghastly API to handle most of the data transfer. There's no intrinsic reason why a SoC version could not be the equal or superior, it merely requires a slightly larger die and a slightly better design.
Ok, what about the general case for virtual cores? Well, the reasoning is that applications place different demands on the CPU. Skype, Tor and Firefox are not equal in their needs, for example. People tend to run a mishmash of programs, it's actually quite rare to run many programs that happen to have identical needs. So rare even in games consoles that IBM opted for a hybrid architecture in their Cell design rather than try to make multiple cores that could do everything well.
In big iron, people tend to write SIMD code because you can't do MIMD on a heterogeneous cluster very well. With virtual cores, it would be the other way round - you'd be able to do MIMD far better than SIMD, since you could divide the processor elements up into more groups. So the question then becomes whether real-world problems are SIMD or MIMD. Since both still fall under the category of Turing-Complete, either can do the problems of both, so it's no use asking what people use. The question is what would be more efficient. Given that people DO use MPI and PVM, I'm less than convinced that people have looked into efficiency when scaling up will work.
Well, yeah. Anyone doing FPU-intensive work on a database (especially an Oracle one) is in the wrong line of business and probably needs considerable therapy. Certainly for database work, you WANT to have as much of the CPU dedicated to running large numbers of relatively basic threads - something the UltraSPARCs and successors do BRILLIANTLY. Hell, if you scaled a StrongARM to handle that many cores and threads, I'd take that over a number-crunching chip for database work.
Oracle RAC is the clustered version of their database (IIRC) but to take advantage of it you need a network card that'll do kernel bypass. By definition, that doesn't involve the CPU beyond the CPU allowing something else to control the bus. After that, it's ALL down to bus speeds and how many independent channels you can run.
I mean, the ones from Mars only need a recording of Tom Jones to defeat them, but you need three juvenile delinquents to defeat The Tripods. Everyone knows that.
Yes, which is the whole point. Zombies just aren't any good at fighting space aliens - it's just way too easy for the space aliens to get hold of a witch doctor or shaman and seize control.
78% believe in angels, 60% or so don't know which coast the Atlantic is on, and 56.8% think it's worth voting for a President, so no.
They ARE bonobo chimps. The channels have been doing these wildlife crossovers for years! (After Pink and The Brain retired from starring in cartoons, they went on to scriptwrite for CSPAN. The Family Guy is actually directed by Flipper the dophin. Fox News is not named such by accident.)