The zune wasn't a failure. [...] There is nothing technically wrong with it.
The Zune came out six months before Apple introduced the iPhone.
Even if there was "nothing technically wrong with" the Zune, if you seriously believe it was the right product at the right time, I have a portable CD player to sell you...
For some reason, I think [it's] not quite right [to say that FFOS is "an OS built in HTML5"]. Perhaps the intent was to write "an OS with built in HTML5"?
FFOS developer here.
The entire FFOS front-end is written in HTML5. That includes the homescreen and the task switcher. So "The Web" is the API that applications use to communicate with the system.
But there's of course plenty of C/C++ below that. To a first approximation, it's probably accurate to guess that parts of Android written in Java were re-written in JS for FFOS.
These are good questions.
even today's high-end devices struggle with a modern web pages.
At some point, designers are going to have to make concessions. cnn.com takes hundreds of MB of RAM to render in Firefox. It's a huge hog, loading hundreds of resources. That's just not going to work on a phone with limited memory; you're right that there's only so much optimization we can do.
But the idea isn't to run desktop Gmail or desktop CNN on your phone. If our competition is "native apps", all of which are purpose-built for the OS, I don't think it's unreasonable to expect app developers to make at least
that, and web apps can't tap into the hardware as well as "native" (note the quotes) apps. you can talk about extensions, but then you are asking devs to write FF OS apps, not web apps, and you are right back in WebOS land.
One difference is that Mozilla's "extensions" (and ohboy do we have them) can become part of Firefox and the general web platform. As a simple example, we added an API for reading the state of your battery. That's primarily useful on phones (and I believe we support it on both Firefox for Android and Firefox OS), but we added it to desktop Firefox, too, so you can read your laptop battery's charge.
Of course, not all APIs are relevant to all devices. If you want to frob the device's vibrator, well, that's probably not going to work so well on a laptop. But the idea is for all of our extensions to become standardized (that is, to no longer be "extensions"), and for them to be available on more platforms than Firefox OS, where applicable.
i'm sure you can rattle off some differenes between FF OS and [WebOS and iPhone web apps] but unless there's something profoundly different from the user's perspective, i don't see it.
Well, WebOS didn't fail because the web stack was a fundamentally bad user experience; in contrast, I know a lot of people who really liked the UI. It failed for a variety of reasons, but in terms of UX, it wasn't particularly performant. In this realm, I think Mozilla is in much better shape: We have a large team of Gecko experts working on the performance of our device; thus far, we've been able to get pretty decent perf on super-low-end hardware. In contrast, Palm didn't have any expertise in WebKit, and this has been cited as a reason they were unable to make it fast.
Well, smartphones all got native progams because anything else is just too inefficient. I don't really see what's changed.
The question is whether the inefficiency was a result of web technologies themselves, or their implementations. I don't think we have a definitive answer to that yet.
The developers of WebOS simply didn't have the kind of expertise with WebKit that Mozilla has with Gecko. We're able to optimize the hell out of this thing.
there's this little company called Google that has this thing called ChromeOS. it is EXACTLY [Firefox OS]
... an OS that boots into a browser. it's not lighting the world on fire either.
(Firefox OS developer here) This is a common misconception, but Chrome OS is a lot different from Firefox OS, at least from an architectural perspective.
Chrome OS is, as you say, an OS that boots into a browser. You're running a full desktop Linux client, including a window manager.
In Firefox OS, the window manager is an HTML page. Gecko (that is, Firefox) shows the window manager. All your apps, are iframes (with special attributes on them). The browser is an app (a special iframe). The browser's tabs are more special iframes inside the browser iframe. There are a lot of iframes in Firefox OS.
Also note that Chrome OS is not targeting smartphones (afaik). It's really quite different.
If they'd sell me an iPhone with voice only service and let me access WiFi only for my data, I'd be on-board, even at $600 up front
T-Mobile value plans are $40/mo for 500 minutes of talk plus 2GB of data. That's what I was paying on AT&T just for voice.
You have to bring your own phone, and the iPhone is not compatible with their 3G network. But I like my Nexus S well enough.
I actually thought this was a joke at first glance. So overall they went from white, to grayish, to grayish with some noise, to this. It's so nice working with such a consistent interface.
If only we had more observant people like you using the nightly channel and filing bugs, we might have avoided this rigamarole altogether!
Noooo it is NOT having "security vulnerabilities" because the Pale Moon devs are fixing holes and porting patches themselves so that is not a problem, and they have already said in their forum they are sticking with the V12 UI because they don't like what the Moz roadmap looks like.
Could you link me to this? Here is a post which implies that they have not forked, and are planning to port FF15. I could not find any discussion about porting security fixes on the bulletin board.
Isn't that the point of FOSS? If you don't like the direction you can fork? Well that is what they did, they forked.
Indeed (*), and if that's what they're actually doing, more power to them. I just hope you and others on
(*) Although I should point out that this guy is not, in my view, acting in the best FOSS faith, regardless of whether he's complying with the license. In addition, if he is backporting security fixes and not releasing the resultant source, he may be in violation of the MPL.
I've seen with my own eyes the difference on an Athlon X2 I keep at the shop. FF is a little piggy core hog while Pale Moon isn't slamming the shit out of the cores. [...] FF sucks major ass on older chips like Pentium Ds and Athlon X2s while PM is snappy.
If you have a reproducible benchmark or testcase, I'd be really interested to see what's going on. We use SSE extensively on hot paths in Firefox, and our assumption has been that having the compiler insert it elsewhere (as PM does) would not be a win. If that's not correct, I'd like to know.
If you are on Windows try Pale Moon [palemoon.org] which has forked away from FF as of V12 because they too grew tired of UI changes.
Firefox is currently at version 14. If you're using Firefox 12, you're using software with known security vulnerabilities.
It's not clear to me that the Pale Moon guys have actually forked Firefox at version 12; it may just be that they haven't upgraded to the latest version yet. But I seriously doubt that Pale Moon has backported every security fix from FF13 and FF14, and if not, it's insecure.
If you don't like the possibility of getting UI changes every six weeks, use Firefox ESR, or, for that matter, use IE. But you're not doing yourself any favors by running an insecure web browser.
it also has the SSE flags set at compile so its snappier than FF
I can't find the benchmarks on the Pale Moon site anymore, but I looked at them some time ago, and didn't observe that it offered any significant performance improvements. I doubt you'll be able to observe a performance difference due to anything other than the placebo effect.
So, here we have Mozilla saying, "porting Firefox to a process (nee thread) model is too hard, but we're going to build an operating system!"
FWIW, most apps in b2g^WFirefox OS will run in separate processes. The difficulty is specifically in porting Firefox to a multi-process architecture; Gecko is pretty capable of working multi-process.
Yet, Chrome continues to grow in market share, for the same reasons as outlined at the start of Electrolysis. In my opinion, the narrative changed but the conditions on the ground did not.
I totally agree. It's possible that the snappy project will get us many of the performance improvements we want without the trouble of electrolysis -- it's hard to say at this point.
I think part of the problem facing WebOS was that they lacked the WebKit expertise necessary to optimize their platform. We at Mozilla do not have the equivalent problem.