Laurent J a écrit 2938 commentaires

Je suis 100% convaincu que Mozilla avait une roadmap bien établie pour qq années

Je n'en suis pas du tout convaincu. Même si je n'étais pas dans les secrets du staff, en tant que contributeur, j'ai pu voir des trucs arriver non prévue plus ou moins rapidement.

Mozilla n'est pas une entreprise comme un autre, car il y a des contributeurs externes à prendre en compte. Ils avaient à l'époque (dans les années 2008-2014) une vision technique à un an ou deux ans max, d'après ce que je voyais. Les contributeurs comme moi étaient invités aux "summits" (en 2008, 2010, 2013 …), rassemblant employés et développeurs, et où on nous annonçait ce qu'il était prévu de faire globalement les prochains mois, mais où aussi il y avait des réunions et workshops entre nous pour discuter d'évolutions techniques, pour proposer des projets etc.. Bref, la roadmap était faite par Mozilla, mais aussi plus ou moins par la communauté.

Et on a d'autres preuves pour laquelle Mozilla n'avaient pas de roadmap figée sur plusieurs années : ce sont la naissance de projets comme Firefox, mais aussi Firefox OS.

Ces deux projets ont démarrés presque en sous-marin, par une poignée de développeurs salariés. Quand il y eu un POC prometteur, la roadmap de Mozilla a été bouleversée pour développer à fond ces projets. Et cela, en quelques mois (Le projet Firefox OS a démarré en juillet 2011, et il était officiellement annoncé début 2012).

qui n’incluait pas une version mobile.

Bah si, Firefox pour android n'a pas arrêté d'être développé de 2010 à aujourd'hui, avec des versions sorties en même temps que celles de Firefox pour desktop. Après, toutes les versions n'ont pas apportés des gros changements, mais il y avait au moins le moteur de mis à jour.

Attendre jusqu’à 2015 est injustifiable.

Ils n'ont pas attendu 2015 justement. Je rappelle qu'entre 2011 et 2015, beaucoup d'effort été concentré sur Firefox OS, donc en particulier sur les perfs et améliorations du moteur de rendu sur un mobile. Firefox Android a profité durant ces années de toutes les améliorations en terme de perfs qui ont été faites pour Firefox OS (qui est en fait un navigateur pour mobile, il faut le rappeler !). Et si tu trouves que Firefox Android était utilisable seulement depuis 2015, c'est parce que vers cette période, toutes les gros chantiers pour améliorer Gecko pour le mobile, ce sont achevés.

Bref, pendant les années 2011-2015, période que tu critiques, Mozilla était en fait à fond sur le mobile, au point de mettre moins de ressource sur le desktop, et de délaisser plus ou moins la communauté. Ce qui a fait perdre des parts de marché à Firefox…

Rater le premier train, c’est une chose, rater le train pendant 5 ans, c’en est une autre, qui pointe à un très mauvais management.

C'est facile de critiquer le passé, mais beaucoup plus compliqué quand il faut prévoir le futur et anticiper. Avec des "si", on peut mettre Paris en bouteille, comme on dit.

Avec toutes les contraintes et priorités de l'époque chez Mozilla (dont tu n'as pas la moindre idée, sauf si tu es un de ces managers de l'époque, caché sous ce pseudonyme groumly), je ne suis pas sûr que tu aurais fait mieux.

Oui, il y a probablement eu des problèmes de management, mais il y avait aussi encore plus probablement d'autres raisons.

le quasi abandon de Thunderbird

Thunderbird n'est pas abandonné. Il y a des salariés à temps plein dessus. Certes, le projet a maintenant sa propre structure, mais il vit. Si Mozilla n'a pas consacré autant de ressources sur ce logiciel que sur Firefox, c'est parce qu'ils n'ont pas réussi à trouver un business modèle pour financer son développement (et ce n'est pas faute d'avoir essayé, il y a eu un temps une équipe pour ça). Développer à perte, ça devient compliqué au bout d'un moment. Sans parler qu'en parallèle, il y a les buldozers comme gmail qui raflent les parts de marché.

Le rejet de toutes techno venant de Google (Dart VM, PNaCL, …),

C'est surtout que ces technos n'avait pas grand chose à voir avec le web, fondamentalement parlant… Et par la suite, il y a eu le Webassembly qui a pu concillier les objectifs de ces technos google avec le web. Donc aucun regret à avoir avec ces technos.

Leur moteur était plus difficile à maintenir que Webkit

C'est probable. Mais ce qui a fait choisir webkit par rapport à gecko, sur nombre projet, c'est surtout la facilité d'embarquer le moteur, pas sa complexité interne (un développeur qui utilise une lib, il s'en fout de comment elle est faite en interne, ce qu'il veut c'est une API simple et stable).

Et Gecko n'était pas fait pour être embarqué, mais plutôt pour embarquer (aka Xulrunner, XPCOM etc..). On peut regretter cependant le manque de volonté de rendre Gecko embarquable (mais cela nécessite une API stable, et cela a donc des conséquences aussi sur l'évolutivité du composant).

À noter que Servo, le moteur experimental de Mozilla, a été conçu dès le départ pour être embarqué.

j’ai beaucoup de mal à croire qu’il a fallu 5 ans pour sortir un MVP.

J'ai vu personnellement des prototypes de Firefox pour mobile vers la fin des années 2010
. Donc Firefox sur mobile, c'est très vieux. Mais cela a mis beaucoup de temps pour arriver sur le grand public, parce que :

1. Il fallait que gecko fasse une cure d'amaigrissement, avec des grosses améliorations coté perf pour que ce soit réellement utilisable. Le projet Firefox OS a permis de réaliser ces améliorations
2. il fallait rendre Gecko embarquable dans une "view" Android. ça aussi ça demande du boulot (je ne parle pas d'IOS, parce que de toute façon Apple interdit d'autre moteur JS et HTML que celui fourni par les iphone)
3. Comme tout cela demande un gros effort d'investissement en temps et en argent, cela s'est fait plus lentement que chez la concurrence. Mozilla, malgré les millions qu'ils gagnaient, n'ont pas la force de frappe de Google ou d'Apple. Et donc comme dans toute entreprise, il y a des priorités, et Firefox pour mobile était moins prioritaire que Firefox pour desktop. Et au passage Firefox OS a pompé pas mal de ressources, donc…

mais de toute façon le code de Firefox est une telle usine à gaz que je serais incapable de pratiquer plusieurs des libertés du LL

Ce n'est pas beau de justifier son incompétence en rejetant la faute sur le code.

Ce n'est pas non plus une honte d'être incapable de comprendre le code d'un moteur de rendu HTML, quel qu'il soit : cela fait parti des trucs les plus complexes à développer, et pas beaucoup de développeurs sont capables de développer un navigateur web. D'ailleurs, c'est la raison principale pour laquelle il n'existe qu'une poignée de moteur de rendu dans le monde.

Pour le reste, l'interface de Firefox, c'est du XUL (enfin maintenant, du HTML avec des web components pour implémenter les tags XUL), du JS et du CSS. Pour cette partie là par contre, c'est à la portée de beaucoup de développeurs (web).

L’intérêt d'avoir un truc central, quand même, c'est de :

1. rendre les fichiers accessible n'importe quand
2. faire une sauvegarde

Parce qu'actuellement, comment le bazar de chacun est sauvegardé ?

• [ ] je ne peux pas installer l'application sur mon téléphone (trop vieux, ou OS "exotique")

La rente de Microsoft c'est toujours Windows et MS Office

Oui et non. Le chiffre d'affaire en 2019 de la division "intelligent cloud" (produits serveurs et services cloud, Microsoft Azure…) est au même niveau que la division "Informatique Personnelle" (Windows, Microsoft Surface, Xbox, search…) et que la division "Productivité et entreprise" (Office 365 et Office, LinkedIn, Microsoft Dynamics…)

Aux alentours de 11 milliards de dollars chacune pour le 4ieme trimestre 2019..

https://www.informatiquenews.fr/microsoft-un-ca-en-croissance-de-14-et-benefice-qui-explose-62815

Bref, la rente Windows et Office "baisse" (en proportion du total du CA) au fil des ans, au profit de Azure &co.

non parce qu'il y a 99,9% de chance que l'adresse mail soit bidon, ou qu'elle soit celle d'une personne qui n'a rien avoir avec cette histoire.

Des fois même l'adresse de l'expéditeur est celle du destinataire.

ça sent le manque de Ram, ou une incompatibilité matériel coté carte graphique. N'aurais-tu pas activé des préférences de fonctions expérimentales liées à la CG dans Firefox ? Essaye avec un profil vierge.

et essaye d'utiliser la version vanilla plutôt que celle buildée par ta distro. https://www.mozilla.org/fr/firefox/new/

Bientôt on pourra se passer des sysadmins et c'est une bonne chose

Alors déjà : non (voir plus bas).

Ensuite, c'est marrant que tu dises ça, alors que plus loin :

Mais dans un contexte de PROD et d'exploitation :
quand il y a un soucis de performance comment cela se passe ?

Quand tu as ça, tu fais justement appel… à un admin système.

À moins que tu sois tout seul à tout faire dans ta boite, ce n'est pas aux développeurs de s'occuper de la prod, de s'occuper de l'infra et de ses problèmes. C'est aux admin sys que tu crois qu'ils vont disparaître.

Admin sys est un vrai travail, un vrai métier, qui est utile pour faire en sorte que ce que produisent les développeurs (du code, des services et éventuellement sous forme de conteneurs Docker), soit opérationnel dans la vrai vie (le laptop du dev, ce n'est pas la vrai vie, c.a.d, n'a pas les contraintes d'un environnement de production).

Opérationnel veut dire :

• monitorer pour détecter les pannes, les ralentissements, les problèmes
• configurer l'infra de manière à ce que tout puisse tourner correctement, qu'il y ait une petite charge ou une grosse charge, que le produit des développeurs soit nickel ou codé avec les pieds
• sécuriser
• sauvegarder
• faire des plan de reprise d'activité
• remplacer le matériel défectueux ou en fin de vie (quoique il peut y avoir du personnel dédié à ça dans des grosses boites ou datacenter)

etc etc etc…

Et pour répondre plus précisément à ta question, quand il y a des soucis de perfs, d'abord c'est grâce à l'admin que tu peux savoir d'où ça vient (à moins que toi en tant que dev, tu n'a rien d'autres à foutre que de surveiller et d'analyser les problèmes de prod), et ensuite, c'est soit la faute à l'admin sys (ne dimensionne pas/ne configure pas correctement les machines et les réseaux), soit la faute à l'architecte logiciel (ex: pas de système de cache ou a fait des choix techniques merdiques), soit la faute au développeur qui a codé de la m..de, avec par exemple des empilements de framework à tout va, des milliers de paquets npm, des algo foireux ou encore a utilisé Java [1]

Disclaimer: je suis avant tout un dev, mais aussi admin sys à mes heures perdues, et je n'aurais jamais cette prétention de pouvoir remplacer un vrai admin sys. C'est juste impossible de tenir les 2 rôles correctement dans une boite qui veut grandir.

[1] oui je sais, on n'est pas vendredi. Désolé.

ok, trouvé : https://benediktkr.github.io/ops/2015/05/01/remote-fde.html

J’espère sérieusement que tu ne chiffres pas tes partitions avec une clef stocké en clair sur la même machine.

Je ne chiffres pas les partitions de mes serveurs, puisque je n'en vois pas trop l'interet.

Par contre, vraie question : si la clé n'est pas sur le serveur, comme fait-on pour avoir un serveur qui puisse rebooter tout seul ? Ou comment fait-on pour indiquer la clé au redémarrage d'un serveur distant ?

Je crois savoir l'intérêt (relatif): une fois que tu rend la machine, celle-ci est louée à une autre personne. Cette personne pourrait analyser le contenu du disque, et essayer de récupérer le contenu des anciennes partitions (avec beaucoup de patience).

Si les partitions sont chiffrés, cela devient bien plus compliqué. Il faut pouvoir retrouver la clé de déchiffrement de la partition. Ce qui, il me semble, est d'autant plus compliqué qu'il y a de forte chance que l'endroit ou elle était stockée ait été écrasé lors de la réinstallation du système.

Toutefois, cette précaution de chiffrer une partition n'est utile que pour les serveurs physiques. Pour les VM et autres conteneurs "cloud", ce sont des disques virtuels donc, données irrécupérables après recréation des partitions virtuelles.

Et encore, pour les serveurs physiques, OVH dit qu'il détruit toutes les données sur les disques avant de remettre le serveur en location. Par contre je n'ai pas trouvé l'information qui explique en quoi consistait exactement cette destruction.

Mouai.. En imaginant qu'un "indélicat" arrive à se procurer un snapshot. Rien ne l'empêche de le remonter sur sa becane avec les bons outils. La VM démarre, déchiffre le disque. Et… au final le chiffrement du disque ne protège rien.

Sauf si le chiffrement s'est fait avec une clé avec passphrase. Mais pas très pratique pour un serveur. D'ailleurs je doute qu'on puisse indiquer la passphrase au lancement d'un serveur sur OVH…

Tu réponds à qui ?

Quel cas est le plus grave?

Les deux.

Perso, je préfère leur système actuel, la première solution.

Et moi aucune des deux.

La vrai solution, et la plus sécurisée : tu met ta clé publique dans ton compte OVH, tu la choisi lors de l'installation de la machine. Tu reçois un mail sans mot de passe et tu n'as pas de souci de pirate qui scruterai ta boite mail.

Au sujet du compte OVH piraté : ça ne devrait pas arriver. Si cela arrive, c'est que tu n'as pas assez sécurisé son accès (par une double authentification par exemple).

Bref, comme tu dis, OVH ne sont pas des débutants…

De quel compte parles-tu ?

Si tu parles du compte OVH, heureusement que le mot de passe root n'est pas indiqué au moment où tu créés ton compte, car cela signifie alors qu'il est stocké/haché quelque part. Conséquence : sécurité moyenne, et surtout, si tu changes ton mot de passe root sur la machine, celui stocké dans ton compte OVH n'est plus valide.

Si tu parles du compte root proprement dit, que tu saisirais dans le formulaire d'installation de la machine, je ne vois pas l’intérêt. Parce que là, tout comme sa génération automatique et envoi par mail comme aujourd'hui, tu ne sais pas où le mot de passe est passé et stocké (même temporairement) lors du processus OVH d'installation de la machine, donc de toute façon, il faut le changer à la première connexion sur ta machine.

Et puis de toute façon, c'est une hérésie d'utiliser un mot de passe pour le compte root : dés la première connexion, la première chose à faire est de changer le mot de passe, poser sa clé ssh, et interdire les connexions par mot de passe (au moins pour le root) dans la config du serveur ssh de la machine.

Ce dont on parle, c'est le mot de passe root de la machine qui vient d'être installé. Rien à voir avec le mot de passe de ton compte OVH.

Ce mot de passe root est généré aléatoirement lors de l'installation du système.

"voila, vous pouvez vous logguer via l'utilisateur root avec le password 123456". J'exagère sur le password, il y avait aussi des lettres, mais la taille est a peu près celle-ci. Ah, et bien sûr, le fingerprint du ssh du serveur…

C'est surtout de ta faute : si tu n'indiques pas de clé ssh dans ton profil, il faut bien, que puisses te connecter sur ton VPS fraîchement installé. Tu veux qu'ils t'envoient ton mot de passe par télépathie ?

Ensuite, faut vraiment pas avoir de bol pour se faire pirater son VPS fraîchement installé, entre le moment où ils t'envoient le mail, et le moment où tu te connectes la première fois et que tu changes ton mot de passe ;-).

Si ça existe, j'ai pas trouvé

"mon compte > services > clés ssh"

je ne mentionne pas le fait que le /etc/sources.list, de mémoire, n'utilise pas les serveurs debian, mais un repo OVH, ce que je peux comprendre, mais j'aurais préféré un proxy genre apt-cacher-ng

Les dépôts sont ceux d'OVH, pour plusieurs raisons :

• ils sont sur leur lan, ça va donc plus vite à installer (et pas de bande passante à payer pour eux vers l’extérieur)
• ils peuvent avoir des noyaux optimisés pour leur matos
• cela permet d'installer leur outil de monitoring pour que tu ais de beaux graphiques dans le manager.

Mais :

• tu peux changer tout ça en faisant pointer sur des dépôts originaux (et d'ailleurs, si je ne me trompe pas, en faisant un apt update && apt upgrade, tu remarqueras probablement qu'au final, il ne réinstalle rien : ce sont les paquets originaux)
• tu peux même installer un noyau vanilla (et même t'installer un noyau custom, on le fait sur certaines machines)
• tu peux virer leur outil de monitoring.

Pour le reste, peut être que l'offre VPS n'est pas ce qu'il te faut pour ton besoin. Je ne sais plus pour les VPS, mais je sais qu'en prenant un serveur physique (j'en gère des dizaines), tu partitionnes comme tu veux avant l'installation de l'OS.

J'aimerais bien un retour d'expérience pour les VPS chez d'autres hébergeurs, voir si c'est aussi "compliqué" de partitionner et de chiffrer…

L'augmentation des stats reste bon signe, c'est certain. Good job!

Luanit est un framework de tests unitaires. Dans un projet, il est donc susceptible d'être lancé à chaque push sur le dépôt du projet, si il y a de l'intégration continue.

Normalement, dans un système d'intégration continue bien fait et bien configuré, les dépendances externes ne sont installés au moment du lancement des tests que quand leur version change ou qu'elles sont nouvelles. Dans gitlab-ci, il est ainsi possible de mettre par exemple un répertoire de dépendances comme node_modules (paquets npm), dans un cache. À chaque lancement de l'intégration continue, gitlab-ci, créé les répertoires de dépendances à partir de son cache. Cela évite au packageur (ici npm), de re-télécharger tous les paquets.

Mais ça c'est quand c'est bien fait.

Il y a des projets où c'est mal foutu : utilisation d'un outil d'intégration continue pas cool, ou mal configuré.
Du coup, à chaque push sur le dépôt d'un de ces projets, téléchargement systématique des dépendances. Sur un projet bien actif, cela peut en provoquer des dizaines par jour. (Pour SlimerJS, j'avais eu des soucis d'un serveur de je ne sais où qui téléchargeait toutes les 2-3 minutes le paquet : il me bouffait toute la bande passante de mon serveur d’hébergement !)

Du coup, les statistiques ne veulent pas dire grand chose. Cela ne correspond pas au nombre d'utilisateurs, donc à la popularité de l'outil.

Disons que c'est une popularité artificielle, qui peut avoir tout de même un bénéfice : avec des stats gonflées ainsi artificiellement, cela propulse le paquet dans les hauteurs des classements des "projets les plus utilisés", donc ça incite plus facilement à ceux qui doivent choisir, d'utiliser le projet en question. Ce qui fait encore plus gonfler les stats etc..

Qu'est-ce que tu appelles "ne plus bouger" ?

Parce que j'utilise Thunderbird depuis sa toute première version, et à chaque mise à jour, il y a des évolutions, en particulier depuis ces 2-3 dernières années. Ok, au niveau fonctionnalités, il n'y a pas de révolution à chaque fois. Mais ça bouge. Beaucoup même ces derniers temps.

Et j'en sais quelque chose : je maintiens pour un client une appli mail qui repose sur thunderbird (c'est un thunderbird avec une tout autre interface, sans passer par une extension, donc il y a des patchs, des modules XUL additionnels etc), et à chaque upgrade, j'ai toujours eu des problèmes de compatibilité avec les api internes, et donc des adaptations à faire, parce que justement, ça bouge.

Et c'est de pire en pire depuis 2-3 ans, surtout en ce moment, car XUL/XBL/etc commence à disparaître de Gecko, donc de TB. Là, concrètement, pour faire le passage à TB 68, l'appli mail du client est toute cassée. Faut que je refasse plein de trucs.

Donc non. TB n'est pas immobile. Peut-être que tu trouves qu'au niveau fonctionnalité ça ne bouge pas trop, mais je t'assure qu'ils font beaucoup de boulot "qui ne se voit pas", pour tuer le code legacy et pouvoir, dans un future proche, bouger encore plus vite.

Si il y a un désaccord, on peut forker.

En théorie. Seulement en théorie. Un moteur de navigateur, c'est pas un hello world. C'est très complexe, très gros. Il faut avoir les moyens financiers d'une grosse boite pour forker un tel projet. Même Microsoft ne s'y est pas risqué.

Ce qui peut être gênant, c'est d'avoir un fournisseur final majoritaire (Google) qui du coup peut dicter un peu plus le futur, pas que le moteur soit unique.

ça ne peut pas être gênant. ça peut être TRÈS gênant. Voir cauchemardesque. Qu'une boite, commerciale, dicte le futur de standards ouverts, c'est toujours mauvais à long terme.

je l'aime beaucoup ce IP qui a tué toutes les diversités

IP est un protocole, pas une implémentation. Fort heureusement, il y a plusieurs implémentations, qui ont permis à IP d'exister et de se répandre !

la responsabilité est de ton côté

Trop facile de balancer la responsabilité du coté des utilisateurs. Comme si tout le monde pouvait, savait, modifier un navigateur.

Tout d'abord il y a au moins une autre application non liée à Mozilla qui s'en sert : Songbird

Oui, mais non. Songbird n'était pas une application qui embarquait gecko, mais qui reposait sur gecko, ou plus exactement XulRunner. Comme la majeure partie d'application XUL de cette époque. Songbird était loin d'être la seule, il y a en a eu plein d'autres : Thunderbird, Nvu, Komodo Ide, Chatzilla et j'en passe.

Il y a une différence entre embarquer Gecko, le moteur de rendu et utiliser XulRunner comme runtime. Le second, c'est en gros Firefox sans son interface : on a donc Gecko, mais aussi tout un framework et des composants XUL ou techniques prêt à l'emploi.

Gecko, c'était vraiment que la partie moteur de rendu et XPCOM (système de composants binaire ou JS).
Il fut un temps où il y avait la possibilité d'embarquer Gecko, c'est à dire d'avoir un lib avec une API, permettant d'instancier un moteur de rendu, de le manipuler (charger une page etc).

Camino, mais aussi d'autres navigateurs de l'époque, utilisaient cette lib. (donc ce n'était pas des applis XUL).

XulRunner, plus simple à utiliser pour développer une application, avait pris le dessus, entre autre parce que Thunderbird l'utilisait et que donc Mozilla le maintenait, et Mozilla du coup mettait moins de moyen sur la partie "embeddable" de Gecko.

L'API embed fut donc de moins en moins maintenue. Et quand Mozilla decida d'abandonner XulRunner puis le XUL, c'était trop tard pour relancer le projet embed. Presque plus personne n'utilisait cette API (Camino était mort…).

Ensuite, il y avait peu de contributeurs sur cette api embed.

En clair, contrairement à ce qui s'est dit, ce n'est pas une vraie volonté de Mozilla de ne pas rendre Gecko embarquable, c'est juste que les moyens manquaient, et qu'il y avait d'autres priorités à l'époque.

Il y a bien eu quelques workshops (il y a de cela 10 ans) pour tenter de relancer le projet de cette API, (j'avais assisté à l'un d'entre eux), mais la mayonnaise n'a pas pris.

Depuis, ils se sont un peu rattrapés : Servo, le moteur 100% en rust de mozilla est fait depuis le début pour être embarqué. Et il y a une lib embarquant gecko pour les navigateurs pour Android, geckoView, qu'utilise Firefox pour Android (ou d'autres variantes, je n'ai pas trop suivi).

Je ne sais pas ce qu'il en est aujourd'hui de cette API embed de Gecko.

non, du moment que le travail demandé est fait dans les temps.

Bosser sur des projets perso, ça fait partie de la "veille" selon moi. D'ailleurs c'est pas pour rien que chez Google ou d'autres boites, les développeurs peuvent passer (ou pouvaient, je ne sais plus si c'est le cas chez Google) 20% de leur temps pour développer sur des projets libres de leur choix.

Une boite qui ne laisse pas faire de la veille à ses devs, c'est une boite à fuir. En tout cas de mon point de vue.