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.
Bein, pour le coup, le fait que le format soit binaire est justement la source du problème que j'essaie de te présenter : les noyaux changent trop d'un système à l'autre pour pouvoir tous les supporter sans avoir recours à la compilation conditionelle.
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é.
Justement, l'argument des developpeurs du kernel est qu'en supprimant les API obsolètes, il empêchent les developpeurs d'utiliser les vieux paradigmes et amélliorent la qualité du noyau.
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.
Bein, pour le coup, le fait que le format soit binaire est justement la source du problème que j'essaie de te présenter : les noyaux changent trop d'un système à l'autre pour pouvoir tous les supporter sans avoir recours à la compilation conditionelle.
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é.
Justement, l'argument des developpeurs du kernel est qu'en supprimant les API obsolètes, il empêchent les developpeurs d'utiliser les vieux paradigmes et amélliorent la qualité du noyau.
Par exemple, la doc mentionne qu'ils sont passé d'un API synchrone a une API asynchrone, pour la gestion de l'usb.
Alors, oui, ils auraient pu faire un API asynchrone dès le début. À condition de savoir dès le début que ce serait le meilleur choix (d'ailleurs je ne sait pas où en est windows de ce point de vu). Et si ils ne maintiennent pas l'ancienne interface c'est paske les gens qui l'utiliseraient nuiraient au performances globales du noyau (peut être à cause du temps passé à attendre, si les I/O sont bloquantes et le kernel monolithique).
C'est pas juste une question d'API, le problème est directement lié au code du pilote. Il faut le réecrire.
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).
Heu, faut dire que j'aurais du mal à parler des évolutions du kernel windows, vu qu'y a pas de changelog. Mais à priori, le kernel Linux propose bien plus : PaX, Netfilter, la préemption plus ou moins mole, la fourniture d'une émulation wifi logicielle pour factoriser les drivers, Fuse, lm-sensors...
De l'avis de développeur du kernel, les "innovations" de la pile IP toute neuve de microsoft windows vista(tm) sont présentes depuis des lustres sous linux. http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/05/13#tc(...)
Et je suppose qu'il doit y avoir une foule d'exemples similaires (le support du "flag NX" par exemple, "nouveauté" de msw xp sp2).
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é.
Pour Qt (et GTK?) c'est diffèrent : on est pas face à un système monolithique qui, si il est mal utilisé, fait planter/ramer tout le système. Qu'une application utilise mal Qt, et elle rameras, sans faire ramer le système.
Après y'a la question de savoir si monolitique c'est bien. Pour moi oui, mais c'est un autre troll.
Du reste, les API Qt/KDE sont bel et bien mise à jour régulièrement, avec même un version majeure tout les deux ans en moyenne (4 en 8ans). Et à mon avis pas mal de changement entre temps puisque par exemple les décorateurs de fenêtre exigent souvent KDE 3.2 .
[^] # Re: Une nouvelle très importante
Posté par un_brice (site web personnel) . En réponse au journal Personne n'en a parlé ? Une interface driver intelligente bientôt sous Linux !. Évalué à 6.
Bein, pour le coup, le fait que le format soit binaire est justement la source du problème que j'essaie de te présenter : les noyaux changent trop d'un système à l'autre pour pouvoir tous les supporter sans avoir recours à la compilation conditionelle.
Justement, l'argument des developpeurs du kernel est qu'en supprimant les API obsolètes, il empêchent les developpeurs d'utiliser les vieux paradigmes et amélliorent la qualité du noyau.
Bein, pour le coup, le fait que le format soit binaire est justement la source du problème que j'essaie de te présenter : les noyaux changent trop d'un système à l'autre pour pouvoir tous les supporter sans avoir recours à la compilation conditionelle.
Justement, l'argument des developpeurs du kernel est qu'en supprimant les API obsolètes, il empêchent les developpeurs d'utiliser les vieux paradigmes et amélliorent la qualité du noyau.
Par exemple, la doc mentionne qu'ils sont passé d'un API synchrone a une API asynchrone, pour la gestion de l'usb.
Alors, oui, ils auraient pu faire un API asynchrone dès le début. À condition de savoir dès le début que ce serait le meilleur choix (d'ailleurs je ne sait pas où en est windows de ce point de vu). Et si ils ne maintiennent pas l'ancienne interface c'est paske les gens qui l'utiliseraient nuiraient au performances globales du noyau (peut être à cause du temps passé à attendre, si les I/O sont bloquantes et le kernel monolithique).
C'est pas juste une question d'API, le problème est directement lié au code du pilote. Il faut le réecrire.
Heu, faut dire que j'aurais du mal à parler des évolutions du kernel windows, vu qu'y a pas de changelog. Mais à priori, le kernel Linux propose bien plus : PaX, Netfilter, la préemption plus ou moins mole, la fourniture d'une émulation wifi logicielle pour factoriser les drivers, Fuse, lm-sensors...
De l'avis de développeur du kernel, les "innovations" de la pile IP toute neuve de microsoft windows vista(tm) sont présentes depuis des lustres sous linux.
http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/05/13#tc(...)
Et je suppose qu'il doit y avoir une foule d'exemples similaires (le support du "flag NX" par exemple, "nouveauté" de msw xp sp2).
Pour Qt (et GTK?) c'est diffèrent : on est pas face à un système monolithique qui, si il est mal utilisé, fait planter/ramer tout le système. Qu'une application utilise mal Qt, et elle rameras, sans faire ramer le système.
Après y'a la question de savoir si monolitique c'est bien. Pour moi oui, mais c'est un autre troll.
Du reste, les API Qt/KDE sont bel et bien mise à jour régulièrement, avec même un version majeure tout les deux ans en moyenne (4 en 8ans). Et à mon avis pas mal de changement entre temps puisque par exemple les décorateurs de fenêtre exigent souvent KDE 3.2 .