Mono (re-implementation de .NET sous license libre) est désormais dispo pour Android cf http://tirania.org/blog/archive/2011/Apr-06.html
Mono était deja disponible pour iOS via MonoTouch (en version 4.0 actuellement).
Attention ! MonoTouch et Mono for Android sont des produits commerciaux (400$ pour les versions pro). Le code source est base sur Mono (MIT/LGPL/GPL) mais monotouch.dll est par exemple closed source.
MonoTouch et Mono for Android permettent d'utiliser les API natives. Comme l'indique de Icaza, le mieux est donc de séparer le noyau de son application de l'interface graphique.
Le noyau est alors identique sur toutes les plateformes, en revanche la GUI est spécifique a chaque plateforme :
- MonoTouch pour iOS
- Mono for Android pour Android
- Silverlight/Mobile pour Windows Phone 7
- MonoMac pour MacOS X
- Gtk# pour Linux
- WPF pour Windows
- ASP.NET MVC pour les sites web
Dommage que ca ne soit pas open source (ca le sera peut être dans le futur ?) mais je trouve qu'ils ont trouve un bon business plan.
Dommage également que Qt pour Mono ne soit pas supporte de façon officiel au meme titre que Gtk+, ca permettrait de limiter le nombre de GUI differentes a développer.
Attention aux trolls, on n'est pas encore vendredi...
# Mouais
Posté par yellowiscool . Évalué à 8.
C'est dommage de faire du closed source. Un modèle mixte à la Qt, c'est quand même mieux.
Il doit avoir des raisons que je ne devines pas. Mais là comme ça, je dirais que c'est juste des vilains pas beaux.
Envoyé depuis mon lapin.
# Je tiendrai jusqu'à demain
Posté par Maclag . Évalué à 10.
Je tiendrai jusqu'à demain
Je tiendrai jusqu'à demain
Je tiendrai jusqu'à demain
Ça pue c'est pas libre et bourré jusqu'à la gueule de brevets!
J'ai pas tenu jusqu'à demain
J'ai pas tenu jusqu'à demain
J'ai pas tenu jusqu'à demain
[^] # Re: Je tiendrai jusqu'à demain
Posté par zebra3 . Évalué à -4.
Je vais me faire moinsser mais tant pis : parce que le noyau Linux n'est pas bourré de brevets ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je tiendrai jusqu'à demain
Posté par Albert_ . Évalué à 1.
Lesquels? Microtruc a prentendu cela il y a plusieurs annees et on attend encore de savoir lesquels et dernierement lorsqu'ils ont decrit les quelques soit disant violation de brevet (5) cela n'a strictement rien avoir avec le kernel.
http://linuxfr.org/users/albert_/journaux/le-retour-des-methodes-mafieuses
[^] # Re: Je tiendrai jusqu'à demain
Posté par zebra3 . Évalué à 9.
Pareil pour Mono : lesquels ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je tiendrai jusqu'à demain
Posté par tanguy_k (site web personnel) . Évalué à 3.
Pas mal la démonstration en 2 étapes :)
AHMA La menace des brevets sur Mono s'amenuise avec le temps
[^] # Re: Je tiendrai jusqu'à demain
Posté par Albert_ . Évalué à -5.
Je te laisse chercher c'est un sujet qui ne m'interesse pas vu que mono degage de mon ordi. Mais bon vu que Microsoft brevete la moindre pisse sortant de chez lui, C# est bourre de brevet et il me semble bien que seul la version ECMA, une tres vieille version de ce truc, a la promesse de non utilisation des brevets. Il me semble bien que mono ne se limitant pas du tout a cette version, il est a peu pres certains que des brevets microtruc sont utilise dedans.
Et vu que microtruc a bien affirme recemment son cote "gros connard de cours de recreation qui tape sur les plus petit pour les racketter" ca m'etonnerait pas qu'ils attendent juste le bon moment pour attaquer sur ce sujet. Pour le moment ils s'abstiennent car ils veluent tenter de faire croire que ce sont des gentils mais il faut vraiment etre un bisounours (ou etre paye par cette boite) pour leur faire confiance.
[^] # Re: Je tiendrai jusqu'à demain
Posté par zebra3 . Évalué à 5.
Ah ben c'est facile de critiquer sans avoir de source. C'est bien simple : pas de preuve, pas d'accusation plausible.
Pour le noyau Linux, il y en eu au moins une : l'implémentation des doubles noms de fichiers dans FAT32. Il me semble que ça a été corrigé, mais c'est arrivé (même si c'est complètement con).
Rien ne dit que c'est encore le cas, mais c'est alors la même chose pour Mono. Et je ne crois pas que l'OIN existe juste pour faire joli.
Pour ce qui est de ces assertions de brevet violés, je te copie cet extrait de la page Wikipédia de Mono :
Seule la couche de compatibilité pourrait éventuellement poser problème, mais pas le reste. Il suffit de ne pas l'installer, d'autant que sous Linux elle n'est pas nécessaire et n'a pas vraiment d'utilité.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je tiendrai jusqu'à demain
Posté par Albert_ . Évalué à 2. Dernière modification le 09 avril 2011 à 13:24.
Donc tu es en train de dire:
et en meme temps:
Tu ne penses pas que ton attitude est "tres" legerement incoherente?
Donc pour linux, ca fait plus de deux ans que microtruc a fait son FUD sur les 200 brevets viole par linux, en fait cela s'est resolu en un seul qui a ete corrige en une journee... Les 199 autres ont attend toujours la liste. Il y a une semaine une nouvelle attaque de microtruc contre linux (sous la forme d'android) ne concerne pas le kernel.
Donc deux solutions :
Personnellement je me tape de savoir lesquels brevets mono viole. Le risque que mono viole des brevets de microtruc est tres tres tres important (montre moi une analyse de mono qui valide par microtruc prouve que pas un seul brevet de microtruc ne sont dedans).
Le benefice d'avoir mono par rapport au risque est tellement en sa defaveur que c'est totalement ridicule de s'obstiner sur ce truc.
[^] # Re: Je tiendrai jusqu'à demain
Posté par zebra3 . Évalué à 6.
Non, je voudrais seulement comprendre : en quoi utiliser Mono serait plus risqué juridiquement que le noyau Linux ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je tiendrai jusqu'à demain
Posté par Albert_ . Évalué à 1.
Probablement parceque en utilisant des technologies microtruc, vu que microtruc brevete toute pisse sortant de chez eux, tu es a peu pres sur qu'il y a donc des brevets dessus.
Jusqu'a preuve du contraire linux n'est pas une technologie microtruc et les 199 autres brevets n'ont toujours pas ete prouves. Cela ne veut naturellement pas dire qu'il y a pas un ou deux brevets que linux violeraient mais bon vu le niveau d'avance de linux pour sortir un brevet innovant sans que cela soit deja depuis longtemps soit implemente, soit dans les mails lists ca va etre rigolo.
Au passage, le brevet viole par linux dont tu as parle montre bien le probleme de mono vu que justement ce brevet implique une technologie microtruc et donc concerne un outil qui permet de communiquer avec le monde windbidule et non pas quelque chose de fondamental a linux.
[^] # Re: Je tiendrai jusqu'à demain
Posté par zebra3 . Évalué à 5.
Jusqu'à preuve du contraire, Mono n'est pas une technologie Microsoft.
C'est l'implémentation d'une norme standardisée ECMA et ISO, accompagnée d'outils propres et d'outils de compatibilité non nécessaires à son fonctionnement et pouvant être écartés.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je tiendrai jusqu'à demain
Posté par Albert_ . Évalué à -1.
Ah tiens C# n'est pas une technologie microtruc. Je ne savais pas. Tu peux me donner le nom et le lien de l'entite qui a pondu cela?
J'ai deja repondu en ce qui concernait ECMA (il me semble pas que cela soit passe a l'ISO meme si je pense que microtruc peut payer encore quelques personnes pour faire passer un truc ou tout est a faire), la version C# de l'ECMA, et donc celle concerne par les promesses de non agression est tres ancienne et ne correspond plus du tout a l'etat actuel de mono.
[^] # Re: Je tiendrai jusqu'à demain
Posté par zebra3 . Évalué à 4.
C# n'est pas la technologie mais un langage. Mono et .Net en sont des implémentations.
Oui je joue sur les mots, mais le vocabulaire est important si on veut jouer dans le domaine juridique.
Ben tu n'oublieras pas de corriger Wikipédia alors :
Et :
Et en citant tes sources, pour changer.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je tiendrai jusqu'à demain
Posté par Albert_ . Évalué à -4.
Si tu joues sur les mots: mono n'est il pas une implementation de la technologie microtruc C#/.Net? C'est amusant de jouer sur les mots mais pretendre que mono ne se fonde pas sur des trucs sortie de Redmond c'est etre un menteur (oui j'utilise le mot en toute connaissance de cause). Ose donc dire que mono n'implemente pas une seule technologie microsoft (je ne parle pas de brevets la).
Je n'allais pas me fatiguer a aller verifier si c'etait ISO ou pas d'ou le fait que j'ai bien utiliser le il me semble pas.
Amusant que tu donnes les dates car les seuls trucs proteges, rappellons le encore une fois, des attaques de microsoft date de 2001 et 2003. Tenterais tu de nous faire croire que mono n'utilise que ces technologies la? Si oui cela sert a quoi ce truc, Qt est tres largement superieur a ca...
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 3.
Tu sais, Qt aussi implémente des technos Microsoft, et même des brevets Microsoft, exemple :
http://www.google.com/patents/about?id=qscSAAAAEBAJ
http://www.google.com/patents/about?id=C8CWAAAAEBAJ
http://www.google.com/patents/about?id=VsUVAAAAEBAJ
Chez Qt ca donne :
http://labs.trolltech.com/blogs/2007/02/28/new-classes-qxmlstreamreader-and-qxmlstreamwriter/
De nombreux projets écrits en C utilise libxml2, et là, paf, même techno, mêmes brevets, et ils ne s'en cachent même pas :
http://www.xmlsoft.org/xmlreader.html
En fait, le seul pas enmerdé, c'est Mono, qui implémente bien la même techno, mais en respectant le standard défini à l'ISO.
Mais chuuttt, tu le répèteras pas, je te fais confiance.
[^] # Re: Je tiendrai jusqu'à demain
Posté par tanguy_k (site web personnel) . Évalué à 5.
LINQ, ADO.Net, WCF, WF, XML, HTTP... Si tu fais du C# t'es pratiquement obligé d'utiliser des composants de .NET (même sous Linux) qui donc ne font pas partie des normes ECMA (sauf a re-inventer la roue évidemment).
ECMA couvre seulement le langage lui même, pire C# 3 et 4 ne sont pas couvert, la dernière norme date de 2006 -> une éternité !
Il a un risque plus important que pour d'autres logiciels libres. Mais Microsoft ne peut pas non plus 10 ans après les faits se plaindre de la violation d'un brevet. Il me semble qu'il est du devoir du détenteur d'un brevet de le faire valoir dans un délais "raisonnable".
Mon avis est donc qu'il ne se passera rien ou au pire des représailles anecdotiques.
Les développeurs de Mono ne sont pas idiots, ils ont bien conscience des risques de brevets. Cf Icaza en 2006 http://tirania.org/blog/archive/2006/Nov-04.html
Et s'ils en rencontraient :
La FAQ de Mono est également assez clair sur le sujet http://www.mono-project.com/FAQ:_Licensing#Patents
Conclusion : le risque n'est pas nul mais assez faible a mon avis
[^] # Re: Je tiendrai jusqu'à demain
Posté par Albert_ . Évalué à 1.
Il a un risque plus important que pour d'autres logiciels libres. Mais Microsoft ne peut pas non plus 10 ans après les faits se plaindre de la violation d'un brevet. Il me semble qu'il est du devoir du détenteur d'un brevet de le faire valoir dans un délais "raisonnable".
Mon avis est donc qu'il ne se passera rien ou au pire des représailles anecdotiques.
Ca c'est ton souhait, le probleme c'est que la loi ne dit pas cela et donc il n'y a strictement aucune garantie sur le sujet, au contraire.
Si tu parles avec des avocats americains sur les brevets, le truc c'est justement l'inverse. Avoir des brevets dit dormants que tu ressorts lorsque que tu peux faire cracher quelqu'un ou que tu veux t'en debarasser (comme dans le cas de microtruc).
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 6.
Non. ECMA couvre bien plus : la VM, le runtime et toutes les libs de base (IO, XML, HTTP, etc.).
Les briques non standardisées sont les briques de haut niveau : WCF (c'est Novell qui a les brevets clés), WF (pas implémenté par Mono), WPF (non plus), ASP.NET (deprecated, remplacé par ASP.NET MVC, sous licence libre).
Contrairement à d'autres logiciels libres, Mono est une implémentation conforme, et est donc couvert par les engagements de Microsoft, tout le contraire des plateformes très proches et avec des concepts clairement identiques, type Java/Dalvik ou encore Vala.
[^] # Re: Je tiendrai jusqu'à demain
Posté par tanguy_k (site web personnel) . Évalué à 3.
Effectivement, il y a 2 normes ECMA (334 et 335).
ECMA 335 couvre la CLI et apparemment tout System.* (notamment XML, HTTP, IO...)
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf et la dernière mise a jour date de décembre 2010 !
[^] # Re: Je tiendrai jusqu'à demain
Posté par houra . Évalué à 2.
Je vois pas ce que vala pourrait violer, sauf à interdire à des gens d'écrire ...
Quant à Mono, moi, je sais pas, mais là, le mec , il demande 400$ , et à ce prix, j'ai un ordinateur sous Windows, Visual Express, le SDK pour WP7, Eclipse et le SDK pour Android.
Ou un-demi MacBook et le SDK pour l'Iphone+ Eclipse et le SDK Android.
Franchement, ça donne pas envie...
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 0.
http://linuxpatents.blogspot.com/2010/05/language-envy.html
Pour un particulier on est d'accord. La cible, c'est les entreprises : 400$, c'est le tarif d'une journée d'ingénieur de base. C'est très largement rentabilisé si ca permet d'économiser une montée en compétence sur Objective-C, ou mieux, une journée d'installation d'Eclipse ;)
[^] # Re: Je tiendrai jusqu'à demain
Posté par Octabrain . Évalué à 2.
Tiré du blogpost :
Donc ce que ce "brevet" couvre :
(c'est du C)C'est une blague ? T'en as beaucoup d'autres des brevets aussi "novateurs" ?
[^] # Re: Je tiendrai jusqu'à demain
Posté par houra . Évalué à 2.
ouais, c'est ce que je dis, Vala est juste un compilateur capable de compiler un programme construit selon un langage qui ressemble à C# en langage machine . Et mis à part le fait de toucher au contenu du développeur lui-même , il n'y a qu'une coquille vide. Rien.
D'ailleurs les brevets couvrant les objets, va falloir qu'on m'explique en quoi un binaire compilé par ValaC puis par GCC enfreint un brevet sur dotnet.
Et en quoi un développeur qui utilise vala lorsqu'il écrit, peut utiliser un outil qui enfreint ce brevet ?
Alors que Mono, c'est une implémentation libre , par Manu de dotnet.
Et le fait de se réjouir du rachat de Nokia par Microsoft comme il l'a fait dans son blog m'incite à ne pas regarder ce qu'il produit.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 0.
Non, ton n'exemple n'est pas bon, et le brevet ne couvre pas les classiques pointeurs de fonction. Les "delegates" en C# pointent vers une méthode dans le contexte d'un objet particulier.
Concrêtement si je fais en C# :
button1.Click += OnClickMethod;
où OnClickMethod est une méthode d'instance (et non pas une fonction "static" ou "globale" comme ton exemple en C). Le compilateur rattache automatiquement l'instance de l'objet qui fait l'action pour former un couple instance+pointeur_methode.
Tu as voulu copier l'exemple Vala et le traduire en C, en fait il fallait plutôt que t'essai de traduire le 2ème exemple. Forcement t'aurais pas réussi sans faire une référence explicite à une structure pour simuler un objet, là où le brevet concerne justement une référencement implicite et automatique.
Après je vais pas dire que c'est une révolution ou même une invention, juste une petite évolution qui permet à C# d'avoir une façon simple de passer une méthode d'instance en tant qu'objet. (Exemple : abonnement/désabonnement à un événement).
[^] # Re: Je tiendrai jusqu'à demain
Posté par Octabrain . Évalué à 3.
Ok ok, tu veux parler de ça ?
(Oui, je suis allé chercher python 1.2 (1995 selon wikipedia, déjà antérieur au brevet), je n'ai pas essayé avec python 1.0 mais je soupçonne que ça fonctionnait déjà)
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 1.
Non plus, tu explicites toujours l'objet dans l'expression a.m (a est la référence explicite)
[^] # Re: Je tiendrai jusqu'à demain
Posté par Octabrain . Évalué à 2.
Alors, je ne comprends toujours pas, dans le deuxième exemple Vala, je lis "DelegateType d1 = foo.f1;" donc bien une référence à "foo". Dans ton exemple C#, où se trouve la "OnClickMethod" ? Dans la classe où la ligne que tu donnes se trouve ?
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 1.
Effectivement le OnClickMethod se trouve dans la même classe que la ligne que je donne.
Après vérification, la différence avec ton exemple Python n'est pas la référence implicite mais dans la notion même de Delegate : c'est une signature de méthode (d'instance ou non). Forcement en Python une signature n'a aucun sens vu que y'a pas de typage fort et statique par le compilateur.
Le titre du brevet est assez explicite :
Il n'y a ce besoin de sécurité de type en Python, donc pas de notion de Delegate comme en C# ou en Vala.
[^] # Re: Je tiendrai jusqu'à demain
Posté par Octabrain . Évalué à 3.
En bref, ce brevet est ridicule, le passage de contexte, on savait le faire (cf. python), et le type-safe on savait le faire (cf. C)...
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 0.
Bref, dans tous les cas, juger le brevet "ridicule" ne changera rien au fait que tu n'es pas trouvé d'antériorité pour un "type-safe delegation of object" tel que détaillé dans le brevet. Et puis tu n'as pris que le premier brevet cité : on est pas juriste, ni l'un ni l'autre, mais si on en revient à la discussion initiale, il est clair que des langages comme Vala ou Java implémentent des "fonctionnalités" issues de C#, et qu'à ce titre ces langages sont au moins aussi dangereux que l'implémentation C# de Mono, pour ne pas dire plus.
[^] # Re: Je tiendrai jusqu'à demain
Posté par Octabrain . Évalué à 2.
C'est un pléonasme, le cast (quel que soit le langage) n'a jamais servi à rien d'autre qu'à permettre au développeur de rendre le compilateur content, soit en lui forçant la main (cast C), soit en lui disant de la fermer et de ne vérifier qu'au runtime (dynamic_cast, casts Java). Si tu veux être type-safe, tu n'utilises pas de casts, et ça tombe bien, c'est possible pour les pointeurs de fonctions en C.
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à -1.
Ok, changeons de troll et partons sur le côté type-safe de C :)
Moi j'entend par type-safe le fait de t'empêcher de faire des cast idiots justement. En C tu peux passer l'adresse une zone mémoire contenant de la donnée en tant pointeur de fonction... Une hérésie source de bugs/failles que C# ne t'autorise pas : impossible de transformer de la donnée en code exécutable, même avec un cast, et dès la compilation.
[^] # Re: Je tiendrai jusqu'à demain
Posté par Batchyx . Évalué à 3.
En gros, si j'ai bien compris, c'est la même chose que boost::bind en C++ ? Sachant que boost::bind n'est qu'une généralisation de fonctions de la STL (bind1st, mem_fun...), qui datent de 1994 ?
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 1.
Ce n'est pas du tout la même chose : Bind est une "fonction" là où un Delegate est un "type", type qui défini une méthode (d'instance ou non).
[^] # Re: Je tiendrai jusqu'à demain
Posté par Batchyx . Évalué à 2.
Dans le cas de boost::bind, le type c'est boost::function<int(char,float)> (fonction prenant un char et un float et retournant un int). boost::bind permet de généraliser et d'utiliser par exemple une méthode de tel objet, ou une fonction à trois paramètres en disant que le deuxième est NULL, ou une combinaison des deux. Je ne vois pas en quoi ça n'a "rien à voir".
Ou si on utilise que la STL, on est limité au méthodes ne prenant qu'un argument, et le type est template <T> binder1st<T,Argument>, il faut juste effacer le type T avec du type erasure.
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 1.
Changeons de méthode parcque là on va pas y arriver.
Traduit en C++ avec boost le code C# suivant (suffisament explicite je pense) :
[^] # Re: Je tiendrai jusqu'à demain
Posté par Batchyx . Évalué à 3.
Oui, et ensuite ?
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 1.
il te faut écrire :
là où moi j'écris simplement :
Différences :
tu passes un pointeur de fonction en paramètre : un pointeur foireux et tu exploses méthode print.
tu es obligé de passer des trucs sans intérêts que le compilateur C# déduit automatiquement : l'objet cible (this dans ton exemple) et les paramètres (on s'en cogne s'est l'appelé qui les remplis.
t'as variante inline est beaucoup trop récente pour servir de prior-art ;)
en l'occurence boost::bind n'apporte rien par rapport au simple typedef en C pour déclarer une signature de méthode : même inconvénients, une syntaxe toujours aussi lourde pour l'appelant et toujours aussi peut type-safe.
[^] # Re: Je tiendrai jusqu'à demain
Posté par Batchyx . Évalué à 3.
[^] # Re: Je tiendrai jusqu'à demain
Posté par TImaniac (site web personnel) . Évalué à 1.
Cet exemple précis n'est pas foireux. Mais en tant que rédacteur de la méthode Print, je n'ai aucune garantie que l'appelant fasse comme toi : on peut imaginer qu'il fasse un gros cast bien crade pour obtenir un pointeur de fonction, on peut imaginer qu'il utilise même pas la fonction bind, bref c'est pas type-safe. Il peut aussi se louper pour le 2ème paramètre de bind, re big explosion.
D'où le brevet déposé : fournir un mécanisme type-safe, directement intégré dans le langage, qui empêche ce genre de problème.
C'est sans intérêt par rapport au brevet qui nous intéresse. Nul doute que Bind a d'autres intérêts.
http://www.google.com/patents/about?id=iT-ZAAAAEBAJ
De rien.
# Closed???
Posté par case42 (site web personnel) . Évalué à 2.
Si il y a vraiment du code GPL dans Mono (comme c'est dit dans la dépêche), comment on peut faire une dll closed source en ce basant dessus (comme c'est dit dans la dépêche) ?
Qu'en pense http://gpl-violations.org/ ?
[^] # Re: Closed???
Posté par TImaniac (site web personnel) . Évalué à 7.
Parcque c'est les mêmes auteurs qui font Mono et MonoDroid. Ils ont le droit de publier leur code sous toutes les licences qu'ils veulent, MIT/GPL/Proprio.
La question se serait effectivement posée différement si MonoDroid était réalisé par un tiers.
[^] # Re: Closed???
Posté par tanguy_k (site web personnel) . Évalué à 3.
Même pas, la licence MIT (concerne les librairies et le compilo) est quasi-identique a la BSD donc tu fais ce que tu veux.
Oui et non, il y a des contributeurs externe a Novell sur Mono...
Mais Novell demande l'assignement du copyright pour certaines parties de Mono (de plus en plus désuet j'imagine avec le basculement vers la licence MIT).
# L'eternelle question
Posté par manifesto . Évalué à -2.
Euh mais en vrai ça sert à quoi mono.
Si il y a une chose qui ne manque pas sous linux ce sont les langages de programmation.
Certes il y a des trucs genre banshee qui utilise ce truc mais est ce que vous avez déjà dans votre vie professionnelle eu des projets/appli qui tournent sous mono ? Si on veux faire du .net autant prendre carrément du windows non ? Avec mono on n'est on pas de toute façon limité par rapport à ce que l'on a sous windows ? Ca me semble vraiment douteux comme solution et de plus c'est un piège trop flagrant (Embrace, extend and extinguish).
[^] # Re: L'eternelle question
Posté par zebra3 . Évalué à 3.
C'est vrai, ça.
À quoi sert Ruby, puisqu'on a Python ?
À quoi sert Python, puisqu'on a Perl ?
À quoi sert Perl, puisqu'on a C ?
À quoi sert C, puiqu'on a l'assembleur ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: L'eternelle question
Posté par pasScott pasForstall . Évalué à -2.
Et a quoi ca sert d'avoir android et linux puisqu'on a deja ios et macos?
Et, oh, c'est 'dredi, hein!
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: L'eternelle question
Posté par TImaniac (site web personnel) . Évalué à 4.
oui.
Ben non justement.
Non, on a même des choses non dispo sous Windows.
En l'occurence MonoDroid sert à avoir un socle technique commun pour iPhone/Android/WindowsPhone.
[^] # Re: L'eternelle question
Posté par Albert_ . Évalué à 0.
En l'occurence MonoDroid sert à avoir un socle technique commun pour iPhone/Android/WindowsPhone.
Ah ah ah la vielle excuse a la con de Elop (Nokia).
[^] # Re: L'eternelle question
Posté par zebra3 . Évalué à 4.
Bah si tu as un autre moyen, n'hésite pas à partager. Ça aidera sûrement TImaniac dans son boulot.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: L'eternelle question
Posté par Albert_ . Évalué à 0.
Je m'en moque d'aider la vie de Timaniac, pbpg etc
Je suis plus concerne par ma liberte a moi mais sinon Qt aurait tres bien pu faire l'affaire sauf que .... microtruc a interdit l'installation sur son bousin. Tiens ne serait ce pas pour tenter de forcer les gens a utiliser leur bousin a eux tout bourres de leur brevet a eux?
[^] # Re: L'eternelle question
Posté par barmic . Évalué à 1.
C'est loin d'être aussi poussé chez Qt. Avec Mono/.Net, c'est comme en Java, tu compile une fois tu execute partout => pas de cross-compilation.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: L'eternelle question
Posté par Eric P. . Évalué à 4.
D'apres l'auteur du journal, avec Mono l'API pour l'interface graphique etant propre a chaque plate-forme, il faut meme recoder l'interface graphique pour chaque plate-forme avant de la recompiler...
Autant dire que ca semble bien plus couteux qu'avec Qt, qui a une API unique pour toutes les plateformes, utilisant elle-meme les API natives du systeme.
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: L'eternelle question
Posté par TImaniac (site web personnel) . Évalué à 0.
C'est juste pas les mêmes objectifs : l'intérêt n'est surtout pas d'avoir la même IHM partout, mais d'avoir une IHM dédiée parfaitement intégrée sur toutes les plateformes.
Si c'est pour faire la même interface partout, autant faire du web mobile.
[^] # Re: L'eternelle question
Posté par pasScott pasForstall . Évalué à -1.
tant mieux s'il faut reecrire l'interface!!
Ca eviteras d'avoir des interfaces pourries concues pour un point'n'click sur un telephone tactile ou autres affreusetes que les frameworks "portables" generent.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: L'eternelle question
Posté par gouttegd . Évalué à 2.
Non, tu exécutes là où un environnement d’exécution est disponible, ce qui est très différent de « partout ».
Je n’ai rien contre Java (enfin, si, mais c’est pas le jour), mais le slogan mensonger « write once, run everywhere » me fait voir rouge depuis que je n’ai pas réussi à trouver une JVM qui fonctionne sur un GNU/Linux sur Mac PPC.
[^] # Re: L'eternelle question
Posté par pasScott pasForstall . Évalué à -3.
Clair que Qt sur iphone, ca doit poutrer copieux.
De meme l'utilisation a travers java pour android, ca doit etre super sexy.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: L'eternelle question
Posté par pasScott pasForstall . Évalué à 0.
Meme si je comprends bien l'idee derriere, a savoir un core ecrit une fois et ensuite interface avec une gui native, je me pose des questions sur l'interet de la chose.
D'une part, une appli mobile c'est generalement essentiellement de la gui quand meme. Ya bien evidemment des applis qui ont domaine complique necessitant un reel effort d'ingenierie (les jeux notamment?) mais ca reste souvent "choppes ton json sur le serveur, assembles le, donne ca a manger a l'interface et si le product manager s'est lache, persiste le sur disque.".
Je me demande quel est le gain compare aux inconvenients, le plus gros etant le fait de melanger plusieurs langages et de se taper un compilation des plus relou a chaque modif du core, et donc de jongler entre ide et chaines de compiles pour ajouter un pauvre champ a une classe.
Le deuxieme inconvenient, on perd (enfin, j'imagine) la possibilite d'utiliser des api natives pourtant bien utiles.
iOS et GCD pour les traitements asynchrones/en arriere plan, c'est foutrement efficace. CoreData est bien pratique aussi. J'imagine qu'android a ses specificites qu'aucun dev android ne veut lacher.
Quid de trucs tres tres specifiques a la platforme, genre api geo localisation, gyroscope, camera et tout le tralala?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: L'eternelle question
Posté par TImaniac (site web personnel) . Évalué à 3.
Ca fait déjà la moitié qui est indépendant du toolkit graphique. C'est déjà ca.
Justement c'est l'inverse : un projet multi-OS mobile "classique" conduit à faire de l'objective-C, du Java, du C#. Mono propose un unique langage pour toutes les plateformes.
Pas plus relou qu'avec un projet classique multi-OS mobile.
T'imagine justement très mal : ils ont justement fait le choix de ne pas avoir une API qui soit un dénominateur commun, mais de créer des bindings pour l'intégralité des API de la plateforme cible. L'objectif est clairement de ne rien perdre en terme de fonctionnel.
[^] # Re: L'eternelle question
Posté par pasScott pasForstall . Évalué à -1.
Plutot 15-20%, a la louche ;)
Donc en fait, tu fait tout en mono, c'est ca? Ce que j'en avais comprit, c'est que mono pondait un lib statique avec le core, et qu'apres il restait plus qu'a linker avec le projet natif.
Comment vous contournez la limitation de l'app store ou l'appli doit avoir ete ecrite en c/c++/objc?
Mais du coup, les auteurs se sont tapes l'integralite des bindings vers cocoa par exemple?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: L'eternelle question
Posté par barmic . Évalué à 4.
Le seul truc c'est que mono n'est pas un langage. C'est une plateforme au dessus tu peut utiliser pleins de langages C#, F#, etc... et ils peuvent tous communiquer entre eux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: L'eternelle question
Posté par monde_de_merde . Évalué à 1.
J'ai la même chose à la maison, ça s'appelle Linux, il y a plein de langage qui communique entre eux dessus ! Pipe, socket et tout.
De quoi j'ai pas compris et c'est pas pareil ?
[^] # Re: L'eternelle question
Posté par Dr BG . Évalué à 2.
Et comment puis-je utiliser une bibliothèque python en ocaml (par exemple) ?
[^] # Re: L'eternelle question
Posté par Maclag . Évalué à 5.
Avec PyCaml.
Sinon via le module Unix ou Sys, suivant ce que tu veux faire exactement.
De rien.
[^] # Re: L'eternelle question
Posté par Octabrain . Évalué à 1.
Pourquoi est-ce que tous les langages auraient le devoir d'interagir entre eux ? Ils peuvent avoir des concepts tellement différents que la couche d'adaptation sera non négligeable.
Comment un langage sans classes (C) pourrait appeler "facilement" des méthodes d'un langage à classes uniquement (Java) ? Comment faire interagir des langages à évaluation lazy et des langages non-lazy ? Etc...
[^] # Re: L'eternelle question
Posté par Octabrain . Évalué à 1.
Par "couche d'adaptation", j'entends le prix que le dev qui voudra faire communiquer 2 langages, devra payer dans son code : l'overhead en terme de code et de syntaxe, pas l'overhead à l'exécution.
Si l'on fait une bibliothèque dans un langage et qu'on vise l'utilisation dans un autre langage précis, on pourra obtenir quelque chose de quasi-natif en terme de code, par exemple pas mal de la lib standard de python est implémentée en C, et cette lib s'utilise très facilement. (Si par contre on a une lib C, conçue pour du C, et qu'on veut l'utiliser en Python, il faudra un wrapper, un peu chiant à écrire mais il y a pire). Si l'on veut que la lib soit utilisable dans plein de langages, même avec ce magnifique "machin" qu'est .net, je doute que l'interaction entre différents langages supportés (sans parler de langages vraiment très différents) soit gratuite en terme de code.
[^] # Re: L'eternelle question
Posté par barmic . Évalué à 7.
Et c'est les même qui crient comme des gorets quand on leur parle de XML ou JSON.
Les IPC c'est génial, mais pouvoir garder la sémantiques objets des données sans se farcir une sérialisation XMl ou JSON, c'est pas désagréable non plus.
Faut arrêter de cracher sur une techno sans y avoir jamais touché et dire que tu as déjà. Oui tu as déjà tout. Tu as un interpréteur sur ta machine qui est turing complet ? He ben potentiellement tout les programmes possibles tu les as sur ta machine, c'est pas beau ça ?
La différence c'est l'effort que tu dois produire pour obtenir un résultat et le goùut de chacun. Tu préfère utiliser des IPC ? Génial ! Personne ne t'oblige à changer tes habitudes. Pouvoir avoir des interactions fortement couplet entre deux code en deux langages différents ça plaît à certains (comme c'est fait avec swig, JNI ou autre), sauf que là c'est encore plus simple à mettre en place et tu le fait de la même façon pour tout les langages de la plateforme (comme avec Java, Scala et Groovy).
Au passage, la commutation de contexte faut pas en abuser si tu veut garder tes perfomances de ouf dans ton programme en C (que c'est même pour ça que les langages de haut niveau c'est de la merde).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: L'eternelle question
Posté par monde_de_merde . Évalué à 1.
À l'occasion je me souviendrait de crier comme un gorets (sic) quand on me parlera de JSON ou de XML, j'aime pas décevoir les gens même si je sais pas bien quand est ce que je me suis insurgé à ce propos. Et j'ai pas non plus cracher sur Mono (ou alors on parle pas la même langue).
My point, comme dise non voisin d'outre-manche, c'est que le fait d’être une plateforme n'est en rien un avantage pour Mono par rapport à l'existant, et que déjà, être une "plateforme", ça veut un peu tout dire. C'est du bullshit marketing quoi.
Mais bon je te laisse crier comme un goret que vraiment le monde est top injuste, parce que oui, le monde est vraiment trop injuste.
[^] # Re: L'eternelle question
Posté par barmic . Évalué à 1.
Oh ! Comme je suis désolé de t'avoir vexé. Ce que j'aime pas c'est quand les gens viennent avec des préjugés et affirme des choses sans avoir étudié plus que ça de quoi il en retournait.
Merci de m'apprendre que les mots n'ont pas de sens hors de leur contexte. Là j'ai expliqué que je voulais dire par là qu'il n'est pas lié à un langage précis mais au contraire prévu pour faire communiquer et exécuter différent langage. Si tu veut que je parle de manière plus simple .Net, c'est : une série de langages + un ensemble de bibliothèque + une machine virtuelle + une série d'outils, tous conçu pour travailler ensemble et donc cohérent entre eux.
C'est moi ou tu ne savais pas quoi dire pour réutiliser mon expression ? Parce que là je ne vois vraiment pas ce que tu cherche à dire (peut être que tu regarde Dr House en même temps :) ).
Bref tout ça pour te dire que faire communiquer des langages entre eux c'est important. Unix a commencé avec tout pleins d'IPC et quelque chose de simple : la sérialisation. On écris dans un format textuel dans un pipe, une socket ou je ne sais quoi et derrière on lis ce que l'autre programme a écris. C'est génial ! Mais quand on veut faire des programmes qui utilisent le paradigme objet, on se retrouve à faire des choses très rébarbatives. Une possibilité est arrivé après c'est d'utiliser des bibliothèques qui vont s'occuper de la serialisation et de la desarialisation d'objets, ça c'est génial, mais généralement pour être portable il faut utiliser XML ou JSON qui ajoutent un temps important dans le "parsage" de ce qui arrive. Là dessus .Net propose une solution qui s'appuie sur une machine virtuelle et l'envoie d'objet directe en binaire.
Donc voila j'ai pas dis que les IPC ça pue, je te montre juste une fonctionnalités qui est bien différente de "ce que tu as" et qui est intéressant (même si c'est estampillé "mal absolue").
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: L'eternelle question
Posté par Albert_ . Évalué à 2.
C'est bien tu as cite a peu pres les deux seuls langage encore supporte par .Net et tu ne cites pas, curieusement, les ironpython et ironruby. Peut etre que ceux ci ont ete abandonne par Microtruc?
[^] # Re: L'eternelle question
Posté par barmic . Évalué à 2.
Je peux citer en plus le VisualBasic, pour le reste très franchement je ne sais pas la liste de langages encore supportés ou non.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: L'eternelle question
Posté par Albert_ . Évalué à 2.
J'etais ironique lorsque je posais la question. Apres avoir fait tout un buzz (pour reprendre les mots a la mode) sur le cote multilangage de .Net les langages que microtruc ne controlent pas sont degage du framework. Alors oui officiellement c'est de Icaza qui reprend le truc mais bon entre mono/moonlight (qui est encore et toujours 2 versions en retard)/ironpython/ironruby/monodroid/monoiphone etc ils ont enormement de choses a maintenir et a developper alors qu'ils sont tres peu (en comparaison des equipes de microtruc qui n'ont qu'une version reduite de .Net et des trucs associes et tres peu de plateformes a supportes.
Donc il ne faut pas trop rever sur le developpement de mono et des trucs associes. Cela va etre de plus en plus a la bourre comme l'est moonlight (toujours incapable de permettre d'utiliser netflix il me semble).
[^] # Re: L'eternelle question
Posté par yellowiscool . Évalué à 2.
Un autre point important à prendre en compte, est que C# et .Net sont des outils très intéressant pour le développement d'applications.
Le langage est agréable et efficace, l'API est complète et plutôt bien fichue, et les outils sont de bonne qualité. Il y a le risque des brevets, qui est inexistant pour un projet qui reste en france, mais pourquoi se priver de quelque chose qui est bien ?
Surtout que le concurrent direct est Java, produit par Oracle.
Envoyé depuis mon lapin.
[^] # Re: L'eternelle question
Posté par Zenitram (site web personnel) . Évalué à 3.
Bref, C#/Mono, c'est mignon pour des projets à court termes, mais je ne mettrais pas mes oeufs dans un truc dont je ne connais pas le support dans 10 ans... (oui, il y a des projets informatiques qui ont pour cible dans 10 ans)
[^] # Re: L'eternelle question
Posté par tanguy_k (site web personnel) . Évalué à 6.
et c'est pas les quelques dev' de Linux qui vont pouvoir développer un OS
Pour info les devs de Mono ont implémenté tout .NET + ajouté pas mal de librairies et applications dont Gtk#, MonoDevelop (IDE), Moonlight, MonoDroid, MonoTouch, MonoMac, Gecko#, WebKit#...
[^] # Re: L'eternelle question
Posté par TImaniac (site web personnel) . Évalué à 5.
Tu critiques le problème de la pérénité des solutions proprio avec 1 seule implémentation. Mono n'est pas proprio.
Si aujourd'hui tu choisis C#, t'as Mono, qui reste un logiciel libre avec une forte communauté derrière : la pérénité semble au moins similaire à une plateforme comme Ruby ou Python par exemple. Bref, Microsoft peut changer de stratégie, il ne se passera pas du tout la même chose qu'avec J# ou VB6 pour les utilisateurs actuels.
[^] # Re: L'eternelle question
Posté par Maclag . Évalué à 5.
Tu vas quand même avoir du mal à me faire croire que tu aurais tenu le même discours avant que MS ne les abandonnent: "MS va abandonner le J# et tous les développeurs qui travaillaient dessus vont l'avoir dans l'os!"
Si le même fil avait eu lieu à l'époque, excuse-moi pour le procès d'intention, mais je suis à peu près certain que tu aurais également expliqué en quoi J# et VB6 sont des situations complètement différentes et qu'il n'y a rien à craindre.
Bref: quand on créé un tel antécédent, il ne faut pas s'étonner que le niveau de confiance en prenne un coup!
[^] # Re: L'eternelle question
Posté par TImaniac (site web personnel) . Évalué à 4.
Et pourquoi ? Je suis un fervent défenseur des logiciels libres (c'est pourquoi je traîne par là), et c'est pourquoi j'ai toujours soigneusement évité VB6 ou J#.
Justement, Mono a pris les devant en créant une version libre, et on devient indépendant de la stratégie de Microsoft. D'ailleurs la FSF a eu la même idée en lançant un projet similaire. Bon ils ont fédérés personne vu que tout le monde était sur Mono, mais l'intention y était.
[^] # Re: L'eternelle question
Posté par yellowiscool . Évalué à 3.
On est pas obligé de coder des choses pour le monde entier et pour dix ans. Une application peux très bien être utilisée uniquement dans un cadre restreint.
Et on ne fait pas tous de l'informatique dans des multinationales. Imaginons que je développe une application libre en C#. Si les utilisateurs états-uniens ne peuvent pas l'utiliser légalement, j'en ai rien à faire. C'est leur problème, et je ne pense pas qu'ils se gêneront beaucoup à l'utiliser malgré l’illégalité…
Pour J#, VB6, et certainement beaucoup d'autres, il me semble normal que certaines technologies soient abandonnées par une entreprise telle que Microsoft. Il y a toujours une part de recherche et développement qui mène à rien, même avec des langages de programmation.
Ensuite, dire que Microsoft pourrait arrêter le support de C# dans moins de 10 ans, c'est comme dire que Oracle pourrait arrêter le support de Java dans moins de 10 ans.
Envoyé depuis mon lapin.
[^] # Re: L'eternelle question
Posté par Gniarf . Évalué à 5.
étant donné que Java (le langage) et C# sont vraiment très très similaires,
étant donné que Java (la JVM, le bazar autour, y compris d'autres langages) est très très similaire à .NET et le bazar autour,
il faudrait surtout se demander, maintenant qu'on a un peu de recul, ce qui a donc bien pu merder avec Java, enfin Sun, pour en arriver là.
[^] # Re: L'eternelle question
Posté par TImaniac (site web personnel) . Évalué à 4.
Il y a plusieurs éléments je penses :
[^] # Re: L'eternelle question
Posté par pasScott pasForstall . Évalué à -4.
Allez, je te met dans la confidence. C'est a cause de bob. Il est con bob! Il a lance l'idee comme ca, a une des premieres editions de Java One, ya un con de journaliste qui y a cru et la sauce a prit. En vrai ca veut rien dire et c'est juste un code pour se reconnaitre entre nous.
Les JSR pair c'est pour ceux qui ont compris la vanne, les impairs c'est les autres (generalement, ils portent des costards eux).
Et AWT alors? Non mais!
Certes, mais vu la cible, c'est pas un mal. Des closures dans un projet entreprise ecrit a moitie par un presta ukrainien alcoolique et un autre presta indien qui parle pas vraiment anglais mais qui trouve que c'est vachement mieux de taper au clavier que de vendre des grigris au touriste, perso ca me fait peur.
Je prefere de tres tres loin limiter le langage, ca reste simple, c'est facile a relire (meme quand les commentaires sont en sanskrit sud oriental) et de toutes facons, ces features sexy sont loin d'etre primordiales dans la plupart des projets ou Java est un bon candidat.
Apres c'est sur que cote client, je fuit, mais beaucoup ne se rendent pas compte que ce reproche fait a Java est en fait en partie responsable de son succes.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: L'eternelle question
Posté par barmic . Évalué à 3.
Je suis pas d'accord sur tout. Les JSR c'est génial, si je ne me trompe pas c'est plus ou moins équivalent aux PEP de python. C'est une volonté de standardisation et de définitions précise de normes.
Par contre je suis d'accord pour le nivellement par le bas. .Net se fout plus ou moins de la compatibilité (tant que ça marche sous Windows).
En critique à Java, je pense que Java n'a pas était pensé comme une plateforme à la base et Scala et groovy n'ont pas le même support que Java.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Mono et ses petits problemes...
Posté par tanguy_k (site web personnel) . Évalué à 3.
Je viens de passer hier soir a bidouiller un peu Mono sous Windows et il y a pas mal de trucs qui me déplaisent...
[^] # Re: Mono et ses petits problemes...
Posté par yellowiscool . Évalué à 4.
En même temps, ça doit intéresser peu de monde d'utiliser Mono sur windows.
Envoyé depuis mon lapin.
# quel intérêt ?
Posté par eemm . Évalué à 1.
Zut, j'ai loupé le sujet!
J'apporte quand même mon expérience en tant que dev Android...
Quand on voit que l'on doit faire appel à une classe JAVA pour lancer la Map ... https://github.com/mono/monodroid-samples/blob/master/GoogleMaps/Activity1.cs
=> Les API ne seront jamais complètes ni à jour. Elles seront buggées, non performantes, instables.
Si on prend ce code là : https://github.com/conceptdev/RestaurantGuide/blob/master/RestGuide_Android/Activities/MainListAdapter.cs
Franchement vu les différences minimes qu'il y a, à coder en JAVA, je comprends vraiment pas l'intérêt (A part pour Novell, qui veut vendre son produit)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.