reno a écrit 3886 commentaires

> Et bien si office etait gratuit, pourrais tu encore te permettre de dire qu'elle est pourri ?

Dans un jugement, le rapport qualité/prix intervient..

> Si oui la suite OpenOffice l'est encore plus.

Possible, je n'utilise pas OOo.

>Paradoxalement toutes les suites de ce genre seraient aussi pourries les unes que les autres mais n'ayant pas mieux tout le monde s'en servirait !

Pourquoi toutes? Le monde ne se résume pas à MSOffice et OOo:
personellement le traitement de texte que j'ai préféré est FrameMaker et je connais peu de personne qui préfére Word à FrameMaker (sauf les experts Words qui apprennent FrameMaker en deuxième), n'empèche que presque personne utilise FrameMaker: trop cher et maintenant le monopole .doc est bien établi..

>Finallement, on retient :
>- Il faut toujours choisir l'algorithme le moins naïf, si ce n'est pas couteux pour la conception du programme (shell sort contre bubble sort par ex pour 2 tri sans appels de piles)

*NON*, il faut choisir l'algorithme le plus simple, le plus maintenable en mettant une interface bien propre.
Mesurer les temps d'executions.
Si ce n'est pas suffisant: optimiser la ou c'est nécéssaire.

Le choix du language est plus difficile au niveau performance car si tu prends un langage lent genre Ruby, il y a aussi le risque du probleme des "milles coupures": pas un point chaud à optimiser (ça c'est pas trop compliqué) mais être lent partout et la, il n'y a plus qu'à réécrire.
Mais surtout il faut trouver un language accepté par ton chef donc D, Scala, Ruby, Limbo et autre Erlang, ce n'est pas gagné..

>> Et jusqu'à preuve du contraire, citer un future
>> échec^W^W^Wproduit Microsoft comme référence
>> sur linuxfr est du plus profond mauvais goût...

Note que singularity est un projet de recherche "pur", ils n'ont même pas encore essayé de vraiment voire le coté compatibilité avec les logiciels existant..
Comment un projet de recherche pourrait être un échec commercial?

>Ce genre de remarque me fais souvent plus pitié que sourir...

Assez d'accord avec ta réponse brouillon, mais pour ce qui est de leurs produits la on n'a pas le même point de vue: leur produit number 1 MSOffice, bien que leur rapportant des sommes indécentes est *pourri*: quand je vois le nombre de documents corrompu, l'interface pénible, etc.
Et la ils n'ont même pas l'excuse des driver.

Pour C#, certes c'est un effort interressant de chez MS, surtout la future v3 d'accord, mais a la base c'est quand même un clone de Java donc pas de quoi non plus s'extasier..

Ce qui est "capital", c'est qu'il y ait enfin des produits fiables en informatique, mais c'est autant (plus AMHA) un probleme de mode de travail que d'outils..

>Dynamo qui est une machine virtuelle proche des processeurs alpha

Non, des PA-RISC si je me souviens bien.
Et pour ce qui est du gain de performances, je me suis toujours demandé s'il serait si bon si on comparait avec du code optimisé "par profil" (on execute une fois le code qui génère un profil d'execution puis on recompile le code de nouveau en exploitant le profil pour amméliorer les perf).

Tu as tronqué mon commentaire, je disais supporte le multi-CPU en 'mode natif', c'est à dire sans différence entre mono et multi-CPU.

Je comprends bien qu'avant en utilisant des interfaces differentes on pouvait utiliser aussi plusieurs CPU.

>Erlang scale (monte en charge) très bien (très très même).

Oui, euh c'est quand meme la *premiere version* qui supporte le multi-CPU..

J'ai peut-être trop pris l'habitude de Sun et de leurs octoprocesseurs, mais quand on me dit 'tiens la montée en charge' et restreint au mono-CPU (si je comprends bien c'était le cas avant en mode 'natif'), je trouve ça un peu curieux.

Oui, je sais Erlang supporte plein de thread légés, mais bon si tes threads font quelque-chose, tu te retrouve facilement avec une machine a genoux..

Je ne sais pour les pubs dans gmail, je n'utilise pas gmail, si tu n'aimes pas, qu'est-ce qui t'empèche d'aller voir ailleurs??
C'est la ou on voit la différence avec Microsoft: rien ne te force a utiliser google ou ses outils alternatifs..

Pour ce qui est de l'outil de recherche par défaut, je ne vois pas trop quelle importance ça a que google soit le moteur par défaut de Mozilla: c'est un très bon outil de recherche donc c'est un choix normal..
Mais je n'aurais pas aimé que par exemple 'ask jeeves' un moteur pourri (mon expèrience avec date de quelques années) soit le défaut

Google a du succès bon et alors?
Je me souviens encore de l'avant google ou les moteurs de recherche étaient vraiment mauvais et planquaient leurs accès dans des pages extrèmement lourde à charger (par modem), les fondateurs de google ont été intelligent et ils ont gagné, rien de répréhensible.

Il y a des conccurents: yahoo, MSN, etc. Si google faisait une bétise demain, les gens changerait de moteurs de recherche *très* facilement: c'est ce qu'on faisait dans le passé et il suffirait que google baisse sa garde pour que cela se reproduise: contrairement à Microsoft et ses formats .doc, (presque) rien n'empèche l'utilisateur de changer.

Google fourni tous un tas de service complémentaire, mouai bof, ils ont loin d'avoir un monopole quelconque sur ces services supplémentaire.


Sinon vis à vis du web sémantique: bof un concept fumeux: le sens qu'on peut obtenir de manière automatique est assez limité et s'il faut remplir 'à la main' le contenu: qui le ferait? quel serait l'avantage?
Quand je vois qu'il n'est même pas possible de savoir ou sont les magasins qui vendent des objet X dans un rayon de 10min autour de chez moi et leurs horaire d'ouverture, les limitations des moteurs de recherches sont bien présentes..

Bon je me lance: quelle est la différence entre les deux?

Bin c'est logique, pas d'utilisateur, pas de profit pour les vendeur de logiciels, donc pas de soft donc pas d'utilisateur, etc.

Plus le marché est mature, plus c'est dur de sortir du cercle vicieux.

Rien a voir avec MS à proprement parler, juste des lois économiques.

Merci, tu m'as éviter de faire une recherche..

Mouai, et comment tu sais que ça fait X lignes?
Avec vi t'es un peu trop obligé de compter le nombre de lignes, c'est ce que je lui reproche.
On peut peut-être dire, "marquer ici", aller la ou on veut et faire "copier/couper" depuis la marque, mais je ne sais pas faire..

Ou plus faire, le probleme avec toutes ces options exotiques, c'est de les retenir..

Bof, ton fabriquant de cartes, il les vends aussi que je sache (à des grossistes bien sûr), il ne les donne pas je pense..

L'important c'est que le standard soit ouvert, mais avoir plusieurs standards affaibli le standard..

Quand à croire qu'un standard ISO ou autre resout tous les problemes.. Le HTML ne m'incite pas à l'optimisme.

C'est triste aussi ta liste: quand il y a une revue de ces logiciels la conclusion est qu'il n'y a pas un seul de ces logiciels qui soit stable, facile à utiliser et qui ait toutes les fonctionnalités demandée.

Je ne m'y connais pas dans ce domaine, c'est juste la conclusion de ceux qui font les comparatifs.
Le nombre ne fait pas forcément la force..

Certains font des drivers par pays pour éviter ça, mais bien sûr rien n'empèche de télécharger le driver du pays d'à coté ;-)

> si les docs étaient disponibles il y aurait d'autant plus de volontaires.

Oui bien sûr mais:
-je pense qu'un driver de carte 3D est plus complexe qu'un driver ethernet..
-les cartes 3D évoluent très vite.
-je me souviens que même quand les specs des cartes ATI étaient libre, le driver n'était pas de bonne qualité: J. Carmarck avait contribué au driver, pas parce que cela l'intérressait mais parce qu'il était en mauvais état pour faire tourner un de ses jeux..
Et c'était *avant* que les drivers intègrent des compilateurs de shadeurs!

Certes on peut penser que la contribution de J. Carmack fait partie du processus 'normal' de développement de driver libre, mais cela montre bien qu'un driver libre peut rester de "mauvaise qualité" pendant très longtemps: il y a peu d'application 3D sous Linux et ceux qui les développent ne sont pas forcément prèts a corriger les bugs des drivers..

De plus il y a le probleme de l'optimisation pour la 3D qui est très différent d'un driver Ethernet: où mettre la barre entre précision et performance?
Pour un jeux, c'est tout à fait justifié de baisser la précision si les FPS augmentent, pour une appli de CAO cela peut être différent..


Ceci dit, la défense de NVidia de ne pas fournir les specs car la communauté OpenSource ne serait pas capable de faire un driver de qualité est bien sûr absurde: certes l'histoire montrent que coté performances les driver proprio sont meilleur, mais
1) cela peut changer si l'interet pour la 3D sur Linux augmentait
2) coté fiabilité en général c'est le contraire (le driver opensources sont meilleurs) donc cela reste très intérressant
3) les non x86 en profitent, argument moins intérressant maintenant:Apple étant passé au x86..

OOo cela je le savait, mais je croyais que Mozilla était une réécriture totale de Netscape?
Si c'est vrai,dire que Mozilla est lourd a cause de son historique ne tient pas..

> si les utilisateurs étaient un peu plus consistants

Bof, dans le cas des cartes 3D haute performances, il n'y a pas le choix, juste de ne pas en acheter, ce qui est un *gros* inconvénient pour les utilisateurs!
Et les utilisateurs de Linux étant quand même très peu nombreux, il n'est pas évident qu'ils aient suffisamment de poids pour faire plier les fabriquants de matériels..

Bin oui parce que rien ne prouve que pour respecter les standard légaux de télécom il faille une partie binaire.
Comme personne n'en sait rien (cela peut même dépendre du pays), et que c'est un prétexte facile pour les entreprises, c'est un troll qui n'est pas près de s'éteindre.

Bah, pour éviter le troll; il suffit de mettre les deux comme dans Scala..

Je sais je suis lourd avec Scala, je -->[]

Un developpeur de FreeBSD a répondu qu'ils n'utilisaient pas non plus par défaut les invalidations de TLB pour faire du zéro-copie par socket: c'est juste une option.
Il est possible que cette option soit "stupide" (inefficace) mais bon comme ce n'est pas le comportement par défaut, pas de quoi fouétté un chat.

Pour Mach, je ne sais pas par contre, mais de toute manière Mach n'a jamais été vu comme un modèle de performance, plutôt le contraire (MacOSX en souffre dans les benchmark d'ailleurs).

On peut écrire du code illisible dans n'importe quel langage, c'est une évidence qui n'apporte *rien*.

Mais certains langages ont une syntaxe qui facilite l'écriture de code propre et la maintenance..

S'il faut faire attention en écrivant en Perl, c'est bien parce que le langage encourage a faire du code peu lisible..
Peu de gens préférent la syntaxe de Perl à celle de Ruby (je parle de la syntaxe hein pas du reste, on peut préférer Perl parce qu'on y est plus habitué, à cause de CPAN..). Donc Ruby doit faire quelque-chose de bien..

Pour exagérer les différences, tu préfère maintenir un programme en Ruby ou en APL?

Les préférences individuelles n'ont que peu d'intérét, le succes d'un langage c'est par définition quelque-chose de collectif: ce sont les préférences d'un grand nombre de programmeurs qui comptent..
Et la majorité des programmeurs se fichent des preuves de Coq mais pas de savoir si c'est facile à lire|maintenir/écrire, les deux ne sont bien sûr pas incompatible, mais apparemment c'est dur à retenir..

Non ce n'est pas 100% subjectif: pour maintenir des programmes, la lisibilité d'un langage est très importante.
Il n'y a qu'a essayer de maintenir un programme écrit par un autre en Perl pour s'en rendre compte..

>sont en fait déroutés par leur premier contact avec un langage fonctionnel.

Ce n'était pas mon premier langage fonctionnel (mais je n'apprécie pas particulièrement les langages fonctionnels à part Scala) et Ocaml est "vendu" comme un langage multi-paradigme pas fonctionnel.
Cependant dans le livre l'accent est mis sur le coté fonctionnel ce qui est pénible..

En fait, j'ai ressenti exactement la même chose que Yusei ce qui est amusant..

Sinon je suis d'accord que l'inférence de type épure le code mais Ocaml n'est pas le seul langage ou l'inférence de type existe: Limbo, Scala, D, bientôt C# v3 etc ont l'inférence de type locale ce qui est suffisant.