Journal Interopérabilité entre distributions...

Posté par  (site web personnel) .
Étiquettes : aucune
0
24
mai
2004
Je viens de lire cet article http://www.01net.com/article/242964.html(...) qui annonce l'arrivée imminente de Mono... jusque là rien de bien exceptionnel et de nouveau sachant qu'il y a déjà eu pleins d'annonces faites il y a plusieurs semaines de celà... Mais il y a un truc qui m'a étonné, c'est un des objectifs de Novell avec Mono :

Mono fournit en effet une couche d'abstraction qui rend une application portable entre différentes plates-formes Linux. Ainsi, « il évite les conflits que l'on constate lorsqu'une application conçue pour les packages de Suse est exécutée par une autre distribution fondée sur des versions de packages incompatibles, par exemple ceux de Red Hat » , relève Érik Dasque

Je trouve celà intéressant comme idée, parcqu'il est clair qu'il permettrait de s'affranchir d'un problème récurant lorsque l'on souhaite distribué un soft sous linux...

En tout cas cet objectif assure au moins que Novell compte fournir des packages pour de nombreuses plateformes et distributions.

Quelque chose me dit que Mono va même faire parti du programme de la prochaine SuSe :-)
  • # Il se passe

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

    Il se passe quand tu utilise un programme Java... Le programme est compatible partout, et ça n'est pas une nouveauté de mono...

    Bon, par contre, c'est clair que java, c'est pas ce qu'il y a de plus libre, alors pour l'intégrer directement dans la distribution c'est pas gagné...

    D'ailleurs je vous conseille l'excellent site :

    http://www.jpackage.org(...)

    qui va vous permettre (enfin)d'arrêter de vous embrouiller avec les autoextractible de java et de toutes la clique libre de apache (jakarta)

    Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

    • [^] # Re: Il se passe

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

      J'ai pas dis que c'était une nouveauté de Mono, la nouveauté c'est que c'est un des objectifs de Novell...
      Evidemment celà fait un enième système de packages supplémentaire mais au moins les solutions Java et Mono sont plus faciles à distribuer, si celà peut aider certaines boites qui ne veulent pas perdre leur temps dans le support de différentes distributions...
      • [^] # Re: Il se passe

        Posté par  . Évalué à 2.

        [+] pour jpackage c´est vraiment bien ca.

        J´imagine que ca doit etre tres facile de faire la meme chose pour les applications Mono, non ?
        On combine les avantages :
        - les boites ne perdent leur temps dans le support de différentes distributions...
        - les utilisateurs n´ont pas a apprendre un enieme systeme de paquetage.
        • [^] # Re: Il se passe

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

          Réussir a garder une compatibilité entre les divers distros ne pose pas que des problémes au niveau binaire, sinon, un coup de -static et ça roulerais tout seul.

          Il y a les chemins, les menus, les noms, et tant de choses si fun en pratique que je ne voit pas ce que mono en lui même va changer.
          • [^] # Re: Il se passe

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

            Pour les libs qui se contenteront de binder une bibiolthèque normal, il y aura effectivement toujours les mêmes problèmes de chemins, de noms, etc. Mais pour les applications qui seront développées au dessus, sur le framework Mono, elles n'auront pas à se demander où est le menu, où sont les libs etc. D'où tout l'intérêt.
  • # Spécificité

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

    Le système de paquets faisant souvent la spécificité d'une distrib, et les distribs étant construites pour ce système de paquets, je vois mal l'intéret de la chose, si ce n'est de rajouter un système de paquet de plus mais celui ci utilisable sur toutes les distribs...

    Personellement, je doute que l'idée prenne...
    • [^] # Re: Spécificité

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

      Si ca peut servir pour le developpement de jeux non libre sur linux, ca m'interresse. (sous entendu c'est pas moi qui les developpe mais comme ca peut etre on aura plus de jeux)
  • # Encore une couche ?

    Posté par  . Évalué à 5.

    « il évite les conflits que l'on constate lorsqu'une application conçue pour les packages de Suse est exécutée par une autre distribution fondée sur des versions de packages incompatibles, par exemple ceux de Red Hat »

    Mouais, je ne sais pas pourquoi mais j'ai un peu de mal à y croire.

    Objectivement, même le langage C, en 1972, avec sa bibliothèque standard était une couche d'abstraction suffisament puissante pour pouvoir porter une application d'une machine à une autre. Aujourd'hui, c'est considéré comme le plus bas niveau de développement et la plupart des gens ne savent même plus qu'il y a du langage machine en dessous.

    Il ne faut pas se leurrer. si .net/mono et Java masquent ce qu'il se passent en dessous d'eux (en sacrifiant les performances), il n'y a pas de raisons pour que les mêmes incompatibilités ne réapparaissent pas au-dessus. Il y aura des packages de fonctionalités écrits en Java ou au dessus de la plateforme .net, et ces packages finiront par entrer mutuellement en conflit ...
    • [^] # Re: Encore une couche ?

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

      Là ce n'est pas au niveau du code qu'il y a incompatibilité (ça c'est résolu avec le code intermédiaire), ...
      Le but n'est pas non plus d'éviter les conflits entre les packages s, ça c'est résolu par un autre élément (versionning des assemblies notamment)...
      Là c'est éviter les problèmes liées aux spécificités de configuration des distributions / OS, et Novell veut faciliter cette distribution de la même manière que Java.
      • [^] # Re: Encore une couche ?

        Posté par  . Évalué à 2.

        C'est comme tu le dis une « idée interressante » dans le sens où les couches d'abstraction sont effectivement orientées en majorité vers la portabilité du code, et qu'a part des outils style ./configure, il n'y a pas grand chose pour s'occuper des settings... probablement parce que c'est une gageure !

        Le problème est que, pour moi, cela ne reglera pas le problème à terme. Pour le moment Java comme .net sont encore suffisament récents et fournis pour que les applications fassent directement appels aux classes standard normalisées par la plateforme, mais lorsqu'il y aura suffisament de packages « maisons » arrivés à maturité, ils vont s'appuyer les uns sur les autres et devront eux aussi être configurés, et les problèmes de versions de distribs, comme ceux du code, vont réapparaître.
  • # Pipo pipo

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

    Les programmes mono seront toujours packagés en rpm, deb,... et donc ce qui est dit est complètement faux.
    Les problèmes de portage entre SuSE et Mandrake ou RedHat sont souvent dus au fait que l'arborescence des distributions diffère.
    Par exemple KDE est dans /usr sous Mandrake et /opt/kde3 sous SuSE. Un coup de rpm --relocate /opt/kde3=/usr --badreloc et ça passe. Ce qui prouve que ce n'est pas majoritairement la compilation / le code binaire qui pose problème.

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Pipo pipo

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

      Les programmes mono seront toujours packagés en rpm, deb,... et donc ce qui est dit est complètement faux.
      Dans tous les cas si c'est une même société, Novell, qui distribue la plateforme Mono sur toutes les plateformes/distributions, ils peuvent garder la même cohérence partout, les libs et bin au même endroit, bref faire abstraction des spécificités de la distri. Et même si y'aura encore des .deb, des .rpm, leur création sera grandement simplifié, notamment entre les différents rpm...
      • [^] # Re: Pipo pipo

        Posté par  . Évalué à 2.

        Dans tous les cas si c'est une même société, Novell, qui distribue la plateforme Mono sur toutes les plateformes/distributions, ils peuvent garder la même cohérence partout, les libs et bin au même endroit, bref faire abstraction des spécificités de la distri.

        Là, je crois que l'on touche le fondement du problème.

        La cohérence recherché n'est pas assurée par le fait que l'on utilise telle ou telle plateforme, mais parce que la normalisation est assurée par un seul organisme.

        C'est d'ailleurs, avec la simplification du style C++, et la pléthore de classes disponibles, ce qui a fait la force du Java. Cela marche parce que Sun gère ses standards avec une poigne de fer, ce qui permet effectivement aux developpeurs de produire des applications sans se soucier de la portabilité. C'est aussi pour cela que Sun s'est faché avec Microsoft lorsque ceux-ci ont voulu créer une version « custom » de leur langage. Il me semble que Redmond a perdu leur procès préciséement sur ce point. Il ont donc à la place créé leur propre langage, ce qui est un moindre mal par rapport à la corruption du Java initial (et à ce moment seul sur son créneau), mais cela commence déjà à fragmenter le développement sur ce segment. Il y aura les programmes Java d'un coté, et les .net de l'autre, tout cela sur une même machine.

        C'est aussi cela qui fait le succès de Windows. L'API peut être pourrie, le fait qu'elle viennent d'un seul et unique endroit rassure les equipes de développement. Pourtant on a tous vu ce que cela peut donner.

        Alors maintenant, quand on me parle d'une couche d'abstraction fonctionnant sur un Unix libre et s'appuyant sur une architecture développée principalement sur Windows par une société dont on connaît tous l'ouverture d'esprit, et donc les règles de fonctionnement sont édictées par Novell, ben moi ça aurait plutôt tendance à m'effrayer.

        Non, pour moi, la vraie interopérabilité Unix, elle tient en deux mots de trois lettres:

        LSB et FHS

        En plus. Novell qui s'appuie sur Mono, ca sent la boîte un peu à la traîne qui ne sait développer que sous Windows et qui veut quand même profiter de la vague des logiciels libres. Un peu comme quand Jayce nous dit que MultiDeskOS fonctionne sous Linux en utilisant Wine ...
  • # Mono/Java ?

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

    On compare toujours Mono à Java..

    Y'a d'ailleurs un troll terrible à ce propos sur planet.gnome.org mais, finalement, qu'est-ce que python n'a pas par rapport à ces deux là ?

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Mono/Java ?

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

      Python n'est pas comparable car joue plutôt dans la cour des langages interprétés comme Ruby par exemple.
      Python est surtout un langage, alors que Mono et Java, en plus de proposer un langage (ou plusieurs), propose un framework qui n'a rien de comparable avec celui de Python, qui vont de la création d'interface web à l'IDE en passant par des applications réparties voir un framework de plus bas niveau avec Mono.
      Mais c'est pas forcement incompatible, comme le prouve IronPython, implémentation du langage Python sur le CLR de Mono et .NET.
      Mais techniquement Python n'est pas du tout une plateforme innovante comme a pu l'être Java, ou comme l'est Mono actuellement (techniquement), Python c'est plutôt sa syntaxe agréable qui fait sa force.
    • [^] # Re: Mono/Java ?

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

      je ne connais pas python, mais au hasard je dirais un manque support d'une grosse entreprise...

      et donc des pme achetant un "support" aux grosses entreprises l'utilisant

      et donc des développeurs des pme l'utilisant

      et donc des utilisateurs utilisant les programmes des développeurs l'utilisant

      Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

Suivre le flux des commentaires

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