Guillaume Laurent a écrit 1148 commentaires

Tu ne détailles pas les raisons de rester en RH6, si tu ne les as pas c'est un exemple sans intérêt.

Je ne connais pas les raisons précises, mais il peut y en avoir une floppée. Ils utilisent une appli validée uniquement sur RH6, ils n'ont pas confiance en RH7, ou tout simplement, ils ne veulent pas upgrader parce que le downtime coute trop cher.

C'est ce que je fais dans ma boite, et ce n'est pas inutile parce que le modèle "proprio+patches" est tellement ancré que personne n'imagine fonctionner autrement. Tout ça c'est dû aux logiciels propriétaires utilisés depuis longtemps et qui posaient toujours problème à la moindre upgrade. L'upgrade fait systématiquement peur maintenant.

Oui, et le libre n'y change absolument rien. Depuis 7 ans que je suis sous Linux, j'ai eu quelques upgrades sans histoire mais en général il y a toujours des merdes. La dernière (upgrade mdk 8.1->8.2) c'était l'ordre des protocoles de ssh qui était changé dans la config ssh. Du coup je ne pouvais plus me connecter sur sourceforge sans donner mon passwd. Ça m'a pris une journée pour trouver le pb. La même connerie sur un gros serveur, ça te coute des millions.

Expliquer que le libre peut différer sur certains points, c'est vraiment pas inutile.

Si, c'est inutile. Les clients s'en foutent. Tout ce qu'ils veulent, c'est que ça marche et que ça ne leur coute pas trop cher. Et différer sur quels points ? Que les upgrades marchent ? C'est indiscutablement faux.

Ah parce que quand on lit LinuxFr, on ne connait que ça et on ne travaille pas dans la vraie vie avec ces problèmes là.

La majorité du lectorat ici est constitués d'étudiants idéalistes, sans aucune expérience en entreprise, où avec des utilisateurs "normaux", avec très peu d'expèrience sous Linux, et dont la participation au logiciel libre se résume à poster "ms suxxx". Mais quand on demande qui contribue vraiment à des projets libres, y a plus personne.

Rien que l'intitulé de cette news "Microsoft est l'ennemi", ça donne le ton.

Ca résume bien la manière dont tu considères tes interlocuteurs ici : ce sont forcément tous des cons.

Pas "forcément". pBpG est un contre-exemple :-).

Mais raté, le problème je l'ai constaté en vrai (dingue non ?)

Quel problème ? Cite moi un exemple précis. Une entreprise qui n'a plus aucun pb d'informatique depuis qu'elle utilise du libre. Que ça soit mieux qu'une solution MS, sans doute. Qu'ils upgradent à tout va sans jamais avoir de problèmes, je voudrais bien savoir quelle distrib ils ont, que je puisse prendre la même.

Si le problème est principalement qu'il faut payer la transition, parce qu'avec les logiciels propiétaires cette transition est soit chère soit impossible. Tout ce que tu cherches à faire, c'est de faire croire qu'une upgrade de distrib c'est aussi coûteux (en prix et en effort de transition) qu'une upgrade d'OS/solution propriétaire, ce qui est totalement faux évidemment.

Qu'est-ce que tu en sais ? Tu as vraiment déjà discuté avec des gens dans ce domaine ? Récemment un de mes potes à IBM me citait le cas d'une boite dont ils hébergent le serveur web, et qui les fait bien chier parce qu'ils veulent absolument rester en RedHat 6. D'où une certaine difficulté pour trouver les fixes de sécurité. Tu veux aller leur expliquer qu'ils n'ont rien compris au libre ?

Et non, pBpG ne cherche pas à faire croire quoi que ce soit, il connait simplement mieux le problème que toi, et il t'explique comment ça se passe en vrai, et pas comment tu crois que ça se passe parce que tu as trop lu linuxfr.

Qu'un antivirus ou qu'un graveur de CD soit mi-driver, c'est qu'il y a comme un pb AMHA. Parce que sous Linux ça n'est pas le cas ? Y a pas de driver pour l'IDE ou le SCSI ? Pas de driver pour ta carte réseau, ou pour IP ? Et sinon, oui, tu es un étudiant donc tu ne sais rien. En plus tu as l'esprit complètement fermé. Et si on peut te le dire, c'est parce qu'on a tous été comme toi. On a tous cru avoir tout compris mieux que ces vieux cons qui bossent dans l'industrie et qui connaissent rien au logiciel libre et à Unix. Et puis après on a pris un peu d'expérience, et on a arrêté d'être cons.

Je ne te parle pas de théorie là, je te demande juste de regarder ce qui ce passe dans la réalité. Evidemment, les utilisateurs de logiciels propriétaires peuvent difficilement fournir des patches sur un code qu'ils n'ont pas. Et ça leur convient très bien parce que la dernière chose qu'ils ont envie de faire c'est de patcher le code que tu leur fourni. Ils préfèrent te demander de le faire, et soit tu le fais, soit ils t'engueulent, et au bout d'un moment ils vont voir ailleurs. Quand une boite fourni un support de merde, ils perdent des clients. Le pb de MS c'est qu'ils sont assez en position de force pour être moins "sensibles" à leurs clients, mais faut pas croire non plus qu'ils n'en ont plus rien à foutre, au contraire. Ils ne resterait pas longtemps là où ils sont si ça n'était pas le cas. Ma toyota je peux la faire réparer chez le garagiste du coin (pan) Pour des réparations de base, oui, mais ça te coutera plus cher. Et il y a des parties accessibles uniquement aux mécanos agrées (genre l'ordi de bord, etc...). mon ordinateur IBM je peux aussi mettre un processeur acheté rue Montgallet si je le souhaite. Attends, je te parle pas du clampin de base avec son petit PC acheté à Carrouf, je parle des grosses entreprises qui veulent faire tourner leur service informatique sur des clusters/mainframes. Quand l'heure de downtime se chiffre en millions de dollars, t'as pas envie de "patcher le source". Tu décroches ton téléphone, tu engueules ton fournisseur jusqu'a ce que ça marche, et à la fin ils te remboursent le downtime parce que c'est dans le contrat. Remarque, le clampin de base n'a pas non plus envie de patcher quoi que ce soit. Lui aussi il veut juste que ça marche. MS n'est évidemment pas une assoc loi 1901, mais faut pas pousser non plus.

Enfin, visiblement tu n'as rien compris sur le fonctionnement du logiciel libre

Non, c'est toi qui n'a rien compris au fonctionnement du monde réel.

MS n'est pas tout rose, mais les "solutions" dont tu parles sont complètement délirantes.

Il n'y a _aucun_ autre domaine ou le client est autant lié à une unique société, et c'est très dangereux.

Les constructeurs de voitures, justement, offrent des solutions similaires (ex Toyota). Un autre exemple dans le domaine de l'info c'est IBM, et les clients vont chez eux précisément pour ça : pour n'avoir qu'un seul interlocuteur pour tout : le réseau, le matos, le soft, etc...

CNN :

http://www.cnn.com/2002/TECH/internet/06/17/browser.war.revival.ap/(...)

Cite-moi le passage qui parle de la "guerre des browsers" (je ne trouve même pas le mot "war" dans l'article). Cite-moi les passages "élogieux". En résumé, l'article donne un historique de Moz, dit qu'il est sorti, qu'on peut réutiliser ses composants, et qu'il est important pour garder le Net ouvert. C'est tout.

Ah si, pardon, j'ai trouvé le mot "war" : dans l'URL :-).

Washington Post :

http://www.washingtonpost.com/wp-dyn/articles/A55122-2002Jun15.html(...)

Aucune reférence à la guerre des browsers non plus. La principale éloge est que Mozilla bloque les pop-ups. Vers la fin il serait même plutôt assez critique ("Mozilla's geeky edges"), surtout quand il parle des autres composants (mail, etc...).

Ah ? Parce qu'autrefois, ca passionnait les foules ?

Oui ("les foules" = la presse info. Ça n'a évidemment jamais interessé le pekin moyen).

Il parait que MSWin domine le marché des OS pour desktop, ca veut dire que Linux et Apple ont perdu la guerre ?

Apple a perdu la guerre. Linux ne l'a même pas faite.

Pourquoi la guerre des navigateurs serait finie ?

Parce que tout le monde s'en fout maintenant ?

Parce qu'Internet Explorer domine le marché ?

Oui, aussi :

http://story.news.yahoo.com/news?tmpl=story&ncid=77&e=1&(...)

C'est pour ça que, personnellement, j'ai tendance à classer cette impossibilité technique à facturer automatiquement la durée de connexion, voire de facturer tout court, comme un gros avantage d'Internet par rapport au minitel, et une des causes de son succès.

Oui, mais c'est aussi pour ça que très peu de services sur Internet sont rentables, alors que la plupart des services minitels le sont.

Complètement faux, essaie de passer une méthode "char *foo(char *)" là où le compilo attend une méthode "void (*)(void *)" et ça ne marchera jamais

Ben non, encore heureux (à moins de caster violemment, mais tu cours au coredump). Et ça ne marchera pas en Java ou en ObjC non plus, ni même en Ruby ou Python (tu aura une exception au runtime si tu essaies d'utiliser la méthode en question).

Au fait, en C++ on utilise plutôt std::string que char*.

essaie de passer un pointeur sur une attribut ou une méthode d'une surclasse à une méthode d'une sous-clase

C'est tout à fait possible, mais pourquoi le faire ? La sous-classe a déjà accès aux méthodes et attributs de la sur-classe. Ça sent très mauvais ton truc. Passer un objet et un pointeur de méthode à une classe complètement différente (genre map()/apply()) ça par contre c'est déjà plus utile, et ça marche aussi.

Ce sont des trucs qui sont rendus impossibles car ils rentrent en conflit avec les méchanismes objets _très_ limités du C++.

Je ne comprends pas. Ce dont tu parles est possible, sauf l'erreur de type qui ne l'est pas pour de très bonnes raisons. Et tu dis que le C est mieux, alors que C n'a même pas ces mécanismes là.

Quand au code aussi optimisé, je l'ai expliqué des dizaines de fois, c'est complètement faux aussi, ou en tous cas avec les compilateurs que j'ai pu tester.

Lesquels ?

Je suis étudiant donc mon avis ne compte pas et j'ai forcément tord ?

Non. Tu es un étudiant, tu n'as pratiquement aucune expérience, et il te reste encore beaucoup à apprendre.

Tu as 2 personnes (moi et pasBill), beaucoup plus expérimentées que toi, qui te disent que tu as tort à propos de ce que tu dis sur C++, un langage que tu connais à peine. Ces deux personnes connaissent C++ bien mieux que toi, et le pratiquent depuis plus longtemps.

Tu préfères continuer de penser que tu as raison, et de rejeter sans refléchir ce que te dit pBpG simplement parce qu'il travaille pour Microsoft. Ça aussi, c'est typique d'un étudiant inexpérimenté.

Si un mec qui n'a jamais essayé Linux t'affirme que Windows est mieux, tu vas le prendre au sérieux ?

Je te juge sur les bétises que tu ecris ici, le fait que tu ne répondes jamais quand on te demande d'étayer tes dires avec des exemples ou du code, et ton CV sur ton site qui est celui d'un débutant.

La façon dont tu réponds aux mises en doute de tes compétences est également révélatrice.

melanger du C++ avec de l'objective C, c'est bien une idee de programmeur C++ ca, car cela n'a aucun interet.

Grandis un peu.

Entre autres interêts, il n'y a pas de toolkit graphique pour Objective C (à part celle de Mac OSX bien sur, mais ailleurs...), et les wrappers GTK+ ont été abandonnés depuis longtemps parce que personne ne les utilisait. Ou trouve un bon parser XML en Objective C par exemple.

Ensuite, compare la taille minimale d'une classe Objective C avec celle d'une classe C++. Si tu dois manipuler un grand nombre de petits objets, il est pratique de t'affranchir du runtime ObjC.

Je ne jamais dit que les templates étaient plus crades que des #define, mais qu'au niveau des concepts c'est la même chose

Non, les templates sont beaucoup plus puissants et flexibles.

Maintenant, peut-être quoi ça te convient mieux pour je ne sais quelles raisons, mais pour faire du C++ au taf 40h/semaine, je peux t'assurer que tous les jours ou presque je butte sur des trucs qui seraient beaucoup simple à faire de manière élégante en C

Comme quoi par exemple ?

Pour l'instant tu donnes plutôt l'impression de quelqu'un qui fait du C++ sans savoir bien s'en servir.

Si, ça fait avec des #define

Montre-moi comment tu fais de la spécialisation de templates avec des #define, par exemple.

Non, les méthodes virtuelles sont _très loin_ de permettre tout ce que permettent les pointeurs de fonction, mais alors très loin.

Exemple ?

Ah, je savais bien qu'il y avait une bonne raison pour laquelle ça n'avait pas été fait. Ça plus les vendeurs de compilo qui se tirent la bourre pour faire leur sauce.

En C++, ta fonction elle se trouve une fois par fichier cpp et par type de données manipulé.

Le linker ne garde évidemment qu'un exemplaire de la fonction pour chaque type, c'est à dire pas tant que ça (tu n'appliques pas un sort<> sur des centaines de types différents non plus), et vu les capacités des machines actuelles, c'est négligeable.

polution du cache

Ça c'est un vieux mythe dont l'origine semble être l'inlining à outrance dans des templates mal écrit. Les templates ne posent pas de problèmes de perf à l'execution, c'est même le contraire : il n'y a qu'avec des templates que tu aura les meilleures perfs, justement parce que tu peux génèrer le code optimal pour ton cas. Ça n'est pas un hasard si Blitz++, une lib de calcul scientifique pour C++ dont les perfs également ou dépassent le code équivalenet en Fortran, est entièrement à base de templates.

de la mémoire, du disque dur

Tu as regardé les prix de ces choses-là dernièrement ? Ça ne coute plus rien. Ça n'est pas avec du code que tu vas bouffer ta mémoire, c'est avec les données qu'il traite. Avoir une fonction instanciée même une centaine de fois n'aura aucune différence.

temps de compilation affreusement longs, nécessité de recompiler toutes les application si un bugfix ou une mise à jour est appliqué dans la lib

Ça c'est hélas vrai.

Sans compter que la méthode C à base de pointeurs de fonction permet de faire des choses qui ne sont pas réalisables avec la méthode C++

C'est bien sur totalement faux. C'est même l'inverse, les templates t'affranchissent de la contrainte d'avoir une interface commune. Quand std::sort<> est instanciée sur un tableau d'int, derrière tu te retrouves avec l'operateur [] pour acceder directement au tableau, au lieu d'appels à des fonctions pseudo-virtuelles. Et si tu veux avoir une hierarchie globale, rien ne t'empèche de la faire.

Et bien sur, avec les templates tu restes type-safe et tu n'as pas besoin de caster dans tous les sens.

Ceci dit, le style tout objet (Ruby, Java) marche aussi très bien, l'expérience prouve qu'on développe plus vite avec, et l'absence de vérification de type n'est pas un si gros problème. Restent les perfs, ou C++ reste imbattable.

- pour le bas niveau : kernel, drivers et qq applis specifiques => C

Ben non, C++ justement.

- pour le reste (90% AMHA) => Java

Sauf les applis desktop, genre traitement de texte, mailer, etc... Tu ne refera pas un équivalent de KDE en Java par exemple.

Ceci dit, je suis d'accord, Java est un bien meilleur langage que C++, et c'est bien dommage qu'il ne puisse pas le remplacer partout.

Normalement si tes contrats (preconditions et postconditions) sont bien écrit,

Donc, en pratique, tu sais qu'ils ne le seront pas

ils ne doivent pas être modifié quand le code change, sauf si tu t'es planté dans tes specifs

Et en pratique, les spécifs changent.

Je te l'accorde, c'est assez idéaliste comme point de vue.

Oh, si peu :-).

C'est pas un troll, il a raison sur tous les points qu'il évoque.

Ben j'essaye, mais plus j'essaye plus je pense que tu es à coté de la plaque

Non, je suis pragmatique. std::vector<> c'est du C++. Tu peux dire "c'est pas du C++, c'est une lib", en pratique ça fait partie de ce que tu peux utiliser en standard quand tu fais du C++. Pareil pour les libs Java.

Si tu veux faire avancer ton code, le plus rapide c'est d'arreter les trolls et d'utiliser les design patterns sur une plateforma adéquate et le langage adapté aidé par un framework solide.

T'es consultant dans la vie réelle ? :-)

Java c'est plus qu'un langage, et STL c'est en plus du C++ mais intimement lié à C++.

Oui, on est d'accord.

Non, c'est mieux quand on spécifie l'ABI (encore un truc que Java et C# ont fait).

Paradoxalement, C++ a beau être énorme, il n'a pas spécifié assez de choses (la lib standard et l'ABI).

la notion de contrats(pré/post condition sur les méthodes et invariants de classe) qui permet de spécifier le protocole d'utilisation d'une classe plus formellement que sa signature seule et ainsi augmente la confiance que l'on peut avoir sur du code fournit par une tierce personne (principe de réutilisation).

En théorie oui. En pratique, c'est le genre de truc que les programmeurs detestent parce que c'est extrèmement chiant à maintenir. Trop lourd, trop contraignant. Chaque fois que tu changes le code d'une méthode, il faut changer le contrat aussi.

A part pour du code "mission critical", tu ne vas jamais réussir à imposer ça à une équipe de développeurs.

On ne l'explique pas, parce que c'est faux (à moins d'avoir un compilo C++ vraiment pourri).

Ou alors tu as une notion très particulière de ce qui est "équivalent".