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.
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.
- 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.
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.
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).
Aller plus loin
- Mono (17 clics)
- Mono 2.0 : Notes de version et captures d'écrans (6 clics)
- Monologue (Planet) (6 clics)
- Communauté francophone (21 clics)
- Mono sur Wikipédia (19 clics)
# polymique...
Posté par collinm (site web personnel) . Évalué à 5.
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 zebra3 . Évalué à 5.
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 bubar🦥 (Mastodon) . Évalué à 8.
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 collinm (site web personnel) . Évalué à 5.
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 Éric (site web personnel) . Évalué à 10.
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 Beretta_Vexee . Évalué à 7.
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 Quzqo . Évalué à 8.
Là on voit que tu ne connais pas mon amie....
[^] # Re: polymique...
Posté par Éric (site web personnel) . Évalué à 7.
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 Yusei (Mastodon) . Évalué à 8.
[^] # Re: polymique...
Posté par romu . Évalué à 6.
.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 zebra3 . Évalué à 10.
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 bubar🦥 (Mastodon) . Évalué à 4.
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 Bozo_le_clown . É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 alice . Évalué à 10.
[^] # Re: polymique...
Posté par Bozo_le_clown . Évalué à 4.
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 jardiland . Évalué à 4.
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 ragoutoutou . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 9.
Alors faut savoir, y'a des applications .NET qui tournent dans des environnements critiques ou pas ?
[^] # Re: polymique...
Posté par ragoutoutou . Évalué à 6.
[^] # Re: polymique...
Posté par TImaniac (site web personnel) . Évalué à 6.
[^] # Re: polemique...
Posté par abramov_MS . Évalué à 2.
[^] # Re: polymique...
Posté par ragoutoutou . Évalué à 4.
En tout cas, rien de comparable chez Sun à la machine de guerre commerciale de Microsoft.
[^] # Re: polymique...
Posté par Jb Evain (site web personnel) . Évalué à 5.
C'est objectif et argumenté ça tiens.
[^] # Re: polymique...
Posté par ragoutoutou . Évalué à 2.
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 Jb Evain (site web personnel) . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 2.
Non mais WCF par contre... Olive, Olive !
[^] # Re: polymique...
Posté par Bozo_le_clown . Évalué à 1.
[^] # Re: polymique...
Posté par Jaimepaslelundi . Évalué à 1.
[^] # Re: polymique...
Posté par jardiland . Évalué à 3.
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 kowalsky . Évalué à 8.
[^] # Re: polymique...
Posté par Bozo_le_clown . Évalué à 4.
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 jardiland . Évalué à 2.
[^] # Re: polymique...
Posté par collinm (site web personnel) . Évalué à 2.
www.solutions-norenda.com
[^] # Re: polymique...
Posté par ckyl . Évalué à 3.
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 pasBill pasGates . Évalué à 6.
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 Pat _ . Évalué à 0.
non, c'est pas argumenté, mais c'est une sensation partagée :)
[^] # Re: polymique...
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: polymique...
Posté par Dring . Évalué à 5.
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 goernil . Évalué à 2.
[^] # Re: polymique...
Posté par Dring . Évalué à 1.
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 pasBill pasGates . Évalué à 2.
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 lezardbreton . Évalué à 2.
[^] # Re: polymique...
Posté par Misc (site web personnel) . Évalué à 5.
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 B16F4RV4RD1N . Évalué à 6.
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 Pierre6020 . Évalué à 6.
[^] # Re: polymique...
Posté par O'neam Anne . Évalué à 10.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: polymique...
Posté par Cédric Chevalier (site web personnel) . Évalué à 1.
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 olympi . Évalué à 3.
# C# n'est pas un langage à typage fort !
Posté par syj . Évalué à 2.
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 Achille Fouilleul (site web personnel) . Évalué à 10.
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 riri le breton (site web personnel) . Évalué à 8.
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 syj . Évalué à 3.
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 riri le breton (site web personnel) . Évalué à 1.
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 Jb Evain (site web personnel) . Évalué à 6.
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 collinm (site web personnel) . Évalué à 6.
www.solutions-norenda.com
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 3.
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 MsieurHappy . Évalué à 2.
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 Jb Evain (site web personnel) . Évalué à 2.
C'est ce que je dis, si ça permet de mettre en avant des concepts intéressants comme ceux-ci, dans un langage mainstream, et peut être d'intéresser certains développeurs vers autre chose, moi je dis tant mieux.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par left . Évalué à 10.
Trop ?
[^] # Re: C# n'est pas un langage à typage fort !
Posté par dinomasque . Évalué à 3.
BeOS le faisait il y a 20 ans !
[^] # Re: C# n'est pas un langage à typage fort !
Posté par case42 (site web personnel) . Évalué à 8.
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 TImaniac (site web personnel) . Évalué à 3.
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 Jb Evain (site web personnel) . Évalué à 6.
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 kahal (site web personnel) . Évalué à 6.
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 TImaniac (site web personnel) . Évalué à 1.
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 kahal (site web personnel) . Évalué à 6.
Dictionary<string, object> cache;
Dictionary<string, object> * cache = new Dictionary<string, object>();
Auto cache = new Dictionary<string, object>();
Donc, je me répète, le C++ c'est pas si mal...
[^] # Re: C# n'est pas un langage à typage fort !
Posté par TImaniac (site web personnel) . Évalué à 1.
Le C++ ca sera pas si mal...
[^] # Re: C# n'est pas un langage à typage fort !
Posté par left . Évalué à 5.
Dictionary<string, object> cache;
etDictionary<string, object> * cache = new Dictionary<string, object>();
n'ont pas du tout la même signification. Dans les 2 cas l'objet est du même type, sauf que y'en a un qui a été alloué sur le tas et l'autre sur la pile. Mauvais exemple.[^] # Re: C# n'est pas un langage à typage fort !
Posté par riba . Évalué à 1.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Gof (site web personnel) . Évalué à 1.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par ß ß . Évalué à 10.
L'avantage c'est qu'on C# t'as le choix entre les 2 syntaxes...
Tu devrais essayer perl, ça va te plaire.[^] # Re: C# n'est pas un langage à typage fort !
Posté par Moonz . Évalué à 3.
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 Narishma Jahar . Évalué à 4.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par left . Évalué à 3.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Guillaume Knispel . Évalué à 1.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par alice . É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 ecyrbe . Évalué à 1.
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 Guillaume Knispel . Évalué à 7.
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 ecyrbe . Évalué à 1.
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 LupusMic (site web personnel, Mastodon) . Évalué à 1.
std::for_each(b_it, e_it, functor) ;
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Moonz . Évalué à 2.
[^] # SQL et LINQ
Posté par Ontologia (site web personnel) . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: SQL et LINQ
Posté par fabien . Évalué à 1.
ainsi le prod cartesien ne se fera qu'entre des "tables" de un enregistrement chacun.
non ?
[^] # Re: SQL et LINQ
Posté par Pat _ . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 3.
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 Ontologia (site web personnel) . Évalué à 1.
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 Guillaume Knispel . Évalué à 3.
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 alice . Évalué à 1.
[^] # Re: SQL et LINQ
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: SQL et LINQ
Posté par alice . Évalué à 1.
[^] # Re: SQL et LINQ
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par benoar . Évalué à 5.
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 Jb Evain (site web personnel) . Évalué à 2.
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 benoar . Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . Évalué à 5.
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 mrlem (site web personnel) . Évalué à 1.
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 Jb Evain (site web personnel) . Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par mrlem (site web personnel) . Évalué à 1.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . Évalué à 2.
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.
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 collinm (site web personnel) . Évalué à 2.
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 Loic Dreux . Évalué à 6.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par zebra3 . Évalué à 1.
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 Camille_B . Évalué à 1.
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.
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 Camille_B . Évalué à 1.
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 seginus . Évalué à 10.
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 zebra3 . Évalué à 3.
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 patrick_g (site web personnel) . Évalué à 5.
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 Guillaume Denry (site web personnel) . Évalué à 7.
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 seginus . Évalué à 4.
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 case42 (site web personnel) . Évalué à 5.
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 hervé Couvelard . Évalué à 1.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par seginus . Évalué à 5.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Mildred (site web personnel) . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Yusei (Mastodon) . Évalué à 6.
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 thedude . Évalué à 2.
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 seginus . Évalué à 3.
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 thedude . Évalué à 2.
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 seginus . Évalué à 2.
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 thedude . Évalué à 3.
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 benja . Évalué à 1.
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 seginus . Évalué à 3.
Avec ctl-maj sous Nautilus on peut faire un lien symbolique, mais je n'ai encore rien vu pour un lien en dur.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par psychoslave__ (site web personnel) . Évalué à 0.
* 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 Guillaume Denry (site web personnel) . Évalué à 3.
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 patrick_g (site web personnel) . Évalué à 3.
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 Yusei (Mastodon) . Évalué à 5.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
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 Mildred (site web personnel) . Évalué à 1.
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 lolop (site web personnel) . Évalué à 3.
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++.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Zorro (site web personnel) . Évalué à 2.
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.
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 Xavier Verne (site web personnel) . Évalué à 3.
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 Camille_B . Évalué à 1.
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 Yusei (Mastodon) . Évalué à 10.
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 Camille_B . Évalué à 2.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par abramov_MS . Évalué à 3.
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 Jb Evain (site web personnel) . Évalué à 3.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Camille_B . Évalué à 1.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par gilgam . Évalué à 2.
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 patrick_g (site web personnel) . Évalué à 1.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Zorro (site web personnel) . Évalué à 4.
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 Camille_B . Évalué à 1.
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.
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 Stéphane Davy . Évalué à 1.
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 abramov_MS . Évalué à 10.
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 Camille_B . Évalué à -1.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 1.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . Évalué à 6.
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 abramov_MS . Évalué à -1.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Gniarf . Évalué à 1.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Bozo_le_clown . Évalué à 1.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
au l'utilisation spécifique de Gnome.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Yusei (Mastodon) . Évalué à 2.
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 Camille_B . Évalué à 6.
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 Mildred (site web personnel) . Évalué à 3.
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 patrick_g (site web personnel) . Évalué à 5.
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 Camille_B . Évalué à 3.
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 abramov_MS . Évalué à 4.
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 Antoine . Évalué à 1.
C'est CPython. Cython, c'est encore autre chose (un fork très amélioré de Pyrex).
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 3.
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 abramov_MS . Évalué à 1.
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 Psychofox (Mastodon) . Évalué à 0.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 4.
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 Psychofox (Mastodon) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 1.
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 Yusei (Mastodon) . Évalué à 3.
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 dinomasque . Évalué à 4.
BeOS le faisait il y a 20 ans !
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . Évalué à 1.
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 abramov_MS . Évalué à 1.
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 Jb Evain (site web personnel) . Évalué à 1.
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 abramov_MS . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . Évalué à 2.
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 Bozo_le_clown . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 3.
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 Bozo_le_clown . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par TImaniac (site web personnel) . Évalué à 3.
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 abramov_MS . Évalué à -1.
On verra a la prochaine version dans 2 ou 3 ans...
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Yusei (Mastodon) . Évalué à 4.
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 collinm (site web personnel) . Évalué à 2.
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 Mildred (site web personnel) . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . Évalué à 1.
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 Gniarf . Évalué à 2.
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 Camille_B . Évalué à 2.
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 abramov_MS . Évalué à 1.
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 Camille_B . É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."
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 abramov_MS . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 4.
T'es toujours incapable de nous citer une seule appli "phare" entièrement en .NET.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Bozo_le_clown . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par TImaniac (site web personnel) . Évalué à 5.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . Évalué à 2.
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 abramov_MS . Évalué à 2.
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 collinm (site web personnel) . Évalué à 1.
www.solutions-norenda.com
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Gniarf . É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 abramov_MS . Évalué à 2.
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 Yusei (Mastodon) . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 2.
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 Camille_B . Évalué à 2.
Mais allez à la source mon vieux :
http://code.google.com/p/paint-mono/
Vous verrez un joli screenshot montrant l'état des lieux. Vous pouvez aussi télécharger les sources et tester la chose vous savez !
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Mildred (site web personnel) . É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 Adrien . Évalué à 2.
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 Jb Evain (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par abramov_MS . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
Après vérification l'appli utilise DirectX.
# .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 3.
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 abramov_MS . Évalué à 2.
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 ragoutoutou . Évalué à 5.
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 TImaniac (site web personnel) . Évalué à 1.
Montre moi les brevets sur Windows.Forms.
[^] # Re: .NET et portabilité GUI = 2
Posté par ragoutoutou . Évalué à 1.
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 zebra3 . Évalué à 2.
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 Bozo_le_clown . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
[^] # Re: .NET et portabilité GUI = 2
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: .NET et portabilité GUI = 2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
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 pasBill pasGates . Évalué à -4.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 pasBill pasGates . Évalué à 0.
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 zebra3 . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: .NET et portabilité GUI = 2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 pasBill pasGates . Évalué à -1.
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 zebra3 . Évalué à 6.
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 pasBill pasGates . Évalué à 1.
[^] # Re: .NET et portabilité GUI = 2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 pasBill pasGates . Évalué à -1.
- 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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 pasBill pasGates . Évalué à 1.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 pasBill pasGates . Évalué à 1.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
- 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 pasBill pasGates . Évalué à 1.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 pasBill pasGates . Évalué à 0.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: .NET et portabilité GUI = 2
Posté par benoar . Évalué à 3.
[^] # Re: .NET et portabilité GUI = 2
Posté par pasBill pasGates . Évalué à -1.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: .NET et portabilité GUI = 2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: .NET et portabilité GUI = 2
Posté par pasBill pasGates . Évalué à -1.
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 Juke (site web personnel) . Évalué à 2.
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 allcolor (site web personnel) . Évalué à 1.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: .NET et portabilité GUI = 2
Posté par collinm (site web personnel) . Évalué à 1.
www.solutions-norenda.com
[^] # Re: .NET et portabilité GUI = 2
Posté par zebra3 . Évalué à 2.
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 ragoutoutou . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 3.
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 ragoutoutou . Évalué à 1.
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 abramov_MS . Évalué à 1.
[^] # Re: .NET et portabilité GUI = 2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: .NET et portabilité GUI = 2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Le grand public est indigne de bénéficier correctement de la concurrence, en revanche.
[^] # Re: .NET et portabilité GUI = 2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
À se demander pourquoi Microsoft fait de la publicité pour Windows, puisque le revenu principal de cette division fonctionne sur le modèle d'une taxe obligatoire.
[^] # Re: .NET et portabilité GUI = 2
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: .NET et portabilité GUI = 2
Posté par vida18 . Évalué à 1.
http://www.lemagit.fr/article/open-source-microsoft-developp(...)
[^] # Re: .NET et portabilité GUI = 2
Posté par TImaniac (site web personnel) . Évalué à 2.
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 Mildred (site web personnel) . Évalué à 0.
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 tanguy_k (site web personnel) . Évalué à 2.
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 tanguy_k (site web personnel) . Évalué à 5.
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 TImaniac (site web personnel) . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 3.
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 tanguy_k (site web personnel) . Évalué à 5.
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 abramov_MS . Évalué à 3.
[^] # Re: .NET et portabilité GUI = 2
Posté par TImaniac (site web personnel) . Évalué à 1.
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 abramov_MS . Évalué à 2.
Tres legerment obsolete tes affirmations...
http://labs.trolltech.com/blogs/2008/09/05/qgtkstyle-now-par(...)
[^] # Re: .NET et portabilité GUI = 2
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . Évalué à 3.
Ouai enfin la c'est quand meme du chipo ou alors on parle pas du meme truc. Moi je pensais a ca par exemple : titre de la fenetre = "Nom de l'appli - nom du fichier ouvert" qui est peut etre different suivant les guidelines des OS. Ou encore l'emplacement du "panneau de config" qui est dans le menu "tools" ou "edit".
Si tu pinailles la dessus et 3 pauv #ifdef dans ton code pour arranger ca, alors je comprends pas pourquoi selon ton point de vue, les WinForms sous Linux/MacOS ne meriteraient pas le terme "experimental" :)
> Faire un theme natif, c'est pas du coloriage
Sans dec. J'ai déjà dis le contraire ?
C'etait en reponse a ton lien http://www.gnome-look.org/content/show.php/show.php?content=(...)
Si tu regardes le contenu, c'est justement du "coloriage", autrement j'aurais pas evoque ce sujet.
t'as jamais eu l'idée qu'on pouvait utiliser les widgets natifs dans un thème ?
Je crois qu'on tourne en rond "Faire un theme natif, c'est pas du coloriage mais utiliser l'API de la plateforme"
Qt s'intègre très mal sous Gnome par exemple qui a une gestion de layout complètement différente
La c'est sur, on tourne vraiment en rond cf les liens au dessus
http://doc.trolltech.com/4.4/qdialogbuttonbox.html http://doc.trolltech.com/4.2/qt4-2-intro.html#desktop-integr(...) (ca existe depuis 2 ans) http://labs.trolltech.com/blogs/2008/10/02/qgtkstyle-now-on-(...)
[^] # Re: .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . Évalué à 2.
D'ailleurs Qt gère en partie certaines de ces problématiques
cf http://doc.trolltech.com/4.4/qmenubar.html#details
[^] # Re: .NET et portabilité GUI = 2
Posté par Gof (site web personnel) . Évalué à 3.
[^] # Re: .NET et portabilité GUI = 2
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: .NET et portabilité GUI = 2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
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 romu . Évalué à 2.
Attention : "vraie appli" = PAS un IDE (ce serait trop facile).
[^] # Re: .NET et portabilité GUI = 2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
[^] # Re: .NET et portabilité GUI = 2
Posté par Bozo_le_clown . Évalué à 3.
De Nada
[^] # Re: .NET et portabilité GUI = 2
Posté par romu . Évalué à 1.
Et puis j'ai triché, je connais une excellente appli dont la GUI est en Swing, Lightzone (la seule appli que j'ai achetée pour Linux) :
http://www.lightcrafts.com/products/
Je reconnais volontiers qu'on peut faire des GUI valables avec Java, mais on se refait pas, je préfère Mono sur mon Linux.
[^] # Re: .NET et portabilité GUI = 2
Posté par abramov_MS . Évalué à 2.
http://www.jython.org/Project/
http://aladin.u-strasbg.fr/
http://www.mercury.im/
http://jalbum.net/
http://rsbweb.nih.gov/ij/
Des trucs assez differents dans des domaines pas du tout lie comme tu peux voir. Certains sont moche d'autre moins. Tous sont multiplateforme et tournent sans problemes sous windows et Unix...
Maintenant j'attend le meme genre de liste pour .Net...
[^] # Re: .NET et portabilité GUI = 2
Posté par abramov_MS . Évalué à 1.
[^] # Re: .NET et portabilité GUI = 2
Posté par Camille_B . Évalué à 2.
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 abramov_MS . Évalué à 1.
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 Camille_B . Évalué à 1.
[^] # Re: .NET et portabilité GUI = 2
Posté par abramov_MS . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: .NET et portabilité GUI = 2
Posté par abramov_MS . Évalué à -2.
On revient a "toujours pas d'exemple"!
[^] # Re: .NET et portabilité GUI = 2
Posté par TImaniac (site web personnel) . Évalué à 2.
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 Bozo_le_clown . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 2.
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 Yusei (Mastodon) . Évalué à 3.
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 Bozo_le_clown . É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 ?
[^] # Re: .NET et portabilité GUI = 2
Posté par TImaniac (site web personnel) . Évalué à 2.
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 Bozo_le_clown . Évalué à 2.
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 Camille_B . Évalué à 1.
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 Bozo_le_clown . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 4.
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 Camille_B . Évalué à 1.
"/// 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 TImaniac (site web personnel) . Évalué à 2.
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 Bozo_le_clown . Évalué à 2.
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 Camille_B . Évalué à 3.
Ç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 collinm (site web personnel) . Évalué à 0.
www.solutions-norenda.com
[^] # Re: .NET et portabilité GUI = 2
Posté par abramov_MS . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 abramov_MS . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 4.
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 thedude . Évalué à 7.
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 romu . Évalué à 1.
# Pas de Mono pour moi...
Posté par David Sporn (site web personnel) . Évalué à 8.
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 Yusei (Mastodon) . É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 ?)
- 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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: Pas de Mono pour moi...
Posté par abramov_MS . Évalué à 6.
[^] # Re: Pas de Mono pour moi...
Posté par Camille_B . Évalué à 0.
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 abramov_MS . Évalué à 3.
[^] # Re: Pas de Mono pour moi...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Pas de Mono pour moi...
Posté par zebra3 . Évalué à 10.
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 thedude . Évalué à 3.
"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 abramov_MS . Évalué à 2.
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 thedude . Évalué à 3.
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 abramov_MS . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 1.
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 Camille_B . Évalué à 1.
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 Yusei (Mastodon) . Évalué à 2.
[^] # Re: Pas de Mono pour moi...
Posté par ragoutoutou . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 ragoutoutou . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Pas de Mono pour moi...
Posté par TImaniac (site web personnel) . Évalué à 2.
- OIN : armes de dissuasion en période de guerre froide.
- accord Novell/MS : accord de cesser le feu entre 2 parties.
[^] # Re: Pas de Mono pour moi...
Posté par alice . Évalué à 2.
Java passe en GPL.
http://www.sun.com/2006-1113/feature/story.jsp
[^] # Re: Pas de Mono pour moi...
Posté par ckyl . Évalué à 2.
Les implémentations d'IBM et de BEA restent toujours aussi proprios.
[^] # Re: Pas de Mono pour moi...
Posté par ckyl . Évalué à 4.
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 Yusei (Mastodon) . Évalué à 2.
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 alice . Évalué à 2.
[^] # Re: Pas de Mono pour moi...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Pas de Mono pour moi...
Posté par David Sporn (site web personnel) . Évalué à 4.
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 kowalsky . Évalué à 4.
[^] # Re: Portabilité !
Posté par Camille_B . Évalué à 2.
[^] # Re: Portabilité !
Posté par Bozo_le_clown . Évalué à 2.
"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 windu.2b . Évalué à 7.
====>[]
# Intérèt de mono et .Net
Posté par Adrien . Évalué à 4.
.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 alice . Évalué à 2.
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 abramov_MS . Évalué à 2.
[^] # Re: Intérèt de mono et .Net
Posté par ckyl . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 ckyl . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 1.
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 alice . Évalué à 0.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Intérèt de mono et .Net
Posté par Jean B . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
2.times(()=>print("toto"));
print("person".pluralize());
[^] # Re: Intérèt de mono et .Net
Posté par sifu . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 Jean B . Évalué à 1.
Le monkey patching lui est global. Menfin ....
[^] # Re: Intérèt de mono et .Net
Posté par TImaniac (site web personnel) . É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 Jean B . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Intérèt de mono et .Net
Posté par TImaniac (site web personnel) . Évalué à 2.
DateTime.Now + 1.hour() + 5.minutes()
Pas besoin de langage dynamique pour ca !
[^] # Re: Intérèt de mono et .Net
Posté par alice . Évalué à 2.
Ou pas!
http://www.theserverside.com/news/thread.tss?thread_id=46887
[^] # Re: Intérèt de mono et .Net
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Intérèt de mono et .Net
Posté par ckyl . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 dufour olivier . Évalué à -3.
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 Troy McClure (site web personnel) . Évalué à 3.
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 Cook Captain . Évalué à 9.
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 TImaniac (site web personnel) . Évalué à 2.
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 Graveen . Évalué à 2.
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 zebra3 . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: déçu
Posté par abramov_MS . Évalué à 3.
[^] # Re: déçu
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: déçu
Posté par syj . Évalué à 2.
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 collinm (site web personnel) . Évalué à -4.
mis à par les vendu à ms?
www.solutions-norenda.com
[^] # Re: priviliégié
Posté par 2PetitsVerres . Évalué à 6.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Portable executable win32
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Portable executable win32
Posté par TImaniac (site web personnel) . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 4.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
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 Jb Evain (site web personnel) . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: Portable executable win32
Posté par Jb Evain (site web personnel) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
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 TImaniac (site web personnel) . Évalué à 5.
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 alice . Évalué à 3.
[^] # Re: Mono pas compatible décideur pressé?
Posté par Mildred (site web personnel) . Évalué à 1.
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 collinm (site web personnel) . Évalué à 2.
www.solutions-norenda.com
[^] # Re: au final...
Posté par abramov_MS . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.