Slashdot Mirror
WebKit Unifies JavaScript Compilation With LLVM Optimizer
An anonymous reader tips this post at Webkit.org:
"Just a decade ago, JavaScript – the programming language used to drive web page interactions – was thought to be too slow for serious application development. But thanks to continuous optimization efforts, it's now possible to write sophisticated, high-performance applications – even graphics-intensive games – using portable standards-compliant JavaScript and HTML5. This post describes a new advancement in JavaScript optimization: the WebKit project has unified its existing JavaScript compilation infrastructure with the state-of-the-art LLVM optimizer. This will allow JavaScript programs to leverage sophisticated optimizations that were previously only available to native applications written in languages like C++ or Objective-C. ... I'm happy to report that our LLVM-based just-in-time (JIT) compiler, dubbed the FTL – short for Fourth Tier LLVM – has been enabled by default on the Mac and iOS ports. This post summarizes the FTL engineering that was undertaken over the past year. It first reviews how WebKit's JIT compilers worked prior to the FTL. Then it describes the FTL architecture along with how we solved some of the fundamental challenges of using LLVM as a dynamic language JIT. Finally, this post shows how the FTL enables a couple of JavaScript-specific optimizations."
Additional benchmarks for Safari with this technology vs. Chrome with its JavaScript acceleration would be appreciated; is this a closing of the speed gap, a move ahead, or a lateral move (i.e. faster in some areas than Chrome, slower in others)?
Also: the purpose Chrome has had in adopting JavaScript acceleration is that Google's web properties are JavaScript heavy, and accelerating JavaScript gives them a better overall user experience for Google Docs, GMail, and similar Google products. Was this a "compete with Chrome" move, or are other sites now following Google's lead, with increasingly sophisticated in-browser programs written in JavaScript, and so it was necessary without the Chrome pressure because of widespread increases in JavaScript overhead on average pages?
Cool stuff, but until one can write an optimized javascript virtual machine in it, I don't consider this project finished.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Of course know we know better.
It's just too shit.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Serious, non-hyperbolic, gets-stuff-done developers? Shit, I dunno, maybe you're right...
... whatever
Making it faster just encourages the cretins that write web apps to use even more javascript. Epic fail.
Not only do they have many copies of the code around, they also keep a lot of information about how each version behaves as well as mapping structures so they can switch between the versions while they are running.
I infer that this means a lot of code bloat. I have no sense of how this memory usage compares to the memory used for DOM storage and the like. Does anyone know if code memory is a significant contributor to the overall memory footprint of a WebKit based browser?
Using FIrefox on the Mac, I experience an ever increasing memory footprint if I keep the browser running for a long period of time, i.e. over the course of a few days. This is partly laziness, but it also reflects how I use online references. Often I have multiple pages open at the same time for references, and I don't want to close them until I finish what I am working on (typically coding). After I have found a lot of relevant information online, I really don't want to end the browser session and then restore everything when I return two work.
So how will WebKit perform in this environment? How does it compare to Chrome and Firefox for memory usage? If something besides FF didn't suffer from memory bloat I might consider changing. Any experience or benchmarks would be interesting to hear about.
Why is Snark Required?
"Just a decade ago, JavaScript â" the programming language used to drive web page interactions â" was thought to be too slow for serious application development. ... and now after 10 years of increases in CPU speed, increase in amounts of RAM and fevered development in optimizing it's now got to the stage where new Javascript kinds sorta competes with C++ on a ten year old machine.
As before, people will still write screeds on how it's really as fast as C++ this time, honest.
Interestingly, there's one language out there which regularly benchmarks better than C++, and it's called FORTRAN (suck it '95ers) and that's one of the few where you never see long articles on micro benchmarks claiming how *this* year it's as fast as C++.
Anyway, yeah, in some inner loop micro benchmarks where there's really good information available to the compiler, the dynamic languages (including Java) benchmark similarly to the native ones.
Basically it's all about aliasing and consistency. The more assumptions of independence the compiler can make about what doesn't alias, the better the optimizations it can make. This folds well into consistency: if you have an inner loop diddling a bunch of floats, then due to the aliasing rules this means that usually the loop bounds are fixed, allowing lots of nice optimizations.
FORTRAN does that really, really, really, REALLY well. C++ does it pretty well. C99 does it a bit better than C++11, though in practice pretty much all C++ implementations support the C99ism as an extension. Everything else is much worse, which means that a much smaller range of things can be optimized well.
And then on to memory. Firstly, garbage collected languages can only get with a factor of 2 for memory use (or so) before the computational cost of GC starts to dominate [citation needed]. Really, there are papers studying this. This has an impact on speed because it can make the cache coherency worse, and does also affect scaling on large datasets.
There's also the thing that memory allocation in C++ (and languages with a similar machine model) is largely completely free: unless you hammer the free store, it's all done on the stack which means the memory allocation is pre-computed at compile time as part of the function prolog. Sure, some of the dynamic languages can approach such things with escape analysis, but they can never do as well for the same reason C++ doesn't do as well as FORTRAN. With C++ you promise to never let local variables escape and the compiler can fuck you if you lie. With the dynamicer languages, the compiler has to figure it out to be correct.
Now interestingly, the things like the simple inner loops of something like naive matrix multiplication can be optimized quite well in other languages now, because compielrs are getting quite good at that. However, not much of my stuff is as simple as that. If you have bigger, more complicated inner loops like you often get in computer vision for example (my job), then C++ really shines.
This is why I've never been much of a fan of the "do the logic in python and the inner loop in C" style of things. Unless your inner loop is really simple, you have to do complex things in a not very expressive language otherwise it's slow.
These improvements sort of make that model obsolete: if you have a really simple inner loop, they can optimize as well as C++. It's everythin else where they can't.
TL;DR
Alisaing.
SJW n. One who posts facts.
These kinds op optimisations in Javascript compilation will barely speed up real-world web page performance anyway. The slowness is all in the DOM, the overhead introduced by compiling & running Javascript is already near negligible.
Pretty good is actually pretty bad.
If so, analysis of the impact ABP has on Firefox shows how much it bloats Firefox which it does even against any savings there are from not loading ads.
Did I miss something? Since when is JIT compilation allowed on iOS? Last I checked it was the AOT way or the highway. So I'm assuming WebKit gets the JIT blessing, while the rest of us peons still gets the short straw?
Half of all the serialization libraries for Mono and .NET, that work in Unity, seem to require JIT somewhere under the hood, which is a pain because I often only notice it (from run-time errors) AFTER it's built it into the project, meaning having to redo the whole thing with a different lib. (or go manual, if I feel like torturing myself) If only people would plainly state how their lib is designed under the hood, and which reflection calls it makes, then all this mess could be avoided.
Of course the biggest culprit is Apple. This and other meaningless and arbitrary rules and restrictions make developing for iOS a royal pain in the behind. I've lost count of the number of times we had trouble building due to bugs in XCode, problems with developer certificates, and provisioning profiles, testflight, needing an OSX machine solely for iOS builds, and all that crap. Nothing wrong with rules in principle, but there's no valid reason for the current mess.
Android may be a different mess, but at least I can test my stuff without jumping through several dozen hoops. /rant
is also the back end behind the Julia Programming Language, and its thoughtful use by the Julia guys has made that language blindingly fast as compared to R, Matlab, Python etc. etc., while still "officially" being an interpreted language. So yes, why not ?
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
When will implement the "unnecessary" things like proper support to integers, strings and etc.?
Religion: The greatest weapon of mass destruction of all time
The slowness is all in the DOM
What about canvas and WebGL?
While the smart guy uses Java Applet???
Not sure if you have a brain.
Nope ... ActiveX ;)
That's the same problem. Google's Blink is supposed to address JITting these calls. (Honestly, I don't know how using LLVM is supposed to achieve anything in terms of real world performance.)
Spends 99% in painting.
I don't know much. I do know that the latest WebKit however includes Mozilla's asm.js-optimized Javascript hints and if you turn this on you get huge boosts on hinted Javascript. So it appears there is room for boosts.
That being said the easiest solution would be to standardize more so that JQuery could drop out. There really is no reason that Apple, Google, Mozilla and Microsoft couldn't agree on very aggressive retirement timelines for browsers now that Microsoft is not trying to hold back the web.
As I understand the behavior of this option, it doesn't save the DOM, only the URLs, and it reloads them on restart as if the user had pressed F5. So if the web application has loaded a bunch of stuff through AJAX in response to user interaction, it won't reload. For example, if you have collapsed all comments in a Slashdot discussion other than the ones to which you intend to reply, the set of collapsed comments will be lost after a reload. Besides, it won't work at all if your laptop is out of range of Wi-Fi when you reopen the browser.
On my maschine (i7, MacBookPro 2013, Mac OS 10.9), the Octane Benchmark http://octane-benchmark.googlecode.com/svn/latest/index.html for Webkit Nightly is about 50% faster than Safari 7.0.3.
* Safari Version 7.0.3 (9537.75.14): 10391
* Webkit Nightly Version 7.0.3 (9537.75.14, r168728): 15544
* Chrome 34.0.1847.137: 17508
* Firefox 29.0.1: 14077
For fun, just because: (same maschine, Windows 7 on Parallels 8)
* Internet Explorer 11.0.7: 9627
Still, the DOM inefficiencies are avoided. Efficient drawing plus efficient, JIT-compiled JavaScript.
Also, it sounds like 'web workers' can help with the Spends 99% in painting issue.
That's the same problem.
Well, no, it's very clearly not. If there are issues, they're not related to the DOM.
If Chrome isn't efficiently handling OpenGL calls, that's a problem, and I'm sure they'll fix it. The code produced by the HotSpot JVM's JIT engine can call C code 'natively', so I'm sure V8 can be engineered to do the same.
(Did you really mean Blink rather than V8?)
I really feel like most of what people use jquery for today is already covered by the latest browsers. The last few projects I've done have been without jquery and I didn't write any work around code.
The big push would be just getting users to stop using the outdated operating systems/browsers and just upgrade.
I was developing before object oriented development took over.
I still don't any great advantage to OO development, and lots of disadvantages.
Web workers can only process data, and they can't directly contact the DOM.
It is a pain in the ass to do your vertex operations in a web worker's ArrayBuffer then hand them off to the main thread for renderer, but it does keep the browser responsive. Really though, rendering and UI should be called from separate threads. The JS event driven model is fucked for animation by its very design. Even the ~60hz refresh callback is shitty.
I can ALMOST get all the code to run in the GPU, and just have a few vectors for input states, however, anything networked is hosed.
Really, it's all happening exactly as predicted: Web browsers turn into a slightly slimmer version of Java (JS bytecode compiler), with a crappy version of "dynamic" PostScript (webGL/canvas). They've even started getting a raw audio interface, and local file/storage API. All we've ever needed is a cross platform media engine with sandboxed compiled bytecode language. Fuck all this DOM, HTML, CSS nonsense. Then, you can have HTML/CSS compile down into your PostScript-esque multi-media system... And that way folks could come up with different box models and different markup languages, etc. But, NooooOOO, we'll have to get there by some cluster fuck of a circuitous route which will be duct-taped together and buggy as hell.
I'd rather just scrap this whole WEB shit and just get Android on the desktop, stat. Even fuck Java/Javascript, and use an unencumbered compiled language like C, Lua, Go, hell even Dart (provided the last two are submitted to standards bodies, like the NaCl bytecode is). We're going to wind up with Web Apps actually being Web Apps anyway. Why go through this excruciating process. I swear all humans are masochists. It doesn't have to be Android, shit, strip the browser down to core components of graphics / audio / input / storage / VM and breakout the Lisp. Then Emacs will finally get google docs and be a descent text editor.
Interesting so your belief is jquery can be avoided. Well that would speed things up hugely.
In terms of the older browsers IMHO Google, Microsoft, Apple and Mozilla Foundation can make that happen. Microsoft was the biggest problem but now they are trying to decrease the amount of time people use older browsers. Bundling newer browsers with service packs and their regular policy of requiring service packs for support should do a pretty good job of driving people to newer browsers. Apple, Mozilla are already pretty aggressive and successful IMHO. Of course they would be more successful if more websites error on old browsers.
The other place to worry about forward going is older versions of Android. Gingerbread is still 16% of the market ( http://www.droid-life.com/tag/... ), as measured by the PlayStore which I suspect is worse than all users of browsers. And I'd expect this problem of lag to get worse not better with time as handsets get more reliable.
Seems like we're trying awfully hard to not notice that this is an Apple project.
...doesn't mean you should.
>> it's now possible to write sophisticated, high-performance applications
Why couldn't we have gotten a real object oriented language with real classes instead of souping up this painful, nested function oddity that was original only meant to add a little eye candy to 90s era web pages?!?! OK, yeah I get it https://xkcd.com/927/. But come on! Javascript sucks! Now it sucks with more power! And there is less incentive to ever replace it with something that doesn't suck!
Could it be that so many web application developers are young, started out with web applications, have never developed with better tools and don't know what they are missing?
In 20 years will we have car manufactureres developing engine control computers programmed in the Arduino IDE?
The really important question is how long does it take to compile? They haven't show how long it takes to fire up gmail, for example. V8 is extremely fast in terms of compilation times.
I wrote semi-complex JavaScript applications over ten years ago and the performance was actually pretty good, just so long as the client was not using Internet Explorer. Pages and actions which completed almost instantly on Opera or Netscape/Firefox would take 30 seconds to a minute on IE. I think this is part of what gave JavaScript such a bad name early on, too many peopel were IE users. In fact ,we used to think our code plain did not work on IE because of some of the bug reports we got, but it turned out if the user just waited a minute the script would complete. Again, this code worked almost instantly on Opera and Netscape, which we used for development.
Which raises an important point. With scripted languages, the language is not itself fast or slow, the implementation of the interpreter is fast or slow.
What idiot would want JavaScript for application development?
I'd rather just scrap this whole WEB shit and just get Android on the desktop, stat.
With Android on the desktop, how would you work in one application while referring to the output of another application? One example would be writing something while referring to a web page. Even if you dock your phone or tablet to a 1080p monitor, the Android CDD still allows applications to assume that the screen's size won't change after installation. It can only exchange the width for the height. Only applications specifically designed for Samsung tablets' multi-window mode can be displayed beside another application. The web, on the other hand, assumes that the window is resizable.
gcc is still useful for fortran, ada, and cobol. It also has more backend support for older architectures. That's probably their biggest advantage but at the same time, nobody wants to support them so they get removed over time (and anybody who wanted to support them would probably be better off working with llvm). Some of the BSDs stick with gcc 2.9 (current version is 4.9) for certain architectures.
Do you even lift?
These aren't the 'roids you're looking for.
My guess is that the amount of space this takes is comparable to a couple of full-sized pngs that the graphics guy forgot to scale down.
would it have gurt the submitter to have spent a few seconds more expanding the first instance of the use of LLVM just like JIT was?
sheesh...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Yes, I really *did* mean Blink. The problem lies not in the lack of "native" C calls (you mean in-line C call sequences in jitted code, I presume) but in the fact that V8 can't inline and inter-procedurally optimize the DOM manipulation methods - because they're opaque blobs of compiled C++ code and not some intermediate form of it. (Well, it could, in theory, but then it would have to include something like DynamoRIO and that would make the whole thing horribly complex, not to mention slower when compiling and less efficient at speeding up the compiled code, since the high level intent isn't there explicitly and has to be recovered somehow.)
If my understanding of what Blink is aiming at is correct, then all APIs exposed to both C++ code and JS code will eventually have two forms: a C++ entry point - the usual kind of compiled code - for any C++ client (for example, for people doing GUI+networking apps with CEF), and the same code for manipulation of the native data structures in an intermediate form that V8 will understand and will be able to inline and specialize at different call sites. Barring that, the APIs will be JS only (because web page clients seem to be their primary efficiency target - more people are browsing web pages in Chrome than using CEF apps) and C++ calls from C++ clients of Blink (like CEF apps) will have to go through JS.
I don't see why the same approach should be inapplicable to Canvas and WebGL. Isn't there a lot of Canvas calls that simply change the drawing state for later operations?
> Making it faster just encourages the cretins that write web apps to use even more javascript. Epic fail.
Well what do you expect since they took away our <BLINK> tag?
I'll see your senator, and I'll raise you two judges.
The main problem with javascript is it's hard to debug. If you can get past that it's a pretty OK language.
The runtimes are so variable that I'd think you'd need to really standardize on one runtime and stick with it forever.
There are times where being able to pass functions around in objects, etc is kind of handy, especially since you can pass them in as json at runtime. Again, that makes debugging really hard. If you persist them you can have objects that look the same with totally different implementations, which can be really confusing.
But as languages go, it's no more horrible than perl.
APK Hosts File Engine 9.0++ 32/64-bit:
http://start64.com/index.php?o...
(Details of hosts' benefits enumerated in link)
Summary:
---
A. ) Hosts do more than AdBlock ("souled-out" 2 Google/Crippled by default) + Ghostery (Advertiser owned) - "Fox guards henhouse", or Request Policy -> http://yro.slashdot.org/commen...
B. ) Hosts add reliability vs. downed or redirected DNS + secure vs. known malicious domains too -> http://tech.slashdot.org/comme... w/ less added "moving parts" complexity + room 4 breakdown,
C. ) Hosts files yield more speed (blocks ads & hardcodes fav sites - faster than remote DNS), security (vs. malicious domains serving mal-content + block spam/phish), reliability (vs. downed or Kaminsky redirect vulnerable DNS, 99% = unpatched vs. it & worst @ ISP level + weak vs FastFlux + DynDNS botnets), & anonymity (vs. dns request logs + DNSBL's).
---
Hosts do more w/ less (1 file) @ a faster level (ring 0) vs redundant browser addons (slowing up slower ring 3 browsers) via filtering 4 the IP stack (coded in C, loads w/ OS, & 1st net resolver queried w\ 45++ yrs.of optimization).
* Addons are more complex + slowup browsers & in message passing (use a few concurrently - you'll see) - Addons slowdown SLOWER usermode browsers layering on MORE - bloating memory consumption too ( (& bloat memory, 4++gb extra in FireFox https://blog.mozilla.org/nneth...) - Instead, I work w/ what you have in kernelmode, via hosts ( A tightly integrated PART of the IP stack itself )
APK
P.S.=> "The premise is, quite simple: Take something designed by nature & reprogram it to make it work FOR the body, rather than against it..." - Dr. Alice Krippen "I AM LEGEND"
...apk -
Fact: I anyone to disprove my subject http://developers.slashdot.org...
APK
P.S.=> It CAN'T be done validly - period... apk
APK Hosts File Engine 9.0++ 32/64-bit:
http://start64.com/index.php?o...
(Details of hosts' benefits enumerated in link)
Summary:
---
A. ) Hosts do more than AdBlock ("souled-out" 2 Google/Crippled by default) + Ghostery (Advertiser owned) - "Fox guards henhouse", or Request Policy -> http://yro.slashdot.org/commen...
B. ) Hosts add reliability vs. downed or redirected DNS + secure vs. known malicious domains too -> http://tech.slashdot.org/comme... w/ less added "moving parts" complexity + room 4 breakdown,
C. ) Hosts files yield more speed (blocks ads & hardcodes fav sites - faster than remote DNS), security (vs. malicious domains serving mal-content + block spam/phish), reliability (vs. downed or Kaminsky redirect vulnerable DNS, 99% = unpatched vs. it & worst @ ISP level + weak vs FastFlux + DynDNS botnets), & anonymity (vs. dns request logs + DNSBL's).
---
Hosts do more w/ less (1 file) @ a faster level (ring 0) vs redundant browser addons (slowing up slower ring 3 browsers) via filtering 4 the IP stack (coded in C, loads w/ OS, & 1st net resolver queried w\ 45++ yrs.of optimization).
* Addons are more complex + slowup browsers & in message passing (use a few concurrently - you'll see)
** Addons slowdown SLOWER usermode browsers layering on MORE - bloating memory consumption too ( (& bloat memory, 4++gb extra in FireFox https://blog.mozilla.org/nneth...)
SO - Instead, I work w/ what you have in kernelmode, via hosts ( A tightly integrated PART of the IP stack itself )
APK
P.S.=> "The premise is, quite simple: Take something designed by nature & reprogram it to make it work FOR the body, rather than against it..." - Dr. Alice Krippen "I AM LEGEND"
...apk
In a happier alternative universe, Java wasn't a goddam disaster when it came to applets and desktop GUI.
Even ignoring the horrendous bloat and browser-crashing tendencies of the Java of old, the security model has always been - and will continue to be - a bad joke. The way they conflate a platform in which secure software can be effectively developed and a platform which effectively resists malicious input programs boggles the mind. Java has a really very good track-record in the former, but its horrific track-record in the latter rather mars it...
Sun's reasoning, as far as I can tell, went something like this:
Screen goes wobbly, camera pans to Sun Microsystems strategy meeting
You know how we could make fast, secure software? Efficiently-implemented high-level languages! We know that C-family languages are an awful choice for developing secure programs... Ok then, let's implement a high-performance virtual-machine for our 'Java' virtual platform. We'll write it in C++, because high-level languages are slow. I'm sure the security will be fine, after all, we're calling it a sandbox, and if we call it that, it's sure to be immune from attack by way of malicious bytecode. Most C++ programs are vulnerable to buffer-overflows, but ours is a sandbox, so it's sure to be just fine.
A few years pass
This is going great. Java has been a great success in 'enterprise' web servers, so we'll push most of our resources at that. We'll keep promoting Java applets though, and we'll ignore the unending stream of security flaws in our 'sandbox', because developing a decent server-side JVM is more important. We could put our money where our mouth is and develop a secure JVM, in, say, Java, but no, we'll keep pushing this bug-filled C++ monstrosity, and keep pretending the 'sandbox' is trustworthy. The bloat can stay too, the server crowd don't seem to mind.
What's that? Someone went and built a secure JVM, in Java? Jikes RVM, you say? With a full JIT compiler and all? Nah, we'll carry on pushing our server product as a secure in-browser sandbox. Applets are sure to catch on any day now, security laughing-stock or not.
The problem lies not in the lack of "native" C calls (you mean in-line C call sequences in jitted code, I presume)
Yes, just so. Getting high-speed calls to C was a big break for HotSpot, as JNI had long been a real performance problem. People would have to optimise their Java/JNI/C programs to minimise the number of calls between the two languages. (Calling Java from C is still somewhat slower, by nature - HotSpot isn't in the business of producing C functions.)
V8 can't inline and inter-procedurally optimize the DOM manipulation methods - because they're opaque blobs of compiled C++ code and not some intermediate form of it.
Deep inlining is nice, of course, but I can't imagine it being a total game-changer for something like this. In a typical C++ program, there's an 'inlining barrier' when you link against a binary library. I could be wrong though, and I don't have any numbers to hand, but if we look at today's C-family compilers, whole-program optimisation is a really great feature, but it's not revolutionary.
I don't see why the same approach should be inapplicable to Canvas and WebGL. Isn't there a lot of Canvas calls that simply change the drawing state for later operations?
I don't get you.
Point-by-quoted-point:
"Require administrative access and modification on each computer you use. This is an incredibly bad idea on work computers." - by LordLimecat (1103839) on Wednesday May 14, 2014 @05:59PM (#47003997)
You must not know much about networking then: Logon script or even scheduled tasks/chronjobs can move hosts from a CENTRALLY LOCATED LOCATION to ANY PC or SERVER on your LAN/WAN - easily & "automagically".
(Your 'point #1' = SHOTDOWN IN FLAMES...)
---
"Affect far more than the browser and may impact other programs in unexpected ways, such as a game being unable to properly connect" - by LordLimecat (1103839) on Wednesday May 14, 2014 @05:59PM (#47003997)
Oh, really? Like AdBlock chewing up nearly 5gb of RAM in FireFox perhaps -> https://blog.mozilla.org/nneth...
??
(No, "don't think so" & hosts do a HELL OF A LOT MORE than crippled by default 'souled-out' to Google Adblock ever could + using my app, it only gets you an initial 1-5mb of hosts tops to consume RAM with...)
(Your 'point #2' = SHOTDOWN IN FLAMES...)
---
"Are incredibly difficult to troubleshoot when they contain zillions of entries." - by LordLimecat (1103839) on Wednesday May 14, 2014 @05:59PM (#47003997)
Are you mentally challenged? You can do THAT using notepad... & my APK Hosts File Engine 9.0++ 32/64-bit http://start64.com/index.php?o... makes it even easier... - totally "automagic"!
(Your 'point #3' = SHOTDOWN IN FLAMES...)
Continuing your last 2 points in my next post!
APK
P.S.=> Lastly - You haven't disproven the 17 points of unassailable FACT I extoll enumerated here showing how hosts files give users of them more SPEED, SECURITY, RELIABILITY, & even ANONYMITY online... now have you? Nope - & all your points shotdown in flames above too?? The SMOKE is just POURING off you... no 1st vs. myself on your end though, lol!
... apk
"Do nothing about same-origin ads (nor can they)" - by LordLimecat (1103839) on Wednesday May 14, 2014 @05:59PM (#47003997)
LMAO - what webmaster is going to get PAID for those? None - it's why you don't SEE THAT BEING DONE on 99.999% of websites (advertisers don't trust them on counts).
(Your 'point #4' = SHOTDOWN IN FLAMES...)
---
"Are about as subtle and precise as a sledgehammer; they are likely to wholesale break websites rather than just blocking ads.." - by LordLimecat (1103839) on Wednesday May 14, 2014 @05:59PM (#47003997)
Not with my program - I took a couple years (didn't release it to the public out of respect for webmasters is why, UNTIL ads started infecting people, badly & "out the door she went" to the masses - hosts do MORE than any single browser addons out there for more security, speed, reliability, & even anonymity online - period.
(Your 'point #5' = SHOTDOWN IN FLAMES...)
APK
P.S.=> APK
P.S.=> Lastly - You haven't disproven the 17 points of unassailable FACT I extoll enumerated here showing how hosts files give users of them more SPEED, SECURITY, RELIABILITY, & even ANONYMITY online... now have you? Nope - & all your points shotdown in flames above too?? The SMOKE is just POURING off you... no 1st vs. myself on your end though, lol!
... apk
"Also, the I am Legend movie was a poor shadow of the book, and Dr Krippen is the last person you want to go to for quotes. I suppose its a good poster-child for "unintended consequences", tho." - by LordLimecat (1103839) on Wednesday May 14, 2014 @05:59PM (#47003997)
You *may* like "The Omega Man" (Charleton Heston) OR "The Last Man on Earth" (Vincent Price) better - I've never read Richard Matheson's tale on it (though I know he did a LOT of "Vampire' based stuff... one of my favs. iirc, that he had something to do with as a boy that I saw @ 10 or so, was "The Night Stalker"... great one that - it's MY personal interpretation of what a VAMPIRE really is: A blood lusting maniacal evil monstrous fiend...)
* By the by - Dr. Robert Neville (Will Smith's portrayal of him, excellent imo) was a BIG inspiration to me to write this program in fact...
APK
P.S.=> Dr. Krippen's quote fits like a glove since hosts IS NATIVE TO YOUR SYSTEM, & yes - it works (better than ANY single browser addon solution out there, bar none, for more speed, & security + reliability AND even anonymity for less, as well as shoring up & securing DNS vs. its redirect faults in security too: multi-bonus!)...
... apk
In Physics, FTL = Faster Than Light. Nice pun. However, the sheer horrendous complexity of the system they described in the blog post indicates all that is wrong with Javascript as "the assembly language of the Web". Why, oh why, haven't we replaced Javascript with something cleaner, more robust and more efficient? It's 2014, people.
Its like that for all tech .. Emacs is a text editor OS.
A Mobile phone is a [strike]phone[/strike] a complete pocketable computer.
A Smart TV is a [strike]TV[/strike] Huge tablet computer that you interact with in a slightly different way.
It's true (thought YOU might find THIS, somewhat interesting) http://www.medicaldaily.com/me...
* Seriously here: "Will wonders NEVER cease..."
APK
P.S.=> Now, what was that Dr. Alice Krippen genetically engineered to cure cancer again? Let's listen -> http://www.youtube.com/watch?v...
... apk
"You know Im not going to waste time arguing with you point by point because we've been through this before in years past." - by LordLimecat (1103839) on Saturday May 17, 2014 @12:37AM (#47023405)
See subject-line above - I dusted you, yet again & you KNOW it, point-by-point here http://developers.slashdot.org... AND here too http://developers.slashdot.org...
* You don't have a leg to stand on - ,b>I busted ALL 5 of them out from under you in those links, totally, by disproving your "SO-CALLED 'POINTS'" easily...
APK
P.S.=> Keep "running" there, "Forrest" (lmao) & I was working in the Fortune 100-500 while YOU WERE IN DIAPERS boy (doing things you NEVER can or will - would you like to compare notes on that in terms of my doing great @ highly esteemed trade shows for commercially sold code to MY NAME TO THIS VERY DAY, or my appearing in books, newspapers, & computer science publications of great esteem as well + FAR more? Go for it)... apk
I never read the book and YOU need to get your "hooked on phonics" lessons out again (lol)...
* HOWEVER - I have seen every version of the film as I noted - Will Smith's portrayal of Col/Dr. Robert Neville WAS TRULY INSPIRING TO ME... hence, why I FINALLY released this (had it in parts since 1997 in character mode, & in 2003-2004 I wrote it up in GUI - not as polished as what is released for folks publicly NOW, here:
APK Hosts File Engine 9.0++ 32/64-bit:
http://start64.com/index.php?o...
Yet it worked JUST FINE: So, what MADE me release it in 2012? Partly the movie (ending before "Light up the Darkness"), & partly the "malware explosion" going on now... &, it works!
Currently/in 1 yr., I've gained roughly a quarter MILLION users already... I didn't EXPECT THAT, but... there 'tis!
APK
P.S.=> Yes folks - yet ANOTHER "butt hurt" little wannabe computer scientist takes a beating from me & has to "lash out" with libel... pitiful!
... apk
please go back to the 1990s :-)...theres quite a few of us who are pretty happy with the way the web has evolved