Version 0.1 de L4Ka:Pistachio disponible

Posté par  . Modéré par Nÿco.
Étiquettes :
0
3
mai
2003
Noyau
La nouvelle mouture du micro-kernel L4Ka est arrivée aujourd'hui 2 mai. Elle implémente donc la dernière version de l'API, dont une des grandes nouveautés est l'«IPC redirect». Finalement, la licence choisie pour cette réimplémentation compléte sera une licence BSD.

Il faut garder à l'esprit que cette sortie est essentielle pour l'avenir du Hurd, qui compte abandonner à moyen/long terme mach pour L4Ka. Maintenant que ce micro-kernel est une réalité, les travaux de portage vont pouvoir commencer. L4Ka::Pistachio est écrit en C++, et fonctionne sur les architectures suivantes :
- Intel IA32 (Pentium and higher)
- Intel IA64 (Itanium1)
- PowerPC 32bit (IBM 750)
- Alpha (21164)
- MIPS 64bit (R4000, R5000)

Aller plus loin

  • # Re: Version 0.1 de L4Ka:Pistachio disponible

    Posté par  . Évalué à 3.

    C'est une très bonne nouvelle.
    J'espère que ceci pourra inciter de nombreuses distributions Linux professionnelles (RedHat, UnitedLinux, ...) à proposer à terme des solutions basées sur Hurd.

  • # Re: Version 0.1 de L4Ka:Pistachio disponible

    Posté par  . Évalué à 3.

    C'est une bonne nouvelle pour le projet Hurd qui va pouvoir se concentrer completement sur le portage pour L4.
    Par contre la moins bonne nouvelle c'est que ca sorte sous licence BSD, ca ne pourra donc pas faire partie du projet GNU, mais une reimplementation sous GPL (ou un fork) sera surement possible j'imagine... un Hurdien dans le coin pourra ptet m'eclairer ?

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

      Posté par  (site web personnel, Mastodon) . É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  (site web personnel) . É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)

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

          Posté par  . É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  (site web personnel, Mastodon) . É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  . É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  . É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  (site web personnel, Mastodon) . É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  . É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 [-] :)

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

                  Posté par  . É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  . É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

    Posté par  . Évalué à 2.

    The Hurd hasn't ever been ported to another microkernel. Porting it for the first time will help to be able to do that in the future.
    The first discussions on the mailing list have shown that there it won't be easy to do the port, one suggestion was to rewrite the Hurd servers from scratch.


    C'est un extrait de http://www.gnu.org/software/hurd/l4-hurd.html(...)

    Je me disait que c'était un lien qui manquait dans cette news: un site sur le portage de Hurd sur L4.

    C'est quoi la différence entre L4 et L4Ka ? Juste une différence de version ?

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

      Posté par  . É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  . É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  . É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  . É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  . É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(...)actualité dans deux/trois jours, le temps que je sois libre.

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

            Posté par  (site web personnel) . É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 :-).

Suivre le flux des commentaires

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