Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de cykl :
- [16/09@17:37] Portable au collège
- [04/09@22:22] GDM et multibureau
- [23/06@12:50] Migration MS Office => XXX Office
- [05/06@01:06] apt tout casse
- [10/05@16:36] Dictionnaire en ligne
- [30/03@11:17] Ecole (avis perso)
- [15/03@09:46] Déçu par KDE 3.1 et OOo
Journal : Module noyau defaut de conception ? (suite)
Posté par cykl (Jabber id, ) le 10 décembre 2003http://kerneltrap.org/node/view/1758(...)
Pour resumer linux n'est pas pres d'arriver a la cheville de Windows et Mac OS :-)))
[historique : https://linuxfr.org/~Sam_from_MS/7495.html(...)]
> Lire le journal (16 commentaires, moyenne: 1,3).
Re: Module noyau defaut de conception ? (suite)
ça n'est pas forcément une mauvaise chose ? je suis un peu d'accord avec linux sur ce point.....
en fait ça coupe en partie l'herbe sous le pied des boites qui voudraient faire des modules propriétaire qui marcherait pour un kernel précis et qui ne marcherait pas pour les suivants.... et surtout ça les oblige à être à jour (combien de boites pondent des drivers buggés une fois pour toute sans jamais les retouchés), comme ça une fois que certaines boites dévelloperons des drivers pour linux , elle travaillerons peut être plus conciensieusement et metterons à jour ......
linus explique d'après ce que j'ai compris, ce c'est une volonté de faire comme ça car si le noyau possède de nouvelles fonctionnalités et intègre de nouveaux concepts, il faudra toujours produire du code pour garder une comptailité avec les anciennes versions.... tandis que si les choses évolue (nouvelles gestion des modules ou des pilotes , que sais-je), comme on a les sources, on les mofifie pour qu'elle fonctionne avec les nouvelles versions et basta..........
c'est pour eviter une surchage de travail, et éviter de se trimballer des défauts de conception à vie ........
-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par kolter (page perso, ) le 10/12/2003 à 11:03. (lien). Évalué à 1.s/avec linux sur/avec linus sur/
-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par Laurent Mouillart (page perso, ) le 10/12/2003 à 11:11. (lien). Évalué à 0.Je suis entièrement d'accord !!! Pourquoi ne pas avoir le même type d'api / abi "mouvante" pour la glibc X gtk etc... ca permetterai d'obliger tout le monde à mettre en permanance ses logiciels à jour, et ainsi de les obliger à corriger des bugs ou erreur de conception. Quelle bonne idée :-)
-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par kolter (page perso, ) le 10/12/2003 à 11:13. (lien). Évalué à 1.c'est un peu ce qui se passe non ?
API GTK1 != API GTK2-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par Laurent Mouillart (page perso, ) le 10/12/2003 à 11:18. (lien). Évalué à 1.Non car si c'était similaire ca serai un type d'api/abi pour le kernel 1.x et un autre pour le kernel 2.x, que cela changent en permance dans tout les sens c'est stupide.
-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par kolter (page perso, ) le 10/12/2003 à 11:24. (lien). Évalué à 1.dans notre cas c'est plutot :
api/abi 2.4 != api/abi 2.6, c'est juste une diff de numérotation mais le principe est le même que pour gtk1 et gtk2, on change une grande partie de l'API pour y intégrer de nouveaux concepts qu'il serait chiant de maintenir avec l'ancienne API....-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par Laurent Mouillart (page perso, ) le 10/12/2003 à 11:37. (lien). Évalué à 1.Je ne connais pas les changements au niveau du 2.6 mais j'aurai plutot pensé 2.6 >= 2.4, donc on à une compatibilité ascendante. C'est pas le cas ?
-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par wismerhill (page perso, ) le 10/12/2003 à 16:04. (lien). Évalué à 2.Faudrait lire un minimum le lien.
Linus dit que l'ABI userland (celle utilisée par des programmes "normaux", à commencer par la glibc) doit absolument rester compatible. C'est uniquement l'ABI plus interne du noyau (pour les modules et quelques programmes étroitement liés au noyau, comme iptables) qui varie beaucoup.-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par Laurent Mouillart (page perso, ) le 10/12/2003 à 16:40. (lien). Évalué à 1.Heu je fesai des analogies , désolé si je me suis mal expliqué ou si tu les as mal compris.
-
-
-
-
-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par Yusei (page perso, ) le 10/12/2003 à 11:19. (lien). Évalué à 2.Pas vraiment, ce n'est pas parce que l'API change une fois tous les X ans qu'elle est "mouvante". Tôt ou tard, il faut accepter de casser la compatibilité, sans quoi on traine le boulet des erreurs de conceptions à vie.
La grosse différence, c'est que GTK1 et GTK2 peuvent cohabiter pendant longtemps, et ainsi n'obligent pas vraiment à effectuer la transition. Si on devait par contre avoir des copies de gtk 1, gtk 1.2, gtk 1.2.4, etc. on aurait plus de problèmes :-)
Et dans le cas du kernel, on peut difficilement en faire cohabiter deux ;-)
-
-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par Yusei (page perso, ) le 10/12/2003 à 11:15. (lien). Évalué à 1.Même qu'on pourrait changer la syntaxe des commandes Unix de temps en temps, pour obliger les administrateurs à rester à la page, et aussi forcer les développeurs de scripts shell à mettre à jour ! :-)
-
[^]Re: Module noyau defaut de conception ? (suite)
Posté par kolter (page perso, ) le 10/12/2003 à 11:16. (lien). Évalué à 1.i faut comparer, ce qui est comparable ? ne pas mélanger les serviettes et les torchons.....
-
-
-
[^]Re: Module noyau defaut de conception ? (suite)
Re: Module noyau defaut de conception ? (suite)
C'est le genre de problème qui n'aura jamais de solution et faut faire avec les choix faits. Le coup de la compatibilité apporte un plus aux utilisateurs (par exemple les possesseurs de carte graphique avec drivers proprio) car leurs pilotes fonctionneront toujours d'un noyau à l'autre. Mais cela n'apporte rien au système lui même qui est basé sur le principe de la compilation à partir des sources.
Mais d'un autre côté, certains fabriquants n'ont cure de l'open source. Nvidia et ATi font de drivers Linux pour élargir leur marchés. Ils seront donc fermés tant qu'aucune concurrence ne se fera sentir :-( Et le perdant dans cette histoire est l'utilisateur car il devient très dépendant du constructeur car seul lui peut décider de faire une release pour un nouveau noyau. Et rien n'empêche le constructeur de dire aux clients: "votre Mx 414214 n'est pas supporté par votre noyau 2.8.10 mais notre nouveau model l'est."
Cruel dilème: "favoriser l'OS ou l'utilisateur ?"
Re: Module noyau defaut de conception ? (suite)
Il me semblait que certaines personnes avait créé un wrapper de modules ...
Je sais plus ou j'ai bien pu voir cela
Re: Module noyau defaut de conception ? (suite)
j'avais ecris un bo commentaire en parlant de hurd, mais c tous perdu!
ce que je disais c'etait :
hurd/l4 et perene dans le temps , user et dev friendly!
on peut tester tous et n'importe quoi, ca doit marché au pire planté juste le module,
si tu veux tester ta pile ipv16 tu peut , et en plus ta pas bession de bidouille le noyau ni meme d'etre root, comme un simple utilistateur non experimenté peut mettre a jours son systeme ou installer un drivers d'un modem usb ou autre, c quand meme beaucoup plus simple !
alors esperont que HURD/L4 sera vite fonctionnel
hurd est a la fois modulaire au niveau source comme linux et extentions comme windows (en allant bien plus loin)
Cette page a été générée par Templeet en 0.0779s (dont 0.0061 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.