Journal Il fallait s'y attendre.

Posté par  (site web personnel, Mastodon) .
Étiquettes : aucune
5
14
déc.
2010
À moitié un journal "bookmark", à moitié un chemin de réflexion.

http://www.osnews.com/story/24129/Mono_Applications_Use_Unsa(...)

"Microsoft maffia'd several companies into signing patents deals with them"

Il y a très longtemps que je pense (et que j'affirme ici) que l'enthousiasme autour de ce clone d'une technolgie fondamentalement propriétaire était dangereux. Surtout à cause du flou légal qui entoure les ecma-ceci, les brevets-cela et les promesses-encore. J'avoue que je ne comprend pas bien (comme la plupart d'entre vous (je suppose)) toutes les subtilitées juridiques autour de cet écosystème logiciel, mais quelque part, je trouve ça inquiétant.

Après Java (en voie de fossayage par Oracle (comme si Sun ne suffisait pas (mais MySQL, c'est moins grave)) (et OOo, non plus)) qui commence à devenir inquiétant dans son contexte de liberté, c'est un autre langage issu du monde "corporate" qui dégaine son épée de Damoclès.

Ne serait-il pas temps de revenir aux saines valeurs ?

  • # Source...

    Posté par  . Évalué à 9.

    A l'origine, un post de The-Source.com, un "supporter" de Roy Schestowitz, trolleur anti-ms/mono professionnel.

    Deja, ca promet.

    Ensuite, la seule chose qu'il ait faite, c'est un coup de grep sur les sources avec une liste de namespaces consideres comme dangereux. Evidemment, il se garde bien d'analyser ce qui est utilise exactement (il l'avoue lui meme, il a la flemme) et si c'est reellement couvert par des brevets. Faire se boulot, c'est long et complique et puis il ne faudrait pas laisser les faits empecher un bon gros FUD.

    En plus, manque de pot, un des logiciels a depuis vire toute utilisation d'un des namespaces (Banshee dans sa version de dev, dont la version 1.9.0 est publiee depuis le 10 nov.), ce qui reduit encore plus son "argumentation".

    Bref, du bon troll anti-mono sans interet, toujours par le meme groupe de personnes pour qui la haine de MS est plus important que tout le reste.

    • [^] # Re: Source...

      Posté par  . Évalué à 2.

      "Evidemment, il se garde bien d'analyser ce qui est utilise exactement (il l'avoue lui meme, il a la flemme) "
      Ça, ça ne devrait pas être trop compliqué à faire : il est tout à fait possible de demander à un IDE de supprimer les appels aux packages inutiles.

    • [^] # Re: Source...

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

      Surtout qu'il cherche pas à réfléchir ou vérifier 2 minutes les références qu'il trouve.
      Prenons les 3 principaux namespaces utilisés :
      - System.Xml : pas de bol, Wikipedia dit des conneries, on retrouve ce namespace à l'ECMA. (et ca prend 2 minutes à vérifier dans l'url source de wikipedia : http://msdn.microsoft.com/en-us/netframework/aa569283.aspx). Et hop, 188 références sur les 419 sont bidons.
      - System.Linq : un des fondement de C# 3, en cours de normalisation à l'ECMA (à l'état de draft en 2010) : il peut encore les compter si ça l'amuse, mais est-ce bien représentatif ? 155 références qui ne seront bientôt plus à compter.
      - System.Web : le namespace pour faire des requêtes HTTP... Si Microsoft a des brevets là dessus, c'est pas les applications Mono qui vont avoir spécifiquement des enmerdes, c'est beaucoup plus de monde.

      En fait, si on prend ce qui reste, c'est à dire quasiment rien, c'est plutôt rassurant : on s'aperçoit que les applications qui tournent sous Mono ne s'appui sur aucune brique potentiellement problématique (System.Windows.Forms, ADO.NET, etc.).

      • [^] # Re: Source...

        Posté par  . Évalué à 3.

        >> - System.Web : le namespace pour faire des requêtes HTTP... Si Microsoft a des brevets là dessus, c'est pas les applications Mono qui vont avoir spécifiquement des enmerdes, c'est beaucoup plus de monde. <<

        La, tu exageres, tu sait très bien que Microsoft peut avoir des brevets sur l'implementation de System.Web sans qu'ils aient des brevets sur HTTP.

        En plus pour ton point, les drafts ça peut durer *très longtemps* parfois, voire ne jamais se concrètiser donc je trouve loin d'être ridicule de le compter.

        • [^] # Re: Source...

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

          La, tu exageres, tu sait très bien que Microsoft peut avoir des brevets sur l'implementation de System.Web sans qu'ils aient des brevets sur HTTP.
          Oui enfin ca serait malheureux que Mono ne trouve pas une implémentation alternative comme le font toutes les autres technos...

          En plus pour ton point, les drafts ça peut durer *très longtemps* parfois, voire ne jamais se concrètiser donc je trouve loin d'être ridicule de le compter.
          Oui c'est possible.

      • [^] # Re: Source...

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

        System.Xml : pas de bol, Wikipedia dit des conneries, on retrouve ce namespace à l'ECMA.

        Tu t'es empressé de corriger j'espère.
        Ça serait dommage de laisser traîner ça, je ne me sens pas compétent dans cet espace de nom (System.Xml) pour pourvoir le faire à ta place, même après ta remarque.

    • [^] # Re: Source...

      Posté par  . Évalué à 0.

      Tiens une attaque ab hominem contre un critique mono/microsoft comme c'est curieux de ta part...

      D'autre personnes se sont penche sur la question et on pose la question a des grans fans de mono. La reponse de ces derniers est assez "amusante":

      http://www.the-source.com/2010/12/on-mono-packaging/


      So, it appears that there are non-ECMA bits even in the “most basic” Mono library. At this point, I was pretty sure we could reject the claim.

      However, even in my freetarded factfinding frenzy I wanted to be sure, so I did something absolutely insane: I asked Jo Shields about it. (In case you don’t know, Mr. Shields packages Mono for Debian and Ubuntu.)

      Mr. Shields was kind enough to respond, and here’s the summarized deal:

      1. ECMA/non-ECMA is not a consideration in packaging Mono.
      2. No distribution ships Mono with ECMA-only components.
      3. It is not possible to do so without “deep surgery”.
      4. Splitting along ECMA/non-ECMA lines is not a priority.

      So, we can reject the claim that distribution packagers are splitting Mono into ECMA/non-ECMA components.

      • [^] # Re: Source...

        Posté par  . Évalué à 4.

        Moué, c'est trop simpliste. Ce n'est pas parce qu'une portion n'est pas standardisée par ECMA que c'est automatiquement issu de chez Microsoft

        Par exemple, GTK# est bien non ECMA, non ? Et pourtant, bien qu'étant un composant essentiel de Mono (pour les GUI), il n'a rien à voir avec Microsoft.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # d'un autre côté

    Posté par  . Évalué à 1.

    Bien que le côté légal de la chose soit subtil, et que ça soit dommage de perdre un langage, ça reste mono. C'est pas comme si c'était un langage avec lequel on fait des outils efficaces et propre. De coclure : :( pour le principe, osef sur ce fait là.

    • [^] # Re: d'un autre côté

      Posté par  . Évalué à 1.

      Franchement, je ne peux plus me passer de Tomboy, et je n'ai rien trouvé d'équivalent, donc Mono risque de me manquer.

      Et qu'on ne me parle pas de GNote, certains bugs et fonctions absentes ne me permettent pas de le choisir pour mon usage intensif.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Il dit qu'il voit pas le rapport.

    Posté par  . Évalué à 4.

    La citation que tu rapportes en tête de ton article, "Microsoft maffia'd several companies into signing patents deals with them", est une phrase qui tombe vraiment comment un cheveux sur la soupe à la fin de l'article original.

    Les fameux "patent deals" ne s'appliquent même pas à Mono mais au marché de la téléphonie mobile et plus précisément au procès contre Motorola.

    En bref, juste un bon gros FUD.

  • # Ne serait-il pas temps

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

    >Ne serait-il pas temps de revenir aux saines valeurs ?
    Valeurs saines, ne pas les perdre.
    Quant à revenir, c'est très certainement ce qu'ils souhaiteraient. Un petit truc d'étudiants bien sympathique pas dans les radars. Mais non ...
    :-)

  • # Ton alarmiste

    Posté par  . Évalué à 5.

    L'article (de OSNews) ne dit pas que la sphère Mono va exploser d'ici quelques jours. De toute façon Microsoft n'a pas d'intérêt à faire ça. Il souligne juste le fait que le Community Promise n'était pas suffisant (et ça on le savait déjà puisque, à sa sortie, certaines des applications Mono phares parlaient déjà de Moonlight).

    Par contre, ces applications Mono dépendent toujours d'un runtime de plus de 70 Mo compressé, sans compter les bibliothèques tierces. C'est chianf.

    • [^] # Re: Ton alarmiste

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

      C'est chianf.
      Ca gène qui ?
      Sur le desktop, je penses que tout le monde s'en tape de 70Mo, qui sont partagés par toutes les applis. Et si vraiment ca te gène, y'a mkbundle qui permet de déployer le strict minimum pour une application donnée.
      Sur les devices mobiles, par exemple sur iPhone, le runtime compressé tombe à 3Mo. C'est encore beaucoup mais largement acceptable si on compare à la taille que peuvent prendre les graphiques.

      • [^] # Re: Ton alarmiste

        Posté par  . Évalué à 4.

        > Sur le desktop, je penses que tout le monde s'en tape de 70Mo

        Mono a l'air de vouloir devenir le nouveau Java. Tu n'es pas sans savoir que certains systèmes préhistoriques comme Mac OS X n'ont toujours pas de gestionnaire de paquets. Ça risque de peser son poids…

        Comme à chaque journal qui parle de Mono, je me contente de rappeler que ça ne fait qu'ajouter un nouveau runtime (qui commence à être de bonne qualité il faut le reconnaître, même si ça n'a pas toujours été le cas) dont on aurait pu se passer avec un peu de jugeote.

        • [^] # Re: Ton alarmiste

          Posté par  . Évalué à 2.

          Tu n'es pas sans savoir que certains systèmes préhistoriques comme Mac OS X n'ont toujours pas de gestionnaire de paquets. Ça risque de peser son poids…

          Tu déportes le problème. C'est la faute d'Apple, pas de Mono.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Ton alarmiste

            Posté par  . Évalué à 0.

            Certes, mais on peut quand même se demander si un nouveau runtime (et plusieurs nouveaux langages) étai(en)t nécessaire(s), là où d'autres cherchent plutôt à réutiliser ce qui existe déjà (la JVM).

            D'autre part, on n'est pas sur AppleFR ici, je le sais bien. C# est également vraisemblablement plus agréable à utiliser que Java, et mieux conçu. Cependant, ça n'est pas une grosse révolution, donc je ne vois pas ce qui justifie qu'on s'embarrasse d'un nouveau venu.

            Il y a beaucoup de choix qui ne sont en définitive que politiques du côté des pro-Mono comme du côté des anti-.

            • [^] # Re: Ton alarmiste

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

              C# est également vraisemblablement plus agréable à utiliser que Java, et mieux conçu. Cependant, ça n'est pas une grosse révolution, donc je ne vois pas ce qui justifie qu'on s'embarrasse d'un nouveau venu
              Ben la réponse est dans ta phrase précédente : quand un développeur passe des heures sur son code, surtout quand il fait des logiciels libres sur son temps perso, il a envie d'utiliser les outils avec lesquels :
              1 - il est habitué (s'il vient du monde .NET)
              2 - qui lui plaisent (choix du langage notamment)
              3 - qui réponde à ses besoins (frameworks, libs).
              A l'époque où Mono a démarré, il n'y avait pas vraiment d'alternative au java proprio qui soit à la hauteur, Mono avait donc tout son sens.
              Un autre atout : l'alternative. Les récentes craintes autour de Java et du comportement de Oracle montre bien qu'il est tout à fait pertinent d'avoir plusieurs technos concurrentes et d'avoir le choix.
              Donc après que celà occupe 70Mo sur le desktop, à côté de tout le reste, clairement on s'en tape.

              • [^] # Re: Ton alarmiste

                Posté par  . Évalué à 5.

                Tandis que grâce à Mono, on a maintenant le choix entre:
                - développer en Java et prendre un procès par Oracle
                ou
                - développer en Mono et prendre un procès par MS.

                Il y a effectivement plusieurs choix possibles.

                Ah zut! l'a l'air de faire friscouille dehors... ---> [ ]

                • [^] # Re: Ton alarmiste

                  Posté par  . Évalué à 2.

                  Plus précisément :
                  - développer en Java et prendre un procès par Oracle (ce qui est *déjà* arrivé);
                  - développer en Mono et prendre un procès par MS (ce qui n'est *jamais* arrivé).

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Ton alarmiste

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

                    s/jamais/pas encore/

                    • [^] # Re: Ton alarmiste

                      Posté par  . Évalué à 1.

                      D'un point de vue juridique, c'est d'une grande différence. Jurisprudence, tout ça...

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Ton alarmiste

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

                  Il y a effectivement plusieurs choix possibles.

                  Voilà un bon résumé des incertitudes actuelles. Tu bosses pour wikileaks ?

Suivre le flux des commentaires

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