Journal Module noyau defaut de conception ? (suite)

Posté par ckyl le 10 décembre 2003 à 11:44.

Étiquettes : aucune

-1

déc.

2003

En passant sur kerneltrap je suis tombe sur quelque chose de plutot interessant :
http://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(...)]

# Re: Module noyau defaut de conception ? (suite)

Posté par kolter (site web personnel, Mastodon) le 10 décembre 2003 à 12:02. Évalué à 4.

ç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 (site web personnel, Mastodon) le 10 décembre 2003 à 12:03. Évalué à 1.
  
  s/avec linux sur/avec linus sur/
- [^] # Re: Module noyau defaut de conception ? (suite)
  
  Posté par Laurent Mouillart le 10 décembre 2003 à 12:11. É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 (site web personnel, Mastodon) le 10 décembre 2003 à 12:13. É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 le 10 décembre 2003 à 12:18. É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 (site web personnel, Mastodon) le 10 décembre 2003 à 12:24. É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 le 10 décembre 2003 à 12:37. É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 le 10 décembre 2003 à 17:04. É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 le 10 décembre 2003 à 17:40. É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 (Mastodon) le 10 décembre 2003 à 12:19. É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 (Mastodon) le 10 décembre 2003 à 12:15. É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 (site web personnel, Mastodon) le 10 décembre 2003 à 12:16. É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)
  
  Posté par ckyl le 10 décembre 2003 à 12:33. Évalué à 1.
  
  Puisque ca n'a pas l'air d'etre clair, ma remarque etait ironique et en rapport avec le journal précédent.
  
  Je suis a 99,65% d'accord avec linus la dessus.
# Re: Module noyau defaut de conception ? (suite)

Posté par deftones_chris le 10 décembre 2003 à 14:04. Évalué à 1.

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)

Posté par Prae le 10 décembre 2003 à 15:08. Évalué à 1.

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)

Posté par Sébastien TeRMiToR le 10 décembre 2003 à 16:35. Évalué à 1.

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)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.