Supprime le débat binaire/libre. Le format binaire ne permet que de mettre en lumière des utilisateurs le problème.
Le seul moyen d'éviter ça serait de faire un kernel générique proposant des trucs qui ne me serviraient pas, de le mettre sur toutes les machines.
Vois pas le rapport. Je te parles uniquement de stabilité des interfaces pour faciliter le travail des développeurs de pilotes, qui sont des plus des mainteneurs que des développeurs.
"Release early. Release often. And listen to your customers." (La cathédrale et le bazar)
Et ? j'ai dis "grosses évolutions", il est donc tout à fait possible de faire des évolutions sans toucher aux interfaces, et quand l'interface doit absolument bougée (ce qui normalement ne doit pas arriver souvent lorsqu'elle est pensée), ben suffit d'en faire une nouvelle tout en gardant l'ancienne, par soucis de compatibilité.
Donc un logiciel qui t'irai bien, ça serais un logiciel contrôlé par une boite qui fait son truc dans son coin, mais qui après le publierais en libre.
Ca c'est tout ce que j'aimerai pas, et c'est Linux : si tu veux un driver non maintenu par l'équipe du kernel mais par tes propres soins, bah démerde toi pour suivre les évolutions et passe ton temps en maintenance, packaging, etc. Une seule solution viable : intégration "forcée" du pilote dans le kernel, tu n'as plus la main dessus, tes patchs seront pas forcement acceptés par la suite, etc.
Curieuse manière de reprendre les arguments formulés dans stable_api_nonsense.txt du dossier Documentation de ton kernel favori. D'ailleurs c'est un raillerie ou une tentative de discutter ?
Les 2 mon capitaine :) On me ressort systématiquement cet argument, mais je n'en ai vu aucun qui me démontrait qu'il était nécessaire de bouger systématiquement les interfaces (je parles toujours uniquement des interfaces, pas du code en soit), les OS proprio montrent clairement le contraire (que ce soit OSX ou Zindows, les interfaces de drivers changent pas tous les mois, sans que cela freine leurs évolutions).
Un aveu que le design est perfectible, nuance. En même temps, c'est plus la reconnaissance d'une loi universelle qu'un aveu à proprement parler.
Moué pas convaincu.
"Release early. Release often"
Je suis bien d'accord, mais on peut être faire exception des interfaces dont l'objectif est de s'accorder sur un protocole d'appel et donc de définir une sorte de "standard" avec un minimum de pérénité ?
C'est comme si les intefaces de programmation de n'importe quelle lib bougeait tous les jours, les libs KDE, les libs Qt, les libs Gnome, les libs nimporte-quoi. Dans toutes ces libs il y a une recherche de la stabilité et de la compatibilité. Je vois pas pourquoi le noyau Linux devrait être pris pour un cas séparé, pour moi c'est exactement le même problème.
[^] # Re: Une nouvelle très importante
Posté par TImaniac (site web personnel) . En réponse au journal Personne n'en a parlé ? Une interface driver intelligente bientôt sous Linux !. Évalué à 2.
Le seul moyen d'éviter ça serait de faire un kernel générique proposant des trucs qui ne me serviraient pas, de le mettre sur toutes les machines.
Vois pas le rapport. Je te parles uniquement de stabilité des interfaces pour faciliter le travail des développeurs de pilotes, qui sont des plus des mainteneurs que des développeurs.
"Release early. Release often. And listen to your customers." (La cathédrale et le bazar)
Et ? j'ai dis "grosses évolutions", il est donc tout à fait possible de faire des évolutions sans toucher aux interfaces, et quand l'interface doit absolument bougée (ce qui normalement ne doit pas arriver souvent lorsqu'elle est pensée), ben suffit d'en faire une nouvelle tout en gardant l'ancienne, par soucis de compatibilité.
Donc un logiciel qui t'irai bien, ça serais un logiciel contrôlé par une boite qui fait son truc dans son coin, mais qui après le publierais en libre.
Ca c'est tout ce que j'aimerai pas, et c'est Linux : si tu veux un driver non maintenu par l'équipe du kernel mais par tes propres soins, bah démerde toi pour suivre les évolutions et passe ton temps en maintenance, packaging, etc. Une seule solution viable : intégration "forcée" du pilote dans le kernel, tu n'as plus la main dessus, tes patchs seront pas forcement acceptés par la suite, etc.
Curieuse manière de reprendre les arguments formulés dans stable_api_nonsense.txt du dossier Documentation de ton kernel favori. D'ailleurs c'est un raillerie ou une tentative de discutter ?
Les 2 mon capitaine :) On me ressort systématiquement cet argument, mais je n'en ai vu aucun qui me démontrait qu'il était nécessaire de bouger systématiquement les interfaces (je parles toujours uniquement des interfaces, pas du code en soit), les OS proprio montrent clairement le contraire (que ce soit OSX ou Zindows, les interfaces de drivers changent pas tous les mois, sans que cela freine leurs évolutions).
Un aveu que le design est perfectible, nuance. En même temps, c'est plus la reconnaissance d'une loi universelle qu'un aveu à proprement parler.
Moué pas convaincu.
"Release early. Release often"
Je suis bien d'accord, mais on peut être faire exception des interfaces dont l'objectif est de s'accorder sur un protocole d'appel et donc de définir une sorte de "standard" avec un minimum de pérénité ?
C'est comme si les intefaces de programmation de n'importe quelle lib bougeait tous les jours, les libs KDE, les libs Qt, les libs Gnome, les libs nimporte-quoi. Dans toutes ces libs il y a une recherche de la stabilité et de la compatibilité. Je vois pas pourquoi le noyau Linux devrait être pris pour un cas séparé, pour moi c'est exactement le même problème.