freem a écrit 5059 commentaires

C’est vraiment mon avis de béotien en développement logiciel que je donne là mais je trouve dommage de fermer le développement par principe. Je veux dire, c’est pas parce que tu acceptes les contributions que tu t’engages à toutes les considérer, à t’investir pour chacune.

Perso, je pense qu'il vaut mieux que les projets soient clairs sur leur politique de ce point de vue, justement pour éviter:

Alors c’est sûr qu’à un moment les contributeurs vont se dire : « Mais qu’il aille bien se faire foutre ce projet si on se casse le cul, qu’on propose des patches, et qu’on a même pas une réponse ! »

Si le projet est clair sur la politique et les objectifs, moins de frustration pour ceux qui s'en servent et ont besoin de le modifier.

La seule raison que je vois de, typiquement, garder privé les rapports de bug, c’est chercher à les dérober à la vue des utilisateurs potentiels.

Pour moi, les contributions de patch et de rapport de bug sont très, très différentes. Un rapport de bug, bien que déjà utile (enfin, ça dépend, on voit nombre de rapports de "bug" sur github ou le rapporteur a juste la flemme de lire la doc… et ne parlons pas des feature requests complètement à l'ouest…), ce n'est qu'une description d'un comportement erroné. C'est relativement rapide a faire, comparé à un patch.

La bibliothèque Fortran ForColormap permet de convertir une valeur réelle en valeurs RVB que vous pouvez utiliser avec n’importe quelle bibliothèque graphique

Donc, ça s'adresse aux développeurs fortrans qui font des applications graphiques. De cette ligne, je suppose que fortran utilise un système de couleurs propre, voire en propose plusieurs. Cet outil semble fait pour pouvoir intégrer ces divers systèmes à l'usage de gtk ou qt.

J'ai bon? (je n'ai lu que la 1ère page et je ne connais pas fortran)

Y'en a effectivement mais c'est tellement specifique au web qu'il y a pleins de logiciels qui ne le supporte pas

La question de la capacité des dev a faire la maintenance se pose, alors, parce que bon… soit on intègre tous les formats un par un, à la main, et la ça pique le coût de maintenance, forcément.

Ou alors on réfléchit 2s, et on utilise une lib dont c'est le job. Il y en existe quelques unes, moi j'en connais 2:

• libimlib2 utilisée par un tas de visualiseur d'images, justement;
• libfreeimage2 que j'ai découverte récemment grâce a TrenchBroom;

Je ne sais pas si le format JXL est supporté par elles, mais ça semblerait un bon point de pénétration, d'autant que FreeImage2 supporte un mécanisme de plugins.

En fait, webp n'est spécifique au web que dans les esprits, pour moi.
Quelle serait la raison pour que ça soit spécifique?
Qu'on me dise que DDS est spécifique aux jeux vidéo, ça, ok, c'est littéralement conçu de manière a ce que ça soit sous-optimal pour des applications graphiques qui n'ont pas autant de besoins d'upload vers la mémoire graphique (ça serait trop gros, c'est optimisé non pas pour l'espace mais pour être géré par les GPU a un coût minimal).

De fait, il y la même chose supposée ici. Enfin, on y pose la question, on n'y affirme rien, ce qui est légèrement différent du cas auquel ce message répond.

Ma fois, ce n'est pas nouveau que leur site est merdique, et je doute qu'en moyenne leur infra soit tellement mieux (la dernière fois que j'ai eu un rdv avec l'un des employés, j'ai eu un sacré ressenti que je ne voudrais pas savoir, de peur d'en avoir des cauchemars, on sentait la qualitay exsuder).
S'ils mettaient plus d'argent dans la technique et, soyons fous, le service lui-même au lieu de renommer (pour un nom qui m'évoque le régime de Pétain en plus… travaille, famille, patrie…) peut-être que ça ne serait pas arrivé, ou au moins avec des conséquences moins volumineuses.

Ah tiens, sur leur site:

Suite à une cyberattaque dont nous avons été victimes avec Cap emploi, des informations personnelles vous concernant sont susceptibles d'être divulguées. Vos informations bancaires ne sont pas concernées. Nous sommes désolés de cet incident et nous vous invitons à rester vigilants.

Donc, ça serait lié à un de leurs partenaires, en plus? Intéressant, je me demande combien des millions de victimes ont accepté que leurs données soient transmises à un partenaire commercial? (il va falloir que je lise plus en détail cette histoire)

Après, est-ce que la CNAV pourrait se contenter du n° de sécu et des dates, j'en sais rien.

Non, parce que les numéros de sécu ne sont pas uniques, les collisions sont plus que possibles.

Je pense que j'ai mal exprimé un truc. Si j'ai pris le temps de répondre, c'est déjà que je trouve la chose intéressante (j'ai pertinenté le lien de mémoire, mais je ne peux que prouver avoir voté).
Pour moi, ce site a un gros bon point: il inclue pas mal de vulgarisation sur un sujet qui semble peu connu globalement. Par exemple, pour goap, qui est je pense une avancée majeure (de 20 ans d'âge), je ne l'ai vu implémenté dans aucun jeu libre dont j'aie lu le code pour l'instant (plusieurs FPS, quelques jeux de stratégie).

Le "bof" que j'aurai clairement du lire, et relire au moins 7 fois, est… oui, je pense: mesquin.
Forcément, un titre pareil ne donne pas envie d'être poli.
Je te demande pardon.

La raison c'est que je ne voulais aucune dépendance

Mais la STL est une dépendance, régulièrement non appréciée pour diverses raisons plus ou moins valides (temps de compilation, taille du binaire notamment liée à l'obligation de supporter les exceptions ou de se passer totalement de mécanismes d'erreur, debug pénible à cause des 150 couches de template, etc)

Oui, parce que l'inférence de type c'est bien.

Discutable pour moi, mais bon.

Libre à toi de faire une PR, c'est ça aussi l'opensource.

Vu que je suis en train de bosser sur un outil pour gpgoap, justement, ça serait envisageable.
Pour les autres je vais avoir la flemme par contre, d'autant que behaviortree.cpp dispose déjà d'un tel outil.

J'ai envie de dire, prends donc un fichier avec plein de contrastes abruptes et d'autres nuancés, prends le raw, convertis le dans les divers fichiers et testes.

A la fois webp, qui me scotche déjà, et à priori JXL ont un mode de compaction lossless, avec, justement, 0 perte de donnée. Dans ce mode, ils marchent mieux en moyenne que le traditionnel jpeg, déjà.

…l'engouement de JPEG-XL. On a déjà pas mal de formats d'images modernes. Qu'apporte-t-il ?

Il apporte une meilleure volumétrie, ce qui veut dire dire moins de données à transférer via le réseau ou a stocker sur disque.
Ainsi qu'une meilleure parallélisation, ce qui veut dire que tu peux charger ou compresser plus vite. C'est utile pour un jeu par exemple, dont chaque texture est souvent un assemblage de plusieurs images, mais pour faire du montage photo, ça doit être agréable aussi d'aller plus vite.
Sans avoir de pertes supplémentaires, voire en en ayant moins.

Récemment, j'ai recompacté la totalité des cartes portées (par quelqu'un d'autre, et dont je dispose) de tremulous vers unvanquished (des jeux libres) pour l'expérience, et le gain de volume en convertissant des images vers webp, une fois tout recompacté, à été de l'ordre de 20%.
Les cartes en question on été portées à la main, sans chercher a les optimiser (ce n'est pas moi, mais je connais la personne), du coup les images originelles ont été conservée dans leur format initial, et compresser juste les tga, utilisés pour les textures, m'a fait gagner 10% de place, une fois repackagé.
Les 10% restants sont des fichiers qui ne sont plus nécessaires au fonctionnement des serveurs d'unv, qui devaient auparavant être fournis au client malgré tout.

A l'heure actuelle, mon dossier "pakpath" qui stocke les données venue du net pèse 3 giga. 20% de 3 gigs, c'est pas rien, c'est un quasi-CD-rom, et je parle de webp, à priori JXL fait mieux que webp)

Alors, je comprend que, du point de vue de l'utilisateur qui a 3 ou 4 milliers de photos, on s'en fout. Mais du point de vue de ceux qui bossent avec l'outil informatique ou l'utilise pour autre chose que les photos de vacance, ça peut vite être significatif. Je veux dire zut, le gain de compression entre png "naïf" et webp est, en pratique, d'environ 10% sur mon cas d'usage, et JXL ferais mieux en moyenne?

Vu que le sujet m'intéresse, j'ai jeté un oeil.

Pour moi, cette lib n'a que peu d'intérêt, parce que:

• C++20 obligatoire. Pas mal de codebases n'autorisent pas C++20 (pour différentes raisons. Par exemple, daemon-engine est limité à C++14 par la dépendance a google NaCl, mais on peu aussi citer recast-navigation qui se limite a C++11, pour leurs propres raisons).
• STL utilisée, et pour de mauvaises raisons en plus. La STL, c'est gros, c'est lent à compiler, c'est chiant a debugguer, le contrôle sur la mémoire est pénible. Certains par exemple y préférerons EASTL.
• la maintenance va être compliquée. Ce code utilise auto pour tout et n'importe quoi. Il y a des shared_ptr qui devraient vraiment être des unique_ptr, également.
• aucun outil. C'est bien d'avoir les briques de base, mais debugguer une IA n'est pas simple. Tant qu'a avoir des dépendances sur la STL, un outil pour charger les données depuis un stockage externe n'aurais pas été de trop. Ces données pouvant ensuite être chargées dans un programme permettant une visualisation, par exemple.

Bref, je n'ai pas en tête de lib pour remplacer tout, notamment utility et les FSM, mais à choisir: GPGOAP ou behaviortree.cpp qui dispose aussi, de mémoire, d'un outil visuel pour manipuler les BT, me semblent mieux indiqués.

A noter que je n'ai pas analysé le code de behaviortree.cpp, mais celui de GPGOAP, si.
Bien que GPGOAP ait la limitation de représenter un "worldstate" sur 64 bits seulement, en réalité 64 états c'est beaucoup.
Augmenter la taille serait simple, il suffirait d'utiliser un long double, par exemple (128 bits).
Sinon, normalement le code des IAs de F.E.A.R. est disponible, par l'auteur du concept même de goap.

Pour ce qui est des outils avec GPGOAP, il est très simple de construire un pseudo fichier de conf qui soit convertible aisément en langage dot (graphviz) pour générer un graph des actions. La lib fournit également des outils pour aider le debug.

Puis pourquoi deb? Pour moi c'est le pire système de packaging qui soit

il serait intéressant de savoir pourquoi.
Parce que perso, et il n'y a pas que moi qui le pense, le format .deb est plutôt bien ficelé, contrairement à, disons, rpm, si j'en crois l'auteur de mon lien.

Et de mon point de vue de développeur, le format .deb et les possibilités qu'il a sont complets malgré une très élégante simplicité. Je regrette juste les script pre/post-inst/rm, mais je vois pas comment faire pour automatiquement mettre à jour le menu de boot, par exemple, lors d'une install/MàJ.

Non, ça n'est pas logique. Enfin, si, mais pas tout le temps, et pas ici.

La gestion des dépendances, qui vérifie la stabilité du bouzin, elle est faite par dpkg, peu importe l'outil que tu utilises.
En fait, c'est dpkg qui fait tout le sale boulot, et c'est pour ça qu'il y a eu quelques coups de gueule pour la migration usr-merge, justement (je laisserai le lecteur intéressé faire ses recherches, possible même qu'on en ait parlé ici, je ne zone plus trop sur linuxfr, moi).

Ce qui va changer, et c'est le seul élément qui me vienne à l'esprit, c'est qu'apt-get ne sait pas se souvenir qu'un paquet à été installé automatiquement ou manuellement, donc pour le ménage, il faut utiliser debfoster, de mémoire.

En tout cas, la dernière que j'ai farfouillé dans /var/lib/apt.*, c'était le seul point que j'aie vu.

(ça ne m’étonnerait pas que ça fasse quinze ans) mais certaines accusations ont la vie dure…

Tout à fait. Mais ça ne m'empêchera pas de répéter régulièrement qu'elles sont fausses, quand je sais de première main que c'est le cas.

A ceci près que l'immense avantage d'une mailing list sur github ou gitlab, c'est que l'on n'est pas forcé d'aller voir dans sa boîte mail pour choper un code quotidien afin de se connecter.

En fait, j'en ai eu tellement marre de ça récemment que j'ai supprimé mon compte. Je ne peux plus contribuer? Pas si grave, en vrai, ce que je ne peux plus faire, c'est rapporter des bugs ou faire des push request, je suis toujours capable, bien entendu, de faire le code, et je peux même upload sur des forges saines d'esprit si besoin est.

J'ai d'ailleurs appris ainsi que github remplace les identités supprimées par "ghost", et je soupçonne qu'ils conservent des stats, puisque le compte de ghost a des "badges" qui sont peut-être proche de ceux que j'avais. Bon, je l'avoue: je m'en contre-fout des badges. J'aurai préféré à la place qu'ils implémentent des fonctionnalités utiles… je sais pas, moi, par exemple un truc pour m'identifier via ma clé ssh publique, sans me pourrir ma boîte mail, par exemple?

J'ai vu au moins un projet qui s'est barré de github pour la même raison, le mainteneur en a eu marre de cette connerie de "double authentification" forcée.
Comme quoi, tout le monde ne suit pas le mouvement. Par contre, le mainteneur à malheureusement préféré savannah, qui est la forge la plus pourrie que je connaisse. Oui, j'ai essayé, j'y avais même un compte, fut un temps.
Ceci dit, il n'a manifestement jamais montré le bout de son nez, et sa soumission a été rejetée. Parce que tout projet qui y va doit être libre, et donc les licences sont vérifiées. En soit, c'est plutôt bon, mais perso, lire un truc comme ça:

3) The following files are missing a copyright notice:

credits.md
quick-start.sh
README.md
release_notes.md
cat6/README.md
labs/README.md
man6/README.md
sounds/README.md

ca me ferait juste fuir de n'importe quelle forge. Mettre le copyright sur le readme, franchement… bref, je suis très bien sur codeberg, moi.

Ou alors on peut se souvenir qu'en théorie, la rubrique "liens" devrais respecter la ligne éditoriale?

La rubrique « liens » est destinée à recevoir les euh… liens vers des contenus en rapport avec la ligne éditoriale de LinuxFr.org.

A ma connaissance, la politique en dehors des problématique de propriété intellectuelle n'en fais pas partie. Mais bon, peu importe (j'ai pas voté^W noté de toute façon).

Je crois me souvenir d'une époque où l'on disait qu'il ne fallait pas installer un truc avec aptitude si tu en avais installé d'autres avec apt ou apt-get (souvenir flou) et je n'ai jamais vraiment compris la logique.

Oula, c'est vieux, ça!

Personnellement, depuis que j'utilise debian (environ 15 ans) j'ai toujours mixé aptitude et apt (anciennement apt-get) pour faire les choses, et je n'ai jamais eu le moindre problème. Pas un seul. J'insiste. Lourdement. Parce que c'est vrai!

Ceci dit, j'utilise majoritairement aptitude, qui est incomparable. C'est d'ailleurs l'outil qui m'empêche de bouger de debian, parce qu'avoir une interface ncurses pour installer des paquets, c'est juste logique: c'est utilisable via ssh, et c'est plus efficace qu'enchaîner des commandes.

Ouais je sais que je renforce le mème "BTW I use Arch" mais franchement sa réputation de complexité est exagérée, je la trouve finalement plus simple à maintenir qu'une Debian ! KISS.

Bon, qui se dévoue pour faire un vrai site de comparaison? Pas moi en tout cas, j'ai trop la flemme :D (y compris pour déterminer ce qu'il faut comparer et comment)

il faut bien avouer que Hadley Wickham a tendance à devenir le Lennart Poetterirng de R.

ben, du coup, il faudrait plutôt mettre son travail par défaut sur toutes les distro, non?

Mais bon sérieux… ce pauvre Lennart n'a fait que filer le source des logiciels qu'il utilise ou écrit pour une boîte, je trouve ça méchamment dégueulasse de le considérer comme un type qui planifie la fin du libre ou je ne sais quelles autres âneries.

Je n'utilise pas son travail (systemd, pulseaudio, etc) pour des raisons à moi, mais je lui suis redevable parce qu'il augmente l'intérêt économique de linux, ce qui crée un petit effet boule de neige, et est donc en ma faveur.

C’est une force incroyable (et qui se basse sur le travail des centaines de packageurs Debian).

Juste des centaines? Mince, vu le boulot, j'aurais imaginé des milliers moi…

Le contre-coup de cela c’est que si un logiciel, aussi populaire soit-il, n’intéresse aucune développeur Debian, alors il ne sera pas dans Debian. Ça arrive assez régulièrement. Y’a pas ce problème avec AUR

Ben, debian est assez centralisée je pense, c'est une belle (magnifique, même) cathédrale libre.
Par contre, il est aussi à noter, je crois, qu'il est possible de publier des dépôts debian pour ses propres paquets, c'est ce que faisais Opera (jusqu’à la 12, je sais pas après), ce que fait nvidia, et ce que fait vivaldi, ce que fait wine!
Dans le cas de vivaldi et opera, franchement, ils pourraient juste éjecter FF et chromium de debian, vu que "le web" et "stabilité" sont antinomique mais bon, avoir des utilisateurs est aussi important pour changer le monde.
On pourrait me dire que tous ces paquets (sauf wine) sont non-libre, mais bon, debian à une section pour le non-libre de toute façon (autrement dit, pas de zélotes, jalous, zélés. C'est l'origine du mot zélote apparemment.)

Je ne connais pas les process d'arch, alors je ne peux pas juger entièrement, mais dans l'ensemble, arch me semble plus orientée travail communautaire que Debian, qui est plutôt du genre a encourager le travail rigoureux et long (ce qui en fait une distro fiable sur le long terme, donc pour construire un système informatique pérenne). Je pense que arch est pertinente pour les gens qui aiment la tech, et encore, juste une portion d'eux (je me considère comme aimant la tech, mais pas arch :))

PS: le correcteur orthographique sur vivaldi est vraiment pourri. Mais bon, linuxfr a le sien, ça aide, multiplier les couches est une bonne solution pour éviter les bugs… sauf quand ça les encourage. Bref, j'en sais rien.

Étonnamment, les gens refusent de le faire mais vont ailleurs et ne font que ça…

Le problème, c'est que modifier un paquet Debian requiert une chiée de paquets à installer (debuild & consort) et le process est loin d'être simple.
Moi-même, j'ai plusieurs paquets recompilés pour exclure des dépendances stupides fonctionnalités que je n'utilise pas, genre dbus, systemd, wayland, et j'en oublie.
Le résultat final est un système allégé de plusieurs pourcents de paquets, et donc, il est plus simple de lire les release notes, vu qu'il y en a moins.

Non, je n'ai rien contre wayland, dont l'architecture me semble plus sensée que celle de Xorg, mais ça n'empêche pas que j'utilise Xorg parce que:
1. ça juste marche;
2. j'y ai tous les logiciels dont j'ai besoin;
3. il y a de la doc;
4. il y a de vraies lib de dev officielles, contrairement à wayland qui génère des trucs basés sur un fichier xml, et quand j'avais regardé, le résultat était plutôt… disons juste que, moi, j'aurai honte de produire ça.

Par contre, l'architecture logicielle de wayland, du peu que j'en sais, me semble largement meilleure que celle de Xorg (et ce défaut me semble être un défaut d'implémentation, pas de standard) vu qu'elle respecte la séparation des privilèges.

Bref, je sujet, c'est la recompilation de paquets debian pour soi-même, et clairement sur ce point, Debian est franchement pourrie.
Entre la chiée d'outils dont on n'est jamais sûr lesquels sont vraiment utiles, ou quel est leur rôle, la fâcheuse habitude de tout activer par défaut (y compris dbus sur sdl, qui était désactivé par défaut upstream je crois, et qui a généré d'énormes problèmes de performances. Bon, d'un autre côté, il faut ne pas regarder de trop près le code pour avoir confiance en la SDL…), les dépendances de ces outils qui semblent au final tirer tout ce qui existe dans debian (mettons du perl, du python, du autotools, et 2-3 autres tech, histoire que ça soit une grosse galère à gérer, c'est plus fun!).

Le processus pour compiler un paquet custom pour soi-même est également pollué par toutes les règles de Debian dont l'objectif est de partager des paquets de qualité.
La réalité, c'est qu'il est 20 fois plus simple d'écrire un script qui génère un paquet binaire à partir de l'exécutable qu'un paquet source. Il serait bon que cet élément soit clairement affiché quelque part, et moins découragé (sauf que bien sûr, le but de Debian est de partager les efforts, et d'avoir un maximum de logiciels libre, donc faire apparaître comme compliqué la création d'un dépôt Debian avec des paquets non source me semble pas déconnant comme stratégie, sauf que ça impacte aussi les logiciels libres moins connus).
J'ai personnellement écrit un script qui génère des paquets .deb pour une boîte dans le passé (donc, on compilait, puis on lançait cet outil pour générer un .deb, que l'on pouvais ensuite répartir et installer sur les systèmes distants), à partir d'une recette minimaliste et des binaires. A cause du faible niveau d'expertise de mes collègues, j'ai du lui donner une interface simple, et une documentation qui tienne la route, sur plusieurs degrés (utilisateur et mainteneur, concrètement, je savais sûrement que je n'allais pas passer ma vie a bosser pour cet empaffé).
Comparé à ça, tous les systèmes de paquets me semblent franchement complexes, et c'est normal: ils gèrent bien plus de cas! C'est incomparable, gérer un parc de moins de 300 machines produites par nous et réparties aléatoirement sur le territoire français ou gérer un parc de plusieurs millions de machines dont aucune n'est identique?

Bon, ok, donc, les paquets source c'est compliqué, très bien, et ça sera jamais simple de toute façon (entre la quantité de langages de prog et de compilos pour chacun…), mais j'aimerai que Debian fournisse un paquet qui permette de construire des paquets binaires sans se prendre autant la tête.

Au fond, ce n'est pas si compliqué, un paquet binaire: il faut juste définir quels paquets doivent être installés, les scripts d'installation et de suppression, que je considère comme étant plutôt une erreur d'architecture logicielle de Debian (leur rôle est surtout d'activer le démarrage automatique des services, désolé, mais je m'en passerai bien) et tout fonctionne assez simplement.

Concrètement, un .deb, c'est une tarball qui contiens 3 fichiers:

1. un fichier qui décrit la version du format
2. une archive qui contiens les données à installer
3. une archive qui contiens les méta-données, c'est à dire la description du paquet (ou sa traduction), la place requise, les dépendances, etc.

Pour le point 2, il me paraît utile de préciser que cette archive ne contiens qu'un seul fichier qui a besoin d'être écrit par l'utilisateur, et le format est dérivé du stockage des mails, donc, c'est du du texte pur, très simple à manipuler, il est possible (je l'ai fait) de se bricoler des scripts awk qui gèrent ça très facilement (je ne sais pas garder d'info d'une ligne à l'autre via sed).

Merde, j'ai encore écrit un pavé qui n'intéressera pas grand monde… Désolé pour ça (en admettant que des gens lisent ça)

Il faut garder à l'esprit que le mariage est (ou au moins a été) un outil pour acquérir la citoyenneté et est donc monnayable.

Et c’est bien là tout le problème : ce ne sont pas plus les clients ou les employés d’Elon MUSK qui choisissent ce que Tesla va produire. C’est Elon Musk.

Ben tiens. Et il sert à quoi le service marketing alors? Les commerciaux, ces gens qui vendent du rêve et dont le travail consiste à créer le besoin, et qui déclenchent ensuite la R&D pour y répondre, ils ne sont pas salariés?
Et les ingés de la R&D, ils ont le pistolet sur la tempe peut-être?

Pour ce qui est des consommateurs, désolé mais si, ils ont demandé, après un éventuel bourrage de crâne soit par le marketing, soit par leur cercle de connaissances, à avoir un truc qui impressionne.

Le tort est partagé, très clairement, et je doute qu'il y aurait production de masse s'il n'y avait pas achat.

Mr. Musk ne peut pas être derrière chacun de ses employés, dans le meilleur des cas il peut juste donner les grandes lignes.

Mais oui sudo-rs supporte surement déjà plus d'option que doas, surtout qu'il se veut un "drop-in" remplacement

Non, ce n'est pas un drop-in, sinon il devrais tout implémenter, hors:

Leaving out less commonly used features so as to reduce attack surface

Le soir, les volants - très lourds et qui ont donc une inertie conséquente - vont faire tourner des dynamos pour restituer l'énergie cinétique stockée sous forme d'électricité.

Et la nuit, un incendie se déclare (ou une inondation, ou…) . Les volets très lours, ils sont aussi très solides? Parce que si oui, les débrayer ne servira à rien. Espérons que les autres accès ne sont pas bloqués.

(chacun sa némésis :D )

La tienne, c'est le D? /me ->[]

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

La preuve, le dev qui a poussé le changement parlais à priori d'un an.

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!