But do we know that this is specific to Google? MS could just be watching anything that people type in their browsers, and then the web sites they end up at.
I hate to say it, but javascript and canvas are disappointingly slow. XaoS is dozens of times faster than this, and while I'm sure a lot of it is to do with specific fractal optimisations, surely a significant factor is the slowness of pixel operations and drawing images.
I'm writing an HTML5 game, and simply drawing an image that fills the screen (with no resampling) brings you down to about 50 fps. A few more small images, some resizing later and I'm into the 30 fps realm, and that's on a really fast computer using Chrome.
So does PLoS One. In fact most journals allow you to pay $2k or so to make your article open access. PLoS One hasn't fixed the system at all, and neither will this.
I would suggest:
1. A more reasonable fee - $100 maybe. 2. Allow commenting, annotating and rating articles. 3. 'Trusted reviewers', i.e. people who are experts in the field (as far as it is possible to tell). Their comments would be highlighted and their ratings more significant.
x264 is just an encoder, I don't see what it has to do with anything.
Also, just nitpicking, but two guys in a garage are never going to write their own (decent) browser. The web is waaaay too complicated for that now. (I agree with your point though.)
But you may be able to get them from libraries, or get documents that are almost the same as the ISO ones.
All ISO standards are available from the British Library, and there's nothing to stop you reading the standard and writing your own description. Inconvenient, yes. Closed? Not really.
All true, but I think there is one big advantage that WebM has over H.264: the WebM format *must* be a Matroska file, and it *must* contain Vorbis and VP8, which only has one profile. That basically means if you have a WebM file, and a WebM decoder, you can almost certainly play it.
In contrast, H.264 can be paired with any audio codec, in any container, and has a large number of different profiles and features that not all players support .
At £50/month (seriously? that's insane), I'm pretty sure they were making money however much bandwidth he was using! It's people like me who spend £8/month they they probably don't make money from.
For Apple, the iPhone is the platform. For Google, the Cloud is the platform. That's why iPhones are expensive, droid devices tend to be cheaper, and Google's network services are better.
Huh? I'm not sure what you're saying here. The iPhone is (marginally) more expensive because it generally higher quality hardware than the competitors, and they have a monopoly on iOS hardware production.
Compare: 16 GB iPhone 4: £530; 16 GB Nexus S: £430. However the iPhone 4 is made of glass and metal, not plastic, has an (arguably) better display, tv-out and the best touchscreen on the market. Those things aren't free.
You're probably thinking "Apple fanboy" now, but actually I have had two Android phones, written a couple of apps for them, and even a patch for AOSP. I hate Apple's control freakery, but anyone who denies the superiority of their hardware (antenna issues aside), is frankly an idiot. That, and their monopoly leads to the slightly higher cost.
That's not really surprising though. The iPhone is more expensive than almost any Android phone (e.g. iPhone 4 16 GB: £530, Nexus S 16 GB: £430), and there are many cheaper Android phones. iPhone users are already self-selected as those willing to spend more money.
It seems likely that Android's market share will increase to be much greater than the iPhone's at which point you will make more money from Android. I agree about the multiple app stores though. It is already enough hassle to submit to Google's; I'm not going to bother submitting it to another one that doesn't even offer better returns.
That seems pretty silly. At some point the effort of maintaining all those drivers themselves will be greater than the effort of maintaining a stable ABI.
Paraphrasing, they say that they can't have a stable ABI because of small differences in how C compilers compile things (alignment of structures, etc.). Has that problem *really* not been solved? Microsoft manage to do it!
They then say they can't have a stable API (DPI?) because it would mean they have to maintain old code (true, but surely not too much work), and people might accidentally use the old version. Seriously? I guess they haven't heard of documentation.
And finally they say the solution is to get your driver into the main kernel tree. Not only would this be a hell of a lot more work than just shoving it on a website (subscribe to mailing lists, learn to use git properly, submit code for review, revise code, etc. etc.) but I seriously doubt they will just accept anything. What if I make a device that only I have? Will they accept a driver that is only useful for me?
It's clearly not the only solution. One could legislate that all new phone technologies should be SIM-based and interoperable between carriers (like it is in Europe). That seems have resulted in a pretty healthy amount of competition here.
They could also make it illegal to bundle phone payment plans into service contracts, or at least force carriers to offer them separately. That should encourage SIM-only contracts and people to buy their phones unlocked.
Erm, until Android 2.3 the NDK didn't have any method for audio output (other than passing the audio back to java, which is slow and stupid). I'd say that's a pretty big barrier.
Fortunately they made the NDK much more awesome for 2.3.
Slashdot Mirror
Wow this article is full of "Well we would , but we don't want to go into those military secrets."
> operatives could smuggle small satellite dishes into a country
Seriously?
But do we know that this is specific to Google? MS could just be watching anything that people type in their browsers, and then the web sites they end up at.
The /64 is so you can do state-less autoconfiguration. I.e. your IP address is derived from your MAC address or a GUID.
I hate to say it, but javascript and canvas are disappointingly slow. XaoS is dozens of times faster than this, and while I'm sure a lot of it is to do with specific fractal optimisations, surely a significant factor is the slowness of pixel operations and drawing images.
I'm writing an HTML5 game, and simply drawing an image that fills the screen (with no resampling) brings you down to about 50 fps. A few more small images, some resizing later and I'm into the 30 fps realm, and that's on a really fast computer using Chrome.
According to the article:
Max speed: 5 mph.
Max distance: 4 km.
Max capacity: 800 tonnes per day.
Market: Basically mining.
This is a stupid submission.
I discovered this years ago. I assumed it was deliberate to make logging in on phones easier...
And I agree, I can't really see a situation where this matters.
Or an RC plane...
So does PLoS One. In fact most journals allow you to pay $2k or so to make your article open access. PLoS One hasn't fixed the system at all, and neither will this.
I would suggest:
1. A more reasonable fee - $100 maybe.
2. Allow commenting, annotating and rating articles.
3. 'Trusted reviewers', i.e. people who are experts in the field (as far as it is possible to tell). Their comments would be highlighted and their ratings more significant.
"Half the bit rate of H.264 for content of the same quality..."
If you believe that...
Just because it's constantly evolving doesn't mean they're going to make backwards-incompatible changes!
x264 is just an encoder, I don't see what it has to do with anything.
Also, just nitpicking, but two guys in a garage are never going to write their own (decent) browser. The web is waaaay too complicated for that now. (I agree with your point though.)
But you may be able to get them from libraries, or get documents that are almost the same as the ISO ones.
All ISO standards are available from the British Library, and there's nothing to stop you reading the standard and writing your own description. Inconvenient, yes. Closed? Not really.
All true, but I think there is one big advantage that WebM has over H.264: the WebM format *must* be a Matroska file, and it *must* contain Vorbis and VP8, which only has one profile. That basically means if you have a WebM file, and a WebM decoder, you can almost certainly play it.
In contrast, H.264 can be paired with any audio codec, in any container, and has a large number of different profiles and features that not all players support .
At £50/month (seriously? that's insane), I'm pretty sure they were making money however much bandwidth he was using! It's people like me who spend £8/month they they probably don't make money from.
For Apple, the iPhone is the platform. For Google, the Cloud is the platform. That's why iPhones are expensive, droid devices tend to be cheaper, and Google's network services are better.
Huh? I'm not sure what you're saying here. The iPhone is (marginally) more expensive because it generally higher quality hardware than the competitors, and they have a monopoly on iOS hardware production.
Compare: 16 GB iPhone 4: £530; 16 GB Nexus S: £430. However the iPhone 4 is made of glass and metal, not plastic, has an (arguably) better display, tv-out and the best touchscreen on the market. Those things aren't free.
You're probably thinking "Apple fanboy" now, but actually I have had two Android phones, written a couple of apps for them, and even a patch for AOSP. I hate Apple's control freakery, but anyone who denies the superiority of their hardware (antenna issues aside), is frankly an idiot. That, and their monopoly leads to the slightly higher cost.
Ah, the rare double-woosh!
Yes but the reason for the licensing issues is that apple don't allow installing software that isn't from the app store.
That's not really surprising though. The iPhone is more expensive than almost any Android phone (e.g. iPhone 4 16 GB: £530, Nexus S 16 GB: £430), and there are many cheaper Android phones. iPhone users are already self-selected as those willing to spend more money.
It seems likely that Android's market share will increase to be much greater than the iPhone's at which point you will make more money from Android. I agree about the multiple app stores though. It is already enough hassle to submit to Google's; I'm not going to bother submitting it to another one that doesn't even offer better returns.
That seems pretty silly. At some point the effort of maintaining all those drivers themselves will be greater than the effort of maintaining a stable ABI.
That is just silly.
Paraphrasing, they say that they can't have a stable ABI because of small differences in how C compilers compile things (alignment of structures, etc.). Has that problem *really* not been solved? Microsoft manage to do it!
They then say they can't have a stable API (DPI?) because it would mean they have to maintain old code (true, but surely not too much work), and people might accidentally use the old version. Seriously? I guess they haven't heard of documentation.
And finally they say the solution is to get your driver into the main kernel tree. Not only would this be a hell of a lot more work than just shoving it on a website (subscribe to mailing lists, learn to use git properly, submit code for review, revise code, etc. etc.) but I seriously doubt they will just accept anything. What if I make a device that only I have? Will they accept a driver that is only useful for me?
Google just (re)started a pretty big advertising campaign for chrome on the London underground.
Only a few percent of the cables have been released, and some parts have been redacted.
It's clearly not the only solution. One could legislate that all new phone technologies should be SIM-based and interoperable between carriers (like it is in Europe). That seems have resulted in a pretty healthy amount of competition here.
They could also make it illegal to bundle phone payment plans into service contracts, or at least force carriers to offer them separately. That should encourage SIM-only contracts and people to buy their phones unlocked.
Erm, until Android 2.3 the NDK didn't have any method for audio output (other than passing the audio back to java, which is slow and stupid). I'd say that's a pretty big barrier.
Fortunately they made the NDK much more awesome for 2.3.
Pedant. And the parent didn't even mention virtual machines...