TImaniac a écrit 6420 commentaires

Billou a en fait le choix entre donner au fisc US ou donner à une fondation,
Tu crois franchement qu'il devait 29 milliards de dollars au fisc et qu'il lui est fait un dégrêvement de 100% ?

Encore heureux qu'il fait pas des erreurs d'arrondis avec des entiers :)
Les erreurs d'arrondis c'est quand tu manipules des flottants, mais bon dans le contexte je penses qu'on peut s'en cogner royalement des centimes :-D

On pourrait dire que c'est un radin, vu que ce qui est donné à la fondation est dérisoire... (pour lui)...
Lui a une fortune estimée à 47 milliards de dollars.
Sa fondation a des fonds estimés à 29 milliards de dollars.
Même s'il lui en reste encore beaucoup, perso je trouve pas ca spécialement dérisoire.

Mets ton CD de WinXP dans le lecteur, démarre le PC dessus, normalement il va lancer l'installation. Tu choisi de réparer ton Windows en lancant la console de récupération.
Là tu tapes :
fixmbr
(en gros : "fix master boot record", ce qui veut à peut prêt dire "corriger l'enregistrement d'initialisation principal", autrement dis ca va... faire ce que tu veux.)

Franchement tu abuses, en plus tu dis avoir peur de dépasser ton droit de citation, genre ca te dérange avec un tel surnom :)
Ok --->[]

Ben si le mec a l'habitude comme moi de faire des CTRL-ALT-SUPPR et autre CTRL-ALT-DEL mais qu'il a également l'habitude de faire des ALT-F4 pour fermer une appli, c'est vite fait de faire une mauvaise combinaison des 2 habitudes :)

Oué enfin tu sais c'est pareil partout : en france tu as une bonne réduction d'impôt si tu fais un don (un truc genre 60% des dons si mes souvenirs sont bons), et j'espère qu'on fait pas tous ca pour faire baisser nos impôts (ou alors on est très con parcqu'au final ca nous coûte plus cher que de ne pas faire de dons du tout).

Il existe des types primitifs en Java (types valeurs en C#) mais on ne peut pas en créer soit même, donc il a raison. En C# tu peux créer tes propres types valeurs (primitifs).
L'intérêt, c'est qu'un type valeur est alloué sur la pile et non sur le tas, ce qui est est beaucoup plus efficace. Enfin faut bien voir que la pile n'a pas une taille infinie et que ces objets sont passés "par valeur", donc à utiliser quand c'est pertinent (ce qui est loin d'être le cas général).

Merci pour les compliments. On se connaît pour que tu puisses juger de mes compétences ? En quoi c'est "MA" technologie ? Enfin tu dois avoir raison même sans argument et avec des "compliments gratuit", puisqu'on te pertinente.

Non, le compilateur de .NET ne compile pas du code natif,
C'est quoi le compilateur .NET ?
Dans ces environnements il y a 2 types de compilateurs :
- les compilateurs qui visent la machine virtuelles (C# --> MSIL ou Java -->bytecode)
- les compilateurs qui visent le code natif (MSIL --> x86 ou bytecode --> x86)

GCC fonctionne à peu prêt pareil : il a un frontend et un backend avec un langage intermédiaire propre à GCC. les frontend (ceux qui manipulent du C, du C++ ou jesaispasquoi) produise du code intermédiaire (ce sont des frontend), puis le backend s'occupe d'effectuer la compilation en code natif suivant la machine cible (x86 ou autre).

Comme tu peux le constater sur le papier, c'est exactement le même fonctionnement. D'ailleur c'est pas pour rien que GCC est capable de compiler du Java, techniquement les 2 phases de compilations sont similaires dans leurs objectifs.

Au final le code qui s'exécute EST du code machine x86 (ou autre) quelque soit la technique :
- Pour le compilateur GCC, le code produit est par défaut systématiquement du code machine. Il est cependant possible de lui demander le code intermédiaire.

Pour les environnement Java et .NET, la dernière étape de compilation (code intermédiaire --> code natif) est effectuée par défaut au dernier moment (Just-In-Time), au prix d'un chargement plus long mais d'une plus grande souplesse de déploiement, voir des optimisations supplémentaires : en effet, le runtime connaît exactement la configuration sur laquelle il tourne, il est alors capable d'effectuer des optimisations spécifiques, là où avec un compilateur "classique" comme GCC tu aurais été obligé de générer toute une série de binaire avec toutes les combinaisons d'optimisations possible, ou, plus généralement, t'aurais pondu un binaire optimisé de manière "générique".
Maintenant, de la même manière qu'il est possible de modifier le comportement par défaut de GCC pour qu'il génère son code intermédiaire, il est possible de modifier le comportement par défaut de Java ou .NET/Mono pour qu'il compile directement en natif, bref pour qu'un binaire x86 arrive à la sortie.
Tu sembles en douter, ben fait le test :
Java :
utilises GCJ, c'est son comportement par défaut
Mono :
mono -aot monprog.exe (AOT pour Ahead-Of-Time)
Avec .NET :
ngen monprog.exe

Le code généré est-il (attention, je parle du code produit par le compilateur dynamique de Mono ou de .net) aussi performant "algorithmiquement" qu'un code C (donc issu de gcc, avec toutes les optimisation qu'il a jugé nécessaire de faire, quand tu lui donnes un -O2) ?
Faut bien voir que même algorithmiquement identiques, des programmes écrits dans des langages différents ne peuvent être optimisés de la même façon, bien souvent à cause de la sémantique du langage. Le C est pas forcement le meilleur dans le domaine, puisque bien souvent il autorise tout et n'importe quoi, ne laissant pas vraiment de liberté au compilateur pour spécialiser un morceau de code.
Ensuite un compilateur comme GCC peut très bien te pondre du code super-optimisé sur telle plateforme (x86) et super mal optimisé sur une autre plateforme (PPC) (je dis n'importe quoi c'est pour l'exemple).
Il peut aussi y avoir de grosses différences entre les compilateurs, le compilo d'intel est par exemple beaucoup plus performant que le compilo GCC.

Donc voilà comme tu peux le constater, c'est vraiment difficile de comparer. Mais techniquement, les problèmes d'optimisations sont les mêmes en C ou C#/Java. Ce qui va ralentir ton code, une fois de plus ce n'est pas le fait qu'il y est un code intermédiaire, mais le fait qu'il est des services associés : sercices de reflexion, de gestion de types, d'isolation et plus généralement de sécurité. Ces services fournissent de nombreuses fonctionnalités aux développeurs et peuvent avoir un coup en terme de performance.
Ces services assurent une qualité de code supplémentaire non négligeable.
Mais que va faire un "bon" programmeur C/C++ ? Il va chercher à acquérir les mêmes types de services (réflexion, gestion mémoire, etc.). Comment va-t-il faire ? Il va utiliser des outils pour (GC, etc.) ou alors il va réinventer la roue, avec de forte chances que le tout soit moins bien optimisé et avec autant de bugs potentiels. Quand à certains services, il ne pourra peut être même pas les "émuler", comme tous ceux liés à la sécurité.

L'intérêt de plateformes comme Java ou .NET c'est de proposer ces services "en standard", avec une implémentation largement testée et éprouvée.

Maintenant que certains préfèrent encore se passer de ces services et gagner quelques malheureux % de temps d'exécution au risque de passer un temps fou à réinventer la roue avec des bugs potentiels supplémentaires, ca les regardent, ca peut être parfois justifier (bas niveau), mais d'une manière générale ca l'est rarement. Ou si pour le "fun".

Il faut également bien voir que les plateformes comme Java ou .NET proposent une grande quantité de classes en standards, celle-ci sont bien souvent optimisés et/ou font appels à du code natif quand c'est nécessaire.

'aimerais trouvé un dump (assembleur x86) d'un traitement matématique écrit en C#, compilé en MSIL puis compilé en langage machine par Mono, puis par .NET (sous Windows). Pour voir si le code est aussi optimisé (dans ce cas précis) ...
Si tu veux prendre un exemple "mathématique", j'ai envie de te répondre : plutôt que de passer 3 plombes en C à débugguer un segmentation fault ou autre fuite mémoire, moi je préfères affiner mon algorithme en Java en réduisant sa complexité. Ca c'est autrement plus efficace ;)

Enfin si tu veux vraiment trouver un dump, ben utilise les méthodes que je t'ai expliqué au dessus (gcj, mono -aot et ngen) pour avoir une image native :) Mais bon visiblement t'y crois pas à ce fameux code natif avant exécution :)

Moi c'est plutôt votre vision VM == interprétation hérité de l'âge Java à ses débuts et autres langages de script qui me fait rire :)

(c'est natif qu'après la compilation dynamique), ...
Ben voilà t'as l'explication qui fou en l'air tout ton raisonnement : Beagle c'est un daemon, la compile JIT est effectuée pendant les première secondes, voir pas du tout si Beagle est compilé en natif avant (AOT), après le service tourne pendant toute sa vie de service en natif, c'est quand même le principal pour un daemon non ?

Sans lancé un troll, je ne peux que me poser la question du choix du language (pseudo compilé, interprété dans une machine virtuelle)
Pourquoi pseudo compilé ? Pourquoi interprété ? C# n'a pas été conçu pour être interprétable, et Beagle n'est PAS interprété. C'est du code natif qui tourne, aussi vite que ton code écrit en C ou n'importe quoi.

Gaspillé par quoi? Par l'interprétation
Y'a aucune phase d'interprétation. C'est pas du javascript !
, par un garbage collector (
Le GC a des inconvénients, mais aussi des avantages : il est capable de recycler la mémoire, il intervient aux moments opportuns (quand le CPU est peu utilisé par exemple). Tu pourras toujours reproduire le même comportement en C/C++ mais de façon très difficile. Et les projets bien "codés" comme tu dis utilises de plus en plus d'approches similaire, comme Apache qui gère une pile mémoire un peu comme un GC.

qui te prend 200Mo parce qu'il a vu que j'avais de la place, et que si je lance un nouveau programme ca commence à swappé
Ca c'est n'importe quoi. Lorsque les ressources mémoires sont trop faibles, le GC s'active et fait du nettoyage pour éviter justement de swapper inutilement.
Le problème général n'est pas du au GC "qui bouffe de la mémoire" mais à la conception de l'application : en java ou C# on se permet parfois de bouffer inutilement de la mémoire en créant des millions d'objets impossible collecter par le GC : là tu bouffes de la mémoire et tu swappes. Mais tu le dis toi même : faut bien coder. Tu peux avoir exactement le même comportement en C/C++ en allouant plein de mémoire.

Dsl pour le troll
C'est rigolo les trolls, mais pour bien troller faut normalement faire semblant de partir sur des vérités pour ensuite dériver sur des conclusions par un raisonnement volontairement fallacieux. Toi tu pars direct avec des idées reçues déjà mainte et mainte fois tuées : C# n'est pas interprété et le GC ne bouffe pas de ressource, c'est le programmeur qui en demande trop.
Enlève toi de la tête cette idée de machine virtuelle, ce n'est qu'un point de vu des compilateur et du développeur, à l'exécution il n'y a qu'un environnement d'exécution proposant des services (GC, sécurité, etc.) et un programme qui tourne en NATIF.

Office 12 == Office 2007

C'est pas seulement "stratégique", c'est vraiment corrélé aux demandes des utilisateurs.
On peut également prendre le cas récent de Firefox : ce navigateur atteind une part de marché non négligeable, même par MS : du coup MS le prend désormais en compte dans ses sites web, dans ses bibliothèques web (Ajax, ASP.NET, etc.). Et pourtant Firefox n'a rien d'un leader comme tu dis.

Oué enfin faut voir un autre truc : le format ODF n'est utilisé que dans OOo 2.0 et OOo 1.1.5 (et encore c'est qu'en lecture)... Alors autant dire qu'il n'y a que OOo 2 et le dernier StarOffice qui sont capables de produire des documents ODF. Y'a aucune stat, mais à mon avis à l'heure actuelle la plupart des OOo déployés sont des 1.1.x. Bref, à l'heure actuelle l'ODF est utilisé par un nombre d'utilisateurs vraiment ridicule.

e n'est pas parce qu'il n'y a pas assez d'utilisateurs que MS ne veut pas faire d'import / export vers le format opendocument, mais juste par stratégie
Je vois pas pourquoi il y aurait une raison plus valable qu'une autre : c'est complémentaire ! Il n'y a quasiment aucune demande des clients, on ne va donc pas supporter le format concurrent.

sans doute très en deçà de la réalité de son déployement en universités, entreprises etc. (une université avec 100 ou 200 postes ne va pas télécharger le logiciel à chaque fois).
Oué enfin on peut aussi trouver de parfait contre exemple qui font baisser les chiffres : perso j'ai du le télécharger une bonne vingtaine de fois, pour des raisons X ou Y. Ensuite je suppose que sont additionner sur Wikipedia toutes les versions de OOo depuis la 1.0. Là encore on peut penser que des utilisateurs se sont maintenus à jour, OOo ne proposant pas de système d'update, le plus simple est de retélécharger la suite, bref de gonfler les stats sans qu'il y est plus d'utilisateur.
Bref on peut dire que tu dis tout autant n'importe quoi. Il faut se faire une raison, à part dans certaines administrations, OOo n'est utilisé quasiment nul part, à commencer chez monsieur tout le monde qui représente une bonne partie du parc informatique. Perso les seules personnes que je connaisse qui l'utilise, c'est les personnes chez qui je l'ai installé. Mais je ne compte plus le nombre de personnes qui me rappelle pour me dire : "oué mais j'arrive pas à ouvrir tel doc" ou "j'ai pas office 2003 bordel !" ou encore "c'est nul ton Office gratuit, il rame et il est vieux" (en fait c'était l'interface graphique qui lui faisait penser que c'était vieux). Bref, la popularité de OOo n'est pas encore gagné. Faut vraiment que des décaïdeurs impose ce choix dans des administrations/entreprises/université pour en voir des exemplaires en route.

our le coup des standards tu l'a dis dans un autre journal relit toi, tu parles toujorus du standard de MS et de ODF soit disant standard
Vas y pointe moi le commentaire où je parle de standard MS OpenXML

Le probleme initial c'est que MS a refuse de continuer a participer a la definition d'un format standard pour les suites offices.
Oui enfin on peut les comprendre : le groupe de travail étant dirigé par Sun, c'est Sun qui tient les manettes. Sun voulait surement que le format se rapproche de StarOffice/OOo et MS qu'il se rapproche de MS Office. Y'avait forcement y avoir un clash. Fallait un vrai consortium indépendant qui sache créer un vrai standard qui tienne compte des 2 principaux acteurs. Au final on se retrouve avec un standard qui est incompatible avec 90% des documents Office qui existe.

autant celui de MS on peut rien dire car il n'existe que des documents theorique et personnes (sauf peut etre les developpeurs et qq beta testeurs) ont vu reelement ce que donne le nouveau format.
Tu vas sur Google, tu trouveras des exemples. Et la première beta a été ouverte à des milliers de testeurs. Sachant que concrêtement tout le monde y a eu accès (merci eMule), tout ceux qui veulent s'y intéresser le peuve (et MS s'en fou royalement que tu le pompes sur la mule même si c'est pas légal). Tu peux donc le tester avec des gros documents si ca t'amuse.

ne presente pas de qualite technique visiblement superieur
Si, il est extensible avec des données XML personnalisés. C'est lié au soft InfoPath dans MS Office, qui n'a pas d'équivalent dans OOo (c'est pour ca qu'on le retrouve pas dans ODF comme par hasard)

e. Cela fait pas mal de point negatif pour lui sans qu'il existe....
Tu peux pas mettre en avant comme point négatif d'un truc qui n'est pas sorti le fait qu'il ne soit pas utilisé :) Franchment Entreprise Bidule, vos futurs produits sont nuls, ils sont pas sortis !

L'autre c'est juste une theorie pour le moment comme le fut le format ODF pendant plusieurs annees
Euh MS a proposé un draft, c'est du concrêt, et une beta de Office12, c'est du concrêt, pas de la théorie.

surtout que tu arretes pas d'appeler le format "theorique" de MS comme etant un standard alors que les suites offices lbres concurrentes de MS ne peuvent pas l'implementer
J'ai jamais dis ca... tu vois où que j'ai dis que le format de MS était un standard ? J'ai dis qu'il avait 2 formats de travails ouvert, et qu'il y en avait un qui se prétendait être un standard (sachant que le 2ème veut faire pareil). Pour moi y'a pas de standard, juste des formats normalisés et ouvert. Il manque toujours un standard dans l'histoire.

pour l'instant c'est la seule critique valable que j'ai pu lire sur ce format
Y'a aussi les macros par exemple. Va faire un tour sur google si tu veux trouver des problèmes :)

Ton argument plus haut, c'était que Koffice n'arriverait pas à implémenter la totalité d'ODF
Bah oui, par des lacunes sémantiques du format ODF, KOffice était incapable d'interprêter les formules contenues dans le format ODF. Le format ODF offrait bien dès le départ la possibilité d'y mettre des formules, c'est juste qu'ils ont "oublié" d'en préciser la sémantique.
Donc oui si tu veux ils auraient pu implémenter l'ODF si tu veux, techniquement le document aurait été "compliant" et respeter le schema Relax NG. J'ai FUDé si tu veux. J'aurais du dire : "KOffice n'arrive pas à lire tous les fichiers OpenDocument créés avec OOo (ce qui est balo pour un format soit disant d'interopérabilité).
Tu veux un autre exemple ?
Les macros. Pareil, le format ODF est trop laxiste, et on va se retrouver avec des différences entre KOffice et OOo à moins qu'ils se mettent d'accord encore une fois sur une extension du format ODF. Bon cela reste moins important que les formules dans le format tableur.
http://software.newsforge.com/article.pl?sid=05/09/09/164025(...)

C'est de l'HTML correct d'après la norme? En tous cas, ça valide en XHTML strict ...
Euh, dans la doc officielle du W3C le champs href est décrit comme devant contenir une URL. C'est donc écrit noir sur blanc dans les spécif le format à adopté, qu'il soit décrit dans une RFC séparée on s'en balance, le fait est que c'est clairement définies. Après si la DTD que tu utilises n'arrive pas à vérifier la syntaxe de ton URL c'est un autre problème.

Euh t'es déjà allé à la fnac ? T'as déjà regardé le nombre de CD ? Tu sais qu' on est 6 milliards d'humains potentiellement musiciens ?

mais ils disent qu'ils ont 60 000 chansons (putain comment ils font pour en avoir autant?
Euh en 2004 chez Wippit ils en avaient 500 000 :
http://www.bucheron.net/weblogs/index.php?2004/10/19/1066
chez Virgin c'est le million...

On peu parler de la merdouille qu'est le format MS qui fout un image en binaire dans le fichier xml directement,
Non on peut pas en parler parcque le format OpenXML de MS utilise un zip comme ODF :)

Cela m'etonnerait un chouilla (non je ne vais pas verifier je n'ai pas signe le NDA sur le format puis j'y connais rien au XML) vu qu'elle est cense fonctionner qu'avec un seul logiciel les autres voulant l'utiliser ayant interet a avoir la meme semantique et les memes formules que la suite office de MS sinon le meme probleme se posera.
Comprend rien à ton raisonnement. En tout cas les formules sont définis dans le draft qu'ils ont soumis à l'ECMA. Pour t'en convaincre, ben t'as qu'à vérifier, y'a pas de NDA et ca parle pas XML :-p

Et là, on tombe dans le « ouais, mais si ça se trouve, ils y arriveront pas ». Avant de dire que Koffice a des problèmes avec ODF, attends qu'ils les ai vraiment.
Ben justement ils ont eu le problème des formules. Ils ont en partis contourné le problème en s'accordant avec OOo, mais reste qu'à la base l'ODF posait problème.
J'ai justement mis ce lien comme argument, je vois pas où est le FUD.

Ton exemple montre un truc qui n'est pas couvert par ODF.
D'où les lacunes du format ODF : avoir un format de document pour un tableur en ayant de grosses lacunes sémantique sur les formules c'est quand même balo, quoiqu'ils en disent:) KOffice se retrouvait dans l'impossibilité de ganratir l'interopérabilité de ses formules avec celles de OOo parcque l'ODF était mal foutu sur ce point là, ce que je voulais démontrer.

it. C'est un peu comme si tu disais que HTML, c'est nul, parce que ça ne dit pas comment décoder un .jpg
Non c'est comme si je disasis que l'HTML c'est nul parcque je sais pas comment créer un hyperlien. Ca sert à rien de dire "oué mais non c'est pas à l'ODF de gérer ca", les formules sont un des points clés d'un document de tableur, au même titre que les hyperliens sont des points clés du HTML.