Vote-by-mail is a secure, effective, and practical voting method, and is virtually immune to the sorts of systemic fraud that plague electronic voting.
Wrong. It's vulnerable to systemic fraud in the counting. If you infiltrate the post office or the election office you can easily alter the results in volume.
When you have a polling location you can verify the box is empty, observe people placing votes into it, and observe the counting. You observe every step in the process to get your poll's final tally, and when the results are posted with a breakdown by polling location you can verify that it was added correctly to the total. All you need is a few trusted people per polling location and you can trust the results.
But in vote-by-mail the only part you observe is casting your own vote. You can't say that a 'household tyrant' didn't vote for others -or- that systemic fraud didn't occur in the post or in the tally. It's better than internet voting could ever be since the unobservable parts (post office, elections office) are harder to corrupt and get away with it, but it's still unacceptable for running fair elections.
"Historically, a device required moving parts to classify as a machine; however, the advent of electronics technology has led to the development of devices without moving parts that many refer to as machines, such as a computer, radio, and television." --The American Heritage Dictionary, 1985
You are living 30 years in the past if you think "machine" has to be some physical device with gears and cogs. You would rather go from straw men to arguing semantics than actually come up with an argument against software patents. Why do you think that is?
Software is a creative work and it is also a machine -- it does something. It transforms scene data into a Pixar movie, or translates a book into another language, or controls other machines to assemble cars, shape metal, or do anything else.
A book or movie is a creative work, but that's all. It doesn't do anything. It isn't a machine.
Being something and doing something are not the same thing. Being something is protected by copyright, doing something is protected by patents. Software does something and should be protected by patents.
Lets just say the concept of wars in space was patented so no one could write a book about wars in space... Do you write software? would you like your code to become subject to trivial patents that claim wholesale ownership of your code?
Did you ever wonder why you can't come up with a real argument against software patents that doesn't rely on straw men?
Basically in a dynamically typed language like JavaScript every property access, function call, or any other thing that can be changed dynamically could be changed at runtime by another thread. So you need locking for every method call, property access, etc to make sure it isn't changed by another thread while it's accessed in another.
There are some generally fast locking algorithms for when locks are used mostly by the same thread... for instance in Java locks can be owned by a thread and that thread never has to lock or unlock at all, but instead it periodically checks if another thread has written a flag saying it wants to become the owner, then there is synchronization to pass off ownership. This works ok for Java, where there are fewer things that can change at runtime and they are explicitly listed out (using 'synchronized'), but in a dynamic language it's usually just too much overhead.
Just for comparison V8 is even more extremely single-threaded, with execution that can only be interrupted at some certain points in the JS code.
You would have a point if Google gave something up, but they still display a massive ad for Chrome on their start page (roughly the same size as the Google logo) and other properties, and a sponsored ad for 'browser', and top results for 'chrome' and 'browser' still have Chrome listed through wikipedia and other second hand sources.
How many people do you think manage to get past the huge logo-sized ad, the banner ads, and the 2nd hand sites without reading about Chrome or being able to download it? If you give up something worthless to you, it shows nothing about your integrity.
It's amazing to me to what extremes people can go to justify their tribes. Here we have college educated people who's job it is to show the differences in the products not being able to recognize their own product. If these people can't tell the difference from a reasonable distance then the general public 10' away in Starbucks sure the hell isn't going to.
It's patently obvious (har har) that Samsung set out to clone iPad, the packaging, the icons, the charger, the IO port, etc. They're going to lose these cloning suits and for good reason.
It's sad that Microsoft is now one of the more morally upstanding corporations (by comparison only) in the industry. At least they create things and with Zune, WP7, etc they do it their own unique way instead of just blindly copying like Google (copying the OS) and Samsung (copying the product).
Some measurements of PC emulator on FF, Chrome on i7.
Though even the Javascript PC emulator http://bellard.org/jslinux loads the Linux kernel pretty much equally fast on both.
It depends... comparing nightly to dev channel:
# x=1; while [[ $x -lt 1000]; do x=$((x+1)); done
Chrome: 2 seconds Firefox: 20 seconds
# time gzip </bin/zcat >/dev/null
Chrome: 206 seconds Firefox: 102 seconds
# find /
Chrome: 11 seconds Firefox: 6.5 seconds
# for x in/bin/*; do $x --help; done 2>/dev/null >&2
Chrome: 12 seconds Firefox: 5.5 seconds
Looks like whatever busybox is doing for the shell is fantastically slow in Firefox, but pretty much everything else I tried was about twice as fast. No wonder Google wants everybody to move to Dart, huh?
Chrome is advertised extensively on all Google properties, but you don't see the ads as a Firefox user because they don't want to tarnish their image with happy Firefox users. Chrome is advertised on TV and the web. Advertising works, that's how Google rakes in the profit.
Can anybody help me out? I'm not trolling here, I seriously want to know what Chrome has over FF.
There's not really any reason to use Chrome over Firefox any more, but many reasons to use Firefox over Chrome (customization, open previous session as it was, better extensions, better rendering, etc).
Interesting. I've been using Firefox nightly for a while now and it seems better than or equal to Chrome in most ways. Plus it's fully open source.
As far as performance goes Javascript in Nightly is on par (+/- a few % on Kracken) with dev channel Chrome, compositing is faster, the garbage collector is better (fewer pauses, less overhead). I don't notice the UI lagging like in older versions. You can have as many tabs open as you want.
As far as features, Nightly has an option to force add-on compatibility and I've yet to have any add-ons fail to work or cause problems. Then you have a noscript that always works, esc to stop animated gifs, view -> style -> no style, customized UI (for minimal UI on netbook), and all those other nice things about Firefox that you can live without but shouldn't have to.
There's no doubt Chrome is winning the popularity contest and at one time it was much faster, but as far as merit goes it just doesn't seem to offer that much anymore.
They only complain about man-made electromagnetic fields. The Earth has this HUGE magnetic field, maybe you've heard of it.
There is a HUGE amount of noise in the world, yet with an annoy-o-tron in your office it's just a tiny man-made noise that drives you batty.
In addition, every single study done so far has shown that when you tell these people that you turned off the source of EM they think is the cause of their problem, they get better.
When I tell you I removed the annoy-o-tron(s) from your office you feel better right away, if you believe me. You also can't tell me reliably if I actually removed them or not (at least not unless they go off again), or how many are hidden in your office and around your home. Maybe they are just in your imagination, unlike that spider in your hair.
I just shot down your argument. Whether these people are actually affected by radio waves or not is a different matter, but you reasoning is not valid.
I would like to phrase it "and nobody in 96 years had this problem."
Since there is a 2.5mm plug clearly people did have this problem before, so you would rephrase it as something simply wrong. Why would one ever use a 2.5mm plug if there was space for a 3.5mm one? It doesn't even need rebutting with counter-examples it's so patently absurd of an idea.
The fact is that this is one of those inventions that takes creativity to come up with, but seems pretty obvious after the fact. A headphone jack that's half the size and is both forward and backward compatible with the existing headphones is freaking awesome. Props to Apple engineers.
And there's your incentive for inventing. Either invent new awesome things (Apple) or get blocked from the market for using other people's inventions (Samsung) or buy other people's work and use that as leverage so you can license the inventions you need (Google).
Invent, pay up, or get out. Patents are a proven solution to furthering progress in the useful arts.
This invention halves the size of the jack, is compatible with all existing devices, and is less likely to break the device (pull on the headphone just pulls it away from the magnet instead of yanking the whole device). And nobody in 96 years thought of this solution.
This is exactly what patents are for. Rewarding the people that spend their dollars on research to improve things. It's a small but innovative idea, and gives Apple a small advantage over competitors. Stop eating the sour grapes and start inventing.
You're celebrating a company that profits from other people's creative works (original content), time and attention (advertising), and inventions. You cheered when google, a company without actual inventions themselves to speak of, complained about the patent system protecting inventors. And you cheered when they essentially bribed the system by buying other people's works; they payed ill-gotten money to make their patent abuse problem go away.
Google is a parasite. Objectively looking at Google's behavior it's one of the more evil, corrosive companies in the tech sector, so why do you celebrate them?
The entire purpose of patents is to block out competitors by securing to inventors exclusive rights over their inventions. Who would invest the money to invent if somebody else can just copy it and not have years of debt to pay off?
And for that matter software patents are good and they encourage innovation. Software is not math, it's a machine. Inventing a new sorting algorithm is no different from inventing a new physical sorting process except it's simulated by a computer. What's really the matter is just obvious patents, absurd patents like 'one click', and all the ones with clear prior art that are granted anyway.
Apple has done a huge amount of research and inventing in many areas and deserves to get advantage from it. The position of the defenders of Android is that blatant copying is okay, making them part of the anti-intellectual crowd that doesn't value ideas and creativity.
Only technically could one argue that Dalvik is "not Java". It isn't exactly the same and doesn't run Java code, not exactly.
But there's nobody technical that can say with good conscience that Dalvik is not simply a blatant copy of the JVM, changed just enough to maybe get around some patents. The byte code is exactly what you would expect from a straight converting of Java bytecode to a register format and the application format is just a bunch of Java class files merged together so there's less redundant strings and such. The basic semantics are entirely the same as Java.
Ultimately what it comes down to is that Google purposely and blatantly worked to get around some patents they considered bogus, creating an incompatible version of Java -- objectively there's simply no denying this. The question is then over whether you feel they were justified to do this or not. The people insisting so loudly that 'Dalvik is not Java' are those that feel that creating an incompatible Java is 'wrong'... but they still want it in their phone.
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.
If there was an HTTP "RESOURCES" request to go along with GET and HEAD that did the same thing then the browser could send that along with a GET on opening the connection and you would have the same benefit, with the extra benefit of being able to query this information independently from requesting the content.
In any case, if the browser already has it cached then you gain nothing in terms of page loading speed (the browser could speculatively load it anyway) and you can tell the browser to cache these kinds of things for a long time by versioning the URL when they have to change.
So occasionally the browser can start loading a resource sooner than the main page is ready and unless all resources fit into this category (page load being held up by those that aren't known on initial GET) then it on average only reduces the page load time by some factor of the bandwidth for that resource. Not worth it.
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.
I think HTTP pipelining is actually the solution people are looking for. The problem is just that it isn't supported well.
If you take a close look at the SPDY performance numbers on their whitepaper, you'll see that they don't compare it to HTTP pipelining even though the test is conducted with a server and client they control that both support pipelining. The reason? They don't want to say "use SPDY it's 3% faster at loading pages than HTTP pipelining" (made up number).
Further you'll see that they don't compare SPDY over SSL with HTTP over SSL. The reason? They don't want to say that "SPDY w/GZIP compression over SSL sends 2% less data than HTTP over SSL w/DEFLATE compression".
The whole thing is obviously such a sham. They have some other reason for pushing SPDY, maybe just to do it, but whatever it is it's certainly not evidence-based.
Once again thank you for taking the time to answer my questions. I wish the answers, in general, were something more substantial than just 'we're Google trust us we're smart durr', since that's essentially what you've written here, for instance:
There is external research on this topic. Feel free to look it up as we did.
I expect somebody who is pushing a new protocol based on published research to be able to at least cite their sources. Even on the web the only research identified are two powerpoint presentations by the same guy, with no review. Frankly, even just based off the fact that you stand behind performance numbers that come from a non- state of the art (even at the time) HTTP stack makes me seriously doubt the quality of research that went into this new protocol.
I don't see any serious response to why the problems in HTTP couldn't just be fixed in the standard instead of being papered-over. I suppose this means unstated is that w3 is too slow or too busy wasting time with RDF and 'semantic web' to improve the spec, so you have no choice but to bypass standards. In any case I would encourage you to collect actual evidence for the need for SPDY and also to at least try alternatives that modify HTTP itself.
1. It can specify other needed files in header, so browser can start loading them before it gets the http page
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.
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.
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.
3. It can prioritize some files over others.
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.
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.
So can SSL, which SPDY basically requires anyway because of proxies. Enable deflate compression over SSL and it compresses headers.
It's really not that interesting. They make a lot of claims without sources or any support whatsoever and won't answer questions about it, for instance see threads here or on reddit where google employees post about SPDY (ie are reading the thread) but won't answer questions about methods and sources or defend their theories.
The problem that SPDY is supposed to solve in it's overly complicated way has a simple solution: tweak HTTP pipelining so that the server can respond in any order it wants to. Then servers can send resources when they are available, in smallest-first order, or whatever and the pipeline doesn't block on ad.doubleclick.net (it's just sent last when it is finally finished profiling you). That's all there is to it. The HTTP designers didn't do it because they didn't want to go far enough with changes, instead just tacking pipelining on almost as an afterthought. Maybe Google invented SPDY because they are afraid of tweaking HTTP or think standards move too slowly? I don't know, all I know is that SPDY is bad news.
Since we've got it direct from the horse's mouth -
- Why server push? Nobody seems to think it's a good idea and it makes things more complicated for everybody involved, including proxies. What is the rationale for this feature.
- Why did you name it "SPDY" to show "how compression can help improve speed" when SSL already supports compression?
- In the performance measurements in the whitepaper, what HTTP client did you use and what multiple connection multiplexing method was used if any? How were the results for HTTP obtained? For instance the whitepaper says an HTTP client using 4 connections per domain "would take roughly 5 RTs" to fetch 20 resources, implying theory math. Were situations like 10 small requests finishing in the time it takes to transfer 1 large request taken into account? (ie in practice multiple requests can be made without increasing total page load time)
- The main supposed benefit seems to be requesting more than one resource at once. Then a request could stall the connection while being processed (ie doubleclick ad) and hold up everything after it, so then you add multiplexing, priorities, canceling requests, and all that complication. Why not just send a list of resources and have the server respond back in whatever order they are available? This provides the same bandwidth and latency with superior fault handling (if the connection closes the browser has only one resource partially transferred instead of several).
- The FAQ kind of reluctantly admits that HTTP pipelining basically has the same benefits in theory as SPDY except if a resource takes a while and holds up the remaining ones. So what benefit would SPDY have over just fixing pipelining so that the server can respond in whatever order it chooses? The only real problem with HTTP tunneling is fixed-order and bad implementations (ie IIS), correct?
Barring really good explanations it looks to me like SPDY is just very complicated and increases speed basically as a side-effect of solving other imaginary problems.
And what we gain is compressed HTTP headers and a requirement to support multiple requests, and multiple streams.
Actually you don't even gain compressed headers. Since SPDY (which is a made up initialism just to be "cute") uses SSL to bypass proxies you could already compress with deflate or whatever else people want to standardize on.
I would much rather like to see anything based on SCTP.
And why hasn't SCTP caught on? Because like SPDY it doesn't solve an actual problem people have.
once either side gets a good win (Like IE 5-6 did) then that is where the trouble gets in where the winner separates from the standard and forces its own standards.
Then I'd be most worried about Chrome. IE can only affect the Windows market, which is not even assured will be relevant in the not-so-distant future. Mozilla has a history of open processes and backward compatibility, for instance there was huge debate and rationale before switching to the awesome bar and you can make it 'less awesome' if you want to. Chrome on the other hand is already including custom junk like native client, SPDY (which is a crappy protocol btw), and like gnome they change the UI on a whim because they feel like it not because of user testing and discussion. Also there's no easy way to use a particular version of chrome and Google advocates a 'rolling standard' for HTML (another thing that's rolling is a treadmill).
RealD Cinema... gives up to two planes of vision at a time
No it gives two projections of vision at a time, one for each eye... just like your eyes get from the rest of the world (each eye only sees 2d of course). It can be as 3d as actually being there, except that you cannot change the focus; your eyes always should always be focused on the screen regardless of what is projected. This causes eye strain and perception problems for some people.
ReadD does have some problems... mostly people who can perceive at 72 Hz or greater will see some flickering, and with movies made from 24 fps source frames are repeated three times (per eye) so people with fast perception will see some stuttering; frames are flashed in sequence 1 1 1 2 2 2 3 3 3..., so if you can perceive individual frames then you'll see action frozen for two frames out of three.
But yeah, if you are only seeing two planes in a movie like Avatar made from 3d source then your brain is not processing correctly (ie you have some visual perception problem). You may in fact not be perceiving the actual world in 3d as other do. I wouldn't expect you to see anything in those random noise pictures where you cross your eyes for instance.
Slashdot Mirror
Vote-by-mail is a secure, effective, and practical voting method, and is virtually immune to the sorts of systemic fraud that plague electronic voting.
Wrong. It's vulnerable to systemic fraud in the counting. If you infiltrate the post office or the election office you can easily alter the results in volume.
When you have a polling location you can verify the box is empty, observe people placing votes into it, and observe the counting. You observe every step in the process to get your poll's final tally, and when the results are posted with a breakdown by polling location you can verify that it was added correctly to the total. All you need is a few trusted people per polling location and you can trust the results.
But in vote-by-mail the only part you observe is casting your own vote. You can't say that a 'household tyrant' didn't vote for others -or- that systemic fraud didn't occur in the post or in the tally. It's better than internet voting could ever be since the unobservable parts (post office, elections office) are harder to corrupt and get away with it, but it's still unacceptable for running fair elections.
"Historically, a device required moving parts to classify as a machine; however, the advent of electronics technology has led to the development of devices without moving parts that many refer to as machines, such as a computer, radio, and television." --The American Heritage Dictionary, 1985
You are living 30 years in the past if you think "machine" has to be some physical device with gears and cogs. You would rather go from straw men to arguing semantics than actually come up with an argument against software patents. Why do you think that is?
Software is a creative work and it is also a machine -- it does something. It transforms scene data into a Pixar movie, or translates a book into another language, or controls other machines to assemble cars, shape metal, or do anything else.
A book or movie is a creative work, but that's all. It doesn't do anything. It isn't a machine.
Being something and doing something are not the same thing. Being something is protected by copyright, doing something is protected by patents. Software does something and should be protected by patents.
Lets just say the concept of wars in space was patented so no one could write a book about wars in space ... Do you write software? would you like your code to become subject to trivial patents that claim wholesale ownership of your code?
Did you ever wonder why you can't come up with a real argument against software patents that doesn't rely on straw men?
I believe what they are talking about is "The Man" in the middle attack not a man-in-the-middle attack.
Basically in a dynamically typed language like JavaScript every property access, function call, or any other thing that can be changed dynamically could be changed at runtime by another thread. So you need locking for every method call, property access, etc to make sure it isn't changed by another thread while it's accessed in another.
There are some generally fast locking algorithms for when locks are used mostly by the same thread... for instance in Java locks can be owned by a thread and that thread never has to lock or unlock at all, but instead it periodically checks if another thread has written a flag saying it wants to become the owner, then there is synchronization to pass off ownership. This works ok for Java, where there are fewer things that can change at runtime and they are explicitly listed out (using 'synchronized'), but in a dynamic language it's usually just too much overhead.
Just for comparison V8 is even more extremely single-threaded, with execution that can only be interrupted at some certain points in the JS code.
You would have a point if Google gave something up, but they still display a massive ad for Chrome on their start page (roughly the same size as the Google logo) and other properties, and a sponsored ad for 'browser', and top results for 'chrome' and 'browser' still have Chrome listed through wikipedia and other second hand sources.
How many people do you think manage to get past the huge logo-sized ad, the banner ads, and the 2nd hand sites without reading about Chrome or being able to download it? If you give up something worthless to you, it shows nothing about your integrity.
It's amazing to me to what extremes people can go to justify their tribes. Here we have college educated people who's job it is to show the differences in the products not being able to recognize their own product. If these people can't tell the difference from a reasonable distance then the general public 10' away in Starbucks sure the hell isn't going to.
It's patently obvious (har har) that Samsung set out to clone iPad, the packaging, the icons, the charger, the IO port, etc. They're going to lose these cloning suits and for good reason.
It's sad that Microsoft is now one of the more morally upstanding corporations (by comparison only) in the industry. At least they create things and with Zune, WP7, etc they do it their own unique way instead of just blindly copying like Google (copying the OS) and Samsung (copying the product).
Some measurements of PC emulator on FF, Chrome on i7.
Though even the Javascript PC emulator http://bellard.org/jslinux loads the Linux kernel pretty much equally fast on both.
It depends... comparing nightly to dev channel:
# x=1; while [[ $x -lt 1000]; do x=$((x+1)); done
Chrome: 2 seconds
Firefox: 20 seconds
# time gzip < /bin/zcat > /dev/null
Chrome: 206 seconds
Firefox: 102 seconds
# find /
Chrome: 11 seconds
Firefox: 6.5 seconds
# for x in /bin/*; do $x --help; done 2>/dev/null >&2
Chrome: 12 seconds
Firefox: 5.5 seconds
Looks like whatever busybox is doing for the shell is fantastically slow in Firefox, but pretty much everything else I tried was about twice as fast. No wonder Google wants everybody to move to Dart, huh?
Chrome is advertised extensively on all Google properties, but you don't see the ads as a Firefox user because they don't want to tarnish their image with happy Firefox users. Chrome is advertised on TV and the web. Advertising works, that's how Google rakes in the profit.
Can anybody help me out? I'm not trolling here, I seriously want to know what Chrome has over FF.
There's not really any reason to use Chrome over Firefox any more, but many reasons to use Firefox over Chrome (customization, open previous session as it was, better extensions, better rendering, etc).
Interesting. I've been using Firefox nightly for a while now and it seems better than or equal to Chrome in most ways. Plus it's fully open source.
As far as performance goes Javascript in Nightly is on par (+/- a few % on Kracken) with dev channel Chrome, compositing is faster, the garbage collector is better (fewer pauses, less overhead). I don't notice the UI lagging like in older versions. You can have as many tabs open as you want.
As far as features, Nightly has an option to force add-on compatibility and I've yet to have any add-ons fail to work or cause problems. Then you have a noscript that always works, esc to stop animated gifs, view -> style -> no style, customized UI (for minimal UI on netbook), and all those other nice things about Firefox that you can live without but shouldn't have to.
There's no doubt Chrome is winning the popularity contest and at one time it was much faster, but as far as merit goes it just doesn't seem to offer that much anymore.
They only complain about man-made electromagnetic fields. The Earth has this HUGE magnetic field, maybe you've heard of it.
There is a HUGE amount of noise in the world, yet with an annoy-o-tron in your office it's just a tiny man-made noise that drives you batty.
In addition, every single study done so far has shown that when you tell these people that you turned off the source of EM they think is the cause of their problem, they get better.
When I tell you I removed the annoy-o-tron(s) from your office you feel better right away, if you believe me. You also can't tell me reliably if I actually removed them or not (at least not unless they go off again), or how many are hidden in your office and around your home. Maybe they are just in your imagination, unlike that spider in your hair.
I just shot down your argument. Whether these people are actually affected by radio waves or not is a different matter, but you reasoning is not valid.
I would like to phrase it "and nobody in 96 years had this problem."
Since there is a 2.5mm plug clearly people did have this problem before, so you would rephrase it as something simply wrong. Why would one ever use a 2.5mm plug if there was space for a 3.5mm one? It doesn't even need rebutting with counter-examples it's so patently absurd of an idea.
The fact is that this is one of those inventions that takes creativity to come up with, but seems pretty obvious after the fact. A headphone jack that's half the size and is both forward and backward compatible with the existing headphones is freaking awesome. Props to Apple engineers.
[some random straw men]
And there's your incentive for inventing. Either invent new awesome things (Apple) or get blocked from the market for using other people's inventions (Samsung) or buy other people's work and use that as leverage so you can license the inventions you need (Google).
Invent, pay up, or get out. Patents are a proven solution to furthering progress in the useful arts.
This invention halves the size of the jack, is compatible with all existing devices, and is less likely to break the device (pull on the headphone just pulls it away from the magnet instead of yanking the whole device). And nobody in 96 years thought of this solution.
This is exactly what patents are for. Rewarding the people that spend their dollars on research to improve things. It's a small but innovative idea, and gives Apple a small advantage over competitors. Stop eating the sour grapes and start inventing.
You're celebrating a company that profits from other people's creative works (original content), time and attention (advertising), and inventions. You cheered when google, a company without actual inventions themselves to speak of, complained about the patent system protecting inventors. And you cheered when they essentially bribed the system by buying other people's works; they payed ill-gotten money to make their patent abuse problem go away.
Google is a parasite. Objectively looking at Google's behavior it's one of the more evil, corrosive companies in the tech sector, so why do you celebrate them?
The entire purpose of patents is to block out competitors by securing to inventors exclusive rights over their inventions. Who would invest the money to invent if somebody else can just copy it and not have years of debt to pay off?
And for that matter software patents are good and they encourage innovation. Software is not math, it's a machine. Inventing a new sorting algorithm is no different from inventing a new physical sorting process except it's simulated by a computer. What's really the matter is just obvious patents, absurd patents like 'one click', and all the ones with clear prior art that are granted anyway.
Apple has done a huge amount of research and inventing in many areas and deserves to get advantage from it. The position of the defenders of Android is that blatant copying is okay, making them part of the anti-intellectual crowd that doesn't value ideas and creativity.
Only technically could one argue that Dalvik is "not Java". It isn't exactly the same and doesn't run Java code, not exactly.
But there's nobody technical that can say with good conscience that Dalvik is not simply a blatant copy of the JVM, changed just enough to maybe get around some patents. The byte code is exactly what you would expect from a straight converting of Java bytecode to a register format and the application format is just a bunch of Java class files merged together so there's less redundant strings and such. The basic semantics are entirely the same as Java.
Ultimately what it comes down to is that Google purposely and blatantly worked to get around some patents they considered bogus, creating an incompatible version of Java -- objectively there's simply no denying this. The question is then over whether you feel they were justified to do this or not. The people insisting so loudly that 'Dalvik is not Java' are those that feel that creating an incompatible Java is 'wrong'... but they still want it in their phone.
I still think ++C++ would be better... the problem with C++ was always that they put the C stuff off to one side.
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.
If there was an HTTP "RESOURCES" request to go along with GET and HEAD that did the same thing then the browser could send that along with a GET on opening the connection and you would have the same benefit, with the extra benefit of being able to query this information independently from requesting the content.
In any case, if the browser already has it cached then you gain nothing in terms of page loading speed (the browser could speculatively load it anyway) and you can tell the browser to cache these kinds of things for a long time by versioning the URL when they have to change.
So occasionally the browser can start loading a resource sooner than the main page is ready and unless all resources fit into this category (page load being held up by those that aren't known on initial GET) then it on average only reduces the page load time by some factor of the bandwidth for that resource. Not worth it.
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.
I think HTTP pipelining is actually the solution people are looking for. The problem is just that it isn't supported well.
If you take a close look at the SPDY performance numbers on their whitepaper, you'll see that they don't compare it to HTTP pipelining even though the test is conducted with a server and client they control that both support pipelining. The reason? They don't want to say "use SPDY it's 3% faster at loading pages than HTTP pipelining" (made up number).
Further you'll see that they don't compare SPDY over SSL with HTTP over SSL. The reason? They don't want to say that "SPDY w/GZIP compression over SSL sends 2% less data than HTTP over SSL w/DEFLATE compression".
The whole thing is obviously such a sham. They have some other reason for pushing SPDY, maybe just to do it, but whatever it is it's certainly not evidence-based.
Once again thank you for taking the time to answer my questions. I wish the answers, in general, were something more substantial than just 'we're Google trust us we're smart durr', since that's essentially what you've written here, for instance:
There is external research on this topic. Feel free to look it up as we did.
I expect somebody who is pushing a new protocol based on published research to be able to at least cite their sources. Even on the web the only research identified are two powerpoint presentations by the same guy, with no review. Frankly, even just based off the fact that you stand behind performance numbers that come from a non- state of the art (even at the time) HTTP stack makes me seriously doubt the quality of research that went into this new protocol.
I don't see any serious response to why the problems in HTTP couldn't just be fixed in the standard instead of being papered-over. I suppose this means unstated is that w3 is too slow or too busy wasting time with RDF and 'semantic web' to improve the spec, so you have no choice but to bypass standards. In any case I would encourage you to collect actual evidence for the need for SPDY and also to at least try alternatives that modify HTTP itself.
1. It can specify other needed files in header, so browser can start loading them before it gets the http page
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.
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.
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.
3. It can prioritize some files over others.
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.
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.
So can SSL, which SPDY basically requires anyway because of proxies. Enable deflate compression over SSL and it compresses headers.
You should read the whitepaper at http://www.chromium.org/spdy/spdy-whitepaper [chromium.org] - it's quite interesting.
It's really not that interesting. They make a lot of claims without sources or any support whatsoever and won't answer questions about it, for instance see threads here or on reddit where google employees post about SPDY (ie are reading the thread) but won't answer questions about methods and sources or defend their theories.
The problem that SPDY is supposed to solve in it's overly complicated way has a simple solution: tweak HTTP pipelining so that the server can respond in any order it wants to. Then servers can send resources when they are available, in smallest-first order, or whatever and the pipeline doesn't block on ad.doubleclick.net (it's just sent last when it is finally finished profiling you). That's all there is to it. The HTTP designers didn't do it because they didn't want to go far enough with changes, instead just tacking pipelining on almost as an afterthought. Maybe Google invented SPDY because they are afraid of tweaking HTTP or think standards move too slowly? I don't know, all I know is that SPDY is bad news.
Since we've got it direct from the horse's mouth -
- Why server push? Nobody seems to think it's a good idea and it makes things more complicated for everybody involved, including proxies. What is the rationale for this feature.
- Why did you name it "SPDY" to show "how compression can help improve speed" when SSL already supports compression?
- In the performance measurements in the whitepaper, what HTTP client did you use and what multiple connection multiplexing method was used if any? How were the results for HTTP obtained? For instance the whitepaper says an HTTP client using 4 connections per domain "would take roughly 5 RTs" to fetch 20 resources, implying theory math. Were situations like 10 small requests finishing in the time it takes to transfer 1 large request taken into account? (ie in practice multiple requests can be made without increasing total page load time)
- The main supposed benefit seems to be requesting more than one resource at once. Then a request could stall the connection while being processed (ie doubleclick ad) and hold up everything after it, so then you add multiplexing, priorities, canceling requests, and all that complication. Why not just send a list of resources and have the server respond back in whatever order they are available? This provides the same bandwidth and latency with superior fault handling (if the connection closes the browser has only one resource partially transferred instead of several).
- The FAQ kind of reluctantly admits that HTTP pipelining basically has the same benefits in theory as SPDY except if a resource takes a while and holds up the remaining ones. So what benefit would SPDY have over just fixing pipelining so that the server can respond in whatever order it chooses? The only real problem with HTTP tunneling is fixed-order and bad implementations (ie IIS), correct?
Barring really good explanations it looks to me like SPDY is just very complicated and increases speed basically as a side-effect of solving other imaginary problems.
Actually you don't even gain compressed headers. Since SPDY (which is a made up initialism just to be "cute") uses SSL to bypass proxies you could already compress with deflate or whatever else people want to standardize on.
And why hasn't SCTP caught on? Because like SPDY it doesn't solve an actual problem people have.
once either side gets a good win (Like IE 5-6 did) then that is where the trouble gets in where the winner separates from the standard and forces its own standards.
Then I'd be most worried about Chrome. IE can only affect the Windows market, which is not even assured will be relevant in the not-so-distant future. Mozilla has a history of open processes and backward compatibility, for instance there was huge debate and rationale before switching to the awesome bar and you can make it 'less awesome' if you want to. Chrome on the other hand is already including custom junk like native client, SPDY (which is a crappy protocol btw), and like gnome they change the UI on a whim because they feel like it not because of user testing and discussion. Also there's no easy way to use a particular version of chrome and Google advocates a 'rolling standard' for HTML (another thing that's rolling is a treadmill).
RealD Cinema ... gives up to two planes of vision at a time
No it gives two projections of vision at a time, one for each eye... just like your eyes get from the rest of the world (each eye only sees 2d of course). It can be as 3d as actually being there, except that you cannot change the focus; your eyes always should always be focused on the screen regardless of what is projected. This causes eye strain and perception problems for some people.
ReadD does have some problems... mostly people who can perceive at 72 Hz or greater will see some flickering, and with movies made from 24 fps source frames are repeated three times (per eye) so people with fast perception will see some stuttering; frames are flashed in sequence 1 1 1 2 2 2 3 3 3..., so if you can perceive individual frames then you'll see action frozen for two frames out of three.
But yeah, if you are only seeing two planes in a movie like Avatar made from 3d source then your brain is not processing correctly (ie you have some visual perception problem). You may in fact not be perceiving the actual world in 3d as other do. I wouldn't expect you to see anything in those random noise pictures where you cross your eyes for instance.