Once you're in steady state, and if you don't use workers and don't use the new parallel processing primitives people are proposing for JS, you're right.
But during JIT warmup, and any time you have to JIT a new function or new codepath it matters because on multicore hardware you can do background compilation.
Mozilla fully supports single-line flexbox (that is, flexbox in which the child flex items are all layed out in a single row or column), which is what most flexbox use cases want, and has for a while.
The target audience is people who don't have a smartphone yet, most probably because they can't afford to pay for a $500 phone. Which is most people in the world, so far.
Noise reduction is great. And airlines have no problem with you wearing headphones, except during takeoff and landing. Every single airline I've ever dealt with will ask you to remove headphones then, to make sue you can in fact hear announcements.
Actually, WebKit cuts corners on standards a lot more than Firefox and IE do. For example, the official CSS 2.1 test suite from when the standard was finalized two years ago shows WebKit passing about 89% of the tests (for comparison, Firefox passed about 97%).
If Firefox/IE aren't rendering a page and WebKit is, it's almost always because the page author has written WebKit-specific code (e.g. used -webkit CSS prefixes on properties that are supported without a prefix in other browsers).
What WebKit and especially Chrome _does_ have is much better marketing. Not least because they have a much larger marketing budget than, say, Mozilla. Sadly, their marketing is working well on you.
The upshot is that variability is high, but for junior pilots pay is between about $20k (for regional airlines) and $50k (highest starting pay at a major ariline). Average major airline starting pay is $36k. Of course pilots fresh out of school don't get those major airline jobs.
I think you're just misunderstanding how these apps work, both for HTML5 and for Android native apps.
Your typical Android "native" app (which does not actually use the NDK) expresses its user interface in a text file containing XML, with Java event handlers attached to it to respond to various user actions. This XML is parsed at runtime and the corresponding Android UI toolkit objects are created.
Your typical "HTML5" app expresses its user interface in a text file containing HTML, with JavaScript event handlers attached to it. The HTML is parsed at runtime and the corresponding DOM nodes and CSS boxes are created.
Both can use OpenGL via the appropriate language bindings (WebGL in the case of HTML5 apps), but typically neither one actually does, leaving that up to the runtime (the browser in the case of the HTML5 appe, the Android runtime libraries for Android native apps) instead.
For a locally installed HTML5 app there are no sockets or TCP involved in a web browser: just reading (or mmapping) data from persistent storage.
If you actually look at the design documents for FirefoxOS they discuss this issue directly. There are actually _fewer_ layers there for rendering than there are for non-NDK Android apps.
On Android your typical "native" app is written in Java and uses GL for graphics if it needs fast 3D graphics. The Java is interpreted (on older Android) or JIT-compiled (Android 2.2 and newer). And this JIT is not exactly like HotSpot in terms of the performance it produces. For audio it uses whatever the system libraries are.
On FirefoxOS your typical app is written in JavaScript and uses WebGL for graphics if it needs fast 3D graphics. The JavaScript is JIT-compiled. The output can be within a factor of 2 of the performance of C++ code for game engines (see http://www.unrealengine.com/html5/ if you've missed it). For audio, it uses the browser's Web Audio implementation.
The two setups are actually a lot more similar than it seems at first glance.
What do you think a browser and an OS do, exactly?
A web browser needs to do render text, various high-performance graphics stuff, show some widgets that a user can interact with, provide a programmable runtime that can be used to create things like gmail or the github UI out of those widgets, do various network access, handle prioritizing things like web workers, painting, layout, and so forth. Oh, and nowadays also audio processing, real-time audio and video communications (WebRTC) and a few other things along those lines.
The non-kernel part of an OS needs to have libraries for high-performance graphics, show some widgets a user can interact with, a modern one will typically provide a programmable runtime for creating UI backed by some logic out of those widgets (C#, Objective C, Dalvik, etc). Pretty similar to a browser, actually.
Which is why it was possible to create FirefoxOS by taking a browser and adding a few APIs for touching hardware that the kernel exposes (things like cameras, FM radio, cell radio, etc). Plus a bunch of optimizations to the browser core that are needed no matter what to have a competitive browser.
The AG in Massachusetts is unfortunately more interested in setting up another run for the US Senate than in doing a good job as AG, as far as I can tell...
Porting Pepper is a huge undertaking, comparable to reimplementing large parts of a web browser from scratch. Oh, and without real specs, so you have to do a bunch of reverse-engineering.
There is no "Firefox browser" on FirefoxOS. There is a web browser UI (written in HTML+JS+CSS) that uses whatever the system browser engine is.
As roca said, there is nothing in the design of FirefoxOS that prevents someone from dropping in a different browser engine as long as it implements the relevant specs that apps rely on. But then this browser engine would then be used not only for the "web" but also for the various apps on the device. And only one browser engine can be used at any given time.
That seems like a failure in antitrust law, if true, in that a monopoly preventing non-commercial competition is just as bad as a monopoly preventing commercial competition, from my point of view.
Slashdot Mirror
Because most of the packages that do something useful involve interaction with the OS.
Sandboxing the python runtime, say, means breaking most of the packages python developers take for granted, no?
It depends.
Once you're in steady state, and if you don't use workers and don't use the new parallel processing primitives people are proposing for JS, you're right.
But during JIT warmup, and any time you have to JIT a new function or new codepath it matters because on multicore hardware you can do background compilation.
Mozilla fully supports single-line flexbox (that is, flexbox in which the child flex items are all layed out in a single row or column), which is what most flexbox use cases want, and has for a while.
What's missing is support for multiline flexbox.
As far as I know, in Colombia, Venezuela, Spain, Poland, so far.
FirefoxOS performs a lot better on devices at that price point than Android does.
The target audience is people who don't have a smartphone yet, most probably because they can't afford to pay for a $500 phone. Which is most people in the world, so far.
Are you in a market where it's available in stores? The marketing has mostly focused on those markets, obviously.
That said, the launch was covered on Slashdot back in July: http://mobile.slashdot.org/story/13/07/09/1414232/mozilla-launches-firefox-os-devices-in-stores-opens-up-app-payments and several other articles, as well as other tech press. No non-tech-focused marketing in the US so far, since it's not like you can buy one of these in a store in the US right now...
Noise reduction is great. And airlines have no problem with you wearing headphones, except during takeoff and landing. Every single airline I've ever dealt with will ask you to remove headphones then, to make sue you can in fact hear announcements.
This has nothing to do with electronics and everything to do with them needing you to be able to hear directions clearly in an emergency.
Actually, WebKit cuts corners on standards a lot more than Firefox and IE do. For example, the official CSS 2.1 test suite from when the standard was finalized two years ago shows WebKit passing about 89% of the tests (for comparison, Firefox passed about 97%).
If Firefox/IE aren't rendering a page and WebKit is, it's almost always because the page author has written WebKit-specific code (e.g. used -webkit CSS prefixes on properties that are supported without a prefix in other browsers).
What WebKit and especially Chrome _does_ have is much better marketing. Not least because they have a much larger marketing budget than, say, Mozilla. Sadly, their marketing is working well on you.
Firefox doesn't use keychain access on Mac. It uses its own password store, encrypted with its own master password. That's why https://bugzilla.mozilla.org/show_bug.cgi?id=106400 is still open.
Likewise on Windows, last I checked.
I haven't checked recently whether Firefox use gnome-keyring on Gnome, but based on past code inspection I rather doubt it.
Fwiw Costco's numbers are about $11.50/hr starting and $20/hr average. So somewhat better than Apple.
But Apple is still way better than other retailers...
Airline pilots are typically paid an hourly rate, but only for flight hours. It's pretty messed up.
> and I suspect pilot salaries probably aren't exactly
> the same as retail employee salaries
Not exactly, but closer than you might think. A look at the numbers: http://blogs.wsj.com/middleseat/2009/06/16/pilot-pay-want-to-know-how-much-your-captain-earns/
The upshot is that variability is high, but for junior pilots pay is between about $20k (for regional airlines) and $50k (highest starting pay at a major ariline). Average major airline starting pay is $36k. Of course pilots fresh out of school don't get those major airline jobs.
Retail salaries also vary widely. Minimum wage is 7.25/hr, which comes out to $14,500/yr if we assume 40-hour weeks and 2 weeks unpaid vacation. On the other hand, Costco pays $11.50 an hour for a starting salary: http://www.forbes.com/sites/timworstall/2013/03/06/of-course-costco-supports-a-higher-minimum-wage-it-already-pays-above-it/ and average pay for Costco employees is around $45k (see ), which is admittedly rather high for retail.
Pages do in fact get much more complex over time. For example, cnn.com nowadays loads well north of a megabyte of JavaScript on every load...
I think you're just misunderstanding how these apps work, both for HTML5 and for Android native apps.
Your typical Android "native" app (which does not actually use the NDK) expresses its user interface in a text file containing XML, with Java event handlers attached to it to respond to various user actions. This XML is parsed at runtime and the corresponding Android UI toolkit objects are created.
Your typical "HTML5" app expresses its user interface in a text file containing HTML, with JavaScript event handlers attached to it. The HTML is parsed at runtime and the corresponding DOM nodes and CSS boxes are created.
Both can use OpenGL via the appropriate language bindings (WebGL in the case of HTML5 apps), but typically neither one actually does, leaving that up to the runtime (the browser in the case of the HTML5 appe, the Android runtime libraries for Android native apps) instead.
For a locally installed HTML5 app there are no sockets or TCP involved in a web browser: just reading (or mmapping) data from persistent storage.
If you actually look at the design documents for FirefoxOS they discuss this issue directly. There are actually _fewer_ layers there for rendering than there are for non-NDK Android apps.
On Android your typical "native" app is written in Java and uses GL for graphics if it needs fast 3D graphics. The Java is interpreted (on older Android) or JIT-compiled (Android 2.2 and newer). And this JIT is not exactly like HotSpot in terms of the performance it produces. For audio it uses whatever the system libraries are.
On FirefoxOS your typical app is written in JavaScript and uses WebGL for graphics if it needs fast 3D graphics. The JavaScript is JIT-compiled. The output can be within a factor of 2 of the performance of C++ code for game engines (see http://www.unrealengine.com/html5/ if you've missed it). For audio, it uses the browser's Web Audio implementation.
The two setups are actually a lot more similar than it seems at first glance.
What do you think a browser and an OS do, exactly?
A web browser needs to do render text, various high-performance graphics stuff, show some widgets that a user can interact with, provide a programmable runtime that can be used to create things like gmail or the github UI out of those widgets, do various network access, handle prioritizing things like web workers, painting, layout, and so forth. Oh, and nowadays also audio processing, real-time audio and video communications (WebRTC) and a few other things along those lines.
The non-kernel part of an OS needs to have libraries for high-performance graphics, show some widgets a user can interact with, a modern one will typically provide a programmable runtime for creating UI backed by some logic out of those widgets (C#, Objective C, Dalvik, etc). Pretty similar to a browser, actually.
Oh, and an OS needs to mediate hardware access, which is done by the kernel. Oddly enough, Mozilla is not creating a kernel from scratch; they're using the Android neé Linux kernel in FirefoxOS. Maybe because they figured this was not something they were experts in and maybe using an existing reasonably good solution would be better than trying to create a new thing.
Which is why it was possible to create FirefoxOS by taking a browser and adding a few APIs for touching hardware that the kernel exposes (things like cameras, FM radio, cell radio, etc). Plus a bunch of optimizations to the browser core that are needed no matter what to have a competitive browser.
You mean the "slow startup speed" that's 2x faster than Chrome? See http://www.tomshardware.com/reviews/chrome-27-firefox-21-opera-next,3534-4.html for what the startup times look like if you actually measure them.
The AG in Massachusetts is unfortunately more interested in setting up another run for the US Senate than in doing a good job as AG, as far as I can tell...
Porting Pepper is a huge undertaking, comparable to reimplementing large parts of a web browser from scratch. Oh, and without real specs, so you have to do a bunch of reverse-engineering.
If you're willing to deliver a browser with no JIT and all the same web rendering bugs as Mobile Safari, doing that on iOS is easy enough.
It's when you think that you want to do better than that that you run into trouble.
There is no "Firefox browser" on FirefoxOS. There is a web browser UI (written in HTML+JS+CSS) that uses whatever the system browser engine is.
As roca said, there is nothing in the design of FirefoxOS that prevents someone from dropping in a different browser engine as long as it implements the relevant specs that apps rely on. But then this browser engine would then be used not only for the "web" but also for the various apps on the device. And only one browser engine can be used at any given time.
That seems like a failure in antitrust law, if true, in that a monopoly preventing non-commercial competition is just as bad as a monopoly preventing commercial competition, from my point of view.
Ah, well.