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.

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.

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.

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.

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.

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.

I still think ++C++ would be better... the problem with C++ was always that they put the C stuff off to one side.

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.

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:

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.

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.

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.

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.

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.