API

• [^]Re: API

  Posté par dripple () le 16/04/2008 à 15:23. (lien). Évalué à 0.

  Toi tu devrais faire un peu plus souvent un
  
rm -rf /temp/*

  
  -->[ ]

  [^]Re: API

  Posté par IsNotGood () le 16/04/2008 à 15:29. (lien). Évalué à 1.

  Linux n'est pas un produit mais un projet. Un projet avec une communauté de développeur qui ne vont pas stopper le boulot pour faire plaisir à telle ou telle boite.
  
  Si tu veux que l'API ne bouge pas, utilise RHEL (7 ans de compatibilité source et binaire).
  
  > Si c'est le cas j'en déduis que vmware doit tout le temp suivre ces changement si il veut avoir un kernel relativement récent.
  
  Ce n'est pas un vrai problème. VMware a décidé d'être impliqué dans le *projet* Linux. Donc il participe aux discussions de concèption, il est en contact avec les développeurs, etc. C'est un plus pour VMware. Si VMware était concentré sur RHEL, ben là il n'y a presque plus rien à discuter. Et si VMware demande de gros changements à RHEL, Red Hat va envoyer VMware chez Fedora ou mieux chez Linux upstream.
  
  > Si c'est le cas c'est quand même un réelle perte de temp
  
  La perde de temps c'est se refuse tout changement d'API. Car Linux ne s'impose pas cette contrainte, il évolue très vite.
  
  > l'utilisation de BSD plutot que de linux.
  
  Le monde est injuste et BSD incompris.
  
  > Apple a bien joué sur ce coup là.
  
  Apple vend un produit.

  [^]Re: API

  Posté par PsychoFox () le 16/04/2008 à 15:45. (lien). Évalué à 5.

  J'ai cru comprendre (je ne suis que de loin ce point, et mes compétences en developpement kernel sont plus que limité), que l'api du kernel avait tendance à changer tout le temp.
  
  Si c'est le cas j'en déduis que vmware doit tout le temp suivre ces changement si il veut avoir un kernel relativement récent.
  
  
  vmware se base encore sur la version 2.4 de linux. Ils ne sont donc pas directement atteints par les changements d'API incessants. Je pense que tant qu'ils n'en ont pas besoin pour une question de support hardware, ils ne passent pas à une version plus récente et se contentent de patcher les éventuels trous de sécu (et encore quand on voit l'attitude de certaines boites qui font du proprio...).

  [^]Re: API

  Posté par GeneralZod () le 16/04/2008 à 15:50. (lien). Évalué à 2.

  Les légendes urbaines ont la vie dure.
  Il faut distinguer deux API dans le noyau Linux:
  * les appels systèmes (kernel <-> userspace) utilisé par les programmes et qui est relativement stable.
  * les appels internes au noyau Linux. Greg Kroah-Hartman l'explique très sur cette page (http://www.kroah.com/log/linux/stable_api_nonsense.html), c'est de la connerie. Si on veut faire une API stable, ça veut dupliquer les API (et risquer que les pilotes continuent à utiliser des API bogués), parfois il est impossible de corriger une faille de sécurité sans casser l'API.
  Quant ton module est dans l'arbre des sources du noyau, il est automatiquement corrigé, si il ne l'est pas comme le module VMWare, bah, c'est à eux de le réparer.
  Donc la vraie perte de temps, c'est d'avoir mis ce putain de module sous licence propriétaire et de ne pas l'avoir inclus dans l'arbre.
  De plus, pour la plupart des modules, les changements sont quasiment invisibles.
  
  Apple n'a pas un noyau dérivéde BSD, mais un noyau hybride XNU basé sur:
  * un micro-noyau Mach.
  * une couche de compatibilité BSD offrant une interface de programmation UNIX classique.
  * l'I/O Kit: un framework (libre au passage) permettant d'écrire des pilotes matériels utilisant un dialecte C++ (de l'embedded C++, du C++ sans héritage multiple, exceptions, RTTI, templates etc ...)
  
  Si l'API pour la programmation de pilotes pour XNU est stable, ce n'est pas grâce à BSD mais à l'I/O Kit.
  De plus, XNU est un noyau à moitié mort avec des perfs merdiques comparés à Linux.

  • [^]Re: API

    Posté par Aurélien Girard () le 16/04/2008 à 18:22. (lien). Évalué à 2.

    De plus, XNU est un noyau à moitié mort avec des perfs merdiques comparés à Linux.
    
    <mode="BeOS forever">C'est rigolo mais BeOS aussi avait un noyau tout lent à coté du Linux de l'époque. Ca ne l'empêchait pas d'avoir un niveau de performance tout à fait exceptionnel pour l'utilisateur final ciblé.
    
    C'est un peu pareil avec MacOSX, le noyau est peut-être lent, il hérite d'une conception qui date des années 80 (NeXT) mais au final il rend bien des services à l'utilisateur.
    
    Tout ça pour dire que l'interface noyau-utilisateur est parfois plus importante que le noyau lui-même.

    • [^]Re: API

      Posté par IsNotGood () le 16/04/2008 à 18:30. (lien). Évalué à 2.

      A une époque un monsieur célebre disait que le multitache était sans intérêt pour un PC perso.
      
      Pour un usage desktop, les performances du noyau sont vraiment accessoires. Mais pour un serveur avec un gros débit réseau/disque, c'est tout autre chose.
      Bref, même si le noyau MacOS est tout pourri (je n'en sais rien), c'est sans grande conséquence dans un usage desktop.

      • [^]Re: API

        Posté par Farvardin (page perso, ) le 16/04/2008 à 21:37. (lien). Évalué à 0.

        mac os x existe également en version serveur. Qu'en est-il dans ce cas-là ? Apparemment ce n'est pas si "pourri".

        --
        You can't grep dead trees...