Bon, comme j'ai participé au troll, je me permets de répondre, en te demandant où tu voyais des attaques personnelles. J'ai surtout vu des gens (dont moi), qui se demandaient un peu pourquoi se faire chier à compiler à la main des applis existant déjà sur la distrib sans raison apparente particulière...
Apparemment, le gros reproche que je faisais (ne pas donner de détails) est en réalité mal placé, vu que sur le site funix ferait les explications que je demandais. :-) Mais je trouve qu'il aurait dû le dire plus clairement.
« Euh. A partir du moment où tu utilises des outils sans te poser de question, sans tester, sans garder un esprit critique tu peux aussi installer windows. »
T'avoueras que c'est quand même un peu le but de Ubuntu : « Linux for human beings ». Cela dit, tu déformes mes propos : ce que je dis, c'est que se contortionner pour compiler un soft qui existe déjà dans le dépôt, si ce n'est pour activer des options particulières, je ne vois pas trop l'intérêt, car c'est une duplication d'effort. Plus exactement, je ne vois pas trop l'intérêt d'en faire un journal (je suis d'accord, d'un point de vue apprentissage perso, c'est pas forcément inintéressant).
Je ne connais pas bien Ubuntu, mais s'ils font comme pour Debian, il est possible de récupérer les sources du paquet qu'on veut utiliser, et donc faire la compilation soit-même - du coup, on peut regarder le makefile, faire des diff par rapport à la version « originale » (celle qu'on télécharge sur le site officiel), et voir ce qui a changé - et on gagne quand même pas mal de temps. Alors bien sûr, ça fait moins bidouille, mais c'est quand même plus constructif. Comme je l'ai dit plus bas, c'est le côté "pas vraiment de détails" qui me gêne dans ce journal. funix en a trop dit ou pas assez.
« De plus il y a un intérêt évident : tester des nouvelles versions, remonter des bugs, participer... c'est du logiciel libre. »
Ah mais ça, c'est très bien ! C'est juste que ça n'a absolument pas transpiré dans le journal !
« Et contrairement à ce qu'en dit Gérald, Ubuntu n'est pas moins prévu pour la ligne de commande que debian ou gentoo. Elle est prévue pour fonctionner "presque" sans réglages. Mais on peut toujours accéder à tous dans un second temps. »
Attention, il ne faut pas confondre « ligne de commande » (et là nous sommes d'accord, Ubuntu est encore un Linux aux dernières nouvelles, et donc on peut parfaitement s'en servir) et compilation des applications. Dans ce dernier cas, en effet, compiler des bibliothèques à la main, sans faire de paquet ni rien, c'est prendre le risque de casser son système de paquets et l'arbre des dépendances, et c'est franchement pas très malin (comme il a été dit plus bas, le seul cas où c'est vraiment justifié, c'est quand on a besoin d'une option/version spécifique du logiciel).
Bien sûr, mais dans le journal je n'ai vu mentionné nulle part que c'était pour activer une option bien précise (j'ai peut-être mal lu ou mal compris, cependant).
J'ai aussi certaines applications compilées à la main, mais parce que j'en ai le besoin. Si c'est pour montrer les difficultés à compiler une application, et comment on a résolu les problèmes, pourquoi pas, mais alors il faut être bien plus précis dans le récit ! :-) Sinon, je persiste : il existe, que ce soit en version source ou en version binaire, des paquets dans le dépôts faits uniquement pour être installés.
Euh. A partir du moment où tu utilises le noyau fourni par ta distrib, et si une application existe dans le dépôt, a priori tout va fonctionner correctement, et y'aura pas besoin de compiler.
De plus, compiler une application et la configurer sont deux choses totalement différentes : dans le premier cas, c'est le but de la distribution de compiler à ta place - ou au moins d'utiliser le système de paquetage pour compiler les sources (apt pour les sources, ça existe, et comme ça on peut rajouter les flags qu'on veut, tout en ayant une base dpkg à jour) ; configurer une application par contre est évidemment du ressort de l'admin de la machine.
Bref, en effet, je vois mal l'intérêt de s'embêter à compiler des applications pour une distribution proposant celles-ci (et qui a donc un mainteneur qui se fait suer pour qu'elle fonctionne).
« Faire ce genre de loi, c'est aller à contre courant de la sacro-sainte "séparation de l'Église et de l'État". »
J'en sais rien non plus, mais le côté « sacro-saint » ne l'est réellement qu'en France (en Allemagne les écoles publiques sont aussi chrétiennes, si je me souviens bien, par exemple).
« je ne vois pas en quoi la comparaison est stupide. Les croyants sont "bridés" par la religion pour les athés puisqu'ils refusent toutes sortes de "libertés" qui nous sont accordées. Je parlais d'hommes et de femmes mais j'aurais du préciser. »
Non, lorsqu'on parle d'hommes au pluriel, on peut vouloir parler du genre humain, et d'ailleurs c'était très clair. Quelques remarques cependant :
« C'est sûr qu'il ya besoin de chiffre hein.
Le milieu de la prostitution n'a rien a voir avec celui de la pornographie. »
Je pense que tu changes le contexte : là on parlait (avec B. Lahaye) de pornographie en France, selon moi. Je me souviens d'une émission de Rive Droite - Rive Gauche, où deux stars françaises du X étaient invitées, dont l'une qui parlait de l'enfer du porno dans les années 80. En fait, les deux avaient discuté sur leurs conditions de travail respectives, et là où la première expliquait (dans son bouquin entre autres) la peur du SIDA, le machisme ambiant, etc., l'autre au contraire expliquait que c'était extrêmement décontracté, et que tout se passait bien. Il faudrait donc savoir comment se passe un tournage porno de nos jours en France.
Pour ce qui est de la prostitution et des pornos dans les pays pauvres, je te rejoins.
En pratique dans les UFR de sciences, et en particulier dans les départements informatiques, les environnements UNIX/Linux ne sont pas rares.
Par contre, dans les autres départements, c'est un peu la misère - et pour cause : un grand nombre d'applications n'existent parfois que sous windows, et sont "leader" sur le marché - du coup, lorsque la fac a les sous (et qu'elle ne doit pas les investir pour virer de l'amiante de ses murs ;-) ), elle investit dans les licences, histoire d'avoir un avantage sur les facs qui ne forment pas (encore) au même soft...
Euh. Lorsque l'IUT donne une formation extrêmement solide, on change aussi ? Tous les IUT ne sont pas égaux, et franchement, je vois la différence de formation d'un IUT/BTS à l'autre...
Pas de problème. Étant donné que j'ai pris la remarque du dessus pour un mauvais troll, j'ai enchaîné. Et puis, c'est la classe d'avoir une récompense à son nom. :-)
« Ce n'a été un évenement mondial que parce qu'on a bien voulu le montrer comme tel. Et puis dire que ça a eu une portée mondiale alors que ça n'a touché qu'une ville des Etats-Unis, c'est un peu exagéré. »
Pardon ? D'une, dans le WTC, différentes personnes de différentes nationalités travaillaient là-bas : c'était un centre d'affaires international. De deux, ça a eu un véritable impact au niveau mondial, et le nier, en disant que « ça n'a touché qu'une ville des Etats-Unis », c'est un discours à la limite de celui où l'on parle de « détail de l'histoire ». Seulement comme ça touche les USA, c'est moins grave, n'est-ce pas ?
Enfin, estimer que la portée symbolique de cet attentat est nulle, c'est faire preuve d'un manque d'ouverture d'esprit flagrant.
« Donc si on part de l'équation symbolique "1 centrale = 1000 éoliennes" mais que l'on prend en compte les points précédents on peut arriver à quelque chose comme "1 centrale = 600 éoliennes" par exemple. »
Non, car si toutes tes affirmations sont vraies, comme on ne sait pas si on parle de l'énergie produite par une centrale directement à sa « sortie » ou bien s'il s'agit de l'énergie qu'on peut consommer dans les ménages, l'effet n'est pas le même tu en conviendras (le posteur précédent n'a pas précisé).
De plus, tu donnes arbitrairement une diminution de 400 éoliennes, mais tu n'en sais rien (moi non plus du reste). Ca pourrait être plus, ça pourrait être beaucoup moins.
« Dans le cas de Linux, on a un megalomaniaque qui decide (avec ou sans justification) ce qui est bon ou non »
C'est tout bonnement faux. Linus le dit lui-même : l'une des premières choses qu'il a dû apprendre à faire, c'est déléguer. Au final il a le mot de la fin si « en-dessous » ils n'arrivent pas à se mettre d'accord quant à certaines orientations techniques, oui. Un peu comme un chef de projet, quoi. Il fait confiance aux gens à qui il délègue.
Le côté mégalomane, je ne le vois pas vraiment. A-t-il un ego très fort ? Oui, assurément. Et là encore, c'est l'un des premiers à dire quelque chose du genre "Le plus simple pour être célèbre, c'est de commencer quelque chose, et de laisser tout le monde compléter l'embryon de projet - en ensuite d'en récupérer tout le mérite" (ce à quoi, Larry Wall, papa de Perl, aurait répondu « vas-y mon frère, dis-leur ! »)
J'ai dû être un peu trop cryptique, donc je vais essayer de mieux m'expliquer : dans une base de données orientée XML, les données peuvent très bien être traduites en interne par des structures de données tout à fait « binaires » : il faut juste qu'il existe une DTD ou un schéma XML disponibles (et comme on parle de gros documents, il serait étonnant que ça n'existe pas).
L'indexation de documents XML et de leur contenu, ça existe déjà depuis un moment. Et puis, rien n'empêche au moment de l'analyse d'un fichier importé en XML de le forcer un peu à avoir une certaine gueule pour faciliter les accès dessus.
« XML ça reste du eXtended Markup Language si je ne me gourre pas - et c'est juste une normalisation du stockage "raw". »
Je ne vois pas ce que tu veux dire par là. Les SGBD/XML ont le même objectif que les SGBD/R : permettre la persistance des données. Et ne t'en déplaise, il existe déjà quelques systèmes qui permettent autre chose qu'un bête export de tables d'un modèle relationnel vers du XML (sinon, à la limite, autant exporter en CSV).
Le besoin de ce genre de SGBD vient entre autres de professions où les critères pour classifier les données sont changeants. Par exemple, une expérience faite par un labo en bio ou en chimie, et qui coûte cher - donc pas possible de recommencer tous les jours - aura tout à gagner à être stockée dans une base avec un langage semi-structuré (par ex. XML ;-) ), car au fur et à mesure qu'on aura besoin de rajouter des critères pour analyser les résultats, on pourra. Alors qu'avec un SGBD/R Classique, une fois le schéma réalisé, rajouter une colonne dans une table alors que la base est déjà en train d'être exploitée tient de la gageure.
« Après, avec une spécification de type de document (DTD & Co) on précise ce qui est acceptable pour un usage. »
Non. Avec une DTD ou un schéma XML, tu *types* ton document, et c'est ce qui fait toute la différence : on passe d'un bête fichier texte « plat » (et donc autant chercher à grands coups de regexps dessus) vers un document semi-structuré, un arbre, dont les noeuds sont ordonnés (oui, je me répète), étiquetés, et qui correspondent à des types. Et quand on a un type, on peut déjà faire tout un tas de choses.
Par exemple (on sait bien sûr aussi faire dans les SGBD/R) :
<!ELEMENT adresse (rue,zipcode,ville,pays)>
<!ELEMENT rue (#PCDATA)>
<!ELEMENT zipcode (#PCDATA)>
<!ELEMENT ville (#PCDATA)>
<!ELEMENT pays (#PCDATA)>
Bon ben, si j'essaie maintenant d'interroger ma base de personnes en demandant des trucs du genre
for $x in doc("mes_personnes.xml")/identite/adresse return $x/rue
Parce que la base connaît le type des données, elle saura inférer toute seule comme une grande que l'adresse ne fait pas partie du type « identité », et la requête renverra vide.
Des choses comme ça, on sait très bien faire, et le langage XQuery est au moins aussi puissant que SQL (c'est un peu normal), voire plus.
Par définition, lorsque tu optimises, tu risques de perdre en lisibilité.
L'optimisation intervient tout à la fin, quand tu as déjà fait les bons choix pour ton logiciel (par exemple en utilisant un tri rapide ou un tri fusion pour trier tes éléments). Choisir un bon tri n'est pas faire de l'optimisation, c'est faire de bons choix de conception.
Ce que j'appelle « optimisation » pourrait sans doute plutôt être appelée « micro-optimisation » : on se rend compte qu'on passe 90% du temps dans une boucle, alors on essaie de voir si on ne pourrait pas améliorer la façon dont elle s'exécute. Maintenant, si ta boucle est en réalité un tri à bulle, tu auras beau optimiser et gagner 10 ou 20 % en perfs, tu seras toujours plusieurs ordres de grandeur derrière un tri rapide ou fusion.
C'est pour ça que les (micro-)optimisations viennent en fin de développement : on a déjà réglé le plus gros des détails, et on a déjà une application raisonnablement rapide.
Donc, de mon point de vue, optimiser un tri à bulles ou un tri rapide, c'est *toujours* de l'optimisation. C'est juste que dans un cas, tu optimises un truc pas très efficace.
« XML est un format d'échange de données, il peut être utilisé pour exploiter en "temps réel" de petites quantités de données (surtout avec les machines actuelles), mais il n'est pas adapté à remplacer une base de données - surtout lorsque le volume stocké augmente. »
Tu vas vexer beaucoup de chercheurs en SGBD, là. Il ne faut pas confondre la forme finale d'un document XML, le document « plat », et ce qu'est un document XML, à savoir un arbre ordonné et étiqueté. La forme finale, c'est ton fichier « lisible par un humain » (qui a pris deux-trois aspirines avant de lire le fichier de 3000 balises). Mais la base en elle-même fait exactement comme les autres : elle indexe les documents, les noeuds fils, les noeuds parents ...
« Mais stocker en XML, dans un fichier 'plat', des données qui peuvent se montrer volumineuses et sur lesquelles on a besoin d'un accès direct: AMA non. »
Du point de vue d'une BDD, un document XML est un arbre (ou un graphe, si tu utilises les IDREF - mais là t'es déjà bien vicieux ;-) ). Rien n'empêche la base d'avoir cette structure version « binaire » (structure de graphe/d'arbre donc) dans la base, et de ne dumper les fichiers XML que lorsque tu en as besoin. D'ailleurs c'est plus ou moins ce que fait BDB/XML : tu importes tes fichiers dans la base, et il garde le tout chez lui, dans une forme interne qui l'arrange. Ensuite, tu peux faire des requêtes sur la base avec XQuery, et récupérer un document au format XML en sortie.
En ce moment, beaucoup d'efforts sont fournis pour adapter les optimisations connues des SGBD/R vers les SGBD/XML. L'indexation est particulière, car si dans un SGBD/R on a des types fixes, avec des lignes de table de taille fixes elles aussi, XML est un langage semi-structuré : il faut en tenir compte.
« Tous ça, c'était surtout utile avant, quand les compilos étaient cons comme des balais. Aujourd'hui, ils optimisent tellement le code qu'il vaut mieux les laisser faire. »
Ben tout dépend de quel compilateur on parle. :-)
Au risque de me répéter vis à vis de ce que j'ai pu dire dans d'autres réactions, gcc n'est pas (encore) le plus optimisant des compilos, et on peut clairement faire mieux à la main, si on a le temps et la volonté d'apprendre l'assembleur de la machine cible. Alors que pour faire mieux à la main que certains autres compilateurs, il faut se lever très tôt.
« Enfin, un argument sensé que j'ai lu je ne sais plus où:
avec des "hacks" comme ça, tu gagnes un peu, mais ce peu va se réduire avec les années (progrès du compilo/métériel). Par contre, tu perds en lisibilité, et pour toujours... »
C'est vrai. C'est pour ça que les deux grandes règles de l'optimisation sont :
1°) N'optimise pas.
2°) (pour experts seulement) N'optimise pas encore.
L'optimisation vient en toute fin de développement, lorsque ton code fonctionne déjà bien, sans bug, etc.
Les manipulations de bits, en règle générale, sont tellement dépendants de la machine qu'il est sans doute plus « simple » si on connaît l'architecture cible d'éditer le code assembleur et de les faire soit-même (ou bien d'insérer le code ASM dans le source C, mais non seulement c'est crade, mais en plus les options d'optimisation sont désactivées automatiquement dans certains compilateurs quand ils détectent ce genre de magouille) :-)
En fait, dès que tu as des ressources matérielles très limitées, ce genre d'algorithmes peut faire gagner beaucoup de temps - ou bien de place, quand le problème tient plus au nombre de registres disponibles, par exemple (exemple tout bête : l'échange du contenu de deux variables à base de XOR).
Sinon, lorsqu'on entre en phase d'optimisation (et donc que le logiciel tourne déjà bien), et qu'une boucle doit être optimisée, parfois avoir recours à des opérations sur les bits peut accélérer les choses - mais j'ai l'impression que c'est très dépendant de l'architecture cible.
Bon, je t'ai pertinenté, mais quand même, j'ai envie de répondre un peu à certains trucs :
« La solution que j'ai trouvé est simple : laisser la gestion de la mémoire, tâche fastidieuse et source de nombreuses erreurs, à un gestionnaire automatique, prévu pour ça. C'est-à-dire en gros, ne pas programmer en C. »
Si si, c'est de la programmation en C. Utiliser un ramasse-miette externe n'est jamais une mauvaise idée si c'est la seule chose qui te gêne dans le langage.
« il est surprenant que, malgré de longues et brillantes recherches en théorie des langages, on se tape encore un langage aussi difficile à programmer que le C. »
Le C n'est pas un langage « difficile ». Sa syntaxe est l'une des plus simples qui existe, je trouve : il y a peu de concepts à retenir, et le plus difficile d'entre eux, le pointeur, est une notion qu'il est nécessaire de connaître si on veut faire de l'informatique professionnellement - enfin je trouve.
Par contre, pour paraphraser certains grands intervenants de fr.comp.lang.c : « C n'est pas un langage de débutant », et « C is a sharp tool ».
Là où par contre je suis tout à fait d'accord : utiliser le langage C est la plupart du temps inutile, car d'autres langages permettent de faire la même chose plus rapidement, avec beaucoup moins de bugs.
Le C est un langage à destination des programmeurs qui savent ce qu'ils font. Il est très important d'en avoir déjà fait à mon avis pour savoir ce qui peut clocher dans des langages de plus haut niveau, mais pour autant, à moins de programmer pour de la haute performance ou du « bas-niveau », utiliser le langage C dans les programmes de tous les jours relève souvent du masochisme.
Ca vient sans doute de gcc 4.x
J'ai testé sur une debian testing, avec gcc 4.0 et 4.1 : bug ;
Sur une red hat customisée : gcc 3.2.3, puis un gcc pré version 4 (gcc-ssa) : ça marche. Idem avec gcc 2.96.
En fait, avec gcc 4, il faut lancer l'optimisation pour que ça marche correctement .
« À ma connaissance, c'est plutôt ton système qui fluh si la sortie est un terminal (je crois qu'il le fait aussi pour les socket et les pipes, non ?) »
Non non, il a raison, c'est le '\n' qui fait que le vidage du tampon est effectué pour printf().
« Ben faut dire que quand tu cherches un bug dans une application multithreadée avec tâches concurrentes, des communications entre objets par signaux/slots et des communications interprocessus genre avec un DCOP serveur ou un kioslave, le débugger ça fait plus perdre de temps qu'autre chose. »
Sauf qu'en fait, dès que tu passes à du multi-process/multi-thread, l'utilisation de printf sur la sortie standard est plutôt déconseillée, vu que tu ne maîtrises pas l'ordre d'affichage des messages et que tu peux même en avoir certains qui passent à la trape.
« d'après mes propres tests non scientifiques et à mon humble avis, ICC n'a rien d'exceptionnel. »
Tout dépend quels programmes tu fais tourner. L'utilisation d'IPO (inter-process optimization) est quand même un super booster de performances. Je ne parle pas de 50% d'accélération (même si ça peut arriver), mais même avec 20%, c'est déjà exceptionnel.
Lorsqu'en plus tu utilises des logiciels qui sont plutôt du genre à boucler 90% du temps sur une boucle avec des codes réguliers (en gros du code « scientifique »), l'utilisation de -O3 et -ipo fait vraiment des merveilles. Tu peux gagner 40% en vitesse d'exécution par rapport à gcc 3 ou 4 en -O3.
Maintenant, je te l'accorde, pour la plupart des codes concernant le noyau, on s'en fout. Mais pour des codes concernant des flux multimédia, etc., ça peut jouer énormément. Idem pour les codes faisant entrer tout plein de calculs en jeu (calcul 3D, analyse numérique, etc).
Concernant les codes irréguliers, ICC se débrouille beaucoup moins bien, mais reste encore bien au-dessus de GCC.
« Surtout sur les systèmes AMD et sur ceux ayant une ou deux années de vie. »
Bon, je suppose que tu sais que ICC = Intel C Compiler. Ca ne me surprend pas outre mesure que les optimisations soient bien meilleures sur architecture Intel. D'ailleurs, si je me souviens bien, il est fortement déconseillé d'utiliser ICC avec un processeur AMD sous peine d'avoir des applications qui pourraient planter à cause de certaines optimisations effectuées par ICC et qui ne peuvent être faites que sur des archis Intel, parce qu'il y a quand même certaines grosses différences au niveau du modèle de processeur, tout ia32 qu'ils soient chez Intel et AMD. Et oui, ICC utilise très certainement des fonctionnalités non documentées des procs d'Intel.
« Par ailleurs, l'interêt que j'ai pour Gentoo vient plus de sa "hackabilité" que de ses performances. »
Possible, mais le titre du fil est « Performances de Gentoo ». Et je répondais sur ce critère uniquement.
Tu l'as dit, tes tests sont non-scientifiques, et il s'agit de ton avis. Ben il est à revoir, dès lors qu'on parle d'applications mettant beaucoup la pression sur le micro-processeur (et bien sûr, en supposant qu'il s'agisse d'un proc Intel, ce qui fait beaucoup de paramètres à prendre en compte, j'en suis conscient).
Mon objectif dans mon post initial était surtout de bien mettre l'accent sur le fait que
1) Des « distributions » source, ça existe depuis un moment (c'est plus ou moins la norme chez les *BSD), et si effectivement parfois ça peut se révéler un bon point pour les perfs, globalement c'est absolument pas concluant pour le système en général ; je pense aussi à LFS, dans le genre « [meta-]distributions source » ; dans tous les cas, je n'ai jamais entendu ceux qui s'en servaient dire « comme ça je peux vraiment gagner en performances », à quelques exceptions près pour certains programmes très précis.
2) GCC n'est pas encore au niveau des bons compilateurs optimisants, et parmi eux, ICC est vraiment l'un des meilleurs. Donc les optimisations proposées par GCC commencent à peine à avoir un « sens » (il suffit de mater comment les gens de chez MPlayer ont configuré le makefile pour comprendre qu'ils ne font pas vraiment confiance à GCC). Cela dit j'espère très fortement que ça va arriver !
Je ne suis pas du tout anti-GCC, je suis anti-jacky-distrib-linux, et franchement, beaucoup de gens utilisant Gentoo m'ont donné cette impression (ce sont les mêmes qui mettent en avant le côté performances avant les avantages que tu abordes, qui sont cent fois plus importants).
[^] # Re: attaque personnelle ?
Posté par lasher . En réponse au journal Dans le genre maso. Évalué à 2.
Apparemment, le gros reproche que je faisais (ne pas donner de détails) est en réalité mal placé, vu que sur le site funix ferait les explications que je demandais. :-) Mais je trouve qu'il aurait dû le dire plus clairement.
Vala vala.
[^] # Re: J'hallucine! aussi
Posté par lasher . En réponse au journal Dans le genre maso. Évalué à 4.
T'avoueras que c'est quand même un peu le but de Ubuntu : « Linux for human beings ». Cela dit, tu déformes mes propos : ce que je dis, c'est que se contortionner pour compiler un soft qui existe déjà dans le dépôt, si ce n'est pour activer des options particulières, je ne vois pas trop l'intérêt, car c'est une duplication d'effort. Plus exactement, je ne vois pas trop l'intérêt d'en faire un journal (je suis d'accord, d'un point de vue apprentissage perso, c'est pas forcément inintéressant).
Je ne connais pas bien Ubuntu, mais s'ils font comme pour Debian, il est possible de récupérer les sources du paquet qu'on veut utiliser, et donc faire la compilation soit-même - du coup, on peut regarder le makefile, faire des diff par rapport à la version « originale » (celle qu'on télécharge sur le site officiel), et voir ce qui a changé - et on gagne quand même pas mal de temps. Alors bien sûr, ça fait moins bidouille, mais c'est quand même plus constructif. Comme je l'ai dit plus bas, c'est le côté "pas vraiment de détails" qui me gêne dans ce journal. funix en a trop dit ou pas assez.
« De plus il y a un intérêt évident : tester des nouvelles versions, remonter des bugs, participer... c'est du logiciel libre. »
Ah mais ça, c'est très bien ! C'est juste que ça n'a absolument pas transpiré dans le journal !
« Et contrairement à ce qu'en dit Gérald, Ubuntu n'est pas moins prévu pour la ligne de commande que debian ou gentoo. Elle est prévue pour fonctionner "presque" sans réglages. Mais on peut toujours accéder à tous dans un second temps. »
Attention, il ne faut pas confondre « ligne de commande » (et là nous sommes d'accord, Ubuntu est encore un Linux aux dernières nouvelles, et donc on peut parfaitement s'en servir) et compilation des applications. Dans ce dernier cas, en effet, compiler des bibliothèques à la main, sans faire de paquet ni rien, c'est prendre le risque de casser son système de paquets et l'arbre des dépendances, et c'est franchement pas très malin (comme il a été dit plus bas, le seul cas où c'est vraiment justifié, c'est quand on a besoin d'une option/version spécifique du logiciel).
[^] # Re: J'hallucine!
Posté par lasher . En réponse au journal Dans le genre maso. Évalué à 3.
J'ai aussi certaines applications compilées à la main, mais parce que j'en ai le besoin. Si c'est pour montrer les difficultés à compiler une application, et comment on a résolu les problèmes, pourquoi pas, mais alors il faut être bien plus précis dans le récit ! :-) Sinon, je persiste : il existe, que ce soit en version source ou en version binaire, des paquets dans le dépôts faits uniquement pour être installés.
[^] # Re: J'hallucine!
Posté par lasher . En réponse au journal Dans le genre maso. Évalué à 0.
De plus, compiler une application et la configurer sont deux choses totalement différentes : dans le premier cas, c'est le but de la distribution de compiler à ta place - ou au moins d'utiliser le système de paquetage pour compiler les sources (apt pour les sources, ça existe, et comme ça on peut rajouter les flags qu'on veut, tout en ayant une base dpkg à jour) ; configurer une application par contre est évidemment du ressort de l'admin de la machine.
Bref, en effet, je vois mal l'intérêt de s'embêter à compiler des applications pour une distribution proposant celles-ci (et qui a donc un mainteneur qui se fait suer pour qu'elle fonctionne).
[^] # Re: freex
Posté par lasher . En réponse au journal Free: tu le sens mon gros débit?. Évalué à 2.
J'en sais rien non plus, mais le côté « sacro-saint » ne l'est réellement qu'en France (en Allemagne les écoles publiques sont aussi chrétiennes, si je me souviens bien, par exemple).
[^] # Re: freex
Posté par lasher . En réponse au journal Free: tu le sens mon gros débit?. Évalué à 3.
Non, lorsqu'on parle d'hommes au pluriel, on peut vouloir parler du genre humain, et d'ailleurs c'était très clair. Quelques remarques cependant :
« C'est sûr qu'il ya besoin de chiffre hein.
Le milieu de la prostitution n'a rien a voir avec celui de la pornographie. »
Je pense que tu changes le contexte : là on parlait (avec B. Lahaye) de pornographie en France, selon moi. Je me souviens d'une émission de Rive Droite - Rive Gauche, où deux stars françaises du X étaient invitées, dont l'une qui parlait de l'enfer du porno dans les années 80. En fait, les deux avaient discuté sur leurs conditions de travail respectives, et là où la première expliquait (dans son bouquin entre autres) la peur du SIDA, le machisme ambiant, etc., l'autre au contraire expliquait que c'était extrêmement décontracté, et que tout se passait bien. Il faudrait donc savoir comment se passe un tournage porno de nos jours en France.
Pour ce qui est de la prostitution et des pornos dans les pays pauvres, je te rejoins.
[^] # Re: Votre GNUniversité
Posté par lasher . En réponse à la dépêche Du logiciel libre dans les Universités (suite). Évalué à 2.
Par contre, dans les autres départements, c'est un peu la misère - et pour cause : un grand nombre d'applications n'existent parfois que sous windows, et sont "leader" sur le marché - du coup, lorsque la fac a les sous (et qu'elle ne doit pas les investir pour virer de l'amiante de ses murs ;-) ), elle investit dans les licences, histoire d'avoir un avantage sur les facs qui ne forment pas (encore) au même soft...
[^] # Re: pas chez moi, et cela ne semble pas près de changer
Posté par lasher . En réponse à la dépêche Du logiciel libre dans les Universités. Évalué à 3.
[^] # Re: 11 septembre, jour férié ?
Posté par lasher . En réponse au journal Joyeux 11 septembre. Évalué à 2.
[^] # Re: 11 septembre, jour férié ?
Posté par lasher . En réponse au journal Joyeux 11 septembre. Évalué à 2.
[^] # Re: pas chez moi, et cela ne semble pas près de changer
Posté par lasher . En réponse à la dépêche Du logiciel libre dans les Universités. Évalué à 3.
[^] # Re: 11 septembre, jour férié ?
Posté par lasher . En réponse au journal Joyeux 11 septembre. Évalué à -2.
Pardon ? D'une, dans le WTC, différentes personnes de différentes nationalités travaillaient là-bas : c'était un centre d'affaires international. De deux, ça a eu un véritable impact au niveau mondial, et le nier, en disant que « ça n'a touché qu'une ville des Etats-Unis », c'est un discours à la limite de celui où l'on parle de « détail de l'histoire ». Seulement comme ça touche les USA, c'est moins grave, n'est-ce pas ?
Enfin, estimer que la portée symbolique de cet attentat est nulle, c'est faire preuve d'un manque d'ouverture d'esprit flagrant.
[^] # Re: Ca fait plaisir
Posté par lasher . En réponse au journal [HS] Consommation d'électricité. Évalué à 2.
[^] # Re: Pas seulement diminuer la consommation électrique ...
Posté par lasher . En réponse au journal [HS] Consommation d'électricité. Évalué à 2.
Non, car si toutes tes affirmations sont vraies, comme on ne sait pas si on parle de l'énergie produite par une centrale directement à sa « sortie » ou bien s'il s'agit de l'énergie qu'on peut consommer dans les ménages, l'effet n'est pas le même tu en conviendras (le posteur précédent n'a pas précisé).
De plus, tu donnes arbitrairement une diminution de 400 éoliennes, mais tu n'en sais rien (moi non plus du reste). Ca pourrait être plus, ça pourrait être beaucoup moins.
[^] # Re: Ne pas tout croire...
Posté par lasher . En réponse au journal NetBSD : droit dans le mur ?. Évalué à 3.
« Dans le cas de Linux, on a un megalomaniaque qui decide (avec ou sans justification) ce qui est bon ou non »
C'est tout bonnement faux. Linus le dit lui-même : l'une des premières choses qu'il a dû apprendre à faire, c'est déléguer. Au final il a le mot de la fin si « en-dessous » ils n'arrivent pas à se mettre d'accord quant à certaines orientations techniques, oui. Un peu comme un chef de projet, quoi. Il fait confiance aux gens à qui il délègue.
Le côté mégalomane, je ne le vois pas vraiment. A-t-il un ego très fort ? Oui, assurément. Et là encore, c'est l'un des premiers à dire quelque chose du genre "Le plus simple pour être célèbre, c'est de commencer quelque chose, et de laisser tout le monde compléter l'embryon de projet - en ensuite d'en récupérer tout le mérite" (ce à quoi, Larry Wall, papa de Perl, aurait répondu « vas-y mon frère, dis-leur ! »)
[^] # Re: Stockage des données...
Posté par lasher . En réponse à la dépêche Sortie de Tellico 1.2. Évalué à 2.
L'indexation de documents XML et de leur contenu, ça existe déjà depuis un moment. Et puis, rien n'empêche au moment de l'analyse d'un fichier importé en XML de le forcer un peu à avoir une certaine gueule pour faciliter les accès dessus.
« XML ça reste du eXtended Markup Language si je ne me gourre pas - et c'est juste une normalisation du stockage "raw". »
Je ne vois pas ce que tu veux dire par là. Les SGBD/XML ont le même objectif que les SGBD/R : permettre la persistance des données. Et ne t'en déplaise, il existe déjà quelques systèmes qui permettent autre chose qu'un bête export de tables d'un modèle relationnel vers du XML (sinon, à la limite, autant exporter en CSV).
Le besoin de ce genre de SGBD vient entre autres de professions où les critères pour classifier les données sont changeants. Par exemple, une expérience faite par un labo en bio ou en chimie, et qui coûte cher - donc pas possible de recommencer tous les jours - aura tout à gagner à être stockée dans une base avec un langage semi-structuré (par ex. XML ;-) ), car au fur et à mesure qu'on aura besoin de rajouter des critères pour analyser les résultats, on pourra. Alors qu'avec un SGBD/R Classique, une fois le schéma réalisé, rajouter une colonne dans une table alors que la base est déjà en train d'être exploitée tient de la gageure.
« Après, avec une spécification de type de document (DTD & Co) on précise ce qui est acceptable pour un usage. »
Non. Avec une DTD ou un schéma XML, tu *types* ton document, et c'est ce qui fait toute la différence : on passe d'un bête fichier texte « plat » (et donc autant chercher à grands coups de regexps dessus) vers un document semi-structuré, un arbre, dont les noeuds sont ordonnés (oui, je me répète), étiquetés, et qui correspondent à des types. Et quand on a un type, on peut déjà faire tout un tas de choses.
Par exemple (on sait bien sûr aussi faire dans les SGBD/R) :
Bon ben, si j'essaie maintenant d'interroger ma base de personnes en demandant des trucs du genre
Parce que la base connaît le type des données, elle saura inférer toute seule comme une grande que l'adresse ne fait pas partie du type « identité », et la requête renverra vide.
Des choses comme ça, on sait très bien faire, et le langage XQuery est au moins aussi puissant que SQL (c'est un peu normal), voire plus.
[^] # Re: Bravo mais..
Posté par lasher . En réponse à la dépêche La quintessence des algorithmes bit à bit. Évalué à 3.
L'optimisation intervient tout à la fin, quand tu as déjà fait les bons choix pour ton logiciel (par exemple en utilisant un tri rapide ou un tri fusion pour trier tes éléments). Choisir un bon tri n'est pas faire de l'optimisation, c'est faire de bons choix de conception.
Ce que j'appelle « optimisation » pourrait sans doute plutôt être appelée « micro-optimisation » : on se rend compte qu'on passe 90% du temps dans une boucle, alors on essaie de voir si on ne pourrait pas améliorer la façon dont elle s'exécute. Maintenant, si ta boucle est en réalité un tri à bulle, tu auras beau optimiser et gagner 10 ou 20 % en perfs, tu seras toujours plusieurs ordres de grandeur derrière un tri rapide ou fusion.
C'est pour ça que les (micro-)optimisations viennent en fin de développement : on a déjà réglé le plus gros des détails, et on a déjà une application raisonnablement rapide.
Donc, de mon point de vue, optimiser un tri à bulles ou un tri rapide, c'est *toujours* de l'optimisation. C'est juste que dans un cas, tu optimises un truc pas très efficace.
[^] # Re: Stockage des données...
Posté par lasher . En réponse à la dépêche Sortie de Tellico 1.2. Évalué à 3.
Tu vas vexer beaucoup de chercheurs en SGBD, là. Il ne faut pas confondre la forme finale d'un document XML, le document « plat », et ce qu'est un document XML, à savoir un arbre ordonné et étiqueté. La forme finale, c'est ton fichier « lisible par un humain » (qui a pris deux-trois aspirines avant de lire le fichier de 3000 balises). Mais la base en elle-même fait exactement comme les autres : elle indexe les documents, les noeuds fils, les noeuds parents ...
« Mais stocker en XML, dans un fichier 'plat', des données qui peuvent se montrer volumineuses et sur lesquelles on a besoin d'un accès direct: AMA non. »
Du point de vue d'une BDD, un document XML est un arbre (ou un graphe, si tu utilises les IDREF - mais là t'es déjà bien vicieux ;-) ). Rien n'empêche la base d'avoir cette structure version « binaire » (structure de graphe/d'arbre donc) dans la base, et de ne dumper les fichiers XML que lorsque tu en as besoin. D'ailleurs c'est plus ou moins ce que fait BDB/XML : tu importes tes fichiers dans la base, et il garde le tout chez lui, dans une forme interne qui l'arrange. Ensuite, tu peux faire des requêtes sur la base avec XQuery, et récupérer un document au format XML en sortie.
En ce moment, beaucoup d'efforts sont fournis pour adapter les optimisations connues des SGBD/R vers les SGBD/XML. L'indexation est particulière, car si dans un SGBD/R on a des types fixes, avec des lignes de table de taille fixes elles aussi, XML est un langage semi-structuré : il faut en tenir compte.
[^] # Re: Bravo mais..
Posté par lasher . En réponse à la dépêche La quintessence des algorithmes bit à bit. Évalué à 3.
Ben tout dépend de quel compilateur on parle. :-)
Au risque de me répéter vis à vis de ce que j'ai pu dire dans d'autres réactions, gcc n'est pas (encore) le plus optimisant des compilos, et on peut clairement faire mieux à la main, si on a le temps et la volonté d'apprendre l'assembleur de la machine cible. Alors que pour faire mieux à la main que certains autres compilateurs, il faut se lever très tôt.
« Enfin, un argument sensé que j'ai lu je ne sais plus où:
avec des "hacks" comme ça, tu gagnes un peu, mais ce peu va se réduire avec les années (progrès du compilo/métériel). Par contre, tu perds en lisibilité, et pour toujours... »
C'est vrai. C'est pour ça que les deux grandes règles de l'optimisation sont :
1°) N'optimise pas.
2°) (pour experts seulement) N'optimise pas encore.
L'optimisation vient en toute fin de développement, lorsque ton code fonctionne déjà bien, sans bug, etc.
Les manipulations de bits, en règle générale, sont tellement dépendants de la machine qu'il est sans doute plus « simple » si on connaît l'architecture cible d'éditer le code assembleur et de les faire soit-même (ou bien d'insérer le code ASM dans le source C, mais non seulement c'est crade, mais en plus les options d'optimisation sont désactivées automatiquement dans certains compilateurs quand ils détectent ce genre de magouille) :-)
[^] # Re: Bravo mais..
Posté par lasher . En réponse à la dépêche La quintessence des algorithmes bit à bit. Évalué à 4.
Sinon, lorsqu'on entre en phase d'optimisation (et donc que le logiciel tourne déjà bien), et qu'une boucle doit être optimisée, parfois avoir recours à des opérations sur les bits peut accélérer les choses - mais j'ai l'impression que c'est très dépendant de l'architecture cible.
[^] # Re: Heisenbug
Posté par lasher . En réponse au journal printf debugging considered harmful. Évalué à 10.
« La solution que j'ai trouvé est simple : laisser la gestion de la mémoire, tâche fastidieuse et source de nombreuses erreurs, à un gestionnaire automatique, prévu pour ça. C'est-à-dire en gros, ne pas programmer en C. »
Si si, c'est de la programmation en C. Utiliser un ramasse-miette externe n'est jamais une mauvaise idée si c'est la seule chose qui te gêne dans le langage.
« il est surprenant que, malgré de longues et brillantes recherches en théorie des langages, on se tape encore un langage aussi difficile à programmer que le C. »
Le C n'est pas un langage « difficile ». Sa syntaxe est l'une des plus simples qui existe, je trouve : il y a peu de concepts à retenir, et le plus difficile d'entre eux, le pointeur, est une notion qu'il est nécessaire de connaître si on veut faire de l'informatique professionnellement - enfin je trouve.
Par contre, pour paraphraser certains grands intervenants de fr.comp.lang.c : « C n'est pas un langage de débutant », et « C is a sharp tool ».
Là où par contre je suis tout à fait d'accord : utiliser le langage C est la plupart du temps inutile, car d'autres langages permettent de faire la même chose plus rapidement, avec beaucoup moins de bugs.
Le C est un langage à destination des programmeurs qui savent ce qu'ils font. Il est très important d'en avoir déjà fait à mon avis pour savoir ce qui peut clocher dans des langages de plus haut niveau, mais pour autant, à moins de programmer pour de la haute performance ou du « bas-niveau », utiliser le langage C dans les programmes de tous les jours relève souvent du masochisme.
[^] # Re: Heisenbug...
Posté par lasher . En réponse au journal printf debugging considered harmful. Évalué à 2.
J'ai testé sur une debian testing, avec gcc 4.0 et 4.1 : bug ;
Sur une red hat customisée : gcc 3.2.3, puis un gcc pré version 4 (gcc-ssa) : ça marche. Idem avec gcc 2.96.
En fait, avec gcc 4, il faut lancer l'optimisation pour que ça marche correctement .
[^] # Re: Au final...
Posté par lasher . En réponse au journal printf debugging considered harmful. Évalué à 2.
Non non, il a raison, c'est le '\n' qui fait que le vidage du tampon est effectué pour printf().
[^] # Re: ouais
Posté par lasher . En réponse au journal printf debugging considered harmful. Évalué à 4.
Sauf qu'en fait, dès que tu passes à du multi-process/multi-thread, l'utilisation de printf sur la sortie standard est plutôt déconseillée, vu que tu ne maîtrises pas l'ordre d'affichage des messages et que tu peux même en avoir certains qui passent à la trape.
[^] # Re: Performances de Gentoo
Posté par lasher . En réponse à la dépêche Gentoo 2006.1 est prête !. Évalué à 3.
Tout dépend quels programmes tu fais tourner. L'utilisation d'IPO (inter-process optimization) est quand même un super booster de performances. Je ne parle pas de 50% d'accélération (même si ça peut arriver), mais même avec 20%, c'est déjà exceptionnel.
Lorsqu'en plus tu utilises des logiciels qui sont plutôt du genre à boucler 90% du temps sur une boucle avec des codes réguliers (en gros du code « scientifique »), l'utilisation de -O3 et -ipo fait vraiment des merveilles. Tu peux gagner 40% en vitesse d'exécution par rapport à gcc 3 ou 4 en -O3.
Maintenant, je te l'accorde, pour la plupart des codes concernant le noyau, on s'en fout. Mais pour des codes concernant des flux multimédia, etc., ça peut jouer énormément. Idem pour les codes faisant entrer tout plein de calculs en jeu (calcul 3D, analyse numérique, etc).
Concernant les codes irréguliers, ICC se débrouille beaucoup moins bien, mais reste encore bien au-dessus de GCC.
« Surtout sur les systèmes AMD et sur ceux ayant une ou deux années de vie. »
Bon, je suppose que tu sais que ICC = Intel C Compiler. Ca ne me surprend pas outre mesure que les optimisations soient bien meilleures sur architecture Intel. D'ailleurs, si je me souviens bien, il est fortement déconseillé d'utiliser ICC avec un processeur AMD sous peine d'avoir des applications qui pourraient planter à cause de certaines optimisations effectuées par ICC et qui ne peuvent être faites que sur des archis Intel, parce qu'il y a quand même certaines grosses différences au niveau du modèle de processeur, tout ia32 qu'ils soient chez Intel et AMD. Et oui, ICC utilise très certainement des fonctionnalités non documentées des procs d'Intel.
« Par ailleurs, l'interêt que j'ai pour Gentoo vient plus de sa "hackabilité" que de ses performances. »
Possible, mais le titre du fil est « Performances de Gentoo ». Et je répondais sur ce critère uniquement.
Tu l'as dit, tes tests sont non-scientifiques, et il s'agit de ton avis. Ben il est à revoir, dès lors qu'on parle d'applications mettant beaucoup la pression sur le micro-processeur (et bien sûr, en supposant qu'il s'agisse d'un proc Intel, ce qui fait beaucoup de paramètres à prendre en compte, j'en suis conscient).
Mon objectif dans mon post initial était surtout de bien mettre l'accent sur le fait que
1) Des « distributions » source, ça existe depuis un moment (c'est plus ou moins la norme chez les *BSD), et si effectivement parfois ça peut se révéler un bon point pour les perfs, globalement c'est absolument pas concluant pour le système en général ; je pense aussi à LFS, dans le genre « [meta-]distributions source » ; dans tous les cas, je n'ai jamais entendu ceux qui s'en servaient dire « comme ça je peux vraiment gagner en performances », à quelques exceptions près pour certains programmes très précis.
2) GCC n'est pas encore au niveau des bons compilateurs optimisants, et parmi eux, ICC est vraiment l'un des meilleurs. Donc les optimisations proposées par GCC commencent à peine à avoir un « sens » (il suffit de mater comment les gens de chez MPlayer ont configuré le makefile pour comprendre qu'ils ne font pas vraiment confiance à GCC). Cela dit j'espère très fortement que ça va arriver !
Je ne suis pas du tout anti-GCC, je suis anti-jacky-distrib-linux, et franchement, beaucoup de gens utilisant Gentoo m'ont donné cette impression (ce sont les mêmes qui mettent en avant le côté performances avant les avantages que tu abordes, qui sont cent fois plus importants).