TImaniac a écrit 6420 commentaires

Oué mais là c'est plus pour des questions d'interopérabilité mais de performance.
Donc change pas de sujet.
De toute façon, tu le cites toi-même, c'est "In addition to the agreements".

Je suis pas spécialiste, j'ai dit que ca expliquait "peut-être".
Je vois mal MS dire : ok je refourge des licences Novell et je garde la possibilité d'attaquer tes clients et vis-et-versa.

C'est pas un problème de spec ouverte ou pas, c'est un problème de test et de certification.

Ce qui peut justifier cette différence, c'est que le partenariat entre MS et Novell inclu des clauses commerciales, MS pouvait refourguer des coupons de licence Novell. Ce qui implique des accords d'IP.
Ca explique peut être cette remarque qui précise la nature purement "technique" des échanges entre MS et RedHat.

C'est vrai ca, imposons aux gens la licence sous laquelle ils diffusent leurs softs plutôt que de leur laisser la liberté d'exprimer eux-mêmes les conditions dans lesquels ils estiment acceptable l'utilisation de leur labeur.

Qu'apporte Silverlight par rapport à ces concurrents, notamment par rapport aux standards du web ?
La même chose que Flash :
- la possibilité pour le programmeur d'utiliser autre chose que les "standards" du W3C qui traînent des boulets derrière eux, à commencer par Javascript avec sa grammaire et ses perfs de merde (malgré tous les efforts des navigateurs).
- la possibilité d'utiliser des bibliothèques multimédias : Vidéo, Audio, 2D, 3D, le tout de manière unifié et intégré. Même en aggrégant tous les standards du W3C ont obtient pas la même couverture fonctionnelle. Suffit de regarder les possibilités en matière de streaming vidéo qui arrive dans Flash10 ou Silverlight pour voir qu'en la matière ce que prévoit le W3C dans HTML5 est totalement à la ramasse.
Évidemment y'a les lots d'inconvénients qui contre-balance largement ces avantages. Mais chacun utilise ce dont il a besoin hein.

L'intérêt de Silverlight par rapport à Flash ?
- la possibilité d'utiliser le javascript de merde si le programmeur en a encore envie (Silverlight 1.0) tout en ayant accès aux possibilités multimédias que n'offrent pas les standards W3C.
- beaucoup plus naturelle pour l'ensemble des programmeurs MS qui retrouvent leurs langages, leurs outils avec toute l'intégration client/serveur qui va bien made-in-MS.
Là encore, Flash a bien d'autres avantages : plus de fonctionnalités, support H264, déjà déployé, etc.

PS : j'utilise pas Silverlight et j'utilise Flash que quand j'ai pas le choix, donc pas taper, j'essai juste d'expliquer.

J'aime beaucoup la rhétorique Microsoft :
Encore une fois, rien ne t'empêche d'ignorer tout simplement cet accord entre Novell et MS qui ne regarde que eux. Y'a pas de piège ou quoi que ce soit, tu regardes pas leurs accords, ca concerne uniquement MS, Novell, et leurs clients respectifs.

quelle est la motivation des dev de Novell pour supporter Moonlight ?
Ben c'est une alternative à Flash. Déjà rien que pour ca, ca mérite d'exister, parcque ca court pas les rues.
Ensuite sinon Novell supporte Moonlight, c'est juste parcque la version suivante s'appui sur .NET, et donc Mono. Ca donne une légitimité supplémentaire au projet Mono (qui est reconnu officiellement par MS pour le coup).
Je suppose que c'est également un pari sur l'avenir : Novell fait le pari que la techno Silverlight pourrait se démocratiser, et qu'il est donc important d'avoir une alternative libre sous linux comme ils ont fait le même pari pour Mono.

Idéologiquement les libristes ne peuvent que cracher dessus,
Juste les anti-MS, pas tous les libristes. On les entend beaucoup parcqu'ils gueulent tout le temps, mais ca veut pas dire qu'ils sont majoritaires.

T'aime bien accumuler les contre-vérités.

l est interdit de mettre en oeuvre Silverlight avec la (L)GPL v3.
N'importe quoi. Ce document dit uniquement que MS s'engage à ne pas attaquer Novell pour distribuer Moonlight, tant que ce ne sont pas des licences de type GPLv3. En imaginant un fork ou un changement de licence de la part de Novell, l'engage de MS ne tient plus, c'est tout. Et Moonlight devient aussi "nue" niveau protection que l'ensemble des autres logiciels libres. Ou que Flash, ou que n'importe quel logiciel non couvert par cet accord.

A ma connaissance, ce qui est proprio dans Flash est la vidéo (flv), mais rien d'autre.
Un peu comme moonlight quoi.

On peut "réver" d'un flash libre avec support Theora.
Et c'est bien connu, Flash et Theora sont des technos qui sont reconnus mondialement pour ne pas être sous l'épée de Damoclès d'un brevet enregistré quelque part dans le monde.

PS : tu compiles moonlight avec ffmeg, ayé tu l'as ton support theora.

Suivant des accord similaire, MS n'attaquera pas non plus Novell pour distribuer le kernel Linux dans ses distributions, dois-je en déduire avec le même raisonnement fallacieux qui le kernel n'est pas libre ?

des bouts de code qu'ils ont publié sous leur propre licence open source ?
pourquoi tu gueules pas sur la fondation apache qui publie sous leur propre licence ?
la licence utilisé par MS est libre au sens OSI et FSF, c'est le principal.

Est-il lié à microsoft ou peut on utiliser d'autres codecs à l'intérieur?
Tu peux compiler moonlight avec ffmpeg.
Le seul avantage du pack Microsoft, c'est qu'il est "légal" d'un point de vue licence/brevet pour les codecs WMV et VC-1.
Sinon effectivement ces codecs c'est du closed source pas bien du tout et bourrés de brevets.

ava a toujours été multi-plateforme
.NET a toujours été multi-plateforme, MS l'a montré dès le début avec des implémentations sous mac et bsd. Ses implémentations sur périphériques embarqués le montre également.

c'est Sun qui a fait le travail
C'est effectivement la grosse différence.

MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).
Pour Silverlight , MS fourni l'implémentation des codecs. Niveau dev c'est le gros du boulot.
Pour Silverlight 2.0, MS fourni la bibliothèque des widgets graphiques.
Pour .NET, MS fourni la stack DLR, la bibliothèques javascript pour ASP.NET AJAX, le compilateur IronPython.
Si ca c'est pas du dev, je sais pas ce que c'est !

Mais bon de toute façon, MS participerait au développement du coeur de Mono que ca vous ferait au contraire une raison supplémentaire de râler.

En tout cas c'est un but "officiel" de Microsoft.

La raison qui amène généralement un utilisateur à supprimer des fichiers, c'est un manque d'espace disque.
Tu cherches quoi en premier ? Les gros fichiers.

Le but n'est pas tant d'éduquer les utilisateurs que de sensibiliser les développeurs : l'UAC encourage ces derniers à faire en sorte que leurs applications limitent au maximum ces interactions "pètes-c..." pour l'utilisateur. Et pour y remédier, le développeur doit améliorer son soft, à commencer par exemple par faire en sorte qu'il soit utilisable sans être admin (oué y'a encore trop d'appli qui nécessite d'être admin).

Oué bah moi je parlais de tous les autres tests : en gros l'impact du multi-thread sur les algos "classiques" et non sur un test dédié.

C'est un module de multi-processing, pas de multi-threading, franchement c'est totalement différent.
Gérer la communication inter-process, c'est non seulement beaucoup moins efficace, mais également beaucoup plus lourd pour le programmeur (faut penser sérialization des données et comm inter-process)

Bah oué que veux-tu le monde du travail est mal fait.

Pas vraiment.
Y'a des contraintes que l'algo doit respecter, mais il y a pas mal de liberté dans la mise en oeuvre.
Il suffit de voir que la plupart des programmes ont changés d'implémentation dans leur version "multi-core" pour justement tirer parti des nouvelles machines quad-core utilisées dans le shootout.

Effectivement, je m'incline, en 5 minutes en peut rendre KDE encore plus moche.

Les langages qui s'en sortent bien dans le shootout sont les langages qui automatisent la gestion des threads et font souvent de bien meilleur choix que lorsqu'on code à la main.
On est pas tout à fait en phase. Moi ce que je disais au contraire, c'est que l'impact du langage est beaucoup moins important dans un contexte multi-thread : c'est l'algo mis en oeuvre par le programmeur qui fait le gros de la différence.

Java/C# vont devoir se mettre au diapason vite fait, mais je fais confiance à Sun/Microsoft pour prendre les dispositions nécessaires.
Au contraire, quand tu vois le bench, on s'apercoit que les langages C# ou Java n'ont pas à rougir des perfs des langages bas niveaux, parcque la différence se fait au niveau de la qualité des algos mis en oeuvre par les programmeurs. Mais en soit la base technique des langages C# ou Java est adapté au contexte multi-core.

Le seul véritable critère important dans le langage, c'est le fait qu'il mette à disposition du programmeur l'accès aux fonctionnalités multi-core natives de l'OS/machine sous-jacent. Les langages comme Python avec des implémentations totalement foireuses du multi-thread se font largués.

Sinon effectivement, si les langages veulent se différencier dans la course au multi-thread, c'est en proposant des nouvelles constructions pour automatiser la répartition sur plusieurs threads. Bien souvent ca se fait à l'aide de bibliothèques, et non directement dans le langage. (pour parler de mon église, on peut citer TPL http://en.wikipedia.org/wiki/Task_Parallel_Library )
Dans tous les cas, ces éventuelles "aides" au programmeur ne pourront que s'appuyer sur les compétences du programmeur : si l'algo est pas adapté, il sera pas parallélisable, quelque soit le langage. Bref, le programmeur va de nouveau devoir réfléchir, et ca c'est bien, ca laisse beaucoup de chemin d'évolution possible.

Ce qui est bien je trouve avec le multi-coeur, c'est que la limite de performance se retrouve côté algorithmique, bref, du côté du programmeur : la limite physique devient de plus en plus loin, et les perfs "pures" des langages également.
Pour s'en convaincre on peut regarder le shootout à cette adresse :
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al(...)

Les benchs à base de langages réputés "lents" (parcque à base de VM, les langages interprétés sont encore vraiment à la ramasse) se rapprochent des perfs des langages "rapides" (C/++ & co).
Ce ne sont plus les perfs du langage en soit qui font la différence, mais les algos mis en oeuvre. Les possibilités du langages restent bien entendus une part non négligeable du bench globale, mais il est intéressant de voir qu'il y a encore du chemin à faire au niveau algorithmique pour obtenir des programmes plus performant avec des multi-cores.
Et la bonne nouvelle, c'est qu'on ne va pas être obligé de codé en C/C++ pour systématiquement recherché les perfs (troll : et visiblement, pas en Lisaac non plus :-p http://shootout.alioth.debian.org/u32q/benchmark.php?test=al(...) )

T'es ridicule. Si Sophisme il y a, il est de ton ressors, je ne fais que te paraphraser. Tu peux pas dire que je cite hors contexte, puisque le contexte est dans ton poste.

u pars du postulat qu'il est juste qu'un commercial gagne par défaut beaucoup plus qu'un profile technique)
Encore une fois, je n'ai rien contre ce débat, sur lequel on pourrait probablement être en accord, mais ce n'est pas le débat. Moi je compare ce qui est comparable. Donc soit on comparer prime vs fixe, sur le même salaire moyen, soit on compare le salaire moyen d'un grouillot et d'un commercial, mais ce sont 2 débats totalement différent.
Toi tu mélanges allègrement les 2 en te contredisant d'un poste à l'autre.

Dans tous les cas ton message reflète pourtant très bien ce que j'essai d'expliquer : quand ton salaire est relativement "bas" (on parle de salaire d'ingénieur grouillot à 2000€, y'a des smicards qui aimerait bien ce salaire), tu veux qu'il soit fixe, et plus ton salaire s'elève, plus tu acceptes, voir préfères, qu'il soit variable.
Ce qui explique largement le fait que les managers ont une part variable et pas les grouillots. CQFD.
Voilà pour la réalité, toi qui avait pas l'air de comprendre pourquoi de nombreux grouillots ne demandait pas d'être intéressé aux résultats de l'entreprise (vu leur salaire).

Maintenant, puisque tu y tiens, on peut discuter de la logique qui consiste à payer en moyenne plus cher un manager qu'un grouillot.
Y'a un début de réponse dans la convention collective qui nous concerne :
http://www.syntec.fr/images/pdf/Convention-Syntec-Annexe_02.(...)
Et je peux t'assurer que y'a une bonne grosse quantité de grouillots qui sont soit incapable soit qui n'ont pas les couilles ni l'envie de prendre des initiatives ou des responsabilités, avec des horaires aléatoires et une présence dans le domicile conjugale plus aléatoire.
Que tu le veuilles ou non, les grouillots 1.1 ou 1.2 dans les entreprises informatique ont la vie plus "cool" que les mecs classés 3.x. Et ils sont payés en conséquence.
Et encore une fois, rien n'empêche le grouillot de postuler à des postes plus "élevés" s'il a de l'ambition ou si l'argent est une de ses motivations.
Mais vas-y, fais une enquête autour de toi, demande à tes collègues s'ils veulent être au poste de leur responsable ou de leur directeur. Je fais le pari que 90% d'entre eux te diront non. C'est bien que finalement ils sont pas si mécontent de leur situation, et il me paraît gonfler de demander autant de thune quelque soit ta position.

Je trouve que KDE 4 ressemble plus à Vista, surtout la barre des tâches. Celle de Windows 7 n'a pas du tout le même look & feel.
Mais franchement, visuellement celle de Vista est plus belle que celle de KDE 4 (qui est vraiment moche), et même que celle de Windows7.
C'est totalement subjectif, mais c'est mon avis.

"2000 € / mois fixe à 1000€ fixe + 0-2000€ variable toutes choses étant égales, parce qu'avec 1000€ je vais avoir des problèmes à payer mon loyer si ça arrive."
Voilà pourquoi le grouillot, il veut un salaire fixe.

"Par contre, je préfère 2000€ + 0-4000€ variable à 4000€ fixe toutes choses étant égales"
Voilà pourquoi le commercial il veut un salaire variable.

Merci pour ta démonstration :)

Et non, on ne peut pas donner 2000€ + 0-4000€ variable à tous les grouillots, ca revient à augmenter les salaire de 100% ce qui est totalement surréaliste.