contacter le responsable du dépôt principal pour lui suggérer de faire un git pull
Si le responsable du dépot est inconcient ou te fait hyper confiance, pourquoi pas.
Mais un responsable vraiment responsable, va
d'abord cloner ton dépot
faire une review et commenter
faire ensuite le pull
Au mieux, pour le responsable, ça lui fait faire donc 3 manips. Au pire Nx2+1 manips quand il demande N fois de corriger des choses. Et encore, la review peut être pénible quand on veut un diff globale entre deux branches (car là il faut créer un remote qui pointe vers le dépôt contributeur, puller la branche en question dans une branche spécifique etc… ça en fait des manip…)
Alors qu'avec github, il n'en a au pire que N+1 :
faire une review et commenter
cliquer sur un bouton
Sans pour autant que toi, en tant que contributeur, cela te demande plus de manipulation. Au contraire : tu n'as pas à chercher par quel moyen de communication tu dois lui envoyer un patch.
Franchement, je préfère largement que les contributeurs passent par github, plutôt que de m'envoyer des patchs par mail ou me donner l'url de leur dépôt. Quand j'ai régulièrement des contributions, je gagne du temps à faire les reviews et les merge.
À moins qu'il y ait des fonctionnalités dans git que je ne soupçonne pas, qui permettrait de faire les reviews et les merges de dépots distants en une seule commande…
J'espère que Mozilla va mettre à jour http://arewefastyet.com/ en incluant ChakraCore, ça pourrait être intéressant de comparer ses performances avec les autres :-) (où l'on voit d'ailleurs que V8 et SpiderMonkey sont équivalent en terme de perf, sauf sur le test sunspider où SpiderMonkey est meilleur)
Parce que la fondation Mozilla n'est pas une entreprise
Non, mais Mozilla Corp (detenu à 100% par la fondation), est une entreprise, donc avec les logiques classiques d'une entreprise : ne pas perdre d'argent. D'ailleurs, c'est aussi le but d'une association et d'une fondation : ne pas perdre d'argent. C'est toujours compliqué de faire des choses quand tu n'as pas d'argent. Pour la gestion de ta famille, de ton logement ou autre, tu n'as pas à etre rentable non plus. Pourtant tu cherches à avoir des bénéfices, c'est à dire de pas être dans le rouge sur ton compte en banque. Parce que sinon ça deviendra de plus en plus compliqué de faire vivre ta famille, de payer ton loyer ou tes traites etc…
Bref, une fondation, une entreprise c'est pareil. Ne pas être dans le rouge pour continuer à exister. Et donc stopper les trucs qui coûtent et qui ne servent plus à rien ou qui ne "fonctionne" plus.
Maintenant, le code du service est en open-source. Libre à ceux qui râlent (ou qui veulent tout simplement aider au "web libre et indépendant") de proposer le même service.
Oh que oui, entièrement d'accord avec toi ! Surtout après le "boulot", jusqu'au coucher du soleil _. La meilleure terrasse de Papeete à vrai dire :-) Et puis bon, là au moins la bière n'a pas fait 22000 km, sortie quasi direct du fût, fraîche de chez fraîche :-)
Pareil, j'aime bien cette bière :-) Fermentée à Tahiti, c'est la boisson ambassadrice de la Polynésie (à boire avec modération bien sûr), à telle point que son logo (la vahinée) est devenu un peu le logo de la polynésie (et le signe de reconnaissance en métropole, collé à l'arrière des voitures, de ceux qui ont vécu là bas…).
Par contre, en métropole, on trouve cette bière surtout en canette, et je trouve qu'elle est un peu moins bonne qu'en bouteille. Peut-être que l'aluminium donne un goût…
Pour info, chez moi, Firefox 38.5 considère déjà le premier certificat intermédiaire de Comodo, USERTrust RSA Certification Authority, comme une racine, donc la chaîne s’arrête à ce certificat.
Pareil chez moi sur la version 43. Il n'affiche pas de "parent" pour USERTrust RSA. Idem sur Chromium 47.
la non divulgation des codes sources ne rassurent pas pour autant, on reste soumis à l'utilisation forcée d'une boîte noire.
Bof. Ça peut être intéressant effectivement qu'on est le code source. Mais je doute que ERDF permettrait de remplacer le firmware.
Conclusion : le boitier resterait une boite noire, et rien ne garantirait que le code source disponible correspondrait à ce qui est réellement implanté dans la boiboite. De mon point de vue, avoir accès au code source ne me rassurerait pas plus que pas de code source.
C'est la même problématique que pour les ordinateurs de vote, les freebox etc…
Un téléphone est bourré de composants qui ont presque tous des firmwares qu'on ne peut pas déloger, en particulier celui du modem.
Que tu ais des drivers libres ou pas, ça ne change rien au final : tu l'as dans l'os en terme de vie privée, puisqu'on ne peut pas l'éradiquer 100%. Autant donc dépenser son énergie sur les couches supérieures, ce qui intéressait au final le plus Mozilla puisque je te rappelle que l'objectif premier de FirefoxOS est de fournir un environnement graphique pour téléphone 100% techno web (et faire ce qui est possible de faire en terme de vie privée, c'est à dire au niveau des applis).
Le rêve d'un téléphone 100% libre est juste une utopie, ne t'en déplaise.
Google a peut être écrit la spec de Shadow DOM, mais ce n'est aucunement une invention de Google. Ça existe depuis 15 ans dans Gecko, inventé par David Hyatt alors qu'il était chez Netscape, et créé pour implémenter XBL, aka, l'ancêtre des Web Components (qui est un ensemble de specs toutes tirés de la spec XBL2, une évolution de XBL).
Bref, l'éditeur d'une spec au W3C n'est pas forcément l'inventeur de la techno décrite.
J'ai oublié de parler aussi de leur nouveau programme d'aide aux projets qu'ils utilisent : Mozilla va verser en tout 1 millions de dollars à divers projets (je ne sais pas encore si les sommes versées à Django, Mercurial et ReadTheDocs se sont fait dans le cadre de ce programme…).
Imagine ce qu'il serait possible de faire avec tout ce fric. Le dev de Gimp qui stagne depuis des années parce que les codeurs tirent le diable par la queue et n'ont pas le temps de bosser à temps plein dessus.
Mozilla ne peut pas subventionner tous les projets libres ! Elle en subventionne déjà pas mal, et régulièrement. Derniers en date : 150000$ à Django pour apporter le support des websocket, 75000$ à Mercurial, 48000$ à ReadTheDocs.. Et ce ne sont que des exemples.
Et que dire des acheteurs de TV Panasonic telle que les CR850E vendue plus de 2300€…
Pourquoi ? Leur télé va s’arrêter de fonctionner ? Au niveau des évolutions, des mises à jour, tu crois que ça va changer grand chose par rapport à d'autres "télés connectés" ? La mienne (une thomson sous un OS non identifié), n'a plus de mise à jour depuis 2-3 ans (et je ne parle pas des "applis internet" qui n'existent plus) : elle fonctionne toujours, je continue à regarder la TNT, mes DVD/BR etc…
Et puis ça tombe bien, une TV, ce n'est pas un smartphone, et Mozilla indique qu'ils continuent de développer Firefox OS pour les "objets connectés". Donc bon…
Par contre qu'ils abandonnent les partenariats pour les smartphones, ça veut dire plus d'évolutions pour les applis téléphoniques et l'appli "bureau" de Firefox OS (faut pas se leurrer, ils vont doucement mais sûrement les abandonner), et ça me fait vraiment, vraiment ch**r. Quand le matos de mes téléphones Firefox OS lâchera, je me vois mal reprendre un de ces téléphones de merdes sous android à 800 boules, bourrés d'appli éspionnes inutiles, lentes et qu'on peut pas enlever.
On prendra ces chiffres avec des pincettes du fait de leur description imprécise et de leur origine (Zend),
Pas besoin de pincettes. Les améliorations ont été largement confirmées par d'autres sociétés sur des vrais infrastructures. J'ai eu des retours sur des boites qui ont fait des tests et qui vont diminuer de manière significative le nombre de leur serveurs PHP grâce à PHP7.
PHP 7 devait aussi apporter une compilation à la volée, nous en parlions en ces termes dans la dépêche annonçant la sortie de PHP 5.6 (..) Malheureusement, cette nouvelle évolution se fait attendre.
Dans l'une des conférences au Forum PHP de cette année, celle de Zeev Suraski si je ne me trompe pas (l'un des créateurs du zend engine), il expliquait qu'ils s'étaient lancés dans le JIT. Mais les benchs avaient montrés que les améliorations sur les perfs n'étaient pas au rendez-vous, en tout cas, pas dans des cas normaux, c'est à dire sur des vrais sites web. Donc ils ont abandonnés l'idée. Donc à mon avis, on va longtemps attendre cette évolution qui n'apporte à priori peu d'avantage avec l'architecture actuelle du zend engine.
Ils ont par contre découvert qu'ils pouvaient faire beaucoup d'amélioration coté occupation mémoire, avec des bénéfices coté perf (moins de mémoire occupée, ça fait moins de travail pour la gestion de la mémoire entre autre). Et les résultats sont là.
Une batterie au lithium(ressource rare) d'Amérique du sud qu'on doit changer souvent
Et qu'il faut recycler correctement, sous peine de pollution environnementale et donc d'atteinte à la santé. Et ça doit être "chouette" les accidents de voitures électriques, quand les batteries sont éventrées…
C'est comme les ampoules basses consommation : on nous bassine que c'est écologique parce que ça consomme moins. Alors que le coût écologique de la fabrication de ces ampoules est sans commune mesure avec celle des ampoules incandescentes. Idem pour le coût écologique de la fin de vie.
En effet une ampoule basse consommation est bourrée de composants électroniques, de mercure et autres cochonneries alors qu'une ampoule classique ce n'est qu'une simple ampoule de verre + fil de tungstene + culot en ferraille. L'énergie utilisée pour fabriquer ces ampoules "écologiques" doit certainement être bien supérieure à celle que l'on aura "économisé" durant son utilisation (quand elles ne claquent pas prématurément, alors qu'on nous promet des durées de vie plus longues) : le nombre de matières premières à extraire, à produire, à acheminer et à transformer est bien plus élevé que celui des ampoules classiques. (extraction = destruction de la nature, acheminement/production/transformation = co2 + pollution + energie consommée)
Ensuite je doute que la majorité des ampoules soient recyclées correctement et donc elles finissent dans la nature ou les décharges, ou encore à l’incinérateur dont on respire les émanations tôt ou tard malgré les soi-disant supers filtres. je ne suis pas un spécialiste, mais j'ai comme l'intuition que sur le long terme, tout ceci ne doit pas être super bon pour l'environnement et la santé, malgré les quantités minimes dans les ampoules.
Et je ne parle pas de l'efficacité toute relative à l'usage…
Bref, de mon point de vue, les ampoules basse consommation sont la plus grosse arnaque des industriels et politiques en ce début de siècle Un désastre écologique à court terme (fabrication) et à long terme (pollution en fin de vie).
tu ne dois pas beaucoup surfer sur le web pour dire ça…
Que ce soit avec uBlock, ghostery ou autre, fatalement, ça casse certains sites pour lesquels les devs n'ont pas vérifié le bon fonctionnement avec les bloqueurs. Et généralement le site est cassé parce qu'ils ont du code qui est dépendant d'un tracker bloqué et qui du coup provoque une erreur JS : le reste du code n'est pas executé. Site cassé.
Les greffons concernés par cette suppression de prise en charge, sont les plugins de type NPAPI, qui sont activables via une balise object dans les pages web, donc qui "s'incrustent" dans la page, à la demande de l'auteur de la page web.
Le greffon H264 c'est un autre type de plugin, un codec, qui étend l'implémentation de webrtc (complétement transparent du point de vue du développeur web, il ne peut agir dessus)
Petite précision. il manque un mot dans ton sujet.
Spoiler : PHP *est* un *mauvais* moteur de template.
trop grande liberté, permettant de faire tout et n'importe quoi dans la "vue" (y compris du code métier qui devrait, dans un projet propre, se trouver dans des belles classes dédiées)
pas de sécurité par défaut : il faut faire attention à échapper soit-même le contenu que l'on affiche pour éviter d'injecter du code XSS &co.
moins lisible quand le template est complexe.
Et plein d'autres arguments que tu trouveras sur le web..
Officiellement oui, Servo n'est qu'un truc expérimental. Et de toute façon, il n'est pas encore prêt.
Mais.
Vu l'état d'avancement, on peut dire qu'il a dépassé le stade de prototype. Le moteur en lui même fonctionne. Au niveau architecture, je pense que ça se stabilise. Il y a encore certainement du travail à faire au niveau optimisation. Mais ce qu'il reste surtout à faire (si j'ai bien suivi) c'est implémenter des API, des propriétés CSS, HTML et j'en passe pour avoir un moteur de rendu qui soit utilisable.
Il est donc probable que d'ici un an on ait une première version que l'on peut tester en réél (dans un navigateur à l'interface minimaliste).
Cependant un navigateur, ce n'est pas qu'un moteur de rendu : gestion des bookmarks, des mots de passe, des préférences, de l'impression, des addons, en plus d'outils de dev web, du mode private, du mode offline, et plein d'autres choses etc… Donc une fois Servo terminé, il restera du boulot.
Pour Mozilla donc, la question se pose déjà. Est ce que Firefox un jour switchera vers Servo ? pour l'instant très difficile à dire, et si j'en crois les mailing-list, Mozilla ne le sait pas lui-même. Une chose est sûre, ils veulent se débarrasser de XUL, XBL, XPCOM et autres trucs (qui ne seront pas implémentés dans Servo, c'est certain). Pour ça il faut se débarrasser du système d'extension XUL (c'est en cours), il faut migrer l'interface XUL vers du HTML ou du natif (et redevelopper plein de composants interne qui sont en XPCOM). La migration de l'interface est en discussion. Certains proposent plutôt de laisser continuer Firefox comme cela, tout en le faisant évoluer de manière à ce que la transition vers un "Firefox nouvelle génération" soit douce (en clair, il faut que les extensions soient prêtes, d'où les webextensions qui arrivent dans Firefox, qui proposeront une API qui s'abstrait totalement de l'API interne du navigateur, donc de Gecko). D'autres proposent de faire le ménage au fur et à mesure et redévelopper ce qu'il y a à redevelopper pour que ce soit compatible Gecko & Servo (cela veut donc dire migrer petit à petit des bouts d'interfaces de XUL vers HTML, de redévelopper des composants XPCOM en module javascript quand c'est pertinent etc..).
Une chose est sûre : cela va prendre beaucoup de temps, quelque soit la solution.
Maintenant il n'y a pas que Firefox Desktop. Il y a aussi Firefox pour Android, et Firefox OS. Ces deux produits n'utilisent pas XUL et autres trucs "deprecated" (l'interface pour FxAndroid utilise la techno d'android, et pour FxOS, tout est en HTML). Il est donc fort possible que ces deux logiciels remplaceront Gecko par Servo quand ce dernier sera suffisamment mature. Même si ça ne se fera pas en 5 minutes, il y a à priori moins de boulot à l'heure actuelle que pour Firefox Desktop (d'ailleurs on remarquera le port de Servo vers Gonk, le système linux de FirefoxOS : c'est une première étape franchie ;-) ).
Comme autre produit phare, reste Thunderbird. Là tout est en XUL, avec beaucoup de composants XPCOM en C++ (implémentation des protocoles de messageries…). Forcément, l'avenir de Thunderbird est lié à l'avenir de Gecko. Les devs de Thunderbird étudient donc la possibilité de refaire un Thunderbird tout en HTML pour l'interface, et même de redévelopper les différents protocoles en JS. (Qui c'est, verra-t-on Thunderbird sur FirefoxOS ? ;-)
En conclusion : Servo est encore expérimental (dans les faits et officiellement), mais je pense que ça deviendra à terme une vrai brique utilisable en "production". Même si Mozilla décide un jour d'abandonner Servo (ce dont je doute), vu le nombre grandissant de contributeurs externes, c'est un truc qui finira en prod de toute façon. Chez Samsung ou ailleurs.
Pareil, ce qui m’intéressait dans la hp48, c'est qu'on arrivait assez vite aux limites de la machine avec le RPL. Avec l'assembleur, on pouvait alors repousser les limites, et ça nous forçait à nous triturer les méninges pour imaginer de meilleurs algorithmes, pour optimiser la mémoire, pour optimiser les temps de calculs etc…
J'ai beaucoup appris sur la gestion de la mémoire, sur l'optimisation du cpu, sur ce qui étais préférable de faire pour avoir de bonne perf pour faire telle ou telle chose. Je me rendais alors mieux compte des "betises" que je faisais avec des langages plus haut niveau comme le C sur d'autres machines.
[^] # Re: Contribuer au projet sans GitHub
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le retour de la Méthode R.A.C.H.E. Évalué à 0.
Tu oublies l'outil de review, avec possibilité de commenter chaque ligne de code etc… Ce que tu ne peux faire facilement par mail…
[^] # Re: Contribuer au projet sans GitHub
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le retour de la Méthode R.A.C.H.E. Évalué à 2.
Si le responsable du dépot est inconcient ou te fait hyper confiance, pourquoi pas.
Mais un responsable vraiment responsable, va
Au mieux, pour le responsable, ça lui fait faire donc 3 manips. Au pire Nx2+1 manips quand il demande N fois de corriger des choses. Et encore, la review peut être pénible quand on veut un diff globale entre deux branches (car là il faut créer un remote qui pointe vers le dépôt contributeur, puller la branche en question dans une branche spécifique etc… ça en fait des manip…)
Alors qu'avec github, il n'en a au pire que N+1 :
Sans pour autant que toi, en tant que contributeur, cela te demande plus de manipulation. Au contraire : tu n'as pas à chercher par quel moyen de communication tu dois lui envoyer un patch.
Franchement, je préfère largement que les contributeurs passent par github, plutôt que de m'envoyer des patchs par mail ou me donner l'url de leur dépôt. Quand j'ai régulièrement des contributions, je gagne du temps à faire les reviews et les merge.
À moins qu'il y ait des fonctionnalités dans git que je ne soupçonne pas, qui permettrait de faire les reviews et les merges de dépots distants en une seule commande…
# concurrence
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal le moteur JavaScript de Microsoft Edge sous licence MIT. Évalué à 5.
Non, un concurrent à V8 (utilisé dans Chrome, Safari) et à SpiderMonkey (utilisé dans Firefox).
Notons au passage que ChakraCore embarque du code de SpiderMonkey, en particulier des bouts de l'implémentation de AsmJS (voir le copyright dans certains fichiers AsmJS*](https://github.com/Microsoft/ChakraCore/tree/WebAssembly/lib/Runtime/Language) ).
J'espère que Mozilla va mettre à jour http://arewefastyet.com/ en incluant ChakraCore, ça pourrait être intéressant de comparer ses performances avec les autres :-) (où l'on voit d'ailleurs que V8 et SpiderMonkey sont équivalent en terme de perf, sauf sur le test sunspider où SpiderMonkey est meilleur)
[^] # Re: Pff
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Persona, c'est bientôt la fin.. Évalué à 0.
Non, mais Mozilla Corp (detenu à 100% par la fondation), est une entreprise, donc avec les logiques classiques d'une entreprise : ne pas perdre d'argent. D'ailleurs, c'est aussi le but d'une association et d'une fondation : ne pas perdre d'argent. C'est toujours compliqué de faire des choses quand tu n'as pas d'argent. Pour la gestion de ta famille, de ton logement ou autre, tu n'as pas à etre rentable non plus. Pourtant tu cherches à avoir des bénéfices, c'est à dire de pas être dans le rouge sur ton compte en banque. Parce que sinon ça deviendra de plus en plus compliqué de faire vivre ta famille, de payer ton loyer ou tes traites etc…
Bref, une fondation, une entreprise c'est pareil. Ne pas être dans le rouge pour continuer à exister. Et donc stopper les trucs qui coûtent et qui ne servent plus à rien ou qui ne "fonctionne" plus.
Maintenant, le code du service est en open-source. Libre à ceux qui râlent (ou qui veulent tout simplement aider au "web libre et indépendant") de proposer le même service.
[^] # Re: Champ de recherche
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Parution de Firefox 43. Évalué à 2.
Qu'est ce que tu entends par "maintenir XUL" ? Ce n'est qu'un langage XML (extensible en plus), et il y a longtemps qu'il n'a plus évolué.
[^] # Re: Hinano
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche e-venement v2.9 "Hinano Beer". Évalué à 2. Dernière modification le 22 décembre 2015 à 21:24.
Oh que oui, entièrement d'accord avec toi ! Surtout après le "boulot", jusqu'au coucher du soleil _. La meilleure terrasse de Papeete à vrai dire :-) Et puis bon, là au moins la bière n'a pas fait 22000 km, sortie quasi direct du fût, fraîche de chez fraîche :-)
Manuia !
[^] # Re: Hinano
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche e-venement v2.9 "Hinano Beer". Évalué à 2.
Pareil, j'aime bien cette bière :-) Fermentée à Tahiti, c'est la boisson ambassadrice de la Polynésie (à boire avec modération bien sûr), à telle point que son logo (la vahinée) est devenu un peu le logo de la polynésie (et le signe de reconnaissance en métropole, collé à l'arrière des voitures, de ceux qui ont vécu là bas…).
Par contre, en métropole, on trouve cette bière surtout en canette, et je trouve qu'elle est un peu moins bonne qu'en bouteille. Peut-être que l'aluminium donne un goût…
[^] # Re: Changement de racine chez Comodo
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Paranoïa, certificat SSL et tracasseries.. Évalué à 4.
Pareil chez moi sur la version 43. Il n'affiche pas de "parent" pour USERTrust RSA. Idem sur Chromium 47.
# Code source
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Compteur communicant. Évalué à 4.
Bof. Ça peut être intéressant effectivement qu'on est le code source. Mais je doute que ERDF permettrait de remplacer le firmware.
Conclusion : le boitier resterait une boite noire, et rien ne garantirait que le code source disponible correspondrait à ce qui est réellement implanté dans la boiboite. De mon point de vue, avoir accès au code source ne me rassurerait pas plus que pas de code source.
C'est la même problématique que pour les ordinateurs de vote, les freebox etc…
[^] # Re: Téléphones peu attractifs…
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Firefox OS. Évalué à 0.
Oui, normal, on ne peut pas vraiment faire mieux. La preuve : https://www.replicant.us/freedom-privacy-security-issues.php
Un téléphone est bourré de composants qui ont presque tous des firmwares qu'on ne peut pas déloger, en particulier celui du modem.
Que tu ais des drivers libres ou pas, ça ne change rien au final : tu l'as dans l'os en terme de vie privée, puisqu'on ne peut pas l'éradiquer 100%. Autant donc dépenser son énergie sur les couches supérieures, ce qui intéressait au final le plus Mozilla puisque je te rappelle que l'objectif premier de FirefoxOS est de fournir un environnement graphique pour téléphone 100% techno web (et faire ce qui est possible de faire en terme de vie privée, c'est à dire au niveau des applis).
Le rêve d'un téléphone 100% libre est juste une utopie, ne t'en déplaise.
[^] # Re: c'est la période des sapins...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox OS est bronsonisé. Évalué à 3.
Google a peut être écrit la spec de Shadow DOM, mais ce n'est aucunement une invention de Google. Ça existe depuis 15 ans dans Gecko, inventé par David Hyatt alors qu'il était chez Netscape, et créé pour implémenter XBL, aka, l'ancêtre des Web Components (qui est un ensemble de specs toutes tirés de la spec XBL2, une évolution de XBL).
Bref, l'éditeur d'une spec au W3C n'est pas forcément l'inventeur de la techno décrite.
[^] # Re: Budget
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Firefox OS. Évalué à 3.
je viens d'avoir la confirmation : les dons aux projets que j'ai indiqué sont bien dans le cadre de MOSS.
[^] # Re: Budget
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Firefox OS. Évalué à 4.
J'ai oublié de parler aussi de leur nouveau programme d'aide aux projets qu'ils utilisent : Mozilla va verser en tout 1 millions de dollars à divers projets (je ne sais pas encore si les sommes versées à Django, Mercurial et ReadTheDocs se sont fait dans le cadre de ce programme…).
[^] # Re: Budget
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Firefox OS. Évalué à 2.
Mozilla ne peut pas subventionner tous les projets libres ! Elle en subventionne déjà pas mal, et régulièrement. Derniers en date : 150000$ à Django pour apporter le support des websocket, 75000$ à Mercurial, 48000$ à ReadTheDocs.. Et ce ne sont que des exemples.
[^] # Re: Dommage
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox OS est bronsonisé. Évalué à 3.
Pourquoi ? Leur télé va s’arrêter de fonctionner ? Au niveau des évolutions, des mises à jour, tu crois que ça va changer grand chose par rapport à d'autres "télés connectés" ? La mienne (une thomson sous un OS non identifié), n'a plus de mise à jour depuis 2-3 ans (et je ne parle pas des "applis internet" qui n'existent plus) : elle fonctionne toujours, je continue à regarder la TNT, mes DVD/BR etc…
Et puis ça tombe bien, une TV, ce n'est pas un smartphone, et Mozilla indique qu'ils continuent de développer Firefox OS pour les "objets connectés". Donc bon…
Par contre qu'ils abandonnent les partenariats pour les smartphones, ça veut dire plus d'évolutions pour les applis téléphoniques et l'appli "bureau" de Firefox OS (faut pas se leurrer, ils vont doucement mais sûrement les abandonner), et ça me fait vraiment, vraiment ch**r. Quand le matos de mes téléphones Firefox OS lâchera, je me vois mal reprendre un de ces téléphones de merdes sous android à 800 boules, bourrés d'appli éspionnes inutiles, lentes et qu'on peut pas enlever.
# Quelques précisions sur les perfs
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 10.
Pas besoin de pincettes. Les améliorations ont été largement confirmées par d'autres sociétés sur des vrais infrastructures. J'ai eu des retours sur des boites qui ont fait des tests et qui vont diminuer de manière significative le nombre de leur serveurs PHP grâce à PHP7.
Dans l'une des conférences au Forum PHP de cette année, celle de Zeev Suraski si je ne me trompe pas (l'un des créateurs du zend engine), il expliquait qu'ils s'étaient lancés dans le JIT. Mais les benchs avaient montrés que les améliorations sur les perfs n'étaient pas au rendez-vous, en tout cas, pas dans des cas normaux, c'est à dire sur des vrais sites web. Donc ils ont abandonnés l'idée. Donc à mon avis, on va longtemps attendre cette évolution qui n'apporte à priori peu d'avantage avec l'architecture actuelle du zend engine.
Ils ont par contre découvert qu'ils pouvaient faire beaucoup d'amélioration coté occupation mémoire, avec des bénéfices coté perf (moins de mémoire occupée, ça fait moins de travail pour la gestion de la mémoire entre autre). Et les résultats sont là.
[^] # Re: Et zut !!
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Jolla va mal. Évalué à 5.
Pour une liste de matériel compatible voir le nouveau site communautaire de FirefoxOS ;-)
[^] # Re: Sur le CO2, un ordre de grandeur
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [HS] Faites chauffer la planète, notre moteur a froid.. Évalué à 10.
Et qu'il faut recycler correctement, sous peine de pollution environnementale et donc d'atteinte à la santé. Et ça doit être "chouette" les accidents de voitures électriques, quand les batteries sont éventrées…
C'est comme les ampoules basses consommation : on nous bassine que c'est écologique parce que ça consomme moins. Alors que le coût écologique de la fabrication de ces ampoules est sans commune mesure avec celle des ampoules incandescentes. Idem pour le coût écologique de la fin de vie.
En effet une ampoule basse consommation est bourrée de composants électroniques, de mercure et autres cochonneries alors qu'une ampoule classique ce n'est qu'une simple ampoule de verre + fil de tungstene + culot en ferraille. L'énergie utilisée pour fabriquer ces ampoules "écologiques" doit certainement être bien supérieure à celle que l'on aura "économisé" durant son utilisation (quand elles ne claquent pas prématurément, alors qu'on nous promet des durées de vie plus longues) : le nombre de matières premières à extraire, à produire, à acheminer et à transformer est bien plus élevé que celui des ampoules classiques. (extraction = destruction de la nature, acheminement/production/transformation = co2 + pollution + energie consommée)
Ensuite je doute que la majorité des ampoules soient recyclées correctement et donc elles finissent dans la nature ou les décharges, ou encore à l’incinérateur dont on respire les émanations tôt ou tard malgré les soi-disant supers filtres. je ne suis pas un spécialiste, mais j'ai comme l'intuition que sur le long terme, tout ceci ne doit pas être super bon pour l'environnement et la santé, malgré les quantités minimes dans les ampoules.
Et je ne parle pas de l'efficacité toute relative à l'usage…
Bref, de mon point de vue, les ampoules basse consommation sont la plus grosse arnaque des industriels et politiques en ce début de siècle Un désastre écologique à court terme (fabrication) et à long terme (pollution en fin de vie).
[^] # Re: tracking protection et mode normal
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox ? 42 !. Évalué à 3. Dernière modification le 12 novembre 2015 à 09:45.
tu ne dois pas beaucoup surfer sur le web pour dire ça…
Que ce soit avec uBlock, ghostery ou autre, fatalement, ça casse certains sites pour lesquels les devs n'ont pas vérifié le bon fonctionnement avec les bloqueurs. Et généralement le site est cassé parce qu'ils ont du code qui est dépendant d'un tracker bloqué et qui du coup provoque une erreur JS : le reste du code n'est pas executé. Site cassé.
[^] # Re: disparition des greffons
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox ? 42 !. Évalué à 3.
Ce n'est pas un plugin comme flash.
Les greffons concernés par cette suppression de prise en charge, sont les plugins de type NPAPI, qui sont activables via une balise object dans les pages web, donc qui "s'incrustent" dans la page, à la demande de l'auteur de la page web.
Le greffon H264 c'est un autre type de plugin, un codec, qui étend l'implémentation de webrtc (complétement transparent du point de vue du développeur web, il ne peut agir dessus)
[^] # Re: Spoiler : PHP *est* un moteur de template.
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Rendez-vous Les moteurs de Template en PHP le 6 octobre 2015 à Paris. Évalué à 1.
dit-il avec une syntaxe totalement obsolète…
Petite précision. il manque un mot dans ton sujet.
Et plein d'autres arguments que tu trouveras sur le web..
[^] # Re: Fin 2015.
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 6.
Si si, il y a bien le moteur JS de Gecko dans Servo. Sinon github, pour ne pas le citer, ne fonctionnerai pas du tout dans Servo.
[^] # Re: Fin 2015.
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 10.
Officiellement oui, Servo n'est qu'un truc expérimental. Et de toute façon, il n'est pas encore prêt.
Mais.
Vu l'état d'avancement, on peut dire qu'il a dépassé le stade de prototype. Le moteur en lui même fonctionne. Au niveau architecture, je pense que ça se stabilise. Il y a encore certainement du travail à faire au niveau optimisation. Mais ce qu'il reste surtout à faire (si j'ai bien suivi) c'est implémenter des API, des propriétés CSS, HTML et j'en passe pour avoir un moteur de rendu qui soit utilisable.
Il est donc probable que d'ici un an on ait une première version que l'on peut tester en réél (dans un navigateur à l'interface minimaliste).
Cependant un navigateur, ce n'est pas qu'un moteur de rendu : gestion des bookmarks, des mots de passe, des préférences, de l'impression, des addons, en plus d'outils de dev web, du mode private, du mode offline, et plein d'autres choses etc… Donc une fois Servo terminé, il restera du boulot.
Pour Mozilla donc, la question se pose déjà. Est ce que Firefox un jour switchera vers Servo ? pour l'instant très difficile à dire, et si j'en crois les mailing-list, Mozilla ne le sait pas lui-même. Une chose est sûre, ils veulent se débarrasser de XUL, XBL, XPCOM et autres trucs (qui ne seront pas implémentés dans Servo, c'est certain). Pour ça il faut se débarrasser du système d'extension XUL (c'est en cours), il faut migrer l'interface XUL vers du HTML ou du natif (et redevelopper plein de composants interne qui sont en XPCOM). La migration de l'interface est en discussion. Certains proposent plutôt de laisser continuer Firefox comme cela, tout en le faisant évoluer de manière à ce que la transition vers un "Firefox nouvelle génération" soit douce (en clair, il faut que les extensions soient prêtes, d'où les webextensions qui arrivent dans Firefox, qui proposeront une API qui s'abstrait totalement de l'API interne du navigateur, donc de Gecko). D'autres proposent de faire le ménage au fur et à mesure et redévelopper ce qu'il y a à redevelopper pour que ce soit compatible Gecko & Servo (cela veut donc dire migrer petit à petit des bouts d'interfaces de XUL vers HTML, de redévelopper des composants XPCOM en module javascript quand c'est pertinent etc..).
Une chose est sûre : cela va prendre beaucoup de temps, quelque soit la solution.
Maintenant il n'y a pas que Firefox Desktop. Il y a aussi Firefox pour Android, et Firefox OS. Ces deux produits n'utilisent pas XUL et autres trucs "deprecated" (l'interface pour FxAndroid utilise la techno d'android, et pour FxOS, tout est en HTML). Il est donc fort possible que ces deux logiciels remplaceront Gecko par Servo quand ce dernier sera suffisamment mature. Même si ça ne se fera pas en 5 minutes, il y a à priori moins de boulot à l'heure actuelle que pour Firefox Desktop (d'ailleurs on remarquera le port de Servo vers Gonk, le système linux de FirefoxOS : c'est une première étape franchie ;-) ).
Comme autre produit phare, reste Thunderbird. Là tout est en XUL, avec beaucoup de composants XPCOM en C++ (implémentation des protocoles de messageries…). Forcément, l'avenir de Thunderbird est lié à l'avenir de Gecko. Les devs de Thunderbird étudient donc la possibilité de refaire un Thunderbird tout en HTML pour l'interface, et même de redévelopper les différents protocoles en JS. (Qui c'est, verra-t-on Thunderbird sur FirefoxOS ? ;-)
En conclusion : Servo est encore expérimental (dans les faits et officiellement), mais je pense que ça deviendra à terme une vrai brique utilisable en "production". Même si Mozilla décide un jour d'abandonner Servo (ce dont je doute), vu le nombre grandissant de contributeurs externes, c'est un truc qui finira en prod de toute façon. Chez Samsung ou ailleurs.
[^] # Re: Nostalgie...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Calculatrice : matériel et logiciel ouverts ?. Évalué à 4.
Pareil, ce qui m’intéressait dans la hp48, c'est qu'on arrivait assez vite aux limites de la machine avec le RPL. Avec l'assembleur, on pouvait alors repousser les limites, et ça nous forçait à nous triturer les méninges pour imaginer de meilleurs algorithmes, pour optimiser la mémoire, pour optimiser les temps de calculs etc…
J'ai beaucoup appris sur la gestion de la mémoire, sur l'optimisation du cpu, sur ce qui étais préférable de faire pour avoir de bonne perf pour faire telle ou telle chose. Je me rendais alors mieux compte des "betises" que je faisais avec des langages plus haut niveau comme le C sur d'autres machines.
/me qui a toujours sa HP48 sur son bureau
[^] # Re: Editeur de bases SQLite
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin du "permissive add-on model" chez Mozilla, ou comment flinguer une base d'extensions. Évalué à 2. Dernière modification le 26 août 2015 à 16:33.
pas du tout. Tu confonds XUL et XULRunner…
(tout dépend après ce que tu appelles "plusieurs années")