But I can live with it, its better than the use of bandwith when you mean data (I guessed you meant that the first time, but it was highly ambiguous you must admit).
Hosting spammers might make you a pariah... but if your bandwith becomes nearly free due to the hosting arrangement you propose they dont need a lot of other buessinuess. I admit there arent a whole lot of way's to generate a lot of traffic in a legit way where the the receiver doesnt explicitly initiate the transfer, so it should be relatively easy to police (the scheme will obviously need traffic _content_ rules in the contracts with anyone providing hosting and policing of those rules though, at least as long as spamming is legal). Such a scheme would make it a lot easier to host warez on you cable account too:)
IMO bandwith costs should not be covered by the people who have surplusses though, ISP's and hosting companies should not be forced into unhappy marriages if it can be avoided. Just make outgoing traffic surplusses tradeable commodities.
From a peer's point of view a content provider will consume bandwith, it might provide bits... but it still consumes bandwith. Only backbones provide bandwith, hosts never.
It might be a nice idea in theory to charge towards peers who consume data and away from peers who provide data, with a slight surcharge per bit to pay for bandwith costs, but hosting a spammer or a DOS attack will provide data just as well as good content.
i-mode makes it money from user subscription to services plain and simple, users subscribe to i-mode content providers and the network operator gets 9% of the subscription fee. A good framework to handle subscriptions through the network operator is nice, but for the internet I doubt many people would care if pay per view costs go to their credit card or to their ISP bills.
Free content at the moment costs no money to provide via i-mode, but it certainly doesnt get the content provider any money either. NTT DoCoMo has even hinted it will start charging for it if they grow large enough...
What does it matter? You dont need 3D cards for off-line rendering (thats why noone in their right mind would consider using the GSCube to do a movie, only slashdot editors).
You dont seem to understand the english language, it doesnt matter to the same extent if theres an occasional failure of an ICBM... a given failure rate can be perfectly acceptable for nukes, but not for nuclear powered vehicles. There are different set of requirements for effectiveness of nukes and safety of launch vehicles.
The first is used in nuclear war, the second isnt. See the difference?
Its still a controlled reentry, and why would an ICBM warhead designer even care about safety? So what if 1% fails during reentry, they are setting off a nuke anyway.
You dont need challenger type accidents for trouble, think Ariane type accidents. Lets assume it will go wrong, I need something more than hand waiving "amount of fissionable material needed would be minimal". Im sure it would be the minimum amount required, Im sure it would be only a fraction of the amount in nuclear reactors and nukes. What Im more worried about is if its say the minimum amount required to double the leukemia rates for the entire south west in the case of an accident.
We need to know if a rocket engine that can safely harness that power can even be made first, without assuming no accidents will happen preferrably, jumping to the conclusion that it can is no better than the reverse.
No processors wouldnt be faster over all, the only way to speed up processing of single threads is by clockrate... there is only so much paralellism you can extract on the fly, not a whole lot, after that clockrate is the only way to speed things up.
The only alternative is going to explicit parallelism, simply making a slightly slower but wider superscalar processor (the old Cyrix approach) doesnt get you very far.
The biggest problem with explicit parallelism is programming, multithreading is a very poor method... unfortunately its the only one most programmers accept.
It doesnt matter, it has to be one of the most important chips on the market to be used in a sentence like that in the first place.... and in his an mine opinion it isnt even that.
Tree's dont grow that fast, and you always spread out the beam a bit (a wider beam has several advantages). If you use a big fresnel lense the only thing you have to worry about is an eagle landing, there's no reason to put any perch worth landing on in front of it anyway.
Unless they use something like OFDM the fact that you will have a lot of path's to the receiver of comparable attenuation will present problems at high rates (havent heard of people using that for laser com... but they might). At low rates it doesnt matter.
Get two fast ethernet to fiber convertor and some fresnel lenses and hack the convertor with the lenses as collimators in front of the laser/pin diode's... then you have a relatively cheap point to point laser connection. That shouldnt be a too difficult to pull of hack.
You dont need all the dynamic discovery shit which drives the price for the japanese product way way up.
Hell you might be able to get professional point to point laser solutions cheaper than that...
1 Gb/s shouldnt be too troublesome, 622 Mb/s laser connections arent really unusual... and why should they be, under good conditions air is actually a pretty damn good transmission path for the laser. It guarantuees a single mode (the chances of photons getting nocked off the path and then nocked back to the receiver are negligible) and transmission losses are usual not a problem. But once you get a good fog or rain storm you'll need a pretty damn powerfull laser to burn through it over 15 miles:/ You are looking at a couple of 1000's of dB's (!!!) worth of attenuation in worst case.
Wireless is a poor WAN infrastructure, there just isnt enough bandwith available in the bands which dont suffer much atmospheric loss... which is why satellites always will be a poor substitute for good old fiber.
Probably RFSQ, which needs superconductance to work, Id hesitate of putting that on the same level as CMOS transistor technology (which this article wasnt about in the first place of course). HTMT does not stand for "Hyper Technology Management Threading".
Did you miss Alpha's dual cluster structure and P4's cross chip communication pipeline stages? You can pipeline everything... including simple transmission lines.
You sublicense it the moment you get it to a closed source license... and hey presto its no longer open source software, despite its origins. Thats why its "compatible" with the GPL too, which is in truth only compatible to itself, it allows sublicensing to nearly any license you want.
Yes indeed, they put DVD decoders in software and look where that got them... somoene reverse engineered it from the software and pirates sprang out of the wood work everywhere to copy content to Divx because it allows easy distribution.
Now thats all fine and well for movies, I like to pirate a movie every now and then too... but Id rather not all the information needed to plunder my money be exposed and copied as easily.
Of course CSS was an inherently unsafe system where obscurity of the underlying algorithm and not the key's was the most important safe guard, although the initial keys used were from reverse engineered software again showing the danger of software... not like e-money schemes which mostly rely on open encryption standards assumed to be strong, but lets not let facts prevent either of us from making stupid analogies.
Reverse engineering of hardware can be made much more difficult and expensive than for software, especially using circuits which only store key's dynamically (ie. always on devices). Even if reverse engineered it doesnt help much, in a good e-money system using public key encryption there are no secret keys on the cards which compromise the system... they just compromise the money stored on it, not worth the effort. With software its much easier and once done can be abused remotely... with exploits coming out like clockwork that is a dangerous mix.
Software schemes are inherently as safe as the OS, which makes software only e-money system about as safe as credit cards. Do we really need another system with that much avenues for abuse???
The only realistic schemes use hardware. Micropayment schemes also require a certain amount of automation of authorization, but once again putting this in software is asking for trouble. Id imagine an option where the external box presents me with some options to give a site an expense cap up to which I will automatically be billed after which I will have to renew my authorization.
In Europe electronic purses are becoming quite popular (I use em... cause Im too lazy to count my change, and the bank charges for normal ATM payments are passed on to the buyers for small sums). I think this provides the most viable way forward for micropayments, see http://www.protonworld.com/apps1/internet.htm for some commercial hype and background.
Widespread use of a software solution for e-money is a disaster waiting to happen.
The second would be nice, but quite impossible... even if you just give them their own memory space context switches will kill you, same problem as using a strict microkernel (in languages like Java it wouldnt be an issue with CSP instead of threads, once you start juggling pointers in C it becomes one though). Id really like to see future processors to allow much more finegrained access control, a process ID on the page identifier would be interesting... for SMT systems this is especially important, since without it they can only run threads from the same process concurrently. But thats all besides the point.
An API which only allowed message passing to me would seem sufficient for most people's uses. That doesnt mean you cant pass references, for efficiency, you'd just make it so passing it implicitly put whats referenced out of scope. Shared memory where multiple processes read the memory and one or more processes perform unsynchronized writes are the exception, why make it the common case in the language and put all the burden for safety on the developer?
Inherently FORTH has no more support for parallelism than say C. The most popular way to make FORTH concurrent is through other means than threading, and that is indeed a good thing... but FORTH in itself has got nothing to do with this topic.
Slashdot Mirror
But I can live with it, its better than the use of bandwith when you mean data (I guessed you meant that the first time, but it was highly ambiguous you must admit).
:)
Hosting spammers might make you a pariah... but if your bandwith becomes nearly free due to the hosting arrangement you propose they dont need a lot of other buessinuess. I admit there arent a whole lot of way's to generate a lot of traffic in a legit way where the the receiver doesnt explicitly initiate the transfer, so it should be relatively easy to police (the scheme will obviously need traffic _content_ rules in the contracts with anyone providing hosting and policing of those rules though, at least as long as spamming is legal). Such a scheme would make it a lot easier to host warez on you cable account too
IMO bandwith costs should not be covered by the people who have surplusses though, ISP's and hosting companies should not be forced into unhappy marriages if it can be avoided. Just make outgoing traffic surplusses tradeable commodities.
From a peer's point of view a content provider will consume bandwith, it might provide bits... but it still consumes bandwith. Only backbones provide bandwith, hosts never.
It might be a nice idea in theory to charge towards peers who consume data and away from peers who provide data, with a slight surcharge per bit to pay for bandwith costs, but hosting a spammer or a DOS attack will provide data just as well as good content.
i-mode makes it money from user subscription to services plain and simple, users subscribe to i-mode content providers and the network operator gets 9% of the subscription fee. A good framework to handle subscriptions through the network operator is nice, but for the internet I doubt many people would care if pay per view costs go to their credit card or to their ISP bills.
Free content at the moment costs no money to provide via i-mode, but it certainly doesnt get the content provider any money either. NTT DoCoMo has even hinted it will start charging for it if they grow large enough...
What does it matter? You dont need 3D cards for off-line rendering (thats why noone in their right mind would consider using the GSCube to do a movie, only slashdot editors).
You dont seem to understand the english language, it doesnt matter to the same extent if theres an occasional failure of an ICBM... a given failure rate can be perfectly acceptable for nukes, but not for nuclear powered vehicles. There are different set of requirements for effectiveness of nukes and safety of launch vehicles.
The first is used in nuclear war, the second isnt. See the difference?
Its still a controlled reentry, and why would an ICBM warhead designer even care about safety? So what if 1% fails during reentry, they are setting off a nuke anyway.
You dont need challenger type accidents for trouble, think Ariane type accidents. Lets assume it will go wrong, I need something more than hand waiving "amount of fissionable material needed would be minimal". Im sure it would be the minimum amount required, Im sure it would be only a fraction of the amount in nuclear reactors and nukes. What Im more worried about is if its say the minimum amount required to double the leukemia rates for the entire south west in the case of an accident.
We need to know if a rocket engine that can safely harness that power can even be made first, without assuming no accidents will happen preferrably, jumping to the conclusion that it can is no better than the reverse.
No processors wouldnt be faster over all, the only way to speed up processing of single threads is by clockrate... there is only so much paralellism you can extract on the fly, not a whole lot, after that clockrate is the only way to speed things up.
The only alternative is going to explicit parallelism, simply making a slightly slower but wider superscalar processor (the old Cyrix approach) doesnt get you very far.
The biggest problem with explicit parallelism is programming, multithreading is a very poor method... unfortunately its the only one most programmers accept.
It doesnt matter, it has to be one of the most important chips on the market to be used in a sentence like that in the first place.... and in his an mine opinion it isnt even that.
Tree's dont grow that fast, and you always spread out the beam a bit (a wider beam has several advantages). If you use a big fresnel lense the only thing you have to worry about is an eagle landing, there's no reason to put any perch worth landing on in front of it anyway.
Pretty impressive... Im wondering what those beams will do to the wLAN products which will soon occupy the same bands though.
Good starting point: http://www.uwb.org/index.htm
Unless they use something like OFDM the fact that you will have a lot of path's to the receiver of comparable attenuation will present problems at high rates (havent heard of people using that for laser com... but they might). At low rates it doesnt matter.
Get two fast ethernet to fiber convertor and some fresnel lenses and hack the convertor with the lenses as collimators in front of the laser/pin diode's... then you have a relatively cheap point to point laser connection. That shouldnt be a too difficult to pull of hack.
You dont need all the dynamic discovery shit which drives the price for the japanese product way way up.
Hell you might be able to get professional point to point laser solutions cheaper than that...
A hundred dB's or so is doable though, so if you can cut it up into ~1 mile segments...
1 Gb/s shouldnt be too troublesome, 622 Mb/s laser connections arent really unusual... and why should they be, under good conditions air is actually a pretty damn good transmission path for the laser. It guarantuees a single mode (the chances of photons getting nocked off the path and then nocked back to the receiver are negligible) and transmission losses are usual not a problem. But once you get a good fog or rain storm you'll need a pretty damn powerfull laser to burn through it over 15 miles :/ You are looking at a couple of 1000's of dB's (!!!) worth of attenuation in worst case.
Wireless is a poor WAN infrastructure, there just isnt enough bandwith available in the bands which dont suffer much atmospheric loss... which is why satellites always will be a poor substitute for good old fiber.
Wireless is for LAN and low bandwith.
Probably RFSQ, which needs superconductance to work, Id hesitate of putting that on the same level as CMOS transistor technology (which this article wasnt about in the first place of course). HTMT does not stand for "Hyper Technology Management Threading".
Did you miss Alpha's dual cluster structure and P4's cross chip communication pipeline stages? You can pipeline everything... including simple transmission lines.
You dont have to acknowledge public domain software authors, they are not like those ego stroking BSD weenies.
If it has a license it isnt PD.
You sublicense it the moment you get it to a closed source license... and hey presto its no longer open source software, despite its origins. Thats why its "compatible" with the GPL too, which is in truth only compatible to itself, it allows sublicensing to nearly any license you want.
I wonder how many IE exploits there are to emulate such a mouseclick (nevermind what happens if you ever get trojaned).
Yes indeed, they put DVD decoders in software and look where that got them... somoene reverse engineered it from the software and pirates sprang out of the wood work everywhere to copy content to Divx because it allows easy distribution.
Now thats all fine and well for movies, I like to pirate a movie every now and then too... but Id rather not all the information needed to plunder my money be exposed and copied as easily.
Of course CSS was an inherently unsafe system where obscurity of the underlying algorithm and not the key's was the most important safe guard, although the initial keys used were from reverse engineered software again showing the danger of software... not like e-money schemes which mostly rely on open encryption standards assumed to be strong, but lets not let facts prevent either of us from making stupid analogies.
Reverse engineering of hardware can be made much more difficult and expensive than for software, especially using circuits which only store key's dynamically (ie. always on devices). Even if reverse engineered it doesnt help much, in a good e-money system using public key encryption there are no secret keys on the cards which compromise the system... they just compromise the money stored on it, not worth the effort. With software its much easier and once done can be abused remotely... with exploits coming out like clockwork that is a dangerous mix.
Software schemes are inherently as safe as the OS, which makes software only e-money system about as safe as credit cards. Do we really need another system with that much avenues for abuse???
The only realistic schemes use hardware. Micropayment schemes also require a certain amount of automation of authorization, but once again putting this in software is asking for trouble. Id imagine an option where the external box presents me with some options to give a site an expense cap up to which I will automatically be billed after which I will have to renew my authorization.
In Europe electronic purses are becoming quite popular (I use em... cause Im too lazy to count my change, and the bank charges for normal ATM payments are passed on to the buyers for small sums). I think this provides the most viable way forward for micropayments, see http://www.protonworld.com/apps1/internet.htm for some commercial hype and background.
Widespread use of a software solution for e-money is a disaster waiting to happen.
The second would be nice, but quite impossible... even if you just give them their own memory space context switches will kill you, same problem as using a strict microkernel (in languages like Java it wouldnt be an issue with CSP instead of threads, once you start juggling pointers in C it becomes one though). Id really like to see future processors to allow much more finegrained access control, a process ID on the page identifier would be interesting... for SMT systems this is especially important, since without it they can only run threads from the same process concurrently. But thats all besides the point.
An API which only allowed message passing to me would seem sufficient for most people's uses. That doesnt mean you cant pass references, for efficiency, you'd just make it so passing it implicitly put whats referenced out of scope. Shared memory where multiple processes read the memory and one or more processes perform unsynchronized writes are the exception, why make it the common case in the language and put all the burden for safety on the developer?
Inherently FORTH has no more support for parallelism than say C. The most popular way to make FORTH concurrent is through other means than threading, and that is indeed a good thing... but FORTH in itself has got nothing to do with this topic.