J'ai parcouru presque tout le journal pour voir si Ce sujet des bibliothèques et dépendances était proposé.
C'est je crois une des raisons principales de la question de la stabilité au sens large de Linux, il y a une mécanique implacable de "fuite en avant" :
Tel logiciel est nouvellement développé
il prend la dernière version la plus à jour de la bibliothèque libTartempionBleedingEdge
Une distrib qui veut mettre ce logiciel nouveau et pratique à disposition une fois qu'il commence à être connu intègre la version libTartempionBleedingEdge, dans le meilleur des cas en concurrence avec libTartempionOldSchool, si pas de conflit.
La version OldSchool est deprecated parce que plus de logiciels utilisent BleedingEdge : qui corrige des failles de sécurité et apporte des fonctions supplémentaires ET casse la compatibilité ascendante
Les logiciels sont à recompiler/migrer/retester avec la version BleedingEdge
C'est un Enorme effort qu'on fait bien seulement pour ce qu'on veut maintenir - grosso modo ce qui va être utilisé - et s'il y a des bonnes âmes
Tout le coeur vivant d'une distrib est poussé en version BleedingEdge qui poursuit sa stabilisation.
Retour à la case 1 avec la refonte d'un logiciel existant ou l'arrivée d'un nouveau (Thunderbird, Scribus, Blender, Gimp3.0 :-), etc….)
Il y a un conflit profond entre :
- Faire quelque chose de "supporté" et "maintenu" avec un engagement de sécurité de performance, etc…Dont les entreprises ont juste besoin.
- ET suivre les tendances pour innover.
Les solutions sont les suivantes pour l'auteur du journal :
- Rester sous Avoir du RedHat, c'est supporté ultra longtemps et très prudent, mais orienté entreprise et pas "user friendly" : exit pas mal de logiciels end user
- Prier pour que la promesse Ubuntu se réalise : se veut être le timing parfait de mises à jour (2 ans, version tous les ans, etc…) et de support (5 ans). C'est ambitieux mais si l'industrialisation du logiciel progresse on aura moins de bug et plus . C'est tout le sens de leur infrastructure de test (build quotidien, smoke tests, tests unitaires avec grosse couverture, etc…)
- Passer sous un OS qui fait cette promesse : MacOS ou Windows, qui quoi qu'on en dise est beaucoup plus lent à évoluer que Linux (il est vrai à cause
- Peut être passer sous Debian : je ne connais pas assez
- Monter une infrastructure ou tous les logiciels sont compilés en statique vis à vis des bibliothèques qui bougent, en dynamique vers des versions majeures qui bougent moins (LibC ? etc…). C'est plus gros mais si ça marche aujourd'hui, ça marche vraisemblablement dans 5 ans et CA COHABITE facilement.
Exemple : J'ai installé aujourd'hui même sur mon Seven du boulot graphviz, et patatra premier lancement erreur bug indescriptible avec des Assemblyx, il faut installer un package C++ version machin, je l'installe et ça marche pas…Résultat, abandon de graphviz au boulot parce qu'ils ont pas compilé le binaire Windows EN STATIQUE ou qu'ils dépendent d'un truc tiers dont ils n'ont pas la gérance….
Comment faire ? Est-ce que techniquement aujourd'hui c'est VRAIMENT possible de concevoir une bibliothèque qui résiste au temps, c'est à dire qui est extensible et dit ce qu'elle sait faire et ne sait pas faire pour pouvoir survivre plus longtemps ?
[^] # Re: If it ain't broken, don't fix it.
Posté par Xavier Verne (site web personnel) . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 2.
J'ai parcouru presque tout le journal pour voir si Ce sujet des bibliothèques et dépendances était proposé.
C'est je crois une des raisons principales de la question de la stabilité au sens large de Linux, il y a une mécanique implacable de "fuite en avant" :
Il y a un conflit profond entre :
- Faire quelque chose de "supporté" et "maintenu" avec un engagement de sécurité de performance, etc…Dont les entreprises ont juste besoin.
- ET suivre les tendances pour innover.
Les solutions sont les suivantes pour l'auteur du journal :
- Rester sous Avoir du RedHat, c'est supporté ultra longtemps et très prudent, mais orienté entreprise et pas "user friendly" : exit pas mal de logiciels end user
- Prier pour que la promesse Ubuntu se réalise : se veut être le timing parfait de mises à jour (2 ans, version tous les ans, etc…) et de support (5 ans). C'est ambitieux mais si l'industrialisation du logiciel progresse on aura moins de bug et plus . C'est tout le sens de leur infrastructure de test (build quotidien, smoke tests, tests unitaires avec grosse couverture, etc…)
- Passer sous un OS qui fait cette promesse : MacOS ou Windows, qui quoi qu'on en dise est beaucoup plus lent à évoluer que Linux (il est vrai à cause
- Peut être passer sous Debian : je ne connais pas assez
- Monter une infrastructure ou tous les logiciels sont compilés en statique vis à vis des bibliothèques qui bougent, en dynamique vers des versions majeures qui bougent moins (LibC ? etc…). C'est plus gros mais si ça marche aujourd'hui, ça marche vraisemblablement dans 5 ans et CA COHABITE facilement.
Exemple : J'ai installé aujourd'hui même sur mon Seven du boulot graphviz, et patatra premier lancement erreur bug indescriptible avec des Assemblyx, il faut installer un package C++ version machin, je l'installe et ça marche pas…Résultat, abandon de graphviz au boulot parce qu'ils ont pas compilé le binaire Windows EN STATIQUE ou qu'ils dépendent d'un truc tiers dont ils n'ont pas la gérance….
Comment faire ? Est-ce que techniquement aujourd'hui c'est VRAIMENT possible de concevoir une bibliothèque qui résiste au temps, c'est à dire qui est extensible et dit ce qu'elle sait faire et ne sait pas faire pour pouvoir survivre plus longtemps ?