Re: Version 0.1 de L4Ka:Pistachio disponible

• [^]Re: Version 0.1 de L4Ka:Pistachio disponible

  Posté par Alexandre DATH (page perso, ) le 02/05/2003 à 23:38. (lien). Évalué à 7.

  A la vitesse ou ca a avancé en comparaison avec Linux depuis qq années, j'ai peur de ne pas voir un Hurd tourné en prod de mon vivant :-/
  
  Je suis pourtant a fond dans le concept ;)
  
  GNU Power ! :-)

  • [+] [^]Re: Version 0.1 de L4Ka:Pistachio disponible

    Posté par lockness () le 03/05/2003 à 01:12. (lien). Évalué à -2.

    C'est le Kernel de GNU/Hurd ? Il me semblait que c'était Mach III (à ne pas confondre avec le rasoir :o))

    • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

      Posté par Pierre () le 03/05/2003 à 02:04. (lien). Évalué à 0.

      toi tu as pas lu la news :)

    • [+] [^]Re: Version 0.1 de L4Ka:Pistachio disponible

      Posté par huhuhu () le 03/05/2003 à 08:06. (lien). Évalué à -1.

      C'est pas plutot mach 1 ?

      • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

        Posté par yves a (page perso, ) le 07/05/2003 à 10:14. (lien). Évalué à 1.

        il est plutôt loin de passer le mur du son actuellement ;-)

        --
        -->

• [+] [^]Re: Version 0.1 de L4Ka:Pistachio disponible

  Posté par Brice Arnould ( un_brice ) (page perso, ) le 03/05/2003 à 09:47. (lien). Évalué à -1.

  LLLLOOOOOLLLL
  
  (en plus y en a qui l'ont pris au sérieux -_^)

  --
  Respect à RMS.

Re: Version 0.1 de L4Ka:Pistachio disponible

• [^]Re: Version 0.1 de L4Ka:Pistachio disponible

  Posté par LupusMic (page perso, ) le 03/05/2003 à 08:53. (lien). Évalué à 1.

  Un fork en GPL est impossible, parceque celà soustenderais que tout le code deviennes GPL. Ce qui empêcherais l'existance d'une variante BSD de la bête.

  • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

    Posté par Brice Arnould ( un_brice ) (page perso, ) le 03/05/2003 à 09:53. (lien). Évalué à 5.

    Je comprend pas: si il est possible de faire des forks proprios des soft sous license BSD (macos10), y devrait y avoir à plus dorte raison moyen de faire des forks GPL?
    
    Je pense même pas que ça empêcherais de réintegrer les modifications du GNU dans le project initial, paske le code GPL peut être lié à du BSD non? (mais c'est vrai que le projet serais plus absolument BSD)

    --
    Respect à RMS.

    • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

      Posté par JSL (page perso, ) le 03/05/2003 à 10:24. (lien). Évalué à 7.

      Si j'ai bien suivi, ce que veut dire Mickaël Wolff, c'est que :
      - l'équipe qui bosse sur ce projet travaille avec une licence BSD.
      - si tu peux redistribuer sous licence GPL (et encore que, j'ai pas assez confiance dans mon anglais pour le garantir), c'est cool, mais :
      - tes améliorations, également en GPL, ne pourront pas nourrir la version de l'équipe principale, puisque qu'elle ne pourrait inclure ton travail qu'en passant la sienne en GPL aussi.
      
      Bref, pour partciper au projet, il faudra accepter le fait que l'équipe principale travaille avec une licence BSD. À moins bien sûr de constituer une équipe plus nombreuse et techniquement meilleur que l'équipe original, mais j'en doute ;)

      • [+] [^]Re: Version 0.1 de L4Ka:Pistachio disponible

        Posté par LupusMic (page perso, ) le 03/05/2003 à 11:21. (lien). Évalué à -1.

        Ce n'est pas ça que j'entendais par impossibilité de forker le code BSD vers du code GPL. En fait, le code publié en BSD peut-être utilisé dans un projet clos (propriétaire). Or, si on rends ce code GPL par un changement de license, le code ne peut plus être clos. En définitive, la license BSD n'a plus court, et le même code publié par l'équipe d'origine ne peux plus être clos, puiqu'il est GPL.
        
        On ne peut pas donc effectuer un fork d'un projet BSD vers un projet GPL. Par contre, on peut changer la license du projet. Mais dans ce cas, ce n'est plus un fork ;)

        • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

          Posté par Wawet76 (page perso, ) le 03/05/2003 à 11:54. (lien). Évalué à 7.

          Quelqu'un peu faire un fork d'un projet BSD et le distribuer sous GPL. Ça n'oblige pas le projet d'origine à devenir GPL.
          
          De toute façon la FSF n'est pas contre l'utilisation de code non-GPL pour son projet GNU. Ils utilisent par exemple XFree86 et Apache...

          • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

            Posté par Pierre () le 03/05/2003 à 14:44. (lien). Évalué à 5.

            De toute façon la FSF n'est pas contre l'utilisation de code non-GPL pour son projet GNU. Ils utilisent par exemple XFree86 et Apache...
            
            Ils les utilisent faute de mieux, mais ils ne font pas partie du projet GNU.

          • [+] [^]Re: Version 0.1 de L4Ka:Pistachio disponible

            Posté par LupusMic (page perso, ) le 03/05/2003 à 19:13. (lien). Évalué à -4.

            Ça n'oblige pas le projet d'origine à devenir GPL.
            Dans l'absolu si, puisque le code est le même, à quelques modules prêts. Donc, en fait, le projet utiliserais du code devenu GPL, et ne pourrais plus le fermer.
            
            Et que la bande de c** qui ont vôté [-] sur mon précédent poste s'exprime, plutôt que de faire la sourde oreille !

            • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

              Posté par Jak () le 03/05/2003 à 21:38. (lien). Évalué à 5.

              > Dans l'absolu si, puisque le code est le même, à quelques modules prêts.
              Mais non ! À partir du moment où quelqu'un reprend du code BSD et le met sous GPL, toutes les améliorations apportées au projet sous GPL ne peuvent pas être portées sur le projet en BSD, évidemment, mais rien ne force les auteurs du code BSD à reprendre le code sous GPL.
              
              Bien sûr, à partir de là, les projets sont dissociés. Il y en a un en GPL et un en BSD. Mais ça n'empêche pas le BSD de continuer à évoluer de son côté.
              
              > Et que la bande de c** qui ont vôté [-] sur mon précédent poste s'exprime, plutôt que de faire la sourde oreille !
              La Cabale n'existe pas, tu n'as pas eu de [-] :)

              --
              « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
              - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)

            • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

              Posté par Wawet76 (page perso, ) le 04/05/2003 à 14:54. (lien). Évalué à 6.

              Pour le post précédent le [-] était parceque ce que tu disais était faux.
              Sur celui ci c'est pour l'insulte injustifiée.

      • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

        Posté par Mickaël L () le 05/05/2003 à 13:38. (lien). Évalué à 2.

        Voila mon point de vue : ils peuvent faire unfork GPL du logiciel sous BSD. La license BSD autorise ce genre de chose (la GPL n'intervient pas encore ici).
        Ensuite la question des modifications :
        - toute modif BSD apportée à la version BSD peut être transférée à la version GPL
        
        - toute modif apportée à la version GPL peut être transférée à la BSD A LA CONDITION que l'auteur du patch l'autorise (en gros son code perso est compatible avec la BSD)
        
        - les modifs à la version GPL qui sont aussi sous GPL ne peuvent être transférées à la version BSD
        
        Aprés c'est une histoire de courtoisie : est-ce que ceux qui ont fait le fork vont refuser à ceux dont ils ont récupérer le travail d'avoir accès aux modifications.
        
        Finalement
        1. le projet GNU n'est pas obligé de faire ce fork puisque la BSD est compatible avec la GPL (en fait, il y a déjà probablement du code BSD dans GNU.
        2. S'ils le font, les deux communautés peuvent coexister et échanger du code pourvu que ceux qui utilisent la license la plus restrictive l'acceptent.
        
        Au fait, c'est ce qui c'est passé pour WINE : le code original était du type MIT ou BSD, et ils sont passé en GPL. Il y a eu un fork avec la license originale à partir de la dernière version ou c'était possible. Les patches sont soit applicables aux 2 soit uniquement à wine.

Re: Version 0.1 de L4Ka:Pistachio disponible

• [^]Re: Version 0.1 de L4Ka:Pistachio disponible

  Posté par JSL (page perso, ) le 03/05/2003 à 12:10. (lien). Évalué à 3.

  Le problème est que la page que tu propose est complétement «outdated». C'est pour cela que je ne l'ai pas mis.
  
  Il y a eu de très bon résumé Hurd et L4 dans des commentaires sur linuxfr, mais il est vrai qu'il serait sympa d'avoir une page de référence sur la chose, même si on sait qu'il y aura encore pas mal de changement d'ici que tout cela devienne réalité ;)
  
  > «C'est quoi la différence entre L4 et L4Ka ? Juste une différence de version ?»
  Je ne connais pas trop l'historique de L4, mais si tu cherche du L4 au jour d'aujourd'hui, tu ne tombes que sur L4Ka avec google.

  • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

    Posté par fleny68 () le 03/05/2003 à 13:11. (lien). Évalué à 4.

    Le problème est que la page que tu propose est complétement «outdated». C'est pour cela que je ne l'ai pas mis.
    
    Bonne raison en effet. Mais les listes de discussions données en lien sont actives, non? ça peut faire un point de départ.
    
    Peut-être celle ci, est-elle plus tenue à jour? date de modification le 26 mars 2002... http://www.nongnu.org/l4hurd/(...) et les listes de discussions sont les mêmes.
    
    Allez, un petit lien pour ceux qui ont du mal à comprendre l'architecture micro-noyau ;-) http://michel.arboi.free.fr/humeur/micronoyaux.html(...)

    • [^]programmation objet et micro-noyaux : même combat !

      Posté par JSL (page perso, ) le 03/05/2003 à 16:54. (lien). Évalué à 10.

      Pour contredire un peu le dernier lien, quelque peu négatif envers les micro-noyaux : je pense que les micro-noyaux sont à l'OS ce que l'objet est à la programmation.
      
      Ce que je veux dire : dans les deux cas, on passe à un niveau d'abstraction supérieur. Dans les deux cas, les avantages au niveau du design apparaissent immédiatement, et on voit tout de suite l'intérêt pratique... à condition que les performances en terme de vitesse d'exécution ne s'effondrent pas, sinon tous ces nouveaux avantages n'ont pas grand intérêt, car la vitesse reste la fonctionnalité la plus recherchée.
      
      Or, justement, dans le cas de la programmation objet et des micro-noyaux, un tas de petite bidouille nous sont interdites, du fait de la plus grande rétention d'information (chaque module/serveur ne communique avec les autres qu'au travers d'interfaces, il ne connaît rien de ce qui se passe à l'intérieur de chacun) induite par l'élévation du niveau d'abstraction.
      
      Et puisqu'on ne peut appliquer ces petites bidouilles (qui sont en général de belle prouesse en terme de hacking d'ailleurs), cela fait autant d'optimisation manuelle perdue ! Une seule solution :
      1) il faut que les mécanismes soient impeccablement pensés, car la moindre perte de performance due à un mauvait choix se fera ressentir à tous les niveaux, puisque inévitable !
      2) il faut qu'un maximum d'optimisations soient applicables automatiquement quand cela est possible, puisque le programmateur ne peut le faire lui-même, à moins de briser le principe de rétention d'information et de modularité. (ce deuxième est surtout valable pour la programmation objet, plus que pour les micro-noyaux, à mon avis)
      
      Dans la pratique, qu'est-ce que cela donne ? Si les débuts des compilateurs de language orienté objets furent une catastrophe (mais si, rappellez-vous, personne n'y croyait...), il faut quand même reconnaître que ça s'est bien amélioré, et en fait, on arrive même (avec des languages comme Eiffel par exemple) à un stade où le compilateur prend en charge tellement d'optimisation automatique qu'un super-hacker ne ferait pas mieux, voire moins bien, et en bien plus de temps. Mais bien sûr, pour que le compilateur puisse faire automatiquement ces optimisations, il faut que lui apparaisse la structure de haut niveau du programme : de telles optimisations automatiques seraient impossibles en C par exemple !
      Et là, les avantages prennent le pas sur les inconvénients, mais il faut énormément de travail en amont, et ça ne s'est pas fait sans heurt, sans erreur et sans recherche éperdue.
      
      Je suis persuadé qu'il en sera de même pour les micro-noyaux : au lieux de laisser à chacun le boulot de faire ses petites optimisations dans son coin (principalement l'énorme problème que constitue la communication inter-processus), une grosse part du problème est déplacée dans le micro-noyaux, mais celui-ci devra se révéler d'une implémentation impeccable, car toute perte de performance sera tout de suite très sensible sur un système complet. Or, le temps passant, je pense que les micro-noyaux vont commencer à révéler leur potentiel pratique.
      
      Ensuite, il faudra que tout ce qui se construit au-dessus suive, et soit au top de la nouveauté, pour que cela intéresse du monde, et ça ne se fera pas en deux ans, mais ce n'est pas une raison pour suivre l'évolution de la chose, avec espoir, mais surtout pas avec de l'impatience ;)

      • [^]Re: programmation objet et micro-noyaux : même combat, mais en plus dur !

        Posté par JSL (page perso, ) le 04/05/2003 à 09:20. (lien). Évalué à 6.

        Je rajoute un petit quelquechose à mon commentaires précédent : Pour le développement de la programmation objet, on a pu commencer par le haut, chose qui n'est pas possible avec les micro-noyaux, ce qui en rend le décollage d'autant plus difficile.
        
        En efffet, il était possible d'écrire un petit programme en C++ par dessus tout un système dès le départ. Ce programme avait les défauts de son language, mais ça restait supportable car cela ne s'étendait pas à tout le système. Au fur et à mesure que le language s'est affiné, mais surtout que les compilateurs se sont améliorés, il était de plus en plus possible d'écrire de gros programme en C++, et jouant des rôles de plus en plus critique. Et aujourd'hui, KDE est entièrement en C++, et il n'apparaît plus absurde d'écrire un kerne lui-même en C++. (même s'il y a encore des progrès à faire)
        Ainsi, dans le cas de la programmation objet, il a pu s'étender progressivement, la pratique venant nourrir la théorie et réciproquement.
        
        Malheureusement, cette approche n'est pas possible avec les micro-noyaux : tant que ça ne marchera pas impeccablement, ça ne sera jamais utilisé en production, car il n'est pas envisageable, comme dans le premier cas, de l'utiliser «par petite touche», puisque par définition, tout viendra se placer au-dessus du micro-noyaux.
        
        Bref, c'est bien le même combat, mais c'est encore plus dur pour le micro-noyaux du fait du rôle nécessairement central qu'il joue dans un système.

    • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

      Posté par Manuel Menal (page perso, ) le 04/05/2003 à 21:58. (lien). Évalué à 2.

      Allez, un petit lien pour ceux qui ont du mal à comprendre l'architecture micro-noyau ;-) http://michel.arboi.free.fr/humeur/micronoyaux.(...)
      
      Voici une réponse que j'avais faite : <http://linuxfr.org/2002/01/02/6461.html(...)

      • [^]Re: Version 0.1 de L4Ka:Pistachio disponible

        Posté par Jacque Chirac () le 05/05/2003 à 19:34. (lien). Évalué à 1.

        Ba, il ne faut pas le prendre trop à coeur. Il faut bien reconnaître que jusqu'à présent les micro-noyaux n'ont pas été franchement convainquant sur le terrain. L4 pourrait bien rendre ce document serieusement obsolet mais ce type ne pouvait pas le connaître, il est tout chaud, il vient tout juste de sortir :-).