Excuse-moi pour le message précédent, je vais la refaire plus calme :
Merci, c'est beaucoup plus intéressant comme ca en plus ;)
Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.
Toutafé :)
jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur.
Je n'employais pas le terme utilisateur au sens séparation espace noyau/espace utilisateur, mais au sens utilisation : le kernel offre des services et des points d'entrée pour s'interfacer avec lui. Pour moi les drivers sont un moyen d'utiliser le kernel (et réciproquement) au même titre que POSIX (même si c'est pas du tout le même cadre d'utilisation), les drivers ne doivent pas être "fagocités" par le kernel.
Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.
La stabilité de l'API constitue également une qualité. Il y a pleins de choses qui font qu'une brique logicielle est de qualité : qualité du code, qualité de la documentation, qualité de la conception, etc. J'ai essayé d'expliquer que des API non stables peut être véritablement handicapant, que ce n'est pas une simple question de compatibilité avec le proprio, que c'est un problème de qualité plus général.
D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ?
Oui, en parrallèle. On met en place un groupe "d'architecte" qui concoivent une API pensée avec les technos d'aujourd'hui et celle de demain, on fait un truc "propre" avec une certaine durée de vie. Et surtout on s'arrange pour que ca soit facile à "échanger" contre un nouvel API dans le futur, car c'est évident que le boulot devra être refait dans plusieurs mois/années. Si c'est bien foutu, on pourra créer une nouvelle version de l'API plus tard, migrer ceux qui sont important, et garder la compatibilité avec l'ancien. Un peu comme de nombreuses bibliothèques au niveau applicatif. Ca marche très bien, on conserve la compatibilité avec les "vieux" trucs qui personne ne veut plus toucher (le plus souvent "parceque ca marche") et de l'autre on propose du neuf.
Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ?
Fut un temps ma clé USB était reconnue. Puis pouf plus reconnue. 1 an après re-reconnue. Relou. Pareil pour ma carte son, fut une époque où la sortie numérique fonctionnait, plus maintenant. Tu me diras sur ce coup je suis pas sûr, ca vient peut être du serveur de son qui a changé, je sais pas trop à quel niveau ca se passe ca.
.. alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes
C'est pour ca que dire "on a les sources, c'est pas proprio, ca va évoluer avec le noyau", c'est illusoire. C'est pareil dans le monde proprio, les vieux trucs qui deviennent "anonymes" ne sont plus maintenu par manque d'intérêt de la part des dev. Et c'est pour ca que j'aimerai bien que les API restent stables pour que je puisse garder mon vieux driver-qui-marchait plutôt que de le voir évoluer vers le néant.
oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".
J'ai bien entendu forcé le trait. Mais l'idée est là : les dev du noyau veulent fagociter un maximum de chose, ils promettent le support du vieux matos mais le résultat n'est pas forcement là, et ca se comprend aisement. Et je suis près à parier que plus la base de driver va grossir, et plus on aura de problèmes.
Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes
Toutafé. Et moi en tant qu'utilisateur je constate parfois les "dégâts". Et j'ai la chance en tant que développeur de comprendre le contexte et le pourquoi du problème, et c'est pour ca que je gueule :)
Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter.
Toutafé. Mais moi je dis que y'a d'autres manière de "s'adapter" à mon sens.
Sinon je plussois toute la fin de ton commentaire ;)
Moi ce que je trouve dommage c'est qu'un des problèmes majeurs de Linux est le support du matos, à cause du manque de disponibilité de doc de la part des constructeurs. J'ai l'impression qu'on ne fait rien pour mettre en évidence les avantages de drivers libres, à savoir la pérennité dans le temps, la réutilisation, toussa, et c'est bien dommage.
Pfff, vivement le Hurd ;)
[^] # Re: Faut pas exagerer...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 3.
Merci, c'est beaucoup plus intéressant comme ca en plus ;)
Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.
Toutafé :)
jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur.
Je n'employais pas le terme utilisateur au sens séparation espace noyau/espace utilisateur, mais au sens utilisation : le kernel offre des services et des points d'entrée pour s'interfacer avec lui. Pour moi les drivers sont un moyen d'utiliser le kernel (et réciproquement) au même titre que POSIX (même si c'est pas du tout le même cadre d'utilisation), les drivers ne doivent pas être "fagocités" par le kernel.
Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.
La stabilité de l'API constitue également une qualité. Il y a pleins de choses qui font qu'une brique logicielle est de qualité : qualité du code, qualité de la documentation, qualité de la conception, etc. J'ai essayé d'expliquer que des API non stables peut être véritablement handicapant, que ce n'est pas une simple question de compatibilité avec le proprio, que c'est un problème de qualité plus général.
D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ?
Oui, en parrallèle. On met en place un groupe "d'architecte" qui concoivent une API pensée avec les technos d'aujourd'hui et celle de demain, on fait un truc "propre" avec une certaine durée de vie. Et surtout on s'arrange pour que ca soit facile à "échanger" contre un nouvel API dans le futur, car c'est évident que le boulot devra être refait dans plusieurs mois/années. Si c'est bien foutu, on pourra créer une nouvelle version de l'API plus tard, migrer ceux qui sont important, et garder la compatibilité avec l'ancien. Un peu comme de nombreuses bibliothèques au niveau applicatif. Ca marche très bien, on conserve la compatibilité avec les "vieux" trucs qui personne ne veut plus toucher (le plus souvent "parceque ca marche") et de l'autre on propose du neuf.
Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ?
Fut un temps ma clé USB était reconnue. Puis pouf plus reconnue. 1 an après re-reconnue. Relou. Pareil pour ma carte son, fut une époque où la sortie numérique fonctionnait, plus maintenant. Tu me diras sur ce coup je suis pas sûr, ca vient peut être du serveur de son qui a changé, je sais pas trop à quel niveau ca se passe ca.
.. alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes
C'est pour ca que dire "on a les sources, c'est pas proprio, ca va évoluer avec le noyau", c'est illusoire. C'est pareil dans le monde proprio, les vieux trucs qui deviennent "anonymes" ne sont plus maintenu par manque d'intérêt de la part des dev. Et c'est pour ca que j'aimerai bien que les API restent stables pour que je puisse garder mon vieux driver-qui-marchait plutôt que de le voir évoluer vers le néant.
oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".
J'ai bien entendu forcé le trait. Mais l'idée est là : les dev du noyau veulent fagociter un maximum de chose, ils promettent le support du vieux matos mais le résultat n'est pas forcement là, et ca se comprend aisement. Et je suis près à parier que plus la base de driver va grossir, et plus on aura de problèmes.
Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes
Toutafé. Et moi en tant qu'utilisateur je constate parfois les "dégâts". Et j'ai la chance en tant que développeur de comprendre le contexte et le pourquoi du problème, et c'est pour ca que je gueule :)
Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter.
Toutafé. Mais moi je dis que y'a d'autres manière de "s'adapter" à mon sens.
Sinon je plussois toute la fin de ton commentaire ;)
Moi ce que je trouve dommage c'est qu'un des problèmes majeurs de Linux est le support du matos, à cause du manque de disponibilité de doc de la part des constructeurs. J'ai l'impression qu'on ne fait rien pour mettre en évidence les avantages de drivers libres, à savoir la pérennité dans le temps, la réutilisation, toussa, et c'est bien dommage.
Pfff, vivement le Hurd ;)