MemShrink progress report, week 23
blog.mozilla.com
blog.mozilla.com
From what I know, IT-departments don't like that.
It's important to note that, yes, it is true that some IT department are reactionary and dislike the new release process, BUT that doesn't mean that are right.
There are plenty of analogous automatic update systems which are used every day in IT departments. Virus checkers are the canonical example, but increasingly SAAS applications are the same.
Many IT departments are stuck in a 1999 mode of trying to control the exact version of every software they run.
Fortunately businesses are wising up - firstly IT tried to tell them they couldn't use iPhone because they "weren't approved". That worked until the CEO demanded one.
Now some try and say rapid browser versioning and automatic releases are bad. They'll get over that, too, or otherwise they'll be ignored.
(And don't bring up the example of the IE6 websites that must use IE6 forever more. That's a problem to solve, not an excuse for keeping an entire enterprise locked to outdated technology.)
- Cross-testing. My team is responsible for roughly 150 enterprise apps of varying scale, platform, age, and quality, ranging from a few disgusting classic ASP apps to monstrosities we pay nearly $1m/yr in licensing fees for. It is neither feasible nor the best use of people's time to keep up with 12wk release cycles.
- Security. There are good reasons why not to allow local admin privileges for most users. Chrome is the first browser we've deployed that we've allowed auto-update to remain enabled, and if it didn't provide silent updates that didn't break extensions AND install in user space, we'd never have been able to do that.
- Antivirus. I'd have thought you'd know this based on the verbiage in your comment, but apparently not. Enterprise AV doesn't work like consumer AV. An orchestrating server software is installed, at which configurations are defined and from which rule sets are distributed to clients.
- Big ERP. As an example, Oracle ERP isn't compatible with every version of Java, and god help you if your users are running Linux and get confused between the official JRE and independent distributions like OpenJDK & Iced Tea. If your apps team has built extensions/interfaces to the ERP that also rely on Java, it's entirely possible or likely that they're dependent on a specific version & patch number, too.
I could go on for hours.
I don't think anyone -- at least none of my peers or colleagues -- would say rapid browser versioning & automatic releases are bad. Not being able to manage them can be risky. We have recently standardized on Chrome, but have deployed Firefox 8 as a fallback just in case, and our Windows users have IE8 (or 9, in the case of the few running Win7). For both Firefox & Chrome we included IETab in the MSI we distributed, customized with rules based on app compatibility. We also distributed a custom PAC file with proxy rules. Coincidentally, most of the web developers -- even if they prefer Chrome for browsing -- still prefer Firefox for dev & testing due to the superiority of Firebug & a few other add-ons.
The old IE6 browser that can run your ancient intranet apps, and the new Chrome that can run the new SaaS apps. The new one auto-updates, and the old one doesn't.
Clearly IT departments are capable of supporting multiple programs since that's what they do when someone purchases native software instead of a ASP app.
Note: about 80% of our employees with computers don't have internet access at all, with the exception of a proxy rule that allows them to access Google Apps (and a few other select SAAS apps). You can imagine this complicates things a wee bit.
Most people don't understand the "old IE6 app" issue - it actually applies to a very, very small number of apps. It isn't that these apps don't display in other browsers because of bad HTML - it is because they use weird IE6 only technologies. Microsoft came up with some very strange things over the years (look at Data Islands: http://msdn.microsoft.com/en-us/library/windows/desktop/ms76...), and fixing these apps isn't just HTML tweaking. Of course, if you still have a Data Island app around these days your IT department should be fired...
I just think it is totally, absolutely and completely wrong.
I think that the "risk-averse" nature of corporate IT doesn't serve business, it holds it back.
Things like "custom ERP extensions" are excuses. If a business builds it's own software, then it should expect to maintain it.
(WRT the anti-virus thing: yes, I understand this. I also know how this really works in 95% of businesses - the vendor sends a new virus definition file, and IT rolls it out to the business when they get in the next day. In another 4.9% of businesses someone will load the definitions on a SOE desktop, check it reboots and then roll it out. It is only in that 0.1% of businesses (if that!) where IT actually adds any value to the virus definition rollout process at all. In all other cases they remove value by holding back updates until that are run through the "IT process")
That's the main reason why app INSTALLS should require admin privileges in general.
That's also why Chrome model for updates is a double-edged sword, and security wise its bad.
For Entreprises, you should be able to manually push out Chrome updates without getting any admin prompts or the need for admin privileges.
Regardless, for non-Entreprise use, seemless update of the browser is something one wants to have.
AFAIK Firefox plans to have an authenticated updater service running for that. It means you can't subvert the Firefox binaries to capture/control/whatever the user's pc as you need admin privileges to upgrade.
And the updater process is a tiny process that verifies signatures before upgrade, thus the likehood that it gets compromised or has bugs is very low (specially compared to browsers which are one of the most complex piece of software ever made)
Arguably, this is the correct place to install, as it means that the application is usable by anyone on the PC, rather than having to be installed for each user individually.
You can find more information here: http://www.brianbondy.com/blog/id/125/
That's why admin privileges are required for accessing Program Files to begin with.
Using a separate updater process is actually the clean way to go, on Windows.
Whereas Chrome has a stable extension API, Firefox really breaks at least one very popular plugin withe each "release." So then you get nasty warnings about incompatible plugin versions and whether or not you want to look up a new version of the plugin. Whereas Chrome a) doesn't break plugin APIs very often, even in alpha and beta channels and b) automatically updates plugins anyway.
The openness of their API is certainly a two edge sword; in one way, it lets developers dig deep in the browser's internals, which means addons can be immensely more powerful than on Chrome; on the other hand, it means they have a dependency on those same internal APIs.
They've launched the Jetpack SDK as a stable API for addons that doesn't require browser restarts to install them, but almost no one uses it:|
It's not really the API which breaks, it's the versioning.
It's beyond inexcusable that this is still not fixed, and I'm sure its part of the reason the userbase declined further.
It is definitely the API which breaks in many cases. These 6-week updates change APIs, both Web APIs (used by both websites and addons) and internal APIs.
For example, websites - not addons - can and do break with Firefox and Chrome 6-week updates, because even Web APIs are changed in these rapid updates.
It is true that versioning is a problem as well, however.
Firefox has been forced to follow Chrome on this AFAIK because otherwise some website features (popular ones.. specially GDocs) wouldn't work optimally. Even right now, loading Google sites is faster (specially GMail) on Chrome because only Chrome has SPDY support (coming in a Firefox near you in some weeks thanks to the fast release mechanism!)
The Web APIs aren't stable at many levels, and HTML5 ain't standard. It's a bunch of drafts and some are even conflicting (hello audio APIs).
It seems to me that Google is the main company right now pushing in new drafts and protocols - using it to make other browsers incompatible. Generally the drafts are technically fine and good, the issue is the way they're used to kill diversity and obtain complete web (or "internet") control.
You can start to see a lot of "you need Chrome to see this website. Chrome, the fastest browser on earth by Google! <click to download>.
Specially true if you use Opera or IE which do not update as often as Firefox and Chrome.
https://developer.mozilla.org/en/Extensions/Bootstrapped_ext...
But I have to use several more extensions to get back some features that were taken out.
LuaJit does it by using a very fast interpreter and a tracecompiler. The secret souce seams to be a SSA based bytecode. Im not sure how the Mozilla interpreter works but since its a relice I doute that its a bytecode optimized for interpreting and compilling. If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise.
If the language is to hart to interpret one could write a simple first stage method-jit and a trace-jit behind it. Exiting times in JIT-Land spezially for dynamic languages. Lets see who comes out with the best implementation in the long run.
If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise.
I'm not an expert but the existence of "SpiderMonkey" "TraceMonkey" "JeagerMonkey" and "IonMonkey" (which can apparently be disabled independently) seems to suggest they have no problems with that.
[1] I presume there is always a fallback interpreter as well.
I don't read anywhere that the method-jit is better in optimizing, i only that the trace-jit dosn't find enought stuff to win. Once you have a good trace you can optimize it like crazy.
Mozilla seams to move in this direction, they have thrown out Tracemonky but in the longrun add one again and as far as I know the want to throw out spidermonky too. The diffrence would be that they would have more power in the method jit and less in the trace jit.
The reason I said that they would have reimplemented alot is that for the intepreter/simple-jit method and trace-jit to work well you need a nicly designed bytecode and I'm not sure they have one atm (I don't really know). There existing implmentation would have to be reworked to use a new bytecode.
How does this differ from what in fact happens?
When theory and reality conflict, reality is correct. If tracing JIT didn't work as well as you expected, it is not reality that is wrong.
Well I think the evidence is not fully in on that jet. Method Jits are much older and there is a alot of reserach done in it spezially the old Self papers. Almost everything done in JS has allready been used in Self. Even some of the same people work on the JS implmentation.
Tracing jit are relativly reason and LuaJit shows how it can work out. It could well be in the end a compination of both is best.
In case you're not sure what I'm talking about, read through the LuaJIT source code at some point. It's a thing of beauty - he's handcrafted assembly to make everything run as fast as possible, on all of x86, x64, PowerPC and now ARM.
"LuaJIT 2.0 intellectual property disclosure and research opportunities" <http://article.gmane.org/gmane.comp.lang.lua.general/58908&#...; is further proof to that.
Rumor has it that Mike Pall is actually a collective pseudonym used by an army of cycle counting language expert cyborgs (from the future).
I have learned alot about LuaJit already and I will digg into it more in the future.
Interesting comment w.r.t. efforts to shrink Firefox's memory footprint being at the mercy of Flash.
The other browsers should have the same problem, right? They have to run Flash somehow.
Also worth mentioning is that LuaJIT and JS engines have different constraints. For example, JS engines must be very careful about security, LuaJIT does not. So JS engines need to do more cleanup/initialization for example, to prevent things like heap spray attacks, which LuaJIT does not. Also, JS engines are written to be maintainable by a large team, LuaJIT is really focused entirely on speed.
I do not see how maintainability could somehow have an inverse relation to the engine speed. IMHO the LuaJIT code base is significantly more maintainable than the Mozilla code base.
Related: Fate of Unladen Swallow and TraceMonkey predicted about two years ago, in February 2010: http://www.reddit.com/r/programming/comments/azibq/a_rant_ab...
Can you elaborate on what you mean by "permanent write-protection"? Is that to prevent code being overwritten? If so, that is just one possible attack.
Does LuaJIT implement techniques to mitigate heap spray attacks and heap inspection problems? JS engines work against that by initializing things like typed arrays to 0, and by overwriting objects when they are free'd. These have a runtime cost though, I'm curious if LuaJIT incurs it as well.
Regarding maintainability, your handwritten interpreter in assembly is not something I would expect other people to easily get up to speed on. The JS engine codebases are more approachable IMHO.
EDIT: I know it's been disabled for months - I'm referring to the original disabling of this code.
I would posit, based upon nothing, that in practice JIT systems can be a net negative to the overwhelming majority of run-once JavaScript encountered across the tubes.
JaegerMonkey is a method JIT.
IonMonkey is an SSA-optimizing JIT.
Type Inference is additional code that analyzes JS both globally and locally for types, and feeds that info into the JITs to make them more effective.
Previously Firefox used TraceMonkey, then TraceMonkey+JaegerMonkey, and now JaegerMonkey+Type Inference. The plan is to move to IonMonkey+Type Inference (not sure where JaegerMonkey fits into that).