Booting to the Web
Andreas Gal
Mozilla believes that the web can displace proprietary, single-vendor stacks for application development. To make open web technologies a better basis for future applications on mobile and desktop alike, we need to keep pushing the envelope of the web to include --- and in places exceed --- the capabilities of the competing stacks in question.
We also need a hill to take, in order to scope and focus our efforts. Recently we saw the pdf.js [http://github.com/andreasgal/pdf.js/] project expose small gaps that needed filling in order for "HTML5" to be a superset of PDF. We want to take a bigger step now, and find the gaps that keep web developers from being able to build apps that are --- in every way --- the equals of native apps built for the iPhone, Android, and WP7.
To that end, we propose a project we’re calling "Boot to Gecko" [http://wiki.mozilla.org/B2G] (B2G) to pursue the goal of building a complete, standalone operating system for the open web. It’s going to require work in a number of areas.
* New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
* Privilege model: making sure that these new capabilities are safely exposed to pages and applications
* Booting: prototype a low-level substrate for an Android-compatible device;
* Applications: choose and port or build apps to prove out and prioritize the power of the system.
We will do this work in the open, we will release the source [http://github.com/andreasgal/B2G] in real-time, we will take all successful additions to an appropriate standards group, and we will track changes that come out of that process. We aren't trying to have these native-grade apps just run on Firefox, we're trying to have them run on the web.
This project is in its infancy; some pieces of it are only captured in our heads today, others aren’t fully explored. We’re talking about it now because we want expertise from all over Mozilla -- and from people who aren’t yet part of Mozilla -- to inform and build the project we’re outlining here.
brendan, cjones, gal, shaver
Tristan Nitot - Mozilla
> we propose a project we’re calling "Boot to Gecko" [http://wiki.mozilla.org/B2G] (B2G) to pursue the goal of building a complete, standalone operating system for the open web.
Very very exciting!
--Tristan
Ian Bicking
Webian OS? (http://webian.org/ - built on Chromeless)
Ian McKellar
> * New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
Yay that's awesome!
> * Booting: prototype a low-level substrate for an Android-compatible device;
Why not boot to a more conventional Linux stack? Android brings a lot
of baggage that's useful for building a mobile phone running J*va apps
but does less for bringing up a Gecko. Surely a straight-forward Linux
w/ X would be a simpler, more open way to implement a Gecko-OS.
Ian
Rob Campbell
On 2011-07-25, at 12:49, Andreas Gal wrote:
> * Booting: prototype a low-level substrate for an Android-compatible device;
Why Android and not a PC to start with? Would it be easier? Fewer moving parts, fewer device unknowns? Is a PC-level device on the table as well?
I realize you might not have these answers just yet, but I'm curious and felt like asking. :)
--
Rob "Scope Creep" Campbell
- blog: http://antennasoft.net/robcee
- twitter: http://twitter.com/robcee
Mike Shaver
> Given this, thoughts about, or reactions, or possible work with to
> Webian OS? (http://webian.org/ - built on Chromeless)
As with ChromeOS and other such projects, we'll be looking all over
the place for both inspiration and collaboration. We're really
focused on the handheld/tablet/mobile experience for this work, and it
looks like Webian is more aiming at the desktop. It will great if
we're both successful!
Webian's experiences in building APIs for system services seem like a
great place to collaborate, too.
Mike
Mike Shaver
> Why Android and not a PC to start with? Would it be easier? Fewer moving parts, fewer device unknowns? Is a PC-level device on the table as well?
We might prototype some stuff on a PC, but the project is really about
the device space. We had to pick somewhere, and this seems like where
the energy is best spent.
Desktop devices tend to be harder to get good open drivers for without
pulling in things like X, which we don't want to do.
Mike
Brendan Eich
> Why not boot to a more conventional Linux stack? Android brings a lot
> of baggage that's useful for building a mobile phone running J*va apps
We won't be taking any of that stuff, not to worry. Just the kernel
and device drivers.
> but does less for bringing up a Gecko. Surely a straight-forward Linux
> w/ X would be a simpler, more open way to implement a Gecko-OS.
Maemo is not making it.
These days the device makers are moving to Android. To get all the HAL
benefits,we want to reuse its lower layers.
All open source is a requirement in my view. We'll see how this goes.
/be
Mike Shaver
> Why not boot to a more conventional Linux stack? Android brings a lot
> of baggage that's useful for building a mobile phone running J*va apps
> but does less for bringing up a Gecko. Surely a straight-forward Linux
> w/ X would be a simpler, more open way to implement a Gecko-OS.
We intend to use as little of Android as possible, in fact. Really,
we want to use the kernel + drivers, plus libc and ancillary stuff.
It's not likely that we'll use the Android Java-wrapped graphics APIs,
for example. It's nice to start from something that's known to boot
and have access to all the devices we want to expose. Maybe that's
not the right direction, though, so if someone wants to explore
another direction that'd be just fine.
Our experiences with performance and hardware acceleration on X
haven't been great, and it's a pretty heavyweight component to bring
in. Are there good drivers for the hardware found in current phones
and tablets?
Mike
Bert Freudenberg
> * New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
> * Privilege model: making sure that these new capabilities are safely exposed to pages and applications
What about exposing the CPU, a la NativeClient?
- Bert -
Mike Hommey
Don't worry, mobile devices are not better for good open drivers, with
or without X. And you get additional fun from the lack of standards
on the hardware side...
Mike
Brendan Eich
Those New Web APIs are for the standardized, portable content
languages (JS/HTML/CSS). We are not looking to run native code,
especially given the requirements for a new plugin API, complex
toolchain, etc. We're following NaCl, including the PNaCl work, but it
is not ready for prime time, and we'd have to spend a lot of people
and time integrating and tracking it. The opportunity cost on pushing
the open web standard is very high, at least for our community.
Google can much better afford to invest in NaCl, but that won't
necessarily make a standard. The toolchains and OSes are likelier to
support control-flow integrity enforcement in native code sooner than
the browser makers, IMHO.
/be
Chris Jones
Pretty much every web API exposes the CPU (or GPU) to content, at some
level of abstraction. Do you mind being a bit more specific about what
you want?
We have no plans to implement Native Client at this time.
Cheers,
Chris
Fabrice Desré
> We intend to use as little of Android as possible, in fact. Really, we
> want to use the kernel + drivers, plus libc and ancillary stuff. It's
> not likely that we'll use the Android Java-wrapped graphics APIs, for
> example. It's nice to start from something that's known to boot and
> have access to all the devices we want to expose. Maybe that's not the
> right direction, though, so if someone wants to explore another
> direction that'd be just fine.
That's a great and ambitious goal, and in a shorter time frame I'm
exploring a less disruptive option:
Set fennec to run as your android homescreen, with the homescreen itself
implemented as a web app, using a couple of additional APIs :
- The openwebapps API (https://developer.mozilla.org/en/OpenWebApps/
The_JavaScript_API)
- An API to list/launch native android apps (based a cleaned up version
of http://dev.w3.org/2009/dap/app-launcher/)
With this we can get android users to transition to a web-based solution
with not much risk : no need to change your ROM for instance.
Fabrice
Matthew
Andreas Gal
On Jul 25, 2011, at 10:47 AM, Fabrice Desré wrote:
> On Mon, 25 Jul 2011 13:27:30 -0400, Mike Shaver wrote:
>
>> We intend to use as little of Android as possible, in fact. Really, we
>> want to use the kernel + drivers, plus libc and ancillary stuff. It's
>> not likely that we'll use the Android Java-wrapped graphics APIs, for
>> example. It's nice to start from something that's known to boot and
>> have access to all the devices we want to expose. Maybe that's not the
>> right direction, though, so if someone wants to explore another
>> direction that'd be just fine.
>
> That's a great and ambitious goal, and in a shorter time frame I'm
> exploring a less disruptive option:
> Set fennec to run as your android homescreen, with the homescreen itself
> implemented as a web app, using a couple of additional APIs :
> - The openwebapps API (https://developer.mozilla.org/en/OpenWebApps/
> The_JavaScript_API)
> - An API to list/launch native android apps (based a cleaned up version
> of http://dev.w3.org/2009/dap/app-launcher/)
This is exactly our current starting point. We have a demo of this up and running.
>
> With this we can get android users to transition to a web-based solution
> with not much risk : no need to change your ROM for instance.
A number of intermediate steps are possible. I am very interested in making a beefed up web stack with powerful local APIs available to users of existing devices. I think we can do this without distracting from the ultimate goal: breaking the stranglehold of proprietary technologies over the mobile device world.
Andreas
>
> Fabrice
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Brendan Eich
> Google can much better afford to invest in NaCl, but that won't
> necessarily make a standard. The toolchains and OSes are likelier to
> support control-flow integrity enforcement in native code sooner than
> the browser makers, IMHO.
ChromeOS will be first, but Microsoft and even Apple may follow -- but
not with NaCl, rather their own equivalents. I don't expect any
standardization for a long, long time. The use-case will still be
downloading binary code, but safer code. It won't be schlepping big
gobs of x86 or even LLVM bitcode (still with machine dependencies)
around as if it were JS.
/be
Marco Zehe
Am 25.07.2011 19:26, schrieb Brendan Eich:
> On Jul 25, 10:19 am, Ian McKellar<ian.mckel...@rd.io> wrote:
>> Why not boot to a more conventional Linux stack? Android brings a lot
>> of baggage that's useful for building a mobile phone running J*va apps
> We won't be taking any of that stuff, not to worry. Just the kernel
> and device drivers.
This has some interesting implications for accessibility which I'll be
blogging about in the near future. Just an initial thought:
We would need the capability to install speech synths so blind users
could use a (yet to be written) extension/possibly part of the browser
that provides them speech feedback in all environments. For that,
whichever we include from Android, we'd need to make sure that the
speech services framework is part of that.
This is super exciting stuff, and I look forward to participating in
this process!
Marco
Chris Jones
> Hi Brendan,
>
> Am 25.07.2011 19:26, schrieb Brendan Eich:
>> On Jul 25, 10:19 am, Ian McKellar<ian.mckel...@rd.io> wrote:
>>> Why not boot to a more conventional Linux stack? Android brings a lot
>>> of baggage that's useful for building a mobile phone running J*va apps
>> We won't be taking any of that stuff, not to worry. Just the kernel
>> and device drivers.
> This has some interesting implications for accessibility which I'll be
> blogging about in the near future. Just an initial thought:
>
> We would need the capability to install speech synths so blind users
> could use a (yet to be written) extension/possibly part of the browser
> that provides them speech feedback in all environments. For that,
> whichever we include from Android, we'd need to make sure that the
> speech services framework is part of that.
>
Speech synthesis is a capability we want to have, but it's not something
we necessarily need to import an android framework for. Speech
synthesis can be implemented by web pages, today, using JavaScript and
audio APIs. We definitely want to hear what the a11y requirements are
for this (and in general!) so we can figure out what the best
implementation might be.
> This is super exciting stuff, and I look forward to participating in
> this process!
Yes, please do.
Cheers,
Chris
Brendan Eich
> Awesome news, I recommend integrating BrowserID as well.[1]
>
> [1]https://browserid.org/
You bet!
/be
Henri Sivonen
> To that end, we propose a project we’re calling "Boot to Gecko" [http://wiki.mozilla.org/B2G] (B2G) to pursue the goal of building a complete, standalone operating system for the open web.
I'm very happy and excited to see this. Awesome! Thank you!
> * Booting: prototype a low-level substrate for an Android-compatible device;
Just curious: Did you evaluate Meego kernel & Wayland in comparison to
Android kernel & Android graphics? Does Android win on driver
availability/quality alone or also on pure technical merit?
What do webOS and Chrome OS use for graphics? Do they ship X or
something that's not X, not Wayland and not the Android graphics layer?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Mike Shaver
> Just curious: Did you evaluate Meego kernel & Wayland in comparison to
> Android kernel & Android graphics? Does Android win on driver
> availability/quality alone or also on pure technical merit?
We'll evaluate them, but for right now we want to take advantage of
the work we've already done (and are doing) on Android, and the ease
of getting devices that are known to work. Specifically, we're
looking at Tegra 2 devices because they have hardware acceleration of
open audio/video formats, and they match what we've got automated
testing running on.
> What do webOS and Chrome OS use for graphics?
I'm not sure -- I don't believe that the graphics stack for ChromeOS
is open, but I might just have missed it browsing the code. No idea
about WebOS either.
If people want to help identify other good OS/device combinations,
though, that would be welcome. For now we're going to be doing just
enough work to get to booting to Gecko and then focus higher up the
stack to write the system services (dialer, camera app, etc.) as
locally-cached web applications.
Mike
Randell Jesup
> On Mon, 2011-07-25 at 08:49 -0700, Andreas Gal wrote:
>> To that end, we propose a project we’re calling "Boot to Gecko" [http://wiki.mozilla.org/B2G] (B2G) to pursue the goal of building a complete, standalone operating system for the open web.
>
> I'm very happy and excited to see this. Awesome! Thank you!
Very cool... especially as an old-time OS geek (Commodore Amiga OS
team/one-time-lead).
>> * Booting: prototype a low-level substrate for an Android-compatible device;
>
> Just curious: Did you evaluate Meego kernel& Wayland in comparison to
> Android kernel& Android graphics? Does Android win on driver
> availability/quality alone or also on pure technical merit?
I'll say that it seems likely that future hardware will come with
drivers for Android (just talk to TI or other chipset makers; they're
pretty much all providing "base" Android ports for their mobile-capable
chipsets), which means access to all that hardware that's often has no
fully-open-source driver. (For example, code that drives the video codec
accelerators.)
--
Randell Jesup, Mozilla Corporation
Remove ".news" for personal email
Stefan Arentz
> On Mon, Jul 25, 2011 at 1:19 PM, Rob Campbell <rcampb...@mozilla.com> wrote:
> > Why Android and not a PC to start with? Would it be easier? Fewer moving parts, fewer device unknowns? Is a PC-level device on the table as well?
>
> We might prototype some stuff on a PC, but the project is really about
> the device space. We had to pick somewhere, and this seems like where
> the energy is best spent.
>
> Desktop devices tend to be harder to get good open drivers for without
> pulling in things like X, which we don't want to do.
I don't know the current state of Android/x86 but wouldn't that also
be a good platform to develop on? It could be an easy way to bootstrap
this. Same Android layer, same Gecko code, lots of overlap with Fennec/
Linux. It would mean that we could hack on BootToGecko on a much
easier to handle environment that runs in VMWare of VirtualBox.
S.
Mike Shaver
> I don't know the current state of Android/x86 but wouldn't that also
> be a good platform to develop on? It could be an easy way to bootstrap
> this. Same Android layer, same Gecko code, lots of overlap with Fennec/
> Linux. It would mean that we could hack on BootToGecko on a much
> easier to handle environment that runs in VMWare of VirtualBox.
Depending on the state of Android/x86, that sounds very promising.
Does that work for Fennec stuff now?
Mike
Chris Jones
Sure, that's an option. Note that the android SDK includes an emulator
based on qemu, so running B2G/ARM builds on your desktop isn't
necessarily a problem (because of the emulator).
Cheers,
Chris
Mike Shaver
>
> On Monday, July 25, 2011 at 10:27 AM, Mike Shaver wrote:
>
>> Our experiences with performance and hardware acceleration on X
>> haven't been great
>
That's great, I should take another look. Thanks!
Mike
ya knygar
now a bit of criticism:
Tegra is an obvious choice for a start (But - nvidia often make the
closed, proprietary drivers, i wonder if they missed their usual
politics on Tegra..) - uprising mega-platform, performance is good
etc.
But:
>We'll evaluate them, but for right now we want to take advantage of
>the work we've already done (and are doing) on Android
i understand that tweaking the gecko once for both Android and Android is cool,
but isn't there already enough of Android and it's SDK? aren't there
are pretty mature
https://secure.wikimedia.org/wikipedia/en/wiki/SHR_(operating_system)
and other variants, many other, more natural - GNU/Linux variants.
Could you, please, tell - when do you plan to evaluate these
non-Android variants?
So we could decide if the petition to Mozilla about non-Android OS is
appropriate now.
Mike Shaver
> i understand that tweaking the gecko once for both Android and Android is cool,
> but isn't there already enough of Android and it's SDK?
Apps won't use the Android SDK, they'll use current-and-future Web APIs.
> Could you, please, tell - when do you plan to evaluate these
> non-Android variants?
I don't know of any plans to evaluate SHR; I don't have any devices it
runs on, personally, and none of the ones listed in Wikipedia are very
interesting to target IMO. We have a lot of work to do even starting
from a working operating system. Adding OS-bringup to our plate isn't
really attractive to me at this time.
If you or someone else would like to evaluate SHR, on the other hand,
that would be welcome information. Just telling us that we shouldn't
look at Android is unlikely to be very effective, since that's where
we feel our work is best directed right now. Facts coming out of
evaluation of Android and other proposed platforms would be much more
influential, because they can actually help inform decisions.
Mike
Robin Berjon
On Jul 25, 2011, at 19:47 , Fabrice Desré wrote:
> - An API to list/launch native android apps (based a cleaned up version
> of http://dev.w3.org/2009/dap/app-launcher/)
I really don't think that using the App Launcher draft as any manner or form of starting point is a good idea. The DAP group has it in its CVS because it is inherited from the APIs that were submitted to it in the beginning, but it's since been abandoned and IMHO for very good reason. I don't think that a cleaned up version will get you anywhere interesting, you need a completely different design.
The problem with the App Launcher API is that there is pretty much no way of making it safe for Web use without making it useless. At the more powerful end of this spectrum you can enumerate installed executables (how that works is in itself an issue, not to mention how you filter it for privacy) and can then run them. I don't think that there is any kind of user interface that will make that functionality safe to run from the Web. At the other end of the spectrum you can have methods like "launch the music player with this". These are typically best served by media types and URI schemes.
Of course you could do something like that if the goal were not to make the APIs in B2G not be Web-safe. But I don't see the value in this, and from reading between the lines I think that the idea is that all of the B2G stack be built with Web APIs. Any monkey with enough time can wrap every lib on the system with js-ctypes but I don't see much value in that. What's hard (and interesting) is to make it work for the Web. That's why DAP dropped App Launcher in favour of an Intents/Introducer approach.
That's not to say that I don't see value in your proposal of having a runtime that can be used on top of an OS rather than requiring a complete replacement. I could well be missing something but I see no reason why the project couldn't have a minimal OS that's just enough to launch the runtime, which in turn could also run elsewhere. But either way there's a bit of code to write before such refinements :)
--
Robin Berjon - http://berjon.com/ - @robinberjon
Andreas Gal
On Jul 25, 2011, at 2:36 PM, Robin Berjon wrote:
> Hi Fabrice,
>
> On Jul 25, 2011, at 19:47 , Fabrice Desré wrote:
>> - An API to list/launch native android apps (based a cleaned up version
>> of http://dev.w3.org/2009/dap/app-launcher/)
If there is a way to launch native android apps from such a system, it would be the same kind of temporary wart that plugins like Flash and Silverlight are for the desktop web platform. If we can't deliver the necessary WebAPIs quickly enough and need Android apps to fill in web platform gaps temporarily, an Android app stop-gap measure might be an acceptable temporary kludge.
In a final system, I don't see much value for this proposal though. The web is in so many ways superior to the locked-in proprietary stores/APIs that it will subsume them pretty quickly as long we make sure the right APIs are in place. This is happening on the desktop today. Your proposal is akin to suggesting that we should urgently add a way to launch Java/native code desktop applications from the desktop browser. It might serve some specific corner cases today, but I doubt it will be relevant in the future.
Andreas
Mike Shaver
> Hi Fabrice,
>
> On Jul 25, 2011, at 19:47 , Fabrice Desré wrote:
>> of http://dev.w3.org/2009/dap/app-launcher/)
Android apps won't likely run on this system once we're done stripping
it down, any more than Linux applications run on Android, so the
launcher isn't likely to be useful even independent of Robin's
well-articulated concerns.
> That's not to say that I don't see value in your proposal of having a runtime that can be used on top of an OS rather than requiring a complete replacement. I could well be missing something but I see no reason why the project couldn't have a minimal OS that's just enough to launch the runtime, which in turn could also run elsewhere.
Whatever we run on top of, we have to bind all these various
capabilities, and many operating systems don't currently expose enough
for us to, f.e., write a dialer app. We'll want to validate against
multiple operating systems in time, but we have to start somewhere,
ideally where we can hack our way around current limitations in the
lower-level stack.
> But either way there's a bit of code to write before such refinements :)
And how! Please help!
Mike
azakai
> On 07/25/2011 02:16 PM, Marco Zehe wrote:
> > This has some interesting implications for accessibility which I'll be
> > blogging about in the near future. Just an initial thought:
>
> > We would need the capability to install speech synths so blind users
> > could use a (yet to be written) extension/possibly part of the browser
> > that provides them speech feedback in all environments. For that,
> > whichever we include from Android, we'd need to make sure that the
> > speech services framework is part of that.
>
> Speech synthesis is a capability we want to have, but it's not something
> we necessarily need to import an android framework for. Speech
> synthesis can be implemented by web pages, today, using JavaScript and
> audio APIs.
I definitely agree that sort of thing can be done on web pages. We can
also compile existing C/C++ codecs into JS for this (perhaps even the
relevant Android framework itself).
In general I think that making it easier for people to compile stuff
into JS, as opposed to adding new native code into the browser, is the
preferable approach, at least for things like this (codecs/logic/non-
hardware accessing stuff).
- azakai
Eric Dorman
I think this is a great idea for the web, but security has to be one
of the center pieces around this OS.
In my opinion, Android is suffering from attacks because some of their
source code is very sensitive to the platform and is constantly being
the victim of malware attacks.
Nick Dafo
this.
Android is already a great mobile O.S. that is open source.
It may run native apps but i see no problem with that. Plus, it has a
great browser that is always getting better with each release so it
supports the HTML5 web apps that mozilla (and also google) likes.
If Mozilla wants to support open source and the web in mobile devices
you should better work as much as possible on the Android version of
Firefox instead of trying to create a whole new O.S.
There is no need for another O.S. if you can build a great Firefox app
for an existing open source O.S. that is already out on the market and
growing faster than the closed systems like apple's and microsoft's.
You may think that i may be saying this because i love Android but
there is much logic and reason in my words.
Kyle Huey
> Android is already a great mobile O.S. that is open source.
>
Can you provide a link to the Honeycomb source?
- Kyle
Rob A
> It may run native apps but i see no problem with that. Plus, it has a
> great browser that is always getting better with each release so it
> supports the HTML5 web apps that mozilla (and also google) likes.
>
It doesn't have a great browser at all; it is at best mediocre. No
web-worker support (was there in 2.1, disappeared in 2.2+), poor support for
CSS transforms. No SVG support until honeycomb came out. No WebGL. No inline
html5 video. Poor performance overall (network, graphics, and touch) and
it's full of quirks across manufacturers (ex: my phone doesn't show
scrollbars). Also, I can't upgrade it. It may get better in each release but
I am at the mercy of the carriers/oems for upgrading. I am essentially
locked into one version of the browser, maybe two if I'm lucky (though
little changed in Gingerbread).
-Rob
Andreas Gal
On Jul 25, 2011, at 5:28 PM, Nick Dafo wrote:
> As a huge Android supporter i dont see why you find the need to do
> this.
>
> Android is already a great mobile O.S. that is open source.
Android is not open source in the sense of "open technology". Android APIs are proprietary Google sauce, not broadly accepted and adopted open web standards. At some point Android used to be at least "available source" where Google would publish secretly/internally developed source code/technology after the fact as products ship, but even those times seem to be over now. I would love to boot my custom Android build on my Galaxy Tab 10", but no luck, Google refuses to release the source.
We want to do Boot to Gecko the way we think open source should be done. In the open, from day 1, for everyone to see and participate.
Andreas
Cedric Vivier
> On Mon, Jul 25, 2011 at 1:19 PM, Rob Campbell <rcam...@mozilla.com> wrote:
>> Why Android and not a PC to start with? Would it be easier? Fewer moving parts, fewer device unknowns? Is a PC-level device on the table as well?
>
> pulling in things like X, which we don't want to do.
>
Since this is about the future, did you consider Wayland?
Afaik it has been designed for use on embedded devices as well.
Awesome project.
sung
performance aspect though.
Travis Galloway
bit different.
Rishi
> Mozilla believes that the web can displace proprietary, single-vendor stacks for application development. To make open web technologies a better basis for future applications on mobile and desktop alike, we need to keep pushing the envelope of the web to include --- and in places exceed --- the capabilities of the competing stacks in question.
>
> We also need a hill to take, in order to scope and focus our efforts. Recently we saw the pdf.js [http://github.com/andreasgal/pdf.js/] project expose small gaps that needed filling in order for "HTML5" to be a superset of PDF. We want to take a bigger step now, and find the gaps that keep web developers from being able to build apps that are --- in every way --- the equals of native apps built for the iPhone, Android, and WP7.
>
> To that end, we propose a project we’re calling "Boot to Gecko" [http://wiki.mozilla.org/B2G] (B2G) to pursue the goal of building a complete, standalone operating system for the open web. It’s going to require work in a number of areas.
>
> * New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
> * Privilege model: making sure that these new capabilities are safely exposed to pages and applications
> * Booting: prototype a low-level substrate for an Android-compatible device;
>
> We will do this work in the open, we will release the source [http://github.com/andreasgal/B2G] in real-time, we will take all successful additions to an appropriate standards group, and we will track changes that come out of that process. We aren't trying to have these native-grade apps just run on Firefox, we're trying to have them run on the web.
>
> This project is in its infancy; some pieces of it are only captured in our heads today, others aren’t fully explored. We’re talking about it now because we want expertise from all over Mozilla -- and from people who aren’t yet part of Mozilla -- to inform and build the project we’re outlining here.
>
> brendan, cjones, gal, shaver
exciting....
bob_so...@yahoo.com
That would be huge IMO. I would definitely
develop for it in that case.
Bob
Tan Yew-wei
Or to take it a step further, perhaps with this project, is it possible to build a new abstraction for networking? (thus avoiding the hairiness of sockets -> a JS-callable version of zeromq perhaps [http://www.zeromq.org/])
Wan Li
XUL should not be considered. Chromeless works just fine.
--
>: ~
Nicholas Nethercote
>
>> Android is already a great mobile O.S. that is open source.
>
Ooh, I see what you did there.
N
Marco Zehe
Am 25.07.2011 20:47, schrieb Chris Jones:
> Speech synthesis is a capability we want to have, but it's not something
> we necessarily need to import an android framework for. Speech synthesis
> can be implemented by web pages, today, using JavaScript and audio APIs.
Yes, I was there when Dave Humphrey demoed this at Whistler 2010. The
quality of the synth was...well...close to the 1980s. Seeing that it was
written in pure JS, however, was fantastic! But I agree it's something
worth looking at, and we need to be aware of multilingual support.
> We definitely want to hear what the a11y requirements are for this (and
> in general!) so we can figure out what the best implementation might be.
We just recently made a decision on how to move forward with
accessibility for Firefox Mobile on Android, and this work will
definitely benefit the B2G project, and we can learn a lot this way.
Cheers,
Marco
jse...@acm.org
cooperatively managed by both browser and kernel, rather than the
current unpalatable possibilities of either being summarily nuked or
indiscriminately swapped.
Shmerl
> On Jul 25, 10:19 am, Ian McKellar <ian.mckel...@rd.io> wrote:
>
> > Why not boot to a more conventional Linux stack? Android brings a lot
> > of baggage that's useful for building a mobile phone running J*va apps
>
> We won't be taking any of that stuff, not to worry. Just the kernel
> and device drivers.
>
> > but does less for bringing up a Gecko. Surely a straight-forward Linux
> > w/ X would be a simpler, more open way to implement a Gecko-OS.
>
> Maemo is not making it.
>
> These days the device makers are moving to Android. To get all the HAL
> benefits,we want to reuse its lower layers.
>
So why promoting their moves? Promote Wayland. Meego should be a
better candidate for that.
Hillel.
ya knygar
> I don't know of any plans to evaluate SHR; I don't have any devices it
> runs on, personally, and none of the ones listed in Wikipedia are very
> interesting to target IMO. We have a lot of work to do even starting
> from a working operating system. Adding OS-bringup to our plate isn't
> really attractive to me at this time.
of-course but given the closed source of latest Android,
given that in opinion of many from FLOSS community -
world would really benefit from GNU/Linux portable OS's (that, by the way,
are developed and tested seriously by the community and would be used
widely, sooner or later,
SHR just another working example - could be installed on iPhones, and,
most of the ARM's are just untested with it,
not that there are many compatibility issues).
If Mozilla dev's would support the freedom OS's in one or other way -
that would likely to rise the Question of
vendor locked-mobiles and the possibility of mobiles computers to
became a PC like machines in which user
could easily install OS of the choice. Work on B2G would help it
anyway, but supporting particularly a freedom OS's
"back-end" could
bring a much larger attention and what is more valuable - support of
community, and, maybe,
some amazing collaborative affords.
Supporting Android is rising up the questions that lead in a kind of
different direction where -
why do we need to re-flash OS if we could run the OS into OS like
Chromeless OS's for example.
Again - it's just my observation.
Porting to GNU/Linux would be done anyway, i think, but this is the
point where, obviously, both Mozilla and GNU/FSF/etc.
community would largely benefit from collaboration. And working with
Google - given what i know about it's work with community,
and helping the forks, in particular,
is a controversial decision.
Marcos
> * New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
The W3C is already working on a bunch of these (Device API Working
Group) [1]. Has Moz evaluated those or considered joining that working
group?
> * Applications: choose and port or build apps to prove out and prioritize the power of the system.
It would be good if packaged applications made use of an open
standardized format... like W3C Widgets [2] [3]... instead of adding
another proprietary layer :)
[1] http://www.w3.org/2009/dap/
[2] http://www.w3.org/TR/widgets/
[3] http://www.w3.org/2008/webapps/wiki/WidgetSpecs
Natanael L
MeeGo should be a better enviroment for this than Android.
On Jul 25, 7:23 pm, Mike Shaver <mike.sha...@gmail.com> wrote:
> On Mon, Jul 25, 2011 at 1:19 PM, Rob Campbell <rcampb...@mozilla.com> wrote:
> > Why Android and not a PC to start with? Would it be easier? Fewer moving parts, fewer device unknowns? Is a PC-level device on the table as well?
>
> We might prototype some stuff on a PC, but the project is really about
> the device space. We had to pick somewhere, and this seems like where
> the energy is best spent.
>
> Desktop devices tend to be harder to get good open drivers for without
> pulling in things like X, which we don't want to do.
>
> Mike
Natanael L
> On Mon, Jul 25, 2011 at 3:14 PM, Henri Sivonen <hsivo...@iki.fi> wrote:
> > Just curious: Did you evaluate Meego kernel & Wayland in comparison to
> > Android kernel & Android graphics? Does Android win on driver
> > availability/quality alone or also on pure technical merit?
>
> We'll evaluate them, but for right now we want to take advantage of
> of getting devices that are known to work. Specifically, we're
> looking at Tegra 2 devices because they have hardware acceleration of
> open audio/video formats, and they match what we've got automated
> testing running on.
"Locally cached" sounds interesting. How would this work? Is this the
same as the HTML5 offline features? IMHO it seems quite strange to use
that for 100% local apps.
Are you going to provide some kind of local webserver? That would
probably allow for a bit more advanced features, I think.
Then I'm thinking about things like local networking (bluetooth, WiFi,
etc...) and P2P apps. I guess that would move away from HTML+JS, but
you could still go for some PHP/Python based server framework for
local apps and try to standardize that.
It would be interesting to hear your opinions on this.
> > What do webOS and Chrome OS use for graphics?
>
> I'm not sure -- I don't believe that the graphics stack for ChromeOS
> is open, but I might just have missed it browsing the code. No idea
> about WebOS either.
>
> If people want to help identify other good OS/device combinations,
> though, that would be welcome. For now we're going to be doing just
> enough work to get to booting to Gecko and then focus higher up the
> stack to write the system services (dialer, camera app, etc.) as
> locally-cached web applications.
>
> Mike
Natanael L
> On Jul 25, 3:39 pm, Mike Shaver <mike.sha...@gmail.com> wrote:
>
> > On Mon, Jul 25, 2011 at 3:30 PM, Stefan Arentz <stefan.are...@gmail.com> wrote:
>
> > > I don't know the current state of Android/x86 but wouldn't that also
> > > be a good platform to develop on? It could be an easy way to bootstrap
> > > this. Same Android layer, same Gecko code, lots of overlap with Fennec/
each other.
Malware can be found anywhere that code can be uploaded without a
thorough review.
![Paul [sabret00the]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXpqWEkVBU_5J5Xax-9ym-MBL8B7zIo97fdWeD9T1Mf9Te1mTw=s40-c)
Paul [sabret00the]
* Firefox Desktop getting a port of Firefox Mobile chromeless browsing
* Firefox running on internet-enabled televisions
* Firefox Mobile getting the rest of features we're all accustomed to in desktop
* Firefox actually sorting out the MSI installer
* Firefox shipping with GPO support
* Firefox shipping a supported 64bit build on Windows
* Panorama actually supporting OS convention in it's operation
* Globalised App Tabs
* Scalable installations +/- RSS support, Share support, etc.
Paul [sabret00the]
Ben Francis
> On Mon, Jul 25, 2011 at 12:56 PM, Ian Bicking <ianbi...@gmail.com> wrote:
> > Given this, thoughts about, or reactions, or possible work with to
> > Webian OS? (http://webian.org/ - built on Chromeless)
>
> As with ChromeOS and other such projects, we'll be looking all over
> the place for both inspiration and collaboration. We're really
> focused on the handheld/tablet/mobile experience for this work, and it
> looks like Webian is more aiming at the desktop. It will great if
> we're both successful!
>
> Webian's experiences in building APIs for system services seem like a
> great place to collaborate, too.
Hi there,
I'm the founder of the Webian project.
It sounds like the long term goals of Webian (http://webian.org/about/) and the goals of the B2G project match up almost exactly. I also support your idea of dropping X as a dependency in pursuit of a lighter OS stack.
It's true that the Webian Shell 0.1 prototype runs on desktop OSs, but that's because I chose to use Mozilla Chromeless to rapidly prototype the UI and Chromeless currently doesn't run on mobile OSs. The announcement blog post and video (http://mozillalabs.com/chromeless/2011/05/31/webian-shell-a-full-screen-web-browser-built-on-chromeless/) mentions the desire to add an on-screen keyboard for touch-based devices and I've always intended for Webian to target a range of form factors. I've tried to make design decisions in the UI which don't exclude touch-based devices, even if a desktop device might be an initial target.
I agree with you that mobile is where a lot of the innovation (and media attention) is focussed at the moment, but it does currently seem to have quite a high barrier to entry. If you want to target smartphones for example then unless you partner with hardware manufacturers and mobile carriers to build phones running your operating system out of the box, you're going to be asking users to flash their device. Not a particularly user friendly process and one which could potentially void their warranty.
That's why I've been thinking that for Webian, nettop computers (http://en.wikipedia.org/wiki/Nettop) would be a more realistic initial target. Then perhaps netbooks, smartphones and smart TVs... but that's a long way off.
B2G is an interesting change in direction for Mozilla (http://news.cnet.com/8301-30685_3-10401867-264.html) and I admire your ambition. I'm curious to know what your longer term goals are for the project. Do you see B2G being a homebrew experiment for the foreseeable future, or do you see a consumer-facing OS strategy in the pipeline if the idea proves popular? B2G (like Webian) seems to want to take the best parts of both Android and Chrome OS, which I expect is where Google is ultimately headed too (http://news.cnet.com/8301-30684_3-10402653-265.html).
The Webian Shell prototype has had nearly 90,000 downloads since it was announced so there definitely seems to be some interest in this area. I really hope that B2G takes off and we can collaborate with each other (and others like Chrome OS) to make the open web the software platform of choice.
Ben
--
Ben Francis
http://webian.org
Natanael L
> On Monday, July 25, 2011 6:22:10 PM UTC+1, Mike Shaver wrote:
> > On Mon, Jul 25, 2011 at 12:56 PM, Ian Bicking <ianbi...@gmail.com> wrote:
> > > Given this, thoughts about, or reactions, or possible work with to
>
> > As with ChromeOS and other such projects, we'll be looking all over
> > the place for both inspiration and collaboration. We're really
> > focused on the handheld/tablet/mobile experience for this work, and it
> > looks like Webian is more aiming at the desktop. It will great if
> > we're both successful!
>
> > Webian's experiences in building APIs for system services seem like a
> > great place to collaborate, too.
>
> Hi there,
>
> I'm the founder of the Webian project.
>
> It sounds like the long term goals of Webian (http://webian.org/about/) and the goals of the B2G project match up almost exactly. I also support your idea of dropping X as a dependency in pursuit of a lighter OS stack.
>
>
> I agree with you that mobile is where a lot of the innovation (and media attention) is focussed at the moment, but it does currently seem to have quite a high barrier to entry. If you want to target smartphones for example then unless you partner with hardware manufacturers and mobile carriers to build phones running your operating system out of the box, you're going to be asking users to flash their device. Not a particularly user friendly process and one which could potentially void their warranty.
>
> That's why I've been thinking that for Webian, nettop computers (http://en.wikipedia.org/wiki/Nettop) would be a more realistic initial target. Then perhaps netbooks, smartphones and smart TVs... but that's a long way off.
>
> B2G is an interesting change in direction for Mozilla (http://news.cnet.com/8301-30685_3-10401867-264.html) and I admire your ambition. I'm curious to know what your longer term goals are for the project. Do you see B2G being a homebrew experiment for the foreseeable future, or do you see a consumer-facing OS strategy in the pipeline if the idea proves popular? B2G (like Webian) seems to want to take the best parts of both Android and Chrome OS, which I expect is where Google is ultimately headed too (http://news.cnet.com/8301-30684_3-10402653-265.html).
>
> The Webian Shell prototype has had nearly 90,000 downloads since it was announced so there definitely seems to be some interest in this area. I really hope that B2G takes off and we can collaborate with each other (and others like Chrome OS) to make the open web the software platform of choice.
>
> Ben
>
> --
> Ben Francis http://webian.org
Personally I see the best way to go forward as turning Chromeless into
a base framework with the necessary system API:s, that you then can
run anything on top of.
I have suggested a similiar thing for Ben Francis already for his
Webian project. The idea is essentially that this web OS is a
framework in the background, the interface is an "extension", or an
app running on it. Whatever you see on the screen, it's all extensions/
apps. Each and every one use standard API:s, and can thus be swapped
out for anything else that use those same API:s.
This means that you could easily switch (web) app launcher and
anything else without patching the OS.
If you would like to replace the whole UI for the browser component,
that would be easy to do. If you like to replace the dialer, that's
just as easy. Or the desktop. Or the notification bar/box/icon/drawer/
list/[anything]. Single-click installation (and of course approving
the required permissions for the apps too) and you're done.
What I hope is that this would make prototyping extremely easy and
fast and would let people experiment with more things, much faster. It
would also be extremely flexible and TRULY give the user freedom to do
whatever (s)he wishes to do.
You could think of it as Chromeless+drivers+kernel = a Linux
distribution with drivers, the kernel, base GNU sw and X/Wayland but
no Gnome/Unity/KDE. The Mozilla OS would then be that base plus an
interface and userland apps (like Linux base with Gnome plus office sw
and browsers).
ya knygar
yep, last time i saw it there weren't much dev on it,
but, along with Webian and many others Mozilla or not,
mobile or not based initiatives - there are enormous
amount of work in that direction that have been done
already.
for example - http://www.defora.org/
driven by one person for a 6+ years, i think.
Robert Kaiser
> If there is a way to launch native android apps from such a system, it would be the same kind of temporary wart that plugins like Flash and Silverlight are for the desktop web platform. If we can't deliver the necessary WebAPIs quickly enough and need Android apps to fill in web platform gaps temporarily, an Android app stop-gap measure might be an acceptable temporary kludge.
Andreas, I agree with you in the basics there, but let's not even
consider that kludge. The absence of what people want is a quite strong
incentive to fill the gaps. I'm also in communities where providing
temporary kludges or kickstarting things with not really adequate
half-solutions lead to not being able to build up a community doing
things the right way.
The web development community is strong enough that I think the really
important things will be available pretty fast if the web technology for
doing them the right way exists. I also think that making Android apps
part of our experience significantly harms us by binding us to that
Google-controlled stack way too much. If this is to succeed, using a
stable base like Android is good for a start but in the end it needs to
end up with a more free base (when such a base is mature enough, and
it's not at this time).
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
djevrek
* Google to enable + button for users posts
so i can like your comment.
Henri Sivonen
> "Locally cached" sounds interesting. How would this work? Is this the
> same as the HTML5 offline features? IMHO it seems quite strange to use
> that for 100% local apps.
Well, are any apps 100% local in the sense that you wouldn't want to
pull updates from the network? If you do want updates, W3C Widgets (or
similar) plus widget updating becomes a second system to support
alongside the HTML5 app cache.
OTOH, "local" apps (all app logic in client-side JS) bundled with the
system could ship as prefilled HTML5 app caches and could thereafter
update themselves from whatever server their URLs point to--the same way
as non-bundled HTML5 appcache-enabled Web apps would update their cached
parts.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
d.hit...@tesco.net
> On Mon, Jul 25, 2011 at 5:28 PM, Nick Dafo <nickdafomob...@gmail.com> wrote:
> > Android is already a great mobile O.S. that is open source.
>
> Can you provide a link to the Honeycomb source?
>
Why a 'great mobile OS'
Its not a deliberate start to an argument, I honestly don't have a
massive insight into the workings of Android. I do know that Symbian -
that much maligned OS has a very good kernel, several features to
prevent memory leaks, keep battery consumption low, prevent memory
tramples and so forth. I appreciate the S60 UI had become a somewhat
inefficient bloated sluggish wreck but Nokia had been striving to make
some improvements. From my perspective - given the huge installed base
of Symbian devices, the low BOM, the flexibility built in, that
building a decent UI on top of the Symbian Kernel would have been a
good option.
I would be interested in this project, I've worked on email, web
browsers and mobile devices for a very long time (way back with pagers
and then through the very early days of GSM).
The decision (as I have read it) is to take Android and rewrite a lot
of it... if Android is that good a starting point surely rewriting is
not a good idea? Symbian would make a good, established, tested and
working start point.
It certainly is possible to create an entire phone UI based on a web
type system - this was behind some of the original WAP 1.0 proposals,
Mobile Explorer also worked along these lines (with all the web
settings, email client, dynamic home pages etc.) being web pages. I
know a collegue that had some interesting ideas around further
enhancements to web layouts that would enable a good deal of
flexibility about how to respond to phones with different shape
screens, different button locations etc. (Mobile Explorer coped with
different screen sizes and featured interesting ideas like not having
any left/right scroll on any webpage, but relaying to fit a scroll
up.down only model as supported by the old Sony Z5 job dial)
d.hit...@tesco.net
I think speech is good, but generally the processing required to
achieve it is rather on the high side. It might be an exciting
additional project, but perhaps its a sideline?
Robert Kaiser
> Tegra is an obvious choice for a start (But - nvidia often make the
> closed, proprietary drivers, i wonder if they missed their usual
> politics on Tegra..) - uprising mega-platform, performance is good
> etc.
NVidia is still the proprietary openness-hostile thing it used to be,
and Tegra doesn't change any bit of that. Mozilla is not interested in
building hardware, though, and a good bunch of modern, capable devices
right now are Tegras, Mozilla also happens to own a number of those to
run tests for our Android version of Firefox, and we need some point to
start this experiment on, so that's a natural choice. Mozilla also
doesn't want to go into developing drivers, we want to improve the web
stack, so we're building on what's there but make it as portable as
possible so it can run on a number of other hardware if people are
willing to try.
> Could you, please, tell - when do you plan to evaluate these
> non-Android variants?
From all I understand, what's being developed here won't be dependent
on Android at all, Mozilla will just use it as the base to run this
experiment for now, as it is there and stable enough to work on. Mozilla
is not interested in developing low-level OS software, drivers, or
anything like that, but just the layer that connects that layer with web
applications, i.e. what was a "browser" in the past and is a "web
application runtime" nowadays - just that we want to give web apps the
capabilities to use a lot of the underlying device.
Android on Tegra is a good starting point now (just as Maemo on N810 was
when we started doing a mobile browser) as we need something ready to
use and stable enough that we can concentrate on the web application
runtime layer we know best. It by no way should be the only
hardware/software combination this runs on.
I'm personally convinced that some alternative to Android will come up
in the next few years (MeeGo and WebOS are in good positions there,
having some power and deployment behind them, even if not in the
conventional markets - e.g. most people don't even know about the
millions of cars that will be delivered with MeeGo installed) and I'd be
very happy if this project would run on a really open stack instead of
the proprietary (source thrown over the wall if you're lucky is nothing
like open), tightly-controlled Android. But we're not at a point where
we either know which more open stack will succeed nor in a position we
can work on one to get there, working on the web application runtime is
a large enough project as it is.
(And note that I'm not part of this project even though I work for
Mozilla, I just got to know about it because someone from the local
media called me and wanted a statement about this from me.)
d.hit...@tesco.net
> I'm really excited about this project. I am a little worried about the
> performance aspect though.
Why? As I said elsewhere, I don't know about the Android stuff, I do
know the basic Symbian Kernel is good (I appreciate many applications
and S60 is not wonderful, but the discussion already is around
replacing a lot of Android, so I wonder if Symbian wouldn't be a
better start point - it was designed for battery power, low memory,
long life embeded devices in the first instance so has a good deal of
well thought through features for this - despite the cruft that grown
on top over the years).
Robert Kaiser
IMHO, HTML currently is incapable of doing great UI, but XUL can do that
right now. But then, I think exactly that's another thing we need to
change with this project and the new standards we need to work on to get
all this working! :)
d.hit...@tesco.net
I would think the most interesting version would be to do the WHOLE UI
in browser technology, with the browser dealing with caches,
tokenising and generally managing its memory. The activities such as
Bluetooth etc. could probably be placed at a layer around the kernel
and be permanently in place and allocating memory only when used.
Symbian kernel has some reasonable memory handling functions.
As I said elsewhere the original WAP 1.0 spec had features to enable
the whole UI to be done in browser technology, indeed Mobile Explorer
used a modified HTML system (templates with tokens for accessing some
data) to provide for the settings pages, menus, email client,
autoupdating home pages and a number of similar things. In fact, you
could send WAP push messages to the home page to keep it up to date,
change the home page by pushing (or pulling) over the air. This
approach might leave us open to having a system that is equally at
home using 'cloud applications' or downloading them for use in railway
tunnels and other unconnected environments....
Robert Kaiser
> Then I suggest that you focus on MeeGo for the sake of technicalities.
> MeeGo should be a better enviroment for this than Android.
If MeeGo succeeds (and sure as hell I hope that it will), then it once
will be a better environment, that's true. Right now, it's not nearly
mature enough to build our web application runtime on top of it and not
care about the low-level OS underneath. Android is mature enough for
that, so it's the obvious choice for a start. Mozilla will not hook into
a lot of Android-specific things, though, and make this highly portable
therefore. I hope, just like you probably do, that it can run on a way
more open stack in the future - and if people from the MeeGo community
are interested in getting this to run there once we have something to
show, I'm very sure that our people working on this will cheer and help
to get it done.
David Rusling
Dave
On Jul 25, 4:49 pm, Andreas Gal <g...@mozilla.com> wrote:
> Mozilla believes that the web can displace proprietary, single-vendor stacks for application development. To make open web technologies a better basis for future applications on mobile and desktop alike, we need to keep pushing the envelope of the web to include --- and in places exceed --- the capabilities of the competing stacks in question.
>
> We also need a hill to take, in order to scope and focus our efforts. Recently we saw the pdf.js [http://github.com/andreasgal/pdf.js/] project expose small gaps that needed filling in order for "HTML5" to be a superset of PDF. We want to take a bigger step now, and find the gaps that keep web developers from being able to build apps that are --- in every way --- the equals of native apps built for the iPhone, Android, and WP7.
>
> To that end, we propose a project we’re calling "Boot to Gecko" [http://wiki.mozilla.org/B2G] (B2G) to pursue the goal of building a complete, standalone operating system for the open web. It’s going to require work in a number of areas.
>
> * New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
> * Privilege model: making sure that these new capabilities are safely exposed to pages and applications
> * Booting: prototype a low-level substrate for an Android-compatible device;
> * Applications: choose and port or build apps to prove out and prioritize the power of the system.
>
> We will do this work in the open, we will release the source [http://github.com/andreasgal/B2G] in real-time, we will take all successful additions to an appropriate standards group, and we will track changes that come out of that process. We aren't trying to have these native-grade apps just run on Firefox, we're trying to have them run on the web.
>
> This project is in its infancy; some pieces of it are only captured in our heads today, others aren’t fully explored. We’re talking about it now because we want expertise from all over Mozilla -- and from people who aren’t yet part of Mozilla -- to inform and build the project we’re outlining here.
>
> brendan, cjones, gal, shaver
Robert Kaiser
> The decision (as I have read it) is to take Android and rewrite a lot
> of it...
Man, I hope not. The UI layer, yes, but the lower layers are hopefully
nothing Mozilla will even consider to rewrite or even touch, but just to
integrate with. It's not just the kernel, there's a whole lot of
userspace stuff to glue high-level UI to low-level kernel etc. workings.
I just hope whatever Android has there (I have so far refused to touch
that proprietary system) is not too far apart from more generic (and
really open) Linux stacks so we can easily build upon more open stack in
the future when they become more mature.
ya knygar
it's webrtc.org by that - could be done like "real" web apps with
indexed db, i think.
what i propose is:
decouple the Chromeless like(by html5 stack styling idea and reuse
Prism/WebRunner ideas, by-the-way) Mobile Gecko part as a installable
browser for web Apps,
by Web Apps.
To run on existing and partially open mobile platforms. That are able
to handle reworked the "client" side like SpiderMonkey compilation for
web browsing, like XULRunner with HTML rather than XUL for dynamic
styling given from standardized Web Apps.
Let it be alpha-omega if any official Mozilla build, but people will
adopt and test it, fork and invent for it..
..with existing API's on platform(s) but, anyway, someone would do it
So - decouple it from back-end OS part, even if device API's that
could be used would differ in that OS
from Mozilla OS, that what i propose, for the overall B2G adoption
part by part.
>Things I'd prefer to see resources devoted to before this:
>* Firefox Desktop getting a port of Firefox Mobile chromeless browsing
+1
>* Firefox running on internet-enabled televisions
+1 BTW - it's another +1 for non-Android backend
https://wiki.mozilla.org/Mobile/Embedding
>* Firefox Mobile getting the rest of features we're all accustomed to in desktop
i propose to continue to work on Mobile Firefox as the stable,
"normal" build for mobiles,
there would be these Moz Open Web Apps places like
https://wiki.mozilla.org/Mobile/Projects/WebApp_Support
and other work that could potentially - not suit to "normal" Firefox Mobile.
Maybe, further from what i proposed above - Mobile FF could evolve
into a part of Moz OS
>* Firefox actually sorting out the MSI installer
:)
>* Firefox shipping with GPO support
what is GPO?
>* Firefox shipping a supported 64bit build on Windows
+1
>* Panorama actually supporting OS convention in it's operation
...
>* Globalised App Tabs
like a part of OS? +1 it's a kind of Chromeless OS's work
>* Scalable installations +/- RSS support, Share support, etc.
that would be wonderful.
-
>You could think of it as Chromeless+drivers+kernel = a Linux
>distribution with drivers, the kernel, base GNU sw and X/Wayland but
>no Gnome/Unity/KDE.
+1! Moz platform powered UI for OS - is the best desicion i could see,
they are doing CSS/JS in these GUI's anyway, could be very, very, useful
given that Win8 could also evolve into kind of Web OS.
Imagine the community driven OS that would compete with Win, even
on gaming and recreation field..
>The Mozilla OS would then be that base plus an
>interface and userland apps (like Linux base with Gnome plus office sw
>and browsers).
do you mean - userland for like LibreOffice on Moz OS? ;
Chromeless like GUI and base for running native web apps,
along with recompiled/ported GTK/Qt/ other potable apps like
on GNU/Linux distributive's now?
PS: excuse me for double-post if for someone.. i'v mailed to this list
into BCC accidentally,
waited for moderation for an hour
and still - haven't seen my message in google group.. don't repeat my mistake:)
SRAO
From my previous experience working with embedded space, I see the following problems
1) Device Drivers - most of the silicon vendors want revenue for there efforts not only to manufacture the device, also for device drivers. Some give it free as open source - not all. If we look at Linux desktop OS, it is still difficult to get some drivers for say SDX cards / graphic drivers. With Google behind Android and working closely with Manufacturers to get the drivers to the world for innovative hardware like 3D displays with recent HTC and LG phones. Microsoft has industry partners. Apple gets everything in-house. Nokia, finally in process of giving up Symbian. For Mozilla this would be a difficult challenge to get the drivers for all kinds of devices in the market. Easiest to target for the project would be a tablet with standard WIFI.
2) Telephony/Wireless, Codec Patents – this is highly explosive area, and Android and as such Linux itself is being targeting from time to time.
3) Industry Support – The project needs to start with a reference hardware design. There are number of hardware designs available such as Beagleboard from hobbyist to OMAP ZOOM platforms for commercial innovative devices. There are many more. As the project is embedded in nature, the first reference design needs to be cheaper such that project participants can buy at cheaper price for producing demo software. Initially an emulator such as QEMU is good. Personally, hardware availability is the best for developers for such projects. Industry support is a must to get the hardware device drivers for new devices, otherwise the fate would be similar to linux running on old devices.
4) App Market - The mobile OS market is highly fragmented like the 1980’s with different desktop OS’s. For mobile – Android, Ubuntu MID(dead now), Nokia Symbian, Microsoft Windows Phone, Apple iOS. Each OS has its own App market and none of them are interoperable. Applications make the device more useful. Should be easy as Apple iOS SDK, Secure as in Symbian Applications, Cross-platform as in Android for multiple devices, intuitive as Windows Phone UI. The challenge is to define best possible API’s for exposing device functionality across multiple vendor handsets.
My suggestion rather then starting a new Mobile OS – pick one that is already available open source like Android, and join hands to make it stable or fork Android to support Gecko shell.
This is good start in one direction – keep it going, just sharing my insights from the Embedded world.
Nayeem
I appreciate the attempt by an established player like Mozilla to
venture into the territory of the mobile OS.
The point I want to raise here is: will there be a support for the
cloud based services and/or whether Mozilla itself is going to provide
some kind of cloud. Something like what Apple is doing with their
mobile devices. I read at a tech website that this OS will be
targeting the Chrome OS of Google, which means a cloud like
infrastructure working behind the browser like interface of the users'
devices.
ya knygar
> right now. But then, I think exactly that's another thing we need to
> change with this project and the new standards we need to work on to get
> all this working! :)
exactly as i think :)
this project could became the catalyst software point,
where the latest standards, innovations and ideas are
being developed to implementation point, tested and becoming reality :
something what Firefox couldn't afford being in continuous mass use,
maybe - like ideology successor of previous Aurora conceptions.
(before Aurora became a name of the dev channel for Firefox)
>4) App Market - The mobile OS market is highly fragmented like the 1980’s with different desktop OS’s. For mobile – Android, Ubuntu MID(dead now), >Nokia Symbian, Microsoft Windows Phone, Apple iOS. Each OS has its own App market and none of them are interoperable. Applications make the >device more useful. Should be easy as Apple iOS SDK, Secure as in Symbian Applications, Cross-platform as in Android for multiple devices, intuitive as ?
>Windows Phone UI. The challenge is to define best possible API’s for exposing device functionality across multiple vendor handsets.
i believe the point of Open Web Apps initiative is to make the new
world market of open web apps that would incorporate all the above
goods - with help of web OS's that - if browsers would follow W3C
ideas - these browser will became finally. I'm glad that with this
initiative -
it would be rather sooner than later.
There are much more for a mobiles in use -- WebOS, RIM, Bada, some
custom Chinese products..
The Problem - most of these "mobile OS's" aren't even close to
desktop one's because of
every major corporation have a hand to grab the market into closed
structure.. in result -
no interoperability etc.
And only chance for Future to not became a Closed Proprietary
(given the consumer ratio of mobiles/pc's market) with a surveillance
in your pocket or bag - is to make the open apps on web platform.
If the problem is in JavaScript/HTML/CSS knowledge for *any* developer,
well - there was all this time to realize the politics of W3C
and browser developers and to propose something better.
>2) Telephony/Wireless, Codec Patents – this is highly explosive area, and Android and as such Linux itself is being targeting from time to time.
i have posted to FreedomBox and would participate in it's or other
group of developers that would make a Freedom mobile OS,
with ideas of freedom box or kind of.
> 1) Device Drivers - most of the silicon vendors want revenue for there efforts not only to manufacture the device, also for device drivers. Some give it free as open source - not all. If we look at Linux desktop OS, it is still difficult to get some drivers for say SDX cards / graphic drivers. With Google behind Android and working closely with Manufacturers to get the drivers to the world for innovative hardware like 3D displays with recent HTC and LG phones. Microsoft has industry partners. Apple gets everything in-house. Nokia, finally in process of giving up Symbian. For Mozilla this would be a difficult challenge to get the drivers for all kinds of devices in the market. Easiest to target for the project would be a tablet with standard WIFI.
if we'll ignore all the GNU-like mobile operation system initiatives
we will lose
more than drivers. I am sure - the situation on today's mobile market or
certain advantages of reusing Google products - shouldn't
dictate Mozilla - how to make the world a better place.
> 3) Industry Support – The project needs to start with a reference hardware design. There are number of hardware designs available such as Beagleboard from hobbyist to OMAP ZOOM platforms for commercial innovative devices. There are many more. As the project is embedded in nature, the first reference design needs to be cheaper such that project participants can buy at cheaper price for producing demo software. Initially an emulator such as QEMU is good. Personally, hardware availability is the best for developers for such projects. Industry support is a must to get the hardware device drivers for new devices, otherwise the fate would be similar to linux running on old devices.
My, personal, opinion - Intel would be strong enough on mobile market
with open source
and NVidia would be with what is cool - they have an option for mobile
Ubuntu and they will
have for any mobile with Mozilla if it will be Mozilla's initiative.
Qualcomm and other ARM would
be just a producers of cpu's.. i hope..
My strong believe that - we all for good of all - need to make the
mobile market more
like a PC not like the consoles approach it has now. We shouldn't
leave the desicions
of what will operate in our pockets or homes to broadband, cell, or
other vendors.
I could bring the many terrible examples of such a power in corporative hands,
i hope you know it, already.
> The point I want to raise here is: will there be a support for the
> cloud based services and/or whether Mozilla itself is going to provide
> some kind of cloud
FreedomBox is working on it, if not - there are enough of other initiatives,
like Unhosted.org, ownCloud.org etc.etc.
I'm dedicated developer of Augmented Reality systems, knowing the
today's AR market and
corporations work (almost every you can name like a Big) in it -- what i need
to conclude here
- Mobile systems with all the camera's, GPS's and other tech inside -
aren't like the desktop, they the vaguest points of "" interest
and the first platform to defeat from proprietary corporations that i
could imagine.
Given that certain mobile vendors their partners etc. etc. could
control by gathering
and even intrusion - the tech in many mobiles, even in that - you may use now.
Given that Android haven't made the reputation of very open OS
(believe me i know what i'm talking about, there are facts "from the
fields", not only AR) and
every bit of that partial closeness is control in certain hands -- i hope
Mozilla will continue to do the best and un-compromised job in the area
of Open and Freedom systems.
ya knygar
> venture into the territory of the mobile OS.
i hope that Mozilla would be more like community
and part of wider FLOSS community,
not a player in this area =)
PS: i'v proposed in some recent survey to make at least the "cloud" Mozilla
mail for these BrowserID's, i think - it's the best
we could hope to see hosted in an open corporation
with a limited, comparing to proprietary resources.
The best of the best, for me, is to hope that - if such
a hosting would be provided it would be based on internal
Mozilla's facilities not on third-party cloud hosting l)
Robin Berjon
> On Tue, 2011-07-26 at 02:22 -0700, Natanael L wrote:
>> same as the HTML5 offline features? IMHO it seems quite strange to use
>> that for 100% local apps.
>
> pull updates from the network?
I can't think of any app for which I would not want a simple and straightforward update path, but I can think of several for which I absolutely do not want to upgrade to the latest version, want to upgrade but only after I've finished the current critical project which would not tolerate data loss or even new bugs, and it has often happened that I've wanted to downgrade back from an upgrade.
While I definitely find the App Cache approach to be rather elegant, I think that it tends to sweep quite a few things under the rug. This is one aspect for which I'd like to forget which standard may or may not be better, or even the fact that we have a standard at all and figure out what we'd like the solution to look like. Then we pick whichever standard's closest (if any) and bang it into shape.
One design consideration that I think should be important here is that the Web is not the Cloud. I want to be able to run an application from a third party without having to rely on them hosting a web site in perpetuity, trusting them not to do anything stupid with upgrades, or coming anywhere near my data — I want the latter on a Sync server which I trust. This is not a browser; we don't have to shoehorn everything into a tab from day one!
In my fantasy world we could get the BOBW by using git as the application distribution format (naturally with a UI that doesn't scare people away). It certainly has properties that are more interesting than either AppCache or Widgets. And it shouldn't be excessively painful to implement either. Using its HTTP protocol, we might just be able to transparently tie-in web sites as well.
> If you do want updates, W3C Widgets (or
> similar) plus widget updating becomes a second system to support
> alongside the HTML5 app cache.
If there are use cases for both, then the differences aren't that huge. A hackish converter from one to the other is not overwhelmingly hard to write: http://berjon.com/blog/2009/06/appcache-to-widget-converter.html. But again, I'd like existing standards to not be the beginning of this conversation.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Marco Zehe
> I think speech is good, but generally the processing required to
> achieve it is rather on the high side. It might be an exciting
> additional project, but perhaps its a sideline?
Accessibility is a core part of Mozilla's mission. A few months ago we
even formed a dedicated team for this within the engineering department.
So no, this is not a sideline.
Marco
Natanael L
On Jul 26, 2:13 pm, ya knygar <kny...@gmail.com> wrote:
> > P2P apps.
>
> it's webrtc.org by that - could be done like "real" web apps with
> indexed db, i think.
Yes, WebRTC is perfect for (most of) this. Real-time network
communication is essential.
> what i propose is:
>
> decouple the Chromeless like(by html5 stack styling idea and reuse
> Prism/WebRunner ideas, by-the-way) Mobile Gecko part as a installable
> browser for web Apps,
> by Web Apps.
This mostly the same as what I said. Just phrased differently.
[...]
> >You could think of it as Chromeless+drivers+kernel = a Linux
> >distribution with drivers, the kernel, base GNU sw and X/Wayland but
> >no Gnome/Unity/KDE.
>
> +1! Moz platform powered UI for OS - is the best desicion i could see,
> they are doing CSS/JS in these GUI's anyway, could be very, very, useful
> given that Win8 could also evolve into kind of Web OS.
> Imagine the community driven OS that would compete with Win, even
> on gaming and recreation field..
Indeed, we could have very exiting UI:s! Mozilla OS should REALLY be
split up in modules, the platform and the interface should be
separated. Integration between the two should be done with API:s that
ANY app can use.
> >The Mozilla OS would then be that base plus an
> >interface and userland apps (like Linux base with Gnome plus office sw
> >and browsers).
>
> do you mean - userland for like LibreOffice on Moz OS? ;
> Chromeless like GUI and base for running native web apps,
> along with recompiled/ported GTK/Qt/ other potable apps like
> on GNU/Linux distributive's now?
What I mean is this:
Ubuntu and Mozilla OS both use the Linux kernel and drivers for their
hardware.
Then things differ: Where Ubuntu use X (soon Wayland?) and GNU
software, there will be Chromeless on Mozilla OS.
Where Ubuntu use Gnome, there will be the Mozilla OS interface, built
in HTML+JS.
Where Ubuntu has applications like OpenOffice, Mozilla OS will run
HTML5 web apps, both web based like Google Docs and local ones (also
in HTML5; using HTML5 offline features) built for this purpose.
Porting software (like recompiling Qt apps) is a completely different
thing. That should be done too some day, but it's not a priority.
Mozilla OS should run HTML5 apps.
tuseroni
emulator written in javascript and running a linux kernel. this seems
like a good starting point. you have a complete OS you just need to
get a way to communicate more with the hardware and maintain
persistence. if you can get the browser to work as a bios for the
underlying hardware the kernel can access it as one would access a
bios in general (ok not entirely the pc emulator already HAS a bios
and would need to be rewritten to better communicate with the browser)
also the source is kinda hard to understand because its minified and
the author either didnt have, or didnt wish to release the un-minified
version. but never the less the idea is there, and much of the
underlying mechanisms are easy enough to understand and it seems to
get a lot of its power from the typed arrays.
Boris Zbarsky
> It would be good if packaged applications made use of an open
> standardized format... like W3C Widgets [2] [3]
This would probably be more likely if we hadn't been told to f** off
when Widgets was being developed and we provided feedback, fwiw.
-Boris
Robin Berjon
> I agree with you that mobile is where a lot of the innovation (and media attention) is focussed at the moment, but it does currently seem to have quite a high barrier to entry. If you want to target smartphones for example then unless you partner with hardware manufacturers and mobile carriers to build phones running your operating system out of the box, you're going to be asking users to flash their device. Not a particularly user friendly process and one which could potentially void their warranty.
A lot of manufacturers and telcos are concerned about having to deal with what is essentially a WebKit monoculture (the many minor divergences notwithstanding). I am very much certain that they would react positively to increased competition and would almost certainly back it. But before that, there needs to be something believable that can be shown. I'm not too worried about that part. It's getting from here to something that could ship OEM that's harder.
Mike Shaver
<sabre...@yahoo.co.uk> wrote:
> Things I'd prefer to see resources devoted to before this:
There are lots of things that Mozilla is working on, virtually all of
them with more resources than B2G. It's great that you have specific
desires, and useful for you to contribute to scratching them, but this
thread is about B2G and not what else Mozilla could be doing. It's
going to be busy enough just on that topic, so I'd thank everyone to
start their own threads in appropriate places to propose other work,
or announce the things they're going to be doing.
Thanks,
Mike
Ken Saunders
Exciting, bold, ambitious, daunting, overwhelming, etc and so on? :)
Of course, you probably had a better foundation to work with.
I am so far outside of my element here that I had to leave a trail of
popcorn to find my way out after commenting, but I just want to say
thanks (sincerely), good luck, and you guys freakin' rock! Seriously.
Ken
Ken Saunders
Natanael L
I started thinking about distributing installable Web App caches
*using Git*. Maybe that's a stupid approach as well, but I think that
could work.
I guess we'd like to have some standardized tags in the repositories,
so that it's easy to see which versions in the history are stable and
which ones are betas.
Also, application signing. Preferably the web apps would be installed
from a single installer file that contains all resources that we need
to store locally. This file would be signed cryptographically. How to
easily combine this with Git is a good question (secondary Git
repository with an installer file for each version (that somebody
bothered to make an installer for), with a pointer to the same version
in the code repository?).
More ideas are coming.
Chris Jones
> Very nice! Is it accurate to say that the point on "New web APIs" encompasses the ability to open UNIX sockets and similar interfaces?
>
> Or to take it a step further, perhaps with this project, is it possible to build a new abstraction for networking? (thus avoiding the hairiness of sockets -> a JS-callable version of zeromq perhaps [http://www.zeromq.org/])
The only networking APIs we expect to expose to content are
XmlHttpRequest and WebSockets, but if you have a compelling use-case
that can't be satisfied by those, please feel free to propose something
new :). The best place to do that would be the WHATWG mailing list.
Cheers,
Chris
Chris Jones
AaronMT
Tan Yew-wei
Mike Shaver
> As a huge Android supporter i dont see why you find the need to do
> this.
You are not the only one to ask this (implied) question, so I
apologize for not making it clearer in the original post.
> If Mozilla wants to support open source and the web in mobile devices
> you should better work as much as possible on the Android version of
> Firefox instead of trying to create a whole new O.S.
We are certainly going to continue with Firefox on Android. It's
improving all the time, and in pretty exciting ways. That's one of
the reasons that we're starting our explorations on Android, in fact.
We don't feel that we can integrate as deeply as we want on stock
Android, for purposes of this project's goals. We don't want to have
a browser next to the apps, we want to have the apps built with the
web platform, including the system apps like the launcher and the
dialer and SMS app and even the app manager/market itself.
We hope that the resulting APIs and capabilities make their way into
all browsers on all platforms, because they will dramatically increase
the reach of the web; we'll certainly be proposing the successful ones
for standardization, and for in-development feedback.
Mike
Chris Jones
> On Jul 25, 5:49 pm, Andreas Gal<g...@mozilla.com> wrote:
>> * New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
>
> Group) [1]. Has Moz evaluated those or considered joining that working
> group?
>
Mozilla has evaluated a few of the APIs. They solve of the problems
we're interested in, e.g. Contacts allows querying contacts, but not
all: Contacts doesn't allow updating contacts. Mozilla has been
involved with Devices before, with at least geolocation, and we would of
course continue as it makes sense for us to.
Cheers,
Chris
Carlo Daffara
> We don't feel that we can integrate as deeply as we want on stock
> Android, for purposes of this project's goals. We don't want to have
> a browser next to the apps, we want to have the apps built with the
> web platform, including the system apps like the launcher and the
> dialer and SMS app and even the app manager/market itself.
This is the approach used by Palm (now HP) with its WebOS; the system
services are actually
written in Node.js (a good example is the Contacts service) and most
of the UI is built in HTML5 and JS.
Carlo Daffara
Eric Dorman
> On Mon, Jul 25, 2011 at 3:30 PM, Stefan Arentz <stefan.are...@gmail.com> wrote:
>
> > I don't know the current state of Android/x86 but wouldn't that also
> > be a good platform to develop on? It could be an easy way to bootstrap
> > this. Same Android layer, same Gecko code, lots of overlap with Fennec/
> > Linux. It would mean that we could hack on BootToGecko on a much
> > easier to handle environment that runs in VMWare of VirtualBox.
>
> Depending on the state of Android/x86, that sounds very promising.
> Does that work for Fennec stuff now?
>
> Mike
I support this, but security has to be one of the first things in this
OS. I am creating a doc file that addresses my security concerns.
ya knygar
> *using Git*. Maybe that's a stupid approach as well, but I think that
> could work.
as i know it's something http://unhosted.org is up to,
along with de-coupling the web app data from web apps themselves.
Their conceptions would likely to be used in FreedomBox's in one
or another way.
I think http://freedomboxfoundation.org mailers has many related
ideas, i mean - i know they have, maybe even these which You
haven't thought about, yet..
Especially in Distributed, Decentralized and Secure systems, i think,
Mozilla team could benefit from their help..
FBX is *almost* a Debian project and has many
strong sides but web apps isn't among them so,
i think, FBX team could, in the turn, benefit from
Mozilla's help :)
By - that - i'm sure - Mozilla team are welcome
to discuss any security concerns as the system
B2G would deal with is Linux and Debian community
are among the strongest there.
http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
ya knygar
> services are actually
> written in Node.js (a good example is the Contacts service) and most
> of the UI is built in HTML5 and JS.
just as you'v mentioned,
i think - when HP would
compete with MS on it's
own market, it's
likely that WebOS would
became an App for Win8.
So there would be a platform
in platform, just like a part of
B2G could be (potentially)
As long as it all would finally,
(potentially) support W3C/IETF
work and standards - building
web apps platforms, it's cool,
i think. As - as long as Mozilla
is good in web, there is chance
for a real Moz OS competing
with proprietary and even closed
one's.
Benoit Jacob
> On Mon, Jul 25, 2011 at 01:23:45PM -0400, Mike Shaver wrote:
>> On Mon, Jul 25, 2011 at 1:19 PM, Rob Campbell <rcam...@mozilla.com> wrote:
>> > Why Android and not a PC to start with? Would it be easier? Fewer moving parts, fewer device unknowns? Is a PC-level device on the table as well?
>>
>> We might prototype some stuff on a PC, but the project is really about
>> the device space. We had to pick somewhere, and this seems like where
>> the energy is best spent.
>>
>> Desktop devices tend to be harder to get good open drivers for without
>> pulling in things like X, which we don't want to do.
>
> Don't worry, mobile devices are not better for good open drivers, with
> or without X. And you get additional fun from the lack of standards
> on the hardware side...
The recent Android devices I've seen all supported OpenGL ES 2.0 well;
that's all we should need.
Benoit
ya knygar
> more useful than Android. Or even NetBSD as the core of the final
> system.
+1 i have proposed http://wiki.openmoko.org/wiki/SHR
there are misleading info, i think,
that there aren't FLOSS mobile systems
that could compete easily, that's why Android
is here, and it's best and "real" among these "academic"
projects,
i think it's not true, i think Android is pre-installed
(in some - almost firmwared)
on every second mobile by other reasons :)
Mike Shaver
>> And how about starting from the OpenMoko O.S.? I think it could be
>> more useful than Android. Or even NetBSD as the core of the final
>> system.
>
> +1 i have proposed http://wiki.openmoko.org/wiki/SHR
Please see my post in this thread about OS selection. Experimental
results for bringing up capable systems on available hardware are
welcome, but abstract advocacy isn't helpful at this stage.
Thanks,
Mike
ya knygar
> results for bringing up capable systems on available hardware are
> welcome, but abstract advocacy isn't helpful at this stage.
I have just read (again) all your posts on topic,
and - still - can't understand how i can help more on Experimental results-
for B2G in current situation..
You'v said
> It's great that you have specific
> desires, and useful for you to contribute to scratching them, but this
> thread is about B2G and not what else Mozilla could be doing.
I think - underlying kernel and platform of B2G so it have started and
would be mentioned in Mass Media like a Mozilla OS (no, really)
is important enough to
start a separate topic about such an essential aspects,
would you create one?
if people from B2G team would describe:
what existing OS's you have evaluated for use in B2G
with detail analyze if there where, any -
so we - who talk about existing mobile OS's to build from:
could discuss and help - starting from what You as a Mozilla
OS team have, not from the scratch and own, separate, project.?
Thanks in advance.