Slashdot Mirror
Google Chrome Will Adopt HTTP/2 In the Coming Weeks, Drop SPDY Support
An anonymous reader writes: Google today announced it will add HTTP/2, the second major version of Hypertext Transfer Protocol (HTTP), to Google Chrome. The company plans to gradually roll out support to the latest version of its browser, Chrome 40, "in the upcoming weeks." At the same time, Google says it will remove support for SPDY in early 2016. SPDY, which is not an acronym but just a short version for the word "speedy," is a protocol developed primarily at Google to improve browsing by forcing SSL encryption for all sites and speeding up page loads. Chrome will also lose support for the TLS extension NPN in favor of ALPN.
perhaps a binary data format, representing data in a database. This should be the next step.
And then we replace Javascript with Swift.
Google has a big case of "Invented Here" syndrome.
If Google started something, you can count on them dropping it.
Will HTTP/2 have a response code that will cause the browser to display the page that is returned from the server AND change the "current url" (for bookmarking, refreshing etc) to an alternate Location? POST to /createnewuser, display the response immediately with the URL of /user/3813812. Refreshing loads /user/3813812, not re-POSTing to /createnewuser.
Right now, the current paradigm of having to either redirect every single POST request to a new URL or risking users too stupid to know that they really need to not press reload on the page after saving something is a drain on server resources one way and support resources the other.
If I have been able to see further than others, it is because I bought a pair of binoculars.
It's pretty easy to get around this issue with JavaScript, e.g. by using Angular. I think this is less a problem with the HTTP protocol and more a problem with website design.
How long will the Brian Williams jokes last?
Ask Brian Williams.
Will Brian get his own internet meme? Not if Brian Williams gets it first.
You could just only return the data required from the POST request and use client side code to render it, instead of reloading the entire page. Saving bandwidth, server-side processing and rendering time.
Nothing is ever so simple. There are situations where you *want* POST to reprocess and refresh, such as when presenting statistics for a server. As a result the prototocol doesn't restrict you to one POST per page, and leaves it up to the server programmer to implement request id's to prevent duplicate execution when it needs to be prevented, rather than limiting the protocol to only allowing that behaviour.
I do not fail; I succeed at finding out what does not work.
What? POST is the non-idempotent one. See the table in http://tools.ietf.org/html/rfc..., section 8.1.3
Color me paranoid but this sounds like Google is going out of there weigh too weeken encryption in transport. For "national security" in homeland, amirite? God save the homeland!
Using onload="history.pushState(null, null, '/user/31813812');" certainly works, but now pushing the "back" button is the landmine instead of pushing refresh (not to mention users that turn off javascript). Being able to use javascript to pretend you're doing what the HTTP procotol should have done does not make it not a problem with the protocol.
That said, the HTTP/1.1 protocol itself is fine. A user agent ought handle a 201 Created response exactly like this as a side effect (OK, so the response body is technically not a listing of places you can get the created object from, but it's supposed to be displayed to the user either way), but there are zero browsers implementing the Location part of it. Adding a response code explicitly for the purpose of "here is a response to display to the user right now, if the user wants to reload it, request this URL instead" would hopefully get browser developers to say "oh, I see why we're doing this" and do it. Doubly so when they're writing a new implementation for a new protocol. At this point, I'd argue that the best thing to do would be to add something like "311 Content With Future Redirect" so that browsers that don't implement it continue with 3xx POST-Redirect-GET semantics (losing nothing) and browsers that do understand it will work.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Color me paranoid but this sounds like Google is going out of there weigh too weeken encryption in transport. For "national security" in homeland, amirite? God save the homeland!
I feel a great disturbance in the internet, as if millions of spellcheckers cried out in terror and were suddenly silenced.
Erm, but in that instance POSTing then doing a GET makes sense.
The POST creates the new user.
The GET retrieves the information for user 3813812.
How are those two things the same? That is exactly how it is supposed to be done.
If your server can't handle that 'additonal' load very well, then I've got a 486 upgrade I'll donate for free.
First, browser developers are in charge of browser behavior, not a protocol. RFC may say "should", or "must", but browser implementers don't have to do that.
There is a need for this, but your question is whether the standard requests, or requires, the feature. Your other, unasked question, is whether any development team has committed to respect the "required" or "must" statement from the RFC.
It's got nothing to do with server load. Useless roundtrips are bad, end of story.
There's a _minimum_ of 300ms of latency for _any_ request to the USA from Australia - and there's nothing you can do about that. So every useless redirect and meaningless request slows down the user experience.
It would make perfect sense for there to be a HTTP Method that was not intended to be idempotent (like POST), but that didn't result in a resubmission on reload (and also didn't results in a stupid browser warning about resubmission). A "OK, that succeeded and now I am showing you the resource at this URI" response would solve the problem perfectly.
A reload would not resubmit, it'd just re-do the implied GET of the resultant resource, and back would take you back to the form prior to submission, _and_ there'd be no useless redirect in between. Win-win.
With modern frameworks and Java level classiness (here, have a mappingfactory class that instantiates the mapping class that maps the data from the form into the object returned from the factory class that produced the object being created) what happens is more like
The POST creates a hospital, staffs it with receptionists, doctors, nurses, and so on. A pregnant woman (the request) goes in, the receptionist routes her to the OB ward where nurses help her into the stirrups and the doctor catches the baby. The doctor takes all the baby's stats, writes it on the birth certificate, drops the certificate into a pneumatic chute that whisks it away to safety (in the database) as the hospital and all its occupants are immediately vaporized by an explosion (if you're still using CGI, replace this with the entire sun going supernova. Add recreating the solar system to the beginning of the next request).
The GET creates a hospital, staffs it with receptionists, doctors, cloning technicians, and so on. A woman (the request) goes in, the receptionist routes her to the cloning ward where the woman hands over the birth certificate that had been mailed to her, the doctor looks over the certificate and checks to make sure she's really supposed to have it (or not, given the state of security these days) then pulls out a cloning tank and reconstitutes a baby that is identical in every way (ideally) to the original and hands it to the woman. As the woman leaves the hospital baby in tow, it explodes behind her, action movie style.
Or, y'know, you could just pass the new baby straight to a View and do all this with half the hospitals, doctors, receptionists and none of the cloning vats.
then I've got a 486 upgrade I'll donate for free.
Thanks! Once it can do the same task with half the number of requests, it'll work twice as well!
If I have been able to see further than others, it is because I bought a pair of binoculars.
Apparently this was already being done in a non-standard compliant manner but supported by all the browsers. The non-standard version, created and promoted by SPDY is going to be withdrawn and the standard-compliant version will be the only thing that will be supported in Chrome going forward. I would imagine it to be something like MsOffice has deciding to switch to ODF as the only supported format.
Definitely not evil and consistent with not trying to be evil.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Yep that sounds correct. That is the entire point of GET and POST being different.
GET retrieves data, never alters it. POST alters data, never retrieves it.
This is kinda HTTP 101. You might disagree, but then you'd be doing it wrong.
You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.
I have no plans to adopt HTTP/2. The mandatory fauxcryption (as implemented in the browsers) is a dealbreaker. Certificates are nothing but a scam and they certainly aren't trustworthy since the CAs are subject to the whims of cybercriminals and governments. All this does is increase the barrier to entry for having your own webpage.
POST alters data, never retrieves it.
Except for all of the cases where POST returns data, sure. There is absolutely no reason to destroy the result of creating a resource instead of returning the newly created resource with a flag "don't do that again".
You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.
Meanwhile you're dulling the perfectly good axe to be sure that nobody cuts down your sacred tree.
If I have been able to see further than others, it is because I bought a pair of binoculars.
If the 'axe' is perfectly good, then why are you requesting fundamental changes to HTTP web apps and every web browser just to save your 8080 web server one additional hit?
Erm, but in that instance POSTing then doing a GET makes sense.
The POST creates the new user.
The GET retrieves the information for user 3813812.
Too many people seem to think it's cool to add round trips for some incoherent appeal to logical consistency.
How are those two things the same? That is exactly how it is supposed to be done.
Who cares? HTTP verbs are insufficient to express jack or jill and HTTP completely lacks any useful transaction semantics. REST in the abstract is a great idea... only problem is HTTP is shit and when you don't treat shit like shit you end up with shit. HTTP is simply the wrong layer to be toying with any kind of abstraction if you care about useful results.
If your server can't handle that 'additonal' load very well, then I've got a 486 upgrade I'll donate for free.
The actual problem is users suffering through yet another round of unnecessary round trips cuz 'GET' *feels* cleaner.
The paradigm and semantic is perfectly clean/correct. The roundtrip is just an implementation detail.
The protocol could simply return the result of the post with a redirect, as well as the result of the get, in 1 response. Then under the hood even though you do a GET, the get "chunk" of the post result would get rendered. No additional roundtrip.
This is already used in some context. Imagine I want to show you a server rendered image based on some query string generated in javascript or something (ie: nothing is known about the image to the initial page except how to request it). I also want to return the description of that image along with some metadata.
I set the image url in an img tag. The image is shown to you. The description of the image is returned in metadata/headers/whatever. It is being requested by an img tag, so I don't get access to its data. I can then to an ajax request for that image, which will get served from cache (no additional roundtrip) and get the data that goes with it.
(yeah, I could request the image and then set the data to the img tag. This was just a roundabout example).
That technique works today, and for some edge cases, it is actually being used in the real world. Making a post -> redirect -> Get without roundtrip wouldn't be very different from existing paradigms.
Since IE 11 is end of life and so is the 2nd most popular browser IE 8 it will prevent adoption.
The saga of short sighted ceos not wanting to loose customers who run old operating systems kills innovation again as win 7 will continue to exist for a long time and with it IE 11 and 8 for corps with old apps
http://saveie6.com/
Yep that sounds correct. That is the entire point of GET and POST being different.
GET retrieves data, never alters it. POST alters data, never retrieves it.
Both assertions are false.
This is kinda HTTP 101. You might disagree, but then you'd be doing it wrong.
LOL if you disagree with me your doing it wrong. No arguing that.
You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.
HTTP is a dull rusty blade attached to a termite infested rotted, split, splintered handle yet it is the only axe left in the world and the only way to cut down trees.
It is unwise to attempt to use it properly as "intended" you will just break it and or injure yourself.
Instructions included with moldy packaging the axe originally came in is only a useful as a reminder of old times before our Alien overlords swooped down from the sky and stole all of the worlds axes except one their computer failed to recognize as an axe.
The paradigm and semantic is perfectly clean/correct. The roundtrip is just an implementation detail.
Like the rest of HTTP it is perfectly useless. No coherency nor atomicity nor any way to implement verbs beyond trivial "CRUD".
The protocol could simply return the result of the post with a redirect, as well as the result of the get, in 1 response.
Why is returning a pointer to data allowed while returning actual data itself not? This just sounds like bullshit.
Then under the hood even though you do a GET, the get "chunk" of the post result would get rendered. No additional roundtrip.
Or you can just return data and stop being silly.
(yeah, I could request the image and then set the data to the img tag. This was just a roundabout example).
It always is... I'll leave failure to communicate a coherent use case to speak for itself.
That technique works today, and for some edge cases, it is actually being used in the real world. Making a post -> redirect -> Get without roundtrip wouldn't be very different from existing paradigms.
But what is the point?
Post is the only non-indempotent of the major http verbs. Its one of the core difference between Post and Put and why when you create a new resource without a natural id, you use post, not put...
Post is the only non-indempotent of the major http verbs. Its one of the core difference between Post and Put and why when you create a new resource without a natural id, you use post, not put...
What happens if you POST to a server and the response is lost? How does client know it was processed or not? The answer is you always need some kind of id/token/big word because non-idempotwhatever is not actually possible.
The only thing POST is... is worthless... defective by design without specific and unnecessary application logic to deal with consequences of HTTP's total lack of a commitment procedure.
I think you're confusing the protocol verbs with a heap of javabollocks on the back end.
In most systems GET occurs much more often than POST, and if you're returning to a system after logging off, you'll be doing a lot of GETs just to restore your environment (or page view).
I think a POST+GET optimisation would be nice, but it would be an optimisation, a little like how some DBs have a 'insert, or update if already exists' statement. But you can already return data from a POST, it does break the concept but it works. Just slap the new data in the body and let the client read it if it wants, so maybe the protocol doesn't need any modification at all (your crappy framework code might though, but that's too bad for using those "easy-to-use" frameworks)
Like the rest of HTTP it is perfectly useless.
Then you'd better stop making posts to an HTTP-based discussion board.
Clearly we're not making posts to an HTTP-based discussion board because when we submit a POST request we get response data back that is then displayed on screen. Violating such fundamental principles of HTTP surely disqualifies it from being considered as such.
If I have been able to see further than others, it is because I bought a pair of binoculars.
"(Disclaimer: I'm a Google security engineer" - by swillden (191260) on Tuesday February 10, 2015 @12:01AM (#49023323) Homepage
See subject: That quote from YOU explains THIS from you to me -> http://yro.slashdot.org/commen... which is SO ironically LUDICROUS it's not funny - YOU FUCKING WORK FOR THE BIGGEST ADVERTISER THERE IS (see subject stupid) & that weak CRAP's the "best you got" & it ain't much fool!
For such a "security engineer" (fucking ROOKIE little BOY), how come that was the "best you have" WITH A DOWNMOD OF MY POST too, vs. my points on Hosts Files BLATANT overall superiority http://yro.slashdot.org/commen...
vs.
AdBlock of ANY kind, what "YOU & YOURS" @ Google "espouse" + HELP TO CRIPPLE BY DEFAULT, SINCE YOU LOVE THAT IT'S CRIPPLED & YOU PAID BOTH AdBlock Plus & AdBlock OFF to NOT BLOCK ADS (a major source of malcode infestation/infection AND bandwidth stealing from end users)?
APK
P.S.=> ANSWER = You're petty, & WEAK (especially vs. myself) like all marketing/advertising douchebags always are, helpless to prove my points on hosts giving users more security, speed, reliability + anonymity even (to a lesser extent on the latter) than *ANY* single "so-called 'solution'" out there, since hosts do FAR MORE, with far less & now you've shown me YOUR FAVORITE COLOR = TRANSPARENT cuz as the saying goes? "I SEE YOU" for what you really are now, BOY!
Thank you: Your "braggadocio" is your undoing & WILL be *VERY USEFUL* to myself in the future vs. your weak bullshit, lol (truth's got a way of coming out, now doesn't it?) ... apk
Dude, my employer is mentioned on my /. profile; I've never made any attempt to hide it. And it really has nothing to do with being annoyed by your crapflooding. EVERYONE is annoyed by your crapflooding.
It's fine that you like using a hosts file to block ads. Really. And it's even fine posting about it a time or two on relevant slashdot threads. If you kept it to a reasonable volume you'd probably even get modded up. But the crapflooding is obnoxious.
Finally, my comment about an APK-block extension was a joke... but now you're making me think seriously about writing it.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Don't downmod again: Can adblock do 16 things hosts do for speed, security, & reliability:
1.) Protect vs. malicious sites/servers (beyond ads: See 2-10 next)
2.) Protect vs. fastflux botnets + stop communication to C&C servers
3.) Protect vs. dynamic dns botnets + stop communication to C&C servers
4.) Protect vs. DGA botnets + stop communication to C&C servers
5.) Protect vs. downed DNS (adds reliability)
6.) Protect vs. DNS redirect poisoned dns
7.) Protect vs. trackers
8.) Protect vs. spam
9.) Protect vs. phishing
10.) Protect vs. bandwidth caps
11.) Get you past a dnsbl
12.) Keep you off dns request logs
13.) Speed up websurfing by adblocks & hardcoded fav. sites
14.) Work on ANY webbound app (think stand-alone email programs) multiplatform.
15.) Give you easily texteditor controlled data for the above
16.) Do all that & block ads (better than addons) more efficiently in cpu cycles + memory usage
APK
P.S.=> ANSWER ="NO" to each above on Ghostery/AdBlock doing it as well or at all!
BOTH do far less than hosts do & less efficiently - hosts by way of comparison, do MORE w/ less + Hosts start w/ the IP stack before REDUNDANT inefficient addons BEGIN to operate (as 1st resolver queried):
AdBlock's 4++gb & 100% CPU usage flooring inefficiency -> https://blog.mozilla.org/nneth... + ClarityRay defeats it + it 'souled-out' & is crippled by default paid off to not do its job http://techcrunch.com/2013/07/...
Ghostery's Advertiser owned - "A fox guards the henhouse"-> http://en.wikipedia.org/wiki/G...
Both add complexity/room for breakdown/exploit + from a slower mode of operations (usermode = more messagepassing overheads vs. hosts in kernelmode).
For the BEST hosts file?
APK Hosts File Engine 9.0++ SR-1 32/64-bit -> http://start64.com/index.php?o...
MalwareBytes' hpHosts Admin (MalwareBytes employee) hosts & recommends it -> http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus http://www.av-test.org/en/news...
... apk
See subject: That's the # estimated using adblockers Mr. Advertiser!
Why'd GOOGLE remove hosts from ANDROID Kit Kat too??
ANSWER = Google's "tipped their hand" again on that one - you're AFRAID of hosts - you can't STOP them is why (buying 'em out like AdBlock isn't possible either).
* Don't b.s. Mr. "plant" - I just turned your WEAK reply against you with WIDELY KNOWN FACTS!
(You're running facts & A FAIR CHALLENGE too, despite your "alleged credentials" http://tech.slashdot.org/comme... )
APK
P.S.=> You're crapflooders @ GOOGLE infecting users with malicious code as advertisers & STEALING BANDWIDTH WE ALL PAY FOR MONTHLY!
Think I haven't work for "big industry names" & that I KNOW they have "special people" put into forums like this to "comment on" topics dealing with their company like the AdBlock payoffs you were TOTALLY off topic spamming in boy (spinmasters & OFF TOPIC CRAP FLOODERS LIKE YOU HERE boy -> http://yro.slashdot.org/commen... ) ? Guess again - now, you're cornered boy... apk
"It's fine that you like using a hosts file to block ads. Really. And it's even fine posting about it a time or two on relevant slashdot threads. If you kept it to a reasonable volume you'd probably even get modded up. But the crapflooding is obnoxious. - by swillden (191260) on Wednesday February 11, 2015 @09:01AM (#49028337) Homepage
UnknownSoldier, gl4ss, sootman, TestedDoughnut, TempestRose, lennier1, ScottCooperDotNet, Bill Dog, drinkypoo, Culture20, Rick17JJ, Ol Olsoc, icebraining, Trax3001BBS, fahrbot-bot, EdIII, bLanark, RocketRabbit, TheRealGrogan, Martin Blank, CAIMLAS. drakaan, Dynedain,Lime Green Bowler, Bob9113, wolrahnaes, raju1kabir, mrbcs, gweihir, frovingslosh, tepples, kimvette, Geeky, humanrev, maestroX, phrostie, ElectricTurtle, mattbee, VShael, AndGodSed, jafiwam, i.r.id10t, NeverVotedBush, falconwolf, BrokenHalo, orclevegam, cyberjock1980, gad_zuki!, furby076, jandrese, halcyon1234, Anonymous Admin, houghi, drooling-dog, dracocat, betterunixthanunix, someones, sqrt(2), cratermoon, bmo, fast turtle, Kris_J, SydShamino, Technician, pjkeyzer, srmalloy, schwit1, mrbcs, KingAlanI, ksemlerK, Scorch_, Mechanic, NealBScott, Anubis IV, crutchy, damn_registrars, couchslug, green1, wakeboarder, Gothmolly, lesincompetent, ls671, DigiShaman, P. Don, Yaa 101, qwertyatwork, dehole, Em Adespoton, CAOgdin, schwit1, MightyYar, RJFerret, idontgno, technosaurus, wickerprints, noh8rz10, sexconker, sandbagger, NewWorldDan, Karmashock, aNonnyMouseCowered, Dracos, keith_nt4, networkzombie, jafiwam, JohnFen, SigmundFloyd, EETech1, duck_rifted, The MAZZTer, Anonymous Brave Guy, plasm4, holophrastic, Baki, StikyPad, kermidge, & myself...
* Same ones I crushed wannabe SECURIY GURU (LIKE YOU) raymorris (whom I am almost certain works for an advertiser redirector too) with (as he shot his mouth off about hosts) here http://it.slashdot.org/comment...
APK
P.S.=> See subject, & those /. users disagree w/ you - they use hosts (you're outnumbered bigtime) ... apk
"If you kept it to a reasonable volume you'd probably even get modded up. But the crapflooding is obnoxious." - by swillden (191260) on Wednesday February 11, 2015 @09:01AM (#49028337) Homepage
"Eat your words" (21/60 upmods of my hosts posts):
http://ask.slashdot.org/commen...
http://slashdot.org/comments.p...
http://it.slashdot.org/comment...
http://it.slashdot.org/comment...
http://it.slashdot.org/comment...
http://tech.slashdot.org/comme...
http://tech.slashdot.org/comme...
http://tech.slashdot.org/comme...
http://yro.slashdot.org/commen...
http://yro.slashdot.org/commen...
http://yro.slashdot.org/commen...
http://yro.slashdot.org/commen...
http://yro.slashdot.org/commen...
http://yro.slashdot.org/commen...
http://linux.slashdot.org/comm...
http://slashdot.org/comments.p...
http://yro.slashdot.org/commen...
http://mobile.slashdot.org/com...
http://it.slashdot.org/comment...
http://mobile.slashdot.org/com...
http://it.slashdot.org/comment...
APK
P.S.=> What's that you said quoted above? Who's FULL OF CRAP (again)?? apk
"If you kept it to a reasonable volume you'd probably even get modded up. But the crapflooding is obnoxious." - by swillden (191260) on Wednesday February 11, 2015 @09:01AM (#49028337) Homepage
"Eat your words" (60 upmods of my hosts posts):
http://yro.slashdot.org/commen...
http://yro.slashdot.org/commen...
http://yro.slashdot.org/commen...
http://yro.slashdot.org/commen...
http://it.slashdot.org/comment...
http://yro.slashdot.org/commen...
http://it.slashdot.org/comment...
http://tech.slashdot.org/comme...
http://hardware.slashdot.org/c...
http://yro.slashdot.org/commen...
http://tech.slashdot.org/comme...
http://mobile.slashdot.org/com...
http://news.slashdot.org/comme...
http://tech.slashdot.org/comme...
http://apple.slashdot.org/comm...
http://it.slashdot.org/comment...
http://it.slashdot.org/comment...
http://it.slashdot.org/comment...
http://yro.slashdot.org/commen...
http://it.slashdot.org/comment...
http://tech.slashdot.org/comme...
APK
P.S.=> What's that you said quoted above? Who's FULL OF CRAP (again)?? apk
"If you kept it to a reasonable volume you'd probably even get modded up. But the crapflooding is obnoxious." - by swillden (191260) on Wednesday February 11, 2015 @09:01AM (#49028337) Homepage
"Eat your words" (60 upmods of my hosts posts):
http://tech.slashdot.org/comme...
http://tech.slashdot.org/comme...
http://tech.slashdot.org/comme...
http://hardware.slashdot.org/c...
http://tech.slashdot.org/comme...
http://tech.slashdot.org/comme...
http://tech.slashdot.org/comme...
http://tech.slashdot.org/comme...
http://mobile.slashdot.org/com...
http://yro.slashdot.org/commen...
http://games.slashdot.org/comm...
http://politics.slashdot.org/c...
http://yro.slashdot.org/commen...
http://yro.slashdot.org/commen...
http://tech.slashdot.org/comme...
http://slashdot.org/comments.p...
APK
P.S.=> What's that you said quoted above? Who's FULL OF CRAP (again)?? apk
"Cat got your tongue"?
Yes -> http://tech.slashdot.org/comme...
Yes -> http://tech.slashdot.org/comme...
Yes -> http://tech.slashdot.org/comme...
Yes -> http://tech.slashdot.org/comme...
Yes -> http://tech.slashdot.org/comme...
* "Run, Forrest: RUN!!!!"
(So much for "Google Security Engineer" wannabes...)
APK
P.S.=> Most importantly, per my subject, you're RUNNING from this -> http://tech.slashdot.org/comme...
"Run, Forrest: RUN!!!" -> http://tech.slashdot.org/comme...
* What's the matter? You TROLL me -> http://yro.slashdot.org/commen... & can't take a little of your own medicine in return?
(ESPECIALLY when it makes you "Run, Forrest: RUN", Mr. wannabe "security guru"?? Yes... THAT's the "best you've got"??? Again, it "ain't much" (Zero))
APK
P.S.=> Gotta LOVE these wannabes shooting their mouths off like swillden here & then they can't backup their b.s.! Proves me correct, EVERY single time (on all I've said above & on all the links posted's points)... apk
"Cat got your tongue", Forrest? Yes (many times) -> http://tech.slashdot.org/comme...
* You, & yes, GOOGLE, fail vs. myself... badly - VERY badly!
(Too bad you troll myself as shown in those links, & then when you're faced with facts you can't get the better of? You run, or downmod posts rampantly, as all TROLLS like yourself always do...)
APK
P.S.=> You're only making me stronger... apk