TImaniac a écrit 6420 commentaires

L'argument de départ était qu'une VM c'est pratique, parce qu'on est facilement multiplateforme tout en ayant une forme de code assez bas niveau. Ce qui permet de "cacher" les sources.
Non, l'argument est de dire qu'une VM a pour principal objectif de faciliter le déploiement de binaire, problématique lié au proprio avec son besoin de distribuer des binaires; et dire que le libre n'a donc pas besoin de VM puisqu'on distribue des sources.

Moi je montre 2 choses :
- le bytecode permet de retrouver une bonne partie du code source, ce qui enmerde certains industriels, d'où le succès des obfuscateurs de bytecode.
Avant un distributeur de soft proporio proposait plusieurs binaires si plusieurs architectures en gardant le code source caché, maintenant il n'en déploie plus qu'un, au prix d'un code source moins caché (bytecode), à moins d'utiliser un soft pour le rendre plus obscure.
- la problématique de déploiement de binaire est également présente dans le libre, c'est la forme la plus généralement utilisée par les grandes distributions linux. Techniquement, ce qui est intéressant pour le proprio l'est aussi pour le libre, ce sont des atouts "techniques", pas politiques.

j'ai quand même du mal à croire qu'il n'y a pas un "gentil dictateur"
Python a son gentil dictateur : http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life

Ben la logique est simple : le bytecode ne va pas dans le sens de "cacher" du code propriétaire, au contraire (ce que j'essai de montrer). La preuve, les softs d'obfusction ont dû débarqués pour colmater en partie la brèche.

Dans la "recherche" ?
Ils cherchent où ? sur google ?

http://www.google.fr/search?hl=fr&q=.net+obfuscator&(...)

http://www.google.fr/search?hl=fr&q=java+obfuscator&(...)

Ca existe depuis des années.

Alors arrêtons d'utiliser tous ce qui est cité sur cette page, la problématique est là même :
http://www-03.ibm.com/linux/ossstds/isplist.html
Y'a des petits trucs intéressants pourtant, mais bon le développement ouvert de LL avec ces standards n'est pas possible : OpenDocument, XML, DITA, UDDI, SOAP, XQuery, XSL, etc.

J'ai python, j'ai QT (ou gtk), pourquoi devrais-je utiliser Mono ? Cela m'apportera il quelque chose ?
Apprend à lire, c'est argumenté plus haut.

Je veux un langage relativement performant parcque mon application fait un minimum de traitement : C# est plus rapide que Python.

Je veux une documentation complète : C# est mieux documenté que Python.

Je veux un langage dont la pérénité est assurée : du code C# 1 est toujours compatible avec C# 3, le langage est standardisé.

Je veux un langage "sûr" avec typage statique qui me permette de faire du refactoring sans devoir prier pour que mes hypothétiques tests unitaires couvrent bien l'ensemble du fonctionnel : C# est bien meilleur que Python.

Je veux un langage avec des fonctionnalités évoluées de requête parcque je manipule beaucoup de données, je prends C# 3 parcqu'il a LINQ que Python n'a pas.

Je veux un langage qui me permette à l'occasion d'avoir de bonnes performances sans me taper du code natif : je prends C# parcque je pourrais ponctuellement utiliser les pointeurs.

Je veux un langage qui me permette d'étendre des types sans utiliser tout en gardant les avantages du typage statique : je prends C# avec les méthodes d'extensions.

Je veux un langage qui me produit des binaires compatibles avec d'autres langages simplement : je prends C# qui me permet de produire des composants réutilisables en VB.NET, en C++/CLI, en IronPython, en Boo.

C'est le problème quand la documentation est plus complète, il faut ajouter des niveaux de classement supplémentaire.
Regarde la doc de split :
http://java.sun.com/javase/6/docs/api/java/lang/String.html#(...)
http://msdn.microsoft.com/fr-fr/library/b873y76a.aspx
Tu vois la doc de MS sur une seule page comme le fait Sun ?
Regarde la doc de Python sur la même fonction, tu verras que y'a même pas besoin de sommaire tellement c'est succinct :
http://docs.python.org/library/stdtypes.html

A peu prêt aussi osé que de comparer le risque qu'il y a à utiliser F-Spot par rapport au fait de jouer avec un bûcher.

Sauf que pour beaucoup d'applications, ce que cherche un développeur c'est pas la peformance, c'est le meilleur compromis entre performance et pleins d'autres trucs :
- simplicité
- sécurité
- compatibilité
- popularité
- support
- fun
- etc.

Si nos ancètre n'avaient jamais eu les couilles de jouer avec le feu, je sais pas où en serait la civilisation aujourd'hui.

Python[...] il est évident que tu a besoin d'une VM.
C# ou de Java[...] tu n'a pas fondamentalement besoin d'une VM.
Tu peux compiler du Python.
Tu peux interpréter du C# ou du Java (ce dernier a d'ailleur été conçu dans cet optique initialement).

Je pense que ça vient en partie d'un raisonnement qui a court dans le monde du logiciel propriétaire et qui est "comment faire tourner mon beau binaire chez le maximum de clients".
C'est une problématique qui existe aussi dans le logiciel libre faut pas croire. La plupart des distributions Linux populaires sont fournies sous la forme de binaires.
Et c'est sûrement pas une partie de plaisir de fournir des ressources supplémentaires (temps, CPU, espace disque) afin de compiler les softs pour différentes architectures (ex : Debian).
Sans parler de l'embarqué.
Avoir accès aux sources ne veut pas dire que c'est le moyen numéro 1 de distribuer un logiciel libre.

Comparons alors, prenons la classe string, en Python, Qt et .NET :
http://docs.python.org/library/stdtypes.html#string-methods
http://doc.trolltech.com/4.5/qstring.html
http://msdn.microsoft.com/fr-fr/library/system.string_member(...) (faut cliquer sur chaque méthode pour avoir les exemples et tout). Et en français s'il te plaît.

Y'a un 3ème mode pour mono/.NET/GCJ :
code source -> bytecode -> code natif -> exécution.

Pas plus qu'un backend de compilateur avec un langage inteermédiaire (llvm ?)
Forcement, c'est une VM.

endian/big endian ne pose problème qu'avec les layout de fichier.
Oui, c'est un problème. http://www.ibm.com/developerworks/aix/library/au-endianc/ind(...)

Si tes threads n'étaient géré que par la VM tu aurais de gros soucis de perf....
Et ? Je parle d'abstraction, dessous y'a du code natif et les threads de l'OS, c'est bien le but.

Faire abstraction de la machine, c'est aussi fournir des services qui ne sont pas offerts en natif : introspection, gestionnaire de mémoire, protection contre les débordements, contrôle fin des droits d'exécution (sandboxing & co), interopérabilité entre les langages de programmation, gestion des exceptions.
Une VM facilite aussi la création de nouveaux langages en proposant de base tous ces outils.
C'est aussi faire abstraction des incompatibilités de la machine qui peut casser mon soft en C recompilé : 32 vs 64 bits, litle-big endian, etc.
C'est aussi faire abstraction des incompatibilités de l'OS : gestion des threads notamment.
C'est aussi utile dans des situations ou recompiler n'est pas une option : déployer une applet web par exemple ou bêtement exécuter du javascript sans utiliser d'interpréteur.

Le coup du "c'est nécessaire pour le proprio qui cache les sources" est un mauvais argument, bien au contraire : ce type de VM a une sémantique bien plus proche du langage utilisé dans le code source : un coup de décompilateur permet de retrouver le code source dans un format proche de l'original (sans les commentaires forcement).

Un peu comme IBM envers OpenDocument & co :
http://www-03.ibm.com/linux/ossstds/isplist.html
""Covered Implementations" are those specific portions of a product that implement and comply with a Covered Specification and are included in a fully compliant implementation of that Covered Specification

Parcque le runtime offre c'est un bon compromis niveau performance / fonctionnalité comparé à C/C++ ou Python/Ruby.
Parcque le support multi-langages est bien intégré (IronPython, Boo & co)
Parcque le langage (C# 3) est bien plus cool et avancé que Java (LINQ, expressions lambda, event, méthodes d'extensions, etc.)
Parcqu'on peut réutiliser ses compétences Windows.
Parcque la compatibilité avec Microsoft assure une large documentation et l'accès à de nombreux outils et bibliothèques tierces, bref de quoi séduire les développeurs.
Parcque mono intègre tout ce qui faut outofthebox pour développer une application Gnome.
Parcque la communauté de developpeurs est très réactive, notamment face aux bugs.

Evidemment tu trouveras beaucoup de ces atouts ailleurs, mais tout réunis ca fait une plateforme sexy.

http://www.ikvm.net/

Ben ca dépend des SSII. Chez nous c'est pas 80% en tout cas.

Tu connais beaucoup de boîte d'intérim qui réalise des projets au forfait dans leurs locaux ?

Simple et ca marche :)
Encore merci !

oui c'est bien un emu10k1.
Je vais regarder asfxload et aconnect.
Merci !

Comme dit précédemment, quand MS à faut son caca nerveux, on a réclamé montrez nous le code, résultat : silence radio.
L'article qu'il pointe n'est pas le caca nerveux de MS mais une étude réalisé par l'un des conseillers de la FSF.
Bon après l'étude ne pointe pas en soit les brevets en question avec une excuse discutable :
"OSRM wont publicly say what the specific software patents are that potentially affect Linux because it "would put the whole developer community at risk."
En gros si on pointe les brevets en question, c'est un gros risque pour la communauté.

Pourr Stallman c'est le raisonnement inverse : le risque c'est l'incertitude. Et plutôt que de lever les incertitudes comme l'ont fait les juristes de RedHat, il FUD en pointant un risque sans relativiser et généraliser son raisonnement à l'ensemble des logiciels libres.

oué d'ailleur WinFS était vraiment sexy, y'a un projet en interne chez MS pour le recycler ?

Merci je vais essayer ce tuto ce soir.
si je comprends bien faut faire la connexion clavier midi -> appli dans qjackctl c'est bien ca ?