I suspect part of the real reason for MS not wanting to go down the HTML5 route is that by doing so, the service provider (aka Google) is then in control of the look and feel of the app.
Google would most certainly not be in the control of the L&F of the App. The app would be Microsoft's and would consume web services from Google, nothing more. That App could be 100% pixel for pixel what MS expects it to be, except for the content of thumbnails and videos.
What will no longer work by default is 3rd-party cookies, because they are used to track people around the 'net as they browse between different sites, which lets companies build centralized dossiers of people's browsing habits.
Unfortunately, they are not used by just that. There are plenty of other scenarios that work with 3rd parties cookies and will be broken if not. One example is the use of a CDN (Akamai, etc.) which quickly point out the need for a subdomain. So your traffic through Akamai will go through a domain and your direct traffic will go through a subdomain. All of a sudden, one JS file that used to store a cookie cannot do it anymore... And your entire website is broken.
The problem with this is that changing something that big will invariably break plenty of websites. And the only ones to suffer from this will be Mozilla as people will quickly learn to go through other browsers because "Mozilla is b0rked".
I completely agree. There is today absolutely NO INCENTIVE to go through a provider to get a phone. It is perfectly fine to get there with your own phone and usually much less expensive over time. Unless you live in the US ans your carrier charges the same price whether you're reimbursing a subsidized phone or not of course which is simply called 'theft' in my book.
Re:Google can fix it with a hammer.
on
AOSP Maintainer Quits
·
· Score: 1, Insightful
Wow... That was some analogy and some conclusion. Let's dive in!
People dont give a shit how a structurally sound a bridge is constructed either, only a tiny tiny % of its users do. Just because only a few know enough to care doesnt change the argument
Comparing a phone with a bridge is at best disingenuous. There are public health safety issues with bridges that are obvious to many I guess. The disadvantage for users is obvious. Phones? What disadvantage can you see for a random user by using a "closed" phone? Right. None.
Very often it is the unpopular ideas that are correct.
Well, now you have to define 'correct'. And you will quickly see that there are as many definitions as there are people trying to define it. Google doesn't care about your definition of correct, nor should it. And you don't care about theirs. Just, remember, don't throw around yours as if it is a universal version of 'correct'.
As it turns out, RIM provides a proxy service for email. That's what they do, and everyone has access to this kind of information as BB doesn't hide it but actually advertises it. It may be a bad idea, but it is most certainly not deception./story.
The same way you verify that the published final result matches the actual votes!
You mean by counting manually the bits in the RAM of the machine, or counting the votes (with a witness in the booth) and checking that against the overall results?
The ONLY way to make e-voting productive is to have those machines... produce a piece of paper on whitch the voter can check that the right name is printed on. Put it in an envelope, and in the urn. At the end of the day, the ballots are opened by some volunteers, the name printed on is read out loud, they are passed into a machine and a giant screen in the room shows the scores increase.
That way: - Considerably less paper (one ballot per voter) - Faster counting (just read the name out loud, people check that the right dude gets the upcount - much faster than doing everything manually. - Possibility to do it manually for recount / electricity outage, etc... Everything in printed on ballots. - The voter can actually make sure he votes for the person he intended to. It's written on the piece of paper. - No need to check the software. because of the previous point.
I wasn't aware that Apple had a dominant position in the e-book world, and so was subject to anti-trust laws on this subject... Does anyone know what this is all about?
There is one fundamental difference from books vs ebooks: ebooks can be cloned perfectly in a split of a millisecond. Books cannot. This was a limitation of the analog world. Now, in the digital age, this limitation has vanished. It's this change that the GP rambles about in his post, and yes, things have changed. The industry can adapt or suffer. Their call. Litigation and legislation will maintain their old business model only so far. In the end, digital will prevail.
Last time I checked, cookies were stored locally and not transmitted with every request.
Check again. How do you think your server knows who you are from a new HTTP request? Cookies. They get in every query your browser sends to your server. Every single one. CSS, images, javascript files, AJAX queries, everything. Moreover, this is upload which often is much slower for the browser.
Now the ViewState.NET variables I'd have to look up because I didn't fall into that trap, but I would imagine that they are also locally stored so not so much the reason your HTTP requests being generally slow.
Well, again, you're sadly mistaken. Check http://msdn.microsoft.com/en-us/library/ms972976.aspx for more information. ViewState data is posted back and forth to sync component state between the server and the client. On a poorly coded site this can amount to hundreds of kilobytes of data for every click the user makes. However, it has nothing to do with HTTP.
Well...it won't - but it could significantly improve the compression when that crap is done.
I really don't see how storing this bloat in binary form will improve anything. Most http requests on the interwebs is already GZIP compressed. Those cookies carry strings, that can be carried away in so many formats - be they binary or string-based. They will be transferred whether the protocol is binary or ASCII . This doesn't change anything on that front really.
Debugging tools are not optional, they are build in all major browsers. Second, under Linux, Firefox with debugging tools opened is slow to the point where with my 4-core CPU it is actually *not* usable anymore. Try loading the home page of Amazon.com in 20+seconds, all pegged at 100% CPU. And the problem is that I almost always have a debugging tool opened in one of my firefox window. This makes me basically ditch Firefox most of the time and as a result I don't test on it anymore. Or less than before. This is all detrimental to firefox.
And saying the development tools are unimportant in a browser is about not paying attention. Sure it doesn't impact directly the public, but it does impact greatly the developers and thus, the users as well.
Stuxnet made me think actually. Anyone organization can succumb to something like that. And the fact that all my money and soon my title of property from everything I own is susceptible to such an attack is... well... kind of annoying.
Slashdot Mirror
I suspect part of the real reason for MS not wanting to go down the HTML5 route is that by doing so, the service provider (aka Google) is then in control of the look and feel of the app.
Google would most certainly not be in the control of the L&F of the App. The app would be Microsoft's and would consume web services from Google, nothing more. That App could be 100% pixel for pixel what MS expects it to be, except for the content of thumbnails and videos.
steal their content by breaking the social contract
Is it stealing if I drive down the highway and don't read the billboards?
No, but try to cover them with a white fabric and we'll see how long you'll hold it on.
What will no longer work by default is 3rd-party cookies, because they are used to track people around the 'net as they browse between different sites, which lets companies build centralized dossiers of people's browsing habits.
Unfortunately, they are not used by just that. There are plenty of other scenarios that work with 3rd parties cookies and will be broken if not. One example is the use of a CDN (Akamai, etc.) which quickly point out the need for a subdomain. So your traffic through Akamai will go through a domain and your direct traffic will go through a subdomain. All of a sudden, one JS file that used to store a cookie cannot do it anymore... And your entire website is broken.
The problem with this is that changing something that big will invariably break plenty of websites. And the only ones to suffer from this will be Mozilla as people will quickly learn to go through other browsers because "Mozilla is b0rked".
I completely agree. There is today absolutely NO INCENTIVE to go through a provider to get a phone. It is perfectly fine to get there with your own phone and usually much less expensive over time. Unless you live in the US ans your carrier charges the same price whether you're reimbursing a subsidized phone or not of course which is simply called 'theft' in my book.
Wow... That was some analogy and some conclusion. Let's dive in!
People dont give a shit how a structurally sound a bridge is constructed either, only a tiny tiny % of its users do. Just because only a few know enough to care doesnt change the argument
Comparing a phone with a bridge is at best disingenuous. There are public health safety issues with bridges that are obvious to many I guess. The disadvantage for users is obvious. Phones? What disadvantage can you see for a random user by using a "closed" phone? Right. None.
Very often it is the unpopular ideas that are correct.
Well, now you have to define 'correct'. And you will quickly see that there are as many definitions as there are people trying to define it. Google doesn't care about your definition of correct, nor should it. And you don't care about theirs. Just, remember, don't throw around yours as if it is a universal version of 'correct'.
Nuke them from orbit. It's the only safe way.
The USA doesn't have universal health care.
Good thing too. In Europe we have it and it appear now that we cannot pay for it. It is basically a money gobbler. Unsustainable.
Guess what the best advice is? Use a different password for every site.
I ran out of memory at 65536. I guess I'm just 16 bits wide.
Does anyone remember what password policy the forums had, trying to work out which password I was using for it.
It's probably the one in your sig.
The story is dumb fuck stupid, no need to be a fanboi to point it out.
Next news on slashdot:
Shocking! Researcher discovers hitting submit on the login page of Gmail actually TRANFERS ALL YOUR CREDENTIALS to Google.
As it turns out, RIM provides a proxy service for email. That's what they do, and everyone has access to this kind of information as BB doesn't hide it but actually advertises it. It may be a bad idea, but it is most certainly not deception. /story.
The only system not broken is voter-verified open voting.
What is that? Can you give us more than 4 words to get an idea?
The same way you verify that the published final result matches the actual votes!
You mean by counting manually the bits in the RAM of the machine, or counting the votes (with a witness in the booth) and checking that against the overall results?
The ONLY way to make e-voting productive is to have those machines ... produce a piece of paper on whitch the voter can check that the right name is printed on. Put it in an envelope, and in the urn. At the end of the day, the ballots are opened by some volunteers, the name printed on is read out loud, they are passed into a machine and a giant screen in the room shows the scores increase.
That way:
- Considerably less paper (one ballot per voter)
- Faster counting (just read the name out loud, people check that the right dude gets the upcount - much faster than doing everything manually.
- Possibility to do it manually for recount / electricity outage, etc... Everything in printed on ballots.
- The voter can actually make sure he votes for the person he intended to. It's written on the piece of paper.
- No need to check the software. because of the previous point.
Thanks. The best answer I got so far, by a few hundred miles.
I wasn't aware that Apple had a dominant position in the e-book world, and so was subject to anti-trust laws on this subject... Does anyone know what this is all about?
There is one fundamental difference from books vs ebooks: ebooks can be cloned perfectly in a split of a millisecond. Books cannot. This was a limitation of the analog world. Now, in the digital age, this limitation has vanished. It's this change that the GP rambles about in his post, and yes, things have changed. The industry can adapt or suffer. Their call. Litigation and legislation will maintain their old business model only so far. In the end, digital will prevail.
Which is 8/6 as big as the origina binary data you were about to send, and all that uncompressed. Lots of wasted space there.
Last time I checked, cookies were stored locally and not transmitted with every request.
Check again. How do you think your server knows who you are from a new HTTP request? Cookies. They get in every query your browser sends to your server. Every single one. CSS, images, javascript files, AJAX queries, everything. Moreover, this is upload which often is much slower for the browser.
Now the ViewState .NET variables I'd have to look up because I didn't fall into that trap, but I would imagine that they are also locally stored so not so much the reason your HTTP requests being generally slow.
Well, again, you're sadly mistaken. Check http://msdn.microsoft.com/en-us/library/ms972976.aspx for more information. ViewState data is posted back and forth to sync component state between the server and the client. On a poorly coded site this can amount to hundreds of kilobytes of data for every click the user makes. However, it has nothing to do with HTTP.
Well...it won't - but it could significantly improve the compression when that crap is done.
I really don't see how storing this bloat in binary form will improve anything. Most http requests on the interwebs is already GZIP compressed. Those cookies carry strings, that can be carried away in so many formats - be they binary or string-based. They will be transferred whether the protocol is binary or ASCII . This doesn't change anything on that front really.
Debugging tools are not optional, they are build in all major browsers. Second, under Linux, Firefox with debugging tools opened is slow to the point where with my 4-core CPU it is actually *not* usable anymore. Try loading the home page of Amazon.com in 20+seconds, all pegged at 100% CPU. And the problem is that I almost always have a debugging tool opened in one of my firefox window. This makes me basically ditch Firefox most of the time and as a result I don't test on it anymore. Or less than before. This is all detrimental to firefox.
And saying the development tools are unimportant in a browser is about not paying attention. Sure it doesn't impact directly the public, but it does impact greatly the developers and thus, the users as well.
Stuxnet did hurt facilities from Iran that were *not* connected to the internet, yet it was because of the internet that Stuxnet got in.
Stuxnet made me think actually. Anyone organization can succumb to something like that. And the fact that all my money and soon my title of property from everything I own is susceptible to such an attack is... well... kind of annoying.
And when do they make a benchmark for Linux and/or MacOS? Or with the debugging tools opened (firebug / chrome debug / ...) ?
Because both these factors will throw Firefox down the drain real fast in my experience.
Because, as far as I know, you used to have to hook your iphone up to your computer to install apps.
Then you know wrong. It was for OS upgrades, not for apps.