Pyjamas provides a python-to-javascript Compiler and a Web Widget set, the combination of which allows developers to easily write well-designed desktop-like Rich Media Applications in python classes and modules that will execute in all major web browsers. without having to write a single line of javascript. Pyjamas is a port of Google Web Toolkit.
This is only a benefit if the resources are already cached locally anyway, so the browser could start loading a.png for instance while the main page html downloads. And there's cost not a benefit if the resource is already in memory. And browsers could do this anyway most of the time by just remembering what resources were used on a page even if the page itself is not cached. So this is an extremely marginal benefit at the cost of some complexity and bandwidth.
You assume here that 1. dynamic content are generated instantly, and 2. the server can saturate the bandwidth. Let's say it take 200 ms to generate the dynamic data. In the mean time, the browser can check if it has the newest JS version from my CDN, since it already know it will need it. Also, since my dynamic content is not on a CDN, it can't fully utilize your bandwidth, so while it's still waiting for the full HTML document, it uses the rest of the bandwidth to fetch some static files it already know it will need.
If multiple files are multiplexed then when the connection drops then multiple files have to be restarted in the middle instead of just one, and dynamically generated resources need to be redone from scratch. The only practical benefit to sending multiple files at once is that the browser could start processing them with just partial data (with an image header for instance it could allocate the memory for the image). This again is very marginal compared to the transfer time and also more complex.
How often does a TCP connection actually drop? Pretty rarely, even with some packet loss. Also, as you mentioned, headers. If the server sends the header of all the images first, it also knows what dimensions it should use in the layout, and can start on that much earlier.
So can pipelining (in general, not "HTTP pipelining"). Browser sends server a list of resource, it replies back sending whole files in smallest-first order for instance. The difference is that if you are sending whole files at once pipelined then you don't have to explicitly state priorities and have mechanism for setting and adjusting them so pipelining is less complex.
Ah, but as you yourself point out, HTTP pipelining can not. People have tried for a long time to get HTTP pipelining to work properly, but so far it's not the solution people are looking for.
So can SSL, which SPDY basically requires anyway because of proxies. Enable deflate compression over SSL and it compresses headers.
Ah, but SSL is crazy expensive(TM) because of the pipelining problems. you need multiple connections, and ssl negotiation is pretty slow.
HTTP is old. Very old in technology standard. It's pretty good too, and can be expanded. But it was designed for a completely different scenario than what we have today, and it have some fundamental limits (as pointed out quite a lot already).
a specific combination of super-popular website plus popular client software
Well, you're wrong on that part, at least. Chrome is happy to use SPDY protocol to all web servers, not just google's (verified by someone earlier in the thread, via https://github.com/donnerjack13589/node-spdy and chrome://net-internals/ ), and I'm sure google's servers are happy to serve content over SPDY to any browser that asks for it. There is a detailed draft around the protocol, and there's open source code out there implenting it (for example in chromium).
I see this as no different from, say, some browsers supporting webgl and audio/video tags before they're standardized. Or if apache added support for a new compression algorithm.
google.com (and apache - mod_spdy), chrome (and chromium - open source). Oh, and a draft paper detailing the protocol....
Lemme think... Nope, don't see the problem here.
Google is seriously making Chrome as fast as they can, on as many servers as they can. They're also seriously making Google pages as fast as they can, on as many browsers as they can.
It IS technical progress. And if your idea of when you should start putting out new tech / standards is when all support it, that's just silly. Nothing stops other browsers / servers from implenting it if they think it's an advantage.
This is, in my opinion, similar to when the img tag came to the web, or if you want to go further back, when cars started to replace horses. Progress happens. And it's backwards compatible, so no splintering.
And as for your last comment, that's just childish peevishness. Of course something that makes the general loading of pages 40% faster, will also make a subset of that page load faster. If you really see a problem / conspiracy in that, I think you might need to get your head checked.
If server "knows" that I "need" 2MB of flash ads to see the 40K html page, it would send them to me. IOW browser is out of control what server sends, browser can only discard the content which has wasted my bandwidth and isn't going to be displayed.
They can already do tricks like that, by sending you 2mb of inline javascript and SVG and base64 encoded content, and other goodie stuffs. Uncompressed, of course.
For static content, it is even worse: first time I visit the page it is cached and then a cached copy used. With SPDY, bandwidth is going to be always wasted for transferring the static content. Yes, I need it to display the page - but no, I have already local cached copy.
That's just a badly configured server. Just like today, when all the static content is with no-cache, expired 1970, and on same domain.
Sorry, mac. The web is already a scary place. SPDY will make some bandwidth abuse things easier (and give a speedup overall), but won't suddenly create new opportunities for Teh Evilz.
From what I can see, it's an open draft, so I don't see why no-one else can implent it. Maybe they should thank Google for doing the hard work (creating it, and putting it into a popular open source browser) instead.
Seriously, if people thought like you when the web was new, we'd never have a tag for displaying images, because that would be unfair for all the browsers and servers that didn't implent it.
1. It can specify other needed files in header, so browser can start loading them before it gets the http page 2. It can send more than one file at a time. It can mux multiple files, while pipelining only allows you to transfer files one at a time. 3. It can prioritize some files over others. 4. It can compress the HTTP headers. Modern browsers send their life history, the weather outside, everything that have ever been installed on the computer, every language / encoding it can possibly use, cookies, referer, when it saw the content last, what the etag of that context was, and so on. Header compression can actually make a difference.
We downloaded 25 of the "top 100" websites over simulated home network connections, with 1% packet loss. We ran the downloads 10 times for each site, and calculated the average page load time for each site, and across all sites. The results show a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL), and 39% - 55% over SSL.
--------
Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers. On the lower-bandwidth DSL link, in which the upload link is only 375 Kbps, request header compression in particular, led to significant page load time improvements for certain sites (i.e. those that issued large number of resource requests). We found a reduction of 45 - 1142 ms in page load time simply due to header compression.
-------
We discovered that SPDY's latency savings increased proportionally with increases in packet loss rates, up to a 48% speedup at 2%. (The increases tapered off above the 2% loss rate, and completely disappeared above 2.5%. In the real world, packets loss rates are typically 1-2%, and RTTs average 50-100 ms in the U.S.)
Agreed. Perspectives is the best solution I've seen for this problem so far.
The only problem I see with it at the moment is either if
1. An attacker control all your internet access from before you install it 2. An attacker control the majority of the Perspectives servers.
But I don't see any of those as impassable problems. 1 can be solved by a trusted install (f.x. from a cdrom), and nr 2 can be solved by crowdsourcing (and some cleverness, like requiring the servers to be in different subnets / countries - thus really complicating things for an attacker).
But, as it threaten a current drug^H^H^H^Hbusiness cartel, and it won't make anyone rich, I doubt it will become a widely enough deployed standard.
What annoys me most is the "If we can't do it, noone can" attitude.
I remember one myth (some details might be slightly wrong here, been a while since I saw it) where a stewardess survived a plane crash by sitting strapped into her seat in the tailpart of the plane. They tried to reproduce it, failed, and then had to label it "plausible", because, well.. After some research, they found out it did actually happen, and was well documented. Before they found that, it was clearly in the "busted" bin.
What does that say about the rest of the tests they do? Not much, admittedly, but it at least gives one case where they got the wrong conclusion.
I like the show a lot, but mostly for entertainment value. I generally find some annoyances regarding their "scientific" testing around every 2-3 episodes. Which, for me, makes it hard to take the show seriously:)
SQL injection? This sounds like people not sanitizing OUTPUT values, also known as XSS.
It's talk about redirect, and I would guess that's via some JS that gets displayed.
I see a script src="url" tag in the screenshot, which further lends credit to that theory.
However, other than the article text, I can't see any evidence of a SQL injection attack, which is a different kettle of fish than XSS.
The researchers also noted that some iTunes URLs have been injected with the script, but that Apple has done a good job in securing the site against this kind of attacks.
"The way iTunes works is that it downloads RSS/XML feeds from the publisher to update the podcast and list of available episodes. We believe that these RSS/XML feeds have been compromised with the injected code. The good thing is that iTunes encodes the script tags, which means that the script doesn't execute on the user's computer," they explained.
But, but, but.... You hate us for our freedom! And will stop at nothing to steal that freedom for yourselves! That's what [silly media person] told me, and he wouldn't lie!
Basically, you're advocating the death penalty for a jaywalking ticket.
Actually, you'd be ticketing person B for the jaywalking of person A, because person B didn't stop him. Never mind that person B was around the street corner and didn't even see the jaywalker.
Elseif Country = "USA":
Then Pr^CHello, this is agent Smith. For your own safety, please stop visiting these terrorist sites. This is your first and only warning.
Taking bets, when to see the first riots "A la Tunisia" starting?
The class was learning about some revolt in which some peasants had wanted to stop being peasants and, since the nobles had won, had stopped being peasants really quickly.
I have modpoints avaliable roughly 50% of the time..
But I almost never use them (Only if I see something very good with low rating), and I never meta-moderate.
Since I still use the old comment layout still, its kinda pain in the ass, since you have to scroll all the way to the bottom to click on the "Moderate" button (and if I don't do it rightaway, I forget it)
That allows them to sell the power some other place where prices are higher then turn around and demand higher prices locally too because reserves are low.
That sounds awfully familiar.. Let me guess, you're from Norway, too?:D
Thank you for pointing out that you're clueless and can't be seen as a valid source of security information.
Now, if you were wondering what I'm talking about, there was a slashdot article on it some time ago and all, and you've been telling everyone how stupid those linux folks are, and so on?
Well, no distribution I know of have autorun. No, not even Ubuntu. What the article were talking about were a flaw in gnome's program for making image thumbnails (which he then put on an usb disk, which made bad things happen when he opened the disk and thumbs were created). He was also talking about a potential flaw in the code that handles new USB devices being plugged in (Like asking for usb id, type, and so on), and mounted (for example, flaws in file system code)
And now that you've gotten some actual info about it, I bet that you'll promptly forget it, because it does not fit in your narrow world view.
(and if I seem to be a bit too snarky, its been a crap week at work. And you were the lucky clueless one)
if particles in the LHC are sent back in time, does this mean that you can set things up such that a particle collides with multiple instances of itself? If so, when does the energy get released from the collision?
December 21, 2012 - with terrible results. There was one lone man that was sent back in time, to warn the world. However, due to the wild time forces, he was sent far back in time, to around 3000 BC.
He says that out of principle, he will continue to use his PS3 for what he bought it for, in spite of what Sony thinks (and for him to do that, he *have* to get a pirate copy. He tried a legitimate copy, but that refuse to run).
And then you say the true measure of one's principle is not to follow one's principle...
I have to ask you : Are you really that retarded, or did you just copy/paste some standard mantra without involving your brain?
That's kinda like saying "If Big Bubba wants to rape you, he will find a way to do it. So you might just as well buy some vaseline and some flowers, get a nice dress, go visit him, and bend over."
I think someone should leak this url to them.. 503 errors are not cool, you know? Especially for someone who tries to cultivate an image of skillz and 1337 (and probably bunnies, too)
Well.. Next best thing :
http://code.google.com/p/pyjamas/
Pyjamas provides a python-to-javascript Compiler and a Web Widget set, the combination of which allows developers to easily write well-designed desktop-like Rich Media Applications in python classes and modules that will execute in all major web browsers. without having to write a single line of javascript. Pyjamas is a port of Google Web Toolkit.
This is only a benefit if the resources are already cached locally anyway, so the browser could start loading a .png for instance while the main page html downloads. And there's cost not a benefit if the resource is already in memory. And browsers could do this anyway most of the time by just remembering what resources were used on a page even if the page itself is not cached. So this is an extremely marginal benefit at the cost of some complexity and bandwidth.
You assume here that 1. dynamic content are generated instantly, and 2. the server can saturate the bandwidth. Let's say it take 200 ms to generate the dynamic data. In the mean time, the browser can check if it has the newest JS version from my CDN, since it already know it will need it. Also, since my dynamic content is not on a CDN, it can't fully utilize your bandwidth, so while it's still waiting for the full HTML document, it uses the rest of the bandwidth to fetch some static files it already know it will need.
If multiple files are multiplexed then when the connection drops then multiple files have to be restarted in the middle instead of just one, and dynamically generated resources need to be redone from scratch. The only practical benefit to sending multiple files at once is that the browser could start processing them with just partial data (with an image header for instance it could allocate the memory for the image). This again is very marginal compared to the transfer time and also more complex.
How often does a TCP connection actually drop? Pretty rarely, even with some packet loss. Also, as you mentioned, headers. If the server sends the header of all the images first, it also knows what dimensions it should use in the layout, and can start on that much earlier.
So can pipelining (in general, not "HTTP pipelining"). Browser sends server a list of resource, it replies back sending whole files in smallest-first order for instance. The difference is that if you are sending whole files at once pipelined then you don't have to explicitly state priorities and have mechanism for setting and adjusting them so pipelining is less complex.
Ah, but as you yourself point out, HTTP pipelining can not. People have tried for a long time to get HTTP pipelining to work properly, but so far it's not the solution people are looking for.
So can SSL, which SPDY basically requires anyway because of proxies. Enable deflate compression over SSL and it compresses headers.
Ah, but SSL is crazy expensive(TM) because of the pipelining problems. you need multiple connections, and ssl negotiation is pretty slow.
HTTP is old. Very old in technology standard. It's pretty good too, and can be expanded. But it was designed for a completely different scenario than what we have today, and it have some fundamental limits (as pointed out quite a lot already).
a specific combination of super-popular website plus popular client software
Well, you're wrong on that part, at least. Chrome is happy to use SPDY protocol to all web servers, not just google's (verified by someone earlier in the thread, via https://github.com/donnerjack13589/node-spdy and chrome://net-internals/ ), and I'm sure google's servers are happy to serve content over SPDY to any browser that asks for it. There is a detailed draft around the protocol, and there's open source code out there implenting it (for example in chromium).
I see this as no different from, say, some browsers supporting webgl and audio/video tags before they're standardized. Or if apache added support for a new compression algorithm.
google.com (and apache - mod_spdy), chrome (and chromium - open source). Oh, and a draft paper detailing the protocol....
Lemme think... Nope, don't see the problem here.
Google is seriously making Chrome as fast as they can, on as many servers as they can. They're also seriously making Google pages as fast as they can, on as many browsers as they can.
It IS technical progress. And if your idea of when you should start putting out new tech / standards is when all support it, that's just silly. Nothing stops other browsers / servers from implenting it if they think it's an advantage.
This is, in my opinion, similar to when the img tag came to the web, or if you want to go further back, when cars started to replace horses. Progress happens. And it's backwards compatible, so no splintering.
And as for your last comment, that's just childish peevishness. Of course something that makes the general loading of pages 40% faster, will also make a subset of that page load faster. If you really see a problem / conspiracy in that, I think you might need to get your head checked.
If server "knows" that I "need" 2MB of flash ads to see the 40K html page, it would send them to me. IOW browser is out of control what server sends, browser can only discard the content which has wasted my bandwidth and isn't going to be displayed.
They can already do tricks like that, by sending you 2mb of inline javascript and SVG and base64 encoded content, and other goodie stuffs. Uncompressed, of course.
For static content, it is even worse: first time I visit the page it is cached and then a cached copy used. With SPDY, bandwidth is going to be always wasted for transferring the static content. Yes, I need it to display the page - but no, I have already local cached copy.
That's just a badly configured server. Just like today, when all the static content is with no-cache, expired 1970, and on same domain.
Sorry, mac. The web is already a scary place. SPDY will make some bandwidth abuse things easier (and give a speedup overall), but won't suddenly create new opportunities for Teh Evilz.
From what I can see, it's an open draft, so I don't see why no-one else can implent it. Maybe they should thank Google for doing the hard work (creating it, and putting it into a popular open source browser) instead.
Seriously, if people thought like you when the web was new, we'd never have a tag for displaying images, because that would be unfair for all the browsers and servers that didn't implent it.
Some tricks:
1. It can specify other needed files in header, so browser can start loading them before it gets the http page
2. It can send more than one file at a time. It can mux multiple files, while pipelining only allows you to transfer files one at a time.
3. It can prioritize some files over others.
4. It can compress the HTTP headers. Modern browsers send their life history, the weather outside, everything that have ever been installed on the computer, every language / encoding it can possibly use, cookies, referer, when it saw the content last, what the etag of that context was, and so on. Header compression can actually make a difference.
You should read the whitepaper at http://www.chromium.org/spdy/spdy-whitepaper - it's quite interesting.
Some quotes:
We downloaded 25 of the "top 100" websites over simulated home network connections, with 1% packet loss. We ran the downloads 10 times for each site, and calculated the average page load time for each site, and across all sites. The results show a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL), and 39% - 55% over SSL.
--------
Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers. On the lower-bandwidth DSL link, in which the upload link is only 375 Kbps, request header compression in particular, led to significant page load time improvements for certain sites (i.e. those that issued large number of resource requests). We found a reduction of 45 - 1142 ms in page load time simply due to header compression.
-------
We discovered that SPDY's latency savings increased proportionally with increases in packet loss rates, up to a 48% speedup at 2%. (The increases tapered off above the 2% loss rate, and completely disappeared above 2.5%. In the real world, packets loss rates are typically 1-2%, and RTTs average 50-100 ms in the U.S.)
Agreed. Perspectives is the best solution I've seen for this problem so far.
The only problem I see with it at the moment is either if
1. An attacker control all your internet access from before you install it
2. An attacker control the majority of the Perspectives servers.
But I don't see any of those as impassable problems. 1 can be solved by a trusted install (f.x. from a cdrom), and nr 2 can be solved by crowdsourcing (and some cleverness, like requiring the servers to be in different subnets / countries - thus really complicating things for an attacker).
But, as it threaten a current drug^H^H^H^Hbusiness cartel, and it won't make anyone rich, I doubt it will become a widely enough deployed standard.
What annoys me most is the "If we can't do it, noone can" attitude.
I remember one myth (some details might be slightly wrong here, been a while since I saw it) where a stewardess survived a plane crash by sitting strapped into her seat in the tailpart of the plane. They tried to reproduce it, failed, and then had to label it "plausible", because, well.. After some research, they found out it did actually happen, and was well documented. Before they found that, it was clearly in the "busted" bin.
What does that say about the rest of the tests they do? Not much, admittedly, but it at least gives one case where they got the wrong conclusion.
I like the show a lot, but mostly for entertainment value. I generally find some annoyances regarding their "scientific" testing around every 2-3 episodes. Which, for me, makes it hard to take the show seriously :)
Thanks for the UPDATE; Better to know than to speculate, even if it shows that my speculations were wrong :)
SQL injection? This sounds like people not sanitizing OUTPUT values, also known as XSS.
It's talk about redirect, and I would guess that's via some JS that gets displayed.
I see a script src="url" tag in the screenshot, which further lends credit to that theory.
However, other than the article text, I can't see any evidence of a SQL injection attack, which is a different kettle of fish than XSS.
The researchers also noted that some iTunes URLs have been injected with the script, but that Apple has done a good job in securing the site against this kind of attacks.
"The way iTunes works is that it downloads RSS/XML feeds from the publisher to update the podcast and list of available episodes. We believe that these RSS/XML feeds have been compromised with the injected code. The good thing is that iTunes encodes the script tags, which means that the script doesn't execute on the user's computer," they explained.
Sounds like XSS
But, but, but.... You hate us for our freedom! And will stop at nothing to steal that freedom for yourselves! That's what [silly media person] told me, and he wouldn't lie!
So, let me get this straight..
You suggest that everyone should stop their work on anything that can be linked to linux in any way, until Adobe fixes their piece of crap?
Basically, you're advocating the death penalty for a jaywalking ticket.
Actually, you'd be ticketing person B for the jaywalking of person A, because person B didn't stop him. Never mind that person B was around the street corner and didn't even see the jaywalker.
Elseif Country = "USA":
Then Pr^CHello, this is agent Smith. For your own safety, please stop visiting these terrorist sites. This is your first and only warning.
Taking bets, when to see the first riots "A la Tunisia" starting?
The class was learning about some revolt in which some peasants had wanted to stop being peasants and, since the nobles had won, had stopped being peasants really quickly.
- Terry Pratchett, Soul Music
I have modpoints avaliable roughly 50% of the time..
But I almost never use them (Only if I see something very good with low rating), and I never meta-moderate.
Since I still use the old comment layout still, its kinda pain in the ass, since you have to scroll all the way to the bottom to click on the "Moderate" button (and if I don't do it rightaway, I forget it)
Just click on "Download Torrent" in the upper right corner, and a dropdown will appear that holds all the releases in various formats.
And if that's too complex, here are the direct links for 720p:
http://vodo.net/assets/torrents/Pioneer.One.S01E01.REDUX.720p.x264-VODO.torrent
http://vodo.net/assets/torrents/Pioneer.One.S01E02.720p.x264-VODO.torrent
That allows them to sell the power some other place where prices are higher then turn around and demand higher prices locally too because reserves are low.
That sounds awfully familiar.. Let me guess, you're from Norway, too? :D
Thank you for pointing out that you're clueless and can't be seen as a valid source of security information.
Now, if you were wondering what I'm talking about, there was a slashdot article on it some time ago and all, and you've been telling everyone how stupid those linux folks are, and so on?
Well, no distribution I know of have autorun. No, not even Ubuntu. What the article were talking about were a flaw in gnome's program for making image thumbnails (which he then put on an usb disk, which made bad things happen when he opened the disk and thumbs were created). He was also talking about a potential flaw in the code that handles new USB devices being plugged in (Like asking for usb id, type, and so on), and mounted (for example, flaws in file system code)
And now that you've gotten some actual info about it, I bet that you'll promptly forget it, because it does not fit in your narrow world view.
(and if I seem to be a bit too snarky, its been a crap week at work. And you were the lucky clueless one)
if particles in the LHC are sent back in time, does this mean that you can set things up such that a particle collides with multiple instances of itself? If so, when does the energy get released from the collision?
December 21, 2012 - with terrible results. There was one lone man that was sent back in time, to warn the world. However, due to the wild time forces, he was sent far back in time, to around 3000 BC.
Wait, what? Go without what? Principles?
He says that out of principle, he will continue to use his PS3 for what he bought it for, in spite of what Sony thinks (and for him to do that, he *have* to get a pirate copy. He tried a legitimate copy, but that refuse to run).
And then you say the true measure of one's principle is not to follow one's principle...
I have to ask you : Are you really that retarded, or did you just copy/paste some standard mantra without involving your brain?
That's kinda like saying "If Big Bubba wants to rape you, he will find a way to do it. So you might just as well buy some vaseline and some flowers, get a nice dress, go visit him, and bend over."
I think someone should leak this url to them.. 503 errors are not cool, you know? Especially for someone who tries to cultivate an image of skillz and 1337 (and probably bunnies, too)