Inferior to Gonk maybe, but at least supported
I just wanted to mention that it has been brought to my attention that Sailfish OS already maintain a Gecko fork for their Sailfish browser. Basically their fork is just adding an embedding API called āembedliteā into Gecko, which they use to implement their QT wrapper so that they can run webviews on their devices. Thereās some description of the layers involved here. Interestingly, the embedlite component which lives in their forked gecko codebase has no QT code ā the QT wrapper lives entirely out of the gecko tree here.
Perhaps we could look into whether this embedlite API could provide us with a way to implement a Gonk replacement out of the gecko tree. If itās working for Sailfish with QT, it seems like this could be possible (obviously a lot of work though). If this does work, then at the very least there would be two groups with an interest in maintaining a single gecko fork; this should be more promising than just the b2g people maintaining one.
I tend to remember their Gecko work is old and hard to keep in sync with us. That is what we are trying to avoid here.
And if itās not a big big drop in performance, thatās not a huge issue. Unless trying to run a game at 60fps, a small difference could be invisible for the user.
I think thereās just no commercial target at all, right now. It would be more like Cyanogen mod (not Cyanogen OS), something that people install if they want.
As @benfrancis already stated, āFirefox of Androidā works, so it is possible to create a usable web experience with this stack, just not with the same performance as B2G.
Right, and I think itās enough.
I didnāt test Firefox for android (I have no android phone soā¦ ) but I guess that if you have a decent browsing experience with it, you can have a decent phone experience. Even if itās a bit longer for heavy tasks (games, batch processing, ā¦)
Iām actually not convinced by Benās assertion about performance. Two data points:
- b2gdroid was not much slower than a gonk b2g on the same hardware. Remember that Fennec doesnāt use e10s, so itās likely not as responsive. I didnāt run benchmarks but b2gdroid UX issues where not in the āitās too slowā department.
- blink is pretty competitive with native apps. so it can be done
Itās true that memory usage will likely increase due to the larger stack. Well, weāre not targetting devices with 256MB of RAM anymore.
But the proof is in the pudding, so Iāll talk more once Iāll get something running.
So most of the features might run without any problem. Weāll see if some heavier task (Video recording/playing, ā¦) are more laggy.
Uhā¦ does that means that the performance will be worse than b2gdroid ?
(I do not remember when e10s will be added to Fennec - Does someone knows it ?)
Right, and all the recent devices come with at least 1 GB of RAM, and more and more with >2GB.
If we are talking about a few MB, I didnāt believe itās an issue.
I canāt wait to know the results
Sorry if I was not clear: fennec doesnāt use e10s, but b2gdroid did. So it works, and we will get the same performance as b2gdroid.
is b2gdroid based on fennec? What exactly is the difference?
Donāt worry, reading again your message, it was clear in fact ^^ (I just understood the contrary )
And thatās a great thing.
I think my confusion came from that:
Iām not really able to tell the difference. My understanding is that b2gdroid is a launcher, for all the gaia apps.
Roughly, B2GDroid is Mulet for Fennec
May I ask if anyone is exploring the Tizen hypothesis?
From what I can understand the system runs both native and web applications, but it seems a lot more similar to b2g os than Android.
More info: https://developer.tizen.org/development/getting-started/overview#type
Unfortunately, the Tizen bootloader is quite different with Android. Samsung Tizen-powered smartphones are not yet support Android such as CyanogenMod and other OS. But, we can flash it through ODIN and other alternatives.
EDIT: Oh, there is Download Mode in Tizen as well. If Tizen is used, how about some proprietary Android drivers? TBH, there are lots of Android device codenames available, so make sure to target the right one first (e.g. outdated devices and lower-middle range smartphones to help them āsurviveā through the power of the Web)
This is from @astheroth who canāt post on his own, at the moment.
I donāt understand several things; perhaps you could explain me
- As Far I know, b2g is gonk (linux kernel + aosp drivers + hal) +geeko + gaia, which are the adventages against android itself (as a complete operative system) and what do add value to this platform, speaking in OS design terms?
- Why and what parts would you take from android to build this rebuilt-OS? What would we lose, and what would we get?
- It appears as Mozilla is moving its coins to Servo, and Gecko would not be developed any more; would we think on using Servo instead Gecko? Perhaps; we can recieve Mozillaās feedback or its developers; at leastā¦
Thatās correct.
I think whatās being proposed is to take AOSP as a base but only run one native app which is the B2G system app running on the Android port of Gecko, to completely replace the default Android UI. That would mean leaving behind the Gonk port of Gecko and using the Android port instead (which is built on top of the Java Android Runtime so adds an extra layer to the architecture but is still supported by Mozilla). This would probably still require a fork of mozilla-central to keep the b2g app and any residual APIs, but wouldnāt require maintaining the Gonk port of Gecko.
Thatās not correct. Mozilla is starting to integrate some pieces from Servo (written in Rust) into Gecko. Servo is still an experimental future focused project and a long way away from being a competitive general purpose browser engine. One of the reasons given for removing B2G code from Gecko is to focus on the big changes Mozilla wants to make to Gecko to support Firefox.
Personally I donāt really like the idea of running Gecko on top of the Java Android Runtime, my main interest here was to have a fully web centric OS, and the curent plan doesnāt seems to go that way to my views as youāll still be based on an underlying Java Runtimeā¦
I know i donāt have the deep technical knowledge like some of you guys but Iām willing to help and to learn but i really have a philosophical issue with Java, and if we work on to off it donāt understand how we can be at least as fast as the other app as soon as we add another level in the OSā¦
Iām sure this OS Structure will be a problem for us sooner or later, at least performance wonāt be good I have tested B2Gdroid on a Nexus 7 and i can tell it was not fluent at allā¦
All this make me think,what is our target with this personally I want to propose to the public an alternative solution with a full Web interface, as i really believe this is the futur of the UI.
Even if itās hard (very Hard) why donāt we just try to continue on Gonk ?
I donāt believe we are in a rush and if we manage to have something working in few months,with some basic app, we can increase the work force around the project ?
At the current status If i understand properly we should be able to have something working even if we still have to continue the clean up of the Mozilla Specifics API and add new one, but this OS is already running on couple of devices and should be able to run on more.
My question is could we be more optimistic, believe in ourself and work on growing up the community around B2G instead of saying itās to hard letās give up and do something easier which is not a good solution be at least it can work for developers to play around ,arenāt we about just to make a new toy for developper ?
Matthieu
Yeah Basically Brendan Eich says it will be difficult, but iām totally aware that as soon as a distrib goes public it needs more man power or even paid dev guy to go further, but my point is that we can think about this once we have something to demonstrate, for now we are still defining the next steps.