Journal Linux : un vis de conception fatal ???

Posté par Samuel Pajilewski le 07 décembre 2003 à 10:36.

Étiquettes : aucune

-1

déc.

2003

Bonjour,

j'ai remarqué avec etonnement que la conception générale du système d'exploitation Linux était bancal, et celà à ma grande déception.

Je m'explique : je voulais installer un driver de carte RAID 5. Ne l'ayant pas sous un noyau 2.4.18-27, je prend donc celui du 2.4.18-14

La différence étant minime, j'étais sur que la manipulation allait fonctionner.
QUE DE NI !
Quand je fais un depmod -a, je constate avec effroi que ce module ne peut pas se charger pour question de non compatibilité.

Abasourdi, je consulte divers forums et en effet, même poue une release mineure de noyau, il faut absolument recompiler les modules pour les faires fonctionner !

Cela prouve un manque de maturité et de professionnalisme du système d'exploitation Linux. Des systèmes d'exploitations plus matures comme Windows ou Mac OS sont capables d'assurer la rétrocompatibilité. Bien sur, elle n'est pas fiable à 100%, mais quand vous prenez un driver Win 2000, vous pouvez l'installer sur un Win XP et celui ci fonctionnera d ans 95% des cas.
Pareil pour un driver MAC OS X 10.2 sur un 10.3 !

Alors pourquoi cela est impossible sous Linux . Je me le demande, je pense qu'un vis de conception se cache derriere : pourquoi modifier les APIs des drivers pour chaque correctif même quand aucun bug n'a été détecté sur celle ci ?

D'après ce que j'ai pu voir sur les Change logs du 2.6, cela n'arrangera pas les choses, bien au contraire : doit on attendre le noyau 3.0 (ou 4.0 ?) pour avoir une gestion potable des drivers ?
Je conçois qu'un driver pour le 2.4.20 ne fonctionne pas sur un 2.6.12, mais entre un 2.4.18 et un 2.4.19, quand aucune faille sur les API n'a été detectée sur le 2.4.18, il faudrait assurer la retro compatibilité !!!

Bref, c'est une grosse deception. Cela n'enleve en rien les autres qualités de Linux, mais avec cette tare, Windows a encore de longues années de tranquilité devant lui.

# Re: Linux : un vis de conception fatal ???

Posté par ckyl le 07 décembre 2003 à 10:39. Évalué à 2.

> mais avec cette tare, Windows a encore de longues années de tranquilité devant lui.

Bin t'as les sources non ? :-)
# Re: Linux : un vis de conception fatal ???

Posté par Laurent J (site web personnel, Mastodon) le 07 décembre 2003 à 10:55. Évalué à 8.

Sur le modèle des bronzés :
"t'as les sources ? t'as un compilateur ? ba tu recompiles les sources du driver !"

Blagues à part, c'est vrai que c'est pas super conviviale mais bon hein, au moins on peut résoudre le problème. Pas comme un driver qui fonctionnerai avec win2000 mais pas avec xp. Dans un cas (rare?) comme celui là, tu l'as un peu DTC...
- [^] # Re: Linux : un vis de conception fatal ???
  
  Posté par jcs (site web personnel) le 07 décembre 2003 à 11:58. Évalué à 3.
  
  au moins on peut résoudre le problème
  A condition de savoir recompiler le noyau ;o) Oui, toi tu sais le faire, moi aussi et sans doute l'immense majorité des lecteurs ici présents... Mais pas ma petite soeur avec sa Mdk 9.2 fraichement installée. Alors c'est vrai que ma soeur n'aura sans doûte pas à installer un pilote pour une carte RAID, mais le problème pourrait se poser pour une carte son, une carte d'acquisition video...
  
  Pas comme un driver qui fonctionnerai avec win2000 mais pas avec xp
  Enfin il faut relativiser tout de même. S'il faut modifier les sources, ça devient vraiment hors de portée de presque tous parce que, contrairement à la compilation, il faut là de serieuses compétences en système.
  - [^] # Re: Linux : un vis de conception fatal ???
    
    Posté par Moby-Dik le 07 décembre 2003 à 13:13. Évalué à 4.
    
    Ta petite soeur, elle installe d'autres versions du noyau que celui fourni par Mandrake ?
    - [^] # Re: Linux : un vis de conception fatal ???
      
      Posté par deftones_chris le 07 décembre 2003 à 13:45. Évalué à 4.
      
      Arrêtons la mauvaise fois... Lors de l'apparition du modem Sagem Fast800 et de l'offre de free, beaucoup de personnes ont du recompiler leur noyau car ils n'avaient pas à l'époque l'option ppoa par exemple. Ou bien encore le cas firewire qui n'était pas présent par défaut. Et pas mal de personnes qui s'y connaissaient pas trop en ont chié pour recompiler le noyau ou bien des modules. Pour un newbie, la recompilation d'un noyau se résume à un mélange de peur et d'incompréhension (à moins d'oublier ses propres débuts ;-) ).
      Et lorsque de nouveaux périphériques apparaîtront et ne seront pas reconnu avec le noyau de la mdk 9.2 mais par celui de la 2.6.x ben sa soeur devra installer une autre version du noyau. Sauf si on veut transformer les "linux users" en "windows users" dans le sens où ils ne feront que des maj/installations de nouvelles versions et deviendront dépendant d'une seule distribution.
      - [^] # on se demande qui est vicieux
        
        Posté par Anonyme le 07 décembre 2003 à 20:45. Évalué à 3.
        
        Free aurait pu fournir sur le CD des paquets rpm avec les modules pour chaque noyau actuel des distribs majeures (RedHat, Mandrake, Debian...).
        
        Ca n'aurait pas constitué une charge énorme de travail.
        
        Ce que nous raconte l'autre blagueur habituel, c'est du FUD comme d'habitude :
        - il est possible, quoique pas recommandé, de faire fonctionner des modules faits pour un autre noyau
        - il n'est pas si compliqué de trouver des solutions
        
        Par exemple, on parle souvent du fait que des boites de libre qui vivent du support : ben oui, si quelqu'un n'a pas le temps/l'envie de savoir recompiler un noyau, il peut payer quelqu'un (Mandrake par exemple) pour lui fournir des noyaux à jour en fonction des problèmes qu'il a, moyennant finances (pour ce type de cas, ça pourrait être très trivial).
        
        Bref, il n'y a ici aucun problème insurmontable, il n'y a que des solutions pour contourner cette situation technique.
        
        [^] # Re: on se demande qui est vicieux
        
        Posté par par le 07 décembre 2003 à 23:31. Évalué à 1.
        
        >... il peut payer quelqu'un (Mandrake par exemple) ...
        
        Pour de l'argent, meme une boite qui fait du proprietaire peut faire un effort... (C'est vrai que le prix a mettre ne sera pas le meme)
# Re: Linux : un vis de conception fatal ???

Posté par kolter (site web personnel, Mastodon) le 07 décembre 2003 à 10:56. Évalué à 2.

moi , j'ai cru le contraire..... dans le 2.6 ce sera possible.....

en fait t'as raison, c'est pas un système pro -> change de système.....

en fait ça ne marche pas peut être parce que ce n'est pas le même compilateur qui à compiler les 2 noyaux.......

M.
# Re: Linux : un vis de conception fatal ???

Posté par deftones_chris le 07 décembre 2003 à 11:00. Évalué à 6.

Je pense que dans ce cas, le problème de linux est qu'il ne dispose d'un HAL qui pourrait être considéré comme un bon moyen de conserver une bonne compatibilité (sauf dans le cas d'une modification des interfaces).
Concernant WinXP, je dirais que c'est le mauvais exemple car lors de sa sortie beaucoup de personnes se sont retrouvés avec du matériel pas ou mal reconnu. Ils ont dû attendre la sortie des nouveaux et dans certains cas ont dû racheter une version plus récente car le constructeur avait décidé de ne pas en faire.

Et il est vrai que compiler le kernel et/ou des modules lors de l'installation de certains périphériques peut freiner le développement de linux chez les non informaticiens. Mais si on veut que Linux soit multiplateformes, c'est le moyen le plus simple (même si de nos jours, on voit fleurir des drivers proprios exclusivement pour x86).
# Re: Linux : un vis de conception fatal ???

Posté par domi le 07 décembre 2003 à 11:14. Évalué à 2.

Service de correction automatique des titres : [actived]
s/un/une/ && s/fatal/fatale/
Ne me remercie pas, c'est tout naturel.
- [^] # Re: Linux : un vis de conception fatal ???
  
  Posté par Jake Justus le 07 décembre 2003 à 11:28. Évalué à 0.
  
  Tu n'aurais pas oublié les balises <humour> par hasard ? A mon avis, ce serait plutôt s/vis/vice/
  Pareil, c'est tout naturel
  - [^] # Re: Linux : un vis de conception fatal ???
    
    Posté par sherpa le 07 décembre 2003 à 19:16. Évalué à 3.
    
    ah bon, moi j'aurais dit
    s/vis/vit
    Quoi, vicelard, moi ?
  - [^] # Re: Linux : un vice de conception fatal ???
    
    Posté par Pierre Jarillon (site web personnel) le 08 décembre 2003 à 01:11. Évalué à 1.
    
    Un vice, c'est vicieux. La paresse est mère de tous les vices.
    
    Une vis se visse avec un tournevis.
    
    L'orthographe, ça ne sert pas qu'à embêter les gens ;-)
# Re: Linux : un vis de conception fatal ???

Posté par Yusei (Mastodon) le 07 décembre 2003 à 11:36. Évalué à 10.

«QUE DE NI !»

Knights of Nee> We shall say Nee! again to you, if you do not appease us !

(désolé)
# Re: Linux : un vis de conception fatal ???

Posté par NewLX2 le 07 décembre 2003 à 12:27. Évalué à 5.

et un "insmod -f " donne quoi ?

-f, --force
Tentera de charger un module meme si la version du noyau en
cours et celle pour laquelle le module a ete compile le module
ne correspondent pas. Ceci ne surcharge que la verification du
numero de noyau, et n'a aucun effet sur la verification des noms
de symbole. Si le nom d'un symbole du module ne correspond pas
au noyau, il n'y a aucun moyen de forcer insmod a le charger.
# Re: Linux : un vis de conception fatal ???

Posté par Mr YouP le 07 décembre 2003 à 13:16. Évalué à 7.

Très cher samuelp.

Je suis désolé de vous apprendre que vous avez échoué à votre cure de detrollification.

bon ok,
-> []
# Et pourquoi ne pas juste recompiler le module RAID ?

Posté par DPhil (site web personnel) le 07 décembre 2003 à 14:35. Évalué à 3.

A ma connaissance il n'y a qu'un noyau 2.4.18.

La je crois que tu es sous Debian et en effet, il est important de garder une dépendance entre le noyau et ses modules dans le sens ou quelque chose a pu être corriger dans le noyau et qui influe sur la compilation des modules.

Ceci étant dit, il y a une chose fantastique, c'est qu'on est pas obligé de recompiler tout le noyau pour avoir les modules.
1 - Télécharger les sources qui vont bien (2.4.18-27 dans ton cas)
2 - Configurer les sources
3 - make dep
4 - make modules
- [^] # Re: Et pourquoi ne pas juste recompiler le module RAID ?
  
  Posté par gnumdk (site web personnel) le 07 décembre 2003 à 15:24. Évalué à 1.
  
  Il y'a des cas ou tu n'a pas les sources du modules(carte sata trop recente par exemple) et t'es obligé de mettre une redhat :-/
  
  M'enfin, comme tout le monde lit les options lors d'un make menuconfig, il y' a moyen de permettre au noyau de passer outre la verification des symobles!
  
  CONFIG_MODVERSIONS
  
  Usually, modules have to be recompiled whenever you switch to a new kernel. Saying Y here makes it possible, and safe, to use the same modules even after compiling a new kernel; this requires the program modprobe. All the software needed for module support is in the modutils package (check the file Documentation/Changes for location and latest version). NOTE: if you say Y here but don't have the program genksyms (which is also contained in the above mentioned modutils package), then the building of your kernel will fail. If you are going to use modules that are generated from non-kernel sources, you would benefit from this option. Otherwise it's not that important. So, N ought to be a safe bet.
# Re: Linux : un vis de conception fatal ???

Posté par BdherVil le 07 décembre 2003 à 14:44. Évalué à 3.

Nvré mais là c'est trop affreux ...

s/Linux : un vis de conception fatal ???/Linux : un vice de conception fatal ???/g

C'est pas une vis qu'il faut resserer mais bien un vice à supprimer !
# Re: Linux : un vis de conception fatal ???

Posté par Fabien Jakimowicz le 07 décembre 2003 à 16:29. Évalué à 1.

Ben regarde dans la premiere ou deuxieme section dans la configuration de ton noyau et tu verras que tu peux avoir cette retro compatibilite.
Ensuite, tu utilises un noyau fourni par debian avec des modules externes, comment veux tu que les mecs de chez debian sachent que tu as besoin du truc bidule pour carte a faire de la lumiere par cable audio. Il y a une methode pour faire marcher a coup sur, c'est de recompiler toi meme ton noyau, ou a la rigueur de recompiler tes modules en recuperant les headers du noyau que tu utilises ...
Ensuite, je suis pas totalement sur de moi, mais on dirait que tu as utilise les binaires directement pour ton driver, donc tu ne sais pas exactement ce qu'ils contiennent et leur action sur ton systeme ...
# Re: Linux : un vis de conception fatal ???

Posté par Jllc le 08 décembre 2003 à 13:00. Évalué à 2.

Je suis assez d'accord avec Samuel. Pour moi qui a l'habitude de Linux, qui a déjà recompilé de nombreuses fois le noyau, ce n'est pas trop un problème.

Mais pour le débutant, ou celui qui veut simplement utiliser Linux sans se poser de questions, c'est un problème de devoir recompiler un noyau pour juste ajouter un pilote.

C'est d'autant plus étonnant qu'on a pas besoin de recompiler tous ses programmes chaque fois qu'on change de noyau. Les shells, les gestionnaires de fichiers, X Window, xmms et compagnie continuent de fonctionner malgré un changement de noyau. C'est p'tet parce que les fonctions fopen(), fread(), etc ... sont standards et ne changent pas. Mais pourquoi ne peut-on pas en faire autant entre le noyau et ses modules ? Au moins dans une même branche (2.2 ou 2.4 ou 2.6).
# Re: Linux : un vis de conception fatal ???

Posté par gege2004 le 26 décembre 2003 à 00:50. Évalué à 1.

Pauvre c?n, si windaube a de la "maturité", c'est parce que des gentils programmeurs se sont faits arnaqués à coder une couche d'abstraction matérielle qui assure le semblant de "rétro-compatibilité " que tu y vois ...
moi j'y vois surtout une "grande" capacité à assurer le service minimum de prise en charge du matériel ...
et si un driver 2k fonctionne sous xp, c'est parce que leur noyau n'est qu'un strap et encore.. et qu'il n'y a pas de diffs entre 2k et xp ... sauf la couleur de la barre des tâches
t'es un trolleur d'après la def !

Suivre le flux des commentaires

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