Mono 2.0 : le singe continue ses grimaces

Posté par (page perso) . Modéré par j.
Tags :
25
9
oct.
2008
Mono
L'environnement d'exécution et de développement Mono vient de passer en version 2.0.

Mono est une plate-forme libre, multi-languages et multi-plates-formes compatible avec le framework .NET (produit Microsoft pour Windows). Il permet notamment d'exécuter des applications .NET sous Linux. C'est également une plate-forme de développement complète intégrant un IDE, un débogueur, la prise en charge de nombreux langages (C#, VB.NET, Python, Java, etc.) et de nombreuses bibliothèques de l'écosystème Linux (GNOME, OpenGL, etc.). Cette version majeure apporte son lot de nouveautés - plates-formes, fonctionnalités, outils - et d'améliorations en terme de performances et compatibilité.

Mono est utilisé dans des contextes variés :
  • Sous Linux par des applications de bureau comme F-Spot, Tomboy, Banshee et Beagle ;
  • Toujours sous Linux par des applications web comme mojoPortal ou Dekiwiki ;
  • Par des applications distribuées comme SecondLife (moteur exécution des scripts utilisateurs sur les serveurs de jeu) ;
  • Toujours dans les jeux, le moteur Unity3D ;
  • Enfin l’embarqué : lecteur MP3 Sansa Connect.
Mono 2.0 tourne bien entendu sous Linux (x86, x86-64, PowerPC32, Itanium, SPARC, ARM, s390, s390x) mais également Solaris (x86-64, SPARC), les *BSD (x86, x86-64), Windows (x86), MacOSX (x86, PowerPC32) ainsi que sur des plates-formes embarquées ou consoles : Wii, iPhone, lecteurs MP3.

Ecosystème Linux/Unix
L'accent est mis sur l'intégration dans l'environnement GNOME et les technologies "standards" sous Linux/Unix à travers la prise en charge des :
  • Bibliothèques GTK, GNOME, DBus, Gecko, Cairo, OpenGL, SDL, ZeroConf, Posix, Bittorent ;
  • Bases de données PostgreSQL, Firebird (MySQL fourni son propre connecteur compatible).

Outils
  • Un débogueur fait enfin parti des outils "officiels" de la plate-forme, il est considéré comme stable dans cette version de Mono, facilitant son intégration dans les applications tiers.
    MonoDevelop, un IDE "maison", qui va lui aussi arriver en version 2.0 avec la très attendue intégration du débogueur. Pour rappel, cet IDE propose le support de nombreux langages (C#, Boo, C++, java) avec notamment un éditeur GTK qui constitue une alternative à Glade ;
  • Mono Migration Analysis : cet outil analyse les composants d'une application .NET pour déterminer si celle-ci est compatible avec Mono d'un point de vue API. Elle détecte notamment les parties non implémentées par Mono et les appels à des bibliothèques natives (dont la portabilité ne peut être vérifiée) ;
  • Cecil, un outil/bibliothèque de manipulation du bytecode CIL propre à l'environnement d'exécution .NET. Celui-ci permet de lire, écrire voir modifier le code exécutable d'une application.
  • Gendarme, au nom évocateur, est capable de valider un composant vis-à-vis d'un ensemble de règles personnalisable : conventions de nommage, sécurité, performances, etc.
  • Mono Linker se propose de faire maigrir un composant/bibliothèque en supprimant les parties non utilisées dans une application, utile dans l'embarqué ;
  • Des compilateurs pour de nombreux langages sont disponibles : C# 3.0, Visual Basic 8.0, Boo (Python-like typé statiquement), Cobra, Java (projet IKVM), Ruby (IronRuby), Python (IronPython), PHP (projet Phalanger), Eiffel (ISE), F#, Pascal et bien d'autres. Il existe également un backend pour GCC générant du bytecode CIL.

Compatibilité
L'environnement d'exécution (CLR pour Common Langage Runtime) est compatible avec les différentes versions de l'environnement .NET existants à ce jour (jusqu'à .NET 3.5 basé sur le CLR 2.0)

Le langage C# 3.0 est pleinement supporté ainsi que le langage VB.NET en version 8. Mono est également compatible avec le moteur d'exécution de langages dynamiques (DLR) utilisés par les compilateurs IronPython et IronRuby : ce composant peut servir de base à l'intégration de nouveaux langages dynamiques et peut être comparé à Parrot avec tous les avantages de l'intégration au CLR : support de l'ensemble des bibliothèques .NET, et interopérabilité avec les autres langages de la plate-forme.

Les efforts de compatibilité se poursuivent, notamment avec l'implémentation d'ASP.NET 3.5, Silverlight 2.0 (concurrent de Flash) et WCF (Windows Communication Framework).

La plupart des composants/bibliothèques du framework .NET 2.0 sont implémentés :
  • ADO.NET 2.0 : accès aux données ;
  • ASP.NET 2.0 : framework d'application web ;
  • Windows.Forms 2.0 : toolkit graphique, avec support natif X11 (Unix/Linux), Win32 et Quartz (MacOSX) ;
  • System.XML 2.0 : manipulation de documents XML ;
  • System.Drawing 2.0 : bibliothèque de rendu graphique ;
  • System.Web.Services : création et consommation de web-services.
Des composants plus récents (framework .NET 3.5) sont également implémentés :
  • System.Core (LINQ) : composant de requête de données, notamment intégré dans C# 3.0 ;
  • System.Xml.Linq : manipulation de documents XML avec LINQ ;
  • ASP.NET AJAX : bibliothèque de composants AJAX pour le développement web.
Les composants COM (Windows/Mainsoft COM, XPCOM) sont également supportés

Le Framework .NET 2.1 à la base de Silverlight est en cours d'implémentation (projet Moonlight), une première version bêta est attendue prochainement. Ce projet controversé est pourtant le première signe de reconnaissance « officiel » de Mono par Microsoft : Moonlight représente un gage de portabilité pour la nouvelle technologie de Microsoft qui entre directement en concurrence avec Flash. Moonlight et Silverlight partagent du code, notamment les codecs audio/vidéo (malheureusement sous forme de binaire uniquement, Mono proposant une alternative à travers ffmpeg), les compilateurs IronPython, IronRuby et le moteur DLR que Microsoft a mis sous licence libre.

C# 3.0
Cette nouvelle version du langage C# apporte un grand nombre de nouveautés, notamment :
  • Intégration native de LINQ ;
  • Support des expressions lambda ;
  • Types anonymes ;
  • Méthodes d'extensions pour étendre des bibliothèques existantes sans héritage de type ;
  • Inférence de type.
Voici un exemple de code écrit en C# 3 :

var rss = XDocument.Load("http://linuxfr.org/backend/news-homepage/rss20.rss");

var articles = from item in rss.Descendants("item")
let title = item.Element("title").Value
orderby DateTime.Parse(item.Element("pubDate").Value)
where title.Contains("Mono")
select new{
Titre = title,
Lien = item.Element("link").Value,
Description = item.Element("description").Value
};

if (articles.Any(article => article.Description.Contains("je me suis trouvé")))
Console.WriteLine("je me suis trouvé :)");

Historiquement proche des langages Java et C, le langage C# prend ici une nouvelle direction et devient également un langage fonctionnel (plus proche des langages issus de ML).
  • # polymique...

    Posté par (page perso) . Évalué à 5.

    quel distribution installe ça par défaut?

    son intégration dans gnome fait l'objet de polymique

    est-ce qu'il y a vraiment un marché pour ça?

    car bon moindrement je ferais un soft commercial en .net, j'oserais pas me fier à ça face à des clients

    de plus seul une partie de .net est standardisé

    avec tout ce que java propose, jvm, librairie.... et sa fort popularité dans le libre... il me semble avoir lu que c'est le langage avec le plus de projet sur sourceforge... à moins d'être un pro windows... l'intéret d'utiliser ce produit est limité

    www.solutions-norenda.com

    • [^] # Re: polymique...

      Posté par . Évalué à 5.

      Par rapport à Java, je ne dirais qu'une chose : la concurrence et l'émulation, c'est le bien.

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

      • [^] # Re: polymique...

        Posté par . Évalué à 8.

        Cites nous une application critique (vraiment critique) écrite en Mono / .Net, ensuite on pourra parler d' émulation et de concurence.

        En attendant, .Net n' est pas un concurrent à Java et ne lui est donc d' aucune utilité pour une quelconque émulation bénéfique...
        • [^] # Re: polymique...

          Posté par (page perso) . Évalué à 5.

          je pense pas qu'il y est vraiment d'application critique en mono...

          faudrait quand même aimer le risque pour le faire...

          qui miserait sa vie là-dessus?

          je crois que J2EE est beaucoup plus utilisé

          www.solutions-norenda.com

        • [^] # Re: polymique...

          Posté par (page perso) . Évalué à 10.

          Dis nous combien tu as d'application critique vraiment critique en java installées sur ton poste ?

          L'essentiel de l'informatique n'est pas constitué de noyeau transactionnel pour le marché boursier. L'essentiel de l'informatique est non critique.

          Ou plutot c'est critique relativement à l'utilisateur, pour moi l'indexation de mes photos est critique, si je la perd c'est une masse d'information très importante qui est perdue.


          Tout ça c'est vrai en Java comme en .Net. Ca n'empêche pas l'émulation.
          Puis ça me rappelle les arguments à l'encontre de PHP à l'époque.
          • [^] # Re: polymique...

            Posté par . Évalué à 7.

            On définit une mission comme critique dès quel fait intervenir la sécurité des biens et des personnes. La perte de tes photos ne risque pas d'atteindre à ta vie ou à tes biens, c'est pas tous a fait la même chose si ta banque perd ton compte, ou si le système d'aiguillage des trains se met à déconne (trains,avions,voiture,hopitale,centrale nucléaire,etc.).

            Une mission critique, ça correspond a une vrais définition ce n'est pas qu'un mot marketing comme le 2.0 ou le Cloud Computing.

            Sinon je suis assez d'accord ce domaine est très spécifique et ne dépend pas directement d'un langage mais de toute un ensemble de compétence et de mesure mise en oeuvre pour assurer la sécurité du système, le choix du langage n'est qu'une petite part de l'ensemble du système.
            • [^] # Re: polymique...

              Posté par . Évalué à 8.

              "La perte de tes photos ne risque pas d'atteindre à ta vie ou à tes biens, ..."

              Là on voit que tu ne connais pas mon amie....
            • [^] # Re: polymique...

              Posté par (page perso) . Évalué à 7.

              Pour Air France la sécurité des avions c'est important, même vide. Une appli qui évite à l'avion de casser son aile dans le hangar c'est critique je suppose.

              Mais la sécurité des biens c'est relatif. Moi perdre toute ma vie de photos c'est largement aussi important que les avions pour Air France.

              Mais peu importe, je réagissais surtout sur le fait qu'il faut arrêter de juger les langages, developpeurs et applis en regardant qui a fait une appli super critique.
              L'essentiel de l'informatique ce sont des softs utiles, intéressants, parfois super géniaux et indispensables même s'ils ne gèrent pas une centrale nucléaire. Et ces logiciels là ils comptent aussi, ce sont même les plus nombreux et ceux qu'on utilise le plus souvent.
        • [^] # Re: polymique...

          Posté par . Évalué à 8.

          .NET est un concurrent à Java simplement parce que son but est de concurrencer Java et que Microsoft est derrière. Une boîte qui ne se méfierait pas lorsqu'elle voit Microsoft arriver sur son terrain de jeu disparaitrait bien vite, et je ne pense pas que Sun prenne ça à la légère.
          • [^] # Re: polymique...

            Posté par . Évalué à 6.

            Je ne pense pas (avis perso) que le but de .Net soit de concurrencer Java. Pour une simple raison : la vision stratégique de Microsoft avec .Net va bien au délà de la simple exécution d'un programme avec un VM.

            .Net pour Microsoft, c'est (ou ce sera bientôt) :
            - un moyen de rénover complètement l'API Win32
            - d'avoir un shell object excellentissime (Powershell pour ceux qui connaissent pas),
            - de permettre l'intégration fusionnelle des applis écrites en C# v3 avec les bases de données SQL Server via LINQ,

            --> Bref un truc très large et qui embrasse tout l'univers Microsoft et qui va déboucher prochainement sur...un OS .Net (donc nous voyons les prémices avec Singularity, et dont les recherches se poursuivent avec Midori).

            Après ça leur permet effectivement de concurrencer Java sur les sites web, mais aussi Flash avec Silverlight.

            J'ai pas d'actions chez MS pour info.
        • [^] # Re: polymique...

          Posté par . Évalué à 10.

          Pour moi, Java et .NET sont très largement comparables. Déjà, il me semble que .Net vient à la base du procés fait entre Microsoft et Sun à propos de la JVM by MS : n'ayant pas le droit de faire ce qu'il veut de Java, il a décidé de faire son propre framework.

          D'ailleurs, Sun aurait-il libéré son Java s'il n'y avait pas eu .NET ? Personnellement j'en doute. Donc la concurrence s'est ici avérée saine et profitable au moins pour le monde libre.

          De plus, on peut dire ce qu'on veut de Mono, mais il a également ses propres librairies (notamment GTK, Cairo, etc) qui le rendent viable et indépendant de Microsoft dans une certaine mesure, et lui apporte une vraie valeur ajoutée par rapport à l'implémentation MS.

          Ici on tape sur une techno parce qu'elle a une base MS, sans s'intéresser à son contenu, c'est ce que je trouve dommage.

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

          • [^] # Re: polymique...

            Posté par . Évalué à 4.

            Oui mais de là à dire qu' il est un concurrent (ie il serait d' ores et déjà un concurrent) il y a une marge.

            Oui .net est conçu dès le départ pour cela : concurencer Java.
            Non .net n' arrive toujours pas à la cheville de Java, parceque son 'spectre' de cibles est bien plus large que .net/mono. Et il le restera longtemps...

            Et ça m' étonnerait qu' un jour il y arrive : je fait confiance à MS pour faire les mêmes erreurs, toujours, qu' avec windows : facile, puissant, rapide et véloce. La fiabilité passe à la trappe. Comme d' hab. C' est pas demain la veille qu' on aura des appli critiques en .net.

            Quant à son intégration toujours plus dans Gnome, c' est finalement l' argument qui me fera rester sous kde4... désolé, là c' est du troll et en plus un jugement personnel. le mal quoi. Mais pourquoi intégrer toujours plus mono (avec son système de double license) : 1. cela semble contradictoire avec la gplv3 (l' esprit de) 2. Java suit le chemin inverse : libération. Donc pour un env. où là ils sont concurents de faits (des appli du bureau de mme michue) je ne comprends pas que gnome choississe mono. Il est certain que je n' ai pas tout les éléments me permettant de comprendre, simplement de me poser des questions.

            Cordialement
            • [^] # Re: polymique...

              Posté par . Évalué à 5.


              Quant à son intégration toujours plus dans GnomeKDE, c' est finalement l' argument qui me fera rester sous kde4>Gnome... désolé, là c' est du troll et en plus un jugement personnel. le mal quoi.
              Mais pourquoi intégrer toujours plus monoQt (avec son système de double license) :
              • [^] # Re: polymique...

                Posté par . Évalué à 10.

                La différence c'est que Trolltech n'a pas un lourd passé de mauvais coups envers le libre ou même simplement la concurrence.
                • [^] # Re: polymique...

                  Posté par . Évalué à 4.

                  Mais Novell non plus et jusqu'à pruve du contraire la rmarque s'adressait à Mono pas à .NET.

                  D'ailleurs je me souviens bien du troll sur les faibles contributions de Ubuntu au kernel. Et quand on sortait que Novell aussi faisait du proprio, on a eu droit à une levée de bouclier. Tout le monde faisait table rase du passé en affirmant qu'ils avaient pris le bon chemin et qu'on pouvait leur faire confiance.
        • [^] # Re: polymique...

          Posté par . Évalué à 4.

          Un site de vente en ligne, dont le nom commence par « c » et fini par « discount » est fait entièrement en point Filet.

          Et pour une société de vente en ligne, avoir son site web opérationnel, c'est plutôt critique, non ?

          Et puis en même temps, les systèmes de sécurité des centrales nucléaires ne sont pas non plus faits en Java.
          • [^] # Re: polymique...

            Posté par . Évalué à 1.

            .Net pour faire un portail de vente en ligne, je veux bien croire que ça marche...

            Pour ce qui est des systèmes vraiment critiques, il me semble que .Net a bien planté la bourse de Londre ...

            Et de nombreux systèmes transactionnels lourds au niveau financier sont basés sur des piles java sur des serveurs inaccessibles à .Net, genre des gros serveurs p IBM avec au choix WebSphere, Weblogic, ... ou des machines un peu plus modestes avec Tomcat, Geronimo, JBoss, ...

            .Net ne tourne pas sur la grosse artillerie, et vu les performances minables et la compatibilité hazardeuse de mono que les portes vers le gros matos vont s'ouvrir demain à l'écosystème .Net
            • [^] # Re: polymique...

              Posté par (page perso) . Évalué à 9.

              il me semble que .Net a bien planté la bourse de Londre ...
              Alors faut savoir, y'a des applications .NET qui tournent dans des environnements critiques ou pas ?
              • [^] # Re: polymique...

                Posté par . Évalué à 6.

                Microsoft pousse derrière... ils ont les moyen de trouver des Daltons pour creuser des tunnels avec une spatule...
                • [^] # Re: polymique...

                  Posté par (page perso) . Évalué à 6.

                  Alors que c'est bien connu, IBM Sun & Co n'ont aucun service commercial qui essaient de vendre leurs produits...
                  • [^] # Re: polemique...

                    Posté par . Évalué à 2.

                    Le jour ou Microsoft sortira seul et comme un grand une application tournant nativement sous linux de la meme version que celle sous windows je changerait peut etre mon opinion sur eux et pourrait eventuellement commencer que cette boite joue le jeu de la concurrence. Je suis tranquille et je sens que de l'eau va couler sous les ponts.
                  • [^] # Re: polymique...

                    Posté par . Évalué à 4.

                    Pour IBM, oui, par contre Sun, d'expérience, je peux dire qu'ils ne sont vraiment pas doués pour la vente... ils sont focalisés sur le hardware et ratent souvent de belles opportunités sur le soft, il faut parfois expliquer à leurs commerciaux des choses comme "vous savez, il y a six ans, vous avez acheté la société x qui faisait le logiciel z, et nous aimerions acheter des licences"...

                    En tout cas, rien de comparable chez Sun à la machine de guerre commerciale de Microsoft.
            • [^] # Re: polymique...

              Posté par (page perso) . Évalué à 5.

              vu les performances minables et la compatibilité hazardeuse de mono

              C'est objectif et argumenté ça tiens.
              • [^] # Re: polymique...

                Posté par . Évalué à 2.

                il y a régulièrement des benchmarks publiés sur les perfs mono comparées aux perfs .Net, rien de neuf à ce sujet, les dev mono ne vont même pas contester, et ils avancent bien sur le sujet... question maturité, en tout cas, il vaut mieux encore attendre.

                Pour la compatibilité, en dehors du fait que mono a une bonne guerre de retard sur .Net, on peut pointer du doigt les pratiques des développeurs d'applications en environnement .Net qui sont beaucoup moins soucieux des problèmes de portabilité que leurs contreparties travaillant sous mono... Microsoft n'encourage pas assez la portabilité et .Net permet trop d'abus.

                Dans l'ensemble, il suffit d'analyser avec MoMA (Mono Migration Analyser) des applications .Net populaires pour se rendre compte que la compatibilité n'est pas encore au rendez-vous et que mono ne peut se substituer à .Net comme environnement runtime, à fortiori en milieu professionnel où il faut héberger des applications tierces.
                • [^] # Re: polymique...

                  Posté par (page perso) . Évalué à 4.

                  Mono est parfois plus rapide que .net, souvent moins rapide, mais j'aimerais bien voir un cas où on est «minable». Et si on en trouve (c'est possible, je dis pas), il suffit de rapporter un bug.

                  Et pour le reste, c'est surtout un problème du côté des applications. Après oui, Mono n'implémente pas .net 3.0, mais a des briques de .net 3.5. Mais bon, des applis WPF, j'en vois pas encore beaucoup quoi.

                  Et oui, dans l'ensemble, il faut faire des analyses avec MoMA, pour voir qu'un grand nombre d'applications peuvent être portées avec des changements mineurs (voir la présentation de Miguel au FOSDEM par exemple). Parce que souvent, le problème est dans l'application.
                  • [^] # Re: polymique...

                    Posté par (page perso) . Évalué à 2.

                    . Mais bon, des applis WPF, j'en vois pas encore beaucoup quoi.
                    Non mais WCF par contre... Olive, Olive !
            • [^] # Re: polymique...

              Posté par . Évalué à 1.

              Pour ce qui est des systèmes vraiment critiques, il me semble que JEE a bien planté le site des impôts...
              • [^] # Re: polymique...

                Posté par . Évalué à 1.

                Rien avoir avec JEE, mais plutôt avec les développeurs du site.
                • [^] # Re: polymique...

                  Posté par . Évalué à 3.

                  Et aussi avec le fonctionnement des déclarations d'impôts, genre : "Tiens, si on demandait à toute la population active de France de se connecter le même jour à notre serveur". (Bon, disons la même semaine).

                  Un collègue qui y était le jour de la première année de télé déclaration m'expliquait qu'ils passait leur temps à rajouter de nouveaux serveur sur leur baie, et à peine le nouveau serveur opérationnel, il tombait.

                  Ah, le bon vieux temps.
                  • [^] # Re: polymique...

                    Posté par . Évalué à 8.

                    Et tout ça avec l'argent de nos impôts que nous n'arrivions pas déclarer :)
                  • [^] # Re: polymique...

                    Posté par . Évalué à 4.

                    Ah ok c'est pas la faute de JEE mais des développeurs et de ces idiots d'utilisateurs qui se connectent tous en même temps.
                    Et qu'en est-il de cette fameuse appli critique en .NET qui a planté.

                    C'etait pas la faute des developpeurs ni des utilisateurs qui chargaient le serveur ?
                    Des sources SVP avant de dénigrer.
                    • [^] # Re: polymique...

                      Posté par . Évalué à 2.

                      Ce n'est ni la faute aux développeurs ni aux utilisateurs, c'est la faute aux architectes systèmes qui n'ont pas su évaluer correctement la charge qui allait leur tomber sur la gueule.
            • [^] # Re: polymique...

              Posté par (page perso) . Évalué à 2.

              ebay utilise j2ee

              www.solutions-norenda.com

              • [^] # Re: polymique...

                Posté par . Évalué à 3.

                Ebay utilise une pile Java mais pas vraiment J2EE (comme la plupart des grosses architectures telle que yahoo, flickr ou linked in).

                En fait les applis tournent dans des containers J2EE (websphere pour ebay, tomcat pour yahoo etc.) mais ils n'utilisent presque rien de la pile J2EE. En général ça se limite aux servlets et éventuellement JDBC/connection pools. Pour JDBC ça dépend pas mal de l'architecture choisie pour la couche donnée.

                Pour le cas spécifiques d'ebay tu peux regarder cette veille présentation http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29(...) ça te donne un bon aperçu. La phrase clé est: "Step 1 - Throw out most of J2EE – eBay scales on servlets and a rewritten connection pool.".

                Si c'était pour faire du J2EE ca serait pas fun de faire de grosses archis :-)
            • [^] # Re: polymique...

              Posté par . Évalué à 6.

              Pour ce qui est des systèmes vraiment critiques, il me semble que .Net a bien planté la bourse de Londre ...

              Euh non, la bourse de Londres, qui tourne sous .Net, a plante, je vois pas trop ce que ca a voir avec .Net

              Quand une app critique ecrite en C ou C++ plante, c'est la faute a C/C++ ou au dev qui a fait une connerie ? Pourquoi serait-ce different avec C# (ou Java) ?

              Et de nombreux systèmes transactionnels lourds au niveau financier sont basés sur des piles java sur des serveurs inaccessibles à .Net, genre des gros serveurs p IBM avec au choix WebSphere, Weblogic, ... ou des machines un peu plus modestes avec Tomcat, Geronimo, JBoss, ...

              Il y a bcp plus de .Net dans le monde financier que tu ne peux l'imaginer, evidemment si les seuls que tu connais sont ceux que tu vois dans la presse quand ils plantent c'est que tu as un certain manque d'informations.

              Sinon, au hasard, devines en quel langage la majorite du dernier Exchange est ecrit, et ca c'est legerement critique comme serveur dans une entreprise de nos jours.
              • [^] # Re: polymique...

                Posté par (page perso) . Évalué à 0.

                en meme temps, la qualité d'exchange...

                non, c'est pas argumenté, mais c'est une sensation partagée :)
                • [^] # Re: polymique...

                  Posté par . Évalué à 3.

                  Quand je vois le nombre de gens disant qu'il est impossible de migrer car il n'y a pas d'equivalent a Exchange sous Linux, je me dis qu'il est pas si mal que ca apres tout.
              • [^] # Re: polymique...

                Posté par . Évalué à 5.

                Bon, pour donner quelques données de l'intérieur, je travaille dans un grand groupe financier, qui tient encore debout (pour l'instant), et toutes nos applications "modernes" sensibles sont écrites en Java.

                L'incursion en .Net a commencé il y a maintenant 2 ou 3 ans, et pour l'instant, est limité aux "light developments", c'est à dire les petites applications non critiques et de moins de 200 j/h.

                Et ce essentiellement pour les raisons suivantes :
                1) on a plein de ressources en Java, et on a déjà essuyé les plâtres
                2) c'est facile de trouver des développeurs java, plus que des développeurs .Net (là, ce n'est pas mon expérience perso, mais ce que m'en disent les commerciaux avec qui je travaille)

                Quand j'en discute avec des collègues partis à la concurrence, c'est à peu près partout le même constat. L'exception vient des éditeurs de softs, qui sont beaucoup plus versés en .Net.

                A mon avis, et je le partage :-), je ne vois pas .Net arriver au niveau de Java dans la finance avant encore au moins 3 ans, si toutefois il arrive vraiment à émerger.

                Sinon, pour troller un peu, quand je vois les grosses merdes que sont les applications en ActiveX (et il y en a encore, hélas), je ne comprends pas qu'on fasse encore confiance à Microsoft pour le futur des applications Web...
                • [^] # Re: polymique...

                  Posté par . Évalué à 2.

                  De mon côté je vois plein de choses qui sont toujours en Cobol. Java pour la partie présentation OK, mais je vois mal java traiter des millions de lignes en Batch. Pareil pour le TP, c'est ce qu'il y a de plus rapide pour les call center, c'est les terminaux 3270. La majorité des flux financier est traité en Cobol, sur du mainframe IBM. D'ici ce que Java (ou .net) remplace tout ça j'espère avoir pris ma retraite (dans 40 ans mini).
                  • [^] # Re: polymique...

                    Posté par . Évalué à 1.

                    Toutafé, c'est pour ça que je parlais d'applis "modernes" (avec les guillemets).

                    Chez nous aussi, beaucoup de Cobol, mais aussi beaucoup de PowerBuilder pour la génération "intermédiaire". Et un peu de C. Sans oublié tous les scripts (perl, bsh, csh, ksh).
                • [^] # Re: polymique...

                  Posté par . Évalué à 2.

                  Quand j'en discute avec des collègues partis à la concurrence, c'est à peu près partout le même constat. L'exception vient des éditeurs de softs, qui sont beaucoup plus versés en .Net.

                  A mon avis, et je le partage :-), je ne vois pas .Net arriver au niveau de Java dans la finance avant encore au moins 3 ans, si toutefois il arrive vraiment à émerger.


                  Je suis bien d'accord, .Net est parti avec qqe annees de retard sur Java, il ne va pas passer la periode d'adaptation plus rapidement, comme toute technologie.

                  Mais comme tu le precises, les editeurs de softs eux passent a C# bien plus rapidement(ce qui est normal, il n'ont pas les memes contraintes), et tout comme avec Java, c'est par la que l'implantation vient: tu amenes un soft de l'exterieur, a l'interieur tu te mets a developper extensions et autres, C# arrive, les gens ayant les competences suivent ou apprennent ces competences, ...

                  Java a suivi le meme chemin, maintenant c'est au tour de .Net, demain ca sera surement autre chose.
                • [^] # Re: polymique...

                  Posté par . Évalué à 2.

                  En fait, pour compléter ton avis, pas mal de grosses banques dont SG et Calyon ont décidé pour la plupart des cas à faire leurs nouvelles applications en Java pour tout ce qui est serveur d'application et .Net pour tout ce qui est interface graphique.
    • [^] # Re: polymique...

      Posté par (page perso) . Évalué à 5.

      En general, les distributions installent par défaut ce qui est requis par les applicatifs par défaut. Tu as un soft qui a besoin de perl ? perl sera donc la par défaut. Tu as un soft en ruby ? Ruby sera la par défaut .
      Tu as rien en python ? Ben python risque de ne pas être installé, sauf à choisr "developpement", ou ce genre de catégorie à l'installation, quand la distribution propose le choix.
    • [^] # Re: polymique...

      Posté par . Évalué à 6.

      et tant mieux si cela fait des polémiques !

      Un groupement de liens sur ces polémiques
      http://boycottnovell.com/2008/03/24/mono-danger-to-linux/

      Mono non merci pas chez moi dans mon Unix. Ce n'est pas aux vieux singes qu'on apprend à faire des grimaces !

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: polymique...

      Posté par . Évalué à 6.

      C'est quoi une polymique ?
      • [^] # Re: polymique...

        Posté par . Évalué à 10.

        C'est plusieurs personnes qui miquent ensemble, je crois :·D.
        • [^] # Re: polymique...

          Posté par (page perso) . Évalué à 1.

          Pas du tout !
          C'est un repas corrèzien pour partager ce mets succulent qu'est la mique (et il vaut mieux être à plusieurs car ça peut se révéler redoutable) !

          Merci maintenant j'ai aussi envie de milhassou, de farcidure et d'un petit clafouti !
    • [^] # Re: polymique...

      Posté par . Évalué à 3.

      Deuxième fois que je lis « polymique » sur linuxfr pour dire « polémique », c'est trotorible ! ;)
  • # C# n'est pas un langage à typage fort !

    Posté par . Évalué à 2.

    Je pensais que C# était un langage à typage fort ?


    var rss = XDocument.Load("http://linuxfr.org/backend/news-homepage/rss20.rss");
    var articles = from item in rss.Descendants("item")


    çà me parrait bizarre. D'ailleurs, il manquerait pas plein de ";".
    • [^] # Re: C# n'est pas un langage à typage fort !

      Posté par (page perso) . Évalué à 10.

      C# est bien un langage à typage fort. C'est la magie de l'inférence de type qui permet de se passer dans ce genre de cas de déclarations superflues.

      Le bout de code d'exemple m'a l'air correct, il se compose bien de trois instructions:
      1. charge le document.
      2. récupère les éléments du flux, ne garde que ceux dont le titre contient le mot "Mono", ordonne par date de publication, et renvoie un IEnumerable d'un type anonyme qui contient le titre, un lien, et la description de chacun des items retenus.
      3. vérifie si la balise "description" d'un item au moins contient la chaîne recherchée et affiche un message le cas échéant.

      À noter: C++0x devrait faire un pas dans cette direction en "recyclant" le mot-clé "auto". Ainsi, les
      for (ContainerType::const_iterator p = list.begin(); p != list.end(); ++p)
          Action(*p, otherArgument);

      ressembleraient plutôt à
      for (auto p = list.begin(); p != list.end(); ++p)
          Action(*p, otherArgument);

      Une bénédiction...
      • [^] # Re: C# n'est pas un langage à typage fort !

        Posté par (page perso) . Évalué à 8.

        Une bénédiction...
        C'est clair, marre d'avoir des lignes de longueur ahurissante juste pour déclarer des variables, j'attends ça, les variadic templates, plus quelques autres trucs, avec impatience.

        Mais on tombe dans le HS là :-)
        • [^] # Re: C# n'est pas un langage à typage fort !

          Posté par . Évalué à 3.

          Je ne suis pas d'accord.

          Je trouve qu'il n'est pas bon de trop compliquer la syntaxe d'un langage.

          çà nuit à sa lisibilité et çà laisse trop de liberté pour un développeur de faire un jour d'une façon et d'un autre d'une autre façon.

          Personnelement un langage comme Java ou Pascal, çà garde un syntaxe facilement compréhensible et tu évites d'avoir un dév qui parre en vrille et te fait un code illisible parce qu'il n'y avait plus de café.

          En plus avec les IDE moderne, tu ne l'es tappes plus des lignes de déclarations.
          La déclaration d'une variable, c'est une template ou une correction automatique du code.
          • [^] # Re: C# n'est pas un langage à typage fort !

            Posté par (page perso) . Évalué à 1.

            Justement, les évolutions portent sur une simplification et une vision plus large du langage, comme l'a fait le standard C++ en 97 par rapport à la première mouture de 90.

            Et même si les IDE modernes (que j'utilise) facilitent la saisie, cela reste manuel (je ne laisse pas non plus mon éditeur coder pour moi) : une vérification visuelle des termes choisis par le complètement automatique est nécessaire (même si elle est rapide). Et même sans parler de saisie, la lecture est souvent pompeuse lorsque le code utilise la bibliothèque standard ou une syntaxe de nommage équivalente (comme boost, que je n'utilise pas :-) ).

            J'utilise Eclipse CDT pour ma saisie de code, car il dispose justement d'un analyseur syntaxique et sémantique performant, et ça c'est un plus. Mais pour moi, les avantages d'un éditeur à la saisie et à la reconnaissance d'erreurs ne doivent pas influer sur la manière de coder.

            Autre exemple que j'ai donné : les variadic templates. C'est un vrai gain pour les techniques dites 'modernes' de programmation générique : plutôt que de faire des spécialisations pour un nombre d'arguments prédéfini (limite), il n'y aura qu'un template à saisir (avec un nombre d'arguments maximum dépendant du compilateur). Encore une simplification pour le développeur (mais pas pour le compilateur :-) )

            A la base, la syntaxe du C++ n'est pas la plus lisible, mais si on développe dans ce langage, il est clair que les nouveautés du standard arrivant vont améliorer les choses à ce niveau (à part peut-être les nouvelles lamba-expressions).
    • [^] # Re: C# n'est pas un langage à typage fort !

      Posté par (page perso) . Évalué à 6.

      C# est un language à typage fort. Seulement il fait de l'inférence de type pour permettre des déclarations plus concises. On aime ou on aime pas, mais c'est possible. Il reste que dans ce cas, il sera impossible d'assigner à la variable `rss` une expression d'un autre type que XDocument.

      Et c'est particulièrement utile dans le cas de requêtes LINQ complexes où on sait juste que la requête LINQ nous renvoit un flux d'objects typés.

      Et non, il ne manque pas de point virgule. C# introduit une nouvelle expression `from` qui a de multiples clauses. Pareil, on aime ou on aime pas cette syntaxe, sachant que ce n'est que du sucre syntaxique, et qu'on peut très bien réaliser cette partie en utilisant une peut être plus verbeuse, mais plus classique, chaîne d'appel de méthodes.
      • [^] # Re: C# n'est pas un langage à typage fort !

        Posté par (page perso) . Évalué à 6.

        ça permet surtout de rendre du code rapidement illisible

        www.solutions-norenda.com

        • [^] # Re: C# n'est pas un langage à typage fort !

          Posté par (page perso) . Évalué à 1.

          Ça c'est ton avis d'expert. Mais moi qui travaille en C# depuis sa toute première beta jusqu'à maintenant, je peux te dire qu'on peut réaliser en C# 3 des choses plus simplement, de manière plus claire, plus aérées, et plus descriptives.

          Et puis tout le monde sait que l'inférence de type la compréhension de liste rendent les programment illisibles, c'est bien connu. En particulier tous les programmeurs qui utilisent des langages fonctionnels tous les jours.

          Cela dit c'est comme pour tout, on peut abuser et abuser de telle ou telle spécificités, et mal écrire du code. Oui, on peut encore le faire.
        • [^] # Re: C# n'est pas un langage à typage fort !

          Posté par (page perso) . Évalué à 3.

          C'est tout le contraire : C# 3 introduit une syntaxe connue de la plupart des développeur : select * from bidule where machin group by machin.name, du bon vieux SQL. C# 3 permet ainsi d'écrire ce qu'on met d'habitude dans une chaîne de caractère et qu'on passe au moteur de BDD (ou abstraction type hibernate) en la généralisant à tout type de source de données (XML, base de données, objets, etc.)
          Les lambdas expressions ne sont que l'extension naturelle et simplifiée des méthodes anonymes de C# 2 qui ont une syntaxe affreuse.
          L'inférence de type évite d'écrire des noms de type à rallonge, rendant le tout beaucoup plus lisible.
      • [^] # Re: C# n'est pas un langage à typage fort !

        Posté par . Évalué à 2.

        "sachant que ce n'est que du sucre syntaxique"

        Pour moi, c'est bien le problème. Cette syntaxe sort des paradigmes de base du langage. Ce ni cohérent, ni un mécanisme généralisable, évoluable ou réutilisable par le programmeur.

        Alors que d'autres langages comme les Lisp et Haskell permettent de créer un syntaxe spécifique à un traitement. c'est une propriété du langage, et non du sucre synaxique. Ce qui permet de faire des trucs chouettes et vraiment utile.

        Je ne suis vraiment pas fan du mélange de paradigmes de C#.

        Dans le genre à la fois fonctionel, impératif et orienté objet, il y a Scala qui est vraiment chouette. (Sauf les noms interminables des fonctions Java)
    • [^] # Re: C# n'est pas un langage à typage fort !

      Posté par (page perso) . Évalué à 8.

      Même perplexité que toi devant cet exemple en C#3... On dirait un gloubiboulga de Javascript et de (Visual)Basic, avec des morceaux de fonctionnel dedans... Beurk!

      Je ne vois pas l'intérêt de faire quelque chose de totalement différent de la version précédente... Si le codeur C#2 ne retrouve plus ses petits en C#3, n'aurait-il pas mieux valu changer de nom?
      • [^] # Re: C# n'est pas un langage à typage fort !

        Posté par (page perso) . Évalué à 3.

        Si le codeur C#2 ne retrouve plus ses petits en C#3, n'aurait-il pas mieux valu changer de nom?
        C# 3 est pleinement compatible avec C# 2, le développeur va donc retrouver ses petits.
        après le développeur fait ce qu'il veut. Je même code que celui de l'article mais en C# 2 :
        class Article
        {
        string titre;
        string lien;
        string description;
        public string Titre { get { return titre; } set { titre = value; } }
        public string Lien { get { return lien; } set { lien = value; } }
        public string Description { get { return description; } set { description = value; } }
        }
        /**plus loin dans le code **/
        XDocument rss = XDocument.Load("http://linuxfr.org/backend/news-homepage/rss20.rss");

        IEnumerable items = rss.Descendants("item").OrderBy(delegate(XElement item){
        return DateTime.Parse(item.Element("pubDate").Value);
        }).Where(delegate(XElement item){
        return item.Element("title").Value.Contains("Mono");
        });

        List articles = new List();
        foreach(XElement elem in items)
        {
        Article article = new Article();
        article.Titre = elem.Element("title").Value;
        article.Lien = elem.Element("link").Value;
        article.Description = elem.Element("description").Value;
        }

        if(articles.Any(delegate(Article article){return article.Titre.Contains("je me suis trouvé");}))
        Console.WriteLine("je me suis trouvé");
      • [^] # Re: C# n'est pas un langage à typage fort !

        Posté par (page perso) . Évalué à 6.

        En fait, C# c'est pas totalement différent de C# 2, et il est très facile de faire retrouver ses petits à un programmeur C# 2 en lui expliquant trois choses.

        Trois choses c'est pas si énorme.

        La première c'est l'inférence de type. Ce n'est qu'un de laisser le compilateur définir le type la variable. Plutôt que de l'écrire soit même. Entre:

        Dictionary<string, object> d = new Dictionary<string, object> ();

        et

        var cache = new Dictionary<string, object> ();

        Je sais ce que je préfère. En plus ça force souvent le programmeur à mieux nommer sa variable, pour mieux refléter son but.

        La seconde c'est les méthodes d'extensions. Attention, encore une fois, ce n'est que du sucre syntaxique. Ce sont des simples méthodes statiques, que le compilateur peut appeler comme des méthodes d'instance. Les mêmes règles s'appliquent qu'avant.

        Mais au lieu d'écrire:

        byte [] b = ...;
        int c = Utilities.ReadCompressed (b, pos);

        On peut écrire:

        byte [] b = ...
        int c = bytes.ReadCompressed (pos)

        Pour peut que l'on ait défini une méthode d'extension.

        Voilà, et la dernière chose, c'est que la syntaxe `from where select`, est en fait utilisé par le compilateur comme une suite d'appel à des méthodes d'extensions.

        Ainsi au lieu d'écrire:

        string [] args = ..;
        IEnumerable<string> big = args.Where (arg => arg.Length > 10).Select (arg => arg.ToUpper ());

        On peut écrire:

        string [] args = ...;
        IEnumerable<string> big = from a in args where arg.Length > 10 select arg.ToUpper ();

        Allez si, j'ai oublié une chose, la syntaxe des expressions lambdas en C# 3, qu'on peut expliquer à un programmeur C# 2 comme une méthode anonyme, plus simplement déclarée.

        Ainsi, dans l'exemple précédent, au lieu d'écrire:

        args.Where (delegate (string arg) { return arg.Length > 10; })

        J'ai écris:

        args.Where (arg => arg.Length > 10);

        Où on bénéficie de l'inférence de type.

        Voilà, c'était le post «Les nouveautés de C# 3 du point de vue pour le programmeur C# 2»

        Petite note personnelle, pour avoir passé plus de 6 mois à implémenter LINQ dans Mono, et pour avoir implémenter un provider LINQ, je peux dire que c'est un des composants les mieux pensés du framework .net, où tout s'emboîte vraiment logiquement.

        Il ne faut pas se focaliser par l'aspect soudainement non typé, ce n'est surtout pas du Visual Basic ou du JavaScript avec du Late-Binding. Et oui, C# s'oriente petit à petit, vers le fonctionnel. Il faut dire que ce n'est pas donné à tout le monde de programmer avec un langage fonctionnel, et que si ça permet d'ouvrir les masses au fonctionnel, je suis totalement pour le fait que ce soit partiel.
        • [^] # Re: C# n'est pas un langage à typage fort !

          Posté par (page perso) . Évalué à 6.

          La première c'est l'inférence de type. Ce n'est qu'un de laisser le compilateur définir le type la variable. Plutôt que de l'écrire soit même. Entre:

          Dictionary<string, object> d = new Dictionary<string, object> ();

          et

          var cache = new Dictionary<string, object> ();

          Je sais ce que je préfère. En plus ça force souvent le programmeur à mieux nommer sa variable, pour mieux refléter son but.


          Oui moi aussi, je sais ce que je préfère:

          Dictionary<string, object> cache;

          Finalement, le C++ c'est pas si mal...
          • [^] # Re: C# n'est pas un langage à typage fort !

            Posté par (page perso) . Évalué à 1.

            Finalement, le C++ c'est pas si mal...
            L'avantage c'est qu'on C# t'as le choix entre les 2 syntaxes...
          • [^] # Re: C# n'est pas un langage à typage fort !

            Posté par . Évalué à 3.

            > Finalement, le C++ c'est pas si mal...
            Sûr, qu'est-ce qu'on s'ennuierait ferme sans les

            for(std::map< int, std::vector< std::string > >::const_iterator it = d.begin(); it != d.end(); ++it) { ... }


            C'est tellement plus lisible que

            for(auto it = d.begin(); it != d.end(); ++it) { ... }

            que ce dernier va être ajouté dans le C++
            • [^] # Re: C# n'est pas un langage à typage fort !

              Posté par . Évalué à 4.

              Les typedefs servent à éviter ce genre de choses en C++.
            • [^] # Re: C# n'est pas un langage à typage fort !

              Posté par . Évalué à 3.

              typedef ?
            • [^] # Re: C# n'est pas un langage à typage fort !

              Posté par . Évalué à 1.

              C'est un progrès vers quelque chose de sensé. Peut-être que dans 10 ans ils introduiront le concept de foreach ? :p (et dans trente la citoyenneté de première classe des fonctions, révons un peu !)
              • [^] # Re: C# n'est pas un langage à typage fort !

                Posté par . Évalué à 3.


                int key;
                std::string value;
                BOOST_FOREACH(boost::tuples::tie(key, value), theMap)
                {
                std::cout << key << " => " << value << "\n";
                }
              • [^] # Re: C# n'est pas un langage à typage fort !

                Posté par . Évalué à 1.

                foreach ? c'est dans c+0x aussi :

                http://en.wikipedia.org/wiki/C%2B%2B0x#Range-based_for-loop

                La programmation fonctionnelle (lambda) aussi et bien d'autres choses. bref ça avance, et c'est prévu pour l'année prochaine.

                pour la liste des nouveautés, voir wikipedia version anglaise...
                • [^] # Re: C# n'est pas un langage à typage fort !

                  Posté par . Évalué à 7.

                  J'espère que ce qu'ils considèrent être de la programmation fonctionnelle est autre chose que des immondices illisibles (et accessoirement indébuguable, je parle d'expérience... :/ ) à base de templates qui nécessitent l'emploi d'adaptateurs dans tous les sens pour des raisons techniques dont ne devrait surtout pas se soucier le développeur (ex: mem_fun)

                  histoire de fixer les idées, voici ce qu'on peut lire dans GnuGK :

                  return InternalFind(compose1(bind2nd(equal_to<H225_EndpointIdentifier>(), epId),
                  mem_fun(&EndpointRec::GetEndpointIdentifier)));


                  (où pour couronner le tout InternalFind est bien sûr lui même une template)

                  ce qui signifie à peu près, dans un langage intelligible par un être humain normal et sans à avoir à apprendre des foisons de symboles supplémentaires :

                  return InternalFind(lambda x: (x.GetEndpointIdentifier() == epId))


                  Bref si ça progresse vers quelque chose de moins sataniste que l'exemple cité ci-dessus, c'est une bonne chose. Sinon il faudrait mieux interdire aux gens de faire du mauvais fonctionnel inutile en C++, car ce n'est pas maintenable par quelqu'un qui ne passe pas sa vie à étudier ce langage et ses "subtilités" (pour rester poli).

                  En passant l'emploi d'une approche pseudo fonctionnelle et donc d'une syntaxe aussi biscornue ne se justifiait absolument pas ici en pratique, une boucle avec un return quand l'élément est trouvé aurait été bien plus compréhensible, maintenable et débuguable.

                  La syntaxe et la nécessité de compenser des faiblesse structurelles du langages (mem_fun + besoin de noter explicitement H225_EndpointIdentifier, sans même parler de l'opérateur == qui visuellement n'est plus repérable) disqualifie donc en pratique une approche qui pourtant peut être considérée comme conceptuellement supérieure.
                  • [^] # Re: C# n'est pas un langage à typage fort !

                    Posté par . Évalué à 1.

                    pour faire court,oui !
                    le support de la programmation fonctionnelle sera complètement intégrée au langage avec c+0x, et ceci sans template.
                    Il a même été décidé que les fonctions lambda ne pouvaient pas être templetisées (excuse le barbarisme).
                    Cependant, l'exemple que tu pointes utilise la librairie standard, qui est complètement inutilisable en programmation fonctionnelle, je te l'accorde, car très mal conçue.
                    Je ne peux que t'encourager à lire la documentation de boost::phoenix qui simplifie grandement la syntaxe tout en utilisant des templates, et démontre qu'on peux quand même faire de la programmation lambda avec le c++ actuel, il suffit de bien concevoir la librairie qui l'implemente
                    http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/doc(...)

                    Je suis tout de même d'accord que ceci n'est qu'un canard boiteux, car toujours autant indébuggable si erreur il y a. Mais la prochaine version c+0x va rectifier le tir...
              • [^] # Re: C# n'est pas un langage à typage fort !

                Posté par (page perso) . Évalué à 1.

                #include

                std::for_each(b_it, e_it, functor) ;
        • [^] # SQL et LINQ

          Posté par (page perso) . Évalué à 3.

          C'est une des rares fois ou Microsoft invente, ou tout au moins combine des innovations intéressantes...

          Je me pose la question suivante, est-ce que le LINQ de C#3 est aussi "limité" qu'SQL ?

          Exemple au hasard : j'ai une table T contenant un champ c1, je veux faire une requête SQL qui me renvoi le nombre total de ligne, et le nombre de ligne où c1 est non nul.

          Si je fais un
          select count(t1.c1), count(t2.c1)
          from (select c1 from T) t1, (select c1 from T where c1 is not null) t2


          J'obtient un produit cartesiens des deux tables, normal, c'est un sgbdr.

          Peut-on s'élever des ces limitations avec LINQ ?

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

          • [^] # Re: SQL et LINQ

            Posté par (page perso) . Évalué à 2.

            explique
          • [^] # Re: SQL et LINQ

            Posté par . Évalué à 1.

            une question bête, pourquoi ne pas mettre les count dans les sous-requete ?
            ainsi le prod cartesien ne se fera qu'entre des "tables" de un enregistrement chacun.
            non ?
          • [^] # Re: SQL et LINQ

            Posté par (page perso) . Évalué à 1.

            elle est ou la limitation ? c'est par definition le comportement du sql...
            si tu ne veux pas faire de sql, tu ne fais pas de sql, mais surtout pas quelque chose qui y ressemble ou alors c'est la porte ouverte à un tas de catastrophes
            !
          • [^] # Re: SQL et LINQ

            Posté par (page perso) . Évalué à 2.

            Bon ben t'as pas expliqué :)
            Sinon toi qui est "fan" de langages et d'innovation, tu penses quoi du DLR ?
            http://en.wikipedia.org/wiki/Dynamic_Language_Runtime
            • [^] # Re: SQL et LINQ

              Posté par (page perso) . Évalué à 3.

              C'est un concept intéressant dans un contexte industriel où on a (et j'ai eu) pas mal d'arrachage de cheveux pour faire discuter entre eux des composants écrits dans des langages différents, quand ça n'était pas impossible.
              Ca fera donc gagner du temps à pas mal de gens.

              Après, je trouve pas ça transcendant du tout, c'est même le minimum qu'on puisse attendre d'une machine virtuelle, sachant que la mode actuelle consiste à se restraindre aux machines virtuelle en en acceptant les défauts, autant en retirer tous les avantages..

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

            • [^] # Re: SQL et LINQ

              Posté par (page perso) . Évalué à 1.

              En fait c'est difficile à expliquer... J'ai pas encore très bien formalisé le problème.

              J'adore SQL, les regexp, Caml dans son aspect filtrage de type + type somme, bref tous ces "métalangage" où je me contente de définir en déclaratif ce que je veux obtenir sans me prendre la tête à expliquer à la machine comment elle va faire.

              Mais SQL a de nombreuses limites en fait, surtout quand tu essayes de faire des stats et autres requetes assez poussées. Je me rend compte que la nature relationnelle de ce langage limite pas mal de choses. J'en produisai un exemple.

              Ce qui peut être potentiellement intéressant dans des langages comme LINQ, c'est qu'il a connaissance de la structure des données, comme si SQL avait connaissance du MLD.

              Falloir que je regarde ça et passe quelques mois à réfléchir à ça, mais je sais pas encore trop formaliser ça... Je cherche un langage d'interrogation de données qui puisent déterminer des patterns, des formes, des séquences.
              Ca touche à la reconnaissance de forme, ça peut aller très loin....

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

              • [^] # Re: SQL et LINQ

                Posté par . Évalué à 3.

                J'adore SQL, les regexp, Caml dans son aspect filtrage de type + type somme, bref tous ces "métalangage" où je me contente de définir en déclaratif ce que je veux obtenir sans me prendre la tête à expliquer à la machine comment elle va faire.

                hm est-ce que ça "mérite" vraiment le titre de "metalangage" parce que c'est plutôt déclaratif qu'impératif ? Utilisé à bon escient c'est certes très supérieur à un spaghetti impératif buggué et 30x plus long, mais je vois pas pourquoi ça serait "méta" pour autant ? Je mettrais plus volontier du "méta" sur les trucs du genre bison.
            • [^] # Re: SQL et LINQ

              Posté par . Évalué à 1.

              En lisant tes posts, j'ai l'impression que tu as lu récemment un article sur le DLR avec l'enthousiasme du vendeur de lavelinge qui découvre un nouvel argument pour impressioner les ménagères et que du coup tu le ressors dès que possible :-)
              • [^] # Re: SQL et LINQ

                Posté par (page perso) . Évalué à 3.

                Euh, c'est la première fois que j'en parle. Techniquement je trouve la chose bien conçue et bien pensée, après j'utilise pas, je suis pas fan des langages dynamiques.
                • [^] # Re: SQL et LINQ

                  Posté par . Évalué à 1.

                  Tu l'as sorti deux fois dans la dépêche et dans trois posts :-)
        • [^] # Re: C# n'est pas un langage à typage fort !

          Posté par . Évalué à 5.

          IEnumerable big = from a in args where arg.Length > 10 select arg.ToUpper ();
          Tiens, ça me fait penser à la syntaxe des générateurs en python (d'ailleurs doit y avoir une faute dans ton code, c'est "from arg in args", non ?) :
          big = (arg.upper() for arg in args if len(arg) > 10)
          • [^] # Re: C# n'est pas un langage à typage fort !

            Posté par (page perso) . Évalué à 2.

            Oui hein, ça fait penser à ça. On peut aussi montrer comment une fois que c'est décomposé, ça ressemble à d'autres langages.

            Voir les slides 15 à 18 de: http://evain.net/conf/Db4oLinq-dUC08.pdf

            Et bien vu pour l'erreur :)
            • [^] # Re: C# n'est pas un langage à typage fort !

              Posté par . Évalué à 2.

              Ce qui me fait marrer dans tes slides, quand même, c'est que ça a beau être une syntaxe SQL, derrière, ça fait un bon gros foreach ... on a vu plus efficace en BDD.
              • [^] # Re: C# n'est pas un langage à typage fort !

                Posté par (page perso) . Évalué à 5.

                Et bien ça dépend de l'implémentation. Si tu travailles en LINQ to Objects, donc en mémoire, le moyen `standard` d'itérer sur un flux d'objets, c'est d'utiliser le même mécanisme qu'un foreach: les énumerateurs.

                Par contre, dans le cas où tu implémentes un provider LINQ, que ce soit vers un SGBDR, ou une autre source de données, et bien non, il ne va pas y avoir récupération de toutes les données puis filtre en mémoire.

                LINQ va te permettre de récupérer une meta-requête, donc une représentation du code de la requête, qu'on appelle entre nous un expression tree. Et on va donc à partir de cette représentation du code C#, créer une requête correspondante, pour la source de données sous-jacente, donc du SQL, ou autre.
        • [^] # Re: C# n'est pas un langage à typage fort !

          Posté par (page perso) . Évalué à 1.

          var cache = new Dictionary<string, object> ();

          Concernant l'inférence de type justement, une question me turlupine en lisant ces lignes : les IDEs retrouvent-ils leurs petits lorsqu'on l'utilise, je pense notamment en terme de propositions de complétion automatique adaptée au type manipulé.

          C'est juste une question hein, je me mets tout juste à Mono par curiosité, mais je dois dire que ce que j'adore avec un langage comme Java, c'est précisément la rigueur syntaxique qu'il impose.
          • [^] # Re: C# n'est pas un langage à typage fort !

            Posté par (page perso) . Évalué à 2.

            Oui, les IDEs comme le compilateur vont ici faire le même travail, regarder le type de l'expression à droite de l'affectation. Ensuite on peut aimer la rigueur de Java et de C# tout en appréciant un côté moins verbeux.
            • [^] # Re: C# n'est pas un langage à typage fort !

              Posté par (page perso) . Évalué à 1.

              Ben en C#, je ne sais pas, mais en Java -que je pratique depuis un sacré bon moment- il m'arrive extrêmement souvent de décorréler la déclaration d'une variable de son initialisation : d'où ma question. Celà veut-il dire que cette inférence de type est réservée aux cas où ces deux phases sont co-localisées ?
              • [^] # Re: C# n'est pas un langage à typage fort !

                Posté par (page perso) . Évalué à 2.

                Bah oui, si ta variable a un type différemment que l'expression que tu veux lui assigner, il vaut mieux spécifier son type manuellement. Genre:

                IEnumerable<string> persons = GetPersonList (...);

                Où GetPersonList renverrait un type concret, genre List<string>.

                Encore une fois, l'inférence de type n'a rien de magique, et n'est utile que dans certains cas.
  • # F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

    Posté par Anonyme . Évalué à 1.

    Tout ce que je me permettrai de dire c'est que F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques dont j'aurais du mal à me passer.

    Les débats techniques et philosophiques échapent à ma compréhension, j'attends de voir les réactions ici :D
    • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

      Posté par (page perso) . Évalué à 2.

      f-spot est facilement remplacé par digikam

      strigi est plus rapide que beagle

      kjots, knowit, basket pour tomboy

      est-ce que mono va diviser la communauté gnome en 2 et donc un fork?

      www.solutions-norenda.com

      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

        Posté par . Évalué à 6.

        Pourquoi tu cherches à nous refourger tes alternatives, moi aussi j'adore F-Spot, Tomboy et Banshee, je n'ai pas envie d'en changer, libre à toi de ne pas les utiliser.
      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

        Posté par . Évalué à 1.

        GNOME est facilement remplacé par KDE. Pourquoi est-ce qu'on garde GNOME ? Parce qu'il est différent.

        C'est la même chose pour ces applis, chacun est libre de les utiliser.

        De toute façon :
        * je n'aime pas digikam, à cause de son choix d'utiliser une arborescence,
        * désolé, je n'arrive pas à trouver Strigi rapide; de toute façon, avec une DB qui prend la moitié de mon disque, je n'ai pas la place pour l'utiliser,
        * j'ai déjà essayé Basket, c'est vrai que c'est sympa, mais je n'arrive qu'à produire des trucs un peu fouillis face à la rigueur que j'ai naturellement avec Tomboy.

        Elles restent de très bonnes applications (bien que je demande à voir pour Strigi...), mais je n'arrive pas à être efficace avec elles.

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

      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

        Posté par . Évalué à 1.

        Oui F-spot peut être remplacé par Digikam, mais l'inverse est également vrai !

        Puisque je préfère largement l'interface de F-spot, j'utilise... F-spot.

        Tomboy est moins complet que Basket, mais il est aussi beaucoup moins bordélique et plus agréable à utiliser. Il lui manque juste l'inclusion de photos et un où deux trucs plus anecdotiques.

        beagle en revanche s'avère être beaucoup plus lourd qu'un strigi ou un tracker. Ce qui est gênant pour un outil qui passe son temps à scanner les modifications sur le système de fichier.
        • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

          Posté par Anonyme . Évalué à 1.

          Oui Beagle était vraiment plus lourd il y a quelques temps et j'ai utilisé Tracker pendant des mois.

          Depuis quelques jours je suis repassé à Beagle et il est beaucoup plus léger qu'avant.

          Surtout, je me suis rendu compte que Tracker ne me trouvait finalement jamais rien (ou presque) alors que les résultats de Beagle sont vraiment pertinents.

          En attendant que Tracker s'améliore, mon choix est fait !
          • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

            Posté par . Évalué à 1.

            Cela est bon à savoir !

            En effet, les résultats de Tracker ne m'ayant jamais sevrit de rien, je ne l'ai jamais vraiment utilisé...
          • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

            Posté par . Évalué à 10.

            Petite question, vous utilisez souvent ce genre d'outils ?
            Parce que personnellement, mais fichiers, je sais où ils sont rangé, et j'ai plus vite fait d'aller les choisirs dans mon arborescence plutôt que de lancer une recherce, et ensuite rechercher dans les résultats de la recherce.

            Personnelement, je désactive toujours tracker sur ubuntu, et je ne l'installe pas sur arch. Vu que l'indexation, logiquement, prend quand même des ressources et que je ne m'en sert jamais.

            Et vous qui l'utilisez, est-ce parce que c'est le gros borlel dans votre ordinateur, où est-ce que ça apporte quelque chose auquel je ne pense pas (et qui pourrait donc finallement m'apporter quelque chose).
            • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

              Posté par . Évalué à 3.

              Personnellement, c'est un peu les deux :-)

              D'un côté, j'utilise une arborescence assez précise parce que j'ai énormément de fichiers, mais j'ai la flemme de retraverser les 42 niveaux de celle-ci, alors je tape le début du nom et j'ai le fichier dont j'ai besoin. Ça n'empêche pas la rigueur, mais ça fait gagner du temps.

              D'un autre côté, c'est bien plus permissif, ce qui fait que « j'oublie » de ranger les nouveaux fichiers, puisque j'y accède sans avoir à les chercher.

              En fait mon problème, c'est surtout la fainéantise de ranger. Ce genre d'outils est parfait pour moi ;-)

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

            • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

              Posté par (page perso) . Évalué à 5.

              >>> Personnelement, je désactive toujours tracker sur ubuntu

              Pareil. Je range mes fichiers donc je sais ou ils sont. Pas besoin de ce truc d'indexation qui boulotte des ressources.
              • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                Posté par (page perso) . Évalué à 7.

                Oui tu ranges tes fichiers mais le problème, c'est que tu es bien obligé d'adopter une certaine sémantique pour la hiérarchisation de tes fichiers, sémantique sur laquelle tu vas t'appuyer lorsque tu vas vouloir retrouver une information plus tard. Le problème, c'est que cette sémantique n'est qu'un des aspects du contenu de tes fichiers; tu peux vouloir retrouver des informations sans que les critères de recherche ne correspondent à ta façon de trier tes fichiers, et là t'es chocolat.
                Personnellement, en tant que développeur, je me sers très souvent de locate/updatedb.
                Je considère que les outils graphiques comme Beagle ou Tracker en sont des versions plus élaborée, ou en tout cas, plus user friendly.
                • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                  Posté par . Évalué à 4.

                  D'où l'intérêt d'une gestion des tags sur le système de fichiers lui-même.
                  Ce qui m'étonne, c'est qu'en plus, il me semble que c'est d'une certaine façon assez simple à mettre en place grace a un outil trop peu utilisé : le lien « dur ».

                  En effet, je m'étais déjà amusé à faire un dossier avec des tags à l'intérieurs. et je faisais des liens des fichiers d'origine. Mais ça pourraît être fait de façon plus ergonomique.

                  J'ai d'ailleurs le projet (mais là, je vais galérer), de faire un outils qui recréerait l'arborescence des tags de f-spot d'un un dossier du système, ce qui permettrait de facilement récupérer les photos depuis n'importe quel application.

                  Le truc très chiant pour les liens en dur est que maintenant, je crois que presque aucun des gestionnaire de fichiers ne le gère (nautilus, konqueror, thunar, etc).
                  Pourtant, ça apporte quelque chose en plus que le lien symbolique et ça peut être très pratique pour crée une arborescence par tags.
                  • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                    Posté par (page perso) . Évalué à 5.

                    Le lien dur est mal-aimé parce qu'il casse la métaphore du dossier/répertoire.

                    J'explique:

                    Pour les gens, "rm fichier" signifie "effacer le fichier". D'ailleurs on utilise souvant rm pour faire de la place. La blague, c'est que ce n'est pas du tout ce que signifie rm. rm signifie: supprimé l'enregistrement de ce fichier dans ce repertoire, et si le fichier a zéro enregistrement, supprimer le fichier.

                    Tu vois donc venir le problème. Pour les gens, un repertoire/dossier, c'est un casier dans lequel ils rangent leurs fichiers. Dans la métaphore du bureau, comme dans la réalité, un fichier ne peux pas être dans deux dossiers en même temps. C'est en ça que le lien dur "casse" la métaphore du bureau, parce qu'a partir du moment ou un fichier a plusieurs liens durs, il cesse de se comporter comme son alter-égo de la vrai vie.

                    D'ou le succès du liens symbolique, qui ne pose pas ces tracasseries

                    ( ça ne veut pas dire qu'on ne peut pas jouer et faire des trucs très sympa avec les liens durs... )
                    • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                      Posté par (page perso) . Évalué à 1.

                      il parait qu'il faut aussi éviter de jouer avec des liens durs entre 2 systèmes de fichiers : ca fait des casses têtes à résoudre.
                      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                        Posté par . Évalué à 5.

                        Ce n'est même pas que c'est a éviter, c'est simplement impossible, un lien en dur, c'est de pointeur dans la table d'index du système de fichier qui pointe vers les même secteurs. (n'ayant pas trop de connaissance dans le dommaine, les termes employés sont donc peut-etre très mauvais). L'index ne peut donc pointer que dans son propre système de fichiers.
                      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                        Posté par (page perso) . Évalué à 3.

                        Ça ne marche tout simplement pas ...
                        Un autre truc qui ne matche qu'en root, c'est les liens des dossiers.

                        J'aime bien les liens symboliques, mais j'aimerais bien qu'ils puissent être mis à jour lorsque l'original bouge. J'aimerais bien voir un jour sur ma machine une daemon accessible via dBus, à qui on pourrait donner des chemins vers des liens symboliques qu'il tenterait de mettre à jour automatiquement (en utilisant inotify sans doute). Et probablement qu'il serait même possible de rajouter dans les métadonnées du lien symbolique le UUID du média où se trouve l'original et le numéro d'inode, comme ça se serait même possible de réparer un lien symbolique pointant vers un fichier sur un autre média (comme une clef usb ou un disque dur externe par exemple). Leur réparation devrait sans doute se faire au montage du média concerné.

                        Bon, après je n'ai pas encore trouvé le langage de programmation parfait pour implémenter ça, mais ça devrait venir un jour.
              • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                Posté par . Évalué à 6.

                Le problème c'est que tu dois choisir une hiérarchie de fichiers, alors que plusieurs hiérarchies peuvent être pertinentes.

                Typiquement, j'ai des articles d'informatique, des articles de biologie, et dans ces deux catégories certains parlent d'ARN, certains d'autres choses. Je peux avoir envie de sélectionner tous les articles d'informatique, tous les articles de biologie, ou bien tous ceux qui parlent d'ARN, mais il n'y a pas de hiérarchie de fichiers qui me permette de faire ça avec un "ls". Sur un exemple simple on peut s'en sortir mais à l'échelle de tout un système de fichier ça peut être plus problématique.

                Le problème est résolu en utilisant un DAG ("des tags") plutôt qu'un arbre, ce qui peut être fait soit en utilisant un logiciel spécial soit en créant à la main des liens durs. Je pourrais ainsi avoir le même article présent dans plusieurs dossiers. Dans les deux cas, il faut taguer à la main.

                Le principe des indexeurs c'est d'essayer de te donner un moyen de faire une requête pour obtenir n'importe quelle "tranche" de tes données sans avoir besoin de spécifier à la main avant que toutes ces données appartiennent à cette tranche. Comme il m'arrive régulièrement de devoir chercher dans plusieurs dossiers pour obtenir une tranche de données, je me dis que c'est utile.
              • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                Posté par . Évalué à 2.

                Tant mieux pour toi si t'es capable de savoir tres precisement ce que contient ton disque de 200+Go, et ou se trouve precisement chaque fichier.

                Perso, meme en m'organisant, j'en suis pas capable, et je suis tres content d'avoir spotlight pour me retrouver des bouts de trucs quand me memoire me fait defaut.

                C'est tres pratique aussi quand tu cherches un fichier que t'es pas sur d'avoir efface: si pas trouve, il a ete efface.
                • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                  Posté par . Évalué à 3.

                  J'ai un To sur mon serveur.
                  Pour le rangement :
                  – Les photos sont regroupées (gérer pour l'instant avec F-Spot)
                  – Les isos de mes DVD sont dans un dossier aussi
                  – Les musiques ont elles aussi leur dossier (gérer par Rhythmbox ou gmpc)
                  – Les documents de bureautiques sont regroupés aussi (avec des sous-cathégories)
                  – Un dossier divers avec les Images Isos de distrib, les pkgbuilds personnels etc

                  Bref, il n'y a pas 150 types de fichiers non plus, et les organiser pour que tout soit retrouvable très rapidement, je trouve que c'est plus que gérable. De plus, j'ai plus confiance dans le classement pour savoir si j'ai bien supprimé où pas un fichier qu'un moteur de recherche dont j'ai toujours la crainte qu'il ai laissé passé quelque chose (erreur de français en ayant tappé le nom d'origine par exemple qui fait qu'on ne le retrouve pas).

                  Après, je connais des tas de gens qui ont tout leur fichiers en bordel directement dans le home, et qui s'y retrouve juste parce que les programmes utilisés (pour la musique, les images etc) filtrent le contenue. Mais très souvent, ils ne savent pas trop ce qu'ils ont dans l'ordinateur.
                  • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                    Posté par . Évalué à 2.

                    Meme en etant tres organise, le nom du fichier ne te dira jamais ce qu'il contient precisement.
                    Ta musique, tu la ranges par artiste/album?
                    Ok, mais si t'as un cd qui est une compile d'artiste, il va etre eparpille sur plusieurs dossiers.

                    Tu peux classer par album dans ce cas.
                    Ok, mais si tu veux voir dans ton explorateur tous les morceaux qui sont d'un meme artiste (pour les copier sur un cle usb pour les filer a un pote par exemple), t'es marron.

                    Bref, tu vois ou je veux en venir, t'as plusieurs chemins possible pour arriver a un meme fichier, et le classement par arborescence ne te donne qu'une possibilite sur plusieurs.

                    Seule une recherche precise peut le faire, et sur le contenu qui plus est.
                    De meme, devoir ouvrir 15 pdf pour chercher ce que je veux, c'est pete couille honnetement.
                    • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                      Posté par . Évalué à 2.

                      D'où l'avantage que procurerai une gestion des tags (ou déjà juste des liens en dur)
                      Après dans l'avantage que peuvent avoir les « trackers », c'est ce que dis ta première phrase, c'est la recherche dans le contenu et pas seulement dans le nom des fichiers.
                      Mais la recherche dans le contenu des fichiers est efficace et rapide ? (ça me semble énorme comme traitement)
                      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                        Posté par . Évalué à 3.

                        Mais la recherche dans le contenu des fichiers est efficace et rapide ? (ça me semble énorme comme traitement)

                        Ben, justement, c'est la ou les spotlight, beagle et consorts sont interessants, ta recherche de contenu est diablement rapide, vu que ce n'est qu'un select sur des mots cles.
                        Evidemment, tu ne vas pas indexer chaque mot de chaque fichier, mais en pratique ca marche plutot pas trop mal (on va dire que c'est indexe a la google quoi).
                        Ca implique d'indexer le fichier quand il est creer/modifier. Comment ca marche precisement, je sais pas trop, un hook sur l'appel au systeme de fichier?

                        Bon beagle, je connais finalement pas, mais le spotlight d'Apple est foutrement efficace a ce niveau.
                        L'overhead de ressource ne me parait meme pas si grand que ca: spotlight tournait admirablement bien sur mon g4/768Mo et le systeme avait encore une grosse marge de manoeuvre.
                        Si beagle ou autre sont des gouffres a ressources, c'est plus une question d'implementation que de concept.
                      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                        Posté par . Évalué à 1.

                        Qu'attends-tu exactement d'une gestion des liens dur dans les gestionnaires de fichiers ? Il me semble qu'ils sont complets à ce niveau là.

                        Si tu t'attends à ce qu'il puisse te donner tous les nom de liens correspondant à une i-node donnée, sache que ce n'est pas possible sans scanner tout le système de fichier. Cela m'étonnerait qu'ils implémentent cette fonctionnalité qui ne doit guère intéresser qu'une infime partie des utilisateurs et qui aurait une lenteur d'exécution désespérante.

                        Sinon, il paraît que chez kde, ils construisent des outils pour le "desktop sémantique" en s'appuyant sur les tags. Par contre, je ne sais pas du tout où cela en est, ni si c'est stable, péren ou utilisable. Si quelqu'un pouvait commenter là dessus :-p
                    • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                      Posté par (page perso) . Évalué à 0.

                      Moi mon dossier musique ce décompose comme ça :
                      * non-free : quelques bootlegs que j'ai enregistré et des morceaux de quelques connaissances, comme l'album de mon beau-frère[1]
                      * free : dans lequel on trouve les sous répertoire lal[2] (licence art libre), cc-by, cc-by-sa
                      * compos : répertoire où j'enregistre mes compositions

                      J'avais aussi un répertoire non-non-free où je mettais les cc-by-nc et cc-by-nd, mais je l'ai viré, j'ai toute manière déjà pas le temps d'écouter tout ce qui ce fait en libre pour en accorder à des œuvres qui ne le sont pas.

                      Mis à part ça je n'ai pas de sous arborescence tout est rangé comme cela. La notion d'album ne présente la plupart du temps qu'un faible intérêt pour moi en tant qu'auditeur. Et quand c'est le cas, les logiciels d'écoute s'occupe de gérer ces classements via les tags dans les fichiers (perso j'utilise sonata comme client mpd).

                      Si je veux copier les morceaux d'un même auteur, un petit "cp" avec l'expression régulière idoine et c'est réglé (sachant que dans le nom de fichier il y a le nom de l'auteur). Cela dit, je fais plutôt des copies sur DVDs pour filer à mes amis, et, ô miracle, le logiciel de gravure permet d'enregistrer des projets histoire de ne pas se casser la tête à refaire les mêmes tries à chaque fois. :)

                      Voila, sinon, moi je dis ça juste comme ça, histoire de raconter ma façon d'aborder le classement de la musique. Personnellement j'ai rien contre l'indexation. Moi je n'en ressent pas le besoin, mais si il y a des gens à qui ça plaie et qui en ont l'utilité, c'est très bien pour eux que ça existe.

                      [1] http://www.dmute.net/chronique-album-22050_-_Elvire_-_Elvire(...)
                      [2] Sachant que tout ce que contiens ce répertoire peut se retrouver ici : http://download.tuxfamily.org/cls/ , le libre c'est bien pour les copies de sauvegarde, mangez en.
            • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

              Posté par (page perso) . Évalué à 3.

              Parce que personnellement, mais fichiers, je sais où ils sont rangé, et j'ai plus vite fait d'aller les choisirs dans mon arborescence plutôt que de lancer une recherce, et ensuite rechercher dans les résultats de la recherce.

              Je vois cet argument revenir assez fréquemment.
              Le truc, c'est qu'on a tous des dizaines de milliers de fichiers sur les PC d'aujourd'hui.
              Les outils comme Beagle ont le même rôle que lorsque tu veux par exemple retrouver un morceau de musique dans ta bibliothèque en ne te souvenant que d'une partie du nom du morceau ou juste de l'auteur, tu commences à le taper et instantanément tu as un filtre qui ne va te sélectionner que les albums qui contiennent ce morceau de texte que tu as tapé, tout cela sous forme contextualisée.
              C'est pareil pour beagle, tu te souviens qu'un gars t'avait envoyé un mail qui concernait par exemple un problème sur une version de la zlib, bah tu tapes "zlib" et tu as instantanément tous les courriers avec le contexte, ainsi que les fichiers texte, les doc, etc.
              Je suis d'accord que si le résultat n'est pas au moins quasi-instantané, ça perd pas mal de son intérêt.
              • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                Posté par (page perso) . Évalué à 3.

                >>> lorsque tu veux par exemple retrouver un morceau de musique dans ta bibliothèque

                Je le cherche avec l'interface de recherche de Rhythmbox et ça marche super bien tout en étant super rapide. En plus c'est spécialisé pour la musique de ma bibliothèque.

                >>> tu te souviens qu'un gars t'avait envoyé un mail qui concernait par exemple un problème sur une version de la zlib

                Utilisant Gmail là-aussi je cherche directement dans Gmail pour avoir le résultat.
                Plus généralement si tu organise ton disque dur de façon assez rationnelle et que tes fichiers ne "bougent" pas beaucoup (peu de turn over de fichiers sur ton disque) alors les outils d'indexation perdent pas mal de leur utilité.
                Je me suis astreint à utiliser tracker pendant une période d'environ 2 mois afin de voir si le bénéfice couvrait le coût mais je n'ai pas été convaincu (pour mon usage à moi, c'est évident que d'autres personnes auront un grand intérêt à utiliser tracker ou beagle).
                • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                  Posté par . Évalué à 5.

                  Finalement, tu utilises des indexeurs spécialisés plutôt qu'un indexeur généraliste...

                  La vision derrière l'indexeur généraliste, c'est de te fournir les mêmes avantages que tes indexeurs spécialisés, mais de pouvoir te permettre en plus de ressortir des données de types différents ayant un lien. Pour prendre un exemple simpliste, si je me souviens qu'un ami m'a parlé de quelque chose au sujet de l'anniversaire de Roger, mais si je ne me souviens pas s'il m'en a parlé par email, sur IRC ou sur Jabber/MSN/autre, avec un indexeur généraliste je vais faire une requête "anniversaire de Roger", là où avec des indexeurs spécialisés j'aurais dû en faire trois.
              • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                Posté par (page perso) . Évalué à 3.

                retrouver un morceau de musique dans ta bibliothèque en ne te souvenant que d'une partie du nom du morceau ou juste de l'auteur

                C'est le rôle de mon jukebox, ça. Mais sinon, vu que je range :
                $ ls multimedia/musique/*<bout du nom de l'artiste>*/*/*<bout du nom du morceau>*

                tu te souviens qu'un gars t'avait envoyé un mail qui concernait par exemple un problème sur une version de la zlib

                Moi, je fais ça comme ça (le premier qui me dit que c'est compliqué, je tire) :
                $ rgrep zlib ~/Maildir
                • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                  Posté par (page perso) . Évalué à 1.

                  C'est pas compliqué, mais en tout cas chez moi c'est très très long (car je le fais de temps en temps, parfois ça a même fini par faire planter ma machine). En général je me souviens où c'était avant que le grep ait fini et je le tue.

                  Mais en même temps, j'ai beaucoup de mails:

                  $ du -hs Mail
                  2.8G Mail
            • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

              Posté par (page perso) . Évalué à 3.

              J'utilise très peu ce genre d'outils pour mes fichiers (j'utilise plutôt la hiérarchie dans le système de fichiers). C'est vraiment à l'occasion si je ne retrouve pas un des fichiers...

              Par contre... je fais indexer les /usr/include, /usr/local/include et consor... et c'est génial pour le développement en C/C++.
            • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

              Posté par (page perso) . Évalué à 2.

              Bonjour,

              Tout dépend de ce que tu fais avec ton ordinateur.

              Personnellement, je ne peux plus vivre sans un tel outil.

              Ce genre d'outil trouve surtout son intérêt, à mon sens, pour une utilisation bureautique de l'ordi.
              J'ai des centaines de fichiers textes, et des dizaines de PDF. Alors certes, ils sont en général bien rangés dans mon arborescence, et j'essaye de leur donner des noms le plus explicites possible.
              Mais régulièrement, je me demande « dans quel texte j'avais parlé d'Opera 9.5 ? » ou « dans quel PDF j'avais lu cet article sur le Dell Inspiron 2110 ». Et là, crois-moi, crois-moi, un outil qui sait fouiller à l'intérieur de tes documents, instantanément, ça prend tout son sens !

              Ensuite, c'est vrai que pour fouiller dans ma musique, mes mails ou mes contacts, je préfère utiliser les moteurs intégrés à Rhythmbox ou Evolution, mais au final, ils font la même chose que Beagle : organiser une base dans laquelle on peut fouiller plus profondément que le simple rangement.

              Maintenant, c'est vrai que ces outils restent quand même particulièrement lourds, et pas très faciles à utiliser :
              - Beagle/Kerry : trop lourd pour mon bon vieux PC du boulot ;
              - Strigi et Tracker, j'ai jamais réussi à les utiliser (sous Mandriva 2009, je comprends pas comment on les installe/configure/utilise en interface graphique)
              - Alors pour l'instant, je suis passé à Google Desktop. Il est pas libre, je sais, mais il est léger (sauf pour la création initiale de la base, qu'il vaut mieux laisser travailler la nuit, mais c'est normal) et efficace, c'est ce qu'il me faut pour l'instant.
            • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

              Posté par Anonyme . Évalué à 2.

              J'utilise assez souvent, parce que j'ai fini par accumuler près de 10 Gb de doc (pdf, doc).

              Donc même avec une bonne organisation, l'indexation du contenu est indispensable pour que cette doc soit efficace !
              • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

                Posté par (page perso) . Évalué à 3.

                Je plussoie sur l'utilisation. Au boulot je me suis installé GoogleDesktop, le gain de productivité est juste _énorme_, avec deux scénarios d'utilisation :

                1. Retrouver des mails : avant je classais tout dans des dossiers et sous-dossiers, et je retrouvais plus rien : encore dans la boite courante, traité ? avec quelle sémantique ?

                Maintenant je laisse dans ma boite courante tout ce qui est à faire (en ce moment 266 mails) et j'archive dans un seul répertoire "Reçus" tout ce qui est traité (3 Go de mail sur 3 ans). Avec une recherche Google Desktop je retrouve instantanément tous mes mails : qui contiennent certains mots, envoyés par une certaine personne, etc, ....

                2. Indexer des partages de dossiers (10 Go et plus sans pb) : on paramètre pour qu'il indexe un partage auquel on accède souvent. Ensuite on peut TOUT chercher très facilement depuis son poste, éventuellement en mode déconnecté avec un cache qui a récupéré le texte (si c'est un ppt par exemple).

                => Je gagne des heures entières par mois : plus de classement, plus de recherche manuelle, plus de perte de temps lorsque je suis au tél avec des interlocuteurs : je retrouve les infos plus vite que vite ! Je rêve d'une techno libre aussi simple d'utilisation et aussi puissante ! Ca arrive et c'est tant mieux.
          • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

            Posté par . Évalué à 1.

            «Oui Beagle était vraiment plus lourd il y a quelques temps et j'ai utilisé Tracker pendant des mois.

            Depuis quelques jours je suis repassé à Beagle et il est beaucoup plus léger qu'avant.»

            Je confirme ! Je viens de tester la version 0.3.7 sur Lenny :l'indexation fut rapide et sans surcharges. Les recherches sont véloces et les résultats meilleurs que dans mes souvenirs. Que ce soit pour tracker ou F-spot que je n'avais jamais vraiment utilisés au quotidien.

            Je révise mon jugement. Cet outil pourrait enfin m'être utile ! Merci !
      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

        Posté par . Évalué à 10.

        est-ce que mono va diviser la communauté gnome en 2 et donc un fork?

        Oui, on va avoir le Gnome traditionnel avec tout codé en C, le Gnome « suppôt de MS » codé en Mono, le Gnome « les espaces sont importants » codé en Python, le Gnome « j'utilise un vrai langage » codé en Ruby, le Gnome « SWING c'est beau » codé en Java, et aussi probablement quelques autres.
      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

        Posté par . Évalué à 3.

        s/digikam/kphotoalbum/ qui est plus le pendant de f-spot.

        beagle a disparu pour ainsi dire dans les distribs pour etre remplace par tracker...
    • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

      Posté par (page perso) . Évalué à 3.

      Gnome-Do aussi, moi c'est simple, je ne peux plus m'en passer.
    • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

      Posté par . Évalué à 2.

      j'utilise fspot et bien dans le genre je te bouffe ton processeur en 2 sec c'est pas mal ..

      les fonctionnalités son intéressantes, , manque juste un export entre deux machines linux, mais les performances sont à chier
      sur macbook pro ubuntu 3 Go 2.16 Core duo ...

      alors sur le pc 2 Go et celeron d430 je te raconte pas ...

      tout ça pour des photos, on dirait les vieilles versions de iphoto sur mac .


      Le problème de digikam c'est que j'ai l'impression qu'il t'installe la moitié de KDE ;-)
      • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

        Posté par (page perso) . Évalué à 1.

        Gthumb est la solution. Gthumb est le messie. Gloire à Gthumb !!!!
        • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

          Posté par (page perso) . Évalué à 4.

          Tout pareil.
          Je n'aime pas que F-Spot exporte mes photos dans son arborescence à lui... Je suis encore de l'ancienne génération, et j'aime contrôler l'arborescence de mon disque, et retrouver quand je le veux des photos par mon explorateur de fichiers, sans avoir à passer par le logiciel de photo (ici, F-Spot, donc). Typiquement, F-Spot ne peut pas renommer un fichier, ce que je trouve hallucinant !
          C'est pour ça que j'aime Gthumb comme le Messie - « J'ai un ami, c'est Gthumb ! Puis-je vous en parler ? », me surprends-je même à demander à mes voisins de métro, avec un sourire niais...
          • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

            Posté par . Évalué à 1.

            Je suis d'accord sur ce point, c'est LE défaut de F-spot.

            J'aime aussi beaucoup Gthumb, il fut pendant longtemps mon visionneur d'images favoris. Mais quelques fonctionnalités lui manque (pour mon usage personnel), même si sur quelques points il est supérieur à F-spot (et beaucoup plus mûr). Je pense tout particulièrement à sa vitesse, et ses outils de traitement en masse des images qui sont aussi simples que puissants.
          • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

            Posté par Anonyme . Évalué à 2.

            Ben c'est simple ! A l'import il y a une case à cocher pour ne pas créer de copie !?

            C'est vrai qu'il est lourd quand on applique des traitements par lots sur plusieurs images, mais sinon c'est fluide chez moi (core 2 duo 2,2 Ghz).

            Pareil que Beagle : tant que je ne connais pas de soft plus rapide avec des fonctionnalités identiques, je reste sur F-spot... Faute de mieux c'est vrai mais c'est déjà pas si mal !
        • [^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques

          Posté par . Évalué à 1.

          tout pareil!
          Ce que j'aime bien en plus avec Gthumb, c'est qu'il reconnait les petites videos prises avec l'appareil photo et les signale avec une icone particulière, alors que F-spot => il faut importer séparément la video.
  • # Tire de l'annonce sur slashdot!

    Posté par . Évalué à 10.

    InternetNews points out that only about half of the .NET apps out there will work on Mono 2.0, for a variety of reasons including (but not limited to) legacy Windows-only libraries and Microsoft's progress on .NET 3.0 and 3.5 APIs.

    Je rigole doucement en lisant cela comme prevu mono sera toujours a la traine et en retard d'un train. C'est rigolo comme cela rappelle "legerement" les formats de documents MS Office...

    http://www.internetnews.com/dev-news/article.php/3776201/Is+(...)
    • [^] # Re: Tire de l'annonce sur slashdot!

      Posté par . Évalué à -1.

      Comme prévu, toujours le même argument débile qui ressort. Mono ne sera et n'a jamais été à la traîne de quoi que ce soit puisqu'il propose son propre jeu de bibliothèques en plus des bibliothèques compatible .NET.
      • [^] # Re: Tire de l'annonce sur slashdot!

        Posté par . Évalué à 1.

        Ah donc arriver a ne faire tourner que la moitie des applis c'est une compatibilite suffisante? En gros c'est comme si tu disais que un compilo C arrive a compiler 50% des logiciels ecrit en C mais par contre dans tout tes logiciel tu aurais en prime un tetris il serait fabuleux... Drole de point de vu.
        • [^] # Re: Tire de l'annonce sur slashdot!

          Posté par (page perso) . Évalué à 6.

          C'est surtout que tu ne connais pas .net. L'un des buts avoué de .net, est une très bonne interopérabilité avec l'existant natif. Et ce, en particulier grâce à ce mécanisme de Platform Invoke.

          Et donc, beaucoup d'applications .net sont construites sur de l'existant natif, voir même, utilisent directement des fonctions et des primitives spécifiques à leur environnement.

          Donc oui, certaines applications ne sont par définition non portable. Ajoute à ça que certains développeurs sont peu regardant sur comment écrire du code cross-platform, et voilà. Mais au final, c'est le même problème avec les applications Java + JNI qui utilisent du code natif non portable.

          Et puis ça va dans les deux sens. Une application Mono écrite spécifiquement pour Linux en utilisant certaines fonctionnalités spécifiques à Linux ne sera pas forcément portable vers Windows.

          Donc c'est un problème du niveau de l'application, pas de la plateforme, pour la plus part des cas. Après bien sur, il reste des bugs et des librairies non implémentées, mais c'est loin de représenter le gros des applications non portables.
          • [^] # Re: Tire de l'annonce sur slashdot!

            Posté par . Évalué à -1.

            Tu as surtout pas lu le lien que j'ai donne ou c'est un dev de mono qui dis lui meme que la compatibilite est de 50% (elle etait de 10% pour mono1) et qu'ils bossaient sur le sujet pour ameliorer cela. Ce qui contredit "legerement" ton argumentation.
            • [^] # Re: Tire de l'annonce sur slashdot!

              Posté par (page perso) . Évalué à 2.

              Sans déconner, tu viens d'apprendre qu'on a bien bosser depuis Mono 1.0 (2004). Nous nous sommes énormément servi d'un outil appellé MoMA pour déterminer quelles étaient les APIs les plus utilisées qui empêchaient de porter le gros des applications. Et on les a implémentées.

              Donc oui, maintenant, le gros des applications non portables, sont du au fait que les applications utilisent des fonctionnalités natives. Mais ça n'enlève pas qu'il reste du travail pour fixer des bugs et implémenter d'autre chose, et encore augmenter le nombre d'applications portables sans modifications.
              • [^] # Re: Tire de l'annonce sur slashdot!

                Posté par (page perso) . Évalué à 2.

                Puisque je t'ai sous la main, j'ai un problème récurrent avec Mono : c'est la portabilité sous Windows (hem). C'est effectivement tentant de faire une application en GTK# par exemple et de la faire tourner sous Windows. Le problème, c'est le déploiement. Y'a bien un setup GTK# runtime, mais il est complètement out-of-date. Faudrait fournir des packages msm tout prêt pour les développeurs visual studio. Non parcque là c'est vraiment un frein au déploiement multi-plateforme d'applications graphiques "portable".
                • [^] # Re: Tire de l'annonce sur slashdot!

                  Posté par . Évalué à 1.

                  bah puisque tu es développeur Mono GTK# pouet pouet, pourquoi tu te colles pas à justement préparer et fournir ce setup GTK# runtime qui visiblement te manque tant ?
                • [^] # Re: Tire de l'annonce sur slashdot!

                  Posté par (page perso) . Évalué à 2.

                  Oép, c'est un contributeur externe qui s'occupait de ça. Je fais remonter le problème, on va en discuter. Merci!
                  • [^] # Re: Tire de l'annonce sur slashdot!

                    Posté par (page perso) . Évalué à 3.

                    Oué mais le problème c'est que le contributeur en question il a l'air de les faire au compte-goutte suivant les besoins de sa boîte (ce qui est logique), bref ca serait mieux si c'était officiellement supporté de votre côté au même titre que le setup mono pour Windows :)
                  • [^] # Re: Tire de l'annonce sur slashdot!

                    Posté par (page perso) . Évalué à 3.

                    J'en rajoute encore une couche, mais vous sous Linux des bindings de GTK 2.12 et sous Windows le setup de mono 2.0 déploie GTK 2.10... hors GTK# 2.12 contient des nouveautés qui ne sont pas anodines...
          • [^] # Re: Tire de l'annonce sur slashdot!

            Posté par . Évalué à 2.

            Donc oui, certaines applications ne sont par définition non portable. Ajoute à ça que certains développeurs sont peu regardant sur comment écrire du code cross-platform, et voilà. Mais au final, c'est le même problème avec les applications Java + JNI qui utilisent du code natif non portable.

            La legere difference c'est que des le depart (la creation de java) l'idee de portabilite etait la et donc les applis java non portable sont beaucoup moins frequentes (je n'ai pas dit inexistante ni en faible nombre je prefere preciser). Je compare avec .NET et malgre le fait que cela ait ete presente comme le remplacant de java, l'effort de ne programmer qu'avec la partie permettant le portage n'est jamais fait pour les grosses applis (meme du cote libre vu que d'apres ce que dis Timaniac http://linuxfr.org/comments/971651.html#971651 , banshee a certains problemes du a l'utilisation specifique de mono...). Du coup aucune grosse application ou presque ne fonctionne sous .NET microsoft et mono. Enfin, bon moi je vais arreter ici. Je voulais avoir une reponse simple a savoir si je pouvais utiliser avec mono certains logiciels .NET, je l'ai eu.
        • [^] # Re: Tire de l'annonce sur slashdot!

          Posté par . Évalué à 2.

          Il me semble intéressant de se demander si Mono est une plateforme utilisable en tant que telle, indépendamment de .NET. La compatibilité est importante pour certains, mais en ce qui me concerne, je n'ai pas à me soucier de .NET, ce qui m'intéresse c'est de savoir si je peux utiliser Mono pour développer mes programmes à moi, et si la plateforme est intéressante.

          En particulier, si je devais un jour utiliser Mono, je préfèrerais utiliser les bindings GTK plutôt que me demander si je peux utiliser le toolkit graphique de Microsoft.
        • [^] # Re: Tire de l'annonce sur slashdot!

          Posté par . Évalué à 6.

          Mais de quoi parlez-vous ? Si la compatibilité avec .NET (la plateforme Windows) est l'un des objectifs du projet Mono, il n'est pas le seul, et sans doute pas le premier.

          Son objectif premier est de proposer un environnement de dévelopement libre utilisant comme base la machine virtuelle de .NET et les APIS définis par l'ECMA auxquels viennent s'ajouter GTK#, Gst#, un module Apache etc. en plus des bibliothèques compatibles avec la plateforme de Microsoft. Mais les bibliothèques de Microsoft ne sont pas indispensables à Mono !

          Votre exemple sur le C est complètement à côté de la plaque puisque le C est un langage alors que Mono est un Framework.

          Je peux dire exactement la même chose de C : gcc compilera toutes les applications C, sauf... celles qui utilisent des bibliothèques absentes sur la machine du type qui compile !

          Il y a des applis en C pour Windows qui utilisent des apis Windows et, tenez-vous bien, un compilateur c sous linux sans bibliothèques compatibles ne compilera pas ces applis !
        • [^] # Re: Tire de l'annonce sur slashdot!

          Posté par (page perso) . Évalué à 3.

          Ah donc arriver a ne faire tourner que la moitie des applis c'est une compatibilite suffisante? En gros c'est comme si tu disais que un compilo C arrive a compiler 50% des logiciels ecrit en C mais par contre dans tout tes logiciel tu aurais en prime un tetris il serait fabuleux... Drole de point de vu.

          Mais on s'en fout de la compatibilité pour les applications Windows !

          Mono fonctionne sous un environnement libre, avec des bibliothèques libres, que demander de plus ? Et si tu veux continuer avec ton analogie avec le C, c'est comme si tu demandait à gcc de compiler des applications prévues pour Windows avec des bibliothèques Windows, ça ne marchera pas, mais ça n'empêche pas à gcc d'être un bon compilateur.

          Pourquoi toujours vouloir ramener Mono à l'environnement Windows. Mono se suffit de lui même et ça me suffit.
      • [^] # Re: Tire de l'annonce sur slashdot!

        Posté par (page perso) . Évalué à 5.

        >>> Mono ne sera et n'a jamais été à la traîne de quoi que ce soit

        J'avais fait un journal sur ce sujet : https://linuxfr.org/~patrick_g/26958.html
        Si tu va lire la déclaration de Miguel de Icaza tu t'apercevra qu'il infirme totalement ta position :
        ""Malheureusement il n'y a pas de détails dans l'interview à propos des nouveautés de C# 4.0. Nous devons attendre jusqu'au PDC (Professional Developers Conference) pour avoir une idée de ce qui va arriver.
        Heureusement, le compilateur C# de Mono est déjà compatible avec la version 3.0 et nous sommes prêt à ajouter les fonctions de la version 4.0 dès qu'elles seront rendues publiques".
        "

        Mono est à la traine structurellement car il réimplémente les choix techniques de Microsoft.
        • [^] # Re: Tire de l'annonce sur slashdot!

          Posté par . Évalué à 3.

          Vous n'avez pas bien compris ce que je voulais dire.

          Mono serait à la traîne s'il était dans la même situation qu'un swfdec : être compatible au maximum avec le .NET de Microsoft pour le premier, et être compatible au maximum avec flash pour le second.

          Or, Mono peut-être utilisé sans se soucier de la compatibilité avec le .NET de Microsoft puisqu'il propose un ensemble de bibliothèques mûres qui le rende tout à fait utilisable dans le cadre du développement d'une appli en GTK pour Gnome, par exemple. Les exemples sont nombreux.

          Ensuite votre exemple sur C# est juste, mais que dire... C'est pareil pour n'importe quel langage issue d'une norme, ou n'importe quel version "non officielle" d'un langage !

          Le python de jython n'intégrera jamais les avancées de Python aussi vite que Python ! GCC n'intègrera jamais les nouvelles fonctionnalités issues d'un brainstorming sur le nouveau C aussi vite que la norme est imprimée !

          Puisque Microsoft bosse directement sur ce qui sera C# 3, 4, 5, et bien oui, le C# de Mono prendra plus de temps pour proposer un C# équivalent.

          Et alors ? Ça empêche de l'utiliser et d'être viable ?
          • [^] # Re: Tire de l'annonce sur slashdot!

            Posté par . Évalué à 4.

            Le python de jython n'intégrera jamais les avancées de Python aussi vite que Python

            Euh je voudrais pa sdire mais c'est un tres mauvais exemple. Je pense que c'est techniquement tout a fait faisable vu que les PEP sont dispos pour tous le monde au meme moment et que aucune decisions n'ait prise par une seule boite. Le probleme vient plutot de la "main d'oeuvre" et aussi dans le cas particulier de Jython du fait que le developpement vient a peine de reprendre. Cython est l'implementation de reference ce qui est legerement different de la seule implementaion officielle.
          • [^] # Re: Tire de l'annonce sur slashdot!

            Posté par . Évalué à 4.

            Et alors ? Ça empêche de l'utiliser et d'être viable ?

            Non mais cela permet, contrairement a tes affirmations, de dire qu'il aura toujours un train de retard!
            • [^] # Re: Tire de l'annonce sur slashdot!

              Posté par (page perso) . Évalué à 3.

              Et tu t'arrêtes à ce genre d'argument à la con destiné uniquement aux commerciaux voulant convaincre des décideurs pressés ?
              Que les choses soient clair : Mono est compatible avec l'environnement d'exécution du framework .NET, même dans sa dernière version. La seule chose qui diffère, ce sont les bibliothèques : .NET propose des libs qui n'existent pas pour mono... et inversement. Après on est sur LinuxFR, alors on pourrait peut être comparer Mono et ses libs aux autres frameworks pour Linux non ?
              • [^] # Re: Tire de l'annonce sur slashdot!

                Posté par . Évalué à 1.

                mono ne fait tourner aucune applications vraiment interessante "out-of the box" ou donne moi la methode pour utiliser sous linux et avec mono:

                http://www.getpaint.net/

                ou encore

                http://www.worldwidetelescope.org/experienceIt/ExperienceIt.(...)

                En comparaison, les applis java, les vrais applis pas les demos, qui fonctionnent sous windows et Unix cela ne se comptent pas sur les doigts de la main.
                • [^] # Re: Tire de l'annonce sur slashdot!

                  Posté par . Évalué à 0.

                  java c'est juste beaucoup plus vieux. Et puis bon avec tous les fudeurs dans ton genre, ça ne peut pas aider ;)
                  • [^] # Re: Tire de l'annonce sur slashdot!

                    Posté par . Évalué à 4.

                    Allez l'attaque classique du FUD c'est facile, pas tres original et cela evite surtout de repondre a la question.

                    En ce qui concerne java, des le depart les applis java tournaient sous Unix et windows de facon indifferencie (c'est a dire aussi mal et aussi moche :) ). Maintenant je repose la question, elle est simple pourtant:

                    Donnez moi une application majeur de .NET (tel que j'ai cite) qui tourne sans probleme sous Linux+Mono et la methode pour m'en servir.

                    C'est bien beau de dire que cela marche mais il semblerait que le prouver reste un peu plus difficile...

                    ps: En 6 ans pas une applis .NET n'as reussi a etre multiplateforme? Et oui java c'est plus vieux mais bon 6 ans a l'echelle informatique c'est tout de meme enorme.
                    • [^] # Re: Tire de l'annonce sur slashdot!

                      Posté par . Évalué à 2.

                      > En ce qui concerne java, des le depart les applis java tournaient sous Unix et windows de facon indifferencie (c'est a dire aussi mal et aussi moche :) ). Maintenant je repose la question, elle est simple pourtant:

                      MOUHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

                      Tu veux qu'on te dresses une liste des applis java tournant sur une plateforme et pas l'autre ?
                      • [^] # Re: Tire de l'annonce sur slashdot!

                        Posté par (page perso) . Évalué à 1.

                        "Write once, run anywhere" ? "Write Once, Debug Everywhere".
                      • [^] # Re: Tire de l'annonce sur slashdot!

                        Posté par . Évalué à 1.

                        faux vraiment apprendre a lire...

                        c'est a dire aussi mal et aussi moche :)

                        ps: marche mal mais au moins marche
                        • [^] # Re: Tire de l'annonce sur slashdot!

                          Posté par . Évalué à 3.

                          Permet moi de souligner une petite nuance entre les deux propositions suivantes:
                          1- le monsieur n'est pas d'accord avec toi
                          2- le monsieur n'a pas compris ce que tu dis

                          En l'occurence, le monsieur semble avoir compris ce que tu as dit, et ne pas être d'accord. Je sais, c'est très surprenant, ça me fait aussi souvent cet effet là.
                      • [^] # Re: Tire de l'annonce sur slashdot!

                        Posté par . Évalué à 4.

                        Qu'est-ce qu'une "appli java" ? Une application en "100% pure java" ou une application majoritairement en java avec des appels à des librairies externes liées au système ?

                        BeOS le faisait il y a 15 ans !

            • [^] # Re: Tire de l'annonce sur slashdot!

              Posté par . Évalué à 1.

              Il aura un train de retard sur ce point. Mais en soi, en tant qu'outil de développement il ne sera en retard sur rien !

              Le fond de mon argumentation n'était pas la comparaison entre jython et python, mais entre swfdec et Mono. L'un est autonome et n'a de retard qu'en comparaison avec un projet (.NET) sur lequel il a un soucis de compatibilité ENTRE AUTRE CHOSES, alors que l'autre n'existe que pour être compatible avec les applis flash qui traîne sur le net, ce qui fait qu'il est substantiellement TOUJOURS en retard (et très utile !).

              Dès l'argument du retard ne peut pas être en soi un argument valable pour dénigrer l'ensemble du projet, sauf pour la personne qui ne s'intéresse à Mono que pour faire ses progs Windows sous Linux. Et vue le mépris que vous affichez pour Mono et tout ce qui touche de près ou de loin à Microsoft (non sans raisons, je vous l'accorde), cela m'étonnerai que Mono vous intéresse pour cette raison.

              Reconnaissez que ce projet propose d'autres bibliothèques qui lui donne une valeur indépendamment de .NET !
              • [^] # Re: Tire de l'annonce sur slashdot!

                Posté par . Évalué à 1.

                Reconnaissez que ce projet propose d'autres bibliothèques qui lui donne une valeur indépendamment de .NET !

                Peut etre mais mon message de depart concernait .NET et la compatibilite mono pas les libs que mono a en plus. Lorsque un developeur de mono dis lui meme que en dehors des trucs specifique windows il n'y a que 50% des applis .NET qui fonctionne cela laisse a reflechir tout de meme non?

                Apres mono, microsoft et ses afficionados vous savez deja ce que j'en pense...

                http://linuxfr.org/comments/971448.html#971448
                • [^] # Re: Tire de l'annonce sur slashdot!

                  Posté par (page perso) . Évalué à 1.

                  Après, faut penser proportion.

                  50% des applications .net au monde, ça fait combien d'applications par rapport au nombre d'application sur Linux ? Perso j'en ai aucune idée, mais j'ai une petite idée d'où la balance penche.
                  • [^] # Re: Tire de l'annonce sur slashdot!

                    Posté par . Évalué à 2.

                    comme dit au dessus donne moi un exemple d'applis .NET complexe et interessante pour un nombre non minime de personne (et developpe par une autre equipe que mono) qui tourne sous linux+mono et par la meme occasion donne moi la facon de m'en servir. Perso je peux donner "quelques" exemple de ce style pour Java...
                    • [^] # Re: Tire de l'annonce sur slashdot!

                      Posté par (page perso) . Évalué à 2.

                      Moi je connais surtout des outils pour les développeurs. Ceux que j'utilise:

                      Reflector, NClass, LinqPAD, IronEditor, NUnit.

                      Reflector par exemple c'est un truc que j'aime bien montrer en démo. C'est utilisé par la grande majorité des développeurs .net. Et c'est aussi simple que de le télécharger, et de faire un mono Reflector.exe.
                    • [^] # Re: Tire de l'annonce sur slashdot!

                      Posté par . Évalué à 3.

                      La philosophie n'est pas la même.

                      Java a été conçu pour être portable et as de ce fait abstraire toutes les couches au dessus de la JVM y compris les toolkit graphiques (AWR/Swing et SWT/JFace). La contre partie c'est des applis portables qui n'ont jamais intégration complètes avec la plateforme en dessous. Ceci explique que Java a du mal à percer sur le desktop.

                      La philosphie de .NEt est d'être indépendant du langage pas de l'OS.
                      La philosophie de Mono (pas .NET qui ne se soucie pas de portabilité) est de dire qu'il faut prendre en charge le maximum de ce qui est raisonnablement portable et de réimplémenter les spécificités d'une plateforme. Un portage donnera donc une appli native mais il rest tjs un cout de portage.
                      Ceci ne t'empêche pas de concevoir dès le début ton appli pour être portable tout comme tu le ferais avec Java (pas de JNI, pas d'accès de bas niveau, sandbox, ...).
                      Les 2 exemples que tu cites n'ont clairement pas été implémenté avec l'idée de la portabilité derrière mais clairement d'une intégration poussée dans Windows.

                      L'autre avantage que pourrait apporter Mono/.NET est la volonté d'utiliser les même appli pour des applis natives et des clients riches.
                      Ici Mono jouerait plutôt sur le terrain de Mozilla.

                      Mais je suis d'accord avec toi l'idée est séduisante mais il reste à convaincre.
                      Ce n'est pas une raison pour dénigrer systématiquement.
                      D'ailleurs j'aime assez voir les mêmes qui critiquent chaque annonce de l'ecosytème Java en bavant sur sa lourdeur par rapport à du natif venir le mettre en avant dès que des annonces sur Mono passent (Ce n'est pas un attaque ad hominem).
                      • [^] # Re: Tire de l'annonce sur slashdot!

                        Posté par (page perso) . Évalué à 3.

                        La philosphie de .NET est d'être indépendant du langage pas de l'OS.
                        Ca c'est la philosophie de certaines bibliothèques du framework .NET. Et encore elles sont rares. La majeure partie du framework, à commencer par son environnement d'exécution (la brique essentielle) est parfaitement indépendante de l'OS.
                        L'abstraction vis-à-vis de l'OS c'est un des objectifs de .NET, même pour Microsoft, ne serais-ce que pour faire abstraction de ses propres "OS" (WindowsCE, WindowsMobile, Xbox360, WindowsXP/Vista, etc.).
                        Le problème de portabilité n'est pas l'indépendance de .NET vis-à-vis de l'OS mais les possibilités d'intégrations avec l'existant qui est lui dépendant de l'OS (libs natives Win32/COM, etc.) : c'est un atout indéniable pour intégrer l'existant sans tout recoder mais ca aussi un frein à la portabilité.
                        Le 2ème frein à la portabilité, c'est que le framework .NET devient très "gros" et pour tout réimplémenter il faut des moyens... (voir .NET 3.0 qui n'est qu'un addon de bibliothèques conséquentes).
                        Il y a cependant un virage pris par Microsoft intéressant : ils commencent à voir l'intérêt de mettre des bouts de code sous licence open-source, permettant à Mono de récupérer le travaille fait par MS : DLR, libs ajax, IronPython ou plus récemment MEF.
                • [^] # Re: Tire de l'annonce sur slashdot!

                  Posté par (page perso) . Évalué à 3.

                  D'un point de vue utilisateur, cette compatibilité n'est effectivement pas suffisante : tu ne peux pas prendre une application "lambda" écrite en .NET et la faire tourner sous Linux.
                  par contre la compatibilité est largement suffisante pour les développeurs qui pensent multi-plateforme : je veux faire du .NET portable qui tourne sous Linux, je peux, je fais juste gaffe d'utiliser des bibliothèques portables.
                  • [^] # Re: Tire de l'annonce sur slashdot!

                    Posté par . Évalué à -1.

                    Bon ben voila tu viens de repondre a la question. Mono ne sert a rien puisque les applis que monsieur tout le monde aimeraient avoir ne tournent pas dessus.

                    On verra a la prochaine version dans 2 ou 3 ans...
                    • [^] # Re: Tire de l'annonce sur slashdot!

                      Posté par . Évalué à 4.

                      Ce n'est pas toi qui peux décider que Mono ne sert à rien parce qu'il ne fait pas ce que tu voudrais. Tout ce que tu peux conclure de tes observations, c'est que Mono ne sert pas à prendre une application .NET et à la faire tourner sous Linux sans changements. En conclure que ça ne sert à rien n'est pas très sérieux.

                      Bon, un cas concret. Admettons que j'aie envie de voir ce que vaut C# comme langage de programmation. Mon premier réflexe pour ça serait d'installer Mono. Existe-t-il une alternative ?

                      Un autre cas concret: on me demande de développer une application simple qui tourne sur .NET. Je n'ai pas Windows et je n'ai pas envie de l'installer juste pour ça. Est-ce que je peux utiliser Mono pour développer cette application, et ensuite la faire tourner sur le .NET officiel ?

                      Je n'ai pas la réponses à ces questions, mais ce sont deux utilités potentielles de Mono que tu ignores soigneusement, me semble-t-il.
                      • [^] # Re: Tire de l'annonce sur slashdot!

                        Posté par (page perso) . Évalué à 2.

                        moi je préfèrerais installer windows et visual studio afin d'avoir un outils bien fait...


                        si on me demanderais de développer une application en .net et que j'ai pas windows,
                        je ferais en sorte de l'obtenir afin de ne pas avoir de problème niveau compatibilité et donc des mauvaises surprise...

                        www.solutions-norenda.com

                    • [^] # Re: Tire de l'annonce sur slashdot!

                      Posté par . Évalué à 1.

                      Allez, au hasard, un tout petit échantillon :

                      http://www.misuzilla.org/dist/net/twitterircgateway/
                      http://paint.net/ (plus que quelques petits bugs)
                      http://banshee-project.org/download/ (bientôt sous windows)
                      http://www.integrazioneweb.com/monosim/

                      Je ne parle même pas des applications web basée sur .NET qui tournent indifféramment sous un serveur windows ou unix.

                      Quand au fameux "les applis que monsieur tout le monde aimeraient avoir". C'est qui monsieur tout le monde ?

                      Si monsieur tout le monde c'est la majorité et que l'on peut suppose que ce monsieur tout le monde utilise winsdows et des applis windows, alors monsieur tout le monde il utile Microsoft Word et Internet Explorer.

                      Et voyez-vous python, perl, java, ou lisp, comme mono, ils ne font pas tourner Internet Explorer et Microsoft Word, les logiciels de "monsieur tout le monde".

                      Donc à vous écouter on devrait tous passer à du .NET... sous windows.
                      • [^] # Re: Tire de l'annonce sur slashdot!

                        Posté par . Évalué à 2.

                        > Et voyez-vous python, perl, java, ou lisp, comme mono, ils ne font pas tourner Internet Explorer et Microsoft Word, les logiciels de "monsieur tout le monde".

                        ben emacs, si.

                        > Donc à vous écouter on devrait tous passer à du .NET... sous windows.

                        tu as mal compris, ils ne veulent ni de .NET ni de Windows, c'est pourtant simple.
                        • [^] # Re: Tire de l'annonce sur slashdot!

                          Posté par . Évalué à 2.

                          "tu as mal compris, ils ne veulent ni de .NET ni de Windows, c'est pourtant simple. "

                          J'ai parfaitement bien compris. Seulement l'argument du monsieur tout le monde, c'est windows. Donc cet argument il peut être utilisé contre quasiment tout les projets libres, et donc la plupart des langages majoritairement utilisés dans l'univers du libre. Les applis windows majoritairement utilisées ne sont pas des applis en python. Donc, si je suis le raisonnement d'Albert, python ça pue au moins autant que mono etc.

                          Bref, c'est un raisonnement con !
                          • [^] # Re: Tire de l'annonce sur slashdot!

                            Posté par . Évalué à 1.

                            Seulement l'argument du monsieur tout le monde, c'est windows.

                            Vu qu'il etait precise sous linux le monsieur tout le monde en question cela voulait dire un non informaticien/developpeur! Mais tu peux jouer a l'idiot aussi.
                            • [^] # Re: Tire de l'annonce sur slashdot!

                              Posté par . Évalué à 1.

                              Mais vous êtes vraiment casse bonbon. Je vous cite :

                              "Bon ben voila tu viens de repondre a la question. Mono ne sert a rien puisque les applis que monsieur tout le monde aimeraient avoir ne tournent pas dessus."

                              Alors oui, "aimeraient" suppose qu'ils ne peuvent l'avoir donc cela sous-entend qu'il serait sur un système autre que .NET.

                              Bon, j'en ai marre de jouer votre jeu. Je vous présente une toute petite liste présentant des applications tournant indifféramment sous .NET et mono et vous faites la fine bouche.

                              J'en ai marre de jouer à votre jeu car vous établissez des limitations bidons.

                              On peut écrire une application sous .NET qui tourne sous Mono. Comme avec java. Seulement c'est rarement fait car les devs .NET programment pour Windows.

                              Java c'est pareil, si vous ne programmez pas en pensant multiplateforme ça risque de ne pas fonctionner.

                              Point barre. Votre question débile c'est une question sélective qui ne vise qu'à aller là ou vous désirez aller, ça n'est pas une vraie question.

                              C'est comme si je vous demandais de me citer une application écrite dans un autre langage que LISP, qui n'embarque pas un interpréteur LISP, qui soit populaire et "auto-programmable". Je sais que vous auriez du mal à en trouver. Et alors ?
                              • [^] # Re: Tire de l'annonce sur slashdot!

                                Posté par . Évalué à 1.

                                J'en ai marre de jouer à votre jeu car vous établissez des limitations bidons.

                                Je n'etablie pas une limite bidon je demande le nom et la facon d'utiliser une seule applis non faite pour les informaticiens developpe avec .NET microsoft qui tourne "out of the box" sous mono+linux. Pour l'instant je n'ai pas eu une seule reponse valable. On m'a donne le nom d'applis mono qui fonctionne sous mono (chouette...), on m'a donne le nom d'une applis qui fonctionne pas en realite que ce soit "out of the box" ou pas d'apres monsieur mono lui meme et on ma donne des excuses bidon tel que ".NET c'est tout recent et c'est pour ca que aucune applis n'est mutliplateforme". Je trouve cela leger.

                                Encore une fois je dis bien que vu que mono est incapable de faire tourner une seule applis phare (pour les non informaticiens) de .NET il sert pas a grand chose et que les efforts pur avoir un framework multiplateforme aurait par consequent etre plus utilement investi ailleurs!
                                • [^] # Re: Tire de l'annonce sur slashdot!

                                  Posté par (page perso) . Évalué à 4.

                                  est incapable de faire tourner une seule applis phare (pour les non informaticiens) de .NET
                                  T'es toujours incapable de nous citer une seule appli "phare" entièrement en .NET.
                                • [^] # Re: Tire de l'annonce sur slashdot!

                                  Posté par . Évalué à 2.

                                  Je vous ai donné des preuves que l'on pouvait programmer des applis en .NET qui tournent sur Mono. Et inversement que des applis Mono pouvaient tourner sur .NET (+ bibliothèques supplémentaires de mono, mais ça c'est valable pour tous logiciel qui ne peut se satisfaire des bibliothèques standard).

                                  Vous voulez des applis "phares". Il n'y en pas pour l'instant selon vos exigences (car banshee fonctionnera très bientôt sur windows, mais vous ne voulez pas en entendre parler). Et alors, quel rapport avec Mono ?

                                  Parce que Word et Internet Explorer ne sont pas écrit en python, je devrais considérer python comme un langage qui ne vaut rien ? Votre raisonnement relève exactement de cette logique.

                                  Sur ce, bye.

                                  P.S. : au passage, je ne suis pas un afficionado de mono. Je n'ai jamais rien programmé en mono, ni en .NET, ni en quoi que ce soit à part un peu de Emacs LISP, de php, et un brin de python et de c. Mais rien de sérieux pour l'instant. Seulement mono a le malheur d'être malaimé pour des raisons stupides, complètement idéologiques, et cela me hérisse le poil.
                                  • [^] # Re: Tire de l'annonce sur slashdot!

                                    Posté par . Évalué à 2.

                                    car banshee fonctionnera très bientôt sur windows, mais vous ne voulez pas en entendre parler

                                    Normal la question etait au present pas au futur ni au conditionnel... et de plus c'etait sur la compatibilite avec .NET que je voulais des informations pas avec mono c'est rigolo comme il y a eu une levee de bouclier sur le sujet alors que c'est tout de meme l'avant dernier paragraphe de la news...
                          • [^] # Re: Tire de l'annonce sur slashdot!

                            Posté par (page perso) . Évalué à 1.

                            linux au niveau du desktop c'est 4%

                            www.solutions-norenda.com

                          • [^] # Re: Tire de l'annonce sur slashdot!

                            Posté par . Évalué à 1.

                            (...)
                            > Vous n'avez pas bien compris ce que je voulais dire.
                            (...)
                            >> tu as mal compris, ils ne veulent ni de .NET ni de Windows, c'est pourtant simple.
                            > J'ai parfaitement bien compris

                            c'est amusant, dans un sens toi tu as le droit "les autres m'ont pas bien compris" mais dans l'autre sens c'est interdit.

                            > J'en ai marre de jouer à votre jeu car vous établissez des limitations bidons.

                            ah. ah. ah. oui bon alors comme on se prend aussi des "toujours le même argument débile qui ressort", tu vas pouvoir continuer à jouer toute seule. sur l'autoroute.
                      • [^] # Re: Tire de l'annonce sur slashdot!

                        Posté par . Évalué à 2.

                        Pour Paint.net c'est pas moi qui le dit mais monsieur mono en personne, ca marche pas "out of the box" loin de la:

                        http://tirania.org/blog/archive/2006/May-19.html

                        banshee hors categorie car ca vient de mono et j'ai bien precise pas une applis dans ce sens la.

                        idem pour monosim

                        twittergateway je sais pas ce que c'est et vu que je ne lis pas le japonais je ne saurais pas.

                        Je repose la question simple:

                        Donnez moi une applis faite pour monsieur tout le monde (monsieur tout le monde n'etant pas un developpeur mais quelqu'un qui veut travailler sur ses photos, utiliser un logiciel tel que stellarium ou googleearth) faite dans le framework .NET (celui de microsoft l'officiel quoi) et qui tourne "out of the box". Si voius en trouvez une donnez moi la facon de la lancer sous linux+mono que je teste.
                        • [^] # Re: Tire de l'annonce sur slashdot!

                          Posté par . Évalué à 2.

                          Tu cites un post de 2006 pour dire que ça marche pas "out of the box" ?
                          • [^] # Re: Tire de l'annonce sur slashdot!

                            Posté par . Évalué à 2.

                            non non je cite le commentaire de di icaza d'il y a 2 mois.
                            • [^] # Re: Tire de l'annonce sur slashdot!

                              Posté par . Évalué à 2.

                              Non non, tu cites un post de 2006. Si tu penses à quelque chose de plus récent, alors tu t'es trompé de citation.
                              • [^] # Re: Tire de l'annonce sur slashdot!

                                Posté par . Évalué à 2.

                                [Moderator] 2 months ago 1 point

                                Sadly, nobody was really interested in completing the port. Lots of people said they would contribute if my patches were published, but nobody had the time in the end.
                                reply



                                Dans le lien fournit tout en bas de la page!
                        • [^] # Re: Tire de l'annonce sur slashdot!

                          Posté par (page perso) . Évalué à 2.


                          Donnez moi une applis faite pour monsieur tout le monde (monsieur tout le monde n'etant pas un developpeur mais quelqu'un qui veut travailler sur ses photos, utiliser un logiciel tel que stellarium ou googleearth) faite dans le framework .NET (celui de microsoft l'officiel quoi) et qui tourne "out of the box". Si voius en trouvez une donnez moi la facon de la lancer sous linux+mono que je teste.


                          Pourquoi devrait-on répondre à ta question ?

                          Pour te prouver que Mono fait fonctionner des milliers d'applications prévues pour Windows uniquement (donc utilisant bien souvent des bibliothèques natives ...) alors que ce n'est pas le cas ?

                          Mono n'est pas bien compatible avec la majorité des applications .NET Windows, mais bien souvent ce n'est pas de sont fait. Et en plus, c'est loin d'être le but de Mono. Ne pas confondre Mono et Wine, le premier a un fort intérêt en lui même alors que le second ne cherche qu'à avoir une compatibilité.
                          • [^] # Re: Tire de l'annonce sur slashdot!

                            Posté par . Évalué à 2.

                            « Mono et Wine, le premier a un fort intérêt en lui même alors que le second ne cherche qu'à avoir une compatibilité.  »

                            Le premier ne fait pas tourner « out of the box » d'appli windows.net (d'après ce que j'ai compris) alors que le second à un fort intérèt en lui même qui est de permettre une compatibilité avec linux pour un bon nombre d'application windows.
                  • [^] # Re: Tire de l'annonce sur slashdot!

                    Posté par (page perso) . Évalué à 2.

                    tu ne peux pas prendre une application "lambda" écrite en .NET et la faire tourner sous Linux.

                    Bah et pourquoi ça ?

                    Y a pleins d'applications métiers passées dans MoMA, et qui marchent bien aussi.
                    • [^] # Re: Tire de l'annonce sur slashdot!

                      Posté par (page perso) . Évalué à 3.

                      Je voulais dire "tu ne peux pas prendre n"importe quelle application "lambda" écrite en .NET et la faire tourner sous Linux."
                    • [^] # Re: Tire de l'annonce sur slashdot!

                      Posté par . Évalué à 2.

                      c'est bien pour ca que j'ai donne des exemples de logiciel non specialise! Ceux qui interesse 90% des personnes.
                      • [^] # Re: Tire de l'annonce sur slashdot!

                        Posté par (page perso) . Évalué à 2.

                        Avant de répondre à ta question, tu dois répondre à une autre question : montre moi une application .NET (et uniquement .NET) tournant sous Windows qui est intéressante pour 90% des personnes que tu voudrais voir tourner sous Linux.
                        • [^] # Re: Tire de l'annonce sur slashdot!

                          Posté par . Évalué à 1.

                          j'ai deja donne deux exemples maintenant le succes de Googleearth te feras peut etre prendre conscience que pour 90% des utilisateurs un truc comme worldwidetelescope peut etre interessant.

                          J'aime beaucoup comme les afficionados de mono tournent autour du pot mais n'arrive pas a trouver un seul exemple a ma question pourtant bien simple et bien legitime.

                          ps: ta maman ne t'a pas appris que c'etait impoli de repondre a une question par une autre question?
                          pps: pas capable de trouver un logiciel non metier (ie pour les informaticiens) fait en .NET et qui tourne sous mono+linux? Cela n'est aps ma faute mais cela montre bien mon point!
                          • [^] # Re: Tire de l'annonce sur slashdot!

                            Posté par (page perso) . Évalué à 2.

                            worldwidetelescope n'est pas entièrement en .NET. Trouve un autre exemple.
                            • [^] # Re: Tire de l'annonce sur slashdot!

                              Posté par . Évalué à 2.

                              http://www.worldwidetelescope.org/experienceIt/ExperienceIt.(...)

                              d'apres ce que je vois ici cela devrait l'etre...

                              et sinon j'aimerai bien voir tes sources pour affirmer cela. Parceque j'ai lu il y a peu de temps une interview du responsable C#/.NET de chez microsoft a qui il etait demande de citer l'applis la plus cool ecrite avec ce framework et il a cite celle la donc soit le monsieur y connait rien soit il a omis quelques details et si c'est le cas j'aimerai avoir un lien.
                              • [^] # Re: Tire de l'annonce sur slashdot!

                                Posté par (page perso) . Évalué à 2.

                                Ben je l'ai téléchargé, et j'ai regardé avec MoMA, l'outil de Mono de vérification de compatibilité, et il indique clairement qu'il y a quelques appels (pas beaucoup) à des composants natifs de la plateforme.
                                Après vérification l'appli utilise DirectX.
  • # .NET et portabilité GUI = 2

    Posté par (page perso) . Évalué à 2.

    Si l'application est développée avec les outils MS, notamment les WinForms, l'application fonctionne (1) seulement sous Windows.

    Si l'application est développée avec Mono, celle-ci va donc utiliser Gtk# et l'application ne tournera pas sous Mac et j'imagine que sous Windows ca doit être encore assez bancale. (1)

    Java SWING ou SWT ne pose pas ce problème
    Qt permet de développer pour plusieurs plateformes, WxWidgets et autres aussi.

    Si utiliser .NET/Mono signifie qu'il faut recoder sa GUI pour chaque plateforme c'est un retour de 10 ans en arrière !

    Existe il au moins une application graphique .NET/Mono qui soit réellement multiplateforme ?




    (1) fonctionne != experimental
    • [^] # Re: .NET et portabilité GUI = 2

      Posté par (page perso) . Évalué à 3.

      Si l'application est développée avec les outils MS, notamment les WinForms, l'application fonctionne (1) seulement sous Windows.
      Ben justement, Mono 2.0 supporte officiellement les Windows.Forms de manière complète.

      elle-ci va donc utiliser Gtk# et l'application ne tournera pas sous Mac
      Ben si y'a GTK sous mac, GTK# est installé avec le setup de Mono sous mac.

      j'imagine que sous Windows ca doit être encore assez bancale. (1)
      Non c'est pas bancale.

      Qt permet de développer pour plusieurs plateformes, WxWidgets et autres aussi.
      Comme GTK... de plus rien n'empêche d'avoir des bindings pour Mono qui soient portables (ce n'est pas encore le cas), et il existe bien des bindings wxWidgets pour Mono.
      • [^] # Re: .NET et portabilité GUI = 2

        Posté par . Évalué à 2.

        Ben si y'a GTK sous mac, GTK# est installé avec le setup de Mono sous mac.

        Ah tiens grande nouvelle on dirait que en effet le port vers mac est enfin officiel et a peu prs stable:

        http://www.gtk-osx.org/

        Dire que certains ont trolle comme des porcs sur le sujet il y a deux semaines :D
      • [^] # Re: .NET et portabilité GUI = 2

        Posté par . Évalué à 5.

        Ben justement, Mono 2.0 supporte officiellement les Windows.Forms de manière complète.

        Certes, mais Windows.Forms ne fait pas partie des normes ECMA, font l'objet de brevets, et seuls Novell et ses clients sont autorisés à les utiliser dans Mono ...

        Redistribuer une implémentation des WinForms (et quelques autres technologies du stack .Net) sans accord préalable avec Microsoft présente un risque juridique non négligeable.

        Mono pourrait bien se transformer en une marche forcée à travers un champ de mines.
        • [^] # Re: .NET et portabilité GUI = 2

          Posté par (page perso) . Évalué à 1.

          font l'objet de brevets
          Montre moi les brevets sur Windows.Forms.
          • [^] # Re: .NET et portabilité GUI = 2

            Posté par . Évalué à 1.

            le principe du champ de mine, c'est qu'on ne voit pas immédiatement où elles sont... et quand on en a trouvé une, il est souvent trop tard...

            Quand on voit l'attitude de Microsoft face à Novell, les accords, le fait que Novell ait demandé une assurance de Microsoft de ne pas se faire attaquer pour Mono, on peut se méfier...

            Et quand on voit des brevets déposés sur l'utilisation des windows forms (USPTO 20060282817), on se dit qu'il doit y avoir des tas de brevets sur des points clefs des winforms qui trainent ici et là...

            Microsoft ne va tout de même pas commencer à faire peur aux développeurs mono alors que ceux-ci rassemblent un maximum de monde à la lisière de la belle clairière à la terre fraichement retournée...
        • [^] # Re: .NET et portabilité GUI = 2

          Posté par . Évalué à 2.

          Faudrait savoir. D'abord on lit « bouh Mono c'est pô compatib' », on démontre que si, et alors on lit « bouh, sapuyadesbrevets ». Si c'est pas de la mauvaise foi, ça. Tout ce que vous cherchez à faire, c'est dénigrer le projet parce que y'a du MS derrière (et encore, indirectement).

          Franchement, c'est lourd. Vous n'aimez pas Mono, ne l'utilisez pas, point. Personne ne vous le force, même pas votre distrib (je n'en connais aucune qui le fournisse d'emblée), alors arrêtez un peu de convaincre ceux qui l'utilisent et développent avec qu'ils sont des sous-merdes parce qu'ils favorisent l'empire du mal.

          Quand bien même, réfléchissez un peu : il y a cinq ans, Microsoft n'aurait jamais favorisé le portage d'une de ses technologies sous un OS libre, et maintenant, ils fournissent de la doc (sous contrat, certes). Au rythme où les mentalités changent (et où les têtes pensantes sont remplacées) chez eux, Windows sera libéré dans cinq ans...

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

          • [^] # Re: .NET et portabilité GUI = 2

            Posté par . Évalué à 3.


            Au rythme où les mentalités changent (et où les têtes pensantes sont remplacées) chez eux, Windows sera libéré dans cinq ans...

            Il aura sa place dans la galerie des monstres
            ou alors comme un exemple de ce qu'il ne faut pas faire dans toutes les universités :D
          • [^] # Re: .NET et portabilité GUI = 2

            Posté par (page perso) . Évalué à -1.

            En ce qui me concerne, je n'arrêterai pas de dénigrer Microsoft tant qu'il ne sera pas possible de ne pas être leur client. C'est une bonne raison, non ?
            • [^] # Re: .NET et portabilité GUI = 2

              Posté par (page perso) . Évalué à 1.

              Ils t'ont posé un flingue sur la tempe pour signer un contrat avec eux ?
              • [^] # Re: .NET et portabilité GUI = 2

                Posté par (page perso) . Évalué à 4.

                Non, on m'a juste forcé à m'engager à l'accepter sans le lire (je sais, c'est lourd comme construction syntaxique, mais c'est la réalité) pour pouvoir acheter mon ordinateur portable.

                Et on m'a ensuite refusé la possibilité de ne pas l'accepter selon ses propres termes (un remboursement, quoi).

                Bref, je suis client Microsoft contre mon gré, et je n'avais pas moyen de faire en sorte de ne pas l'être, puisqu'un ordinateur portable, il m'en fallait un pour mes études.
                • [^] # Re: .NET et portabilité GUI = 2

                  Posté par . Évalué à -4.

                  Dans ce cas tu devrais penser a denigrer le constructeur de ton portable plutot que MS.

                  Il y a nombre de societes qui vendent des machines sans Windows, preuve que MS ne force personne a vendre avec Windows uniquement.
                  • [^] # Re: .NET et portabilité GUI = 2

                    Posté par (page perso) . Évalué à 2.

                    C'est ça, rajoute que Microsoft n'y est pour rien, qu'on rigole.

                    Et si je veux c modèle d'ordinateur ? Au hasard, un ThinkPad R61 ou T42 ? Tiens, je suis contraint d'acheter une licence Windows…
                    • [^] # Re: .NET et portabilité GUI = 2

                      Posté par . Évalué à 0.

                      Mais je le rajoutes mon cher.

                      A toi de prouver que MS est coupable de ce dont tu l'accuses, et jusqu'a maintenant tu n'as RIEN montre.

                      Si IBM ne te vend pas un portable de type X sans Windows, c'est le choix d'IBM, pas de MS mon cher, a moins que tu n'aies des preuves montrant l'inverse, ce dont je doutes enormement.
                      • [^] # Re: .NET et portabilité GUI = 2

                        Posté par . Évalué à 2.

                        Je suis tout à fait d'accord avec toi, c'est nous qui accusons, donc c'est à nous d'avancer des preuves, que bien évidemment nous n'avons pas.

                        Mais il faut voir la réalité en face et reconnaître que seules de très rares marques proposent des machines sans Windows, et pour celles qui ne le font pas, tu ne peux refuser un CLUF qu'après avoir acheter le matériel et donc une licence Windows, que tu ne peux te faire rembourser une somme minime qu'après le parcours du combattant (quand tu arrives à te faire rembourser).

                        Nier que Microsoft y soit impliqué, c'est croire aux bisounours, surtout avec les nombreux coups bas dans pas mal d'autres cas qui ont été eux prouvés (Sun, Real, Netscape, etc), et les actes « avoués » par Microsoft (laisser faire le piratage pour être partout, entre autres).

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

                        • [^] # Re: .NET et portabilité GUI = 2

                          Posté par (page perso) . Évalué à 2.

                          Ah, tiens, si, Microsoft y est pour quelque chose, puisqu'ils acceptent de fournir des licences à des revendeurs qui ne permettent pas à leurs clients de bénéficier de tous les termes du contrat de licence.

                          Et bien, oui, un vendeur qui refuse de rembourser une licence Windows refusée par le client, il est en contradiction totale avec la licence en question. Normalement, Microsoft devrait vérifier que ses revendeurs permettent l'application du contrat de licence…
                          • [^] # Re: .NET et portabilité GUI = 2

                            Posté par (page perso) . Évalué à 2.

                            Et... en quoi ca le regarde ? pourquoi MS devrait faire ca ? Que tu sois responsable de ce que font des fournisseurs, ok, de ce que font tes clients...
                            • [^] # Re: .NET et portabilité GUI = 2

                              Posté par (page perso) . Évalué à 2.

                              Si, ça les regarde, parce que le contrat de licence de Windows est passé entre Microsoft et l'utilisateur final, et, bien qu'il ne soit pas signé par le revendeur, certaines de ses clauses supposent une action du vendeur, au hasard, un remboursement. Or, il me semble que ce sont les signataires qui s'engagent à respecter les clauses d'un contrat : dans notre cas, Microsoft s'engage à ce que son revendeur rembourse le prix de la licence si je la refuse.

                              On peut voir ça sous un autre angle : j'ai un contrat avec Microsoft, dont je veux faire jouer une clause. Si on me le refuse, qui est responsable ? Pas moi, puisque ma demande est légitime, selon les termes du contrat. Pas le revendeur, il n'est pas signataire…

                              Ensuite, il est possible que cette clause soit en réalité incorrecte et nulle, mais ça m'étonnerait, parce qu'elle n'a pas été mise pour rien, et que sans elle, le contrat de licence est à mon avis entièrement inacceptable et donc nul.
                              • [^] # Re: .NET et portabilité GUI = 2

                                Posté par . Évalué à -1.

                                Si, ça les regarde, parce que le contrat de licence de Windows est passé entre Microsoft et l'utilisateur final, et, bien qu'il ne soit pas signé par le revendeur, certaines de ses clauses supposent une action du vendeur, au hasard, un remboursement. Or, il me semble que ce sont les signataires qui s'engagent à respecter les clauses d'un contrat : dans notre cas, Microsoft s'engage à ce que son revendeur rembourse le prix de la licence si je la refuse.

                                Si tu lis la licence de Windows, elle parle de retourner le produit, elle ne parle pas de l'OS specifiquement, la licence OEM (entre MS et le constructeur) dit elle que le constructeur peut rembourser l'OS si il est retourne par le client.

                                Bref, perso de ce que j'en comprends, si tu decides de retourner le package complet, le constructeur DOIT te rembourser, sinon, le constructeur PEUT te rembourser si tu retournes l'OS uniquement.
                                • [^] # Re: .NET et portabilité GUI = 2

                                  Posté par . Évalué à 6.

                                  C'est marrant, ça ressemble à de la vente liée ;-)

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

                                • [^] # Re: .NET et portabilité GUI = 2

                                  Posté par (page perso) . Évalué à 2.

                                  Si tu lis la licence de Windows, elle parle de retourner le produit, elle ne parle pas de l'OS specifiquement

                                  Bien bien, l'ordinateur et la licence étant des produits différents, c'est très clair, il s'agit de rembourser le prix de la licence. CQFD.
                                  • [^] # Re: .NET et portabilité GUI = 2

                                    Posté par . Évalué à -1.

                                    J'adores ta manire de tout trouver tres simple :

                                    - Le mot "produit" est evidemment la licence dans le texte
                                    - Les constructeurs ont une solution tres simple : changer les manuels, former les vendeurs, changer leur images, ajouter un systeme de codes d'acces, etc...

                                    A se demander, tu es etudiant ou tu as deja bosse dans le monde reel ?
                                    • [^] # Re: .NET et portabilité GUI = 2

                                      Posté par (page perso) . Évalué à 2.

                                      Le mot "produit" est evidemment la licence dans le texte

                                      Oui, on est d'accord, et alors ?

                                      Les constructeurs ont une solution tres simple

                                      Certainement pas un obstacle pour eux, puisqu'ils l'appliquent déjà ! Dans certains pays, et même en France, pour des ventes de détail réservées aux étudiants, par exemple.

                                      A se demander, tu es etudiant ou tu as deja bosse dans le monde reel ?

                                      Les deux mon capitaine, mais pas dans la grande distribution. En tout cas, je vis dans un monde^W pays où un éditeur de logiciels est maintenu dans une position de monopole proprement ahurissante.
                                      • [^] # Re: .NET et portabilité GUI = 2

                                        Posté par . Évalué à 1.

                                        Oui, on est d'accord, et alors ?

                                        C'etait ironique, non ne je ne suis pas d'accord

                                        Certainement pas un obstacle pour eux, puisqu'ils l'appliquent déjà ! Dans certains pays, et même en France, pour des ventes de détail réservées aux étudiants, par exemple.

                                        C'est pas un obstacle ? Ben oui, c'est donc qu'ils sont simplement stupides et ne comprennent rien a leur ligne de production alors...ou peut-etre c'est de la mauvaise volonte du fait que cela ne leur amene rien si ce n'est du boulot en plus...

                                        Les deux mon capitaine, mais pas dans la grande distribution. En tout cas, je vis dans un monde^W pays où un éditeur de logiciels est maintenu dans une position de monopole proprement ahurissante.

                                        Ca explique probablement pourquoi tu ne comprends rien a la problematique du point de vue des constructeurs.
                                        Que MS soit maintenu dans une situation de monopole, je le comprends bien, le point qui croche, c'est les raisons: Simplifier la production en n'ayant qu'un produit(qui ramene de l'argent grace aux parteneriats avec des editeurs qui veulent avoir leur softs installes par defaut) a gerer arrange tout le monde.

                                        Le PC sans OS n'arrange personne, difficile donc de l'envisager sauf pour les grosses commandes car la le client(une entreprise d'habitude) a un moyen de pression.

                                        Un PC avec Linux sera enviseagable en masse le jour ou il rapportera autant qu'un PC avec Windows au constructeur.

                                        C'est une simple logique mercantile vraiment.
                                        • [^] # Re: .NET et portabilité GUI = 2

                                          Posté par (page perso) . Évalué à 2.

                                          C'etait ironique, non ne je ne suis pas d'accord

                                          Avec Windows XP, c'était pourtant très clair. Mais la licence de Windows Vista apporte une importante régression à ce sujet, malheureusement.

                                          C'est pas un obstacle ? Ben oui, c'est donc qu'ils sont simplement stupides et ne comprennent rien a leur ligne de production alors...ou peut-etre c'est de la mauvaise volonte du fait que cela ne leur amene rien si ce n'est du boulot en plus...

                                          Non, puisqu'ils le font déjà ! De façon marginale en France, et beaucoup plus générale dans d'autres pays. Le travail est déjà fait.

                                          Le PC sans OS n'arrange personne

                                          IL-NE-S'AGIT-PAS-DE-PC-NUS

                                          Un PC avec Linux sera enviseagable

                                          IL-NE-S'AGIT-PAS-DE-PC-AVEC-GNU/LINUX-PRÉINSTALLÉ
                                          • [^] # Re: .NET et portabilité GUI = 2

                                            Posté par . Évalué à 1.

                                            Je reformule :

                                            Un PC ou le constructeur ne se fait pas autant d'argent qu'avec un PC+Windows n'est pas enviseagable.

                                            Que tu le fasses sans OS, avec Windows+code d'acces, Linux, MultiDeskOS ou autre, le probleme a la base c'est ce que ca rapporte.

                                            On sait deja que sans OS ou avec Linux n'est aujourd'hui pas le cas, Windows+code d'acces rend la chose plus complexe c'est garanti(va falloir gerer ces codes d'acces, les reinstallations, ...), donc couts plus eleves, bref meme topo.
                                            • [^] # Re: .NET et portabilité GUI = 2

                                              Posté par (page perso) . Évalué à 2.

                                              On sait deja que sans OS ou avec Linux n'est aujourd'hui pas le cas

                                              SI,-C'EST-LE-CAS, pour des ventes étudiantes ou à des entreprises, et dans des pays étrangers, ce qui prouve, il me semble, que des constructeurs peuvent le faire sans problème.
                                              • [^] # Re: .NET et portabilité GUI = 2

                                                Posté par (page perso) . Évalué à 2.

                                                Précision, ça casse simplement un bon nombre d'arguments, notamment :
                                                - trop compliqué de proposer le choix entre préinstallé et nu (il s'agit de nu, ici) :
                                                - trop cher à mettre en œuvre ;
                                                - problèmes de support : non, puisque choisir de ne pas acheter le système d'exploitation proposé demande une action volontaire (décocher une case), et comporte un avertissement très clair (réservé à ceux qui savent ce qu'ils font, en gros).
                                                • [^] # Re: .NET et portabilité GUI = 2

                                                  Posté par . Évalué à 1.

                                                  Toi tu ne comprends pas la difference entre le cas entreprise/contrat gouvernement ou le client a un moyen de pression et le cas du pekin moyen.

                                                  Dans le cas a) le client demande ce qu'il veut, et le constructeur prefere se faire 30$ que rien du tout, parce que l'entreprise/gouvernement quand il demande une offre pour 5'000 machines, ca a tendance a attendrire les constructeurs.

                                                  Dans le cas du pekin moyen, lui n'a aucun moyen de pression parce que dans 90% des cas il va prendre un gros constructeur, et la ils font tous du Windows uniquement, bref il va pas menacer Dell d'aller chez HP vu qu'ils fournissent le meme truc.

                                                  Maintenant tu peux decider de rester colle a tes prejuges, mais tant que tu ne comprendras pas l'etat d'esprit des constructeurs tu en resteras a essayer des trouver des theories fumeuses pour expliquer leur comportement.
                                                  • [^] # Re: .NET et portabilité GUI = 2

                                                    Posté par (page perso) . Évalué à 2.

                                                    Non, ça tient toujours.

                                                    Les ventes étudiantes que je mentionnes sont individuelles, ce qui prouve que les constructeurs ont les moyen techniques pour proposer une optionnalité, et que les ventes sans licence Windows ne leurs coûtent pas plus cher : c'est déjà ça.

                                                    Par ailleurs, ils pourraient tout à fait proposer, au même prix ou pour une différence ridicule, des ordinateurs sans licence. Ce serait scandaleux, mais, en ce qui me concerne, je préfère payer le même prix, mettre la différence dans la poche du directeur, et être sûr de ne pas aider à financer une entreprise dont je ne souhaite pas être client et qui ne m'apporte rien.

                                                    Si mon boulanger me vendait le pain 1 euro, donc 25 centimes pour le sac en plastique de marque Machin (toujours la même), comme je n'ai pas besoin de ce sac, je préférerais encore donner directement les 25 centimes au boulanger, avec sa garantie qu'il ne les donnera pas à Machin.
                                                    • [^] # Re: .NET et portabilité GUI = 2

                                                      Posté par . Évalué à 0.

                                                      Les ventes étudiantes que je mentionnes sont individuelles, ce qui prouve que les constructeurs ont les moyen techniques pour proposer une optionnalité, et que les ventes sans licence Windows ne leurs coûtent pas plus cher : c'est déjà ça.

                                                      Mais evidemment qu'ils ont les moyens techniques, c'est juste moins rentables donc ils font tout pour l'eviter.

                                                      Par ailleurs, ils pourraient tout à fait proposer, au même prix ou pour une différence ridicule, des ordinateurs sans licence. Ce serait scandaleux, mais, en ce qui me concerne, je préfère payer le même prix, mettre la différence dans la poche du directeur, et être sûr de ne pas aider à financer une entreprise dont je ne souhaite pas être client et qui ne m'apporte rien.

                                                      Au meme prix ? Mais tu ne comprends pas le probleme mon cher, arretes de voir les choses de ton point de vue et regarde du point de vue du constructeur.
                                                      Symantec, McAfee, Google, ... ne vont pas les payer si Windows n'est pas sur la machine, alors ils se retrouvent avec un Windows non-installe qu'ils ne paient pas, mais ils se retrouvent aussi avec ces softs non-installes qui ne leur rapportent pas l'argent escompte tout en devant gerer une configuration(sans OS) de plus et les appels au support potentiels de gens qui se demandent pourquoi il n'y a rien quand le PC demarre, qui telephonent apres avoir essaye d'installer Windows eux-meme et ca marche pas, etc...

                                                      Sinon, ta comparaison entre un constructeur de PC qui est une multinationale et un boulanger me fait bien rire...
                                                      • [^] # Re: .NET et portabilité GUI = 2

                                                        Posté par (page perso) . Évalué à 2.

                                                        Bien, mine de rien, tu détruis toi-même pas mal d'arguments. Je doute quand même que les boufficiels rapportent d'avantage d'argent que le prix d'une licence Windows, mais je suis content de voir que la théorie des boufficiels ne semble pas si fumeuse.

                                                        Pour les appels au support que tu ressors à chaque fois, c'est une impasse : je pense qu'il suffit de mettre les avertissements qui vont bien, et tu penses que ça ne suffit pas. Bon, il faudra voir que ce que donnera dans quelques années ou décennies.

                                                        Dans tous les cas, j'espère qu'on sortira un jour de cette distorsion de concurrence.
                                                        • [^] # Re: .NET et portabilité GUI = 2

                                                          Posté par (page perso) . Évalué à 2.

                                                          pBpG a raison : en fait tu résonnes en individuel et non en effet de masse.

                                                          Les constructeurs qui vendent des centaines de milliers de machines résonnent en masse, et s'il commencent à proposer une optionnalité, kro$oft va voir une baisse de ses volumes de ventes, ainsi que ses associés et donc devoir augmenter les tarifs de licences OEM, et donc baisser la marge du constructeur.

                                                          Il n'y a pas d'étique qui tiens...

                                                          Atterrissez un peu les fanatiques du libre, c'est une histoire de négociation commerciale, pas d'éthique...

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

                                                          • [^] # Re: .NET et portabilité GUI = 2

                                                            Posté par (page perso) . Évalué à 1.

                                                            Là, ce n'est pas du fanatisme du libre, mais de la concurrence, en tant que pression bénéfique pour l'économie de marché.
                                                            • [^] # Re: .NET et portabilité GUI = 2

                                                              Posté par . Évalué à 3.

                                                              Bon, après avoir bien trollé avec pBpG, tu comprendra que tout ça c'est de la magouille de haut vol, que la concurrence, le marché libre, toussa, c'est que de la connerie, et que c'est juste qu'on nous impose (pas que MS, le gouvernement et les grands industriels de ce pays) ce qu'ils veulent. Point. Ça fait très carricatural, mais franchement, à discuter sans fin dans un "débat" comme ça, au bout d'un moment, il faut se faire une raison.
                        • [^] # Re: .NET et portabilité GUI = 2

                          Posté par . Évalué à -1.

                          Mais il faut voir la réalité en face et reconnaître que seules de très rares marques proposent des machines sans Windows, et pour celles qui ne le font pas, tu ne peux refuser un CLUF qu'après avoir acheter le matériel et donc une licence Windows, que tu ne peux te faire rembourser une somme minime qu'après le parcours du combattant (quand tu arrives à te faire rembourser).

                          Mais je reconnais cela parfaitement, et si j'etais constructeur, je ferais comme eux !

                          Allez, imagines que tu es constructeur, tu peux vendre :

                          PC(500$, tu fais disons 30$ de benef dessus)+Windows(100$, tu l'as paye 90)+Google Toolbar(Google te paie 10$)+Symantec Anti-Virus(Symantec te paie 10$)+....

                          ou

                          PC(500$, 30$ de benef)

                          Resultat des courses :

                          60$ de benef pour le cas 1)
                          30$ de benef pour le cas 2)

                          Faudrait etre stupide pour choisir le cas 2
                          • [^] # Re: .NET et portabilité GUI = 2

                            Posté par (page perso) . Évalué à 2.

                            L'ennui, c'est que le second cas, il est illégal.
                            • [^] # Re: .NET et portabilité GUI = 2

                              Posté par (page perso) . Évalué à 4.

                              Remarque, c'est intéressant, parce que pour le moment, les constructeurs bénéficient d'une tolérance qu'ils justifient en disant que « c'est pour le bien du consommateur ». Et là, tu es en train de prouver de façon magistrale que, au contraire, c'est pour leur bien ! :-)
                              • [^] # Re: .NET et portabilité GUI = 2

                                Posté par . Évalué à -1.

                                Tu sais, ca peut etre pour les deux. Evidemment il y a differents avis sur le fait que c'est pour le bien du consommateur, et la repression des fraudes et le gouvernement ne sont pas forcement du cote de l'APRIL la dessus.

                                Mais comme tu viens de l'admettre, les constructeur ont interet a faire cela independamment de toute pression de MS.

                                Il serait donc de bon ton que tu revises tes accusations envers MS sans argument valable sur ce point.
                • [^] # Re: .NET et portabilité GUI = 2

                  Posté par (page perso) . Évalué à 2.

                  >Non, on m'a juste forcé à m'engager à l'accepter sans le lire (je sais, c'est lourd comme construction syntaxique, mais c'est la réalité) pour pouvoir acheter mon ordinateur portable.

                  Heu tu peux depuis des années acheter un portable sans windows (et meme sous linux), par exemple chez Keynux.
                  Tu peux aussi acheter un portable Mac par exemple.

                  C'est juste que la configuration que TU voulais, n'etait pas disponible chez le vendeur que TU voulais au prix ou TU voulais. (et c'est un probleme j'en convient)

                  Moi mon revendeur ne m'a jamais imposé d'acheter un clavier/souris ou de prendre une assurance/garantie, il ne m'impose pas non plus l'OS...

                  Ça ne veux pas dire qu'il ne faut pas dénoncer les abus de MS mais il est tout a fait possible de ne pas être leur client.
                  • [^] # Re: .NET et portabilité GUI = 2

                    Posté par (page perso) . Évalué à 1.

                    Bien d'accord, mais il faut reconnaître que:

                    1- Keynux c'est pas vraiment connu (enfin *je* ne connais pas) et pas accessible au grand nombre.

                    2- Les machines vendues dans le commerce *grand public* ne sont pas disponible sans windows à la grande majorité (99%). Va dans n'importe quel magasin qui n'est pas un intégrateur... genre un carrouf, mediamarkt ou sur internet Dell, etc ben t'as pas de portable sans windows.

                    Donc oui c'est possible d'acheter sans windows... pour des gens avertis avec des configs qu'on choisit pas vraiment.
              • [^] # Re: .NET et portabilité GUI = 2

                Posté par (page perso) . Évalué à 2.

                Ceci dit, il s'agit bien de coercition. Ce n'est pas : achetez nos licences, sinon on vous tue, mais simplement : achetez nos licences, sinon vous n'aurez pas d'ordinateur portable.
          • [^] # Re: .NET et portabilité GUI = 2

            Posté par (page perso) . Évalué à 1.

            c'est ça qu'une grosse partie de la communaité linux à décidé... on en veut pas

            www.solutions-norenda.com

            • [^] # Re: .NET et portabilité GUI = 2

              Posté par . Évalué à 2.

              Tout à fait. D'ailleurs, une grosse partie de la communauté informatique ne veut pas de Linux. Je dirais environ... 95%. Et donc, selon ton raisonnement, on devrait arrêter le développement de Linux.

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

          • [^] # Re: .NET et portabilité GUI = 2

            Posté par . Évalué à 1.

            Au rythme où les mentalités changent (et où les têtes pensantes sont remplacées) chez eux, Windows sera libéré dans cinq ans...

            Bon, là on voit bien que tu n'es pas bien ancré dans la réalité...

            Tout ce que vous cherchez à faire, c'est dénigrer le projet parce que y'a du MS derrière (et encore, indirectement).

            Oui, on est que des méchants qui aiment pas Microsoft et n'ont pas de vrais arguments...

            arrêtez un peu de convaincre ceux qui l'utilisent et développent avec qu'ils sont des sous-merdes parce qu'ils favorisent l'empire du mal.

            Ah oui, on souligne le fait que la problématique des brevets n'est pas mise à plat, donc on traite les développeurs de mono de sous-merdes... c'est logique... et tu programmes sinon?

            Pour ta gouverne, de nombreux grands acteurs du marché ont signalé officiellement, en dehors de toute contrainte normative, qu'ils octroyaient des licences perpétuelle et inaliénable à leurs brevets sur certaines technologies pour que les logiciels libres puissent les intégrer. Microsoft ne l'a pas fait, en dehors de ce qui est passé en norme ECMA il n'y a aucune base légale pour ce qui est intégré à Mono, pourquoi à ton avis? Pourquoi Microsoft a t'il décidé de garder une arme chargée braquée sur la communauté libre? Pourquoi Microsoft tient-il à faire signer des accords sur ses brevets aux entreprises qui veulent utiliser ou distribuer linux? Pourquoi Mono est-il un projet à peine reconnu par Microsoft, alors que ce dernier pourrait activement le supporter?

            On peut tout de même se poser la question si Microsoft n'essaye pas simplement d'ouvrir temporairement, sans se mouiller, .Net au monde libre tout en gardant le bouton à portée de main pour sonner la fin de la récré une fois ses objectifs de parts de marché atteints.

            Si Microsoft daignait donner des signaux forts d'engagement ferme dans une politique d'accès à ses brevets pour tous les utilisateurs de mono (et pas seulement ceux couverts par l'accord avec novell), je pense qu'il n'y aurait plus de quoi autant s'inquiéter.
            • [^] # Re: .NET et portabilité GUI = 2

              Posté par (page perso) . Évalué à 3.

              Pour ta gouverne, de nombreux grands acteurs du marché ont signalé officiellement, en dehors de toute contrainte normative, qu'ils octroyaient des licences perpétuelle et inaliénable à leurs brevets sur certaines technologies pour que les logiciels libres puissent les intégrer.
              Et quand Microsoft le fait, tout le monde gueule en s'improvisant juriste et en criant au loup parcque y'a sûrement un piège :
              http://www.microsoft.com/interop/osp/default.mspx

              il n'y a aucune base légale pour ce qui est intégré à Mono, pourquoi à ton avis?
              Pour les API de compatibilité, oui. Idem pour Wine. Pour le reste, à savoir ce qui est normalisé ECMA + API spécifiques à Mono (GTK#, etc.), t'as pas plus de problème qu'avec un autre framework.

              Pourquoi Mono est-il un projet à peine reconnu par Microsoft, alors que ce dernier pourrait activement le supporter?
              Putain mais ca sert à quoi d'écrire un article ? Je précise justement que le port de Silverlight par mono est important d'un point de vue politique puisque c'est la reconnaissance officiel de cette implémentation "alternative", que MS aide activement l'équipe Mono, qu'ils partagent même du code !

              Pourquoi Microsoft tient-il à faire signer des accords sur ses brevets aux entreprises qui veulent utiliser ou distribuer linux?
              Parcque Linux est un concurrent ? Parcque les acteurs du libre ont autant d'armes pointées dans l'autre sens et que la plupart des accords sont bidirectionnels ?

              Si Microsoft daignait donner des signaux forts d'engagement ferme dans une politique d'accès à ses brevets pour tous les utilisateurs de mono
              pourquoi mono ? c'est pas spécifique à mono ! c'est tout linux qui est dans la même position vis-à-vis de Microsoft !
              • [^] # Re: .NET et portabilité GUI = 2

                Posté par . Évalué à 1.

                Et quand Microsoft le fait, tout le monde gueule en s'improvisant juriste et en criant au loup parcque y'a sûrement un piège :
                http://www.microsoft.com/interop/osp/default.mspx


                D'un autre côté, dans cette liste, on retrouve aussi l'IP v6, et un paquet d'éléments arrachés par la contrainte par la commission européenne ...

                Parcque Linux est un concurrent ? Parcque les acteurs du libre ont autant d'armes pointées dans l'autre sens et que la plupart des accords sont bidirectionnels ?

                Tu trouves donc normal donc le fait que Microsoft essaye de se placer comme garde barrière devant GNU/Linux et force les distributeurs à négocier son autorisation pour avoir accès aux libertés du logiciel libre? Et tu voudrais ensuite nous dire d'avancer en terrain miné?

                pourquoi mono ? c'est pas spécifique à mono ! c'est tout linux qui est dans la même position vis-à-vis de Microsoft !

                Et c'est une raison pour augmenter l'ampleur du risque?
              • [^] # Re: .NET et portabilité GUI = 2

                Posté par . Évalué à 1.

                Ben vu que tu n'as pas reussi a trouver une applis microsoft programme en .NET qui tourne sous linux avec Mono je pense que l'on peut aisement speculer que .NET n'est pas franchement fait pour la portabilite des applications (contrairement a Java) et qui plus est que Microsoft continue a jouer a son jeu a la con qui consister a tenter d'isoler son concurrent. Et par consequent j'en deduis de facon tres naturelle que C#/.NET c'est un piege.
              • [^] # Re: .NET et portabilité GUI = 2

                Posté par (page perso) . Évalué à 2.

                Parcque Linux est un concurrent ?

                Concurrent ? Excusez-moi, j'ai dû manquer un épisode. Depuis quand y a-t-il concurrence sur la distribution de systèmes d'exploitation pour PC ?
              • [^] # Re: .NET et portabilité GUI = 2

                Posté par . Évalué à 1.

                Faux, Mono et .net ne partagent aucun code. Dotnet est sous licence Microsoft Reference License qui autorise seulement à regarder le code mais interdiction formelle d'y toucher sous peine de poursuite. D'ailleurs Miguel de Icaza l'a dit la version 2.0 de Mono n'a pas bénéficié des travaux effectués dans les sacro-saints laboratoires d'interopérabilité, issus de l'accord polémique entre Microsoft et Novell. Et confirme que la seule collaboration avec les équipes Microsoft porte sur Moonlight, l'éditeur de Redmond ayant partagé les spécifications et les résultats de tests de Silverlight .

                http://www.lemagit.fr/article/open-source-microsoft-developp(...)
                • [^] # Re: .NET et portabilité GUI = 2

                  Posté par (page perso) . Évalué à 2.

                  Faux, Mono et .net ne partagent aucun code.
                  si.
                  Et confirme que la seule collaboration avec les équipes Microsoft porte sur Moonlight,
                  C'est de ca que je parle.
                  Et entre autre de IronPython et du DLR, qui sont bien développés par MS sous licence open-source approuvée par la FSF, et la pas Microsoft Reference Licence, mais la Microsoft Public Licence, quoique t'en dise. Et utilisé dans Moonlight, quoique t'en dise.
        • [^] # Re: .NET et portabilité GUI = 2

          Posté par (page perso) . Évalué à 0.

          Sauf que les brevets logiciels ne tiennent pas en Europe, donc les brevets de MS sur les WinForms on s'en fout.
          Après, ce serait bien de travailler avec les pays du reste du monde pour qu'ils puissent aussi y accéder. Mais je ne pense pas qu'on devrait se limiter à cause d'autres pays qui ont une législation bancale. A mon avis, moins on prend en compte les brevets logiciels dans nos choix, mieux on peux démontrer que ceux ci sont nocifs.

          Et dernière chose, je pense (à vérifier) que si on utilise des brevets logiciels en Europe, si ils sont un jour autorisés, je ne pense pas que les projets existants les utilisant puissent être condamnés pour leur utilisation. C'est le principe de non rétroactivité.
      • [^] # Re: .NET et portabilité GUI = 2

        Posté par (page perso) . Évalué à 2.

        J'avais indiqué (1) fonctionne != experimental

        Mono 2.0 supporte officiellement les Windows.Forms [...] Non c'est pas bancale
        Ah oui, c'est vrai et ça ressemble même à ça :
        http://www.mono-project.com/Image:Monopaint.png
        Ça botte quelqu'un pour son desktop Linux ?

        y'a GTK sous mac
        Depuis 1 semaine LOL
        Voila un screenshot : http://developer.imendio.com/sites/developer.imendio.com/fil(...)
        Bref GTK Windows/Mac même combat que les WinForms sous Linux : personne ne veut de ça !

        On est quand même loin des frameworks comme Java/Qt ou les GUI sont un minimum intégrées à l'environnement cible sans compter que tout ça ça doit pas être super mature. Ca serait rigolo qu'un Qt C# stable arrive en sauveur http://www.qyoto.org/


        La vérité c'est que Microsoft a tout fait pour que .NET ne soit pas multiplateforme. Si les WinForms march(ottent) sous d'autres OS c'est non-voulu ni supporté par son créateur et donc franchement pas fait pour (i.e il doit y avoir des grosses surprises)
        C'est quand même super con d'avoir un tout nouveau langage/framework que l'on nous vends comme le meilleur du monde alors qu'il n'est même pas réellement multiplateforme. Mono palie tout simplement aux manquements de .NET

        Conclusion: si j'avais à coder une appli multi-OS je ne le ferais clairement pas en C#/.NET/Mono
        • [^] # Re: .NET et portabilité GUI = 2

          Posté par (page perso) . Évalué à 5.

          J'ai l'impression que je me suis un peu trop lache dans mon post...

          Je viens de lire ca http://www.mono-project.com/WinForms
          et en gros l'implementation des WinForms sous Mono c'est le meme principe que Qt : des primitives de dessin qui sont specifiques a la plateforme (~20% du code j'imagine) et tout le reste (~80%) multiplateforme. C'est un nouveau toolkit recode de 0.
          Actuellement le theme des WinForms/Mono utilise un theme "Windows classic" mais rien n'empeche dans le futur (comme Qt) d'avoir des themes natifs.

          Donc bref ironiquement les Windows Forms sont probablement le meilleur choix (vs GTK+) si un jour on souhaite que son soft ressemble a quelque chose sur toutes les plateformes.
          • [^] # Re: .NET et portabilité GUI = 2

            Posté par (page perso) . Évalué à 3.

            et en gros l'implementation des WinForms sous Mono c'est le meme principe que Qt :
            pareil pour GTK, pour quasiment tous les toolkits graphiques j'ai envie de dire :) Tu croyais quoi ? Que les WinForms étaient hardcodés par Intel dans ses CPU pour tourner uniquement sous Windows ? :)

            d'avoir des themes natifs.
            Comme GTK... ok c'est pas parfait comme thèmes, mais des applications comme Gimp ou Pidjin arrivent à ne pas être trop moches sous Windows ou MacOSX.

            Qt c'est gentil mais c'est pas la panacé non plus : visuellement le toolkit se débrouille pas mal niveau intégration, mais y'a encore du boulot à faire côté ergonomie et accessibilité. Bref, y'a aucune toolkit portable qui permettent de faire des applications bureautiques vraiment intégrées, à part dans leur environnement natif. Pour le moment, la seule façon de faire est d'avoir une interface spécifique pour chaque environnement et le coeur de l'application partagé : c'est du boulot de dev/maintenance, mais c'est la seule solution qui peut se vanter d'être vraiment multi-plateforme.
            • [^] # Re: .NET et portabilité GUI = 2

              Posté par (page perso) . Évalué à 2.

              SWT, utilisé par Eclipse ?
            • [^] # Re: .NET et portabilité GUI = 2

              Posté par (page perso) . Évalué à 3.

              pour quasiment tous les toolkits graphiques
              AWT, WxWidgets, SWT et probablement un paquet d'autres... meme les WinForms/Mono puisqu'ils avaient commences par faire un backend GTK+
              Il est probable que la majorite des toolkits graphiques utilisent cette methode. Par exemple les MFC et autres WFC sont des bindings par dessus les widgets win32.
              Et perso j'etais resté sur l'idee que les WinForms/Mono etaient implementees en utilisant Wine d'ou mon post juste au dessus.

              Qt c'est gentil [...] mais y'a encore du boulot à faire côté ergonomie et accessibilité.
              Je suis tres curieux de connaitre les problemes d'ergonomie et d'accessibilite de Qt ! Et ensuite comparer avec WinForms, GTK+ et les autres.

              Gimp ou Pidjin arrivent à ne pas être trop moches sous Windows ou MacOSX
              Pour MacOSX, suffit de regarder les screenshots que j'ai balance au dessus
              http://developer.imendio.com/sites/developer.imendio.com/fil(...)
              http://developer.imendio.com/sites/developer.imendio.com/fil(...)
              Sous MacOSX ton soft GTK+ a la meme gueule que sous Linux :/

              Sous Windows ca s'ameliore mais y'a encore beaucoup de trucs a faire. Genre aucune boite de dialogue n'est native. En dehors des boutons et des scrollbars y'a encore pas mal de widgets qui n'ont pas de theme natif (genre les combobox). Sans compter que sous Windows, GTK+/GLib ne compile pas avec Visual C++ mais uniquement avec MinGW et ca peut etre pas mal handicapant.

              Pour faire court, ce que les utilisateurs GTK+ supportent sous Windows et MacOSX, pas beaucoup de Linuxiens le supporteraient sur leurs propres systemes.

              Que les WinForms étaient hardcodés par Intel
              T'as bouffe quoi pour faire des blagues aussi droles ?
              • [^] # Re: .NET et portabilité GUI = 2

                Posté par (page perso) . Évalué à 3.

                Je suis tres curieux de connaitre les problemes d'ergonomie et d'accessibilite de Qt
                Ben c'est pas compliqué, chaque destktop a ses recommandations et ses règles pour concevoir les IHM (ordre des boutons, style de nommage, convention de boîtes de dialogue, etc.), autant de truc qui varie d'un environnement à un autre, et Qt ne résoud pas ce problème (ou très peu).

                Sous MacOSX ton soft GTK+ a la meme gueule que sous Linux :/
                C'est un thème comme un autre... tu peux utiliser ce thème GTK sous Windows aussi... D'ailleur je le fais car je le trouve classe ce thème :)

                En dehors des boutons et des scrollbars y'a encore pas mal de widgets qui n'ont pas de theme natif (genre les combobox)
                Forcement quand y'a pas d'équivalent dans la plateforme cible...

                Globalement je suis d'accord que GTK+ s'intègre pas aussi bien dans Windows que d'autres toolkits, mais y'a aucun toolkit qui fait un truc acceptable pour une application de bureautique un minimum soignée et désirant être intégrée dans le bureau.

                T'as bouffe quoi pour faire des blagues aussi droles ?
                Un truc au moins aussi délirant que ce que t'as fumé dans ton premier post sur les WinForms ;)

                Au final je te rappelle quand même que ta remarque initiale portait sur le côté "expérimental", au final on s'aperçoit que tous les toolkits sont à la même enseigne : ils sont portables mais y'a un problème d'intégration. La plupart supporte la notion de thème pour s'intégrer visuellement mais quand c'est fait c'est jamais suffisant.
                • [^] # Re: .NET et portabilité GUI = 2

                  Posté par (page perso) . Évalué à 5.

                  Qt ne résoud pas ce problème (ou très peu)
                  Rectificatif : Qt resoud bien mieux ce genre de problemes que n'importe qu'elle autre toolkit, et de tres tres tres loin.
                  C'est meme le fond de commerce de Trolltech. Ca fait plus de 10 ans que Qt fonctionne sur Win/Linux/Mac. Ca tourne meme sur WinCE en natif depuis peu (!)

                  ordre des boutons
                  http://doc.trolltech.com/4.4/qdialogbuttonbox.html

                  style de nommage
                  En partie, ca depend ce que t'appelle style de nommage
                  Par exemple voici un wizard Qt sous differents OS :
                  http://doc.trolltech.com/4.4/qwizard.html#wizard-look-and-fe(...)
                  Apres c'est sur que le titre d'une fenetre faudra peut etre faire des #ifdef mais c'est tout a fait normal.

                  boîtes de dialogue
                  Toutes les boites de dialogues sont natives avec Qt. Meme celles pour l'impression http://doc.trolltech.com/4.4/qprintdialog.html ou le systray http://doc.trolltech.com/4.4/qsystemtrayicon.html

                  Au passage, Qt s'integre parfaitement a GNOME depuis peu (meme les boites de dialogues) (ca fonctionne aussi sous Windows !)
                  http://labs.trolltech.com/blogs/2008/10/02/qgtkstyle-now-on-(...)

                  C'est un thème comme un autre
                  Non justement ! le style MacOSX c'est pas juste une scrollbar bleue. Typiquement sous Windows il est impossible de faire la difference entre une appli Qt et une appli MFC/WTL. pareil sous MacOSX, Qt utilise Carbon et bientot Cocoa (ce qui va resoudre les derniers problemes connus).

                  Faire un theme natif, c'est pas du coloriage mais utiliser l'API de la plateforme et c'est pas franchement evident a faire. Avant que WinForms/GTK+ arrivent a un niveau equivalent du Qt de 2008 il va falloir attendre encore quelques longues annees.

                  Quand on lit la doc de Qt, il y a plein d'endroits ou il a des trucs specifiques a une plateforme ou une autre, des methodes qui ne font rien sur certaines plateformes ect... et c'est hyper bien foutu et pour aller plus loin il y a aussi des vrais exemples http://doc.trolltech.com/qq/qq23-layouts.html http://doc.trolltech.com/qq/qq19-buttons.html
                  WinForms ne pourra jamais faire ca car l'API est controlee par Microsoft et a ete concu seulement pour fonctionner sous Windows contairement a Qt qui est fait pour des le depart.

                  Au final je te rappelle quand même que ta remarque initiale portait sur le côté "expérimental"
                  Oui c'est vrai, c'est pourquoi j'ai indique que "je me suis un peu trop lache dans mon post" car la derniere fois que j'ai utilise C#, WinForms utilisait Wine et GTK+ sous Mac utilisait X11 (!)

                  Neamoins entre
                  http://picasaweb.google.co.uk/icefox/AroraScreenshots#523144(...)
                  http://labs.trolltech.com/blogs/wp-content/uploads/2008/02/d(...)
                  http://code.google.com/p/arora/wiki/Screenshots
                  et ca
                  http://developer.imendio.com/sites/developer.imendio.com/fil(...)
                  http://www.mono-project.com/Image:Monopaint.png
                  Ba y'a trop pas photo
                  • [^] # Re: .NET et portabilité GUI = 2

                    Posté par . Évalué à 3.

                    Si Gnome/GTK voulait avoir un truc coherent avec le reste du systeme cela se saurait depuis longtemps en tout cas sous linux c'est toujours de Qt/KDE que sont venu les efforts pour harmonisait les deux interfaces graphiques. Il y a deja plusieurs annees dans le sens GTK -> KDE (c'est a dire faire en sorte que les applis GTK s'integre bien dans KDE) et depuis peu dans l'autre sens Qt -> GTK (c'est a dire que les applis Qt s'integre bien dans un bureau GTK). Mais bon visiblement faire en sorte de respecter l'apparence d'un systeme proprio semble etre de plus grande priorite pour les gtkiste/gnomeiste... C'est un peu dommage mais vu l'origine de Gnome c'est assez peu surprenant!
                  • [^] # Re: .NET et portabilité GUI = 2

                    Posté par (page perso) . Évalué à 1.

                    Apres c'est sur que le titre d'une fenetre faudra peut etre faire des #ifdef mais c'est tout a fait normal.
                    Mais pas cross plateform pour 2 sous. C'est évidemment de ca que je parlais : je connais aucun toolkit capable de modifier les label écrits par les développeurs pour refleter le style verbal recommandé.

                    Toutes les boites de dialogues sont natives avec Qt.
                    Je parle pas d'être natif ou non, ni des boîtes de dialogue ouvrir fichier & co, mais des boîtes de dialogue créé par le développeur.

                    Non justement !
                    Et t'as jamais eu l'idée qu'on pouvait utiliser les widgets natifs dans un thème ? C'est exactement ce que fait le thème gtk-wimp sous Windows.

                    Faire un theme natif, c'est pas du coloriage
                    Sans dec. J'ai déjà dis le contraire ?

                    Avant que WinForms/GTK+ arrivent a un niveau equivalent du Qt de 2008 il va falloir attendre encore quelques longues annees.
                    oui, je suis bien d'accord, qt est sans doute le moins pourri (encore que une appli Qt sous Gnome c'est pourri) "visuellement", mais ca reste que si on veut une application intégré au destktop, c'est pas la bonne solution à l'heure actuelle.

                    contairement a Qt qui est fait pour des le depart.
                    Qt s'intègre très mal sous Gnome par exemple qui a une gestion de layout complètement différente.

                    car la derniere fois que j'ai utilise C#, WinForms utilisait Wine et GTK+ sous Mac utilisait X11 (!)
                    Oué donc en gros tu critiquais une API pas finie quand moi j'annonce qu'elle est finie. Forcement :)
              • [^] # Re: .NET et portabilité GUI = 2

                Posté par (page perso) . Évalué à 2.

                Je suppose que GTK sous mac os X avec ce thème doit avoir un peu plus de gueule : http://www.gnome-look.org/content/show.php/show.php?content=(...)
    • [^] # Re: .NET et portabilité GUI = 2

      Posté par (page perso) . Évalué à 5.

      Java SWING ou SWT ne pose pas ce problème

      Mouais… Ce ne sont pas des saletés qui supposent que ton gestionnaire de fenêtre change le parent de ta fenêtre, ces composants ?
    • [^] # Re: .NET et portabilité GUI = 2

      Posté par . Évalué à 2.

      Tu me montres une vraie appli avec une vraie GUI écrite en Java et je change mon opinion au sujet de Java sur le poste de travail.

      Attention : "vraie appli" = PAS un IDE (ce serait trop facile).
    • [^] # Re: .NET et portabilité GUI = 2

      Posté par . Évalué à 1.

      C'est exactement ce que je pense! C#/.NET a ete presente comme le remplacant/concurrent de Java mais en realite cela ne joue pas du tout dans la meme categorie car cela n'est absolument pas multiplateforme! Cela le deviendra peut etre "grace" au travail de mono mais peut etre dans la prochaine version et encore vu que entre temps il y aura eu de nouvelles versions du framework de la part de Microsoft cela ne changera rien au probleme. Les applis interessantes (pour d'autre personnes que des devs) ne tourneront pas "out-of the box".
      • [^] # Re: .NET et portabilité GUI = 2

        Posté par . Évalué à 2.

        On parle d'un environnement de développement (langes, bibliothèques, outils), la question n'est pas de savoir s'il existe des applications intéressantes qui tournent "out of the box" sur la plupart des OS écrite avec mono (de fait il en existe, j'en ai listé une brindille), la question est de savoir si on peut les écrire, et la réponse est oui.

        De plus votre argumentation est stupide, c'est quoi une "application intéressante" ?

        Tomboy, banshee (bientôt multi-plateforme) et f-spot ne sont pas des applications "intéressantes" ?

        Paint.NET n'est pas une appli intéressante ?
        • [^] # Re: .NET et portabilité GUI = 2

          Posté par . Évalué à 1.

          Paint.Net ne tourne pas sous mono "out of the box". Vous pouvez tourner le probleme de tous les cotes cela ne changera pas le fait que actuellement mono est un joli jouet pour informaticiens mais que cela ne fait pas fonctionner les applis .NET comme le montre l'impossibilite d'avoir un exemple qui fonctionne autre que ceux developpe avec mono.

          Beaucoup d'applis java (j'ai bien dit beaucoup je n'ai pas dit la majorite ni l'ensemble) fonctionne avec des java autre que celui de SUN.
          • [^] # Re: .NET et portabilité GUI = 2

            Posté par . Évalué à 1.

            Arrêtez vos conneries. Vous vous basez sur un article qui date de 2006 pour dire cela. Aujourd'hui il reste quelque tous petits bugs, mais la compatibilité est quasi parfaite (avec mono 2.0). Et il est utilisable.
            • [^] # Re: .NET et portabilité GUI = 2

              Posté par . Évalué à 2.

              cf mon post plus haut:

              de icaza dans son commentaire d'il y a 2 mois est pas exactement du meme avis. Si c'est corrige que l'on me donne la methode pour le lancer "out of the box".
              • [^] # Re: .NET et portabilité GUI = 2

                Posté par (page perso) . Évalué à 2.

                Oui bah De Icaza précise que si Paint.NET ne tourne pas out-of-the-box sous Mono, c'est à cause de morceaux de code qui ne sont pas en .NET. Ca n'a jamais été l'objectif de Mono d'être compatible avec ca.
                • [^] # Re: .NET et portabilité GUI = 2

                  Posté par . Évalué à -2.

                  CQFD

                  On revient a "toujours pas d'exemple"!
                  • [^] # Re: .NET et portabilité GUI = 2

                    Posté par (page perso) . Évalué à 2.

                    On revient a "toujours pas d'exemple"!
                    Bah oué, toujours au même point : t'es toujours pas capable de nous montrer la fameuse "killer-app" en .NET qui marche pas sous Mono.
                    • [^] # Re: .NET et portabilité GUI = 2

                      Posté par . Évalué à 3.

                      Sur le fond tu as raison faire appel à des librairies/protocoles natif excuse Mono.
                      Mais bon c'est inquiétant qu'on ne puisse pas faire une appli grand public complètement en .NET .

                      Tu te tires pas un peu une balle dasn le pied là ?
                      • [^] # Re: .NET et portabilité GUI = 2

                        Posté par (page perso) . Évalué à 2.

                        ais bon c'est inquiétant qu'on ne puisse pas faire une appli grand public complètement en .NET .
                        Ben si on peut évidemment. Mais faut que les développeurs aient la volonté !

                        Tu te tires pas un peu une balle dasn le pied là ?
                        ? En quoi ca me concerne ?
                      • [^] # Re: .NET et portabilité GUI = 2

                        Posté par . Évalué à 3.

                        Au pire, c'est une critique à faire sur .NET ou sur les développeurs qui utilisent .NET sans se soucier d'être indépendant de la plateforme, pas sur Mono.

                        De même, ce n'est pas la faute des développeurs de JVM sous linux si certains développent des applications Java faisant des appels natifs. Ce n'est même pas un argument contre Java car il est possible de coder sans appels natifs en Java.
                        • [^] # Re: .NET et portabilité GUI = 2

                          Posté par . Évalué à 2.

                          Oui sauf qu'il existe bien des applis Java portées.
                          Est-ce que banshee sera vraiment portable en .NET si on le passe en Mono 2.0 ou faudra t'il des adaptations entre les 2 plateformes ?
                          • [^] # Re: .NET et portabilité GUI = 2

                            Posté par (page perso) . Évalué à 2.

                            Est-ce que banshee sera vraiment portable en .NET si on le passe en Mono 2.0 ou faudra t'il des adaptations entre les 2 plateformes ?
                            Oué ca me gave, j'attend Banshee sous Windows depuis un moment. Mais le code commence à être un peu trop macqué avec Gnome, bref avec du code natif...
                            • [^] # Re: .NET et portabilité GUI = 2

                              Posté par . Évalué à 2.

                              Donc je reformule ma question:

                              Peux t'on concevoir une appli grand public non Web qui ne fasse appel qu'à .NET/Mono ?
                              En existe t'il une qui provienne du monde Linux ou Windows et qui ne nécessite pas d'adaptation pour chaque plateforme, (i.e un bout de code natif pour chaque plateforme) ?
                              • [^] # Re: .NET et portabilité GUI = 2

                                Posté par . Évalué à 1.

                                Oui.

                                Si on n'avait pas honteusement moinssé l'un de mes précédents commentaires qui ne faisait que lister des applis répondant à cette question, vous auriez votre réponse.

                                Exemple :

                                http://www.integrazioneweb.com/monosim/

                                "...is a simple application that can be used to read, write, update, delete and backup your sim card contacts." => appli non web grand public

                                Dépendances :
                                * MONO Framework 1.2.4 or higher
                                * GTK# 2.8.3 or higher

                                Puis parmis les downloads :

                                Binary package only with .exe and .dll (GTK# 2.10)
                                monoSIM_v1.3.0.Linux.tar.gz
                                • [^] # Re: .NET et portabilité GUI = 2

                                  Posté par . Évalué à 3.

                                  Je n'y entends pas grand chose en C# mais peux tu me dire à quoi servent les fichiers
                                  clsWindowsPCSC.cs
                                  et
                                  clsLinuxPCSC.cs
                                  dans le tarball car ca manque de commentaire ?
                                  http://monosim.googlecode.com/files/monosim-1.3.0.1.tar.gz

                                  Serait-ce que la gestion des cartes SIM n'est pas isolée par une couche d'abstraction avec Mono/.Net ?
                                  Quoiqu'il en soit il est vrai que l'effort de portage n'apparait pas énorme mais on n'en est pas encore à out of the box pour cette appli.
                                  Pas sûr que l'on ferait mieux avec du Java.
                                  • [^] # Re: .NET et portabilité GUI = 2

                                    Posté par (page perso) . Évalué à 4.

                                    Serait-ce que la gestion des cartes SIM n'est pas isolée par une couche d'abstraction avec Mono/.Net ?
                                    Effectivement, .NET/Mono ne fourni pas de base de service pour accéder à des smart cards.

                                    Quoiqu'il en soit il est vrai que l'effort de portage n'apparait pas énorme mais on n'en est pas encore à out of the box pour cette appli.
                                    Ben en l'occurence si, je même binaire va fonctionner sous Windows et Linux sans modif aucune. C'est d'ailleur un des gros avantages de la technique P/Invoke dans .NET/Mono par rapport à une solution comme JNI.
                                  • [^] # Re: .NET et portabilité GUI = 2

                                    Posté par . Évalué à 1.

                                    Les commentaires indiquent :

                                    "/// Class to implement communication with standard PC/SC smartcard readers "

                                    Voilu.

                                    Il ne doit tout simplement pas y avoir de classe standard dans .NET ou mono gérant la communication avec les lecteurs de smartcard. Ce qui n'est pas très étonnant.

                                    Je ne sais pas si on ferait mieux avec Java. Je ne connais aucun des deux framework.

                                    Mais on ne ferait que comparer la richesse numéraire des bibliothèques standards, avec tout ce qui va avec : une bibliothèque standard doit-elle proposer une solution standard à tous les problèmes possibles ; ou doit-elle uniquement proposer des bibliothèques permettant de mettre en œuvre la création de bibliothèques et de programme bien conçus etc.

                                    Personnellement je n'en sais rien. Je ne sais pas où se situe .NET et Java sur ce point.
                              • [^] # Re: .NET et portabilité GUI = 2

                                Posté par (page perso) . Évalué à 2.

                                Y'a ca : http://www.plasticscm.com/xpfront.aspx
                                y'a aussi ca : http://www.likewisesoftware.com/
                                Pas beaucoup d'application "bureautique" pour une simple et bonne raison : portabilité et intégration oblige parfois à faire des choix. Si on veut une appli pleinement intégré dans un environnement cible, faut souvent utiliser ses spécificités et donc perdre en portabilité...
                                • [^] # Re: .NET et portabilité GUI = 2

                                  Posté par . Évalué à 2.

                                  Merci à tous les deux .

                                  Je vais jeter un coup d'oeil aux sources pour m'assurer qu'il n'y a pas un infâme hack mais je suis presque convaincu.

                                  Pour ce qui est de l'intégration je comprend bien. C'est pareil avec Java , Qt, wxWidget, ....
                  • [^] # Re: .NET et portabilité GUI = 2

                    Posté par . Évalué à 3.

                    Mais des exemples de quoi ?

                    Ça fait 15 fois que je vous explique qu'il existe des logiciels .NET qui fonctionne sous mono et inversement.

                    Vous n'en voulez pas car ils ne sont pas "populaires".

                    ET ALORS ?????
                    • [^] # Re: .NET et portabilité GUI = 2

                      Posté par (page perso) . Évalué à 0.

                      non non, j'en veux pas car on trouve mieux c'est tout

                      www.solutions-norenda.com

                    • [^] # Re: .NET et portabilité GUI = 2

                      Posté par . Évalué à 2.

                      Ça fait 15 fois que je vous explique qu'il existe des logiciels .NET qui fonctionne sous mono et inversement.

                      L'expliquer c'st bien le montrer c'est mieux, c'est tout ce que je demandais et bon il y en un seul (en dehors des trucs fait par et pour des developpeurs). Visiblement poser une question simple, poliment et serieuse cela enerve pas mal de monde (non non je ne trollais pas). J'aurais vraiment voulu essayer les deux applis que j'ai cite mais aucune des deux ne peux fonctionner, j'en connais pas d'autre qui aurait pu m'interesser sinon j'aurai demande aussi juste pour voir.
                      • [^] # Re: .NET et portabilité GUI = 2

                        Posté par (page perso) . Évalué à 2.

                        J'aurais vraiment voulu essayer les deux applis que j'ai cite mais aucune des deux ne peux fonctionner
                        Bah oui, pour des raisons qui ne concerne ni .NET, ni Mono, bref hors-sujet.

                        'en connais pas d'autre qui aurait pu m'interesser sinon j'aurai demande aussi juste pour voir.
                        Monotorrent ? Plastic SCM ? Dekiwiki ? OpenVISTA ? iFolder ? mojoPortal ?
                        Oui bah oui, y'a pas d'application de bureautique "qui tue" pour madame michu, parcque justement une application bureautique bien foutue s'intègre dans son environnement au détriment de la portabilité.
                        • [^] # Re: .NET et portabilité GUI = 2

                          Posté par . Évalué à 2.

                          Bah oui, pour des raisons qui ne concerne ni .NET, ni Mono, bref hors-sujet.

                          Oui et non. Ces deux applis sont presentes comme des applis .NET donc ce n'est pas hors sujet. Pour Paint.NET c'est ecrit nul part que cela vient de l'utilisation des trucs autre que .NET dans le message de de Icaza quand a l'autre c'est toi qui me le dis. Tu remarqueras que apres avoir eu une vrai reponse, avec une bonne justification, je n'ai pas insiste sur ses deux logiciels. La question etait une vrai question pas un troll mais il a fallu insister "legerement".

                          Monotorrent ? Plastic SCM ? Dekiwiki ? OpenVISTA ? iFolder ? mojoPortal ?

                          connais pas et sauf, peut etre plastic scm, ne repondent pas a la question car c'est du mono vers .NET

                          Enfin bon comme deja dit la question etait pour savoir si un applis lambda .NET avait une chance de s'utiliser avec mono sous linux question legitime ou efface ton paragraphe sur la compatibilite dans la news. Il semblerait que la reponse et "Oui il y a une chance mais elle est faible". Vu que le dev Mono pretendait une compatibilite a 50%, cela veut dire une applis sur 2 mais je me doutais bien que c'etait un discours marketing...
                          • [^] # Re: .NET et portabilité GUI = 2

                            Posté par (page perso) . Évalué à 4.

                            es deux applis sont presentes comme des applis .NET donc ce n'est pas hors sujet.
                            C'est écrit où qu'elles étaient intégralement en code .NET ?

                            . Pour Paint.NET c'est ecrit nul part que cela vient de l'utilisation des trucs autre que .NET dans le message de de Icaza quand a l'autre c'est toi qui me le dis.
                            Parcque tu lis en diagonales, ou que tu lis pas ce qui t'arrange pas. Tiré du blog de MDI :
                            "his Paint application despite its young age is quite sophisticated and calls into a number of Win32 libraries to use features not exposed directly by the .NET libraries."
                            sur la page de port de Paint.NET :
                            "There are a number of cases where Paint.NET is using P/Invoke"

                            ne repondent pas a la question car c'est du mono vers .NET
                            mouarf ! pourquoi du mono vers .NET ? Ce sont jsute des applis qui ont été conçues pour être portable dès la base, donc oui de tourner entre autre sous mono.

                            efface ton paragraphe sur la compatibilite dans la news.
                            Je parle de compatibilité de bibliothèques, d'outils, de langage, je parle de compatibilité pour les développeurs.

                            Vu que le dev Mono pretendait une compatibilite a 50%, cela veut dire une applis sur 2 mais je me doutais bien que c'etait un discours marketing...
                            lol ! je te cites des applis, tout ce que tu dis quand on te cite des exemples c'est : "ca compte pas", "je connais pas", "c'est pas dans le sens là", gnagnagna. La vérité c'est que tu connais pas le 1000ème des applis codés en .NET, et moi non plus, car la plupart sont des applis qui nous intéresse pas (pas notre domaine/métier). Pour les applications bureautiques, j'ai déjà expliqué le pourquoi du problème de la portabilité, problème qui est identique avec tous les autres frameworks.
          • [^] # Re: .NET et portabilité GUI = 2

            Posté par . Évalué à 7.

            t'es capable de comprendre ce que veux dire "link avec une lib native" ou ton cerveau a encore une fois bloque sur le microsoft?
            IBM serait derriere .Net tu serais en train de faire la promo de mono avec toute la mauvaise foi et les mensonges qui te caracterisent.
            oui, une ad hominem, tu l'as merite de part ton passe de trolleur ici meme.

            Nan, parce que des applis Java+JNI linkees a une lib native et donc non portable sans les sources de la lib native, j'en ai moi meme ecrites quelques unes, et ca se trouve facilement sur la toile.

            Le truc, c'est qu'en java, on evite generalement JNI autant que possible, parce que c'est casse couille et que ca colle pas trop a la philosophie du langage/plateforme.

            Un des concepts de base de .Net c'est tres precisement de pouvoir aisement mixe differents langages dans un meme projet.
            Donc, forcement, vu que .Net a ete tres majoritairement utilise par des developeurs windows pour faire des applis 100% windows et pas portables du tout, tu te retrouves avec une palanquee d'applis pas portable, car meme pas voulue portable a la base.
            Super.
            Albert vient de nous apprendre qu'une appli non portable, non voulue portable et pas pensee multi os depuis le debut est non portable.
            Merci.
    • [^] # Re: .NET et portabilité GUI = 2

      Posté par . Évalué à 1.

      C'est pas un retour de 10 ans en arrière, c'est encore la seule solution aujourd'hui pour avoir une appli qui s'intègre parfaitement dans l'environnement sur lequel elle s'exécute.
  • # Pas de Mono pour moi...

    Posté par (page perso) . Évalué à 8.

    Mon avis sur Mono est totallement idéologique : pas d'outil de développement calqué sur la propriété intellectuelle de Microsoft dans mon monde libre.

    L'attitude de Microsoft (abus de position de monopole constaté et sanctionné par les instances judiciaires américaine et européenne), qu'on a encore pu constater dans le déroulement de la procédure accélérée de certification de leur format bureautique montre qu'on ne pourra pas leur faire confiance avant bien longtemps.

    J'avais mis en pause mes développement en Java à cause du "piège Java" ( http://www.gnu.org/philosophy/java-trap.html ) et maintenant que Java est en passe de devenir complètement libre, je me suis remis à la tâche.

    Pour moi, Mono est un simple rouage d'un nouveau piège similaire au "piège Java", servant de masque au "piège .Net".

    Je n'ai aucun avis sur le mérite technique de la technologie en elle-même, car jusqu'à maintenant, j'ai eu la chance (de mon point de vue actuelle) de ne pas avoir besoin de l'utiliser. Et je dirais que je ne suis pas pressé que ça change...
    • [^] # Re: Pas de Mono pour moi...

      Posté par . Évalué à 2.

      Il y a une énorme différence entre le "piège Java" et le cas de Mono:
      - dans le cas du "piège Java", tu fais du libre reposant sur du non libre reposant sur des brevets de Sun (et autre ?)
      - dans le cas de Mono, tu fais du libre reposant sur du libre reposant sur des brevets de MS

      Pour autant que je sache, on peut utiliser Mono sur une plateforme entièrement libre. La seule objection qui tienne la route est que peut-être un jour MS va se mettre à utiliser ses brevets pour s'attaquer à Mono. Ça semble assez hypothétique, et il faut tenir compte du fait que la plupart des langages modernes tombent probablement aussi sous le coup de divers brevets logiciels.

      Il me semble, personnellement, que Mono est seulement suspect à cause du nom de Microsoft, mais qu'en réalité rien ne s'oppose à l'utilisation de la plateforme pour développer son propre logiciel libre. Ce n'est pas pour autant que je vais le faire, puisque je suis content de mon baril de Ruby, ceci dit.
      • [^] # Re: Pas de Mono pour moi...

        Posté par (page perso) . Évalué à 4.

        Rien n'indique que Sun posera des problèmes avec Java. En revanche, on a toutes les raisons de se méfier de Microsoft, vu leurs agissements passés et présents.
        • [^] # Re: Pas de Mono pour moi...

          Posté par . Évalué à 6.

          meuh non c'etait juste une blague la menace des 128 brevets viole par linux et le pourquoi des accords avec novell...
          • [^] # Re: Pas de Mono pour moi...

            Posté par . Évalué à 0.

            Parce que Linux c'est Mono ?

            Si je suis votre raisonnement. Puisque Mono est potentiellement menacé de vilation brevet par Microsoft, et que pour cette raison il est préférable de ne jamais touché à cette chose impie.

            Alors puisque Linux n'est pas potentiellement menacé de violiation de brevets, mais est menacé EN ACTE, il nous faut tous virer Linux pour y mettre Windows !
            • [^] # Re: Pas de Mono pour moi...

              Posté par . Évalué à 3.

              euh la franchement.... un des points important de l'accord c'est la "protection" (pendant 5 ans) sur mono alors si cela a un gros rapport.
            • [^] # Re: Pas de Mono pour moi...

              Posté par . Évalué à 10.

              Vous devriez arrêter de vous prendre la tête avec Albert, ça ne fera que vous énerver encore plus.
              Je crois qu'il a une dent contre Microsoft (ce qu'on ne peut lui reprocher) et ça plombe ses commentaire de mauvaise foi.

              Il n'y a qu'à voir ses « débats » avec pasBillpasGates (notamment sur OpenXML vs OpenDocument) où ce dernier défendait Microsoft avec des arguments pertinents mais qui ne faisaient pas plaisir à tout le monde. Et ça y allait à coup de sodomie de coléoptère, que suivait pourtant pBpG (je ne comprends d'ailleurs pas comment il a fait pour tenir si longtemps :-)

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

              • [^] # Re: Pas de Mono pour moi...

                Posté par . Évalué à 3.

                je crois que le plus bel exemple de mauvaise foi que j'ai vu de sa part c'etait le coup de:
                "You may not blablabla" dans une licence, ca veut dire que "tu ne peux eventuellement pas faire blablabla, mais que si tu veux le faire, tu peux quand meme".

                Cela s'appliquait evidemment aux "may not" des licences microsoft, par contre quand on lui a montre le "may not" de la gpl, la ca voulait plus du tout dire la meme chose.

                J'en rigole encore dis donc.

                (bien sur, soit il ne va pas repondre a ce commentaire, soit il va me traiter d'ad hominem, comme quoi c'est mal blablabla)
                • [^] # Re: Pas de Mono pour moi...

                  Posté par . Évalué à 2.

                  Euh non tu/vous pouvez m'attaquer je m'en moque passablement. Cela vous fait plaisir, cela doit encore plus faire plaisir au gars paye par Microsoft pour troller, mentir et fuder ici. Je suis admiratif que quelqu'uns suivent des trolls comme ceux que j'ai eu avec l'autre type car qu'est ce qu'ils sont chiant ces trolls lorsque c'est pas toi le trolleur.

                  Allez juste pour te faire plaisir:

                  Microsoft est la plus gentil boite du monde, ils ont fait le plus beau framewwork de l'histoire et ils l'on eux meme porte sur plein d'architecture differente et ont fait en sorte de pas mettre un seul brevet dessus. Et je vais me flageler avec des orties fraiches pour me punir de mon manque de foi envers sa deite billou!

                  Content?
                  • [^] # Re: Pas de Mono pour moi...

                    Posté par . Évalué à 3.

                    car qu'est ce qu'ils sont chiant ces trolls lorsque c'est pas toi le trolleur.

                    non non, au contraire c'est vachement rigolo de te voir t'enliser et te faire coincer par pbpg.
                    Genre le coup du may not, qu'est ce que ca m'avais fait marrer...

                    J'adore voire tes contradictions et tes arguments telephones.

                    Genre le dernier en date: MS c'est des cons, ils devraient laisser promouvoir ODF et participer a l'elaboration de la spec.
                    Pis le jour ou ms ajoute un filtre d'export natif ODF et rentre dans le comite d'elaboration d'ODF, c'est des pourris qui veulent miner ODF.

                    Y a t il ne serait ce qu'une chose que ms peut faire sans que tu ne crache ta bile sur leurs actions?
                    Steve ballmer peut il aller pisser sans que tu l'insultes pour polluer les egouts?
                    • [^] # Re: Pas de Mono pour moi...

                      Posté par . Évalué à 1.

                      Ah ah encore un rigolo qiu pretend que j'insulte tout le monde. Comme deja dit lors de ce genre d'affirmation montre donc moi un endroit ou j'insulte et cela de facon totalement gratuite et sans m'en avoir pris plein la tete auparavant.

                      Allez je te laisse a ton (mauvais) trip. J'ai eu ma reponse a la question que j'ai poliment pose et qui me semble on ne peut plus legitime vu le sujet de la news.
                      • [^] # Re: Pas de Mono pour moi...

                        Posté par (page perso) . Évalué à 1.

                        'ai eu ma reponse a la question que j'ai poliment pose et qui me semble on ne peut plus legitime vu le sujet de la news.
                        Bof, ta question, c'est ton délire. Dans la news je n'ai nullement venté un truc "ala" Wine. Quand j'ai parlé compatibilité, j'ai parlé bibliothèques, outils, bref, la compatibilité est là pour les développeurs. Y'a pas encore beaucoup d'applis portables ? ben justement, il faut sensibiliser les développeurs windows à la portabilité, mono est un moyen comme un autre.
            • [^] # Re: Pas de Mono pour moi...

              Posté par . Évalué à 1.

              «Si je suis votre raisonnement. Puisque Mono est potentiellement menacé de vilation brevet par Microsoft, et que pour cette raison il est préférable de ne jamais touché à cette chose impie.

              Alors puisque Linux n'est pas potentiellement menacé de violiation de brevets, mais est menacé EN ACTE, il nous faut tous virer Linux pour y mettre Windows !»

              C'est dans ces moments que je regrette l'impossibilité d'éditer ses commentaires...

              Je corrige :

              """ Si votre raisonnement est exact, puisque Mono est potentiellement menacé par Microsoft pour cause de violation de brevet, et qu'il faut pour cette raison s'interdire de l'utiliser ; alors, Linux, ACTUELLEMENT menacé (menacé en acte et on en puissance) pour la même raison par la même entreprise, doit être en toute logique et en toute urgence supprimé de nos machines."""
          • [^] # Re: Pas de Mono pour moi...

            Posté par . Évalué à 2.

            Microsoft a bien plus intérêt à tuer Linux qu'à tuer Mono, qui augmente l'intérêt de .NET en tentant de rendre ses applications portables. Les éventuels brevets que MS possède violés par Linux sont-ils un argument pour ne pas utiliser Linux ?
            • [^] # Re: Pas de Mono pour moi...

              Posté par . Évalué à 2.

              Le fait est que dans le cas de linux, lorsqu'il a été demandé à Microsoft de fournir la liste des brevets supposés violés, ce dernier a préféré continuer à gueuler et à menacer comme si de rien n'était, ce qui tend à indiquer que son histoire ne tient pas sur des bases très solides (le risque est grand de voir des universités se lancer dans un concours d'invalidation de brevets dès que la liste serait disponible), mais ça a suffi à faire peur à quelques entreprises qui ont demandé à Microsoft la permission de continuer à distribuer du linux...

              Pour .Net, Microsoft a pour le moment besoin de se faire des parts de marché, quitte à déborder sur le monde libre. Toutefois, Microsoft ne s'implique pas dans le développement de Mono ni ne donne une autorisation explicite à tous d'utiliser les technologies non-ecma. Une fois .Net adopté massivement, Microsoft pourrait faire valoir ses droits et exiger le retrait de technologies dont les applications p

              Microsoft garde son fusil chargé et se réserve le droit de tirer quand bon lui semble, c'est suffisant pour se méfier de ses intention. Si par contre il déposait les armes, on pourrait avancer plus sereinement avec mono.
              • [^] # Re: Pas de Mono pour moi...

                Posté par (page perso) . Évalué à 2.

                Microsoft ne s'implique pas dans le développement de Mono
                Bah si, ils leurs filent même du code, même sous licence libre et approuvé par la FSF. Tu dis n'importe quoi pourvu que ca serve tes propos.

                ni ne donne une autorisation explicite à tous d'utiliser les technologies non-ecma.
                On est sur LinuxFR non ? c'est aussi la stack d'API mono pour linux qui devraient nous intéressons non ? quel est le rapport avec .NET ou Microsoft ?

                Une fois .Net adopté massivement, Microsoft pourrait faire valoir ses droits et exiger le retrait de technologies dont les applications p

                oué et Novell va se laisser faire ? c'est des bisounours ? faut-il rappeler qu'ils ont aussi un portefeuille de brevets, entre autre sur .NET (ironie du sort n'est-ce pas)
                Faut-il encore le rappeler que tarlouzes comme Novell, IBM, NEC, Philips, Red Hat et Sony se sont alliés en fournissant chaque leurs armes (brevets) pour protéger des logiciels libres comme Linux ou Mono ?
                http://www.openinventionnetwork.com/

                Si par contre il déposait les armes, on pourrait avancer plus sereinement avec mono.
                avec Linux.
                • [^] # Re: Pas de Mono pour moi...

                  Posté par . Évalué à 2.

                  Faut-il encore le rappeler que tarlouzes comme Novell, IBM, NEC, Philips, Red Hat et Sony se sont alliés en fournissant chaque leurs armes (brevets) pour protéger des logiciels libres comme Linux ou Mono ?

                  Oui, c'est toujours intéressant à rappeler, je pense même que c'est un élément majeur à mettre en avant qui permettrait de montrer qu'il y a effectivement une forme d'assurance sur Mono dépassant potentiellement le cadre de l'accord de Novell ou de l'ECMA...
      • [^] # Re: Pas de Mono pour moi...

        Posté par . Évalué à 2.

        - dans le cas du "piège Java", tu fais du libre reposant sur du non libre reposant sur des brevets de Sun (et autre ?)

        Java passe en GPL.

        http://www.sun.com/2006-1113/feature/story.jsp
        • [^] # Re: Pas de Mono pour moi...

          Posté par . Évalué à 2.

          L'implémentation de Sun est passée en GPL il y a déjà un moment. Ca a d'abord commencé par Java 7 pour ensuite fournir Java 6. D'ailleurs OpenJDK 6 a récemment passé le TCK ce qui en fait une implémentation de Java (c'est un peu comme pour firefox, si ca passe pas le TCK tu ne peux pas utiliser officiellement le nom Java).

          Les implémentations d'IBM et de BEA restent toujours aussi proprios.
      • [^] # Re: Pas de Mono pour moi...

        Posté par . Évalué à 4.

        Non la java trap c'était que la communauté du logiciel libre n'a jamais été foutue de se sortir les doigts du cul pour faire une implémentation qui passe le TCK.

        Le fonctionement du JCP n'a pas été modifié depuis que Sun à libéré son implémentation. Les règles sont restées les mêmes. D'ailleurs il était possible de faire des implémentations alternatives puisque IBM et BEA l'ont fait. Il aurait tout à fait été possible de faire une implémentation libre.

        Le problème c'est que gcj / classpath n'avait pas du tout le man power suffisant pour y arriver. Alors on préfère crier au loup. La seule chose qui a changé depuis l'époque ou tout le monde disait que Java c'était de la merde ici, c'est que Sun a donné son code source en GPL...
        • [^] # Re: Pas de Mono pour moi...

          Posté par . Évalué à 2.

          Les raisons pour lesquelles la plateforme n'était pas libre ne changent pas le fait que la plateforme n'était pas libre. On peut accuser qui on veut d'avoir été un gros fainéant, l'argumentation reste la même: on peut faire du logiciel libre reposant sur une plateforme non-libre, mais c'est problématique.

          Après, mettre ça sur le dos de la fainéantise des développeurs du libre, pourquoi pas. C'est valable pour tout ce qui n'est pas libre, pratique. « Ah vous gueulez parce que X n'est pas libre ? Vous n'avez qu'à en coder un libre ! » C'est pas faux, ça fait pas avancer le schmilblick, mais je suppose que ça défoule.
        • [^] # Re: Pas de Mono pour moi...

          Posté par (page perso) . Évalué à 4.

          "Non la java trap c'était que la communauté du logiciel libre n'a jamais été foutue de se sortir les doigts du cul pour faire une implémentation qui passe le TCK."

          Pas forcément une histoire de flemme : pour s'assurer de développer sans problème de propriété intellectuelle, il fallait ne pas avoir regardé les sources de chez Sun. Or, le jdk embarquait le code source de Swing. A partir du moment ou on avait regardé ce source, "pour voir comment ça marche", on ne pouvait plus participer au développement des réimplémentation libre de ses classes. Et donc, moi je n'ai pas pu participer...
  • # Portabilité !

    Posté par . Évalué à 4.

    Je vois beaucoup parler de portabilité dans cette dépêche, et donc, Mono/C# est comparé à Java. Mais java n'est pas pour moi un exemple de portabilité. Java ne tourne pas sur la majorité des architectures ou OS existant. Certe, la JVM tourne sur les plus importants d'entre eux, mais bon... Donc prendre java comme exemple de portabilité, ça m'embête,car on peut dire pareil de Flash dans ce cas.
    • [^] # Re: Portabilité !

      Posté par . Évalué à 2.

      Reconnaissons que l'ouverture du code source de Java aide à son déploiement sur des architectures et des OS "minoritaires". Ça devrait donc largement s'arranger.
    • [^] # Re: Portabilité !

      Posté par . Évalué à 2.

      Je pense que le debat ne porte pas sur le nombre de plateforme supportées mais sur la portabilité à moindre coût c'est a dire sans code spécifique.
      "C" est peut-être le plus portable mais à cout de directive #ifdef WIN32, #ifdef POSIX ca devient vite lassant.
  • # "le singe continue ses grimaces"

    Posté par . Évalué à 7.

    On parle de Steve Ballmer ?

    ====>[]
  • # Intérèt de mono et .Net

    Posté par . Évalué à 4.

    J'ai un peu de mal à comprendre…

    .Net c'est la plateforme de développement de MS pour son windows.
    Mono c'est .Net mais sous linux.

    Mais d'après les commentaires plus haut les appli .Net pour windows ne sont pas directement portable sous mono.

    D'où mon incompréhension :
    À quoi sert mono ?
    .Net semble être profondément attaché à windows, quel intérèt de le porter sous linux si c'est pour ne pas avoir une compatibilité direct avec le vrai .Net ?
    • [^] # Re: Intérèt de mono et .Net

      Posté par . Évalué à 2.

      Je me demande pourquoi tant d'efforts pour porter une plateforme d'un éditeur qui a fait tant de mal au libre.

      Pourquoi ne pas plutôt adapter LINQ pour Java? (C'est la seule fonctionnalité qui me semble vraiment manquer).
      • [^] # Re: Intérèt de mono et .Net

        Posté par . Évalué à 2.

        Ca c'est bien la question que je me pose. La seule raison que j'aurai trouve valable c'est de faire fonctionner des applis windows sur linux un peu comme wine mais pour celle de nouvelle generation et de facon un peu plus native mais non apres 6 ans de developpement ce n'est toujours pas possible et a peu pres aucune applications sortant du .NET windows peut tourner sous linux. Il semblerait que il y en ait tout de meme une (en dehors des trucs pour developpeurs) qu existe ce qui est legerement aberrant car j'ai du mal a croire que en 6 ans d'existence les seuls logiciels existant sur la plateforme .NET soit presque uniquement fait pour developper sur cette plateforme...
      • [^] # Re: Intérèt de mono et .Net

        Posté par . Évalué à 2.

        Par ce que LINQ fait parti du langage C#, ce n'est pas une bibliothèque.

        Cela veut dire que si tu veux ajouter Linq à Java, il faut modifier le langage. Ca va prendre un bon moment, pas avant Java 8. Il faut faire une JSR, qu'il y ait concensus, que tu sois en stade final et surtout que ta JSR soit acceptée pour rentrer dans Java. L'avantage qu'à Microsoft sur Sun c'est qu'ils sont seuls au monde, ca va plus vite quand on peut décider unilatéralement. Ca veut aussi dire qu'OpenJDK peut faire une implémentation de Linq (comme ils le font actuellement pour les closures) mais ca ne sera jamais dans une release puisque dans ce cas ce n'est plus Java.

        Un mouvement est d'ailleurs en train de s'opérer dans la communauté Java, c'est l'apparition de nouveaux langages sur la JVM: Jython, JRuby, Scala etc.

        Puisque Java est un mastodonte qu'il est difficile de changer (Sun essaye de garder le langage stable), on retrouve la souplesse par l'ajout de nouveaux langages. Comme tout tourne sur la JVM on peut facilement utiliser les libs d'un langage dans un autre. Tout comme en .Net via le CLR.

        Cela on retrouve en Java des équivalents à LINQ pour la partie XML (type XMLBean) pour la partie DB, la plupart des applis Java reposent sur hibernate, ce qui limite un peu la manipulation de requètes SQL. Et pour la partie collection de données il n'y a rien.
        • [^] # Re: Intérèt de mono et .Net

          Posté par (page perso) . Évalué à 2.

          Par ce que LINQ fait parti du langage C#, ce n'est pas une bibliothèque.
          Nan LINQ est une bibliothèque. Tu peux l'utiliser en C# 2 qui n'a pas la syntaxe C# 3.

          Puisque Java est un mastodonte qu'il est difficile de changer (Sun essaye de garder le langage stable).
          Oué enfin Sun sait aussi se bouger le cul quand y'a de la concurrence : foreach, attributs de méta-données, autoboxing, etc.

          Tout comme en .Net via le CLR.
          Sauf que y'en a un qui est conçu pour avec des normes bien définies et standardisées

          a plupart des applis Java reposent sur hibernate, ce qui limite un peu la manipulation de requètes SQL.
          oué mais hibernate c'est pas là panacée : LINQ permet d'avoir une compilation "statique" avec tous les avantages qui vont avec. D'ailleur pour .NET y'a un connecteur LINQtoNHibernate qui montre bien que les 2 ne résolvent pas les mêmes problèmes.
          • [^] # Re: Intérèt de mono et .Net

            Posté par . Évalué à 2.

            > Nan LINQ est une bibliothèque. Tu peux l'utiliser en C# 2 qui n'a pas la syntaxe C# 3.

            Bon point j'avais pas noté

            > Oué enfin Sun sait aussi se bouger le cul quand y'a de la concurrence

            Sun a su se bouger le cul. Depuis Java 5 ils traînent des deux pieds pour tout casser à nouveau. C'était clairement visible à JavaOne cette année. C'est même Sun qui pousse à développer de nouveaux langages sur la JVM (track dédié à JavaOne, leurs blogs, l'ajout d'invoke dynamic à la JVM etc.)

            Si tu regardes les updates prévus pour Java 7, http://tech.puredanger.com/2008/08/02/java7-prediction-updat(...) , il n'y a pas de d'énorme nouveauté. Je ne dis pas que ca n'arrivera pas mais ca ne me semble pas dans l'air du temps.

            > Sauf que y'en a un qui est conçu pour avec des normes bien définies et standardisées

            A la base le CLR a effectivement été conçu pour ça contrairement à la JVM (l'un était multi langage mono plateforme, l'autre mono langage multi plateforme). Maintenant la JVM est standardisée http://java.sun.com/docs/books/jvms/ mais je ne sais pas à quel point la spec aide ou rend difficile le multi langage. Ce n'est pas mon domaine. Le cas de Scala me fait dire que ca sent pas trop mauvais tout de même.

            > oué mais hibernate c'est pas là panacée

            Je disais clairement qu'on aimerait bien un LINQ en Java. C'était justement pour montrer qu'on avait que des rustines qui rendait la vie un peu plus facile.
            • [^] # Re: Intérèt de mono et .Net

              Posté par (page perso) . Évalué à 1.

              l'un était multi langage mono plateforme, l'autre mono langage multi plateforme)
              J'insiste, mais .NET a été conçu dès la base pour être multi-plateforme (WindowsCE/WindowsMobile/Windows/XBox/carte à puces) et même sous Unix (MS a proposé une implémentation du coeur de la plateforme pour unix/macosx).

              Maintenant la JVM est standardisée
              La JVM n'a pas bougé d'un iota pour autant. Ce qu'il manque ce sont des spécifications qui définissent clairement les règles que doivent respecter tel ou tels langages pour se conformer au modèle de machine virtuel où son code va s'exécuter. Ceci afin de garantir que les langages utilisent les mêmes règles pour produire leur code et décrivent leurs types de la même manière afin de garantir l'interopérabilité entre les composants produits et leurs utilisations dans un autre langage.

              C'est même Sun qui pousse à développer de nouveaux langages sur la JVM
              Bah oui faut suivre la concurrence :) Et la concurrence a (à mon avis) encore un train d'avance avec le DLR (dynamic language runtime) qui est aux langages dynamiques (Python, Ruby et autre JavaScript) ce qu'est le CLR aux langages statiques : un modèle "générique" permettant de concevoir de nouveaux langages dynamiques interopérables et sans réinventer la roue.
              • [^] # Re: Intérèt de mono et .Net

                Posté par . Évalué à 0.

                Et la concurrence a (à mon avis) encore un train d'avance avec le DLR (dynamic language runtime)

                A l'heure de l'inférence de type, ça sert à quoi un langage dynamique?
                • [^] # Re: Intérèt de mono et .Net

                  Posté par (page perso) . Évalué à 2.

                  ben faut croire que y'en a qui préfère les applications qui pète chez le client plutôt qu'à la compil dans leur IDE ;)
                • [^] # Re: Intérèt de mono et .Net

                  Posté par . Évalué à 2.

                  A ouvrir des concepts sympas comme l'introspection et l'intercession.

                  Par exemple le monkey patching ( en:Monkey_patch ) en ruby.
                  Beaucoup dirons que c'est casse geule mais c'est ce qui rend RoR si agréable avec des bouts de code du genre :

                  >> Time.now + 1.hour + 5.minutes
                  => Sat Oct 11 01:10:58 +0200 2008

                  >> 2.times do
                  ?> print "toto\n"
                  >> end
                  toto
                  toto
                  => 2

                  >> 'person'.pluralize
                  => "people"


                  Fin bref des trucs bien plus sexy AHMA qu'un embryon de SQL dans le langage.

                  Je pourrait aussi parler des méthodes magiques du type Model.find_by_xxx_and_xxx
                  • [^] # Re: Intérèt de mono et .Net

                    Posté par (page perso) . Évalué à 2.

                    En C# 3 j'obtiens la même chose avec ca :
                    2.times(()=>print("toto"));
                    print("person".pluralize());
                    • [^] # Re: Intérèt de mono et .Net

                      Posté par . Évalué à 1.

                      Chez moi ces lignes ne fonctionnent pas...

                      Je viens juste d'essayer sur un Visual Studio 2008 sur le poste de mon voisin...
                      • [^] # Re: Intérèt de mono et .Net

                        Posté par (page perso) . Évalué à 2.

                        C'est parcque je n'ai pas mis la définition des méthodes. Voici le code complet qui tourne dans Visual Studio 2008 :

                        using System;
                        using System.IO;

                        public static class LinuxFrTrollExtensions
                        {
                        public static void times(this int nb, Action action)
                        {
                        for (int i = 0; i < nb; i++)
                        action();
                        }

                        public static string pluralize(this string text)
                        {
                        return "people";//devrait parcourir un dictionnaire ici
                        }

                        public static TimeSpan hour(this int h)
                        {
                        return TimeSpan.FromHours(h);
                        }

                        public static TimeSpan minutes(this int m)
                        {
                        return TimeSpan.FromMinutes(m);
                        }

                        }

                        class Program
                        {
                        static void print(object o)
                        {
                        Console.WriteLine(o);
                        }

                        static void Main(string[] args)
                        {
                        2.times(() => print("toto"));
                        print("person".pluralize());
                        print(DateTime.Now + 1.hour() + 5.minutes());
                        Console.ReadLine();
                        }
                        }
                        • [^] # Re: Intérèt de mono et .Net

                          Posté par . Évalué à 1.

                          Ton exemple n'agit que sur une portée locale.

                          Le monkey patching lui est global. Menfin ....
                          • [^] # Re: Intérèt de mono et .Net

                            Posté par (page perso) . Évalué à 3.

                            ?
                            si ma classe d'extensions est dans un namespace "Extensions", celles-ci seront accessibles de "partout" où l'on met la directive "using Extensions;"
                            D'ailleur tout le framework LINQ qui est accessible de "partout" est entièrement codé en méthodes d'extensions de ce style.
                            Ou alors j'ai pas bien compris ta remarque.
                            • [^] # Re: Intérèt de mono et .Net

                              Posté par . Évalué à 1.

                              Et bien ton code ne modifiera le comportement de ta classe que dans les "parties" qui le demande explicitement.

                              En ruby si tu fait :

                              1.class.send :define_method, :to_s do
                              return "foo"
                              end


                              une fois ce code exécuté la classe Fixnum elle même est modifié et tout les appels a Fixnum.to_s sans aucune exception renverront la chaîne "foo".

                              Je te l'accorde l'exemple que j'ai donné est sans intérêt. Mais ça ouvre pas mal de possibilités sympa notamment du fait que la modification n'est active qu'au moment ou le code est exécuté ce qui permet d'activer/désactiver des méthodes par moment etc.
                              • [^] # Re: Intérèt de mono et .Net

                                Posté par (page perso) . Évalué à 3.

                                euh, c'est juste parcque j'ai fais le choix de mettre mes extensions dans un namespace, si je les mets hors d'un namespace ce sera accessible depuis n'importe où dans mon programme...
                  • [^] # Re: Intérèt de mono et .Net

                    Posté par (page perso) . Évalué à 2.

                    J'avais oublié la première ligne, en C# ca donne :
                    DateTime.Now + 1.hour() + 5.minutes()
                    Pas besoin de langage dynamique pour ca !
        • [^] # Re: Intérèt de mono et .Net

          Posté par . Évalué à 2.

          Cela veut dire que si tu veux ajouter Linq à Java, il faut modifier le langage.

          Ou pas!

          http://www.theserverside.com/news/thread.tss?thread_id=46887
          • [^] # Re: Intérèt de mono et .Net

            Posté par (page perso) . Évalué à 2.

            il y a même un moyen d'y arriver autrement... en utilisant Mono : Mainsoft est spécialisé dans le déploiement d'applications .NET sur plateforme JEE en convertissant le bytecode des libs de Mono en bytecode Java... Je me demande ce que donnerait le résultat en appliquant le même principe sur l'implémentation de LINQ par Mono...
          • [^] # Re: Intérèt de mono et .Net

            Posté par . Évalué à 2.

            Je pensais à LINQ tel que dans C# 3, effectivement comme lib c'est possible.

            Cela dit Quaere c'est plutôt bien mort. Rien depuis fin 2007. J'avais regardé les projets qui pouvaient s'apparenter à LINQ en Java il y a quelques temps et rien n'était vraiment ressorti d'un lot des protos en 1 mois.
    • [^] # Re: Intérèt de mono et .Net

      Posté par (page perso) . Évalué à 2.

      Mais d'après les commentaires plus haut les appli .Net pour windows ne sont pas directement portable sous mono.
      Si elles le sont. Le problème c'est qu'il existe peu d'application écrites uniquement en .NET sous Windows (parcque c'est un des avantages de NET de permettre une intégration aisée avec l'existant).

      À quoi sert mono ?
      Ben Mono c'est aussi une plateforme complète de développement pour Linux, notamment Gnome.

      quel intérèt de le porter sous linux si c'est pour ne pas avoir une compatibilité direct avec le vrai .Net ?
      Mono c'est aussi l'implémentation d'une techno standardisée multi-plateforme et multi-languages, agréable à utiliser pour les développeurs et qui a les mêmes avantages sous Linux que .NET sous Windows : l'intégration avec l'existant.
      C'est aussi une facon d'attirer sous Linux des développeurs "windowziens" habitués au C# ou au VB. Et y'en a beaucoup plus que d'adeptes de Python ou Ruby.
  • # linux reste sectaire a ce que je vois...

    Posté par . Évalué à -3.

    tout ca prouve a quel point certain reste sectaire...
    Ca me rappelle un collègue qui adore le cobol sous AS400 et ne comprends pas l'interet des nouveaux languages.... ou encore les adepte de la console qui ne comprenne pas l'interet d'un gui car ca va moins vite a utilisé quand tu connais bien.

    Bref, mono n'est pas la uniquement pour le coté cross plateform mais est surtout la pour fournir une plateforme complete de developpement ou on a pas a reinventé la roue. Donc le C/cpp oublie. Y a qu'a compter le nombre de lib qui font la même chose en C. On est sans arret entrain de réinventé la roue car il n'y a pas de framework.

    Le GC permet de ne pas avoir a gérer la mémoire donc plus de memory leak ....

    Concernant le java, c'est lent, ca oblige a avoir un server IBM en entreprise. En plus coté language, le java = le C# - foreach, - lambda - delegate - les generics ... bref c'est juste qu'on a plus de code a écrir pour faire la meme chose donc moins lisisble donc moins maintenable.

    Vous voulez une appli utilisable par tout le monde ... monotorrent marche sur les 2.
    maintenant, vu la mauvaise fois, on va surement me dire que ca compte pas...

    L'avantage de mono est que c'est cross langage donc on peut coder dans le language que l'on veut.
    Il y a déjà pas mal de language de supporté...

    Pour ce qui est des performances, certain code écris en C# sont meme plus rapide que du C.
    Et puis si on veut joué au con, coté perf arretons le Cpp et vive l'assembleur.
    • [^] # Re: linux reste sectaire a ce que je vois...

      Posté par (page perso) . Évalué à 3.

      > Pour ce qui est des performances, certain code écris en C# sont meme plus rapide que du C.

      ouuéééé supper , d'habitude c'est les javaistes qui la sortent celle-là. Le super compilo JIT 3-en-un qui compile et optimise de plus en plus ton code à chaque qu'il repasse dans la même portion, un peu comme un rasoir à 42 lames

      Avant de faire des compilos qui soit-disant vont plus vite que le C, faudrait déjà faire en sorte que les programmes generés demarrent rapidement et ne bouffent pas des tétrachiées de mémoire
  • # Mon experience .Net

    Posté par . Évalué à 9.

    A la recherche d'un logiciel métier spécifique, je contacte un petit éditeur français d'une solution serveur intéressante développée en .Net . Discussion classique sur le produit puis:

    Moi> le problème, c'est que votre solution tourne uniquement sous windows et mes serveurs sont en linux. Ca m'ennuie.
    Lui> Pas de problème. Avec Linux Il y a mono.
    Moi> (naif) Ah oui c'est vrai...

    1 semaine plus tard :

    Moi> (vicieux) Ok pour tester votre solution mais sous linux
    Lui> Ah oui, euh, euh... c'est à dire que ... on va certifier la prochaine version, mais actuellement c'est pas le cas. Vous voulez pas essayer en windows?

    Finalement, j'ai acheté le produit parce qu'il m'intéressait et j'ai installé un serveur windows (bouh!!!) . Depuis on a essuyé quelques platres et particulièrement des problèmes de perfs. (pas directement liés à .Net). Discussion avec un des développeurs de la société éditrice :

    Lui> il faudrait upgrader la version de la librairie AJAX utilisée avec .Net car il y a des bugs et des fuites mémoire. Mais le directeur a les boules car la société créatrice de la librairie en question a augmenté ses tarifs par 3. Et puis, y a pas longtemps on a racheté 10 licences visual studio et c'est pas franchement donné.

    Moralité :

    1. les grosses applis développées .net ne tournent pas sous mono
    2. Mono est utilisé comme argument marketing pour vendre des produits microsoft.
    3. L'écosystème .Net est majoritairement closed source et payant

    Ma question : les développeurs de mono ont-ils conscience de se faire manipuler par Microsoft ?
    • [^] # Re: Mon experience .Net

      Posté par (page perso) . Évalué à 2.

      les grosses applis développées .net ne tournent pas sous mono
      Elle est entièrement en .NET ? quelle appli est-ce ?

      L'écosystème .Net est majoritairement closed source et payant
      Sans doute plus que Java, mais il y a beaucoup de projets open-source pour .NET, en tout cas d'un point de vue développeur.

      les développeurs de mono ont-ils conscience de se faire manipuler par Microsoft ?
      Genre c'était un commercial Microsoft ?
    • [^] # Re: Mon experience .Net

      Posté par . Évalué à 2.

      c'est effectivement ce qui me gène le plus dans mono, c'est certes un language ECMA mais étant donné qu'il est poussé par MS dont la philosophie ne se rapproche pas du logiciel libre, on peut douter de son impartialité.

      Aprés, c'est un language trés agréable, et les outils (visual studio, sharpdevelop) sont trés bien ficelés (ce qui contribue énormement à le rendre trés agréable :p ).

      Il n'en reste pas moins que - même si Mono se defend de courrir aprés Microsoft - ca ressemble à une copie, et d'un certain point de vue, c'est un frein à l'innovation.
      • [^] # Re: Mon experience .Net

        Posté par . Évalué à 1.

        Comme ça a été dit, Mono n'est pas qu'une copie puisqu'il propose ses librairies natives, comme GTK#, Cairo, etc. Il y a même des bindings vers Glib, Gecko, Evolution, Dbus, Webkit, et bien d'autres.

        C'est une vraie technologie écrite pour le bureau Linux (enfin surtout GNOME, mais bon...), pas seulement un port d'une techno existante.

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

  • # déçu

    Posté par (page perso) . Évalué à 2.

    pfff 270 commentaires et pas un couillon pour s'apercevoir que mon bout de code C# 3 se trouve pas :(
    • [^] # Re: déçu

      Posté par . Évalué à 3.

      ca prouve a quel point tout le monde s'en fout de C# et mono :)
      • [^] # Re: déçu

        Posté par (page perso) . Évalué à 3.

        de quoi les 270 commentaires ? :-p
        • [^] # Re: déçu

          Posté par . Évalué à 2.

          Si le Troll n'était pas déjà utilisé.

          Je pense que çà aurait été l'animal de prédilection pour la mascotte de Mono.

          Qui sait dans 20 ans, on verra peut être une évolution de la sémantique où on ne parlera plus de "troll" mais de "singe".
  • # priviliégié

    Posté par (page perso) . Évalué à -4.

    est-ce qu'il y a vraiment des gens qui vont utiliser ça au lieu d'une version natif d'un soft sous linux?

    mis à par les vendu à ms?

    www.solutions-norenda.com

  • # Portable executable win32

    Posté par (page perso) . Évalué à 3.

    Est-ce que les applications Mono ont toujours pour identifiant magique celui des portable executables win32 ? C'est le genre de truc qui montre que .NET n'a pas vraiment été conçu pour être multiplate-forme, et qui oblige à des kludges pour détecter s'il faut lancer tel programme avec Wine ou avec Mono…
    • [^] # Re: Portable executable win32

      Posté par (page perso) . Évalué à 3.

      tu troll sur le "conteneur" de l'exécutable qui contient effectivement une signature permettant à Windows de reconnaître un assembly .NET comme un exécutable.
      Ca ne rend pas le format du bytecode (le contenu) moins portable, quoique t'en dise.
      Un fichier Java a également une signature qui lui es propre et personne n'en fait un pataques.

      qui oblige à des kludges pour détecter s'il faut lancer tel programme avec Wine ou avec Mono…
      oué bah oué, comme sous Linux si tu veux pouvoir lancer automatiquement n'importe quel fichier : faut détecter son format puis choisir le bon exécutable, rien de neuf.
      Windows fait le même boulot pour savoir si c'est un exécutable "natif" ou s'il doit appeler le runtime .NET.
      • [^] # Re: Portable executable win32

        Posté par (page perso) . Évalué à 4.

        Un fichier Java a également une signature qui lui es propre et personne n'en fait un pataques.

        Oui, Java a été bien pensé, pour être reconnaissable partout : il a sa signature propre. .NET, non, il a la signature d'un exécutable Windows, et il faut aller chercher plus loin pour voir qu'il s'agit en fait de .NET.

        oué bah oué, comme sous Linux si tu veux pouvoir lancer automatiquement n'importe quel fichier : faut détecter son format puis choisir le bon exécutable, rien de neuf.

        Oui, je crois que les octets magiques sont fait pour ça. Problème : ceux des exécutables .NET les identifient comme Portable executable win32. Ce qu'ils ne sont pas.
        • [^] # Re: Portable executable win32

          Posté par (page perso) . Évalué à 4.

          il faut aller chercher plus loin pour voir qu'il s'agit en fait de .NET.
          trop dur ! faut lire quelques octets en plus ! Mon dieu !
          Et les fichiers OOo qui sont des zip ? Pareil faut aller lire plus loin ! Les scripts python ? des fichiers textes ! t'imagine ? Scandaleux !
          T'en à d'autres des arguments pourris comme ca ?

          Y'a aucun format d'exécutable natif portable d'un OS à l'autre.
          • [^] # Re: Portable executable win32

            Posté par (page perso) . Évalué à 3.

            Les fichiers OOo qui sont des Zip : au moins, ce format ne fait pas de référence trop spécifique. Pour que la comparaison soit valable, il faudrait que les fichiers OOo aient le même identifiant que ceux Microsoft Office mais ne soient pas lisibles en tant que fichier Microsoft Office, par exemple.

            Les scripts Pythons : #! /usr/bin/python.

            Y'a aucun format d'exécutable natif portable d'un OS à l'autre.

            Effectivement. Mais ici, il ne s'agit pas d'exécutable natif, mais de bytecode pour machine virtuelle, tout à fait portable, ou sensé l'être, en tout cas. Or leur identification fait référence à une plate-forme tout à fait spécifique, ce qui est pour moi un défaut de conception basique. Pas énorme, mais qui remonte au tout début de la conception et mériterait d'être corrigé.
            • [^] # Re: Portable executable win32

              Posté par (page perso) . Évalué à 1.

              Je viens de trouver une formulation plus simple.

              Quand je trouve un exécutable ELF x86-64 64 bits pour GNU/Linux, je m'attends à pouvoir l'exécuter depuis le chargeur de Debian GNU/Linux AMD64.

              Quand je trouve un exécutable qui est une archive Zip, je regarde un peu plus loin, et si je vois que c'est un JAR, j'essaie de le lancer avec Java.

              Quand je trouve un exécutable PE x86-32 pour Windows, je m'attends à pouvoir l'exécuter depuis le chargeur de Windows XP x86 32 bits, et à avoir une chance de pouvoir l'exécuter depuis le chargeur de Wine.

              Et bien là, non, c'est de la tromperie : c'est signé comme un exécutable PE x86-32 pour Windows, mais ce n'en est pas un. En particulier, je n'ai pas la moindre chance de pouvoir l'exécuter avec Wine, et ce n'est pas la faute de Wine.
              • [^] # Re: Portable executable win32

                Posté par (page perso) . Évalué à 3.

                Et bien là, non, c'est de la tromperie : c'est signé comme un exécutable PE x86-32 pour Windows, mais ce n'en est pas un.

                Bien sur que si c'en est un. C'est un exécutable PE32 ou PE32+ tout ce qu'il y a de plus normal, avec une caractéristique particulière, il a un header un champ spécial COM2+ (le pre pre pre nom de .net).

                Et tu pourrais très bien le lancer dans Wine en théorie. Dans le cas où le loader ne reconnaît pas directement l'exécutable comme contenant du code .net (comme celui de Win2000), il y a un bout de code natif qui jump vers une librairie native du Framework .net, déclenchant le lancement de la CLR, et l'exécution du code managé.

                Donc Wine peut très bien consommer un tel fichier, mais devrait sûrement se plaindre de la non existence de cette librairie particulière.

                Donc si on prends ton exemple:

                Quand je trouve un exécutable qui est une archive Zip, je regarde un peu plus loin, et si je vois que c'est un JAR, j'essaie de le lancer avec Java.

                On peut le transformer en:

                Quand je trouve un exécutable qui est un fichier PE, je regarde un peu plus loin, et si je vois que c'est un PE avec un header pour du code managé, j'essaie de le lancer avec Mono.

                Dingue, ça marche.
                • [^] # Re: Portable executable win32

                  Posté par (page perso) . Évalué à 1.

                  Bon, soit. Mais dans ce cas, on ne peut pas dire que .NET soit portable, puisqu'il repose sur l'architecture x86 32 bits. Java, non, par exemple.
                  • [^] # Re: Portable executable win32

                    Posté par (page perso) . Évalué à 2.

                    Mais n'imp'.

                    C'est vrai que Mono et pnet ne montrent pas du tout que .net soit portable hein.

                    Mono en fonctionnant sur x86, x86-64, ppc, sparc, ARM et j'en passe, pour des OS comme Linux, Solaris, *BSD, Mac OS X ou Windows, ne montre pas du tout que .net est portable.

                    Et Microsoft lui même, en sortant un Rotor qui fonctionnait pour sa version 1 sur FreeBSD, Mac OS X, et Windows, montre que .net n'est pas portable.

                    C'est juste un format de fichier !!!

                    Il se trouve que Microsoft qui a créer .net, a utilisé son format pour ses exécutables. Ce qui fait donc qu'un fichier .net est un véritable fichier PE32 ou PE32+ (donc 32 ou 64bits, ça importe quand on doit appeler du code natif 32 ou 64 bits).

                    Et que donc un loader qui comprend les fichiers PE peut comprendre un binaire .net, mais devra faire appel bien sur à une VM pour exécuter le code intermédiaire.

                    C'est ce que fait le PE loader de WinXP et 2003, qui quand ils reçoivent un binaire, vérifie s'il a son champ spécial dans son header, et dans ce cas là passe la main à .net, et sinon continue son bonhomme de chemin.

                    Le code X86 inclus dans le binaire n'est exécuté que par les loaders qui ne comprennent pas ce petit champ spécial (ceux de Win2K et 98, youahou). Même Wine gère ce champ, maintenant qu'on peut exécuter des applis .net dans Wine.

                    En fait le problème je crois, c'est que tu ne comprends pas bien comment tout ça marche.
                    • [^] # Re: Portable executable win32

                      Posté par (page perso) . Évalué à 4.

                      Si, je comprends. Et dans les faits, oui, c'est portable, mais pas conçu pour l'être. Sinon, ils n'auraient pas fait référence à un format spécifique, mais auraient créé un format de fichier dédié. Là, c'est tout simplement crade : c'est du code portable mis dans un conteneur spécifique hacké pour l'occasion, ce qui favorise explicitement une architecture particulière.

                      Dirait-on que Java est conçu pour être portable, si le format de ses classes avait une signature d'a.out pour SunOS SPARC ? Portables, ils le seraient dans les faits, mais la première chose que l'on voit dans le fichier montrerait qu'au départ, ils n'ont pas été conçus pour l'être, et que l'éditeur ne s'est pas donné la peine de corriger le tir par la suite.

                      Autre exemple : je sors une extension géniale pour le HTML, avec un plugin pour le lire sous Explorer. Ensuite, je publie les spécifications de ce format, mais il faut que ces documents commencent par <!--[if IE]-->. Désolé, mais c'est complètement baveux, comme attitude.
                  • [^] # Re: Portable executable win32

                    Posté par (page perso) . Évalué à 5.

                    Bon, soit. Mais dans ce cas, on ne peut pas dire que .NET soit portable, puisqu'il repose sur l'architecture x86 32 bits.
                    Ce qui repose sur du x86 32 bits c'est uniquement le bootstrap qui est là par soucis de compatibilité avec des vieux Windows. C'est là par soucis de pratique, ca n'enlèce strictement rien à la portabilité du code .NET en soit, et tous les runtime CLR savent lire ce bytecode et l'exécuter de manière portable.
                    C'est comme les fichiers script Python ou autre : les fichiers textes font chier parcqu'ils ne déclarent pas leur contenu (et ni leur encodage). On a trouvé une astuce en ajoutant une ligne ou 2 en début de fichier pour pallier cet inconvénient, c'est un hack, c'est pas joli joli, mais ca permet d'ouvrir le fichier avec n'importe quel éditeur texte, puisque ca reste un fichier texte. Mais ca n'empêche pas le shell qui sait lire les 2 lignes d'entête d'exécuter le script convenablement, lui qui sait les interpréter.
                    Pareil pour les fichiers OOo, ils auraient pu faire leur propre entête tout en conservant la compression zip, mais par pragmatisme et soucis "pratique" ils ont voulus laisser la possibilité de réutiliser les softs de décompression zip existant.
                    Mais franchement, se servir de ce genre d'argument pour dire : c'est pas conçu pour être portable, quand dans la pratique c'est tout à fait portable, c'est vraiment pitoyable.
  • # Mono pas compatible décideur pressé?

    Posté par . Évalué à 3.

    En admettant que l'on ferme les yeux sur le "piège microsoft", est-ce que Mono est utilisable en entreprise? Je m'imagine mal aller voir mon chef et lui proposer "on va faire du dotnet, mais au lieu de prendre la plateforme et les outils officiels pour lesquels ils existent des formations, du support et des certifications, on va prendre une implémentation à moitié compatible développée par d'obscurs geeks au fond de leur grotte" :-)
    • [^] # Re: Mono pas compatible décideur pressé?

      Posté par (page perso) . Évalué à 1.

      à moitié compatible

      Tu est sûr ?

      J'aimerais bien savoir dans quelle mesure mono garantit être conforme à la plateforme .NET. par exemple, dans ce qui est normalisé par l'ECMA, je suppose que tout est implémenté, c'est vrai ?

      Et pour le reste, il suffit de prendre les bindings mono pour des libs populaires comme Gtk# ou Qt#, non ?
  • # au final...

    Posté par (page perso) . Évalué à 2.

    au final qui va installer mono 2.0?

    www.solutions-norenda.com

Suivre le flux des commentaires

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