I worked on the Sprint ION project for over a year as a software engineer, and I got to know the system pretty well.
The reasons it ran into such massive monetary and technical problems are involved, and many I don't even know about. But I do know a little, and the ION project is still a fascinating system regardless.
(please forgive the acronyms and jargon, some of this may be a bit obscure if you are not familiar with ATM or switched networks)
Integrated On-demand Network
ION was one of the first projects to bring converged digital services to the consumer/small business. This meant digital phone service in addition to high speed broadband service.
Sprint decided to implement all of these services over an ATM network. ATM AAL2 rt-vbr (realtime variable bit rate) was great for carrying compressed voice traffic over switched digital networks. AAL5 was used for IP transport (ala classical IPoATM). And for management of the end point devices, the RISH's as they called them (Residential Integrated Services Hub) there was an ATM AAL2 cbr (constant bit rate) connection.
So, you had a DSL line rated at 8Mbps downstream and 1.5Mbps up. Over this DSL connection was an ATM layer, which in turn supported the three PVC's mentioned above for voice,data and signalling/mgmt.
At the time, the speed itself was a big plus. 8Mbps/1.5Mbps was way more than most DSL providers offered. In addition, you also got four phone lines that shared the voice pvc. Four phone lines and data over a single copper pair!
The voice channels were configured for VBR ATM traffic, which meant that you only used part of your 8/1.5Mbps bandwidth for voice traffic when you were actually making calls. For every call in progress you ate about 64kbps of bandwidth. As soon as the call was released, the bandwidth was again available for data communications.
The business oriented ION service allowed you to plug in as many voice lines as you wanted (up to about 32 max, simply plug in more voice cards) and could use T1 or HDSL connectivity depending on your configuration. And again, you only ate into the data bandwidth when calls were actually in progress.
Those are all the well known features, but there was also a lot of possibilities that Sprint had dreamed up for ION.
Since everything from Sprint's internal backbone out all the way to the customer's RISH was ATM, you could configure ATM SVC's with true Quality of Service. Were arent talking IP URGENT flags, this is true, real time quality of service. Things like video conferencing between ION customers was possible, with no jitter, no degraded voice quality. it was perfect. And only ION had the capability to provide such high quality of service features directly into the home (you need ATM for this level of QoS)
Video on demand was another popular topic. Internet video suffers from all kinds of congestion and low bandwidth. ION promised high speed DSL service with ATM QoS that would provide seemless, high quality video transmission.
In short, ION had a number of strong technical features in the architecture itself, which could provide a number of services which could never be supported over traditional internet broadband.
"On the bleeding edge, you simply bleed..."
That was a favorite quote made by a fellow developer. ION was ambitious. And everything about ION seemed to call for bleeding edge technogloy, from networking equipment to development tools, to provisioning and managment.
The network layer, HDSL, ATM AAL2/5 PVCs to the home was technically challenging. The switches required to take multiple OC3 connections from the DSLAM's that all the RISH's connected to had to support ATM AAL2 vbr, AAL5, and IP over ATM. These were incredibly expensive switches to handle the SVC soft switching and IP ATM routing/switching. Every regional location had to have one of these bad boys and at a price of roughly 2.5 million each, they racked up a steep cost very quickly.
ATM is also a switched networking protocol. For every customer, there were three PVC's which had to be manually provisioned into the various ATM switches and DSLAMs. On top of that, every voice connection (phone line) required an SVC to be setup, and connected to the desired location. Soft switching telephone networking was and is a relatively new system, and it was both expensive and difficult to maintain.
The software developed in house to support ION was also complex. Everything from order entry to configuration to network provisioning was supposed to be automated. This required a lot of diverse groups within Sprint to coordinate and interoperate using CORBA and other messaging / middle ware. Getting such a system operational and stable proved to be a very difficult and costly affair. The number of steps between an operator entering an ION customer order, to a network technician installing the device, to servers providing the RISH firmware and configuration data was high. There were a lot of points of failure, and getting this massive set of software systems to work was a major source of time and money drain.
"Timing is everything..."
In short, ION was a bit ahead of its time, and due to various delays, it didn't become available it its truly usefull form until it was already too late. The economic slowdown and broadband crunch started towards the end of 2000, and ION really didnt reach a viable point for widespread deployment until mid 2001. The timing was bad, and the ambitious and challenging nature of ION proved to be too costly in both time and money.
I am really sad to see it go. I put a lot of time and effory to write code that was supposed to be part of a new kind of communication infrastructure. I worked with a lot of really smart people there who also put a lot of effort into it, and most of them (actually, almost all of them) have been laid off as of last week.
ION itself had a lot of promise. High speed internet access and phone service was just the beginning of what it could provide.
For this to work, the bogus nodes would have to substantially outnumber user nodes, and the bogus data files (keys) would have to substantially outnumber the popular keys.
You are wrong. The very thing that makes freenet work so well in caching oft requested content where it is needed is the very thing that makes it easy to exploit the finite cache space of nodes.
This is a well known exploit in Freenet, but fortunately it has not been implemented and freenet itself has remained rather small.
Only if storage space allocated on the nodes is very small and easily overrun, resulting in frequent and sweeping cache purges, can this happen.
Freenet is unreliable storage. Data drops out of freenet all the time. And by default the cache size is 100M. The maximum cache file size (due to architecture contraints) is 2G. Very within the realm of exploitability.
The attacker also has no control over which data a particular node will throw away, except that he can be sure that it was less popular than what would remain.
Exactly, you could not force out specific data, but you could force out most or all legitimate data, leaving only crap in the caches of the nodes (which they mistakenly beleive is valid popular information)
Freenet has its own vulnerabilities. If you want to force content out of Freenet, simply have a number of rogue nodes cooperatively insert bogus data and request it from multiple locations.
This is a very quick and efficient way to force legitimate data out of the caches of various nodes.
700M only contains the genetic information required for the process of life to occur.
The execution of this genetic program is what you call life, and being human. To store the 'output' from this genetic program would be impossible.
There is infinite variety and always will be because the environment in which this 700M genetic program executes is always dynamic, and is a nonlinear dynamic system.
I dont want to get into the details here, but suffice it to say that there is a GIGANTIC difference between the genetic code, which is small, and the end result, which is life.
That the wonders of life can arise from such simple programs is a mystery to me as well... I am in no means trying to trivialive life or individuality.
See recent research on complex adaptive systems if you are curious...
OT: P2P resources
on
P2P Goes To War
·
· Score: 3, Informative
The emerging P2P scene is still pretty interesting. For the curious there are a few good resources out there for the latest info on peer networks in general:
The human genome project usually stored and manipulated data in a space inefficient text format. I.e. GATTAC...
You can compress this into binary with each base pair represented by 2 bits (00, 01, 10, 11) which reduces the amount of data by a factor of 4.
There are some additional diferences between a compact binary representation for a single genome, and the data used by the HGP, some of which is used for correlating sequences, etc.
In short, your DNA sequence would fit on a CD-R.
While it may be closer to 700M, it would still fit.
As a side note, if you removed the excess filler in the genome, you would end up with substantially less than 600-700M. perhaps in the neighborhood of 200-300M. But no one is sure if that filler is truely filler, or if it plays an indirect part in the gene expression within cells...
Good point. Connection Machines were probablt the first to employ massively parrallel processing. If I recall correctly, programming on connection machines was almost exclusively Lisp or one of its variants.
I wonder if the limits of the programming languages available had any impact on the decline of thinking machines and massively parrallel computing. Perhaps it was some other factor entirely (like synchronization, resource contention, etc)...
The 25X system reminded me of IBM's Blue Gene computer, where a large number of inexpensive CPU cores are placed on a single chip.
The biggest problem in dealing with a large number of small cores lies in the programming. I.e. how do you design and code a program that can utilize a thousand cores efficiently for some kind of operation? This goes beyond multi-threading into an entirely different kind of program organization and execution.
Do you see Forth (or future extensions to Forth) as a solution to this kind of problem? Does 25X dream of scaling to the magnitude that IBM envisions for Blue Gene? Do you think massively parrallel computing with inexpensive, expendable cores clustered on cheap die's will hit the desktop or power-user market, or forver be constrained to research...
The biggest question that remains in my mind in situations like this is how do they determine that you are sharing copyrighted works?
For something to stand up in court, you would need (i would hope) an IP, a date & time, and the actual content in question itself, that was obtained from your machine illegally.
It looks like the majority of these copyright monitoring services simply check file names and consider this sufficient.
What happens when you are using a client that supports any file type (gnutella/freenet/etc) and they find 'Metallica - A history of the band.html' and send your ISP a nastygram? This is obviously not a video or music file, however, unless they download it, how do they know?
Finally, I am concerned about people who use DHCP to configure their net access. Your IP changes every so often on cable/DSL. How accurate are their methods of finding the exact subscriber?
Perhaps the person who had your current IP before you was sharing files. Now you have that IP, and they accidentally terminate your access. Where are the checks and balances in this process?
The only solution in my mind right now is to switch to an ISP that isnt so trigger happy. Perhaps one that requires actual *proof* of any kind that such an infraction occured (like a copy of the file perhaps? even a description?) before terminated an account.
Does anyone know how various DSL/cable modem providers stack up in this regard?
Quantum computers are strange, in that they are good for mainly one kind of computation: Combinatorial optimization / state space search.
Normal computers would still be needed to work with quantum computers, and in fact, any kind of quantum computer would likely be a regular digital computer with a 'Quantum CoProcessor' to crunch on the difficult combinatorial optimization / state space search part of the problem.
Everything else would be done by the digital computer.
So, as a short answer to your question, think of Quantum Computers as a math coprocessor that you use in tandem with a digital computer to solve very complex problems that cannot be solved using conventional digital computers (or take prohibitively long to do so).
Here are a few things that quantum computers (when fully realized and sufficiently powerful) may bring with them in the future:
1. No more encryption. Quantum computers can crack block ciphers with ease, as well as assymetric public key cyphers. Bigger keys? Just use more qubits. Hmm... can anonymous networks (MixMaster, Freenet, Publius, etc...) exist without encryption? Can banking exist without encryption? How about online transactions in general?
2. Uber compression. Everything digital occurs in the Pi sequence somewhere right? Well, quantum computers might be able find that offset and length within Pi, LCG's, or any other kind of sequence.
Imagine downloading a 4 hour DIVX using 20 bytes. 4b sequence ID, 8b offset, 8b length. That is the same length as an IP header...
3. Massive optimization. Remember all those NP-complete problems you learned in comp. sci. ? No more simmulated annealing, genetic algorithm, guesstimation methods. Qubits can find the optimal solution instantly. No more intense calculations for hours/days to find meager 'near' optimal solutions. P.S. NP-complete type problems shows up in almost every complex system in every field / domain.
So what are the implications of this kind of computing becoming available in ten years? It's a wonder we dont hear more about this when reading about quantum computers. The effect they will have when available is almost more interesting than the implementation;)
Complexity and Software
on
Mob Software
·
· Score: 2
I was surprised and pleased to see references to Stuart Koffman in this essay.
The research being done at the Sante Fe Institute with regards to complex adaptive systems, and the nature of complexity in general provide a number of insights to coders writing large software projects (and many other discplines...)
I would highly reccomend At Home in the Universe as a good introduction to the ideas behind research in CAS. ISBN: 0195111303
For those who like more thorough and academic texts the S.I. produces a number of conference and workshop transcripts which are chock full of great papers and enlightening discussion. ISBN: 0201626063 is a good one.
As software/hardware systems grow ever more complex, we will need to apply ever more powerfull methods to manage this complexity. Perhaps by learning from the experiences of millions of years of evolutionary biological computation to socio/economic progression and interaction we can begin to fashion methods of building software/hardware that can adapt and scale in ways we dream of...
Re:Freenet - dodging the issue
on
Taming the Web
·
· Score: 3, Interesting
It makes things easier on the target machine. Filters themselves require a fair amount of bandwidth and CPU to process incoming packets.
If you are running web services on a limited bandwidth connection (T1/etc) a filter at your ISP (i.e. before your gateway router and you) prevents all the bogus traffic from reaching your machine and wasting bandwidth (and CPU).
Raw Sockets allow someone to send forged IP packets (spoofing) that appear to come from any IP address the sender chooses.
This makes filtering a DoS attack harder, because you can no longer filter the traffic by IP or domain.
So, right now the limited defense in the DDoS zombie attacks from Windoze is the fact that the IP packets have valid source addresses. These can be filtered at backbone or ISP provider routers.
If these attacks used spoofed IP packets, there would be no easy defense.
The two main points of this article are based on flawed assumptions.
1. Raw sockets in windoze is not the end of the world. *nix systems have them, even vxworks. A number of ISP's filter forged packets. If this type of spoofing is such a harm, it is trivial for ISPs to implement this. Cripling stack interfaces in OS'es is rediculous.
2. Passport will not authenticate every connection made on the net. Sorry, this is a pipe dream M$ sold you on somehow. And second, priority net traffic based on M$ passport is even more impossible.
In the case of M$'s Passport the worst that could happen is online identity theft, where your reputation is soiled, your bank account drained, and your accounts/data for the online services you use are destroyed or corrupted.
Not a trivial matter. Passport is intended to be THE identification and authorization checkpoint for every service in.NET
A breach of security at this critical juncture would have many severe repurcussions.
Google does not traffic specific identifying information. They only collect query information to drive their statistics.
This is completely different from M$ and.Net which basically OWNS your entire online identity, or Intel with UNIQUE identifying serial numbers on CPU's.
It is not the amount of data that we should be concerned about, but rather the type of data and its intended use.
Someone mod this up. Not a practical solution, but something worth thinking about.
This hits especially close to home now that I finished working a contract where the pimp agency was siphening off $54/hour of my wages. A fellow I worked with (H1B visa) was actually getting a paltry 45K/year salary, no overtime, while the pimp agency billed him to clients at $95/hour for 40-60 hours a week.
At any rate, never before have I felt this kind of exploitation so close to home, but now I see it many places I look in the business world.
Currently, it is rather difficult to post something anonymously to a newsgroup. Especially if your only newsgroup access is via your ISP.
So, by using anonymizer.com or something similar to log into google groups and then using google to post to a newsgroup, you have a much better chance of remaining anonymous.
Thing is, I don't see why anyone would use this. In reality, the transfer rates aren't as good as a single fast dedicated server
True. If you have an adequate dedicated server with plenty of bandwidth, it will be hard to top with swarmcast.
The benifit comes in terms of cost. Those beefy servers cost a shitload of money in terms of colocation and bandwidth.
A small, unfunded content shop may want to stream animations but cannot afford the cost of a central server to do it.
If they use swarmcast, however, the streaming is accomplished by utilizing bandwidth of everyone participating. No expensive server is needed, and performance is at least decent.
Real world uses for this technology are still lacking, so we shall see how swarmcast gets adopted IRL.
Second, don't the packets contain things like the MAC address of the ethernet card?
Yes, but this changes with every hop of the packet. The initial MAC ID is from your computer, and is the MAC ID of your NIC.
Once this packet hits the first router, it forwards the packet and it now contains the MAC ID of the router's NIC.
The only time tracking MAC IDs is usefull is if you are on a broadcast LAN, like ethernet w/ dumb hubs, and you can sniff traffic. Otherwise, its all the routers/switches MACs...
How could a physicist become a born-again Christian?
When they get old and start to fear death.
Go read about complex systems, self organization, auto catalytic sets, the genome projects underway and the relationship genetically between all living things.
Hope does not make it true. Faith does not change fact.
While I hope that Peekabooty becomes a useable tamper/monitor resistant network, I wish the cDc had focused on some of the more challenging problems facing peer based networks.
There are already a number of secure information sharing networks, like Freenet, Publius, Anonymizer, etc, etc...
The problem with these networks, and probably a majority of the net is locating the content you want in the first place.
They do not mention any details on the discovery mechanism Peekabooty uses, so perhaps they have covered this base as well, but I doubt it.
Napster, which is great for locating content, is quickly dying a painfull death. Gnutella and Freenet, which are more legally resistant are no where near as effective at locating content.
Gnutella is especially inefficient at this task, so I hope Peekabooty is not modeled after the Gnutella style discovery method.
At any rate, I wish a lot of the focus of peer based projects would shift from simply being Peer to Peer!!! into specific implementations of peer based functionality, like resource discovery, content transfer, etc.
"Could you please list the advantages C++ has over Java?"
How about the memory eating JVM for starters?
The point is, the Java people will consider many aspects of the language as 'benifits!'. While the C++ people will see these as misplaced, ill implemented 'drawbacks!'.
Slashdot Mirror
I worked on the Sprint ION project for over a year as a software engineer, and I got to know the system pretty well.
The reasons it ran into such massive monetary and technical problems are involved, and many I don't even know about. But I do know a little, and the ION project is still a fascinating system regardless.
(please forgive the acronyms and jargon, some of this may be a bit obscure if you are not familiar with ATM or switched networks)
Integrated On-demand Network
ION was one of the first projects to bring converged digital services to the consumer/small business. This meant digital phone service in addition to high speed broadband service.
Sprint decided to implement all of these services over an ATM network. ATM AAL2 rt-vbr (realtime variable bit rate) was great for carrying compressed voice traffic over switched digital networks. AAL5 was used for IP transport (ala classical IPoATM). And for management of the end point devices, the RISH's as they called them (Residential Integrated Services Hub) there was an ATM AAL2 cbr (constant bit rate) connection.
So, you had a DSL line rated at 8Mbps downstream and 1.5Mbps up. Over this DSL connection was an ATM layer, which in turn supported the three PVC's mentioned above for voice,data and signalling/mgmt.
At the time, the speed itself was a big plus. 8Mbps/1.5Mbps was way more than most DSL providers offered. In addition, you also got four phone lines that shared the voice pvc. Four phone lines and data over a single copper pair!
The voice channels were configured for VBR ATM traffic, which meant that you only used part of your 8/1.5Mbps bandwidth for voice traffic when you were actually making calls. For every call in progress you ate about 64kbps of bandwidth. As soon as the call was released, the bandwidth was again available for data communications.
The business oriented ION service allowed you to plug in as many voice lines as you wanted (up to about 32 max, simply plug in more voice cards) and could use T1 or HDSL connectivity depending on your configuration. And again, you only ate into the data bandwidth when calls were actually in progress.
Those are all the well known features, but there was also a lot of possibilities that Sprint had dreamed up for ION.
Since everything from Sprint's internal backbone out all the way to the customer's RISH was ATM, you could configure ATM SVC's with true Quality of Service. Were arent talking IP URGENT flags, this is true, real time quality of service. Things like video conferencing between ION customers was possible, with no jitter, no degraded voice quality. it was perfect. And only ION had the capability to provide such high quality of service features directly into the home (you need ATM for this level of QoS)
Video on demand was another popular topic. Internet video suffers from all kinds of congestion and low bandwidth. ION promised high speed DSL service with ATM QoS that would provide seemless, high quality video transmission.
In short, ION had a number of strong technical features in the architecture itself, which could provide a number of services which could never be supported over traditional internet broadband.
"On the bleeding edge, you simply bleed..."
That was a favorite quote made by a fellow developer. ION was ambitious. And everything about ION seemed to call for bleeding edge technogloy, from networking equipment to development tools, to provisioning and managment.
The network layer, HDSL, ATM AAL2/5 PVCs to the home was technically challenging. The switches required to take multiple OC3 connections from the DSLAM's that all the RISH's connected to had to support ATM AAL2 vbr, AAL5, and IP over ATM. These were incredibly expensive switches to handle the SVC soft switching and IP ATM routing/switching. Every regional location had to have one of these bad boys and at a price of roughly 2.5 million each, they racked up a steep cost very quickly.
ATM is also a switched networking protocol. For every customer, there were three PVC's which had to be manually provisioned into the various ATM switches and DSLAMs. On top of that, every voice connection (phone line) required an SVC to be setup, and connected to the desired location. Soft switching telephone networking was and is a relatively new system, and it was both expensive and difficult to maintain.
The software developed in house to support ION was also complex. Everything from order entry to configuration to network provisioning was supposed to be automated. This required a lot of diverse groups within Sprint to coordinate and interoperate using CORBA and other messaging / middle ware. Getting such a system operational and stable proved to be a very difficult and costly affair. The number of steps between an operator entering an ION customer order, to a network technician installing the device, to servers providing the RISH firmware and configuration data was high. There were a lot of points of failure, and getting this massive set of software systems to work was a major source of time and money drain.
"Timing is everything..."
In short, ION was a bit ahead of its time, and due to various delays, it didn't become available it its truly usefull form until it was already too late. The economic slowdown and broadband crunch started towards the end of 2000, and ION really didnt reach a viable point for widespread deployment until mid 2001. The timing was bad, and the ambitious and challenging nature of ION proved to be too costly in both time and money.
I am really sad to see it go. I put a lot of time and effory to write code that was supposed to be part of a new kind of communication infrastructure. I worked with a lot of really smart people there who also put a lot of effort into it, and most of them (actually, almost all of them) have been laid off as of last week.
ION itself had a lot of promise. High speed internet access and phone service was just the beginning of what it could provide.
For this to work, the bogus nodes would have to substantially outnumber user nodes, and the bogus data files (keys) would have to substantially outnumber the popular keys.
You are wrong. The very thing that makes freenet work so well in caching oft requested content where it is needed is the very thing that makes it easy to exploit the finite cache space of nodes.
This is a well known exploit in Freenet, but fortunately it has not been implemented and freenet itself has remained rather small.
Only if storage space allocated on the nodes is very small and easily overrun, resulting in frequent and sweeping cache purges, can this happen.
Freenet is unreliable storage. Data drops out of freenet all the time. And by default the cache size is 100M. The maximum cache file size (due to architecture contraints) is 2G. Very within the realm of exploitability.
The attacker also has no control over which data a particular node will throw away, except that he can be sure that it was less popular than what would remain.
Exactly, you could not force out specific data, but you could force out most or all legitimate data, leaving only crap in the caches of the nodes (which they mistakenly beleive is valid popular information)
Freenet has its own vulnerabilities. If you want to force content out of Freenet, simply have a number of rogue nodes cooperatively insert bogus data and request it from multiple locations.
This is a very quick and efficient way to force legitimate data out of the caches of various nodes.
You are barking up the wrong tree.
700M only contains the genetic information required for the process of life to occur.
The execution of this genetic program is what you call life, and being human. To store the 'output' from this genetic program would be impossible.
There is infinite variety and always will be because the environment in which this 700M genetic program executes is always dynamic, and is a nonlinear dynamic system.
I dont want to get into the details here, but suffice it to say that there is a GIGANTIC difference between the genetic code, which is small, and the end result, which is life.
That the wonders of life can arise from such simple programs is a mystery to me as well... I am in no means trying to trivialive life or individuality.
See recent research on complex adaptive systems if you are curious...
The emerging P2P scene is still pretty interesting. For the curious there are a few good resources out there for the latest info on peer networks in general:
www.infoanarchy.org
www.peertal.com
Decentralization mailing list
P2P-hackers mailing list
The human genome project usually stored and manipulated data in a space inefficient text format. I.e. GATTAC...
You can compress this into binary with each base pair represented by 2 bits (00, 01, 10, 11) which reduces the amount of data by a factor of 4.
There are some additional diferences between a compact binary representation for a single genome, and the data used by the HGP, some of which is used for correlating sequences, etc.
In short, your DNA sequence would fit on a CD-R.
While it may be closer to 700M, it would still fit.
As a side note, if you removed the excess filler in the genome, you would end up with substantially less than 600-700M. perhaps in the neighborhood of 200-300M. But no one is sure if that filler is truely filler, or if it plays an indirect part in the gene expression within cells...
Good point. Connection Machines were probablt the first to employ massively parrallel processing. If I recall correctly, programming on connection machines was almost exclusively Lisp or one of its variants.
I wonder if the limits of the programming languages available had any impact on the decline of thinking machines and massively parrallel computing. Perhaps it was some other factor entirely (like synchronization, resource contention, etc)...
The 25X system reminded me of IBM's Blue Gene computer, where a large number of inexpensive CPU cores are placed on a single chip.
The biggest problem in dealing with a large number of small cores lies in the programming. I.e. how do you design and code a program that can utilize a thousand cores efficiently for some kind of operation? This goes beyond multi-threading into an entirely different kind of program organization and execution.
Do you see Forth (or future extensions to Forth) as a solution to this kind of problem? Does 25X dream of scaling to the magnitude that IBM envisions for Blue Gene? Do you think massively parrallel computing with inexpensive, expendable cores clustered on cheap die's will hit the desktop or power-user market, or forver be constrained to research...
The biggest question that remains in my mind in situations like this is how do they determine that you are sharing copyrighted works?
For something to stand up in court, you would need (i would hope) an IP, a date & time, and the actual content in question itself, that was obtained from your machine illegally.
It looks like the majority of these copyright monitoring services simply check file names and consider this sufficient.
What happens when you are using a client that supports any file type (gnutella/freenet/etc) and they find 'Metallica - A history of the band.html' and send your ISP a nastygram? This is obviously not a video or music file, however, unless they download it, how do they know?
Finally, I am concerned about people who use DHCP to configure their net access. Your IP changes every so often on cable/DSL. How accurate are their methods of finding the exact subscriber?
Perhaps the person who had your current IP before you was sharing files. Now you have that IP, and they accidentally terminate your access. Where are the checks and balances in this process?
The only solution in my mind right now is to switch to an ISP that isnt so trigger happy. Perhaps one that requires actual *proof* of any kind that such an infraction occured (like a copy of the file perhaps? even a description?) before terminated an account.
Does anyone know how various DSL/cable modem providers stack up in this regard?
Quantum computers are strange, in that they are good for mainly one kind of computation: Combinatorial optimization / state space search.
Normal computers would still be needed to work with quantum computers, and in fact, any kind of quantum computer would likely be a regular digital computer with a 'Quantum CoProcessor' to crunch on the difficult combinatorial optimization / state space search part of the problem.
Everything else would be done by the digital computer.
So, as a short answer to your question, think of Quantum Computers as a math coprocessor that you use in tandem with a digital computer to solve very complex problems that cannot be solved using conventional digital computers (or take prohibitively long to do so).
Here are a few things that quantum computers (when fully realized and sufficiently powerful) may bring with them in the future:
;)
1. No more encryption. Quantum computers can crack block ciphers with ease, as well as assymetric public key cyphers. Bigger keys? Just use more qubits. Hmm... can anonymous networks (MixMaster, Freenet, Publius, etc...) exist without encryption? Can banking exist without encryption? How about online transactions in general?
2. Uber compression. Everything digital occurs in the Pi sequence somewhere right? Well, quantum computers might be able find that offset and length within Pi, LCG's, or any other kind of sequence.
Imagine downloading a 4 hour DIVX using 20 bytes. 4b sequence ID, 8b offset, 8b length. That is the same length as an IP header...
3. Massive optimization. Remember all those NP-complete problems you learned in comp. sci. ? No more simmulated annealing, genetic algorithm, guesstimation methods. Qubits can find the optimal solution instantly. No more intense calculations for hours/days to find meager 'near' optimal solutions. P.S. NP-complete type problems shows up in almost every complex system in every field / domain.
So what are the implications of this kind of computing becoming available in ten years? It's a wonder we dont hear more about this when reading about quantum computers. The effect they will have when available is almost more interesting than the implementation
I was surprised and pleased to see references to Stuart Koffman in this essay.
The research being done at the Sante Fe Institute with regards to complex adaptive systems, and the nature of complexity in general provide a number of insights to coders writing large software projects (and many other discplines...)
I would highly reccomend At Home in the Universe as a good introduction to the ideas behind research in CAS. ISBN: 0195111303
For those who like more thorough and academic texts the S.I. produces a number of conference and workshop transcripts which are chock full of great papers and enlightening discussion. ISBN: 0201626063 is a good one.
As software/hardware systems grow ever more complex, we will need to apply ever more powerfull methods to manage this complexity. Perhaps by learning from the experiences of millions of years of evolutionary biological computation to socio/economic progression and interaction we can begin to fashion methods of building software/hardware that can adapt and scale in ways we dream of...
All we need to compliment Freenet is a decentralized resource discovery/search infrastructure.
Then all arguments in the afore mentioned article disappear. The sole remaining thorn will be port blocking / filtering by ISP's.
And even this is a technicality, not a show stopper.
It makes things easier on the target machine. Filters themselves require a fair amount of bandwidth and CPU to process incoming packets.
If you are running web services on a limited bandwidth connection (T1/etc) a filter at your ISP (i.e. before your gateway router and you) prevents all the bogus traffic from reaching your machine and wasting bandwidth (and CPU).
There seems to be a lot of confusion about this.
Raw Sockets allow someone to send forged IP packets (spoofing) that appear to come from any IP address the sender chooses.
This makes filtering a DoS attack harder, because you can no longer filter the traffic by IP or domain.
So, right now the limited defense in the DDoS zombie attacks from Windoze is the fact that the IP packets have valid source addresses. These can be filtered at backbone or ISP provider routers.
If these attacks used spoofed IP packets, there would be no easy defense.
The two main points of this article are based on flawed assumptions.
1. Raw sockets in windoze is not the end of the world. *nix systems have them, even vxworks. A number of ISP's filter forged packets. If this type of spoofing is such a harm, it is trivial for ISPs to implement this. Cripling stack interfaces in OS'es is rediculous.
2. Passport will not authenticate every connection made on the net. Sorry, this is a pipe dream M$ sold you on somehow. And second, priority net traffic based on M$ passport is even more impossible.
In the case of M$'s Passport the worst that could happen is online identity theft, where your reputation is soiled, your bank account drained, and your accounts/data for the online services you use are destroyed or corrupted.
.NET
Not a trivial matter. Passport is intended to be THE identification and authorization checkpoint for every service in
A breach of security at this critical juncture would have many severe repurcussions.
Google does not traffic specific identifying information. They only collect query information to drive their statistics.
.Net which basically OWNS your entire online identity, or Intel with UNIQUE identifying serial numbers on CPU's.
This is completely different from M$ and
It is not the amount of data that we should be concerned about, but rather the type of data and its intended use.
Someone mod this up. Not a practical solution, but something worth thinking about.
This hits especially close to home now that I finished working a contract where the pimp agency was siphening off $54/hour of my wages. A fellow I worked with (H1B visa) was actually getting a paltry 45K/year salary, no overtime, while the pimp agency billed him to clients at $95/hour for 40-60 hours a week.
At any rate, never before have I felt this kind of exploitation so close to home, but now I see it many places I look in the business world.
Currently, it is rather difficult to post something anonymously to a newsgroup. Especially if your only newsgroup access is via your ISP.
So, by using anonymizer.com or something similar to log into google groups and then using google to post to a newsgroup, you have a much better chance of remaining anonymous.
Thing is, I don't see why anyone would use this. In reality, the transfer rates aren't as good as a single fast dedicated server
True. If you have an adequate dedicated server with plenty of bandwidth, it will be hard to top with swarmcast.
The benifit comes in terms of cost. Those beefy servers cost a shitload of money in terms of colocation and bandwidth.
A small, unfunded content shop may want to stream animations but cannot afford the cost of a central server to do it.
If they use swarmcast, however, the streaming is accomplished by utilizing bandwidth of everyone participating. No expensive server is needed, and performance is at least decent.
Real world uses for this technology are still lacking, so we shall see how swarmcast gets adopted IRL.
Second, don't the packets contain things like the MAC address of the ethernet card?
Yes, but this changes with every hop of the packet. The initial MAC ID is from your computer, and is the MAC ID of your NIC.
Once this packet hits the first router, it forwards the packet and it now contains the MAC ID of the router's NIC.
The only time tracking MAC IDs is usefull is if you are on a broadcast LAN, like ethernet w/ dumb hubs, and you can sniff traffic. Otherwise, its all the routers/switches MACs...
How could a physicist become a born-again Christian?
When they get old and start to fear death.
Go read about complex systems, self organization, auto catalytic sets, the genome projects underway and the relationship genetically between all living things.
Hope does not make it true. Faith does not change fact.
While I hope that Peekabooty becomes a useable tamper/monitor resistant network, I wish the cDc had focused on some of the more challenging problems facing peer based networks.
There are already a number of secure information sharing networks, like Freenet, Publius, Anonymizer, etc, etc...
The problem with these networks, and probably a majority of the net is locating the content you want in the first place.
They do not mention any details on the discovery mechanism Peekabooty uses, so perhaps they have covered this base as well, but I doubt it.
Napster, which is great for locating content, is quickly dying a painfull death. Gnutella and Freenet, which are more legally resistant are no where near as effective at locating content.
Gnutella is especially inefficient at this task, so I hope Peekabooty is not modeled after the Gnutella style discovery method.
At any rate, I wish a lot of the focus of peer based projects would shift from simply being Peer to Peer!!! into specific implementations of peer based functionality, like resource discovery, content transfer, etc.
"Could you please list the advantages C++ has over Java?"
How about the memory eating JVM for starters?
The point is, the Java people will consider many aspects of the language as 'benifits!'. While the C++ people will see these as misplaced, ill implemented 'drawbacks!'.
It's all about viewpoint...