B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes

Posté par  (site web personnel) . Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
25
14
nov.
2011
Mozilla

Un gecko « désigne l’ensemble des lézards de la famille des geckonidés » et Gecko « est un moteur d’affichage libre de pages Web utilisé par de nombreux navigateurs Web, tels que SeaMonkey (anciennement Suite Mozilla), Firefox, Camino ou encore Netscape ». Le projet de la Fondation Mozilla Boot to Gecko (aka B2G) n’a pas pour but de mettre des bottes à un lézard, mais de faire de Gecko le cœur d’un système d’exploitation pour téléphones intelligents et tablettes.

Projet de R & D Boot to Gecko a pour objectif de trouver les manques de l’intégration du Web avec le matériel, et de promouvoir de nouvelles interfaces de programmation (API) comblant ces manques dans les autres implémentations Web et de systèmes d’exploitation. Un peu comme presque‐feu‐WebOS l’a fait, mais de manière un tantinet plus ouverte.

N’attendez donc pas de smartphones ou tablettes Boot to Gecko sur le marché pour très bientôt. Comptez sur le courant 2012 pour un système hackable et installable comme un Cyanogen ou Replicant.

Aller plus loin

  • # Francais

    Posté par  . Évalué à 4.

    On remarquera que les screens sont Francais. Salut les gars ;-)

    • [^] # Re: Francais

      Posté par  . Évalué à 3.

      Qui m'a mis dans son carnet d'adresse ? Oo

    • [^] # Re: Francais

      Posté par  . Évalué à 1.

      Oui, je remarque que les copies d'écran sont en français. CQFC.
      ------------> [ ] blam !

  • # Et sinon Gecko il est où ?

    Posté par  (site web personnel) . Évalué à 3.

    Gecko « est un moteur d’affichage libre de pages Web utilisé par de nombreux navigateurs Web, tels que SeaMonkey (anciennement Suite Mozilla), Firefox, Camino ou encore Netscape »

    En vrai, Gecko il est utilisé où à part dans les produits de Mozilla (ou fork des produits suite à leur abandon ?)
    Parce que :

    • SeaMonkey : comme indiqué ça vient de Mozilla (avant même Firefox, non ?) et c'est juste que ça a été abandonné, certains ont donc pris le relais mais logique que ça y soit
    • firefox : ha bon ?
    • Netscape : de part l'histoire c'est logique (m'enfin ça existe encore ?)

    Donc il reste camino (on aurait aussi pu indiquer thunderbird).
    Ca fait pas grand chose pour "utilisé par de nombreux navigateurs" de coller trois fois des produits (ou l'ayant été) de Mozilla / Netscape.

    Mais histoire que ça ne reste pas sur un vilain troll, ça m'interpelle lorsqu'on voit la profusion de webkit embarqués.
    Est-il beaucoup plus compliqué d'embarquer un webkit qu'un gecko ?
    Est-il beaucoup plus hype/fun d'embarquer un webkit qu'un gecko ?
    Au final, n'est-ce pas dommage pour Mozilla qu'il n'y en ait pas plus ? (mais là si on pense au "support" de XUL, on se dit que Mozilla n'a malheureusement jamais su faire de ses produits une vrai plateforme)

    • [^] # Re: Et sinon Gecko il est où ?

      Posté par  . Évalué à 9.

      Gecko il est utilisé où à part dans les produits de Mozilla

      Quelques produits basés sur XUL que j'utilise ou ai utilisé:

      • Nvu, Komposer, BlueGriffon : éditeurs HTML
      • Songbird : media player
      • Miro : video player
      • Instantbird : messagerie instantanée
      • Chatzilla : client IRC

      Et, bien sûr, les produits de la MoFo que j'utilise tous les jours:

      • Firefox
      • Thunderbird
      • Lightning
      • [^] # Re: Et sinon Gecko il est où ?

        Posté par  (site web personnel) . Évalué à 2.

        Hum, attention, je parlais bien de gecko et non XUL (d'ailleurs seamonkey n'est pas en XUL)

        Nvu, Komposer c'est bien basé sur l'éditeur de la suite mozilla, non ?
        (oui car la partie intéressante était surtout Gecko ailleurs que chez Mozilla ou dérivé)

        • [^] # Re: Et sinon Gecko il est où ?

          Posté par  (site web personnel, Mastodon) . Évalué à 6.

          seamonkey n'est pas en XUL

          Euh si.. Tout est en XUL dans seamonkey. Depuis 99, tous les produits Mozilla (ou dérivé) sont en XUL. (Mozilla suite, Firefox, Thunderbird, Sunbird...).

          Kompozer est le descendant de Nvu, qui est un descendant de l'éditeur Composer, qui était fourni dans la suite mozilla. Donc eux aussi en XUL.

          • [^] # Re: Et sinon Gecko il est où ?

            Posté par  (site web personnel) . Évalué à 3.

            Ha, merdouille. Je croyais que firefox et la suite était fait différemment...

            Donc bon, au final, Gecko intégré ailleurs qu'en XUL ça n'existe pas quoi. Dommage, car il a fallu attendre que webkit soit là pour intégrer partout un navigateur potable (je pense aux toolkits, qt, gtk, etc)

            • [^] # Re: Et sinon Gecko il est où ?

              Posté par  . Évalué à 2.

              Sous Windows, il y a K-meleon qui utilise Gecko avec une GUI Win32 native.
              Sous GNU/Linux, il y a epiphany utilisait GTK+Gecko, mais maintenant il utilise WebKit.

        • [^] # Re: Et sinon Gecko il est où ?

          Posté par  . Évalué à 1.

          Nvu, Komposer c'est bien basé sur l'éditeur de la suite mozilla, non ?

          chatzilla aussi, non ?

    • [^] # Re: Et sinon Gecko il est où ?

      Posté par  (site web personnel) . Évalué à 3.

    • [^] # Re: Et sinon Gecko il est où ?

      Posté par  (site web personnel, Mastodon) . Évalué à 7.

      Je pense que ce que tu cherches, c'est ça : http://www.mozilla.org/projects/mozilla-based.html ;-)

      De rien.

      Est-il beaucoup plus compliqué d'embarquer un webkit qu'un gecko ?

      Je pense que tu veux dire l'inverse. Oui, gecko est plus compliqué à embarqué que webkit. En même temps, gecko est plus fait pour embarquer (cf xulrunner), que pour être embarqué. Et puis l'API d'embedding a été supprimé recement car plus maintenue et super trop obsolète. Une discussion a eu lieu sur gecko embedding au mozcamp de ce week end, avec notamment des packageurs linux (dont Glandium, pour Debian, packageur officiel pour les softs mozilla). Est ce qu'il y a un intérêt à refaire une API embedding ? qui a besoin d'embedding etc. Si vous vous sentez concerné, allez en discuter sur les newsgroup de mozilla (voir google groups)

      mais là si on pense au "support" de XUL, on se dit que Mozilla n'a malheureusement jamais su faire de ses produits une vrai plateforme

      Ce n'est pas une question de n'avoir pas su faire, c'était une question de volonté, une question politique produit. La principale raison : si ils avaient voulu faire de la plateforme un vrai produit (genre promouvoir XulRunner etc), ils auraient été obligé de gelée un certain nombre d'API, ils auraient eu plus de boulot parce qu'il y aura fatalement eu des choses à développer et à corriger qui n'ont pas de rapport avec Firefox. Or, la guerre des navigateurs sévi, le web se propriétise de plus en plus et Firefox est devenu le fer de lance de Mozilla. C'est LE produit par lequel Mozilla peut se faire entendre, peut promouvoir un web libre et ouvert (cf le manifesto mozilla). Ne pas supporter officiellement la plateforme gecko (par XulRunner etc), permet aux développeurs mozilla de faire évoluer gecko dans la direction qu'ils veulent, en toute liberté, en cassant tout ce qu'ils veulent casser quand c'est nécessaire.

      Quand je dis plateforme, je parle bien de la plateforme gecko, XUL. Ce que Mozilla promeut par contre bien évidement, c'est la plateforme "web", qui est la couche au dessus si on peut dire. Et qui fait abstraction au final du navigateur (en théorie :)). On le voit d'ailleurs avec B2G : utilisation des technos web partout.

      • [^] # Re: Et sinon Gecko il est où ?

        Posté par  (site web personnel) . Évalué à 4.

        Je pense que tu veux dire l'inverse

        Oui, bien sur :)

        Est ce qu'il y a un intérêt à refaire une API embedding ? qui a besoin d'embedding

        Qui a besoin ? A la rigueur les mêmes que ceux qui embarquent du webkit... Et si webkit prend de l'importance (et bouffe peu à peu des parts à Gecko) c'est en bonne partie pour ça. Le web ouvert c'est bien, mais le web ouvert uniquement via Mozilla non. Et jusqu'à l'apparition de webkit pas grand monde ne voulait embarquer du gecko quand même (comparativement à embarquer du webkit aujourd'hui).

        ils auraient été obligé de gelée un certain nombre d'API

        En même temps vu le rythme des sorties de leurs produits à l'époque, c'était pas tellement un problème.

        Après je comprend ce que tu écris, mais je reste déçu de ce qui s'est passé, alors qu'il y a quelques années mozilla disait que XUL était l'avenir et n'a jamais correctement su communiquer dessus...

        • [^] # Re: Et sinon Gecko il est où ?

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          alors qu'il y a quelques années mozilla disait que XUL était l'avenir

          Ils n'ont jamais vraiment dit ça. Par contre, c'est peut être de ma faute si tu le penses, puisque c'est plus ou moins ce que je disais à l'époque sur xulfr.org et ailleurs, croyant au développement de XulRunner &co. Et puis patatra, un jour Mozilla annonça que XulRunner ne sera jamais un "produit" (ils l'ont fait parce que je pense qu'ils se rendaient compte que XulRunner prenait trop d'ampleur, et que ça allait gêner le développement de Firefox dans le futur).

          Et comme toi je fus extrêmement déçu... XulRunner et XUL restera un truc de geek, pas une technologie utilisée massivement en dehors de Firefox et TB.

          • [^] # Re: Et sinon Gecko il est où ?

            Posté par  (Mastodon) . Évalué à 4.

            Apparemment, Debian aussi y croyait puisqu'ils ont packagé (et continuent de packager) xulrunner et voulaient que ça servent pour tous les produits XUL (Thunderbird/Icedove par exemple). C'est vraiment dommage, ça aurait pu marcher.

        • [^] # Re: Et sinon Gecko il est où ?

          Posté par  . Évalué à 3.

          Est ce qu'il y a un intérêt à refaire une API embedding ? qui a besoin d'embedding

          Si webkit prend de l'importance (et bouffe peu à peu des parts à Gecko) c'est en bonne partie pour ça. Le web ouvert c'est bien, mais le web ouvert uniquement via Mozilla non. Et jusqu'à l'apparition de webkit pas grand monde ne voulait embarquer du gecko quand même (comparativement à embarquer du webkit aujourd'hui).

          Ben le truc c'est que ça n'a jamais été facile d'embarquer du gecko, car ce n'était clairement pas fait pour. Ensuite Webkit est arrivé (sans s'presser) et a comblé le besoin de "widget de visualisation HTML all-purposes" et c'est pour ça (simplicité, mais aussi le fait que les devs de gecko s'en foutaient) que les utilisateurs de gecko sont tous passés à webkit... Parmi ces utilisateurs, on trouve epiphany, mais aussi des yelp, devhelp, liferea et similaires.

          Donc en résumé il y avait clairement un besoin pour un widget "HTML/Web", et gecko a été utilisé pour tout un temps, mais maintenant webkit a pris la place, et on se dirige vers un web avec quasi-uniquement webkit... (Safari, Chrome, Epiphany, plein de trucs en ligne, plein d'applis tierces, etc.)

        • [^] # Re: Et sinon Gecko il est où ?

          Posté par  . Évalué à 2.

          Et si webkit prend de l'importance (et bouffe peu à peu des parts à Gecko) c'est en bonne partie pour ça.

          C'est en petite partie pour ça. La grosse partie, c'est Chrome, la marque, d'où la réaction de mozilla de se concentrer sur la marque Firefox.

  • # Dépend du matos

    Posté par  . Évalué à 2.

    faudra juste des téléphones avec 8Go de ram

  • # Ah ouais d'accord

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    Lorsque j'ai entendu parler de B2G pour la première fois, je pensais que Mozilla voulait lancer un Chrome OS sauce maison. En fait, à en croire ces screens, nous avons affaire à un véritable clone d'iOS/Android, du moins en apparence (la FAQ nous apprend que l'objectif est surtout de permettre aux programmeurs de contrôler le plus possible l'appareil avec des applis HTML5, si j'ai bien compris).

    Quitte à sortir une banalité, j'espère voir rapidement Gaia (l"user experience" du projet) acquérir son "distinct look-and-feel", histoire de voir si la communauté, puisque le projet semble bien ouvert, s'en tire aussi bien que les designers d'Apple, Android ou HP... ou MeeGo et Tizen, et pourquoi pas Microsoft et les mecs de Gnome OS ? En ce moment, les interfaces pour tactile surgissent de partout, et je suis curieux de voir comment elles vont parvenir à se distinguer intelligemment.

    • [^] # Re: Ah ouais d'accord

      Posté par  (site web personnel) . Évalué à 3.

      Ce n'est pas du tout le but du projet à en juger par la FAQ, mais oui ce serait super intéressant. Mais par pitié, si iOS et Android se ressemblent et fonctionnent bien tout en empruntant l'un à l'autres, pitié disais-je pas de tiles à la Metro !

  • # Quelques compléments

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Hello,

    Je reviens du meeting mozcamp qui a eu lieu à Berlin ce week-end dernier, regroupant bon nombre de contributeurs européens et africains.

    Et nous avons eu droit à une conf sur B2G, avec demo etc. (Sachant que je suis bien pote avec les deux français qui font parti de l'équipe B2G, Vivien et Mounir, j'ai déjà eu droit à une démo il y a quelques semaines déjà :) (ouai, je crâne grave))

    Ce qu'il faut savoir donc :

    • Mozilla est déjà en relation avec des fabricants, qui sont très intéresses pour avoir une alternative à android.
    • Si la roadmap est tenu (hum), il y aura des téléphones B2G à la fin 2012
    • Dans le projet B2G, il y a deux projets en gros :
      • les API web, qui vont taper dans le système
      • l'interface.
    • L'interface sera interchangeable, personnalisable à donf par les utilisateurs ou fabricants, et pour cause : tout sera en HTML. Donc si pour le moment ça ressemble à de l'android, ça pourrait ne plus l'être dans quelques mois, ou en tout cas, des alternatives seront possibles.
    • le but est de permettre d'avoir des applis webphone qui soient interopérable entre webphone "html" (il y a des specs aux W3C pour les paquets webapp, je suppose qu'ils vont reprendre ça, je ne sais pas). Pas besoin de SDK apple ou windows qui coute la peau des fesses, pas besoin d'apprendre un enième langage si vous faites déjà du web. Et pas obligé de passer par un trucstore pour installer l'appli (comme les app d'android).
    • le but aussi est de fournir une alternative d'os qui ne soit pas dépendant obligatoire d'un fournisseur (google ou apple par ex) pour tout ce qui est données persos etc.. Les autres projets mozilla qui sont en cours et concernant le respect de la vie privée etc serviront dans B2G à priori.
    • pour le moment, B2G marchouille (avec pleins de bug, c'est encore super experimental) : on peut envoyer et recevoir des SMS, on peut émettre et recevoir un appel (un bug empêche pour le moment de raccrocher :-) ).
    • il y a encore pas mal de dépendance avec des composants android, mais ça disparaitra à l'avenir, (pour n'avoir au final qu'un linusque et un gecko avec les libs qui vont bien)

    Et petit rappel : c'est un projet libre !!! Vous pouvez y contribuer !! C'est l'occasion de faire du html hard core (cool ! plus besoin de se préoccuper d'une compatibilité avec tel navigateur, vous pouvez utiliser les dernières fonctionnalités CSS et HTML sans retenu !), l'occasion de faire de la prog système (développement des apis entre autre), ou encore l'occasion de proposer des solutions qui permettent d'améliorer l'expérience utilisateur, ou encore qui permettent d'avoir une interface "différente".

  • # Prism

    Posté par  (site web personnel) . Évalué à 6.

    Bonjour

    je profite du sujet pour demander quelle solution est utilisé pour faire des applications standalone, j'utilise actuellement prism mais il n'est plus maintenu par mozilla et ses remplacants on l'air abandonnés ou tournés vers windows.

    • [^] # Re: Prism

      Posté par  . Évalué à 4.

      J'utilisais aussi Prism et depuis peu j'ai remplacé ça par un profil spécifique de Firefox.
      J'ai donc par exemple un raccourci qui me lance Firefox avec comme option -P GMail -no-remote, ce profil étant configuré pour n'afficher qu'une page GMail sans barre d'adresse, de favoris...
      D'après ce que j'avais pu lire sur le web c'était un moyen de remplacer Prism.

  • # Concrètement ...

    Posté par  . Évalué à 3.

    C'est un OS qui va reposé sur un Android ou sur un Linux plus classique ?

    • [^] # Re: Concrètement ...

      Posté par  . Évalué à 3.

      C'est une très bonne question ça, et ils n'y répondent pas dans la FAQ.
      De ce qu'on peut lire :

      the updater-binary built by CyanogenMod has been observed to corrupt the /system filesystem of the Galaxy S II when applying an update.zip

      Ah, ils doivent partir d'Android/Fennec alors.

      Start porting gecko to directly use native libs instead of java wrappers. Big project.
      Hmm, au fond, ils veulent le faire tourner sur un OS posix ?

      Linux a priori, pour ce qui est de la libc je sais pas…

    • [^] # Re: Concrètement ...

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      De ce que j'ai compris : ils partent d'android pour ne pas avoir à démarrer from scratch et pouvoir aussi utiliser au minimum le téléphone pour tester les nouvelles api. Et petit à petit ils vont remplacer les applis natives par des webapp.

      à priori, au final, il ne restera d'android pas grand chose, si ce n'est le noyau linux et ce qui va autour au niveau système. Si j'ai bien compris. :-)

  • # Régression

    Posté par  . Évalué à 2.

    Donc là on parle d'une plateforme qui va reproduire toutes les APIs du noyau, au dessus du noyau. Avec comme plus-value un sandboxing des applis (comme ça on peut charger le code depuis le web sans s'inquiéter) et comme moins-value que, bah, le code est pas natif.

    Mais heu, c'est pas possible de juste sandboxer des applis natives ?

    • [^] # Re: Régression

      Posté par  . Évalué à 3.

      Si, mais les applis natives ne sont pas en HTML/CSS/javascript.
      En fait, ils ne veulent pas "reproduire" les apis noyaux, ils veulent juste faire des bindings si je comprends bien.

    • [^] # Re: Régression

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      comme moins-value que, bah, le code est pas natif.

      à l'heure actuel, les applis dans android sont en java. Donc déjà pas en code natif. y a probablement du JIT, mais bon, les applis web aussi c'est pareil, y a du JIT au niveau javascript (la lourdeur java en moins).

      Bref, je ne vois pas de moins value là dedans.

      La moins value que je vois (c'est mon opinion), c'est que developper une webapp va être probablement plus long, car on n'a pas forcément tous les widgets d'interface prêt à l'emploi que l'on dispose dans le toolkit d'android par exemple (bon, j'y connais pas grand chose à android non plus). à moins que Mozilla passe la seconde sur un remplaçant standardisé de XBL (permettant de développer des composants réutilisables).

      • [^] # Re: Régression

        Posté par  . Évalué à 3.

        moi je dirais pas sur, ca serait même sans doute plus rapide et il y aura forcement un toolkit pour l'UI de base. et puis pas de compilo, pas de eclipse, pas de android platform tools.
        tu pond un ptit js/html, scp pif paf fini

        sur android, passé le hello world c'est relativement le bordel quand même et pour deployer une app il faut passer un bout de temps a tout setup (même sans eclipse)

    • [^] # Re: Régression

      Posté par  . Évalué à 3.

      Avec comme plus-value un sandboxing des applis

      et le déploiement simplifié (pas d'installation, tout le monde à jour).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Régression

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        pas d'installation

        Si au contraire. Le terme Webapp est peut être utilisé à tord, mais dans le cas de B2G, ça ne veut pas dire hebergé sur un serveur. Une webapp au sens B2G, est une appli qui utilise les technos web, mais qui est packagée pour être installé sur le téléphone. Heureusement encore, parce que si il fallait obligatoirement une connectivité pour faire fonctionner la moindre appli :-)

        Donc installation, et donc mise à jour à faire. Et au niveau format de paquet, on peut imaginer que ça utilisera ça http://www.w3.org/TR/2011/REC-widgets-20110927/ . ou pas.

        • [^] # Re: Régression

          Posté par  . Évalué à 1.

          Je comprends du coup il y a un serveur web en local ou ils utilisent autre chose ?

          Pour le déploiement, il serait, je pense, jolie d'avoir quelque chose à la JavaWebStart.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Régression

            Posté par  (site web personnel) . Évalué à 7.

            Pour le déploiement, il serait, je pense, jolie d'avoir quelque chose à la JavaWebStart.

            pfiou, j'ai failli m'étouffer ! Faut pas écrire des choses pareilles, joli et javawebstart...

          • [^] # Re: Régression

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Depuis quand on a besoin d'un serveur web pour afficher un fichier html ? ;-)

            • [^] # Re: Régression

              Posté par  . Évalué à 0.

              Depuis qu'on se sert du web pour faire des applications (d'où le terme de webapp).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Régression

                Posté par  (site web personnel) . Évalué à 5.

                Non non.
                Tu prend une zoli nimage page html, tu y colles du javascript, du xhr/jsonp/websocket, du css pour le style et hop tu l'as ton application.
                Et si tu veux faire une application de prise de note (exemple au pif) du ne communique jamais avec l'extérieur, tu utilise l'api de stockage de données d'HTML5 (sait plus comment ça s'appel, avant il y avait Google Gears) et tu peux avoir de la donnée locale.

                Oui, en gros ça reviendrait à dire que cette API correspond à l'API d'accès aux données (disque dur, système de fichier, ...), que html+css(+js) est le moteur de rendu, et que js(/dart) est le langage dans lequel tu programme ton application. Le navigateur devient ton "OS". Avec un parallèle du genre tu es très proche de la logique classique d'une application. Et si tu veux communiquer avec l'extérieur, ben tu fais du client serveur.

                • [^] # Re: Régression

                  Posté par  . Évalué à 3.

                  tu utilise l'api de stockage de données d'HTML5 (sait plus comment ça s'appel, avant il y avait Google Gears

                  Storage ou web storage si je en me trompe pas, c'est limité à 10 Mio et c'est sous la forme clef -> valeur si je ne me trompe pas.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Régression

                    Posté par  . Évalué à 2.

                    C'est le navigateur qui fixe cette limite, donc je suppose que sur B2G ils feront ce qu'il faut.

                • [^] # Re: Régression

                  Posté par  . Évalué à 0.

                  Bah c'est exactement cque jdis (et critique) : ton navigo est l'OS. Cqui est complètement con puisque, bah, t'as djà un OS en dessous, sûrement plus performant et sécurisé que n'importe quel "moteur web".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.