C'est un cycle court, donc ce n'est pas considéré comme polluant dans la mesure où le maïs de l'année suivante va emprisonner la même quantité de CO2. C'est le même raisonnement qui est appliqué quand on dit que les pellets de bois ne sont pas polluants par opposition au mazout (qui est un cycle très long): tu ne libères pas du nouveau carbone dans l'atmosphère.
Du reste, si ton maïs passe par une phase "plastique" à courte durée de vie, il finira de toute façon dans l'incinérateur avec les autres déchets. Mais effectivement c'est un cycle court donc c'est moins polluant que du plastique à base de pétrole.
Les liens symboliques c'est à faire en dernier recours quand même, car on se trompe vite dans les droits (un -a manquant derrière le cp et c'est foutu) et ça peut causer des dysfonctionnements assez folklo à débugger. Il faut commencer par les usual suspects (voir plus bas) avant de chipoter.
Tu peux procéder avec du -sh /* | sort -h et aller récursivement dans les dossiers qui ont une taille suspecte (tu peux aussi utiliser baobab si tu as Gnome, et il y a sans doute un équivalent KDE)
Typiquement, ton espace disque est bouffé par:
Les archives de ton gestionnaire de paquets. Commence par un pt-get clean ou équivalent.
Des logs, en particulier si un événement s'est produit et a rempli le disque. Une fois j'ai eu un disque rempli par des logs qui me prévenaient que mon disque était presque plein toutes les 5 secondes… jusqu'à ce qu'il n'y ait plus de place pour écrire les logs. Idem avec postfix.log si tu as un problème de relai de mail.
Des gros fichiers temporaires dans /tmp (sauf si tmpfs), genre une iso téléchargée avec Firefox et autres joyeusetés du genre.
Commence par vérifier cela avant de perdre ton temps avec baobab.
J'ai été surpris par ce nouveau connecteur et l'absence de port USB. Il me semblait en effet qu'en Europe les smartphones devaient obligatoirement être équipés d'un port micro-usb pour le chargeur, mais apparemment donner un adaptateur avec le smartphone est suffisant (ce qui est con vu que du coup on perd l'avantage du chargeur universel, sauf à se balader toujours avec l'adaptateur).
Compiler quelque chose n'impose pas de l'installer, par contre cela impose d'installer toutes les dépendances de compilation. C'est le problème mentionné ici: le mainteneur de lfs ne veut pas installer systemd mais la fusion lui impose d'installer les dépendances de compilation de celui-ci, qui comprennent la libdbus.
Après il pourrait probablement installer la libdbus sans installer le dbus complet, comme c'est déjà le cas sur une debian serveur par exemple.
Posté par nud .
En réponse au journal udev forké.
Évalué à 3.
systemd dépend de la libdbus car il propose une "activation dbus" similaire à l'activation par socket, mais utilisant un nom dbus. Si on avait un autre mode d'IPC de type bus répandu il dépendrait probablement de la lib idoine pour fournir également une activation paresseuse pour ce protocole d'IPC.
Non, la fusion oblige juste à compiler systemd, mais udev reste fonctionnellement indépendant.
les dev de Dbus avaient plus ou moins promis que la fusion n'empêcherait pas l'usage de Dbus sans systemd
Non, On peut toujours utiliser dbus sans systemd… Le problème est ici udev, qui est compilé avec systemd, qui nécessite la libdbus.
Gnome (et sa galaxie d'applications) qui va nécessiter systemd
Non, Gnome utilise juste de certaines interfaces dbus simples implémentées par systemd et qui pourraient être implémentées par d'autres démons de la même façon (genre org.freedestktop.hostname1). On ne peut pas même parler de dépendance: si tu n'as pas de démon qui implémente cette interface tu peux juste pas changer ton hostname depuis la GUI.
les gars de LFS ont déjà fait un script pour compiler Dbus sans systemd
Non, dbus a pas besoin de systemd, c'est udev qui a été fusionné, pas dbus.
Posté par nud .
En réponse au journal udev forké.
Évalué à 7.
Sauf que systemd est idéalement placé pour se rendre compte que le service disparaît au moment où il disparaît. Idem s'il bloque. Il reçoit le sigchld, il contrôle le socket, bref, il est où il faut pour ça.
Les services externes de monitoring (mon, monit, god et consorts) ne font que du polling, donc si tu vérifies tes services une fois toutes les 5 minutes tu cours le risque de rester avec un service down pendant 4:59 au pire des cas. Systemd peut réagir immédiatement.
J'attends la sortie de wheezy justement pour pouvoir utiliser systemd sur des serveurs, justement pour avoir cette surveillance qui fonctionne bien mieux avec systemd qu'avec mon.
Posté par nud .
En réponse au journal udev forké.
Évalué à 3.
Juste car c'est le même auteur, tu peux tout à fait faire tourner ces petits programmes triviaux sans systemd, certaines distro le font. Ça utilise probablement un .so commun mais ça marche aussi avec sysvinit.
Posté par nud .
En réponse au journal udev forké.
Évalué à 10.
la tentative de dépendance obligatoire dans GNOME.
Ce point a déjà été discuté précédemment. Gnome ne dépend pas de systemd, mais il dépend d'interfaces D-Bus diverses (genre org.freedesktop.hostname1) spécifiées au sein de freedesktop.org, et qui sont pour l'instant uniquement implémentées par des petits utilitaires fournis par systemd. Ces interfaces sont triviales (vraiment) et peuvent être implémentées facilement par un autre outil.
Il s'agit juste de déplacer la maintenance des outils spécifiques aux distros au sein des distros au lieu de les garder au niveau de l'upstream, car de toute façon les outils upstream (system-tools-backend) ne supportaient que redhat, debian et opensuse.
Posté par nud .
En réponse au journal Une histoire de fork.
Évalué à 0.
Dernière modification le 22 août 2012 à 11:31.
Elles sont toutes innovantes ?
La liste n'est peut-être pas exhaustive mais elle n'est pas non plus limitée à XUL, une bonne dose des applications citées utilisent juste NSS, SpiderMonkey ou Rhino…
dans un monde idéal. Mais un éditeur de logiciel ne va pas attendre 4 ans que la nouvelle Debian sorte pour avoir le paquet officiel de la dernière version de XulRunner.
Et pourquoi le ferait-il? En quoi utiliser une version forkée de xulrunner change-t-il quelque chose à cela? Ou bien le problème est-il pour l'éditeur de logiciel d'attendre que Mozilla ne release une nouvelle version de xulrunner ? Côté éditeur, on peut soit packager une nouvelle version de xulrunner soi-même, soit compiler son paquet statiquement. On fait des trucs similaires dans ma boite. Si au contraire c'est Debian qui veut la nouvelle version de Thunderbird, elle se débrouillera pour fournir un package du dernier xulrunner.
Non, ils doivent la modifier, parce qu'ils ont des besoins spécifiques que ne fourni pas le XulRunner standards.
Il ne faut pas voir XulRunner comme une lib classique, mais comme une plateforme, un framework embarquable.
Comme Qt, qui fournit QtQuick, Webkit, un client HTTP, un environnement de scripting javascript et plein d'autres trucs. Qt n'est pas une lib classique, c'est une plateforme, un framework embarquable. Est-ce pour autant que tout le monde forke et patche ? Non. Il s'agit juste de faire en sorte que la plateforme fournisse tout ce qui est nécessaire, et d'ajouter ce qui manque pour avoir une plateforme satisfaisante pour tous les usages, et réduire d'autant les coûts de maintenance des différentes applications.
Si ce n'est pas possible, c'est que xulrunner n'était pas le bon framework pour développer l'application. Si c'est suite à un manque de volonté de la part de Mozilla, tout pareil.
Je sais que Mozilla assume pleinement le fait que xulrunner est avant tout la plateforme de Firefox et refuse d'implémenter des choses qui ne sont pas dans l'intérêt immédiat de Firefox. Il n'y a pas de problème intrinsèque avec cela, il faut juste alors arrêter de promouvoir xulrunner comme une plateforme de développement généraliste.
Et ce genre de situation arrive souvent dans les projets XulRunner conséquents, que j'ai vu passé.
Pourquoi cela n'arrive-t-il pas avec les éditeurs basés sur webkit ? Peut-être est-ce un problème de design ou de modularité du moteur gecko, ou de refus d'ajouter des fonctionnalités qui ne sont pas directement nécessaires à Firefox (bien que avec les nouveaux webdev tools…) ? D'un autre côté, j'imagine mal un truc comme sunbird ou thunderbird nécessiter une modification du moteur de rendu. Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.
Toutes les applications ne sont pas forcément packagées, et encore moins pour toutes les distros ou versions de distros. Donc l'utilisateur devrait utiliser le XulRunner proposé dans sa distro, bien souvent incompatible pour les applis complexes (surtout celles qui contiennent des composants binaires)
Non, c'est un raccourci malsain, car comme dit plus haut, le fait de pouvoir le faire n'implique pas qu'on ne peut pas faire autrement. On peut distribuer une appli compilée statiquement, et de toute façon le problème est le même pour les dépendances déjà présentes dans la distro (cairo, gtk+, libx* et toutes les autres). Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.
Ben, en fait, oui. On travaille avec deux projets libres, l'un en GPL et l'autre sous copyright attribution double licence. Dans l'un des cas on remonte les patches, dans l'autre pas (la politique, tout ça, je passe les détails). On est une très petite boite.
Donc oui, dans les faits ça me coûte moins cher en temps de remonter les patches une fois que de maintenir ma pile de patches et de les mettre à jour à chaque nouvelle version mineure du projet. Dans le premier cas il m'a fallu quelques jours pour faire accepter le patch, dans l'autre il me faut chaque fois une journée, au mieux, pour adapter les patches. Après genre cinq versions, la première façon de faire est clairement gagnante en terme de temps dépensé.
Quant à l'intérêt, encore une fois c'est l'intérêt immédiat comparé à un intérêt à plus long terme. Au moment de commencer le jeu il est bien plus facile de forker. Après un an ou deux de galère et de patches divers je me demande si certains ne préféreraient pas avoir moins de code à maintenir et utiliser un moteur commun. Moins de code à maintenir, c'est aussi plus de temps à investir dans d'autres aspects du développement, comme de nouvelles fonctionnalités, un meilleur gameplay ou de nouveaux niveaux. Cependant, passer d'un fork à l'utilisation d'un moteur commun ne se fait pas en une nuit, et donc, encore une fois l'efficacité à court terme est de conserver son fork.
Qt et Gtk sont utilisés sous Windows, pas de fork. Donc en utilisant votre logique, ce n'est pas un problème de Windowsien. Merci de m'aider à la démonstration.
En terme de conclusions hâtives tu ne te fais pas prier non plus. Gtk et Qt sont développés principalement sur un environnement Linux et donc profitent de l'idéologie locale du packaging, tandis que les moteurs de jeux et xulrunner sont principalement développés sous Windows et donc souffrent du fait que les développeurs sont moins familiers avec le concept de packager les choses une fois pour toute. Il n'y a strictement rien de plus à en conclure.
Google forke pas mal de projets (y compris Linux pour Android)
Et ils sont en train de remonter plein de patches dans le noyau upstream. Le fork est très efficace en terme de ressources sur le court terme, mais très coûteux sur le long terme. Le fait de tout forker pour lancer un nouveau projet est différent du fait de maintenir tout cela sur le long terme.
De plus, sans vouloir pinailler, comparer google et ses milliers de développeurs avec des projets libres qui luttent pour en trouver quatre…
[^] # Re: Taille standardisé
Posté par nud . En réponse au journal Nano SIM maxi pollution.. Évalué à 3.
C'est un cycle court, donc ce n'est pas considéré comme polluant dans la mesure où le maïs de l'année suivante va emprisonner la même quantité de CO2. C'est le même raisonnement qui est appliqué quand on dit que les pellets de bois ne sont pas polluants par opposition au mazout (qui est un cycle très long): tu ne libères pas du nouveau carbone dans l'atmosphère.
Du reste, si ton maïs passe par une phase "plastique" à courte durée de vie, il finira de toute façon dans l'incinérateur avec les autres déchets. Mais effectivement c'est un cycle court donc c'est moins polluant que du plastique à base de pétrole.
[^] # Re: Partitions, RAID, etc.
Posté par nud . En réponse au message Manque de place sur /. Évalué à 0.
Les liens symboliques c'est à faire en dernier recours quand même, car on se trompe vite dans les droits (un -a manquant derrière le cp et c'est foutu) et ça peut causer des dysfonctionnements assez folklo à débugger. Il faut commencer par les usual suspects (voir plus bas) avant de chipoter.
[^] # Re: Partitions, RAID, etc.
Posté par nud . En réponse au message Manque de place sur /. Évalué à 0.
Inutile sur un PC de bureau de séparer /var. Ne séparez plus non plus /usr, c'est chercher des misères avec udev.
# Analyse avec du ou baobab
Posté par nud . En réponse au message Manque de place sur /. Évalué à 5.
Tu peux procéder avec du -sh /* | sort -h et aller récursivement dans les dossiers qui ont une taille suspecte (tu peux aussi utiliser baobab si tu as Gnome, et il y a sans doute un équivalent KDE)
Typiquement, ton espace disque est bouffé par:
Commence par vérifier cela avant de perdre ton temps avec baobab.
[^] # Re: tempete dans un verre d'eau
Posté par nud . En réponse au journal L'histoire d'un bide prévisible.... Évalué à 1.
Certes. Mais est-ce dans ce cas bien légal vis-à-vis de la législation européenne ?
[^] # Re: Old
Posté par nud . En réponse au journal PHP, A Fractal Of Bad Design. Évalué à 5.
Ah les joies du plein emploi…
[^] # Re: tempete dans un verre d'eau
Posté par nud . En réponse au journal L'histoire d'un bide prévisible.... Évalué à 4.
J'ai été surpris par ce nouveau connecteur et l'absence de port USB. Il me semblait en effet qu'en Europe les smartphones devaient obligatoirement être équipés d'un port micro-usb pour le chargeur, mais apparemment donner un adaptateur avec le smartphone est suffisant (ce qui est con vu que du coup on perd l'avantage du chargeur universel, sauf à se balader toujours avec l'adaptateur).
[^] # Re: Y'a pas comme un soucis ?
Posté par nud . En réponse au journal Diaspora : un space opéra open-source et multi-plateformes dans l'univers de BSG. Évalué à 2.
Après faut voir aussi les droits sur l'univers BSG, le design des appareils, tout ça.
[^] # Re: résumé
Posté par nud . En réponse au journal Linux from scratch face à udev. Évalué à 2.
make vs make install.
Compiler quelque chose n'impose pas de l'installer, par contre cela impose d'installer toutes les dépendances de compilation. C'est le problème mentionné ici: le mainteneur de lfs ne veut pas installer systemd mais la fusion lui impose d'installer les dépendances de compilation de celui-ci, qui comprennent la libdbus.
Après il pourrait probablement installer la libdbus sans installer le dbus complet, comme c'est déjà le cas sur une debian serveur par exemple.
[^] # Re: la guerre de s unices
Posté par nud . En réponse au journal udev forké. Évalué à 3.
systemd dépend de la libdbus car il propose une "activation dbus" similaire à l'activation par socket, mais utilisant un nom dbus. Si on avait un autre mode d'IPC de type bus répandu il dépendrait probablement de la lib idoine pour fournir également une activation paresseuse pour ce protocole d'IPC.
[^] # Re: résumé
Posté par nud . En réponse au journal Linux from scratch face à udev. Évalué à 1.
Tu n'as pas bien suivi.
Non, la fusion oblige juste à compiler systemd, mais udev reste fonctionnellement indépendant.
Non, On peut toujours utiliser dbus sans systemd… Le problème est ici udev, qui est compilé avec systemd, qui nécessite la libdbus.
Non, Gnome utilise juste de certaines interfaces dbus simples implémentées par systemd et qui pourraient être implémentées par d'autres démons de la même façon (genre org.freedestktop.hostname1). On ne peut pas même parler de dépendance: si tu n'as pas de démon qui implémente cette interface tu peux juste pas changer ton hostname depuis la GUI.
Non, dbus a pas besoin de systemd, c'est udev qui a été fusionné, pas dbus.
[^] # Re: Le thread dont vous éte le Mollah
Posté par nud . En réponse au journal udev forké. Évalué à 7.
Sauf que systemd est idéalement placé pour se rendre compte que le service disparaît au moment où il disparaît. Idem s'il bloque. Il reçoit le sigchld, il contrôle le socket, bref, il est où il faut pour ça.
Les services externes de monitoring (mon, monit, god et consorts) ne font que du polling, donc si tu vérifies tes services une fois toutes les 5 minutes tu cours le risque de rester avec un service down pendant 4:59 au pire des cas. Systemd peut réagir immédiatement.
J'attends la sortie de wheezy justement pour pouvoir utiliser systemd sur des serveurs, justement pour avoir cette surveillance qui fonctionne bien mieux avec systemd qu'avec mon.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par nud . En réponse au journal udev forké. Évalué à 3.
Juste car c'est le même auteur, tu peux tout à fait faire tourner ces petits programmes triviaux sans systemd, certaines distro le font. Ça utilise probablement un .so commun mais ça marche aussi avec sysvinit.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par nud . En réponse au journal udev forké. Évalué à 10.
Ce point a déjà été discuté précédemment. Gnome ne dépend pas de systemd, mais il dépend d'interfaces D-Bus diverses (genre org.freedesktop.hostname1) spécifiées au sein de freedesktop.org, et qui sont pour l'instant uniquement implémentées par des petits utilitaires fournis par systemd. Ces interfaces sont triviales (vraiment) et peuvent être implémentées facilement par un autre outil.
Il s'agit juste de déplacer la maintenance des outils spécifiques aux distros au sein des distros au lieu de les garder au niveau de l'upstream, car de toute façon les outils upstream (system-tools-backend) ne supportaient que redhat, debian et opensuse.
[^] # Re: AppleFr
Posté par nud . En réponse au journal Self serving. Évalué à 4.
Note que la distinction PC vs Mac n'a plus vraiment de sens, de nos jours c'est plutôt PC livré avec Windows vs PC de marque Apple livré avec MacOSX.
[^] # Re: Excusez-moi
Posté par nud . En réponse au journal Un flim de les Nuls ce soir (pour ceux qui le veulent bien). Évalué à 3.
Non je suis le pape et j'attends ma sœur.
[^] # Re: Toc toc…
Posté par nud . En réponse au journal Un flim de les Nuls ce soir (pour ceux qui le veulent bien). Évalué à 6.
Non, c'est à côté
[^] # Re: US vs !US
Posté par nud . En réponse au journal Apple vs Samsung: le verdict. Évalué à 2. Dernière modification le 25 août 2012 à 18:04.
Par contre Samsung risque d'empocher des indemnités de rupture pas piquées des vers.
[^] # Re: Merci Gnome
Posté par nud . En réponse à la dépêche GUADEC 2012, en route vers GNOME 4.0 et GNOME OS. Évalué à 2.
Et encore, tout le monde n'était pas là.
[^] # Re: C'est nul
Posté par nud . En réponse au journal Un nouveau logo pour Microsoft. Évalué à 4.
Il ne me demande pas de l'accepter, je sais afficher l'image. Et ça marche sur les autres pages. Vous voyez l'image sur la page des journaux vous?
# C'est nul
Posté par nud . En réponse au journal Un nouveau logo pour Microsoft. Évalué à 6.
Bon en fait c'est nul, le logo n'apparaît pas sur la page d'accueil, juste le texte.
[^] # Re: à propos de XulRunner
Posté par nud . En réponse au journal Une histoire de fork. Évalué à 0. Dernière modification le 22 août 2012 à 11:31.
Elles sont toutes innovantes ?
La liste n'est peut-être pas exhaustive mais elle n'est pas non plus limitée à XUL, une bonne dose des applications citées utilisent juste NSS, SpiderMonkey ou Rhino…
[^] # Re: à propos de XulRunner
Posté par nud . En réponse au journal Une histoire de fork. Évalué à 3.
Et pourquoi le ferait-il? En quoi utiliser une version forkée de xulrunner change-t-il quelque chose à cela? Ou bien le problème est-il pour l'éditeur de logiciel d'attendre que Mozilla ne release une nouvelle version de xulrunner ? Côté éditeur, on peut soit packager une nouvelle version de xulrunner soi-même, soit compiler son paquet statiquement. On fait des trucs similaires dans ma boite. Si au contraire c'est Debian qui veut la nouvelle version de Thunderbird, elle se débrouillera pour fournir un package du dernier xulrunner.
Comme Qt, qui fournit QtQuick, Webkit, un client HTTP, un environnement de scripting javascript et plein d'autres trucs. Qt n'est pas une lib classique, c'est une plateforme, un framework embarquable. Est-ce pour autant que tout le monde forke et patche ? Non. Il s'agit juste de faire en sorte que la plateforme fournisse tout ce qui est nécessaire, et d'ajouter ce qui manque pour avoir une plateforme satisfaisante pour tous les usages, et réduire d'autant les coûts de maintenance des différentes applications.
Si ce n'est pas possible, c'est que xulrunner n'était pas le bon framework pour développer l'application. Si c'est suite à un manque de volonté de la part de Mozilla, tout pareil.
Je sais que Mozilla assume pleinement le fait que xulrunner est avant tout la plateforme de Firefox et refuse d'implémenter des choses qui ne sont pas dans l'intérêt immédiat de Firefox. Il n'y a pas de problème intrinsèque avec cela, il faut juste alors arrêter de promouvoir xulrunner comme une plateforme de développement généraliste.
Pourquoi cela n'arrive-t-il pas avec les éditeurs basés sur webkit ? Peut-être est-ce un problème de design ou de modularité du moteur gecko, ou de refus d'ajouter des fonctionnalités qui ne sont pas directement nécessaires à Firefox (bien que avec les nouveaux webdev tools…) ? D'un autre côté, j'imagine mal un truc comme sunbird ou thunderbird nécessiter une modification du moteur de rendu. Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.
Non, c'est un raccourci malsain, car comme dit plus haut, le fait de pouvoir le faire n'implique pas qu'on ne peut pas faire autrement. On peut distribuer une appli compilée statiquement, et de toute façon le problème est le même pour les dépendances déjà présentes dans la distro (cairo, gtk+, libx* et toutes les autres). Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.
[^] # Re: à propos de XulRunner
Posté par nud . En réponse au journal Une histoire de fork. Évalué à 7.
Ben, en fait, oui. On travaille avec deux projets libres, l'un en GPL et l'autre sous copyright attribution double licence. Dans l'un des cas on remonte les patches, dans l'autre pas (la politique, tout ça, je passe les détails). On est une très petite boite.
Donc oui, dans les faits ça me coûte moins cher en temps de remonter les patches une fois que de maintenir ma pile de patches et de les mettre à jour à chaque nouvelle version mineure du projet. Dans le premier cas il m'a fallu quelques jours pour faire accepter le patch, dans l'autre il me faut chaque fois une journée, au mieux, pour adapter les patches. Après genre cinq versions, la première façon de faire est clairement gagnante en terme de temps dépensé.
Quant à l'intérêt, encore une fois c'est l'intérêt immédiat comparé à un intérêt à plus long terme. Au moment de commencer le jeu il est bien plus facile de forker. Après un an ou deux de galère et de patches divers je me demande si certains ne préféreraient pas avoir moins de code à maintenir et utiliser un moteur commun. Moins de code à maintenir, c'est aussi plus de temps à investir dans d'autres aspects du développement, comme de nouvelles fonctionnalités, un meilleur gameplay ou de nouveaux niveaux. Cependant, passer d'un fork à l'utilisation d'un moteur commun ne se fait pas en une nuit, et donc, encore une fois l'efficacité à court terme est de conserver son fork.
[^] # Re: à propos de XulRunner
Posté par nud . En réponse au journal Une histoire de fork. Évalué à 9.
En terme de conclusions hâtives tu ne te fais pas prier non plus. Gtk et Qt sont développés principalement sur un environnement Linux et donc profitent de l'idéologie locale du packaging, tandis que les moteurs de jeux et xulrunner sont principalement développés sous Windows et donc souffrent du fait que les développeurs sont moins familiers avec le concept de packager les choses une fois pour toute. Il n'y a strictement rien de plus à en conclure.
Et ils sont en train de remonter plein de patches dans le noyau upstream. Le fork est très efficace en terme de ressources sur le court terme, mais très coûteux sur le long terme. Le fait de tout forker pour lancer un nouveau projet est différent du fait de maintenir tout cela sur le long terme.
De plus, sans vouloir pinailler, comparer google et ses milliers de développeurs avec des projets libres qui luttent pour en trouver quatre…