Slashdot Mirror
Firefox 18 Beta Out With IonMonkey JavaScript Engine
An anonymous reader writes with a quick bite from The Next Web about the latest Firefox beta, this time featuring some under-the-hood improvements: "Mozilla on Monday announced the release of Firefox 18 beta for Windows, Mac, and Linux. You can download it now from Mozilla.org/Firefox/Beta. The biggest addition in this update is significant JavaScript improvements, courtesy of Mozilla's new JavaScript JIT compiler called IonMonkey. The company promises the performance bump should be noticeable whenever Firefox is displaying Web apps, games, and other JavaScript-heavy pages."
None of these improvements feel any faster. Pages still load as quickly as they did a decade ago (provided your connection was fast). Why can't they make anything render faster?
Only the State obtains its revenue by coercion. - Murray Rothbard
I found it remarkable that the benchmarks only compared to earlier versions of the Firefox JavaScript implementation. A comparison with JavaScriptCore and v8 can be found at http://arewefastyet.com
With Mozilla's frequency of spitting out new and newer versions, I just can't keep up!
No problem, just turn automatic updates on.
Signature has left the building.
I haven't kept track with the JIT's that have been in Firefox. I recall the days when TraceMonkey and JagerMonkey were added to boost performance. Could somebody recap or tell why Firefox is abandoning the older versions or redoing them? I'm truly curious as to what they learned, what worked and what didn't work. Are they finding new usage patterns that warrant a new JIT design? Thanks.
Its good to see the focus of this release being an attempt to increase javascript speed by leaps and bounds. Modern webpages often use JS that goes way beyond anything people did 10 years ago (Jquery for example) and the complexities of what people do with javascript noticably slow down most webpages considerably.
http://interserver.net/
Its good to see the focus of this release being an attempt to increase javascript speed by leaps and bounds. Modern webpages often use JS that goes way beyond anything people did 10 years ago (Jquery for example) and the complexities of what people do with javascript noticably slow down most webpages considerably.
When I first learned to program in BASIC, I used to think that people should try speeding up C and Assembly language -- Make EVERYTHING run faster... Then I learned C and x86 Assembly and I realized, you can't speed up assembly language -- It's a perfectly optimized language, there's nothing under the hood to tweak. You might select a better algorithm, or better use registers, but this isn't changing ASM. C can't really be hugely optimized either, it's pretty close to the metal, but there there are a few things one can do to increase performance in the space of its minimal abstractions; fewer with a mature compiler on mature hardware/platform...
I always wondered what the deal was with JavaScript too, "Wow, it's getting faster, AGAIN?" Then I created my own languages and compilers and I learned: A sign of a horribly designed language is that the speed of its implementations can be repeatedly increased "by leaps and bounds"...
/. is now a little bit more bearable.
It won't run on about 55% of the macs out there.
They aren't being replaced. Each of these codenames is an additional optimization layer. The performance enhancements are cumulative.
Wikipedia goes into a bit of detail about it but in basic summary...
TraceMonkey was the first JIT compiler for SpiderMonkey released in Firefox 3.5.
JagerMonkey is a different design on TraceMonkey which outperforms it in certain circumstances (Some differences between TraceMonkey and JagerMonkey)
IonMonkey is another attempt at better perfecting the idea of JagerMonkey allowing even greater optimisations under particular circumstances.
However TraceMonkey, JagerMonkey and IonMonkey are part of SpiderMonkey as JIT compilers, not a replacement of SpiderMonkey itself.
The big difference with IonMonkey is that it adds an IR (intermediate representation) stage. That allows for much better and more modular optimizations at the cost of making compilation take significantly longer. The idea is that the JägerMonkey JIT has faster start-up time and will be used for not-as-long-running code while IonMonkey will be used to more heavily optimize very long running code.
That's not quite true.
TraceMonkey has in fact been removed, and JaegerMonkey may be too once the new baseline JIT being worked on now is done.
I'm not so sure that the Javascript (well, EMCA Script) LANGUAGE is the problem. The challenges with respect to rendering speed have more to do with the DOM and the interaction with the browser itself. The DOM is a bulky beast. When javascript listeners are assigned to page elements the code can in turn alter the DOM creating or destroying elements, all of which can trigger javascript functions, any of which can create or destroy more DOM elements. It's a properly tangled mess. Memory management in this environment is no small task.
A short summary:
1) TraceMonkey turned out to have very uneven performance. This was partly because it type-specialized very aggressively, and partly because it didn't deal well with very branchy code due to trace-tree explosion. As a result, when it was good it was really good (for back then), but when it hit a case it didn't handle well it was awful. JaegerMonkey was added as a way to address these shortcomings by having a baseline compiler that handled most cases, reserving tracing for very hot type-specialized codepaths.
2) As work on JaegerMonkey progressed and as Brian Hackett's type inference system was being put in place, it turned out that JaegerMonkey + type inference could give performance similar to TraceMonkey, with somewhat less complexity than supporting both compilers on top of type inference. So when TI was enabled, TraceMonkey was switched off, and later removed from the tree. But keep in mind that JaegerMonkey was designed to be a baseline JIT: run fast, compile everything, no fancy optimizations.
3) IonMonkey exists to handle the cases TraceMonkey used to do well. It has a much slower compilation pass than JaegerMonkey, because it does more involved optimizations. So most code gets compiled with JaegerMonkey, and then particularly hot code is compiled with IonMonkey.
This is a common design for JIT systems, actually: a faster JIT that produces slower code and a slower JIT that produces faster code for the cases where it matters.
https://blog.mozilla.org/dmandelin/2011/04/22/mozilla-javascript-2011/ has a bit of discussion about some of this.
aaaand I'll be abel to boot Linux faster!
I don't understand why this comment got +5. It is pretty misguided.
The statement:
> I realized, you can't speed up assembly language -- It's a perfectly optimized language, there's nothing under the hood to tweak
makes some limited sense in some contexts (one could argue that the microcode supporting the assembler on the CPU is repeatedly optimized), but none in this. The IonMonkey JIT does essentially optimize the assembler code[*], by rearranging it in various ways to make it faster. E.g. it takes stuff like this (in javascript, as I have not written assembler in years):
for ( var i = 0; i != 10 ; ++ i ) {
var foo = "bar";
}
and changes it to e.g. this:
for ( var i = 0; i != 10; ++i ) {
}
var foo = "bar";
possibly then this:
var foo = "bar";
This is an optimization and it is performed at assembler level (Again: the above is not meant to be read as JavaScript, but assembler).
The other statement that really sticks out is this:
> A sign of a horribly designed language is that the speed of its implementations can be repeatedly increased "by leaps and bounds"...
This simply highlights that the poster really do not understand the goals behind crossplatform languages, such as Java, Dalvik, JavaScript, lisp, ML, Python, Perl, and so on, or the goals for weakly typed languages.
[*] It works on an abstract representation of the assembler code, but it might as well have been working directly on the assembler, was it not for the fact that this would require it to learn to many assembler variants.
because sometimes law enforcement doesn't know there are other browsers.
lynx renders..
09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
The webmonkeys get hold of it. Do everything with it. They're ecstatic! Finally something that runs their javascript nice and fast!
So they throw more js into their webpages. Drop in a few more libraries, for their convenience. Of course, they're testing the stuff to the dev server that's at least as fast as the production server but sees only a small fraction of the load, and they have gigabit from desktop to server.
Thus, their websites become that much more crappy for everyone else, for everyone who doesn't have the lastest accellerator, or a nice and fast connection to an overspecced and mostly idle server.
It's happened before, it's happened again. Feh, if your desktop is old enough (single core, less than 2GHz these days) then between the crashes due to low memory you can actually notice when, say, jquery gets an update: Everything that uses it gets slower.
This is the state of websites, and as things stand, faster browsers mean slower websites for non-webmonkeys.
Its horrible performance on FB is one of the reasons my customers are using a Chromium variant right now. Does anybody know how it does as far as CPU loading? I have to support a lot of low power systems and since around FF V6 its been completely unusable, especially for watching SD video, but even opening new tabs can cause FF to slam the CPU to 100%.
Anyway i don't mess with beta software anymore (enough bugs in the releases, thanks ever so) but if anybody has a low power AMD bobcat or Intel Atom I would like to know how this compares to Chrome.
ACs don't waste your time replying, your posts are never seen by me.
how is it horribly misguided, when you're one example proves his point.
that you cannot optimise the ASM layer, cause it's already directly on the cpu, but you can optimise the algorithm.
your example did just that and this optimisation is done FAR FAR above the assembly level.
I invite you to go read http://en.wikipedia.org/wiki/Program_optimization#.22Levels.22_of_optimization
And perhaps http://en.wikipedia.org/wiki/Tracing_just-in-time_compilation
As I said: The statement might make limited sense in some contexts, but not in this.
Actually, I shouldn't say that. Firefox started breaking on github around version 17.0. Many of the sub-project pages, e.g. Issues page and the Markdown - Raw viewer, redirect to a "Page did not load in a timely fashion" error page. This happens consistently on every github project. Unless the github team has done something weird on their end, this is another in the lengthy amount of compatibility problems Firefox is beginning to have.
That was about the 64-bit build, running exclusively in 64-bit mode. Running the 32-bit version of Firefox on 64-bit Windows is still fully supported. The big problem with 64-bit Firefox on Windows was that, unlike Linux, plug-in developers (read: Adobe) didn't port their plug-ins to 64-bit, and only released them in 32-bit variants.
What I liked about the previous mozilla javascript engines was that they supported multithreading. That made them suitable for web-server use. In contrast with, for example Chrome's V8, which is not suitable for server use (unless you are prepared to spawn multiple processes instead of threads, but this is very expensive performance-wise of course).
So I hope they support multithreading.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
I have to support a lot of low power systems and since around FF V6 its been completely unusable, especially for watching SD video, but even opening new tabs can cause FF to slam the CPU to 100%.
Well, yes. I have an eee 900 (which is single core). I found firefox and chromium both to be pretty pathetic at playing video. Even in HTML 5. Actually, I'm not sure how they manage to make such a meal of it. It's really terrible. They're basically no better than flash. Perhaps even worse.
I used to use flashvideoreplacer, but that doesn't work any more. I now use a greasemonkey script which basically replaces youtube videos (perhaps others?) with MPlayer, and it can decode 720p just fine in realtime.
Firefox can slam the CPU to 100%. Chromium is multiple threaded, so it can slam the CPU to 100% with a load average of 57 making the machine grind completely to a halt.
Chromium feels a bit snappier in that the UI elements give visual feedback quicker, but it doesn't actually seem to get the pages up faster. I switched back to firefox after a while.
SJW n. One who posts facts.
In retrospect, "text/javascript" for the first two items should be "bin/javascript".
It is dangerous to be right when the government is wrong.
its not like javascript were the problem of any current browser, but all of them work on improving the js engines instead of taking a break from the x-th js improvement and build a better browser ui. For example mozilla should fix stuff like menubar, favicon, statusbar, ... all the "we need to look like chrome" stuff. hey, if i want something which looks like chrome, i use chrome. If there weren't all the extension fixing this crap, maybe i would be a chrome user for a long time, since firefox gave up its own identity and started to clone chrome.
Then I learned C and x86 Assembly and I realized, you can't speed up assembly language -- It's a perfectly optimized language, there's nothing under the hood to tweak.
Well, not really. You can't optimize perfectly optimized assembly any further, but that's just tautology. You can optimize even quite well written assembly further, especially on modern CPUs with various selections of functional units, variable pipelines, multiple instruction dispatch per cycle, vectorising etc.
In fact, the days have generally passed where I can write better ASM that what gcc can output from a C/C++/Fortran program, because it has much better knowledge of the CPU internals and is generally better at doing things like register allocation etc.
In terms of Fortran, C99 and GNU's extensions to C++, it can even be told when pointers don't alias, so one of the final benefits of assembly has vanished. With good SSE scheduling and support from within higher level languages, the other main benefit of assembler has vanished.
It's now at the point where C++ is generally faster than assembler for all but the best of assembler programs and some very specific cases, for instance where it helps to have direct access to something like the CPU flags.
One reason is that the optimizers have got really, really good. They can even figure out when you're stepping through a 2D array in the wrong order can re order the loops. They are also excellent at removing redundancy which means you can write simpler code (and therefore write more advanced algorithms much more easily) without worrying about redundancy killing performance.
The optimizers are amazing and do an awful lot. This is why optimized code is more or less impossible to debug. Once it does passes of inline, partial redundancy emimination, loop unswitching, fusion, strip mining, dead code elimination, constant propagation, alias analysis, loop unrolling, modulo scheduling and register allocation, a given instruction probably doesn't correspond to any one line of code at all, so no stack trace is even possible.
And as for assembly, things aren't so simple there. Look at the difference between the faster clocking P4 and the much faster performing Ivy Bridge i7. The result of that is essentially that the i7 has an optimizer inside it which runs at 3.3 GHz and performs many of those steps real-time before actually farming out instructions for computation. IPC is all about optimizing assembler as much as possible.
Then I created my own languages and compilers and I learned: A sign of a horribly designed language is that the speed of its implementations can be repeatedly increased "by leaps and bounds"
It depends on what you mean "horribly designed". Many languages are designed to be easy for some particular task rather than maximal performance. It's hard to argue that Haskell is poorly designed, but optimization is a very tricky problem and performance has certainly increased greatly as optimization techniques have become well understood.
Even FORTRAN, which was specifically designed to be optimizable even given the non-existant state of the art at the time (optimizing compilers were essentially invented for FORTRAN) has seen significant improvements in the performance of the compilers.
C and C++ which were designed to be close to the metal and so not need much optimizing have also got much better with improved optimizers.
It seems that the key to a high performing language is to allow the user to tell the computer as much as possible about the program's intent, so that things can be proven and optimization can be performed.
SJW n. One who posts facts.
I would prefer a more efficient lower level intermediate language, common to every browser that could be targeted by more languages.
People don't change browsers much if those I know are any indicator. When they do, it typically is because one or more of three events occurred. The first is when they're actively shown an alternative by a preacher. The next is when they compare a site in different browsers and notice a material difference, eg when designing it. The last is when intense frustration leads them to actively seek alternatives.
In my (non-representative) sample, FF has been hemorrhaging irate users for several years now. And the list of thinga that irritated them seems unending. So this feels like too little, too late.
Can we get OpenGL based hardware accelerated rendering already?
You should already have it :)
Tools > Preferences > Advanced > General > Browsing: "Use hardware acceleration when available"
I can't wait to see what kind of malware this type of scheme would produce. I have no proof, but if feels like running a compiled bytecode would be easier to exploit than text based javascript.
For fuck's sake - 5 layers deep of scripts? Six? More? No Script has become nearly useless when I have to turn on 5 or 6 LAYERS of scripts and 45 different scripts just to format a page. And on a good day they slow everything down to level of running it on a 486DX100 machine circa 1996.
Well, it would actually be a step back for usability for web developers. If you haven't tried an interpreted language, you probably don't understand why, but it does actually matter.
Also, I could be wrong, but I think state-of-the-art Javascript compilers don't actually spit out a binary, instead they sort of grow the program in place. The old separate-compilation idea makes some optimizations much harder compared to a JIT that can actually watch the whole program + libraries run.
This is especially true for a dynamic library like Javascript because most of the speed up comes from inferring the types, e.g. instead of representing [0, 1, 4] as an array with three objects, it can be allocated as int a[3], and the code can add the ints directly rather than having to unbox operand 1, unbox operand 2, add them, and box the result. Without some kind of help from the programmer, it's really, really hard to infer types automatically - so you basically have to watch the program run to see what types actually occur.
Do you have a source to back that up?
I'm personally under the impression that most pages are slow because of rendering speed, not because of Javascript execution itself. I see improvements in Javascript compilers mostly as an enabler of future tech, not something that significantly speeds up existing pages.
Of course, with a couple of big libraries, parsing time is perhaps important.
./firefox ./firefox: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
bash:
Linux koala 3.6.6-1.fc16.x86_64 #1 SMP Mon Nov 5 16:56:43 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Why can't web developers compile the javascript and provide that?
The whole point of the web and the reason javascript has become what it has is because we can write things now as websites that once would have been native applications that only worked on a single platform. If we had to go to the effort of compiling the web application before shipping it we might as well use something like Java, C or C++ and then ship native applications with all the increased flexibility that provides.
Instead we now use websites for very complicated applications using AJAX interactions and such that are often hosted on intranets in order to keep latencies low. The main driver to this has been the cross platform support that the modern web provides for the end user. Even stand alone applications that require no interaction with anything outside themselves are often now shipped as web based apps if there are not IP issues to do with protecting the code (most of the time there is an issue with distributing the code which is why Java is so popular).
The biggest issue though is probably that if a browser vendor suggested an approach like you suggest they would be shooting themselves in the foot as it would increase the workload for each additional browser a web application needed to support far more than at present. If I had to produce a compiled version of the JS libraries for opera then there is no way I could justify that cost to management based on their browser share. It might even be that things like Opera and Firefox started falling off the supported list for many clients since they might be only interested in the corporate space where IE is still dominant. I think I could just about make a case for supporting Safari based for Macs but in other cases I would have to work impossibly hard too justify multiple browsers supported on a single platform when considering the increased costs for each.
I dont read
I can not recommend Ghostery enough. More pragmatic than NoScript.
It's been done. A lot.
http://www.linuxjournal.com/article/6863
http://www.boutell.com/cgic/
http://www.cs.tut.fi/~jkorpela/forms/cgic.html
Thank you for the comparison. Why can't web developers compile the javascript and provide that? I do understand that each runtime (browser) is unique...
...and that's the problem. The only way to do this well would be to have some sort of standardized bytecode that browsers could compile to, and there is no such standard at the moment. As long as each browser goes through its own intermediate formats, you'd have to have different builds for different browsers, and nobody would bother to maintain them properly.
The real problem is jquery itself. People won't even bother learning regular javascript, so jquery is required for all the crap they write.
And then they can't even be bothered to write their own code using jquery either and they download pre-made code that requires jquery to run, ending up with pre-written code calling jquery calling javascript.
All that for a fucking mouse-over effect with pre-loading of images that should have been done with CSS and sprites in the first place.
Get free satoshi (Bitcoin) and Dogecoins
The problem is that as runtimes evolve the compiled format changes. Furthermore, the end result of the compilation depends on the exact processor being used by the user, and at least in SpiderMonkey on things like the location of the Window object in memory.
Not only that, but the final compiled version is unsafe machine code, so a browser couldn't trust a web page to provide it anyway.
So pages wouldn't be able to provide a final compiled version no matter what. They may be able to provide bytecode of some sort, but again the bytecode format browsers use is not fixed (assuming it exists at all; V8 doesn't have a bytecode) and compilation of JS to bytecode would have to be replaced by some sort of bytecode verifier for security reasons, so there may not even be much of a performance win from the switch.
That's what I've been reading, anyhow. My sources didn't specify if this would only be on OS X or also on other OSes which you might run on the same hardware.
Hail Eris, full of mischief...
E pluribus sanguinem
I have used ion monkey for quite some time - I was running nightly ion-monkey builds before it was merged into the 'regular' nightly code. The speed up is at best minimal from a user perception except on really heavy js sites. And if anyone from the dev team reads this, there is a dreadful memory leak in the latest 20s.
> C can't really be hugely optimized either,
You've never worked on a C/C++ compiler have you? :-)
C most definitely can be sped up. Why do you think we even have the "restrict" keyword?
http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html
Function temperature provides hints to the compiler on what code should be inlined.
The back-end of a compiler has a lot of room for generating optimal code IF it understands the target hardware. i.e. Minimizing register spill is extremely important on x86 with its lack of GP registers, reordering instructions to minimize pipeline stalls, known when/where to issue read/write barriers, etc.
One of the major features / problems in C is that arrays = pointers. This is a MAJOR headache WRT to optimizations in a C compiler. In a "clean" language without pointers the compiler is able to strongly infer a lot of assertions; once you throw pointers in the mix the potential for optimizations goes right out the window since the compiler is no longer able to "pre-calculate" offsets.
The lack of strong type inference in C also limits its optimizations.
The LISP / Haskell guys don't have pointers and as such they force the burden on the compiler to "churn" through the type inference system in order to generate optimal code. This leads to a smaller, cleaner compiler, at the expense of a developer needing tons of RAM and CPU to just get the same level optimization a C compiler can do in half the time.
At the end of the day it is all about instruction ordering and caching. Keeping track at what time are what variables "live" and where.
Uhhh...last I checked there is a 64 bit Flash for Windows and it runs just fine...I have it installed in Pale Moon X64 on my hexacore at home.
But that don't change the fact that since chrome came out and started drinking their milkshake FF has gone downhill with regards to low power devices, as I said i have to support all kinds of systems, from the latest multicores to Atoms and older office machines and FF since V6 has just been terrible on these. SD video is a slideshow, opening new tabs, hell even scrolling bookmarks can cause FF to peg the CPU at 100% and even make the UI unresponsive, that is simply unacceptable.
So while i hope that they fix it, as I have yet to find a replacement for the FF "download as MP4 or FLV" YouTube plugin which some of my home users love, so far I've tried every new release, as well as several variants like Waterfox and IceDragon and Pale Moon and so far no dice, they ALL peg the CPU, which leads me to believe its a problem with Gecko.
ACs don't waste your time replying, your posts are never seen by me.
Totally agree on that one, I have the same experience. Well, I never switches to Chrome, but everytime I try it out that the above conclusion is mine too.
New things are always on the horizon
So which software, or pretty much any software really became more efficient ?
Yes, many things get optimised in software, but the total "product" usually supports more hardware or software combinations and has more features and thus becomes slightly more bulky when you look at them year over year.
New things are always on the horizon
That was about the 64-bit build, running exclusively in 64-bit mode. Running the 32-bit version of Firefox on 64-bit Windows is still fully supported. The big problem with 64-bit Firefox on Windows was that, unlike Linux, plug-in developers (read: Adobe) didn't port their plug-ins to 64-bit, and only released them in 32-bit variants.
Which means potentially better security in a Windows program version than a Linux version for once, and one less thorn in the side of Windows/Firefox users. But no no no... Mozilla can't just allow that. That would be just too much of a good thing for their users.
Thank you. I'll look into that.
It is dangerous to be right when the government is wrong.
It looks like you are correct. Thank you! However, there are some details that are not clear, so I posted this question on StackExchange which might interest you:
http://stackoverflow.com/questions/13591069/why-use-application-javascript-as-opposed-to-text-javascript
Again, thank you.
It is dangerous to be right when the government is wrong.
I haven't noticed any problems.
Is it recent? Firefox had these issues when 3.6 and 4.0 were out 1.5 years ago, but not anymore. Benchmarks show Firefox has greatly improved and on my own computer using peacekeeper benchmark had a higherscore for Firefox than Chrome. Perhaps your customers are not having hardware acceleration enabled for some reason in FF? Chrome is enabling more and more of these GPU features on by default. Older intel 910 or 8x is so buggy it is not worth turning it on and then the video is choppy. A good incentive there Hairy to sell a new system ;-)
I do not have a bobcat or an Atom but my old PhenomII shows both about the same in performance. However, under VMWare Firefox 3.6 on this is a POS. Disk access is slower because it is in a virtualized envrionment but it is just sluggish on my same system.
http://saveie6.com/
I have yet to find a replacement for the FF "download as MP4 or FLV" YouTube plugin
I have found one that works great in Comodo, but I only have it on my home PC. I'll tell you what it is called and where to get it when I get home. It might require a manual install, but other than that it's effectively bulletproof as far as I have found.
C makes 1970s assumptions like there will be only 1 thread (no parallelism), no such thing as SSE, and few built-ins (thus requiring a variety of libraries that may make similar errors). Modern technology offers C extensions (OpenMP), better libraries, better compilers which have utilize modern architecture targets. Even Java now auto-parallelizes some code that it once ran linearly. There is enormous potential for non-trivial code to better-fit the hardware.
Science & open-source build trust from peer review. Learn systems you can trust.
If it has the single "download" button in YouTube I'd sure appreciate it Crosshair, i have a lot of older customers that like to download little funny videos and send them to their relatives (yes I know they could just send the links, but they don't want to, they want to send the videos, and as the tech its my job to make sure they can do what they want to do with their machine, even if its dumb) and frankly I haven't found anything that is THAT simple, i install it and they just have a big "download" button under the video, hell my mom could figure out how to use that.
The few I've found were not only a PITA to install but frankly required a bunch of steps to get the video, that isn't gonna cut it with home users, simpler the better is the way to go. So if you know a way i'm all ears, just shoot it in an email to the address in my UID if you don't mind as I'm getting a lot of posts responded to so this one is probably gonna be buried soon. Thanks.
ACs don't waste your time replying, your posts are never seen by me.
Yes, apparently they did, but it's still quite recent (and only works on Windows 7). Naturally, it took them years to come out with it after 64-bit Windows came out (yes, I'm counting XP x86_64, it was a 64-bit desktop OS). Whether or not Adobe came out with it now, they're hardly the ONLY plug-in developer. The problem of plug-ins not being ported to 64-bit browsers on Windows is hardly just Adobe's. That being said, I'm not sure why you think Flash is the only plug-in Adobe makes.
Yes, we get it, you're a person that works on everything, and so you know what you're talking about. That's nice. Some of us have been using Fx just fine (including myself), only we don't complain about it every time it comes up on Slashdot. You're not going to convince me to stop using Slashdot because you named a list of machines you work on and say that Firefox has been awful on every single one. If Fx stops working well on my machines, then I'll switch, but I'm not going to switch just because someone says Fx doesn't work for them.
If you're talking about HTML5 video then fine, but if you're talking about Flash, why in the hell are you blaming the browser for that? Naturally, on the three computers I regularly use, I have exactly zero of the problems you mention, with both HTML5 and Flash videos. Anecdotes are completely pointless, because everyone can have different experiences. Yours aren't special because you can list a lot of computers.
The security bit is nonsense. ASLR and DEP are always opt-in, for both 32-bit and 64-bit, unless (except for DEP) the user changes it to cover all programs. There's nothing else I can find that would cover application security and be different for 32-bit and 64-bit programs.
Apparently Flash has been ported to 64-bit browsers on Windows, but that's not the only plug-in out there. Why would they maintain a piece of software that no one would use, because they can't do X on it?
And how would it be one less thorn in the side of Windows Firefox users? I use 32-bit Firefox on 64-bit Windows constantly, and have no problems whatsoever with it.
OK, here it is, Ultimate YouTube Downloader for Chrome.
http://www.chromeextensions.org/utilities/ultimate-youtube-downloader/
It requires a manual install, but that is it. You click on the download button and select from the drop-down which quality/format you want and it automatically puts the video title as the file name, after adjusting for characters that can't be in file names of course, and then saves it to wherever you have the browser setup to download files to.
I don't see how it could be any simpler, other than an option to automatically download one select format/resolution. Hope it works for what you need.
Thanks Crosshair, I slapped it on the flash i keep in my wallet so when i come across those customers that just love the FF extension i can just install that one in Dragon instead.
I personally don't need it as I switched to Jaksta streaming media converter a couple of years back, well worth the money IMHO as it'll download from pretty much any site, even captures streams. But for my customers that live for YouTube downloader I'll have it ready to go, thanks.
ACs don't waste your time replying, your posts are never seen by me.
You're welcome, I'll check out Jaksta and see what that does. Been plenty of videos I've been unable to download that have disappeared later on, so such a tool could be handy.
What you do with Jaksta is launch it and then click on whatever video you want to download and pretty much if you can play it in your browser Jaksta can download it, even stuff that is only supposed to be streamed, be it flash or even WMV.
I'm pretty sure that Jaksta has a trial of their media recorder so you can give it a spin and see if its for you. I've had it for a couple of years now and so far i have yet to find a video it can't download.
ACs don't waste your time replying, your posts are never seen by me.
Whoosh. Apparently you don't get the point. I was slamming Flash, Java and similar plug-ins.
Here, let me try to spell it out for you: The 64-bit version of Firefox doesn't support insecure plug-ins; therefore, unless you would run NoScript anyway, the 64-bit version of Firefox is more secure. But apparently those shiny insecure features are more important to Mozilla than the security benefits. Get it?
If you have to explain a whoosh that much, is it really a whoosh? One generally only says whoosh when it's pretty clear what you're trying to say.
Also, how does that make sense to say "one less thorn in the side of Windows/Firefox users" when users normally want the plug-ins (or else they wouldn't install them)? Next time, before you say whoosh, try to make your point clear so that someone that isn't you can easily figure out what you're getting at.
Wow. I didn't know there were such strict guidelines (or any at all) on the use of fucking Internet slang here on Slashdot.
There's this thing called "common courtesy" which includes "not criticizing someone for not getting something you didn't make clear in any way at all, and half of which still doesn't make sense." Of course, nothing requires you to be courteous on Slashdot, as you astutely pointed out, but that doesn't mean it's not a good idea.