Les bugs (failles de sécurités incluses) sont en nombre fini dans un logiciel quelconque, en les corrigeant un par un sans en introduire de nouveau, au bout d'un moment, il n'y en a plus.
Ben non, les "bugs" ça inclut les nouvelles fonctionnalités, les changements quand le compilateur change et que ça impacte ton système de build, ou que tu veux en profiter (par exemple même le support pour C90 n'est pas universel...)
Et corriger un bug sans en introduire de nouveau, c'est pas si simple que ça...
Des exemples, les logiciels triviaux : cat, rm, echo, cp, true, false...
Nom : coreutils
Version : 8.22-2
Description : The basic file, shell and text manipulation utilities of
the GNU operating system
Architecture : x86_64
URL : http://www.gnu.org/software/coreutils
Licences : GPL3
Groupes : base
Fournit : --
Dépend de : glibc pam acl gmp libcap openssl
Dépendances opt. : --
Requis par : ca-certificates linux mkinitcpio netctl util-linux
Optionnel pour : usbutils
Est en conflit avec : --
Remplace : --
Taille installé : 13388,00 KiB
Paqueteur : Allan McRae allan@archlinux.org
Compilé le : mar. 17 déc. 2013 02:59:13 CET
Installé le : lun. 06 janv. 2014 23:26:23 CET
Motif d’installation : Explicitement installé
Script d’installation : Oui
Validé par : Signature
Dans les logiciels non triviaux : un bibliothèque pour manipuler des objets X. Si elle est correcte, portable, et si ses performances sont satisfaisantes, pourquoi y toucher ?
Parce qu'on l'utilise et qu'on découvre des bugs ? Qu'on se rend compte que l'API est mauvaise ?
Qu'on veut cibler une nouvelle plateforme ?
Les autres logiciels changent, les besoins changent, les compilateurs changent, les langages changent (exemple : passage de Python2 à Python3).... Tôt ou tard, ton logiciel sera condamné à évoluer.
Sinon, des logiciels répondant à un usage précis qui ne change pas, par exemple éditer du texte, les usages n'ont pas changé depuis les les années 60
Ça dépend, si tu édites du code, on a néovim qui sort aujourd'hui encore...
il a fallut ajouter le support de l'utf-8 et autres trucs du genre, et avoir un beau système de plugin pour la prises en charge de nouveaux langages et voilà.
Tu oublies la coloration syntaxique, la documentation incorporée, le refactoring, les suggestions intelligentes, ... (pour le code)
Voire le correcteur ortographique/grammaticale (pour les trucs du genre LibreOffice Writer), l'insertion d'images/tableaux au sein du texte, le support pour l'impression, etc...
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Evolution
Posté par xcomcmdr . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 3. Dernière modification le 26 février 2014 à 22:19.
Ben non, les "bugs" ça inclut les nouvelles fonctionnalités, les changements quand le compilateur change et que ça impacte ton système de build, ou que tu veux en profiter (par exemple même le support pour C90 n'est pas universel...)
Et corriger un bug sans en introduire de nouveau, c'est pas si simple que ça...
Qui évoluent toujours.
Parce qu'on l'utilise et qu'on découvre des bugs ? Qu'on se rend compte que l'API est mauvaise ?
Qu'on veut cibler une nouvelle plateforme ?
Les autres logiciels changent, les besoins changent, les compilateurs changent, les langages changent (exemple : passage de Python2 à Python3).... Tôt ou tard, ton logiciel sera condamné à évoluer.
Ça dépend, si tu édites du code, on a néovim qui sort aujourd'hui encore...
Tu oublies la coloration syntaxique, la documentation incorporée, le refactoring, les suggestions intelligentes, ... (pour le code)
Voire le correcteur ortographique/grammaticale (pour les trucs du genre LibreOffice Writer), l'insertion d'images/tableaux au sein du texte, le support pour l'impression, etc...
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)