Laurent J a écrit 2932 commentaires

Il est temps de revenir sur Firefox ;-)

ou proposer tout simplement les deux…

Note: le dépôt https://packages.sury.org/php est géré par le mainteneur officiel des paquets PHP pour Debian.. voir https://deb.sury.org

Ça fait un peu plus de boulot de faire les paquets pour deux versions différentes, mais pas trop si vous organisez les fichiers correctement dès le départ. Sur une debian like, ils y arrivent bien (/etc/php/<version>/<fichiers de config>), et on peut installer théoriquement plusieurs versions de PHP en même temps.

Même si les dépôts officiels de Debian ne proposent qu'une version, on peut utiliser le dépôt alternatif https://packages.sury.org/php qui permet d'installer plusieurs versions en parallèle avec la même organisation de fichier que l'officiel Debian.

Il y gscan2pdf qui permet de scanner et de faire de l'OCR avec notament Tessaract. Par contre le sortie c'est du PDF ou Djvu. Pas de texte brut. Donc faudra convertir le pdf en texte brut (ce qui doit certainement se faire..)

L'écriture inclusive n'oblige pas à utiliser le point médian.

je dirais qu'un dev qui va promouvoir PHP est un dev qui n'a eu que très peu d'autres expériences de langages

Moi je dirais que, de ton premier commentaire à celui-ci, tu as des idées (fausses) bien trop arrêtées pour te permettre un tel jugement.

J'ai 35 ans de programmation derrière moi, avec au final pas mal d'expérience dans beaucoup de langages. PHP n'est pas sans défaut, mais de là à le mépriser à ta façon, c'est totalement débile.

En tout cas, ce snobisme sur tel ou tel langage parce qu'il serait plus "pure", ça me gonfle, car souvent prônés par des personnes qui sont en décalage avec la réalité du terrain, et croient détenir la vérité à cause de leur immaturité professionnelle, et pour certains sous l'emprise d'un bel effet Dunning-Kruger.

Non, je ne connais pas bien

Critiquer un truc qu'on ne connaît pas bien, c'est fort quand même…

Ces typages sur des langages interprétés ont tendance plus à m'agacer

En PHP, tu n'es pas obligé de les utiliser. Toutes les nouveautés syntaxiques sont des ajouts et sont optionnels.

Donc tu peux continuer à utiliser PHP comme en version 3 pour un langage de template, il n'y a pas de souci (enfin presque, les constructeurs des classes ne peuvent plus avoir le nom de la classe et doivent s'appeler __construct, mais à part ça…).

améliorer la qualité de produits qui ne peuvent pas changer de techno rapidement.

s/peuvent/veulent. Sérieux, pourquoi faudrait-il absolument passer à une autre techno ? Que sais-tu des besoins et envies des développeurs sur ces projets en PHP, surtout pour les projets internes ?

Si un langage satisfait les objectifs de l'application, aucune raison de changer. On choisi un langage selon l'application. Pas l'inverse. Ce n'est pas à toi de décider qu'il faudrait arrêter PHP, tout ça parce que tu n'aimes pas ce langage. C'est totalement absurde.

la syntaxe juste imbuvable quand on a connu d'autres choses

Totalement subjectif. Question de goût.

l'incapacité de faire de l'asynchrone, de faire autre chose que du web etc.

Mouai, ça montre surtout que tu ne connais pas bien l'éco-système PHP, et qu'au final, tu perd toute crédibilité dans tes conclusions.

On peut faire plein d'autres choses que du web. J'ai des workers en PHP dans une infra qui commence à être conséquente (des dizaines de VM) : aucun souci (pas de plantages, pas de problème mémoire.. rien). Avec ReactPHP, tu peux faire de l'asynchrone. Etc..

Le passage de PHP 5 à 7 a été très compliqué

Je n'ai quasiment rien modifié dans les applis PHP que je maintiens. Je ne vois pas en quoi le passage de PHP 5 à 7 a été compliqué.

Les améliorations qu'il y a eu dans PHP 7 et PHP 8 au niveau syntaxe, n'introduit pas des incompatibilités avec les versions précédentes. Ce sont des ajouts. Tu n'es pas obligé d'utiliser toutes ces nouveautés syntaxiques.

Ces modifications peuvent se faire lors de refactorisations de code ou lors d'ajout de code par exemple. Mais ce n'est pas une obligation.

Pardon, mais contrairement aux freins, à la mutuelle ou à l'assurance, les cookies non techniques ne sont aucunement une obligation.. technique, et encore moins une obligation légale.

Si vous n'avez pas le temps de respecter le RGPD, ne perdez alors pas de temps à installer les cochonneries qui créé ces cookies, surtout si ils ne vous servent à rien.

en même temps, si il n'y a pas le format que tu veux, comment voudrais-tu exporter le contenu ? En le chiffrant ? mais alors ça sert à quoi de l'exporter ? autant garder ton kbx.

L'export sert pour importer ces données dans une autre base, un autre système qui possède sa propre manière de chiffrer les données. Si à ce système tu lui donnes un csv avec des données chiffrées (dont il ne sait pas comment elles sont chiffrées), je vois pas comment il pourra les importer.

Personnellement, l'export CSV me sert à comparer le contenu des deux exemplaires de ma base (une sur chaque ordinateur), quand je ne sais plus si les deux exemplaires sont bien synchronisés, et surtout quand j'ai fait des modifications des deux cotés en oubliant de les synchroniser avant.

si tu as ton propre serveur mail, je ne suis pas sûr que cette application soit vraiment utile. D'une part parce qu'effectivement, ça ne va pas changer grand chose que tu consomme 1go ou 490go de ton espace disque.

Et parce qu'on peut imaginer que tu peux avoir des scripts installés sur ce serveur qui feront cet archivage automatiquement pour toi (puisqu'ils auront accès directement aux fichiers des mails).

Genre un script qui tous les jours ou toutes les semaines, scanne les dossiers "archives" de chaque compte mail, et déplace ces mails vers un stockage "froid" (c'est à dire un zip quelque part, un autre répertoire, un stockage "cloud" ou autre…).

j'encourage à ce que tu changes ton mot de passe après avoir utilisé l'application web

Pourquoi pas, mais c'est pas très pratique, parce qu'il va falloir reconfigurer les compte mails dans tous les clients mails (mot de passe sauvegardé dans le navigateur, client mail de son smartphone etc…)

Dans thunderbird, les mails sont stockés dans un format standard (mbox ou maildir, au choix). Donc profil ok ou pas, il n'y a pas à s’inquiéter, les mails sont lisibles par tout autre client lourd compatible avec ces formats (je ne dis pas que ce sera simple toutefois de faire cet import..)

Maintenant, j'utilise Thunderbird depuis plus de 15 ans, avec actuellement 17 boites aux lettres, et je n'ai jamais eu de problème de profils.

J'utilise Thunderbird, et une solution pour archiver les e-mails est de les déplacer dans les dossiers locaux, tout simplement.

D'ailleurs, on peut utiliser la fonction d'archivage (bouton archiver sur chaque message), que l'on configure pour que ça aille dans le compte/dossier de son choix.

Et sinon, personnellement, je n'utiliserais pas ta solution en ligne : je trouve "dangereux" de donner mes accès à mes boites mails à une application web, quand bien même tu jures que ce qui est installé sur ton serveur est strictement le même code source que la version que tu publies. Bref, préférez installer cette jolie application sur votre propre serveur ;-)

Ton post semble très intéressant. J'ai réussi à le lire presque jusqu'au bout. Malheureusement, à cause de la longueur du récit, et surtout l'utilisation d'un vocabulaire ultra technique, la lecture reste accessible uniquement aux gens dont le réseau, c'est leur métier.

J'ai donc l'impression que, malgré cet "exploit", c'est un maigre espoir pour ceux qui veulent se passer de leur box Orange. Je me trompe ? Est-ce beaucoup plus simple qu'il n'y parait ?

Déjà, elle ne dirige plus la fondation.

D'autres parts, on parle dans ce post de critiques sur ce qu'a fait Mozilla Corp par le passé. Par le passé, elle n'a jamais dirigé Moz corp. Sans vouloir l'innocenté de tout, elle n'est donc pas non plus responsable de tous les déboires et errements de Mozilla Corp. D'où le sens de mon commentaire.

non. Le projet Firefox a démarré par 2-3 employés Mozilla qui voulaient proposer un navigateur allégé par rapport à la Suite Mozilla. ça a donc démarré par un POC développé sur leur temps libre, et une fois que Phoenix (ancien nom de Firefox) 0.1 était sorti, le dev de Firefox a vraiment démarré.

Est-ce possible d’arrêter avec ces histoires de salaire du boss ? Rien à voir avec les problèmes de management ou autre. La compétence ou l'incompétence d'un CEO n'est pas proportionnel à son salaire.

Et puis il faut savoir aussi de quel boss on parle. Il y a deux entités, Mozilla fundation, et Mozilla Corp, chacune avec un boss différent.

Et Mozilla Corp, responsable des développements (non, ce n'est pas la fondation qui décide quoi développer, elle s'occupe juste de la gouvernance du projet, de la vision à long terme etc..), a vu au moins 4-5 CEO se succéder depuis une décennie.

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é ?