Does anyone know which is the cheapest phone that can be hacked to run Firefox OS? As in, is there a port to any of the , for example, the chinese Mediatek SoC-based phones - some of those sell for less than $50, retail. Vast majority sell for less than ~$100. They usually come with Android ICS/JB, but if even one of them has been hacked to run FFOS, i'd sure like to give it a try.
I know that existing Android ROM hacking communities have made some progress too, but I personally use a phone that explicitly supports FirefoxOS (Geeksphone Keon) which I am pretty happy with. I'll probably switch to the new reference device (the Flame) once it is available, although I'm really interested in the $25 Spreadtrum model too.
conversely, are there any expensive phones that can run it yet? i would love to try it on my rooted HTC Jewel (Sprint EVO 4G LTE). currently running CyanogenMod nightlies.
i guess i was more interested to know which phones has it been ported to. i understand that technically it can run on every phone that currently runs android since the linux layer is identical.
Before anyone buys the ZTE do be aware that the touch interaction with the device can be a little annoying. I have one of these phones and quite often I have a hard time getting it to correctly register anything.
Is there anything particularly remarkable about this release? The release notes make it sound like it really offers nothing more than some bug fixes, and very minor new functionality.
It will be a sign of things to come to see how many releases are supported on the first-generation Firefox OS phone that I have (ZTE Open). This doesn't mention it, and a quick Googling doesn't show any positive signs... anyone know?
I am quite sure that backwards compatibility won't be an issue. As you may know Firefox OS is aimed at low-end phones, so I don't think they plan on ending support for first generation phones… ever?. The only issue is the manufacturer, which has to take care for the Firmware updates for his own handsets. ZTE doesn't look very eager to give its users constant updates.
I guess it will take some time for ZTE to provide 1.3 for their phones, because v1.3 is in pre-release stage for the moment. ZTE took quite some time to provide v1.1, but then 1.2 followed quite quickly [1].
Trunk builds of Firefox OS (version 1.4ish) work fine on my ZTE Open. I doubt they'll see consumer release though. I hope they do but I'm not confident in carriers pushing it.
2# this is not marketed as a substitute to iPhone or even Android. It's mean for people that can't afford high end phones. People that if the choice is a $25 phone without contacts sync or a $100 phone with sync they will take the former.
3# A lot of people are working hard on this project improving it every day. Dismissing it like that for a quite minor thing, yes minor, seems quite childish to me.
When a potential user expresses a very legitimate desire for some missing functionality, it leaves a very bad impression when that user is then told to add the functionality himself or herself.
It also doesn't help to refer to that very legitimate feature request as "childish", especially when it involves core functionality that's very critical to many users.
It's been usable by the average user for a long time now, but first the average user needs to get it. Average users usually need a lot of help to obtain operating systems that are not sold in boxes or that don't come preinstalled. That and the selection of compatible hardware, which has not always been easy. Luckily, most hardware makers are a little better at building compatible computers these days. Worst: average users have a lot to unlearn.
My mom (she's 78) is on Linux since 2006 or so. Moved from Windows to Mac and then to Linux. Never had an issue.
The key is what the user expects. If you approach Linux wanting a seamless transition from Windows, you'll be frustrated. Everything makes sense, but it's different. Your software won't run. If you approach Linux without expecting it to be like Windows, you'll be happy. The average user overestimates how much they know about computing and bring their own baggage. That baggage holds them down. They want to download Nero to burn a CD. They want to download Firefox from the firefox.org website. The whole idea of a package manager is completely alien to the average user (or was, until the advent of the app store).
This feedback (CardDav support) isn't a dismissal. It's a key feature, even for a low-end smartphone. We're not talking advanced BT profiles, or Facebook sync - this is basic contacts stuff, and thanks to the CardDav standard it's pretty straightforward.
It wasn't harshly worded at all. A phone is a communication device. Being able to quickly and easily add the contact details of other people is a very basic and critical feature to have in a phone these days. If such functionality is lacking, then the phone can indeed be considered useless.
If FirefoxOS is to have any chance at adoption by the general public that attitude has to go. How many people will be happy with responses like yours when they ask a very reasonable question? Not too many.
The ES6 spec draft is in its final stages of being revised. At this point there shouldn't be any substantial developer-facing changes except to a few final things that are being ironed out (mainly modules).
The features that are being shipped in Firefox are ones that are stable in the draft spec and not expected to change. At the point of spec stability, these features need to be actually tested in broader distribution to help find any potential compatibility corner cases, similar to the issues found with Array.prototype.values [1].
Moreover, the model in which large, multifaceted standards go through a series of revisions, with vendors following in lockstep, releasing implementations of everything that has been decreed stable and nothing that has not, has never been the way the web worked, despite the fact that many standards organisations design their processes around it.
In practice vendors implement small chunks of emerging ideas, with flags to prevent the ideas reaching the stable versions being a relatively novel addition to the process made possible by rapid release schedules. The ideas become stable, ready or not, when enough people are using them that it's no longer possible to remove or amend the implementation without breaking sites and thereby annoying your user base.
I hear that the TC39 group that controls ECMAScript are planning to adjust to this reality by incrementally standardising features in the future so, perhaps, instead of "ES7" we will see specs for "ES foo", where "foo" is a specific feature. Ironically this is closer to the way that some non-web languages like Python (ignoring the 2/3 divide) work, with a series of enhancements that are adopted as they are ready, even though Python actually does have clear and meaningful versions.
I agree with it in principle, but this isn't the first time FF has dropped in Javascript features which are still not finalized. I just think that if other browser vendors are going to be raked over the coals for not rigidly adhering to standards processes and shipping non-approved features not behind flags, everyone should be held to the same standard, a consistent policy.
If the other vendors weren't, respectively, the largest, second largest, and third largest tech companies in the world, and amongst the most valuable companies in the world this comparison would make sense. If, of the other three browser makers, we weren't discussing a company that holds a near monopoly on desktop OS's, a company that holds a near monopoly on the high-end of computing, and the third which holds a near monopoly on internet services this comparison would again make sense.
Should Mozilla have been more conservative in shipping features that are actually written up in a spec on their fledgling OS? Probably, playing strictly by the rules is generally a good thing. Is this comparable to a different vendor working to ship an enormous feature which didn't even have a spec, and which the person at the centre of the controversy asked other people to help write because they had been so busy? No, not at all.
Size, influence, and power always make a difference. I have a hard time understanding how you wouldn't see this.
Like the Geneva Conventions, they protect both big and small players, in times of war, as long as everyone agrees to abide by them. The big players, as you indicate, could really do a lot more, unimpeded, but have shown relative restraint and participated voluntarily these standards committees. I don't think granting a waiver for one particular vendor is conducive to influencing others to play by the rules.
> I just think that if other browser vendors are going to be raked over the coals for not rigidly adhering to standards processes and shipping non-approved features not behind flags, everyone should be held to the same standard, a consistent policy.
ES6 has cross-vendor support and a draft specification [1], which are not true of PNaCl or Dart. No browser vendor has stated opposition to ES6 that I'm aware of; everyone's committed to implementing it.
This has nothing to do with PNaCL or Dart, so why beat that strawman? This is about standards committee stuff being pushed out before finalization not behind a flag, the kind of stuff that incited the big brouhaha over prefixed APIs not too long ago. Commitment to implement is not the same as "won't change before final release", so what happens if it gets significant uptake, and the final draft actually tweaks something important?
As far as I know, the way ES6 works is that there is consent for everyone to implement features that have been approved in the "face to face" meetings. That is not the same way that the CSS working group works, however, because CSS is now modularized as opposed to monolithic.
You're trying to create controversy where there is none. Nobody on TC39 objects to SpiderMonkey implementing specific features with broad consensus before all of ES6 has been finalized.
This already exists, in the form of Android. Is it ideologically perfect? Maybe not, but it's more than good enough for most people. Android is widely adopted, it's available on many different devices, users can install their own apps from a variety of sources, and there's a fair amount of freedom for developers to choose how to implement and distribute their apps.
Jolla at one point claimed to have €200m in capital. This is probably some Nokia and some Finland government money. Crunchbase does not list VC investors, or any investors for that matter.
"New Array methods have been implemented: Array.prototype.keys"
Dafuq.
Yes I'm aware how Arrays are just objects in JS but please stop bastardizing the Array data type even further. This is also part of ES6 so I don't blame Mozilla for implementing it.
Arrays in javascript are not what you might think. They are defined by the spec to be maps where certain keys (those that are string representations of Uint32 numbers) are treated differently, and a magic property length which is always one more than the largest such key.
They are not necessarily dense - there can be gaps, and any kind of relationship to a contiguous block of memory is purely at the discretion of the implementation.
I presume that your complaint is really about calling such a thing an array, because a 'keys' method is certainly not a further bastardization of what was already in the spec.
What do you mean by bastardizing? I'm not sure when I'd ever use Array.keys, but it seems like it could be potentially useful -- and more importantly, totally in the spirit of JavaScript.
It seems like a poorly-chosen name. I like the idea of being able to get an indexes iterator, but I'd probably have named it `indexes()` rather than `keys()`, as the latter tends to be much more strongly associated with dictionaries.
