Journal Lisaac libéré ?!?

Posté par  .
Étiquettes : aucune
0
20
mar.
2006
En me rendant sur le site de Lisaac, quelle ne fut pas ma stupéfaction : Lisaac a été libéré (et breveté, cf. dernière dépêche) sous CeCILL v2 ???

http://isaacos.loria.fr/li_download.html

\o/ \o/ \o/

Je m'étonne que personne (Ontologia ?) ne l'ait annoncé ici même !

Ou alors j'ai raté quelque chose ?

  • # Et voilà !!

    Posté par  . Évalué à 1.

    Reste à faire un beau noyau GNU basé là dessus :-)
    Qui s'y colle ??

    • [^] # Re: Et voilà !!

      Posté par  . Évalué à 2.

      Ben IsaacOS a été libéré lui aussi, sous CeCILL compatible GPL... donc bon, autant travailler sur de l'existant !

  • # Pas exactement

    Posté par  (site web personnel) . Évalué à 4.

    La librairie est libéré en CeCILL V2. Cela implique que tout code produit avec le compilateur est automatiquement en CeCILL...

    Le compilateur, pas encore.

    L'INRIA "exige" les droits sur le brevet, bien qu'à ma connaissance rien n'ait été déposé. Par contre le programme a été déposé dans plusieurs pays pour prouver l'antériorité, éventuellement.

    IsaacOS sera bientôt libéré (l'autorisation en a été donnée jusqu'à nouvel ordre), mais Benoit aimerait terminer la version 0.2 du compilateur (qui a impliqué une récriture complète de celui-ci), faire une belle distrib, avec quelques explications.
    Bref, faire les choses proprement.

    En ce qui concerne le compilateur, il y a encore incertitude, surtout que si l'INRIA veut déposer un brevet, c'est un long processus.

    Trollez bien pendant 24 h (je ne serai pas là) ;-)

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Pas exactement

      Posté par  . Évalué à 3.

      La librairie est libéré en CeCILL V2. Cela implique que tout code produit avec le compilateur est automatiquement en CeCILL...

      qu'en est il du code Lissac non CeCILL et de l'executable derivé ?
      Si je produis du code Lissac proprio, le code C genere sera CeCILL et l'executable resultant aussi ?
      ce qui signifie que si je distribue un programme executable code a l'origine en Lissac il faut absoluement que le fournisse les sources C ?

      Je n'ai pas lu la licence (flemingite aigue et incompetence monumentale) mais est elle stringente au point d'imposer une licence au produit d'un traitement informatique par un logiciel sous CeCILL ?
      Si je fais un programme "addition" qui genere la somme des deux arguments que je lui transmet, et que ce programme est mis sous licence CeCILL, alors toute valeur issue de ce programme est sous licence CeCILL...

      Dans ma conception du libre a moi que j'ai, on determine les regles de distribution et/ou d'utilisation d'un logiciel par sa licence, mais les donnees generees par ce logiciel doivent rester la propriete entiere de l'utilisateur

      m'enfin ... quelqu'un pour m'eclairer ?

      • [^] # Re: Pas exactement

        Posté par  . Évalué à 2.

        Hum, je pense qu'il s'agit d'une histoire de liaison : si CeCILL est semblable à la GPL, la liaison avec la librairie Lisaac (obligatoire) impose que le résultat soit sous CeCILL (licence "virale"). Je ne pense pas que ça s'applique aux résultats de ton programme d'addition.

        • [^] # Re: Pas exactement

          Posté par  . Évalué à 2.

          Il me semble que si tu recodes toutes les librairies avec les licenses que tu veux, tu peux compiler du code et le distribuer avec ces mêmes licenses.

          • [^] # Re: Pas exactement

            Posté par  . Évalué à 2.

            En l'occurrence, on parle de la lib qui contient les types primitifs (INTEGER, BOOLEAN...), donc tu es en théorie obligé de l'utiliser (à moins de modifier le compilo).

            • [^] # Re: Pas exactement

              Posté par  . Évalué à 2.

              Il y a pas une execption à la GPL dans le cas de composants "de base" du système, typiquement INTEGER, BOOLEAN c'est vraiment des trucs de base ?

              Enfin, peut être que l'exception c'est uniquement les libs de base du système d'exploitation. A vérifier, donc, à mon avis.

              • [^] # Re: Pas exactement

                Posté par  (site web personnel) . Évalué à 2.

                Non car les lib C sont en LGPL, ce qui permet de faire ce que tu veux en éliminant le caractère viral.

                Donc le fait que la licence de la lib soit viral, implique que tout code généra avec le compilateur utilisant cette lib est sous cette licence (Cecill en l'occurance), le source C ainsi que le binaire.

                Il est donc interdit de faire du proprio avec le compilateur Lisaac en l'état, à mois de réécrire la lib...

                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                • [^] # Re: Pas exactement

                  Posté par  (site web personnel) . Évalué à 2.

                  c'est quoi cette histoire de viral ?

                  En plus, tu donnes la manière de procéder : celui qui veut faire du proprio peut le faire sans problème avec le compilo... en se basant sur une lib avec une licence permissive (genre BSD) ou en la réécrivant.
                  Ya pas de raison d'avoir que des profiteurs non plus...

                  Pour moi, l'aspect viral, c'est surtout le proprio qui se refuse à faire de l'open source et ne permet pas d'améliorer ses lib/programmes ni vérifier ce qu'elles font, ce qui t'oblige à les réécrire pour maîtriser ce qui est fait (lorsque c'est nécessaire, mais bon rien que passer de x86 à x86_64 le nécessite parfois). Après, je n'utilise pas le terme viral, le proprio peut le rester, j'ai le droit de privilégier du libre aussi...

                  • [^] # Re: Pas exactement

                    Posté par  (site web personnel) . Évalué à 4.

                    Effectivement, tu peux t'amuser à réécrire la lib et dans ce cas je te souhaite bonne chance. Surtout qu'il y a certaines primitives que tu devras réécrire d'une façon différente pour ne pas amener le juge à constater que tu as copié la lib originale.

                    Tiens, et si on verrouillait toutes les façons de faire des messages if, while, etc... ?

                    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                    • [^] # Re: Pas exactement

                      Posté par  . Évalué à 3.

                      C'est le fait de copier qui est interdit, pas d'avoir une implémentation semblable (je ne prends pas le cas où il y aurait des brevets sur l'implémentation, jusqu'à preuve du contraire nous sommes toujours en Europe et les brevets logiciels n'existent pas), donc, théoriquement, le fait de couvrir de base l'ensemble des implémentations possibles (si c'est un ensemble fini) ne garantie pas pour autant que l'autre à copié... par contre ça devient en pratique très difficile (impossible?) de prouver que l'on a pas copié !
                      Ca serait un cas intéressant en tous cas...

  • # Comme disait l'autre...

    Posté par  . Évalué à 4.

    Vive le lisaac libre !

  • # Commentaire supprimé

    Posté par  . Évalué à 4.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Pourquoi breveter ?

      Posté par  . Évalué à 4.

      attention risque de troll mais loin de moi cette volonté

      pourquoi breveter ? plusieurs raisons imaginables :
      - pour le type qui dépose ca fait bien sur son CV pour chercher un taf (pas partout mais y'a des endroits où ca compte) ou pour obtenir des subventions par exemple...
      - c'est peut être plus simple de déposer le brevet que de prendre le risque de se faire attaquer pour viol de brevet si quelqu'un le dépose à ta place et que l'OEB n'a pas bien fait sa vérification d'entériorité
      - j'en avait d'autres mais elles me sont sorties de la tête pendant que je faisais autre chose.

      par rapport à l'incompatibilité, c'est pas une chose que GPL v3 essaye de régler entre autre ? mais par exemple, le W3C n'est pas formellement opposé au brevet, il faut juste qu'ils soient libres d'utilisation.

    • [^] # Re: Pourquoi breveter ?

      Posté par  . Évalué à 5.

      Pour résumer, les raisons officielles : le compilo Lisaac utilise des techniques très innovantes, et l'INRIA refuse de voir une grande entreprise (lire Microsoft, Sun...) les reprendre et les déposer, si le code était libéré. Certes il y a antériorité, mais un procès risquerait de couter des millions. D'après Ontologia, (roulements de tambours) RMS lui même a compris/admis/préconisé l'utilisation d'un brevet défensif.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Pourquoi breveter ?

          Posté par  . Évalué à -1.

          >donc c'est du brevetage défensif. Ça me va

          Pas moi, ça ne me va pas du tout. Tant que c'est pour se défendre, on a le droit de faire des truc criminels alors.

        • [^] # Re: Pourquoi breveter ?

          Posté par  (site web personnel) . Évalué à 3.

          quels sont ses technologie innovante dont l'Inria est si jalouse ?

          Le compilateur utilise une technique d'analyse de flot qui permet d'analyser l'ensemble du code vivant. Cette annalyse de flot permet de faire pas mal de prédictions de types, spécialisation, etc...

          C'est un algo novateur qui n'a jamais été utilisé ailleurs et qui doit être protégé.
          Je ne veux que cela tombe dans l'escarcelle du logiciel propriétaire.

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Pourquoi breveter ?

            Posté par  . Évalué à 4.

            Et quand bien même ils l'utiliseraient, serait-ce si facile que ça à détecter sans les sources ? Je me demande, parce qu'autant pour un truc largement visible pour l'utilisateur ça se détecte facilement, mais pour ce genre de chose ... ?

      • [^] # Re: Pourquoi breveter ?

        Posté par  . Évalué à 1.

        Pour moi ce n'est pas comme ça qu'on se sert d'un brevet défensif : Il peut y'avoir un procès , brevet ou pas, anteriorité ou pas. L'interet du brevet est comme monnaie d'échange.

        Si une entreprise fait un procès pour violation de brevets, c'est qu'elle utilise une technologie proche, donc qu'elle risque elle-meme tout autant de violer tes propres brevets. Donc à partir de là, il y'a des alliances, des pactes de 'non-agressions', etc. Mais tout ceci n'est possible que si tu as un moyen de pression : posséder des brevets.

        C'est un des problèmes les plus importants des brevets : ils concentrent la technologie et surtout le droit de l'utiliser dans les mains de quelques grosses entités qui ont les moyens de se constituer des portefeuilles de brevets suffisants.

        • [^] # Re: Pourquoi breveter ?

          Posté par  (site web personnel) . Évalué à 3.

          L'interet du brevet est comme monnaie d'échange.

          Ce que tu dis est vrai quand les deux entreprises possèdent effectivement deux gros portefeuilles de brevets mais ce n'est pas le cas courant.

          Habituellement quand une entreprise possède un brevet qui intéresse une plus grosse entreprise il y a négociation d'une licence, partenariat voire rachat de la petite entreprise. Cela se fait beaucoup par exemple dans les domaines pharmaceutique, chimique ou agro-alimentaire.

    • [^] # Re: Pourquoi breveter ?

      Posté par  . Évalué à 1.

      C'est vrai, c'est moche, on croirait que c'est une bonne nouvelle, mais en fait c'est une entourloupe.

    • [^] # Re: Pourquoi breveter ?

      Posté par  . Évalué à 2.

      Exposer ses utilisateurs à des risques de revendications en propriété intellectuelle est effectivement peu à la logique du libre. Hélas, étant donné les pratiques actuelles de l'OEB, le risque existe qu'on brevete ou qu'on ne brevete pas.

      Le mieux est donc de breveter et d'attendre l'expiration du brevet, pour qu'au moins le délai courre.

  • # .

    Posté par  (site web personnel) . Évalué à 8.

    Mais merde, est-ce que c'est devenu normal pour tout le monde ici, de breveter ce genre de truc ??!!!

    • [^] # Re: .

      Posté par  . Évalué à 2.

      c'est breveté certe mais s'il publier sous licence libre , on ne peut pas nous empeche de l'utiliser ( sous les conditions de la licence ) non ?

    • [^] # Re: .

      Posté par  . Évalué à 1.

      Je suis bien ignorant, et je veux pas te froisser, mais je me pose quelque questions...

      Qu'aurais tu voulu...?

      une license GPL...?
      C'est "leur" bébé, pourquoi aurait ils fait ça...?
      Est-ce que c'est un du, un devoir qu'ils avaient de mettre lissac sous GPL...?

      c'est vraiment par curiosité, je ne comprend pas ce qui te gene.

      • [^] # Re: .

        Posté par  . Évalué à 2.

        Juste pour info, en passant le projet sous cecill ça te permet de faire un fork complet sous GPL.

      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 9.

        La licence et le brevet sont deux choses séparées.

        Un OS est un ensemble d'algorithmes. Des algorithmes NE SONT PAS BREVETABLES en tant qu'algorithmes.
        Tout le monde avait pourtant l'air d'accord là-dessus, même au niveau européen.

        • [^] # Re: .

          Posté par  . Évalué à 2.

          Ouais, et pendant que tu fais des belles phrases sur ce qui devrait etre, les algos sont brevetes en pratique.
          Et si on t'ecoutes on va se retrouver gros jean comme devant.

          Bref, dans le contexte actuel, ca me parait normal de breveter.
          Ce qui ne veut pas dire qu'on est pour les brevets, juste que tu peux pas faire autrement aujourd'hui si tu comptes perser un tant soit peu sur la balance (t'entends?).

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: .

      Posté par  . Évalué à 4.

      Bah tu sais aujourd'hui c'est une mode dans le libre : on brevète les trucs quand c'est pour du libre, mais quand c'est les enculés-d'en-face-qui-font-du-proprio c'est inadmissible. On utilise des drivers proprios qui déchirent niveau rapidité sous linux, mais sinon le proprio sous windows ça pue. Et les DRM Open Source de Sun c'est coool, alors que ceux de Sony/VU/... c'est nul ça restreint la liberté des gens. Etc...

  • # Pour vous éviter un clic

    Posté par  (site web personnel) . Évalué à 4.

    Si vous êtes comme moi et que vous ne connaissez pas Isaac, voila les permiers lignes du site :

    Le projet Isaac [...] constitue les premières étapes de la conception d'une nouvelle architecture de système d'exploitation, entièrement basée sur la technologie objet à base de prototype.

    Mais alors, c'est un concurent de linux, de hurd et de multideskOS, ce truc ?
    Plus sérieusement, il y a des applis qui tournent dessus ?

    • [^] # Re: Pour vous éviter un clic

      Posté par  (site web personnel) . Évalué à 4.

      Un puissance4, un tetris, un lecteur vidéo et un viewer bmp. C'est pas mal non ?

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Pour vous éviter un clic

      Posté par  (site web personnel) . Évalué à 1.

      Et quel est l'intérêt ? Ça rend la conception de drivers beaucoup plus complexe, je suppose.

      • [^] # Re: Pour vous éviter un clic

        Posté par  (site web personnel) . Évalué à 4.

        Ah non !!
        Au contraîre !
        Ecrire un driver sous Isaac devient d'une simplicité enfantine.

        Regarde le driver VIDEO. VIDEO hérite de BITMAP, donc il possède toutes les fonctions de dessins, etc...

        Dans VIDEO tu as a écrire les méthodes :

        - make w,h:INTEGER

        Pour initialiser

        - close

        Pour clore ;-)

        - pixel_hard x,y:INTEGER color col:UINTEGER

        Le pixel_ hard.
        C'est la seule méthode indispensable. Tout est écrit dans bitmap à partir de celles-là.

        - line_h_hard x,y:INTEGER until x1:INTEGER color col:UINTEGER
        Méthode facultative

        - line_h_hard x,y:INTEGER until x1:INTEGER image line:BMP_LINE offset ofs:INTEGER
        Idem, pour dessiner une ligne de bitmap.


        Comme VIDEO hérite de BITMAP et que BITMAP contient tout ce qu'il faut pour dessiner des lignes, des points, polygones, cercles, etc.. il suffit que VIDEO redéfinisse la méthode et c'est bon.

        Donc si Nvidia ou ATI veulent écrire un driver pour IsaacOS, il leur suffit d'écrire quelques méthodes de ce genre, plus des méthodes pour la 3d.
        Les fonctionalités systèmes de Lisaac font le reste.

        Donc, non, écrire un driver pour IsaacOS est enfantin.

        C'est une de ses intérêts majeurs.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Pour vous éviter un clic

          Posté par  . Évalué à 4.

          Chouette, des cartes video comme on en faisait il y a 30 ans : les seules fonctions sont get/set_pixel (et draw_line, à la rigueur, mais en fait on en a pas besoin).

          T'aurais p't-être dû prendre un autre exemple...

          • [^] # Re: Pour vous éviter un clic

            Posté par  . Évalué à 1.

            Au contraire on peut surcharger les méthodes du driver generique logiciel par celle fournie par le materiel. Par exemple pour remplacer l'affichage logiciel d'un bitmap qui utilise set_pixel par une methode qui réalise l'appel a la carte graphique.

        • [^] # Re: Pour vous éviter un clic

          Posté par  (site web personnel) . Évalué à 3.

          Oui c'est gentil, mais toute la difficulté de la rédaction d'un driver réside dans l'implémentation efficace des méthodes en fonction du matos. Autant dire que Lisaac n'apporte strictement rien au problème : il faut toujours interagir avec un processeur graphique qui lui a des APIs autrement plus complexes que setPixel et getPixel.
          Faire un driver c'est simple. Faire un driver efficace et qui tire partie des atouts du matos, c'est une autre pair de manche, et c''est pas trop le langage qui fait la différence, mais la façon dont intéragit le matos avec le driver.
          (Si sous Linux c'est si difficile d'avoir des bons drivers, c'est aussi parcqu'il manque la composante documentation, Lisaac ne va strictement rien changé de ce côté là non plus).

          Enfin tu peux toujours rêver pour qu'ATI et nVidia te ponde des drivers, vu qu'ils seraient obliger de les faire sous GPL (ce qui visiblement n'est pas dans leur intention, une bonne partie de leur savoir faire étant inclu dans le driver).

          • [^] # Re: Pour vous éviter un clic

            Posté par  . Évalué à 2.

            Faire un driver c'est simple. Faire un driver efficace et qui tire partie des atouts du matos, c'est une autre pair de manche, et c''est pas trop le langage qui fait la différence, mais la façon dont intéragit le matos avec le driver.


            Je ne suis pas d'accord c'est plus facile de *bien* faire intéragir le matos avec le driver si on a un langage qui permet d'exprimer plus facilement ce que l'on essaye de faire.

            Evidement ca ne change rien de fondamental (rien non plus aux problemes de spec non disponible), mais je pense que la rédaction de driver serai plus rapide de plusieurs ordres de grandeur si on abandonne le C pour un langage plus haut niveau.

            • [^] # Re: Pour vous éviter un clic

              Posté par  (site web personnel) . Évalué à 3.

              Evidemment, tau gagnes du temps en rédaction de code, en maintenance, etc, mais l'exemple cité semble indiquer "regarde c'est génial, t'as 3 méthodes ultra-simples à implémentées pour faire un driver. Lisaac c'est trop fort". Moi j'ai envie de dire "oué cool je peux te faire pareil dans tous les langages". Ca n'a rien à avoir avec le langage cette facilité.
              Par contre je suis curieux de voir comme en Lisaac on va intéragir avec les "vraies" cartes graphiques actuelles, faire mumuse avec les shaders par exemple...

              • [^] # Re: Pour vous éviter un clic

                Posté par  . Évalué à 2.

                oui c'est vrai.

                Mais les shader ca ce programme pas indépendament du logiciel qui l'utilise avec un espece d'assembleur standard ? j'ai pas l'impression que les shaders ca fait partie du driver mais je suis pas un spécialiste

                • [^] # Re: Pour vous éviter un clic

                  Posté par  (site web personnel) . Évalué à 2.

                  avec un espece d'assembleur standard
                  En fait il y a des langages de plus haut niveau inspiré du C qui compilent dans un assembleur spécial. DirectX intègre le siens par exemple. Moi j'ai du mal à voir comment en Lisaac je vais faire le driver derrière :) Enfin y'aura toujours moyen d'interfacer ca en Lisaac, mais reste que la difficulté est vraiment ailleur que dans l'exemple "académique" présenté au dessus.

                  • [^] # Re: Pour vous éviter un clic

                    Posté par  . Évalué à 2.

                    J'imagine qu'il faudrait adapter le compilo avec une bibliothèque spéciale représentant les capacités des shaders. et compiler differement le code selon que cela fait partie de d'appli utilisatrice ou des shader a destination de la carte.

                    Par contre le compilo lisaac est prévu pour faire du c, donc faudrait en prime refaire tous la partie arrière pour sortir l'asm des shaders.

                    C'est vrai que cela serait intéressant de voir si le modèle proposé resiste au choc.

          • [^] # Re: Pour vous éviter un clic

            Posté par  . Évalué à 5.

            Bon, je suis pas très content... Mon commentaire (que je trouvais pourtant pertinent ;-) ) est apparement passé à la trappe. Donc je re-commence.

            Imaginons que le pilotes "standard" fournis avec Lisaac possède les méthodes suivantes :
            - drawLine
            - drawCircle
            - setPixel

            Le minimum nécessaire pour avoir un pilote fonctionnel est de surcharger setPixel pour l'adapter au matériel. Les implémentations de base de drawLine et drawCircle utiliseraient setPixel avec quelques algorithmes bien choisis (Bresenham, ...) (un peu comme Mesa dans Xorg je pense)

            Mais rien n'empêche un constructeur de surcharger drawLine et drawCircle pour utiliser des fonctionnalités précises de son matériel. De cet façon, on a un pilote optimisé.

            En gros, un constructeur qui s'en fiche surcharge uniquement setPixel => performances médiocres. Un "gentil" constructeur surchargera aussi drawLine et drawPixel pour avoir un pilote rapide.

            J'espère ne pas avoit dit trop de bétise car je ne me suis absolument pas documenté sur Lisaac. J'ai juste livré mes pensées en lisant ce fil.

            • [^] # Re: Pour vous éviter un clic

              Posté par  . Évalué à 2.

              oui c'est exactement ca :)

              Évidement ca ne change rien au fait que sorti des fonction de base comme drawLine le travail reste compliqué. (je dis ca avant que quelqu'un d'autre le dise :))

            • [^] # Re: Pour vous éviter un clic

              Posté par  (site web personnel) . Évalué à 4.

              Ca c'est une question d'interface, ca n'a rien à voir avec Lisaac. C'est comme ca que marche déjà la plupart des environnements graphiques : support matériel ? rendu hardware sinon rendu software.

              • [^] # Re: Pour vous éviter un clic

                Posté par  . Évalué à 4.

                Évidement le traitement a réaliser est le même. et oui cela a déjà été fait.

                Ouais mais aucun compilateur ne permet d'utiliser toutes les techniques objet pour du code dont la rapiditée d'exécution est critique. Genre dans ce genre de biblio

                Par exemple si tu regarde les autres projets (y'a des liens sur le site de lisaac) de codage d'un os avec un langage objet ils recommandent tous de ne surtout pas utiliser le polymorphisme. du coup on ne voit pas trop l'interet d'utiliser un langage objet. Alors qu'ici le but est bien de ne pas se restreindre et de garder l'efficacitée.

                En ce moment c'est a la mode de dire que les concept objet c'est juste une vision de l'esprit et que l'on peut faire de l'objet avec n'importe quel objet.

                Alors c'est vrai oui, de la même facon que l'on peut tout réaliser avec n'importe quel langage, ils sont tous turing-complet.

                Mais il y aussi indéniable que si on utilise des langages bien adapté a ce que l'on veut faire on arrive plus vite a un meilleur résultat.

                Perso je pense que refaire le travail du compilateur tous les jours pasque on essaie de faire de l'objet avec du C, ben c'est une mauvaise idée.

                Alors évidement il faut absolument un compilo qui tienne la route, ce qui est le cas ici.

                • [^] # Re: Pour vous éviter un clic

                  Posté par  . Évalué à 2.

                  Alors c'est vrai oui, de la même facon que l'on peut tout réaliser avec n'importe quel langage, ils sont tous turing-complet.

                  Faut pas non plus exagérer : tu peux réaliser toutes les fonctions, mais tu ne peux peux pas tout faire. P.ex. gawk est turing-complet, on peut même y manipuler des sockets (si, si, cherchez gawkinet, en standard avec gawk), mais on ne peut pas en faire un OS sans l'augmenter, sans lui ajouter une couche pour accéder au matériel (et bien que l'aspect « tout est flux » d'awk se rapproche de celui d'Unix, il n'est pas suffisant).

                  Perso je pense que refaire le travail du compilateur tous les jours pasque on essaie de faire de l'objet avec du C, ben c'est une mauvaise idée.

                  C'est pourtant ce que fait Gtk (pas Gtk--, hein, Gtk) : de l'objet avec du C.

                  • [^] # Re: Pour vous éviter un clic

                    Posté par  . Évalué à 3.

                    Oui mais c'est un problème de communication de la platforme du langage avec le reste de la machine pas du langage en soit. Enfin je suis d'accord avec ce que tu dis.

                    Je sais bien que c'est ce que fait gtk et personnellement je n'échangerai pas deux barils de gtk contre un baril de qt.

                    Alors après il y a d'autre avantage a l'utilisation de gtk : binding plus facile avec d'autre langage, compilo plus performant que celui de c++.

                    Mais justement si on arrive à résoudre ces problèmes je preferai largement programmer en objet.

              • [^] # Re: Pour vous éviter un clic

                Posté par  . Évalué à 2.

                Je suis tout à fait d'accord. En réalité, je voulais répondre à Sylvain Sauvage juste au dessus de ton message.

              • [^] # Re: Pour vous éviter un clic

                Posté par  (site web personnel) . Évalué à 2.

                Je te rejoint pour affirmer avec toi, que cette possibilité qui a été présenté est un choix de design de l'OS.

                Néanmois, ne pas oublier que ce genre de possibilitée est directement offerte par le fait que Lisaac soit un langage objet à prototype, et que cette différence permet une bien plus grande flexibilité qu'un modèle à classe où il faudrait écrire des composants (voir Think, etc...)

                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                • [^] # Re: Pour vous éviter un clic

                  Posté par  (site web personnel) . Évalué à 4.

                  Justement ca serait cool que tu nous montres en quoi le fait que c'est un langage de prototype te permet d'avoir cette architecture, et en quoi c'est pas possible dans un modèle plus classique !
                  Nan parcque là je vois une simple interface à implémenter, quoi de plus standard dans le monde objet ?

                  • [^] # Re: Pour vous éviter un clic

                    Posté par  . Évalué à 3.

                    Il se trouve que dans le monde des langages a objet, tu ne trouvera pas de système d'exploitation. Et très peu de bibliothèque (performante) bas niveau.

                    Car justement le résultat de la compilation n'est pas terrible en prog objet.

                    Et l'interet du modèle prototype de lisaac est qu'il permet de mettre en place des techniques de compilation plus efficace pasque le langage s'y prete bien.

                    • [^] # Re: Pour vous éviter un clic

                      Posté par  (site web personnel) . Évalué à 1.

                      Oué enfin même sans parler d'objet", c'est déjà ce que propose Linux pour les drivers : une "interface" à implémenter, en C à priori. et rien n'empêche de proposer une interface simpliste comme celle proposée ci dessus en C standard. Je vois toujours pas le rapport avec Lisaac.

                      • [^] # Re: Pour vous éviter un clic

                        Posté par  . Évalué à 2.

                        Ben justement si on parle pas d'objet on ne peut pas voir le rapport car justement lisaac et isaac c'est de l'objet. Je ne comprend que tu ne vois pas les avantages, mais franchement je ne pense pas que l'on trouvera un jour tous les details techniques d'un projet dans les commentaires de dlfp.

                        J'arreterai donc cette conversation ici...

                        Mais t'inquiete pas quand j'aurais eu plus le temps d'apronfondir tout ca je reposterai un truc et on pourra de nouveau troller ...

                        De toute manière on a juste le code en C de libre pour le moment et il faudra revoir tout ca en detail quand on aura toutes les sources en lisaac.

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Et c'est où pour tester ?

      Posté par  . Évalué à 2.

      Je pense que c'est un projet a moyen terme.

      Pour le moment on a juste le compilo dans un fichier c généré depuis la version en lisaac. Et isaac (l'os) dans un fichier c aussi généré depuis la version en lisaac. Par contre la lib est dispo en lisaac. (le tout en licence cecill)

      Mais ils ont l'air assez ouvert au libre maintenant. Alors je pense qu'il faut mettre la pression jusqu'a ce que ils fournissent le compilo (surtout) et l'os. Histoire qu'ils sentent qu'on est derrière et qu'on est intéressé d'en faire un projet libre.

      Pour répondre à ta question techniquement je pense pas que cela soit trop dur, c'est quoi dans un iPaq un ARM ?

      • [^] # Re: Et c'est où pour tester ?

        Posté par  . Évalué à 3.

        Oh ben non, c'est pas trop dur : suffit d'hériter...

        Ouais, je suis maichant. N'empêche que Linux sur les ipaq a encore de gros problèmes (et ce malgré la participation active de membres de HP), notamment avec les cartes SD : faut avoir du bol quand on en achète une, sinon on peut rejouer.

        Penser un pilote dans la théorie et coder un pilote fonctionnel dans la pratique sont deux choses totalement différentes. Et avoir les spécs, ça aide, mais ce n'est pas une formule magique (les standards sont parfois flous, les mises en ½uvre plus ou moins déviantes ou boguées¹).

        ¹ : p.ex. l'USB est un standard (« universel », même), un périphérique USB est un périphérique USB. Sauf que certaines clefs USB posent des problèmes (y compris pour les OS avec pilotes propriétaires), certaines souris n'aiment pas être débranchées, etc.

        • [^] # Re: Et c'est où pour tester ?

          Posté par  . Évalué à 2.

          Oh ben non, c'est pas trop dur : suffit d'hériter...


          J'aurai du préciser pas trop dur par rapport a l'avancé du projet (il me semble qu'un portage sur ARM a déjà été fait) et a la difficulité des techniques habituelles.

          Apres évidement je pense que tout le monde a une idée de la quantité de travail derrière ...

          • [^] # Re: Et c'est où pour tester ?

            Posté par  (site web personnel) . Évalué à 3.

            Il me semble qu'il tourne sur un ARM IsaacOS. Je me souvient que Benoit m'avait raconté à quel point l'assembleur est prise de tête sur ce processeurs (bah oui pour faire l'OS, ya un centaine de lignes à écrire).

            Après le tester....

            A voir si on le met dans la distrib

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Suivre le flux des commentaires

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