Je me suis toujours demandé ce que ferait la communauté si Mozilla se cassait la gueule et qu'il n'y avait plus de Firefox. Est-ce que quelqu'un - Red Hat, Ubuntu, etc. - serait capable de reprendre le flambeau ? Est-ce qu'on finirait tous par utiliser Chrome ou un de ses dérivés libres (ex. Ungoogled Chromium) ou pas ?
C'est une chose qui risque d'arriver, surtout que 80% des revenus de Mozilla proviennent de Google. Le jour où Alphabet décidera de lui couper les vivres, c'en est fini de Firefox.
De mémoire, il y a eu une période où Firefox avait eu des problèmes de performances, mais c'était il y a des années.
Les versions actuelles sont à mon avis très performantes, sachant que j'utilise Ungoogled Chromium à côté pour certains sites incompatibles ou pour utiliser le mode application qui n'existe plus sous Firefox depuis l'arrêt de PRISM. De plus, Chromium est devenu un ogre qui dévore ma RAM comme pas possible.
Évidemment le temps de chargement d'une page peut-être un peu plus lent en activant les extensions, mais quel plaisir d'oublier les publicités, cookies de traçage et autres joyeusetés apportées par le Web moderne.
ça me rappel un projet énorme de ma boite, utilisé par plusieurs métier, qui va tranquillement sur ses vingt ans, avec son lot de dette technique. Il a été décidé de la refaire en technique moderne (micro service, web app…) des moyens colossaux ont été mis dessus pendant plusieurs années, on commence a peine à pouvoir faire une fraction de l'ancien outil, ça perd du temps en refacto, parce qu'on va pas partir en prod avec de la dette technique. Quasiment tous les devs de l'ancien sont partis vers le nouveau, y'a plus d'évolution (sauf les indispensable dans l'ancien)…
Bref si les moyens mis dans le nouveau avaient été mis dans l'ancien, qu'on avait rationalisé les inputs pour limiter le nombre de format d'entrées, on aurait pas eu cette interruption d'évolutions…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
La réécriture est toujours un gros dilemme dans une équipe de développement. Si ça peut être évité, c'est toujours une bonne idée de faire évoluer plutôt que réécrire ; mais ça n'est parfois pas possible et souvent ça semble bien plus coûteux (ce qui est généralement faux à périmètre fonctionnel égal)
Je ne comprends pas ta position. Tu veux dire que la transition valait le coup, ou le contraire ? Dans cet article, l'auteur, qui semble être familier avec Wayland (I'm no stranger to Wayland. Sway was my daily driver for many years. My primary reason for switching was merely curiosity to see what it was like. I found some things lacking, so I went and patched/fixed a few bugs), ne semble pas convaincu de l'intérêt de l'opération : Wayland Isn't Going to Save The Linux Desktop
Au contraire, je pense que c'est une très bonne comparaison. Il s'agit de réécrire de zéro un logiciel pour faire la même chose que l'ancien. Le fait qu'il le fasse différemment, avec des techniques modernes et des choix adaptés au monde actuel va de soi (de même que je suis sûr que c'était le cas dans l'exemple cité par fearan). On ne parle donc pas d'être "compatible" mais bien de refaire un logiciel de zéro pour les mêmes usages.
Wayland est effectivement un bon cas de "tout réécrire a foutu la merde pendant 10 ans au moins". Certes pour beaucoup de gens, Wayland est devenu utilisable, il y a quelques années déjà. Néanmoins, même pour ces personnes, cela a provoqué de nombreuses années charnières où il ne s'est rien passé dans le monde de la gestion des périphériques graphiques de sortie. Tout simplement parce qu'il n'y avait plus (ou presque) de dévs X pour développer quoi que ce soit (de nouveau, ou en correction) parce que "Wayland, c'est l'avenir".
Pendant des années, ça a donc été la merde pour la gestion des écrans haute densité (c'est pourtant loin d'être nouveau, même dans le ± grand public), dans la gestion du multi-écran, surtout avec des résolutions différentes et dans plein d'autres trucs.
Et même si maintenant Wayland est utilisable par le grand public, ça reste inutilisable pour le graphisme pro (qui est pourtant — je le rappelle — l'une des industries majeures dans les gros utilisateurs du numérique métier). On nous fait miroiter le futur avec le HDR, etc. mais la simple correction des couleurs (calibration, etc.) en SDR n'existe pas encore dans Wayland stable. Dans toutes ces années, le HDR aurait aussi pu arriver sur X11 s'il y avait encore du développement.
Et ainsi de suite.
Alors me faites pas dire ce que je n'ai pas dit. J'attends avec impatience que tout cela arrive dans Wayland, et je ne me fais aucune illusion que Wayland est le futur… parce qu'y a pas le choix et qu'on est déjà allé si loin, c'est pas comme si on allait faire un retour en arrière. Maintenant faut juste pousser pour que ces choses qui manquent (puis les nouvelles "fonctionnalités de la mort qui tue") soient rapidement implémentées. Je ne fais pas partie de ceux qui disent qu'il faut arrêter et retourner à X11. Cela ne m'empêche pas de regarder le passé et le présent avec un regard critique pour en tirer des leçons.
En fait, il fut un moment où il me semble bien que Linux commençait à avoir le vent en poupe et à être considéré de plus en plus sérieusement dans le monde du graphisme et surtout du son. Ces 2 moments critiques ont été perdus (j'ai l'impression) avec une succession de mauvaises directions techniques, même si ça revient pour le graphisme (mais pas grâce à Wayland — du moins pas pour l'instant —, surtout avec des logiciels qui commencent à prendre plus d'importance).
En fait dans mon expérience, aucune tentative de "réécriture de zéro" n'a eu un bilan totalement positif. J'ai aussi travaillé pour une startup qui a un jour décidé — il y a plus de 10 ans — de refaire tout son site en Python (parce que c'était la mode, et plus PHP qu'on utilisait jusque là! 🤦), micro-services (tout doit être en micro-services! 🖧) avec des APIs, etc. etc. On a passé 6 mois à temps plein dessus avant qu'un manager décide de tout mettre à la corbeille (on avait bien avancé, mais on était tout simplement pas au niveau de l'ancien site qui avait été construit depuis des années) et qu'on doit continuer à améliorer le vieux site à la place. J'étais l'un des seuls (voire le seul?) d'ailleurs à être contre ce projet de réécriture au début, mais ça m'a pas fait plaisir pour autant d'avoir raison. Parce que gâcher 6 mois de travail, c'est pas glop.
Pour parler de mon expérience plus au présent, tout ceux qui ont gueulé contre GIMP et ont dit qu'on peut réécrire un logiciel de graphisme en quelques années, qui serait au même niveau, se sont gaufrés. Attention, je dis pas non plus qu'il ne faut pas faire de tels logiciels. C'est d'ailleurs bien d'avoir plus de logiciels, plus de choix avec des directions et décisions différentes. Mais il faut simplement être conscient que pour en arriver au niveau de GIMP, il leur faudra 15 ans au moins si ce sont de bons développeurs (GIMP a presque 28 ans, mais disons qu'ils éviteront peut-être certains écueils, ne feront pas nos erreurs, etc. Je leur laisse le bénéfice du doute…). Et à ce moment là, 15 ans plus tard, ils auront accumulé leur propre dette technique inévitable. Et GIMP aussi aura évolué dans ce laps de temps. S'ils sont conscients de cela et font cela en connaissance de cause, tout ira bien. En un an ou deux, ils auront peut-être de super fonctionnalités et sûrement même des trucs qu'ils feront mieux que GIMP (ce qui est bien suffisant pour avoir des gens intéressés!). Mais ils ne seront pas aussi complet, car cela prend du temps et ne peut être qu'incrémental. Tant que les gens ne comprendront pas cela, ils continueront à se vautrer en repartant à chaque fois de zéro, dès qu'y a un petit nouveau qu'il croit qu'il fera mieux que tout le monde.
Et encore une fois, ce n'est pas impossible de refaire tout de zéro, il faut juste savoir qu'il y a un prix à payer (et ce prix peut être tout simplement 15 ans de stagnation, coincé entre le vieux logiciel qui n'avance plus techniquement et le nouveau qui fait certains trucs aussi bien, parfois mieux si on a de la chance, mais ne fait pas plein de trucs importants que faisait l'ancien).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je rebondis sur le point que tu met en rouge. Je n'ai jamais vu de documentation correctement maintenue. Du coup au lieu de rechercher une licorne, j'arrête d'essayer. On prend en entrée, le code d'avant, les tests, la doc et on fait des interviews utilisateurs1. Et on ne refait pas l'ancien mais ce dont les utilisateurs ont besoin aujourd'hui. Pour les utilisateurs ce n'est donc pas une période de stagnation, mais au contraire un moment où ils vont pouvoir exprimer leurs doléances.
ou ce qui ressemble le plus à un utilisateur le cas échéant ↩
Justement, le problème est là : le danger de reprendre le code en tant qu'entrée, c'est de persister dans des cas d'usage obsolètes, inutilement complexes (le code doit gérer tout un historique qui n'est sans doute plus nécessaire) voire faux si le code est mal compris.
Ça n'est pas une hypothèse théorique, mais un problème que j'ai constaté à chaque fois que cette idée de "repartir du code pour en tirer les règles fonctionnelles" s'est présentée.
Et donc, si la documentation fonctionnelle n'est pas à jour, la solution n'est pas de repartir du code pour la recréer (ou pire : pour s'en passer, déjà vu), mais de commencer par la refaire en partant de la source : les besoins utilisateur (ce qui est déjà documenté, ce qui savent les équipes, de nouveaux entretiens utilisateur, etc). Et créer et appliquer un processus pour maintenir cette connaissance.
J'ajoute que dans ce cas les tests fonctionnels sont une source intéressante de données, mais comme toutes les autres à prendre avec du recul, devant lesquels il faut se demander s'ils testent une règle encore pertinente ou obsolète.
Posté par barmic 🦦 .
Évalué à 3.
Dernière modification le 15 août 2023 à 12:05.
Tu prends tout ce que tu peux comme entrée, tu pondére par contre leur niveau de fiabilité. Il arrive fréquemment que les utilisateurs ne sachent pas décrire ce qu'ils font. Ils t'expliquent qu'ils cliquent sur tel bouton pour faire telle action alors que ce n'est pas ce que ça fait ou ça ne fait pas que ça mais ils se foutent de cette seconde partie qui ne les concernent pas.
Choisir d'ignorer une source d'information n'est pas responsable. Ça mène juste à reproduire les même bugs.
Évidemment qu'il ne faut pas dire amen à toutes les demandes utilisateur, c'est même écrit en toutes lettres dans mon billet… Le recueil du besoin, c'est un métier.
Sinon tu es en train de de t'énerver tout seul en surinterprétant un bout de mon billet. Le passage dont tu parles est :
Le code n’est pas une putain de documentation. Jamais.
« Regarde comment c’est fait aujourd’hui » n’est jamais une réponse valable à une question qui porte sur le fonctionnel.
Ça parle du fonctionnel, point. Le code peut être une excellente source pour retrouver un fonctionnement technique ou pour vérifier l'existant (avec toutes les limites que ce dernier point implique).
Mais le propos principal du truc, c'est surtout ça : si la seule (ou principale) source de vérité fonctionnelle de ton projet est le code, alors ton projet a un énorme problème et va droit vers des ennuis massifs.
Je ne vois pas ce qui te fais dire que je m'énerve. Je dis juste que la documentation est de mon expérience et de ce que j'ai pu voir autour de moi au mieux aussi fiable que le code. Ce n'est pas un énervement c'est juste un retour sur la partie que tu met le plus en avant de ton billet.
En fait dans mon expérience, aucune tentative de "réécriture de zéro" n'a eu un bilan totalement positif.
Je ne sais pas ce que tu entends par récrire de 0. Mais si c'est dire que l'on fait tout en un bloque ça n'a pas de sens. Sur le logiciel sur le quel je travail, nous sommes dans le cas d'une réécriture de 0, mais ça a été fait progressivement. On a pas gardé une ligne du logiciel précédent, on a même changé de langage, mais on a mis 2 ou 3 ans à mettre sur la touche de manière complète le logiciel précédent et chaque passage d'une fonctionnalité du précédent logiciel vers le nouveau était accompagné de valeur ajoutée sensible pour l'utilisateur. Non seulement les raisons de la réécriture (beaucoup plus rapide, interface revue,…) mais aussi ajouté des fonctionnalités demandées. On a jamais dis aux utilisateurs que leurs demandes allait attendre. On travaillait plus vite avec la nouvelle base de code que l'ancienne.
C'est de la conduite du changement, ça ne s'improvise pas.
Et c'est très coûteux et long. Mais effectivement le point clé c'est que c'est une problématique de changement et que ça doit se gérer en tant que tel (ne pas oublier les utilisateurs, les informer et les former, assurer une transition fluide, etc).
Mais il y a un aspect où je suis certain que les utilisateurs vont perdre et pour longtemps : toutes les petites optimisations qui sont arrivées au fil de l'eau et qui vont mettre autant de temps à revenir (curseur à l'ouverture d'un écran, priorisation des informations dans une vue tabulaire, raccourcis claviers, optimisation des copié-collé, valeurs par défaut des champs etc etc)
Pour l'expérience que j'ai tu n'avais justement pas ces choses là.
Faut comprendre que ceux qui veulent bien faire les choses, ils ne réécrivent pas un logiciel qui marchent pour le plaisir de l'aventure. Ils ont un logiciel qui a pleins de problèmes (potentiellement dont les utilisateurs sont captifs et n'ont simplement pas d'autres choix, en entreprise par exemple) et les nouvelles demandent et/ou les corrections/améliorations sont coûteuses quand elles sont encore possibles.
Pour mon cas contrairement au précédent logiciel :
on a des boutons de copie dans le presse-papiers partout où ça paraît utile même à peu d'utilisateurs
on a maintenu certaines redirections pendant une paire d'années et maintenant on fait attention que les pages soient partageables (les critères de recherche sont des query param)
on est allé voir nos utilisateurs et la plupart de leurs usages voir de leurs outil sont implémentés dans notre logiciel
évidemment les focus sont réfléchis mais c'est une toute petite partie dans nos formulaires dans les quels on a plus de champ qui n'ont pas d'explications, où ont a choisi des inputs validés par nos utilisateurs (par exemple on a un composant pour rentrer l'heure et tu peux le by passer si tu veux aller plus vite)
On a pas de raccourcis clavier, mais on stocke certains paramètres dans le localstorage pour que l'utilisateur retrouve le même état quand il reviendra.
Mais c'est une bonne idée les raccourcis, je vais regarder ce qu'on peut faire.
Ce que je voulais dire, c'est que la valeur/ qualité ressentie d'un logiciel est autant dans son "métier" de base que dans le niveau de "polish" de l'expérience utilisateur. Et ça, c'est une myriade de petites attentions qui sont bien souvent perdues lors d'une réécriture.
J'ai envie de dire que ça dépend aussi beaucoup du terminal. J'ai déjà eu à réécrire un logiciel, et une archi système en fait, de zéro, pour le boulot, parce que non il n'y avais pas le choix, le code originel n'étais ni écrit correctement, ni documenté, ni n'avais personne d'historique pour le maintenir.
L'interface en question était un écran à LEDs à l'ancienne, et un clavier du même genre. C'était sur de l'embarqué.
Quand j'ai commencé à bosser dessus, c'était pour adapter le logiciel à un PC plus classique, dalle graphique 800x600 et dalle tactile par dessus (bref, une souris).
La réécriture avais donc plusieurs buts, mais à cause de l'architecture logicielle ancienne, on ne pouvais refaire une partie aisément. A la place, je suis parti sur une archi avec plusieurs processus, programmes écrits séparément.
Certes, ça a eu un coût initial élevé, mais la différence est qu'il était possible de remplacer un seul logiciel pour une nouvelle machine, d'être plus portable en soit.
Les optimisations du logiciel originel… il aurait déjà fallu qu'il marche de manière fiable, pour en avoir.
Evidemment, ici, je ne parle pas d'un logiciel développé depuis 10 ans par des pros expérimentés… non, la base de code en question était écrite par 3 stagiaires qui se sont vaguement croisés.
Bref: parfois on y perd, parfois on y gagne, il y a un vrai travail d'analyse pour estimer la rentabilité, et on ne refais pas un truc sans, en effet, faire un minimum de doc, ne serait-ce que pour convaincre le patron!
Je ne connais pas les contraintes de X et de wayland, mais une situation où tu n'es pas en mesure de mettre dans les mains des utilisateurs une version limité de ton logiciel à court terme n'est pas une bonne solution. Ça a marché pour wayland ? Cool, mais ça a échoué pour Hurd et pour Servo. Ca aurait pu échouer pour PulseAudio et c'est une réussite en demi-teinte pour PolicyKit qui reste peu utilisé il me semble au profit des sudo/doas/etc.
Les choix de long terme sont stratégiques mais il faut prendre en compte le court terme dans cette stratégie car il (le court terme) est sur le chemin critique du long terme.
J'ai pas le sentiment que l'écriture de Wayland ait été pensée comme "X doit continuer d'évoluer en parallèle, le temps qu'on parvienne à une version utilisable de Wayland).
Je n'étais pas dans les petits papiers, j'ai vu les choses de l'extérieur mais il me semble qu'il y a eu des périodes où ni l'une ni l'autre des solutions ne convenait vraiment (je n'ai plus les sujets en tête, ça remonte à quelques temps déjà)
Pour faire une analogie, remplacer un logiciel par un autre, c'est la même problématique que de faire tangenter deux trajectoires. Ton module spatial il faut qu'il arrive sur Mars au bon endroit, au bon moment ; sachant que les deux (ton module spatial et la planète Mars) continuent d'avancer en parallèle.
Je maintiens que l'exemple wayland n'est pas pertinent.
Parce que ce qui a pêché essentiellement les premières années ne venait pas que du protocole wayland lui-même, mais aussi de l'écosystème d'applications qui l'utilise qui a pris du temps à se mettre en place.
Xorg a pourtant continué à fonctionner comme avant. Ça a mis plusieurs années avant d'avoir Wayland utilisable quotidiennement et encore plus pour voir une distribution (Fedora ?) l'adopter par défaut. Et encore je pense qu'au départ c'était Intel only.
Il me semble qu'à un moment on s'est trouvé (en tant qu'utilisateur) avec une régression des possibilités par rapport à l'accélération 3D matérielle. Genre les vieilles cartes étaient toujours supportées par X mais pas les nouvelles, et que du coup tu te retrouvais avec une expérience dégradée avec du matériel actuel (de l'époque).
C'est un souvenir vague, mais il y a eu j'en suis quasiment certain une période de no man's land (c'est pas une question de régression de X, mais de non maintien au standard en cours)
Posté par Psychofox (Mastodon) .
Évalué à 3.
Dernière modification le 17 août 2023 à 14:11.
Clairement sur ma machine pro xorg fonctionne moins bien que wayland. Par curiosité sur l'état de l'art des DE actuels, j'ai voulu passer quelques semaines sous XFCE. Si j'utilises xorg avec un écran branché sur hdmi sur mon laptop pro, j'ai régulièrement des freeze écrans dus à des erreurs du module i915. Je débranche et rebranche l'écran externe et ça repart mais j'ai finis par perdre patience et reswitcher sous gnome+wayland sur lequel je n'ai pas ces freezes.
J'ignore si ce problème est là sur une distro stable parce que de moins en moins de monde teste sous xorg où si c'est juste un glitch spécifique à ma machine, je ne suis pas encore allé jusqu'à faire un rapport de bug parce que je n'utilise plus très souvent xorg, mais ça m'a semblé étrange qu'un tel problème passe les différents filtres sur du gpu intel pourtant bien fréquent (mais relativement nouveau dans ce cas, vu que c'est du Iris Xe).
Posté par Psychofox (Mastodon) .
Évalué à 3.
Dernière modification le 15 août 2023 à 13:05.
Il n'est pas libre mais que penses tu de photopea par exemple comparé à Gimp?
Son auteur est parti de 0 il y à 9 ans. Et il est fonctionnel déjà depuis de nombreuses années pour plein d'usages. Auteur unique, à part pour les traductions, qui ne sont pas forcément complètes[1]. Il a pris le parti d'être le plus proche possible de photoshop pour avoir moins de choix et d'étude d'UX à faire pour se faciliter la vie.
[1] mais beaucoup de celles de Gimp mériteraient une refonte générale.
Posté par flagos .
Évalué à 5.
Dernière modification le 15 août 2023 à 14:19.
En fait dans mon expérience, aucune tentative de "réécriture de zéro" n'a eu un bilan totalement positif. J'ai aussi travaillé pour une startup qui a un jour décidé — il y a plus de 10 ans — de refaire tout son site en Python (parce que c'était la mode, et plus PHP qu'on utilisait jusque là! 🤦), micro-services (tout doit être en micro-services! 🖧) avec des APIs, etc. etc. On a passé 6 mois à temps plein dessus avant qu'un manager décide de tout mettre à la corbeille
J'ai eu le coup d'un projet cathédrale: un truc top qualité, des perfs incroyables, ca devait remplacer le machin tout moche existant. Le projet typique pousse par un dev tres compétent, mais nul en gestion de projet. Au bout d'un an, l'echeance etait repousse de 2. C’était bien trop ambitieux et ca n’atterrissait nulle part.
Comme le besoin était encore la, le management a reflechi comment aborder le truc: ils ont fait une architecture avec les 2 stacks, l'ancienne monolithe et la nouvelle en micro-service. L'ancienne a expose une interface pour permettre a la nouvelle de choper des données et de les distribuer en mode kafka. Et, point assez malin, la nouvelle stack n’implémentait que des nouvelles features, donc on a pu la livrer quasiment de suite.
Du coup, comme la nouvelle stack n'etait pas encore bloat en feature, on avait le temps de les faire a peu pres correctement, et petit a petit de reduire l'ancienne stack en portant les features du monolithe vers les micro-services au fur et a mesure des besoins.
Franchement, j'y croyais pas du tout, mais en 3 ans l'essentiel du boulot était migre sur la nouvelle archi, ca scalait bien et propre, et on a jamais arrete de livrer. Ca me chier de le dire, mais oui des fois l'agile ca marche.
Il ne faut pas être absolutiste. Il n'y a pas de réponse universelle à récrire ou non. Ça dépend du contexte. Mais beaucoup de situations chaotiques me semblent venir d'une méthodologie à l'emporte pièce plus qu'autre chose. Il faut souvent accepter de casser la propreté de son design initial au profit d'un passage plus progressif de l'ancien au nouveau. L'art dans ce cas là, c'est de limiter dans le temps la corruption du design.
Mais c'est une approche globale à avoir. Si déjà régulièrement (toutes les 2 semaines ? Tous les mois ?) tu te demande ce que tu a apporté de concret à tes utilisateurs, tu ne peux pas accepter d'interruption de service long…
Il y aussi des cas de réécriture partielle, comme le projet Stylo pour Firefox qui a remplacé un gros morceau avec du code Rust issu de Servo. Comme image à l'époque les dévs avaient comparé la difficulté, je crois, avec le fait de changer un moteur en plein vol !
Posté par Psychofox (Mastodon) .
Évalué à 3.
Dernière modification le 14 août 2023 à 11:25.
Mis à part le manque de support d'extensions et le fait qu'il avait crashé quelque fois, j'aimais bien le navigateur web Eolie écrit par gnumdk. Il s'intégrait très bien au bureau Gnome, contrairement à firefox. C'est bien dommage qu'il semble si compliqué de séparer le moteur quantum de firefox et son interface.
Au départ le moteur (Gecko) était bien séparé du navigateur. Mozilla a fait le choix de ne plus livrer Gecko séparément, probablement parce que ça leur simplifiait la vie pour faire évoluer l'interface entre le navigateur et le moteur, et supprimer du moteur les trucs qui ne servaient plus.
Développer un moteur séparé demande une organisation plus complexe et moins de flexibilité. Ça a été compliqué aux débuts de WebKit, le code a été forké depuis khtml et la collaboration entre les 2 projets était compliquée. Je crois que ça va mieux maintenant même si Apple a peut-être encore un role trop important (ça se corrige en contribuant plus à WebKit, à mon avis, pas en faisant un fork?)
Oui mais l'intégration de gecko dans des app tierces était compliquée de toute façon apparemment. Donc fallait améliorer ou abandonner AMHA et ça a été le 2e
Je dirais que, de nos jours, c'est plutôt blink qui est le plus maintenu, donc, pas le webkit d'apple, mais le blink de google. C'est le même problème, mais l'acteur à changé.
Normalement, si on réécrit, c'est que les techno permettent de gagner un temps important en dev, et en sûreté. On peut aussi le faire pour des raisons de gestion de dépendance.
Je suis persuadé que les techniques très récentes sont réellement inefficaces par rapport aux anciennes techniques, en terme de temps de dev. Les React, Angular, et autres, très à la mode, les IDE comme à la mode sont des régressions.
C'est très beau techniquement de faire du MVVC, mais c'est jeter l'argent par les fenêtres, et bousiller la vie de millions de dev pour rien. Je trouve cela dramatique, car tous est orienté pour subdiviser, spécialiser, augmenter les coûts et les barrières, mais sans raisons, au contraire, en augmentant la complexité, et la possibilité de résoudre des problèmes autrefois simple, proprement.
La seule chose qui compte, c'est l'UI, le thème.. En aucun cas le coût de dév. On veut utiliser du JS partout, c'est juste la pire chose à faire. Continuons, j'ai envie de dire : Merci Mozilla.. Tant pis pour le moinssage.
# Je partage les craintes de l'auteur
Posté par abbe_sayday . Évalué à 6.
Je me suis toujours demandé ce que ferait la communauté si Mozilla se cassait la gueule et qu'il n'y avait plus de Firefox. Est-ce que quelqu'un - Red Hat, Ubuntu, etc. - serait capable de reprendre le flambeau ? Est-ce qu'on finirait tous par utiliser Chrome ou un de ses dérivés libres (ex. Ungoogled Chromium) ou pas ?
C'est une chose qui risque d'arriver, surtout que 80% des revenus de Mozilla proviennent de Google. Le jour où Alphabet décidera de lui couper les vivres, c'en est fini de Firefox.
Nec spe, nec metu
[^] # Re: Je partage les craintes de l'auteur
Posté par GG (site web personnel) . Évalué à 10.
Ce serait bien dommage.
Je voudrais bien qu'on m'explique en quoi Firefox est lent.
Je trouve qu'il (avec les extensions), filtre bien les publicités et les traqueurs, et c'est quelque chose que les autres ne font pas ou font mal.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Je partage les craintes de l'auteur
Posté par abbe_sayday . Évalué à 10.
De mémoire, il y a eu une période où Firefox avait eu des problèmes de performances, mais c'était il y a des années.
Les versions actuelles sont à mon avis très performantes, sachant que j'utilise Ungoogled Chromium à côté pour certains sites incompatibles ou pour utiliser le mode application qui n'existe plus sous Firefox depuis l'arrêt de PRISM. De plus, Chromium est devenu un ogre qui dévore ma RAM comme pas possible.
Évidemment le temps de chargement d'une page peut-être un peu plus lent en activant les extensions, mais quel plaisir d'oublier les publicités, cookies de traçage et autres joyeusetés apportées par le Web moderne.
Nec spe, nec metu
# Fork
Posté par barmic 🦦 . Évalué à 10.
Trouver que la meilleure solution quand on manque de main d'œuvre est de forker me rend triste.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# mouais
Posté par fearan . Évalué à 8.
ça me rappel un projet énorme de ma boite, utilisé par plusieurs métier, qui va tranquillement sur ses vingt ans, avec son lot de dette technique. Il a été décidé de la refaire en technique moderne (micro service, web app…) des moyens colossaux ont été mis dessus pendant plusieurs années, on commence a peine à pouvoir faire une fraction de l'ancien outil, ça perd du temps en refacto, parce qu'on va pas partir en prod avec de la dette technique. Quasiment tous les devs de l'ancien sont partis vers le nouveau, y'a plus d'évolution (sauf les indispensable dans l'ancien)…
Bref si les moyens mis dans le nouveau avaient été mis dans l'ancien, qu'on avait rationalisé les inputs pour limiter le nombre de format d'entrées, on aurait pas eu cette interruption d'évolutions…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: mouais
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 10.
La réécriture est toujours un gros dilemme dans une équipe de développement. Si ça peut être évité, c'est toujours une bonne idée de faire évoluer plutôt que réécrire ; mais ça n'est parfois pas possible et souvent ça semble bien plus coûteux (ce qui est généralement faux à périmètre fonctionnel égal)
[^] # Re: mouais
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 14 août 2023 à 09:29.
Cf X.Org / Wayland par exemple
[^] # Re: mouais
Posté par yv_2000 . Évalué à 4.
Je ne comprends pas ta position. Tu veux dire que la transition valait le coup, ou le contraire ? Dans cet article, l'auteur, qui semble être familier avec Wayland (I'm no stranger to Wayland. Sway was my daily driver for many years. My primary reason for switching was merely curiosity to see what it was like. I found some things lacking, so I went and patched/fixed a few bugs), ne semble pas convaincu de l'intérêt de l'opération : Wayland Isn't Going to Save The Linux Desktop
[^] # Re: mouais
Posté par Psychofox (Mastodon) . Évalué à 8.
La comparaison ne me parait pas correcte. Wayland n'est pas une réécriture de xorg, ne prétend pas être compatible ni avoir les mêmes fonctionnalités.
[^] # Re: mouais
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Au contraire, je pense que c'est une très bonne comparaison. Il s'agit de réécrire de zéro un logiciel pour faire la même chose que l'ancien. Le fait qu'il le fasse différemment, avec des techniques modernes et des choix adaptés au monde actuel va de soi (de même que je suis sûr que c'était le cas dans l'exemple cité par fearan). On ne parle donc pas d'être "compatible" mais bien de refaire un logiciel de zéro pour les mêmes usages.
Wayland est effectivement un bon cas de "tout réécrire a foutu la merde pendant 10 ans au moins". Certes pour beaucoup de gens, Wayland est devenu utilisable, il y a quelques années déjà. Néanmoins, même pour ces personnes, cela a provoqué de nombreuses années charnières où il ne s'est rien passé dans le monde de la gestion des périphériques graphiques de sortie. Tout simplement parce qu'il n'y avait plus (ou presque) de dévs X pour développer quoi que ce soit (de nouveau, ou en correction) parce que "Wayland, c'est l'avenir".
Pendant des années, ça a donc été la merde pour la gestion des écrans haute densité (c'est pourtant loin d'être nouveau, même dans le ± grand public), dans la gestion du multi-écran, surtout avec des résolutions différentes et dans plein d'autres trucs.
Et même si maintenant Wayland est utilisable par le grand public, ça reste inutilisable pour le graphisme pro (qui est pourtant — je le rappelle — l'une des industries majeures dans les gros utilisateurs du numérique métier). On nous fait miroiter le futur avec le HDR, etc. mais la simple correction des couleurs (calibration, etc.) en SDR n'existe pas encore dans Wayland stable. Dans toutes ces années, le HDR aurait aussi pu arriver sur X11 s'il y avait encore du développement.
Et ainsi de suite.
Alors me faites pas dire ce que je n'ai pas dit. J'attends avec impatience que tout cela arrive dans Wayland, et je ne me fais aucune illusion que Wayland est le futur… parce qu'y a pas le choix et qu'on est déjà allé si loin, c'est pas comme si on allait faire un retour en arrière. Maintenant faut juste pousser pour que ces choses qui manquent (puis les nouvelles "fonctionnalités de la mort qui tue") soient rapidement implémentées. Je ne fais pas partie de ceux qui disent qu'il faut arrêter et retourner à X11. Cela ne m'empêche pas de regarder le passé et le présent avec un regard critique pour en tirer des leçons.
En fait, il fut un moment où il me semble bien que Linux commençait à avoir le vent en poupe et à être considéré de plus en plus sérieusement dans le monde du graphisme et surtout du son. Ces 2 moments critiques ont été perdus (j'ai l'impression) avec une succession de mauvaises directions techniques, même si ça revient pour le graphisme (mais pas grâce à Wayland — du moins pas pour l'instant —, surtout avec des logiciels qui commencent à prendre plus d'importance).
En fait dans mon expérience, aucune tentative de "réécriture de zéro" n'a eu un bilan totalement positif. J'ai aussi travaillé pour une startup qui a un jour décidé — il y a plus de 10 ans — de refaire tout son site en Python (parce que c'était la mode, et plus PHP qu'on utilisait jusque là! 🤦), micro-services (tout doit être en micro-services! 🖧) avec des APIs, etc. etc. On a passé 6 mois à temps plein dessus avant qu'un manager décide de tout mettre à la corbeille (on avait bien avancé, mais on était tout simplement pas au niveau de l'ancien site qui avait été construit depuis des années) et qu'on doit continuer à améliorer le vieux site à la place. J'étais l'un des seuls (voire le seul?) d'ailleurs à être contre ce projet de réécriture au début, mais ça m'a pas fait plaisir pour autant d'avoir raison. Parce que gâcher 6 mois de travail, c'est pas glop.
Pour parler de mon expérience plus au présent, tout ceux qui ont gueulé contre GIMP et ont dit qu'on peut réécrire un logiciel de graphisme en quelques années, qui serait au même niveau, se sont gaufrés. Attention, je dis pas non plus qu'il ne faut pas faire de tels logiciels. C'est d'ailleurs bien d'avoir plus de logiciels, plus de choix avec des directions et décisions différentes. Mais il faut simplement être conscient que pour en arriver au niveau de GIMP, il leur faudra 15 ans au moins si ce sont de bons développeurs (GIMP a presque 28 ans, mais disons qu'ils éviteront peut-être certains écueils, ne feront pas nos erreurs, etc. Je leur laisse le bénéfice du doute…). Et à ce moment là, 15 ans plus tard, ils auront accumulé leur propre dette technique inévitable. Et GIMP aussi aura évolué dans ce laps de temps. S'ils sont conscients de cela et font cela en connaissance de cause, tout ira bien. En un an ou deux, ils auront peut-être de super fonctionnalités et sûrement même des trucs qu'ils feront mieux que GIMP (ce qui est bien suffisant pour avoir des gens intéressés!). Mais ils ne seront pas aussi complet, car cela prend du temps et ne peut être qu'incrémental. Tant que les gens ne comprendront pas cela, ils continueront à se vautrer en repartant à chaque fois de zéro, dès qu'y a un petit nouveau qu'il croit qu'il fera mieux que tout le monde.
Et encore une fois, ce n'est pas impossible de refaire tout de zéro, il faut juste savoir qu'il y a un prix à payer (et ce prix peut être tout simplement 15 ans de stagnation, coincé entre le vieux logiciel qui n'avance plus techniquement et le nouveau qui fait certains trucs aussi bien, parfois mieux si on a de la chance, mais ne fait pas plein de trucs importants que faisait l'ancien).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: mouais
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Un gros +1 ici.
J’avais commencé à écrire un truc, et ça s’est un peu étalé, du coup j’en ai fait un billet séparé disponible ici.
La connaissance libre : https://zestedesavoir.com
[^] # Re: mouais
Posté par barmic 🦦 . Évalué à 2.
Je rebondis sur le point que tu met en rouge. Je n'ai jamais vu de documentation correctement maintenue. Du coup au lieu de rechercher une licorne, j'arrête d'essayer. On prend en entrée, le code d'avant, les tests, la doc et on fait des interviews utilisateurs1. Et on ne refait pas l'ancien mais ce dont les utilisateurs ont besoin aujourd'hui. Pour les utilisateurs ce n'est donc pas une période de stagnation, mais au contraire un moment où ils vont pouvoir exprimer leurs doléances.
ou ce qui ressemble le plus à un utilisateur le cas échéant ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouais
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Justement, le problème est là : le danger de reprendre le code en tant qu'entrée, c'est de persister dans des cas d'usage obsolètes, inutilement complexes (le code doit gérer tout un historique qui n'est sans doute plus nécessaire) voire faux si le code est mal compris.
Ça n'est pas une hypothèse théorique, mais un problème que j'ai constaté à chaque fois que cette idée de "repartir du code pour en tirer les règles fonctionnelles" s'est présentée.
Et donc, si la documentation fonctionnelle n'est pas à jour, la solution n'est pas de repartir du code pour la recréer (ou pire : pour s'en passer, déjà vu), mais de commencer par la refaire en partant de la source : les besoins utilisateur (ce qui est déjà documenté, ce qui savent les équipes, de nouveaux entretiens utilisateur, etc). Et créer et appliquer un processus pour maintenir cette connaissance.
J'ajoute que dans ce cas les tests fonctionnels sont une source intéressante de données, mais comme toutes les autres à prendre avec du recul, devant lesquels il faut se demander s'ils testent une règle encore pertinente ou obsolète.
La connaissance libre : https://zestedesavoir.com
[^] # Re: mouais
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 15 août 2023 à 12:05.
Tu prends tout ce que tu peux comme entrée, tu pondére par contre leur niveau de fiabilité. Il arrive fréquemment que les utilisateurs ne sachent pas décrire ce qu'ils font. Ils t'expliquent qu'ils cliquent sur tel bouton pour faire telle action alors que ce n'est pas ce que ça fait ou ça ne fait pas que ça mais ils se foutent de cette seconde partie qui ne les concernent pas.
Choisir d'ignorer une source d'information n'est pas responsable. Ça mène juste à reproduire les même bugs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouais
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 15 août 2023 à 13:12.
Évidemment qu'il ne faut pas dire amen à toutes les demandes utilisateur, c'est même écrit en toutes lettres dans mon billet… Le recueil du besoin, c'est un métier.
Sinon tu es en train de de t'énerver tout seul en surinterprétant un bout de mon billet. Le passage dont tu parles est :
Ça parle du fonctionnel, point. Le code peut être une excellente source pour retrouver un fonctionnement technique ou pour vérifier l'existant (avec toutes les limites que ce dernier point implique).
Mais le propos principal du truc, c'est surtout ça : si la seule (ou principale) source de vérité fonctionnelle de ton projet est le code, alors ton projet a un énorme problème et va droit vers des ennuis massifs.
La connaissance libre : https://zestedesavoir.com
[^] # Re: mouais
Posté par barmic 🦦 . Évalué à 2.
Je ne vois pas ce qui te fais dire que je m'énerve. Je dis juste que la documentation est de mon expérience et de ce que j'ai pu voir autour de moi au mieux aussi fiable que le code. Ce n'est pas un énervement c'est juste un retour sur la partie que tu met le plus en avant de ton billet.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouais
Posté par barmic 🦦 . Évalué à 5.
Je ne sais pas ce que tu entends par récrire de 0. Mais si c'est dire que l'on fait tout en un bloque ça n'a pas de sens. Sur le logiciel sur le quel je travail, nous sommes dans le cas d'une réécriture de 0, mais ça a été fait progressivement. On a pas gardé une ligne du logiciel précédent, on a même changé de langage, mais on a mis 2 ou 3 ans à mettre sur la touche de manière complète le logiciel précédent et chaque passage d'une fonctionnalité du précédent logiciel vers le nouveau était accompagné de valeur ajoutée sensible pour l'utilisateur. Non seulement les raisons de la réécriture (beaucoup plus rapide, interface revue,…) mais aussi ajouté des fonctionnalités demandées. On a jamais dis aux utilisateurs que leurs demandes allait attendre. On travaillait plus vite avec la nouvelle base de code que l'ancienne.
C'est de la conduite du changement, ça ne s'improvise pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouais
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Et c'est très coûteux et long. Mais effectivement le point clé c'est que c'est une problématique de changement et que ça doit se gérer en tant que tel (ne pas oublier les utilisateurs, les informer et les former, assurer une transition fluide, etc).
Mais il y a un aspect où je suis certain que les utilisateurs vont perdre et pour longtemps : toutes les petites optimisations qui sont arrivées au fil de l'eau et qui vont mettre autant de temps à revenir (curseur à l'ouverture d'un écran, priorisation des informations dans une vue tabulaire, raccourcis claviers, optimisation des copié-collé, valeurs par défaut des champs etc etc)
[^] # Re: mouais
Posté par barmic 🦦 . Évalué à 2.
Pour l'expérience que j'ai tu n'avais justement pas ces choses là.
Faut comprendre que ceux qui veulent bien faire les choses, ils ne réécrivent pas un logiciel qui marchent pour le plaisir de l'aventure. Ils ont un logiciel qui a pleins de problèmes (potentiellement dont les utilisateurs sont captifs et n'ont simplement pas d'autres choix, en entreprise par exemple) et les nouvelles demandent et/ou les corrections/améliorations sont coûteuses quand elles sont encore possibles.
Pour mon cas contrairement au précédent logiciel :
On a pas de raccourcis clavier, mais on stocke certains paramètres dans le localstorage pour que l'utilisateur retrouve le même état quand il reviendra.
Mais c'est une bonne idée les raccourcis, je vais regarder ce qu'on peut faire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouais
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Ce que je voulais dire, c'est que la valeur/ qualité ressentie d'un logiciel est autant dans son "métier" de base que dans le niveau de "polish" de l'expérience utilisateur. Et ça, c'est une myriade de petites attentions qui sont bien souvent perdues lors d'une réécriture.
[^] # Re: mouais
Posté par freem . Évalué à 4.
J'ai envie de dire que ça dépend aussi beaucoup du terminal. J'ai déjà eu à réécrire un logiciel, et une archi système en fait, de zéro, pour le boulot, parce que non il n'y avais pas le choix, le code originel n'étais ni écrit correctement, ni documenté, ni n'avais personne d'historique pour le maintenir.
L'interface en question était un écran à LEDs à l'ancienne, et un clavier du même genre. C'était sur de l'embarqué.
Quand j'ai commencé à bosser dessus, c'était pour adapter le logiciel à un PC plus classique, dalle graphique 800x600 et dalle tactile par dessus (bref, une souris).
La réécriture avais donc plusieurs buts, mais à cause de l'architecture logicielle ancienne, on ne pouvais refaire une partie aisément. A la place, je suis parti sur une archi avec plusieurs processus, programmes écrits séparément.
Certes, ça a eu un coût initial élevé, mais la différence est qu'il était possible de remplacer un seul logiciel pour une nouvelle machine, d'être plus portable en soit.
Les optimisations du logiciel originel… il aurait déjà fallu qu'il marche de manière fiable, pour en avoir.
Evidemment, ici, je ne parle pas d'un logiciel développé depuis 10 ans par des pros expérimentés… non, la base de code en question était écrite par 3 stagiaires qui se sont vaguement croisés.
Bref: parfois on y perd, parfois on y gagne, il y a un vrai travail d'analyse pour estimer la rentabilité, et on ne refais pas un truc sans, en effet, faire un minimum de doc, ne serait-ce que pour convaincre le patron!
[^] # Re: mouais
Posté par ff9097 . Évalué à 4. Dernière modification le 15 août 2023 à 09:44.
Et les leçons c'est quoi ? Parce que pour moi Wayland c'est une très bonne décision de long terme. Certes ce fut long et compliqué mais indispensable
[^] # Re: mouais
Posté par barmic 🦦 . Évalué à 0.
Je ne connais pas les contraintes de X et de wayland, mais une situation où tu n'es pas en mesure de mettre dans les mains des utilisateurs une version limité de ton logiciel à court terme n'est pas une bonne solution. Ça a marché pour wayland ? Cool, mais ça a échoué pour Hurd et pour Servo. Ca aurait pu échouer pour PulseAudio et c'est une réussite en demi-teinte pour PolicyKit qui reste peu utilisé il me semble au profit des sudo/doas/etc.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouais
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Les choix de long terme sont stratégiques mais il faut prendre en compte le court terme dans cette stratégie car il (le court terme) est sur le chemin critique du long terme.
J'ai pas le sentiment que l'écriture de Wayland ait été pensée comme "X doit continuer d'évoluer en parallèle, le temps qu'on parvienne à une version utilisable de Wayland).
Je n'étais pas dans les petits papiers, j'ai vu les choses de l'extérieur mais il me semble qu'il y a eu des périodes où ni l'une ni l'autre des solutions ne convenait vraiment (je n'ai plus les sujets en tête, ça remonte à quelques temps déjà)
[^] # Re: mouais
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Pour faire une analogie, remplacer un logiciel par un autre, c'est la même problématique que de faire tangenter deux trajectoires. Ton module spatial il faut qu'il arrive sur Mars au bon endroit, au bon moment ; sachant que les deux (ton module spatial et la planète Mars) continuent d'avancer en parallèle.
[^] # Re: mouais
Posté par Psychofox (Mastodon) . Évalué à 2.
Je maintiens que l'exemple wayland n'est pas pertinent.
Parce que ce qui a pêché essentiellement les premières années ne venait pas que du protocole wayland lui-même, mais aussi de l'écosystème d'applications qui l'utilise qui a pris du temps à se mettre en place.
[^] # Re: mouais
Posté par ff9097 . Évalué à 3.
Xorg a pourtant continué à fonctionner comme avant. Ça a mis plusieurs années avant d'avoir Wayland utilisable quotidiennement et encore plus pour voir une distribution (Fedora ?) l'adopter par défaut. Et encore je pense qu'au départ c'était Intel only.
[^] # Re: mouais
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Il me semble qu'à un moment on s'est trouvé (en tant qu'utilisateur) avec une régression des possibilités par rapport à l'accélération 3D matérielle. Genre les vieilles cartes étaient toujours supportées par X mais pas les nouvelles, et que du coup tu te retrouvais avec une expérience dégradée avec du matériel actuel (de l'époque).
C'est un souvenir vague, mais il y a eu j'en suis quasiment certain une période de no man's land (c'est pas une question de régression de X, mais de non maintien au standard en cours)
[^] # Re: mouais
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 17 août 2023 à 14:11.
Clairement sur ma machine pro xorg fonctionne moins bien que wayland. Par curiosité sur l'état de l'art des DE actuels, j'ai voulu passer quelques semaines sous XFCE. Si j'utilises xorg avec un écran branché sur hdmi sur mon laptop pro, j'ai régulièrement des freeze écrans dus à des erreurs du module i915. Je débranche et rebranche l'écran externe et ça repart mais j'ai finis par perdre patience et reswitcher sous gnome+wayland sur lequel je n'ai pas ces freezes.
J'ignore si ce problème est là sur une distro stable parce que de moins en moins de monde teste sous xorg où si c'est juste un glitch spécifique à ma machine, je ne suis pas encore allé jusqu'à faire un rapport de bug parce que je n'utilise plus très souvent xorg, mais ça m'a semblé étrange qu'un tel problème passe les différents filtres sur du gpu intel pourtant bien fréquent (mais relativement nouveau dans ce cas, vu que c'est du Iris Xe).
[^] # Re: mouais
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 15 août 2023 à 13:05.
Il n'est pas libre mais que penses tu de photopea par exemple comparé à Gimp?
Son auteur est parti de 0 il y à 9 ans. Et il est fonctionnel déjà depuis de nombreuses années pour plein d'usages. Auteur unique, à part pour les traductions, qui ne sont pas forcément complètes[1]. Il a pris le parti d'être le plus proche possible de photoshop pour avoir moins de choix et d'étude d'UX à faire pour se faciliter la vie.
[1] mais beaucoup de celles de Gimp mériteraient une refonte générale.
[^] # Re: mouais
Posté par flagos . Évalué à 5. Dernière modification le 15 août 2023 à 14:19.
J'ai eu le coup d'un projet cathédrale: un truc top qualité, des perfs incroyables, ca devait remplacer le machin tout moche existant. Le projet typique pousse par un dev tres compétent, mais nul en gestion de projet. Au bout d'un an, l'echeance etait repousse de 2. C’était bien trop ambitieux et ca n’atterrissait nulle part.
Comme le besoin était encore la, le management a reflechi comment aborder le truc: ils ont fait une architecture avec les 2 stacks, l'ancienne monolithe et la nouvelle en micro-service. L'ancienne a expose une interface pour permettre a la nouvelle de choper des données et de les distribuer en mode kafka. Et, point assez malin, la nouvelle stack n’implémentait que des nouvelles features, donc on a pu la livrer quasiment de suite.
Du coup, comme la nouvelle stack n'etait pas encore bloat en feature, on avait le temps de les faire a peu pres correctement, et petit a petit de reduire l'ancienne stack en portant les features du monolithe vers les micro-services au fur et a mesure des besoins.
Franchement, j'y croyais pas du tout, mais en 3 ans l'essentiel du boulot était migre sur la nouvelle archi, ca scalait bien et propre, et on a jamais arrete de livrer. Ca me chier de le dire, mais oui des fois l'agile ca marche.
[^] # Re: mouais
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
C'est la bonne strat' ça. Et ça reste long 3 ans ; les réécriture sont très souvent sous estimées par les décideurs mais aussi par les développeurs…
[^] # Re: mouais
Posté par freem . Évalué à 2.
La preuve, le dev qui a poussé le changement parlais à priori d'un an.
[^] # Re: mouais
Posté par barmic 🦦 . Évalué à 2.
Il ne faut pas être absolutiste. Il n'y a pas de réponse universelle à récrire ou non. Ça dépend du contexte. Mais beaucoup de situations chaotiques me semblent venir d'une méthodologie à l'emporte pièce plus qu'autre chose. Il faut souvent accepter de casser la propreté de son design initial au profit d'un passage plus progressif de l'ancien au nouveau. L'art dans ce cas là, c'est de limiter dans le temps la corruption du design.
Mais c'est une approche globale à avoir. Si déjà régulièrement (toutes les 2 semaines ? Tous les mois ?) tu te demande ce que tu a apporté de concret à tes utilisateurs, tu ne peux pas accepter d'interruption de service long…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mouais
Posté par antistress (site web personnel) . Évalué à 6.
Il y aussi des cas de réécriture partielle, comme le projet Stylo pour Firefox qui a remplacé un gros morceau avec du code Rust issu de Servo. Comme image à l'époque les dévs avaient comparé la difficulté, je crois, avec le fait de changer un moteur en plein vol !
# eolie
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 14 août 2023 à 11:25.
Mis à part le manque de support d'extensions et le fait qu'il avait crashé quelque fois, j'aimais bien le navigateur web Eolie écrit par gnumdk. Il s'intégrait très bien au bureau Gnome, contrairement à firefox. C'est bien dommage qu'il semble si compliqué de séparer le moteur quantum de firefox et son interface.
J'utilise sporadiquement Gnome Web / epiphany.
[^] # Re: eolie
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Au départ le moteur (Gecko) était bien séparé du navigateur. Mozilla a fait le choix de ne plus livrer Gecko séparément, probablement parce que ça leur simplifiait la vie pour faire évoluer l'interface entre le navigateur et le moteur, et supprimer du moteur les trucs qui ne servaient plus.
Développer un moteur séparé demande une organisation plus complexe et moins de flexibilité. Ça a été compliqué aux débuts de WebKit, le code a été forké depuis khtml et la collaboration entre les 2 projets était compliquée. Je crois que ça va mieux maintenant même si Apple a peut-être encore un role trop important (ça se corrige en contribuant plus à WebKit, à mon avis, pas en faisant un fork?)
[^] # Re: eolie
Posté par antistress (site web personnel) . Évalué à 3.
Oui mais l'intégration de gecko dans des app tierces était compliquée de toute façon apparemment. Donc fallait améliorer ou abandonner AMHA et ça a été le 2e
[^] # Re: eolie
Posté par freem . Évalué à 2.
Je dirais que, de nos jours, c'est plutôt blink qui est le plus maintenu, donc, pas le webkit d'apple, mais le blink de google. C'est le même problème, mais l'acteur à changé.
# Reprise de données et formation
Posté par YBoy360 (site web personnel) . Évalué à 7.
Normalement, si on réécrit, c'est que les techno permettent de gagner un temps important en dev, et en sûreté. On peut aussi le faire pour des raisons de gestion de dépendance.
Je suis persuadé que les techniques très récentes sont réellement inefficaces par rapport aux anciennes techniques, en terme de temps de dev. Les React, Angular, et autres, très à la mode, les IDE comme à la mode sont des régressions.
C'est très beau techniquement de faire du MVVC, mais c'est jeter l'argent par les fenêtres, et bousiller la vie de millions de dev pour rien. Je trouve cela dramatique, car tous est orienté pour subdiviser, spécialiser, augmenter les coûts et les barrières, mais sans raisons, au contraire, en augmentant la complexité, et la possibilité de résoudre des problèmes autrefois simple, proprement.
La seule chose qui compte, c'est l'UI, le thème.. En aucun cas le coût de dév. On veut utiliser du JS partout, c'est juste la pire chose à faire. Continuons, j'ai envie de dire : Merci Mozilla.. Tant pis pour le moinssage.
[^] # Re: Reprise de données et formation
Posté par YBoy360 (site web personnel) . Évalué à 1.
Mince, je voulais répondre au thread "Mouai", Ooops.
[^] # Re: Reprise de données et formation
Posté par xcomcmdr . Évalué à 5.
Pour rien au monde je reviendrais aux anciens IDEs, et aux anciens frameworks, anciens languages.
Ce qu'il faut c'est éviter de mettre des microservices partout.
Et oubliez les langages dynamiques, par pitié ! On peut typer les choses, on est plus en 1996 !
(chacun sa némésis :D )
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Reprise de données et formation
Posté par freem . Évalué à 2. Dernière modification le 17 août 2023 à 01:13.
La tienne, c'est le D? /me ->[]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.