How to handle this situation primarily depends on where your site is hosted.
If you have your servers hosted with co-location provider like AT&T, Globix, Cable and Wireless (ha ha), Verio ot the like then you'll almost always have the option to "burst" above your monthly allotment of transfer per month - problem solved. Just do some simple math and figure out what is the max of the LAN connection of the provider, how much your server(s) can handle with respect to transfer and you'll be able to figure out if you need to add hardware or NIC's to handle the load. Generally speaking the "bursting" is usually calculated fairly. Also, in months that you use less bandwidth you won't have to pay for a higher class of service above the already agreed upon monthly transfer rates.
However, It doesn't sound like this is the case. A t-1 has a physical capacity to transfer 1.544 Mb/sec. You will never be able to "burst" above this rate. As long as your servers are at the end of this pipe they will never be able to transfer more than ~ 180K/sec to the internet at large. Your options at this point are:
* Add more capacity to your hosting site (expensive).
* "Partner" with a company like Akamai for content delivery. It'll be a few thousand dollars plus the cost of bandwith to set up the content redistribution. Not really a bad deal if you are serious about delivering your content to your users. They also have great reporting about who and where your users are coming from.
* Your last option is to set up a shared/dedicated hosting account with a provider that charges you by the GB. That way you only pay for what you use + the monthly cost of the server. Try interland they have some good deals.
The bottom line is that if your site is hosted at the end of a physical connection you own - it's not going to be enough. You'll need a datacenter environment that has a PhatPipe to the internet and a machine or machine(s) that can handle the throughput. If you have the cash go with Akamai - they are good at what they do.
Flash "Royale" vs. MS "Future Product" Not So Much
on
Platform Evangelism
·
· Score: 5, Insightful
Micah Alpern raises some good points about MS's attention to vector based ui's. I think though that he's completely offbase when saying that Macromedia's announcement of Royal will ilicit any response from Redmond.
Flash won't be a threat to Microsoft as a "full platform". The primary reason is that Macromedia is great at marketing their products - but architecutally their product line lacks consistancy of vision and execution. Flash for example has, over the past three versions proved time and time again that it lacks a reliable, and easy to use programming environment, an absolute necessity for building truly sophisticated ui's and functionality.
Don't get me wrong - there is some amazing flash work out there. Kudo's to the design/developers that were able to produce such things. The road to such accomplishments however is frought with errors, head scratching and mysteries.
This is primarily because Macromedia seems to think that it's OK to produce API level functions that don't behave as expected so long as they are documented. See Macromedia 'Technotes' for further ammo er info. I think somewhere along the way someone at Macromedia misread "Test and Deploy" as "Deploy and Test". Most have to do with I/O such as load movie, getUrl, and loadVariables. Solid multi source I/O is an absolute necessity for building fully featured "rich client" applications. JavaScript is also not an acceptable language for building real applications. Especailly Macromedia's implementation which has a very loose object based approach to dealing with items in the movie. Flash is also slow. On machines who are not as "swift" as their high speed grand children - high complexity movies are sluggish and don't respond well.
What this all comes down to is the fact that from a technology perspective, Macromedia lacks a coherent architecture for accomplishing complex tasks that will be required to build "Royale" and there is a good chance that developers first taste of Royale will be a bitter one.
Of this dude's site. One Thousand Mirrors. The quilting pattern business can't be so pritable that they can afford to take legal action against 1,000 people. Or could it?
It's good software. Being closed or open doesn't matter to many people as long as the software is good.
This is not true at all. Opera is one of the most popular software packages on the bugtraq mailing list. It "features" a wide variety of javascript and buffer overflow exploits. That is not good software.
"the truth must be stated, and that is that it's in no significant body's interests to perform research."
I'd say that statement isn't entirely true. Countless significant figures throughout history have persued knowledge and understanding of the world without the motivation of money and research budgets.
I think you misinterpreted my statement reagarding "arguments about cellphones can most certainly be proven quantitively and should be" It's not that an institution should prove that cellphones do cause damge cellular damage, who cares? There are plenty of other things to do that. No, that was not my intention at all.
So often unfounded or rediculos comments get posted on/.. Some out of jest and others out of ignorance. Sometimes a person might for example, say something like "your cell phone produces 200W". Another person disagrees, and hopefully, at the end of the discussion that ensues someone manages to prove something. And maybe one or all learn something in the process.
If you think you know something, like you knew that I was wrong, then test it by articulating it and having others look over it. Perhaps someone comes along and adds something that you hadn't orginally thought of. That is the value in disproving foolishly drawn conclusions.
Clearly somethings can't be proven, they are a matter of like or dislike or not enough data exists to prove or disprove - those topics just help to broaden our knowledgebase or perhaps, make us feel stupid.
Though according to your math (and mine) 3.2wh * 3600s = 11,520J Not the 1152 as stated. Right?
That would be: 3.2 * 60 = 194 194 * 60 = 11,520.
@.2J per 200W 1ms pulse - that is 58,320 pulses. I say, I say, boyyyya, that's a lot of pulses.
Now... with that said the question is weather or not your phone actually radiates 200W of power at any given point in time, which is really what this whole thing is about.
I found this link:
Maxim CDMA Chipset Specs which is a pretty standard cdma chipset for a cellphone phone. The max power output for the chip is is 39 DBm which is equivalent to about 6 watts. Back to one of two points earlier, a cell phone does not produce 200W RF.
The other point was an attempt to prove that the phone doesn't have the capacity to produce 200W for 1% duty cycle. While this is still a true statement, my calcs for it were way off (i'll be sure to check my units next time).
As for being stubborn, maybe a little. I'm interested in people proving what they say. The arguments about cellphones can most certainly be proven quantitively and should be. Instead of asanine remarks along the lines of "because my monitor shakes, the phone MUST produce 200W." It's foolish to draw such a conclusion. I'd have to think that you would agree being of a learned background.
this is correct. it is also correct to say that that is the total energy capacity of my cell phone. with that said the next calculation in my previous post says that my phones battery can produce 200W for.016 (?) seconds before HAVING NO ENERGY LEFT.
My point is A) My phone will never produce 200 Watts of RF power. B) Even if it did, i could only do so for.016 seconds on a fully charged battery.
Also a 1.5V battery can power a Xenon strobe - but what you you don't have in volts you must make up for in Amps. Inductors are all well and good but they still don't change the fact that Volts * Amps = Watts.
As far as triggered cooking goes - the largest pulses from a GSM phone are 600mW. The question is really does continued expose to this level of RF Output cause cellular damage?
I don't have that answer and I don't know enough to argue for or against it.
No I don't think that you should be concerend about this. The law is vague about how what constitutes "hiding" the point of orgin of comunication.
A better way to look at it is this: you have a tunnel which has an orgin and an enpoint. Both of which are known physical locations, further more the computer that you are likely communicating with is also "known" becuase it's connected to a LAN which is in turn connected to a tunnel end point - which is a known location, not just to you, but at the very least your service provider. It's not as if you are trying to hide or even succeding in "hiding" the point of orgin for your communication.
I imagine that someone will go to court with this but it's not going to hold up - becuase communications networks require physical devices to do the communication and especially in the LAN->Internet scenario the origin of that communication is almost always known. Now bulding a tunnel from a cell phone, then from multiple servers and clearing out the log entries is something else...
Was listed on palm's web site: Tungsten|C Built-in Wi-Fi.
Bluetooth never caught on. In fact - we will find that Bluetooth is going to be used for wireless keyboards and mice - and that's about it. 802.11 is far more usefull from an application programming standpoint more bandwith, more range, more interop with other "connected devices", more versatility.
It used to be that BT had an edge becuase it consumed less power and fit into a smaller package, but with 802.11 CF adapters it's no longer a selling point. 802.11 is here to stay until of course 802.1394.
Absolutely - in these situations, just like we learned in 2nd grade "honesty is the best policy". It doesn't do you, or anyone else any good in underestimating the real cost. Select OSS because it's right for your organization - not becuase it "seems" like a good idea.
Before you go to upper management find out how much the non-open source applications are going to cost. Factor in any consulting fees for setup. Then factor in the cost for global support on an ongoing basis over say the course of the next five years. I'd also suggest adding in any special hardware requirements.
Next find your open source "products". Then find developers who are very comfortable with the "products" that you are recommending. Factor in the cost of hiring them and their salary on an on going basis. They will be your "support" team. Also factor in hardware if needed.
The first hurdle is to prove that it will cost less or at the very least no more than the "off the shelf" products. Then you'll need to put your sales hat on and do a side by side "feature comparison" of the OSS alternatives to the products that you evaluated.
Most of all, be objective and very matter of fact about your presentation. Prove to them that OSS is the way to go becuase it costs less to aquire and maintian and has an equal or superior feature set. Apache is a great case study...
Microsoft has been showing less and less interest in being an exclusive "partner" with our good friends at Intel... Maybe MS is taking the Tel out of WinTel.
My bad - perhaps a better example would be the Outlook bourne viruses that were the craze a few years ago. MS has done a much better job of releasing and quickly distributing their patches of late which is why I say "back then" that it would be easier for making a case for negligence. Though I'm not even sure that it's valid. It will be interested in seeing how this turns out.
Clearly they haven't read their software agreements. It specifically states that MS is not responsible for damage caused as a result of their products. A better chance to procecute MS would have been during the Code Red incident. One might have argued that not being proactive enough about patching consitituted "negligence" on their part. I guess it can't hurt to try!
Slashdot Mirror
How to handle this situation primarily depends on where your site is hosted.
If you have your servers hosted with co-location provider like AT&T, Globix, Cable and Wireless (ha ha), Verio ot the like then you'll almost always have the option to "burst" above your monthly allotment of transfer per month - problem solved. Just do some simple math and figure out what is the max of the LAN connection of the provider, how much your server(s) can handle with respect to transfer and you'll be able to figure out if you need to add hardware or NIC's to handle the load. Generally speaking the "bursting" is usually calculated fairly. Also, in months that you use less bandwidth you won't have to pay for a higher class of service above the already agreed upon monthly transfer rates.
However, It doesn't sound like this is the case. A t-1 has a physical capacity to transfer 1.544 Mb/sec. You will never be able to "burst" above this rate. As long as your servers are at the end of this pipe they will never be able to transfer more than ~ 180K/sec to the internet at large. Your options at this point are:
* Add more capacity to your hosting site (expensive).
* "Partner" with a company like Akamai for content delivery. It'll be a few thousand dollars plus the cost of bandwith to set up the content redistribution. Not really a bad deal if you are serious about delivering your content to your users. They also have great reporting about who and where your users are coming from.
* Your last option is to set up a shared/dedicated hosting account with a provider that charges you by the GB. That way you only pay for what you use + the monthly cost of the server. Try interland they have some good deals.
The bottom line is that if your site is hosted at the end of a physical connection you own - it's not going to be enough. You'll need a datacenter environment that has a PhatPipe to the internet and a machine or machine(s) that can handle the throughput. If you have the cash go with Akamai - they are good at what they do.
Micah Alpern raises some good points about MS's attention to vector based ui's. I think though that he's completely offbase when saying that Macromedia's announcement of Royal will ilicit any response from Redmond.
Flash won't be a threat to Microsoft as a "full platform". The primary reason is that Macromedia is great at marketing their products - but architecutally their product line lacks consistancy of vision and execution. Flash for example has, over the past three versions proved time and time again that it lacks a reliable, and easy to use programming environment, an absolute necessity for building truly sophisticated ui's and functionality.
Don't get me wrong - there is some amazing flash work out there. Kudo's to the design/developers that were able to produce such things. The road to such accomplishments however is frought with errors, head scratching and mysteries.
This is primarily because Macromedia seems to think that it's OK to produce API level functions that don't behave as expected so long as they are documented. See Macromedia 'Technotes' for further ammo er info. I think somewhere along the way someone at Macromedia misread "Test and Deploy" as "Deploy and Test". Most have to do with I/O such as load movie, getUrl, and loadVariables. Solid multi source I/O is an absolute necessity for building fully featured "rich client" applications. JavaScript is also not an acceptable language for building real applications. Especailly Macromedia's implementation which has a very loose object based approach to dealing with items in the movie. Flash is also slow. On machines who are not as "swift" as their high speed grand children - high complexity movies are sluggish and don't respond well.
What this all comes down to is the fact that from a technology perspective, Macromedia lacks a coherent architecture for accomplishing complex tasks that will be required to build "Royale" and there is a good chance that developers first taste of Royale will be a bitter one.
Of this dude's site. One Thousand Mirrors. The quilting pattern business can't be so pritable that they can afford to take legal action against 1,000 people. Or could it?
It's good software. Being closed or open doesn't matter to many people as long as the software is good.
This is not true at all. Opera is one of the most popular software packages on the bugtraq mailing list. It "features" a wide variety of javascript and buffer overflow exploits. That is not good software.
"the truth must be stated, and that is that it's in no significant body's interests to perform research."
/.. Some out of jest and others out of ignorance. Sometimes a person might for example, say something like "your cell phone produces 200W". Another person disagrees, and hopefully, at the end of the discussion that ensues someone manages to prove something. And maybe one or all learn something in the process.
I'd say that statement isn't entirely true. Countless significant figures throughout history have persued knowledge and understanding of the world without the motivation of money and research budgets.
I think you misinterpreted my statement reagarding "arguments about cellphones can most certainly be proven quantitively and should be" It's not that an institution should prove that cellphones do cause damge cellular damage, who cares? There are plenty of other things to do that. No, that was not my intention at all.
So often unfounded or rediculos comments get posted on
If you think you know something, like you knew that I was wrong, then test it by articulating it and having others look over it. Perhaps someone comes along and adds something that you hadn't orginally thought of. That is the value in disproving foolishly drawn conclusions.
Clearly somethings can't be proven, they are a matter of like or dislike or not enough data exists to prove or disprove - those topics just help to broaden our knowledgebase or perhaps, make us feel stupid.
May the remainder of your days shine upon you.
Unfortuate that I forgot that V/Ah = Wh.
.2J per 200W 1ms pulse - that is 58,320 pulses. I say, I say, boyyyya, that's a lot of pulses.
Though according to your math (and mine) 3.2wh * 3600s = 11,520J Not the 1152 as stated. Right?
That would be:
3.2 * 60 = 194
194 * 60 = 11,520.
@
Now... with that said the question is weather or not your phone actually radiates 200W of power at any given point in time, which is really what this whole thing is about.
I found this link: Maxim CDMA Chipset Specs which is a pretty standard cdma chipset for a cellphone phone. The max power output for the chip is is 39 DBm which is equivalent to about 6 watts. Back to one of two points earlier, a cell phone does not produce 200W RF.
The other point was an attempt to prove that the phone doesn't have the capacity to produce 200W for 1% duty cycle. While this is still a true statement, my calcs for it were way off (i'll be sure to check my units next time).
As for being stubborn, maybe a little. I'm interested in people proving what they say. The arguments about cellphones can most certainly be proven quantitively and should be. Instead of asanine remarks along the lines of "because my monitor shakes, the phone MUST produce 200W." It's foolish to draw such a conclusion. I'd have to think that you would agree being of a learned background.
-ZebraX
3.6 Volts * 900 mAh = 3.2 Watts
.016 (?) seconds before HAVING NO ENERGY LEFT.
.016 seconds on a fully charged battery.
this is correct. it is also correct to say that that is the total energy capacity of my cell phone. with that said the next calculation in my previous post says that my phones battery can produce 200W for
My point is
A) My phone will never produce 200 Watts of RF power.
B) Even if it did, i could only do so for
Also a 1.5V battery can power a Xenon strobe - but what you you don't have in volts you must make up for in Amps. Inductors are all well and good but they still don't change the fact that Volts * Amps = Watts.
As far as triggered cooking goes - the largest pulses from a GSM phone are 600mW. The question is really does continued expose to this level of RF Output cause cellular damage?
I don't have that answer and I don't know enough to argue for or against it.
No I don't think that you should be concerend about this. The law is vague about how what constitutes "hiding" the point of orgin of comunication.
A better way to look at it is this: you have a tunnel which has an orgin and an enpoint. Both of which are known physical locations, further more the computer that you are likely communicating with is also "known" becuase it's connected to a LAN which is in turn connected to a tunnel end point - which is a known location, not just to you, but at the very least your service provider. It's not as if you are trying to hide or even succeding in "hiding" the point of orgin for your communication.
I imagine that someone will go to court with this but it's not going to hold up - becuase communications networks require physical devices to do the communication and especially in the LAN->Internet scenario the origin of that communication is almost always known. Now bulding a tunnel from a cell phone, then from multiple servers and clearing out the log entries is something else...
Was listed on palm's web site:
Tungsten|C Built-in Wi-Fi.
Bluetooth never caught on. In fact - we will find that Bluetooth is going to be used for wireless keyboards and mice - and that's about it. 802.11 is far more usefull from an application programming standpoint more bandwith, more range, more interop with other "connected devices", more versatility.
It used to be that BT had an edge becuase it consumed less power and fit into a smaller package, but with 802.11 CF adapters it's no longer a selling point. 802.11 is here to stay until of course 802.1394.
Absolutely - in these situations, just like we learned in 2nd grade "honesty is the best policy". It doesn't do you, or anyone else any good in underestimating the real cost. Select OSS because it's right for your organization - not becuase it "seems" like a good idea.
d00d yur g3ttin' a d3ll!
Nah - i thought it would be interesting to click through an argument with myself - kind of amusing i thought. :-)
The moderators apparently didn't like it all that much.
Kind of artful in a split personility sort of way
Before you go to upper management find out how much the non-open source applications are going to cost. Factor in any consulting fees for setup. Then factor in the cost for global support on an ongoing basis over say the course of the next five years. I'd also suggest adding in any special hardware requirements.
Next find your open source "products". Then find developers who are very comfortable with the "products" that you are recommending. Factor in the cost of hiring them and their salary on an on going basis. They will be your "support" team. Also factor in hardware if needed.
The first hurdle is to prove that it will cost less or at the very least no more than the "off the shelf" products. Then you'll need to put your sales hat on and do a side by side "feature comparison" of the OSS alternatives to the products that you evaluated.
Most of all, be objective and very matter of fact about your presentation. Prove to them that OSS is the way to go becuase it costs less to aquire and maintian and has an equal or superior feature set. Apache is a great case study...
Good luck!
All right that's enought I've had it with you other self - I'm taking my meds again!
Nah d00d yUr the 0ne with I$$UeZ!!!!!
yUr a n00b!!!
I think you have problems.
nAh - y0u go 4uK YuRslef A$$ cL0Wn
YO YO, go 4uK YuR SElF
Microsoft has been showing less and less interest in being an exclusive "partner" with our good friends at Intel... Maybe MS is taking the Tel out of WinTel.
My bad - perhaps a better example would be the Outlook bourne viruses that were the craze a few years ago. MS has done a much better job of releasing and quickly distributing their patches of late which is why I say "back then" that it would be easier for making a case for negligence. Though I'm not even sure that it's valid. It will be interested in seeing how this turns out.
Clearly they haven't read their software agreements. It specifically states that MS is not responsible for damage caused as a result of their products. A better chance to procecute MS would have been during the Code Red incident. One might have argued that not being proactive enough about patching consitituted "negligence" on their part. I guess it can't hurt to try!
I think they should get a platinum record or something.
I've already made it. You are wrong and full of baseless claims.
What are you talking about?
Only a few people within SUn seem to really `get it'
What evidence do you have to support this claim?
PHBs convinced that if they let a GPLed program in the door, every shred of their own software immediately becomes public.
What makes you say this?
Do you have any proof that this is the case?
Unfortunately leon has a bit of trobule being able to prove his wild assertions.