Reprise du message précédent :

Tu aimes les mobilettes

Moi, je connais linux, je sais très bien l'utiliser, et bien je préfère windows

et moi c'est l'inverse

moi je suis sous linux et je vous em

 
Figure 1 : linux ne supporte pas les phrases trop longues

Oh quoi ici, on est pas vendredi, hein

ben si justement

 
On va tester !
 

 
Juste par moral Linux est de toute façon la meilleure solution.
 
Tu dois en être dépourvu.

Ah ouais m*rd* ?! C'est pour ça que tout le monde est parti autour de moi

PUT*IN DE BAN IMAGES §§§§§§§§§§§§§§§§§§§ /FOU /FOU/ /FOU/

 
T'imagines même pas, c'est le genre de mec à jouer avec un grand couteau

Ca dépend des besoins

 
On ne t'a jamais dit que l'informatique, c'est un loisir de riche ?  
 

 
Je crois que tu ignore complétement le cout de développmeent d'un soft...
 

 
Si linux devient payant au prix qu'il est censé couter par rapport au temps que les gens ont passé à l'écrire, tu es pas prêt de pouvoir te le payer. Parcequ'en plus, le code sous linux a souvent été réécrit de nombreuses fois tellement il était misérable au début (et coucou à) la pile IP de linux, qui doit en être à sa 5eme version).

 
  Dans quel cas Linux ne convient pas?

 
 
Oui, j'ai pas le moral, et j'ai un gros kafar

Non mais les os c'est comme les voitures, t'en as pour ton argent !
T'imagine pas avoir un ferrari au ptix d'une twingo !

 
Perso, il ne me convient pas car je bosse toute la journée sur Solaris, et quand j'arrive le soir chez moi je préfère jouer à HL² ou WoW plutôt que de coder en C

 
tous
 
Tu as un truc que tu peux faire au moins aussi bien sous linux que sous windows ?

 
Coder.
(ahhh, les core dumps)

Jeux , se faire chier à l'installer et trouver des programmes qui marcdhent aussi bien que ceux de win !

Tiens un chocobn de l'amour !    

 
  Justement ça ne marche pas comme ça.

 
Il faut vraiment que je réponde ? Parceque justement, j'en suis revenu

 
  Je réponds la même chose TOUS.

 
 

 
Tu peux pas faire une réponse sérieuse ?

 
Je veux bien.
Pas pour troller, par vraie curiosité, j'ai plus codé sous Windows depuis... Win98, donc mon avis est un peu biaisé... Par MP si tu veux, qu'on laisse les trolls s'amuser

D'accord c'est pas encore parfait... Reviens dans 5 ans et on en reparle.

Je crois que je suis plus souvent ban image que pas ban image !

 
dakor
 
Je me présente. Je suis spécialiste depuis 10 ans en programmation C++ de haut niveau. J'ai travaillé sur tout une variété de systèmes et de compilateurs dans de nombreuses missions. Un jour, on me propose une mission : un développment en C++ sous linux. Je me dit chouette, enfin une nouveauté. J'était assez enthousiaste après avoir lu quelques articles sur cet OS. J'en bavais d'avance.
 
Et enfin, je commence ma mission. Première étape, installation et configuration de l'OS. La première partie se passe bien, la redhat s'installe comme un charme et reconnais tout sans problème sur ma station de travail. Je lis mon mail, surf sur le web (à la recherche de documentations techniques bien sur), et accède aux ressources partagées des autres machines. Bien. Commençons maintenant à relire quelques spec. Je lance OpenOffice... Je lance OpenOffice ... Ah non, il avait pas planté, il est juste long à ouvrir, pardon. C'est pas grave, ouvrons les documents de spéficication : MAIS C'EST QUOI CETTE HORREUR. Les shémas sont explosés, le mode révision perdu, les polices ont viré au grand n'importe quoi (mention particulière aux polices utilisées comme bibliothèque de symboles techniques). Bon, je ferme cette chose et je vais me l'imprimer depuis autre autre machine. Je met le document dans un dossier partagé de mon PC, et vais embêter un des développeurs sous windows. Voisinage réseau, et ... MAIS OU EST MA MACHINE ?. Rien n'y a fait, après des heures de configurations de samba (avec swat, avec l'outil de redhat qui plante, à la main, tout seul ou avec l'aide de forums), bide complet. Impossible d'acceder à la machine linux depuis les autres machines du réseau. Je me renseigne un peu sur le projet samba, et j'apprends qu'ils ne travaillent que par reverse engeenering sur les protocoles, et qu'ils sont extrèmements en retards. Ici, je suis dans un réseau windows 2000 avec active directory et tout le tralala, et bien, ça ne marche pas. La version de samba présente sur ma machine ne reconnait pas ce protocole.
 
Bon, je vais devoir bosser avec toutes mes specs imprimées sur papier, et sans contact réseaux. Merci, on a pas l'impression de retourner en arrière.
 
Bon, commençons donc à travailler. Je fait un premier essai from scratch, je linke avec la librairie fournie par notre fournisseur, ça compile, ça linke.
 
Je lance mon application pour la première fois, plantage. Bon, c'est pas grave, c'est du C++, j'ai l'habitude. Je vérifie mon code, tout va bien. Et même avec un exemple bête, ça plante. Bon, j'appelle le support :
 
- bonjour, je vous appelle, j'ai un problème, ça plante
(je passe sur les explication)
- vous utiliser quelle version de gcc ?
- 3.2 ?
- quelle version de glibc ?
- 2.3.4
- quelle vers
 
Bon, en fait il s'avère que gcc change d'ABI quasiment à chaque version, obligeant à recompiler tout à chaque fois. Sauf que comme notre fournisseur nous fourni des librairies pré-compilées, il faut EXACTEMENT la même version de compilateur, le librairie C++, de glibc, que lui. Sympa. Heureusement que l'on a qu'un seul fournisseur de biblioythèques. QU'es-ce que cela donnerais avec une dizaine de fournisseurs différents, chacun réclamant une version de gcc différente !
 
Bon, passons. J'ai besoin d'un parseur XML. J'ai de la chance, j'ai le choix sous linux. Je porte mon choix sur Xerces. Je l'utilise partout où j'ai besoin, ça marche pas mal. Et un jour : PAN!, je tombe sur un bug. Bon, ça arrive. Voyons sur le site... Ah oui, il est connu. Et corrigé dans la dernière version. Mise à jour de xerces et ... plus rien ne compile ! A quoi cela sert-il de standardiser l'interface DOM si on peut la changer à chaque version ? En effet, l'API de xerces 1 et de xerces 2 n'ont absolument rien à voir. Donc pour mettre à jour, il faut tout réécrire. Merci. Sympa. FInalement, on va le garder notre bug, on va planquer ça dans un coin, mettre un bout de scotch pour que ça tienne, et ça ira bien.
 
 
Maintenant, l'application commence à être un peu grosse et c'est devenu catastrophique de lenteur ! En effet, gcc est vendu comme un compilateur efficace, respectueux des standards, mais on oublie de dire quelques trucs : c'est une charette incroyable. Pas de support des headers précompilés (sauf dans une hypothétique future version, mais de toutes façon, je suis coincé sur la version actuelle), ce qui fait que la compilation est monstrueusement lente. Mais d'un facteur deux par rapport au visual C++ 6 pour le même fichier.
 
Et le link. Ah ce link. Un vrai bonheur. Le visual C++ 6 est globalement 8 à 10 fois rapide pour linker la même application (en enlevant le link différentiel, sinon c'est pire: 20 fois). Résultat : dans les cycles de débuggage intensif, je perds tellement de temps que ma productivité est divisées par deux ou par trois par rapport à ceux qui font la même chose sous windows (à machine égale bien sur).
 
Et alors pour débugger, ...
 
Je croyais que faire pire que le link n'était pas possible. Et bien si !
 
Sous linux, il n'y a qu'un seul débugger : gdb. C'est con, mais c'est comme ça. Tous les debuggers que l'on trouve sous des surcouches graphique à gdb. J'installe toute une série de débuggeurs, et je les testes.
 
Alors, on commence par supprimer ceux qui n'arrivent pas à charger mon binaire (il fait 100Mo), ceux qui sont incapables d'afficher les sources ensuite (gvd parse toutes les sources, au demmarage, vu la taille, c'est pas une bonne idée, je l'ai tué après une heure), ceux qui ont une interface pourrie et ... il y en a plus un seul.
 
Bon, ne gardons que ceux qui ont une interface pourrie alors. Je fini par utiliser ddd.
 
La commande la plus utilisé dans ce débugger est : "restart debugger". C'est génial comme truc, il perd pieds tous les deux ou trois lancement d'application, se met à s'arrêter n'importe ou, est incapable d'afficher la moindre variable, bon, on recommence (et au passage, on perds les points d'arrêts et les "watchs" que l'on avait posé).
 
Ensuite cet outil est grandiose pour afficher du code. Pas de coloration syntaxique, pas de recherche dans les fichiers ouverts (bon, il faut que je pose un point d'arrêt dans cette méthode, lisons tout le fichier pour la trouver... MERDE, je suis dans le fichier généré par yacc...). Et un vrai bonheur pour lire le contenu des variable, puisqu'il ne reconnais que les tpyes définis dans mon application. Je veux avoir des informations sur un ifstream, ou sur une des classes provenant des bibliothèques fournisseurs, et j'ai le droit à un laconique "incomplete type". Sans compter cet affichage sous forme d'arbre qui est incapable d'avoir un placement correct, et que ça ne dérange pas d'afficher 25 fois la même variable.
 
C'est génial ce débugger. En fait, j'ai généralement plus vite fait d'aller sur une machine windows pour essayer de comprendre ce qui se passe. Au moins, le debugger du visual, il est capable d'afficher toutes les informations que je lui demande.
 
Encore une petite méchanceté pour la route ? Il ne vérifie pas ou on pose les breakpoints. Donc si vous le mettez sur une ligne ou il n'y p pas de code à exécuter, il ne s'arrêtera pas. Bon, on s'y fait. Mais là ou ça devient drôle, c'est que l'on rajoute une ligne de code plus haut, ça décale le code, mais pas les points d'arrêts, donc il ne s'arrêtes plus. Sympa ça.
 
Bon, maintenant je vais devoir attaquer le profiling de l'application. Il va falloir que j'exploite ce que me sortent valgrind et gprof, je crois que je vais avoir de la lecture. Beaucoup de lecture. Au moins pour comprtendre comment marchent ces outils. Avant de lire leurs mégas-octets de logs divers et variés (merci à valgrind qui me sort tous les problème mémoirre de X, notamment leurs utilisations de variables non initialisées, mais c'est mon application qui m'interresse).

 
Ca fait bientot 15 ans que j'entens ça à propos de linux

tain non y nous ressort sa vieille merde

Je croyais que le premier noyau était né en 92  
edit: 1992 bien sûr

 
septembre 1991
 
Et on est en 2005 ...
 
bientot 15 ans

Avec toute les conneries de brevet logiciel, de drm et de plein d'autre connerie je sais pas pourquoi mais il m'arrive a avoir peur  

 
ma vieille merde ne contient que de la vérité

 
REVIVAL  
 
 

Et bien sûr tu l'utilises depuis la premier version    

 
Ma première install date de 1993 ou 94
 
Un noyau 1.3 qui reconnaissait pas les bibliothèques dynamiques, avec un X ou on était content quand il se lançait, et un windows manager de kalitai (twn, ou fvwm pour les riches)

  je m'étais fourvoyé comme un porc  

 
Je confirme plusieurs points rencontrés, notament les problèmes de versions entre gcc et des libs propriétaires (mais je pense que la faute est partagée dans ce cas), les soucis avec staroffice (repris par Sun, c'est plus pareil maintenant).
Pour le debugging je ne saurais pas te dire pour gdb, j'utilise dbx de Sun, et avant celui d'HP-UX, je sais plus comment il s'appelle (mais il avait une interface graphique géniale).
 
Par contre pour le debugging, je trouve que sous Windows ça manque cruellement de pouvoir générer un core dump utilisable, car surtout sur les gros programmes, tous les bugs ne sont pas facilement reproductibles.
 
Dans l'ensemble, tu as quand même eu un amoncellement de malchance (Murphy est passé par là ), car tu as eu tous les problèmes sans les avantages.