Je sais pas si tu fais beaucoup de développement, mais même s'il arrive bien entendu de s'inspirer de code existant, lire du code complexe pour le réimplémenter n'a rien d'une partie de plaisir et surtout n'a rien de simple.
Très souvent, dans un cas tel que de la prise en charge de format de fichier ou de protocole, il sera même bien plus simple de faire de l’ingénierie inverse directement sur des échantillons de fichiers existants que d'essayer de lire 5000 lignes de code existant.
Le coup du "Ça existe déjà dans le logiciel libre X, pourquoi vous reprenez pas juste le code?" est probablement l'une des déclarations les plus vaines et frustrantes qu'on lit régulièrement sur le web, de gens qui ne développent pas (ou peu).
Bien sûr, l'existence de code, ça aide. Mais lire du code complexe n'est absolument pas équivalent à une spec qui dira la même chose en un paragraphe de texte simple qu'un code qui fera des boucles, des renvois en fonctions, des break, manipulera probablement des octets (on parle de données) et des bits (flags de bit, etc. typique dans les formats de fichiers), possiblement avec des optimisations de traitement super abscons et opaques qu'on doit relire 5 fois avant de comprendre ce que ça fait et dont on aura déjà oublié à moitié la logique le lendemain quand on relira le même code (et complètement une semaine après). Parce que dès qu'on se met à manipuler des octets et des bits, il y a toujours énormément de trucs super pas clairs pour permettre des optimisations en lecture-écriture (la différence entre un algorithme dit "naïf" qui est celui implémenté en premier car il paraît logique et qui est donc aussi simple à lire, et celui optimisé quand on se rend compte que son algo naïf est aussi super lent — genre 50 fois plus lent qu'un algo optimisé mais abscons — quand on doit traiter de vrais données du monde réel, donc des images super méga grosses).
Et ça c'est sans parler du fait qu'on parle d'image et de couleur, donc avec en plus de la conversion de modèles de couleur, parfois des trucs bizarres dans la gestion des canaux, etc.
une fois qu'on les a implémentées dans un logiciel libre, en quoi le caractère "fermé" des specs pourrait nuire au caractère "ouvert" du format (si on considère le JPEG-XL comme un "format ouvert") ?
Donc non, on ne peut pas dire qu'un format sans specs accessibles soit "ouvert". Une implémentation libre de specs fermées n'est pas comparable à des specs.
Et c'est sans compter qu'une implémentation peut avoir des bugs. Sans accès à la spec, si on prend pour argent comptant ce qu'une implémentation particulière fait, on peut avoir des soucis.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Format ouvert et spécifications ouvertes
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des formats d'image. Évalué à 4.
Je sais pas si tu fais beaucoup de développement, mais même s'il arrive bien entendu de s'inspirer de code existant, lire du code complexe pour le réimplémenter n'a rien d'une partie de plaisir et surtout n'a rien de simple.
Très souvent, dans un cas tel que de la prise en charge de format de fichier ou de protocole, il sera même bien plus simple de faire de l’ingénierie inverse directement sur des échantillons de fichiers existants que d'essayer de lire 5000 lignes de code existant.
Le coup du "Ça existe déjà dans le logiciel libre X, pourquoi vous reprenez pas juste le code?" est probablement l'une des déclarations les plus vaines et frustrantes qu'on lit régulièrement sur le web, de gens qui ne développent pas (ou peu).
Bien sûr, l'existence de code, ça aide. Mais lire du code complexe n'est absolument pas équivalent à une spec qui dira la même chose en un paragraphe de texte simple qu'un code qui fera des boucles, des renvois en fonctions, des
break, manipulera probablement des octets (on parle de données) et des bits (flags de bit, etc. typique dans les formats de fichiers), possiblement avec des optimisations de traitement super abscons et opaques qu'on doit relire 5 fois avant de comprendre ce que ça fait et dont on aura déjà oublié à moitié la logique le lendemain quand on relira le même code (et complètement une semaine après). Parce que dès qu'on se met à manipuler des octets et des bits, il y a toujours énormément de trucs super pas clairs pour permettre des optimisations en lecture-écriture (la différence entre un algorithme dit "naïf" qui est celui implémenté en premier car il paraît logique et qui est donc aussi simple à lire, et celui optimisé quand on se rend compte que son algo naïf est aussi super lent — genre 50 fois plus lent qu'un algo optimisé mais abscons — quand on doit traiter de vrais données du monde réel, donc des images super méga grosses).Et ça c'est sans parler du fait qu'on parle d'image et de couleur, donc avec en plus de la conversion de modèles de couleur, parfois des trucs bizarres dans la gestion des canaux, etc.
Donc non, on ne peut pas dire qu'un format sans specs accessibles soit "ouvert". Une implémentation libre de specs fermées n'est pas comparable à des specs.
Et c'est sans compter qu'une implémentation peut avoir des bugs. Sans accès à la spec, si on prend pour argent comptant ce qu'une implémentation particulière fait, on peut avoir des soucis.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]