You should see HTTPS, which has a 12-way hand-shake, over a 200ms cell-phone link. This is one of the reasons why we need something other than TCP+HTTPS. Fewer-hand-shakes in exchange for more CPU usage, which we have tons idle CPU time.
TCP has some major issues with congestion control that isn't playing well with buffer-bloat. The Internet is bursty in nature. TCP takes too long to ramp-up. It is acutally easier on infrastructure to burst 10MB over one second than to stream it over 10 seconds.
There are a lot of write-ups on issues with TCP, but one of the big issues that is starting to become a problem as speeds increase but latency is staying fixed, is the congestion control. Because TCP starts off slow and ramps up, it tends not to make use of available bandwidth. Un-used bandwidth is bad. The other issue is current TCP uses packet-loss to decide when to back off. The issue this creates is packet-loss tends to affect a lot of connections at the same time. You get this synchronization where lots of computers experiencing packet-loss all at the same time, so they all back-off at the same time. Suddenly the route is under-utilized. All of the connections start building up again until the route is over-utilized, then they all back-off at the same time.
This issue alone could possible cause large portions of the Internet to fail. It has happened in the past and the variables are getting to be similar again. Essentially you're left with a large portion of the Internet routes in a constant violent swing between over-utilized and under-utilized.
You get this issue where the average utilization is low, but packet-loss and jitter is high. Relatively speaking.
There is a lot of theory on how to fight these issues, but the only real way to figure this out is to actually test these theories on the large scale. A protocol that rides on top of UDP and runs in the application is the perfect place to test this. If something goes wrong, you just disable it. You can't do that with most OSs TCP stacks.
BitTorrent has a custom protocol that uses UDP and is even more fair than TCP. UDP doesn't have flow-control built in, but there is nothing stopping the application layer from implementing it.
The main reason to not use TCP is that you can roll your own hand-shake and flow-control and congestion detection, without relying on the baked-in static implementation your OS has.
By definition, classified means it's only available to authorized personal or secret. By definition, public knowledge cannot be classified. If it can be, then the word carries no meaning and is pointless.
If you want a different meaning, then use a different word. I cannot think of any word that currently describes the current situation, so a new word may need to be created.
The reason is fine, but the problem is it entirely hinges on the effectiveness of the formal process to declassify the data. If this part of the process is broke, then the entire process is broke.
By common sense, what is public knowledge cannot not be classified. Otherwise the government could classify the color of the sky and tell workers to not look up.
The point is MongoDB is queries via REST which is native to Javascript, it returns a JSON result, which is transparently handled by the Javascript Middle-tier, when then passes it along to the client, which also runs Javascript.
No Other language(that I know of) can lay claim to a "full stack", like that.
TCP is quite good about not hogging, just make sure you don't have insane buffer bloat causing the protocol to not realize that there is congestion. Otherwise TCP is quite good at backing off.
Some older videos are worse than the newer ones just because of the original quality but what can you expect for a 3Mb-4Mb (max) stream?. As for hick-ups in Netflix.. What? It buffers out over a minute.
I heard Netflix Super HD is really nice and is 8Mb. I contacted my ISP and awaiting a response.
The more you know about the position of the cat, the less you know about its velocity. Ever try to measure the position of a cat that you just dropped into the bathtub? You know it has a high velocity, but it's hard to tell where it really is.
Yep. Programming is thought process and a way of life. Languages are just a way to express a thought processes. You don't need to write code to be a good programmer.
Slashdot Mirror
Don't copy that floppy! Never mind, it's GPL'd. Copy away.
My Win7-64 with 6GB of memory takes under 30sec to boot.
It's going to be a long time between playing games or doing work then, I only reboot my computer once a month or so.
Boeing and NASA are using DWAVE computers to crunch very specific types of data almost 10,000 times faster. A little more than just "research"
You should see HTTPS, which has a 12-way hand-shake, over a 200ms cell-phone link. This is one of the reasons why we need something other than TCP+HTTPS. Fewer-hand-shakes in exchange for more CPU usage, which we have tons idle CPU time.
TCP has some major issues with congestion control that isn't playing well with buffer-bloat. The Internet is bursty in nature. TCP takes too long to ramp-up. It is acutally easier on infrastructure to burst 10MB over one second than to stream it over 10 seconds.
There are a lot of write-ups on issues with TCP, but one of the big issues that is starting to become a problem as speeds increase but latency is staying fixed, is the congestion control. Because TCP starts off slow and ramps up, it tends not to make use of available bandwidth. Un-used bandwidth is bad. The other issue is current TCP uses packet-loss to decide when to back off. The issue this creates is packet-loss tends to affect a lot of connections at the same time. You get this synchronization where lots of computers experiencing packet-loss all at the same time, so they all back-off at the same time. Suddenly the route is under-utilized. All of the connections start building up again until the route is over-utilized, then they all back-off at the same time.
This issue alone could possible cause large portions of the Internet to fail. It has happened in the past and the variables are getting to be similar again. Essentially you're left with a large portion of the Internet routes in a constant violent swing between over-utilized and under-utilized.
You get this issue where the average utilization is low, but packet-loss and jitter is high. Relatively speaking.
There is a lot of theory on how to fight these issues, but the only real way to figure this out is to actually test these theories on the large scale. A protocol that rides on top of UDP and runs in the application is the perfect place to test this. If something goes wrong, you just disable it. You can't do that with most OSs TCP stacks.
BitTorrent has a custom protocol that uses UDP and is even more fair than TCP. UDP doesn't have flow-control built in, but there is nothing stopping the application layer from implementing it.
The main reason to not use TCP is that you can roll your own hand-shake and flow-control and congestion detection, without relying on the baked-in static implementation your OS has.
By definition, classified means it's only available to authorized personal or secret. By definition, public knowledge cannot be classified. If it can be, then the word carries no meaning and is pointless.
If you want a different meaning, then use a different word. I cannot think of any word that currently describes the current situation, so a new word may need to be created.
Anything paid for by taxes is by definition, public domain.
"Leaked" describes how the information was released, but either way, it was released.
The reason is fine, but the problem is it entirely hinges on the effectiveness of the formal process to declassify the data. If this part of the process is broke, then the entire process is broke.
By common sense, what is public knowledge cannot not be classified. Otherwise the government could classify the color of the sky and tell workers to not look up.
It is nothing more than a state of denial.
I can transparently run C/Python/etc on MongoDB?!
The point is MongoDB is queries via REST which is native to Javascript, it returns a JSON result, which is transparently handled by the Javascript Middle-tier, when then passes it along to the client, which also runs Javascript.
No Other language(that I know of) can lay claim to a "full stack", like that.
Or OS or hardware, while we're being pedantic.
He wasn't talking about Mars, but the moon. His argument stands.
The Linux crowd includes cheap effective set-top boxes, like Roku. You may want to alter your argument.
Because people watch Netflix at work? Everyone else has a home computer with Win7.
TCP is quite good about not hogging, just make sure you don't have insane buffer bloat causing the protocol to not realize that there is congestion. Otherwise TCP is quite good at backing off.
Some older videos are worse than the newer ones just because of the original quality but what can you expect for a 3Mb-4Mb (max) stream?. As for hick-ups in Netflix.. What? It buffers out over a minute.
I heard Netflix Super HD is really nice and is 8Mb. I contacted my ISP and awaiting a response.
Random googled link. Feel free to google more. http://www.geek.com/games/ps4-runs-modified-version-of-the-freebsd-9-0-operating-system-1559866/
A compute rate that varies with temperature would seem to be a bug, rather than a feature.
Only in an environment where a stable temperature is a feature, unless you think crashing is a good thing, chips can only get so warm.
Suicide is not cowardice, it's either a mental disorder or logical. Probably a bit of grey in between those two.
Well, Sony did say that PS4 will be running on a custom OS that is based from FreeBSD 9.0
The more you know about the position of the cat, the less you know about its velocity. Ever try to measure the position of a cat that you just dropped into the bathtub? You know it has a high velocity, but it's hard to tell where it really is.
Yep. Programming is thought process and a way of life. Languages are just a way to express a thought processes. You don't need to write code to be a good programmer.