pierthi a écrit 178 commentaires

Mouais, ils ont bon dos les langages de programmation, hein ...

Je pense que tu rejetes le problème sur la mauvaise personne. Une API moisie, mal documentée, un programme incompréhensible, complètement bancal serait la faute du langage ? Ben voyons, si c'était si simple, ça se saurait.

Le problème numéro 1, c'est quand même l'interface chaise-clavier. Je mettrais ma tête à couper que ta frustration vient d'une API mal faite, pénible à utiliser et très certainement mal documentée, qui a du évoluer chaotiquement, comme tant d'autre ont du se farcir ici. Je n'aime moi non plus pas particulièrement le C++, mais je ne pense pourtant pas qu'il soit mauvais, loin de là.

Chaque langage à son domaine où il s'illustre un peu mieux que les autres, qui est fortement conditionné par l'api de base fournit avec. Aux programmeurs de faire les bon choix ... ou d'être motivé pour combler les lacunes de l'api (ce qui n'est franchement pas fun, c'est clair).

Ah mince, moi qui pensait qu'il avait réussi à intégrer une mini centrale thermo-nucléaire, à fusion matière / anti-matière dans le manche du sabre, qui arrive à dégager dans les 3765 GW (sans que le guignol^WJedi ne soit brulée au 72ème degré), pour découper les portes blindées de trois mètres d'épaisseur (la lame ne fait qu'un mètre, mais bon on va pas chipoter).

<mauvais esprit>
Ils sont vraiment mal chez Intel, je me demande comment ils vont faire pour trouver une nouvelle source d'énergie pour alimenter leurs futurs processeurs.
</mauvais esprit>

Hmm, j'avais aussi essayé ça, mettre un return [true|false]; à la fin de la fonction, dans le corps de l'attribut onclick ou href. Bon, vu le peu de doc que j'ai vu sur le sujet et vu l'absence de specifs du w3c, j'ai viré cette fonctionnalité.

Waou, tu t'es focalisé sur le point le moins pertinent de mon post :-)

J'ai dis stagiaire, j'aurais pu dire femme de ménage. Les applis bancales sur lesquelles j'ai du bosser, je n'en avais aucune idée de qui les avait réalisées initialement. Keep cool jeune padawan, moi aussi j'ai été stagiaire, et je n'ai pas oublié cette condition, loin de là.

Le point clé était que ça ne communiquait pas ou peu. Ou pire : tout le monde s'en foutait du moment que ça marche. Ça ne m'étonne pas la frilosité de Didier Lambert face aux changements, pour faire court et calmer un peu le troll, décidément bien remonté.

Quand on voit par exemple K3B qui permet de tout faire, moi je prefere passer par differentes petites applications (mais c'est juste MON avis)

Tu es dur avec K3B. Ok, c'est une application KDE, donc qui ne s'intègre pas du tout à autre chose. Mais, s'il y a bien une appli dans la philosophie Unix, c'est bien K3B : il ne s'agit ni plus ni moins que d'une interface graphique à des outils en ligne de commande comme mkisofs, cdrecord, growisofs, etc ... si tu ne t'en es pas rendu compte, c'est que l'intégration a bien été faite.

Un meilleur exemple aurait été KOffice.

Mouais bof, un parc homogène est une partie de la réponse, mais des formats ouverts, ou j'aurais plutôt dit documentés, ça facilite quand même bien les choses. Combien ont du se farcir la maintenance d'une application bricolée par le stagiaire ou le beau-fils de 15 ans du patron, un amas de ligne de code imbitable, bancal, pleins de rustines et des béquilles dans tous les sens, pas de doc et codés avec les pieds. Alors parler d'une migration, lorsqu'on est déjà content que ça marche.

Ça me rappelle aussi une phrase d'un consultant (il y en avait une cinquantaine, en fait) qui étaient en train de mettre en place une solution SAP chez un très gros client : "oui, ça coute les yeux de la tête, et ça ne marche pas du premier coup (ni du second, ni du troisième d'ailleurs), mais c'est normal que ça merde !". Magistral, je n'ose même pas imaginer comme tout doit être verrouillé, l'évolution vers d'autres solutions impossible, et les décideurs hantés par le blocage du systéme. J'ai notamment du m'occuper de la maintenance d'un module de cette usine à gaz immonde : une horreur, un stagiaire n'aurait pas pu faire pire.

D'ailleurs, n'est ce pas une situation de ce type qui avait pousser LLDC à migrer vers du proprio, mais plus "standardisé". Pas de doc, pas d'évolution.

Ce ne sont que quelques exemples, je ne prétend pas à une généralisation, mais je mettrais ma tête à couper que ça doit être le lot quotidien de bon nombre d'entreprise : on est déjà bien content quand ça marche, enfermés en plus avec des outils ultra-proprio, le tout évidemment peu ou pas documenté, le savoir n'est détenu que par quelques élites qui savent : la marge de manoeuvre est quasi-nulle.

Désolé d'avoir marché dedans.

Le boulot fait par Apple est pas mal

Oula, avant que ça parte en troll .... j'aurais du préciser le plus gros du boulot à quand même été fait par l'équipe de KHTML.

Bah, je bosse dans une boite de pré-presse (50 personnes). Sans surprise, 90% de Mac OS X ici. Pratiquement tout le monde utilise Safari, quelques irréductibles de IE, une personne dois utiliser Firefox (pas moi, mais patapé). Je dois reconnaitre que le boulot fait par Apple est pas mal : le rendu de Safari (très proche de Gecko) est magnifique et très bien intégré au système.

Je pense que là où Safari (et KHTML aussi d'ailleurs) enfonce FireFox (enfin Gecko), c'est en vitesse de rendu. Utilisez des div en "position: fixed" ou de la transparence PNG avec un "background-position: fixed" : c'est d'une lenteur exaspérante avec FireFox. Sur les G4 500 du parc, c'est très trés pénible, Safari en comparaison est 2 à 3 fois plus rapide.

Et puis, j'attends encore le jour où Gecko cessera d'utiliser son système de widget "fait maison", qui est plus moche que Motif et Tk réuni (encore une raison de préférer KHTML ou Safari).

En gros, je dirais qu'il faut qu'il y ait le moins de diversité possible dans l'infrastructure

C'est clair qu'il y a du ménage à faire. Mon rève serait qu'il se passe la même chose sur le desktop Linux, que ce qui c'est passé avec les standards Web : une standardisation au niveau de l'API qui peut être transcrite dans plusieurs langages, avec des extensions pour laisser une petite marge de manoeuvre.

Franchement, entre XtVaCreateWidget, gdk_create_button, document.createElement, QTMachinBidule, et autres whatmille toolkits, c'est lourdingue au possible, aussi bien pour le développeur que pour l'utilisateur. Le plus navrant, c'est que l'architecture X11 avait commencer à standardiser un peu tout ce foutoir avec Xt, mais personne n'a suivit (ou plutôt si: Athena Widget, une horreur et Motif, avec une licence d'utilisation que même Microsoft n'a pas osé faire pire) et ça a encore moins évolué (syndrome XFree86 ?).

Peut-être que XUL apportera un peu de standardisation... même si je doute que quelque chose ne sorte avant une dizaine d'année, parce que l'API graphique n'est que la partie émergée de l'iceberg. Bref, je pense qu'ils ont encore de beaux jours devant eux, chez Microsoft.

D'ailleurs, ça me rappelle cette citation de Freud (ou autre, vous corrigerez), qui résume un peu le problème :

La plupart des individus ne veulent pas réellement de liberté, car la liberté implique la responsabilité, et la plupart des individus sont effrayés par la responsabilité.

Hmm, les threads et la Xlib (utilisés par GTK) est un coktail assez explosif. Tu as intérêt à savoir ce que tu fais avant de toucher à ta fenêtre. Pour info, la connexion avec le serveur X est un descripteur de fichier, tout ce qu'il y a de plus banal (socket unix locale).

Maintenant si tu t'amuses à faire des mises à jour dans chaque thread de ton interface, les paquets Xlib (XDrawText, XCopyArea, etc...) risque de s'emméler et foutre complètement en l'air le protocole.

Deux façon de faire, d'abord la casse gueule :
- Tu fais tes mises à jour n'importe quel thread, en faisant attention d'encadrer CHAQUE appel à gtk/X11/gdk par un appel à mutex, je lancerais aussi un XFlush() avant.

Plus propre :
- Un et un seul thread s'occupe de gérer l'affichage, synchronisé avec une classe qui va bien (mutex, pipe, & co).

En tous les cas l'erreur que tu as reçu de la Xlib est typiquement le reflet d'un problème de paquets entremélés.

Ah, les joies de la programmtion multi-threadé en environnement X11 ....

Quitte à être hors sujet ....

Quelques connaissances m'ont rapporté que la pile TCP/IP de Windows XP était bridée en appliquant le SP2. Cela, soit disant pour des raisons de sécurité, pour contrer des attaques type Sasser ou Blaster (et accessoirement faire c...é les utilisateurs de P2P). On reconnait bien là, la politique légendaire de Microsoft en matière de sécurité, puisque cette limitation serait contournable via une improbable valeur dans une clé de la fumeuse base de registre.

J'utilise le conditionnel, parce que d'une part je n'utilise pas Windows et d'autre part ça me parait tellement débile, que j'ai du mal à croire les quelques sites qui relatent ce "problème".

Une bonne âme pour me confirmer que ce n'est pas un canular ?

Ça me rappelle une boite où j'ai bossé, on éditait les fichiers via un serveur NFS avec annonce vocale™ des fichiers qu'on voulait modifier. Miraculeusement, les conflits étaient très rares. Je priais quand même chaque jour pour qu'on installe CVS, il a fallu un intense lobying auprès des instances dirigeantes, pour qu'il soit mis en place. Pas facile à changer les habitudes.

Sinon, un conseil dénué du moindre troll, tu devrais vraiment leur mettre vim comme éditeur, qui lui au moins sait détecter ce genre de problème.

Plus sérieusement, CVS est vraiment taillé pour ce genre de travail.

Ce que tu rechercherais, ce ne serait pas plutôt un moteur 3D (ce que n'est pas SDL) ? Tu as du te rendre compte qu'OpenGL est une API très bas niveau pour gérer des rudiments d'une scène 3D. Pour ce qui est de la gestion des phénomènes physiques (gravité, chocs, friction, etc...), ombres portées, mouvement par contraintes, import d'objets issus des modeleurs, etc... bah tu dois tout faire toi même.

Même avec un binding C++, je ne pense pas qu'OpenGL sera beaucoup plus pratique à utiliser. Ce n'est pas le but, le but étant que ça soit facilement gérable au niveau matériel.

Bref, ce qu'il te faudrait c'est une API d'un peu plus haut niveau encapsulant les appels à OpenGL. J'en connais deux, et utilisé seulement un :
- Soya 3D : utilisé par Slune, écrit en Python. C'est celui que j'ai utilisé pour mes très maigres besoins. Il est vraiment très facile à utiliser.
- Blender : Là aussi, c'est du python. Mais je ne me suis pas trop penché sur cet outil.

Il doit y en avoir d'autres avec des bindings C++, comme tu sembles y être attaché. Le point clé de ce message étant qu'OpenGL ne t'offrira jamais de fonctions de haut niveau, donc cherche ailleurs.

Effectivement, c'est bien openldap 2.2.24 que j'utilise et il y a bien une option dans slapd.conf pour limiter le nombre de réponse envoyée par requète.

Sauf que du client, une requète n'est envoyée au serveur LDAP que s'il y a une chaine dans la zone de recherche. Mozilla et Thunderbird teste si la chaine est contenue dans un des champs (cn, mail, ...) alors que l'address book de Mac OS X teste seulement si le champ commence par la chaine donnée (il faut donc gruger avec une chaine du style *@ pour avoir toute la liste).

Bon, ben, on fera avec.

Aller, une dernière pour chipoter (Interview de Bill G.) :
s/perméttant /permettant/

Qu'il soit pro-Windows ou pro-IE, on s'en fout. C'est son étroitesse d'esprit qui fait peur, le même genre de raisonnement que trop de Webmaster font encore, par fainéantise, par incompétence ou par stupidité. Cet intégrisme à croire que IE réponds aux besoins de tous, ou pire qu'il soit un "standard".

Quand on lit des avis aussi débile, on se dit qu'il y a encore du chemin à faire pour l'adoption des vrais standards du Web. J'aimerais en rire, mais si je crois plutôt qu'il a sérieusement besoin d'une greffe de cerveau, ce gentil monsieur.

Ce n'est certes qu'un coup de gueule irréfléchit, mais révélateur du laxisme qu'il y a encore chez trop de gorets auto-proclamé "développeur Web". Ces sites torchés à coup de tables, de styles pourris à la FrontPage, d'activeX et de Flash, qui font le plaisir à tant de mal-voyants, alors que les standards règlent élégament tout cela.

P...n ce n'est pas gagné.

Sans parler de Debian qui est forcément plus nulle que Mandrake, vu qu'elle utilise un installateur en mode texte. Que dire de gentoo qui favorise l'effet de serre pour compiler OOo et KDE, voire Gnome pour les inconscients, car chacun sait que XFCE rulez. Puis de toute façon, Linux dans 5 ans sera pareil que Windows. Mais je pense que ça a déjà été dit, alors autant pour moi.
--
Utilisez le renard de feu => http://www.mozilla.org/products/firefox/(...)

Ça me rappelle le groupe Manau, lors de la sortie de leur album "panique celtique". Sur un CD à 120Fr, j'avais lu que chaque artiste du groupe gagnait quelque chose comme 3Fr, ce qui fait environ 3% du prix HT. Ça m'avait assez surpris de savoir qu'ils gagnaient aussi peu à l'époque. Je me demande même comment des artistes peuvent avoir aujourd'hui la vocation, avec ces conditions proches du racket.

Est ce que les "maisons de disques" fournissent un service, genre remasterisation de la maquette, soutien logistique (appareils musicaux), retouche numérique, adaptation des paroles pour justifier de telles marges ?

Je ne connais pas du tout ce milieu, mais j'ai l'impression que c'est encore pire que l'informatique avec le monopole Microsoft.

Ouais, c'est de l'ordre de quelques microsecondes par an, du à l'attraction lunaire il me semble. Il faudra plusieurs milliards d'années pour arriver à des jours de 28 heures. Bref, le soleil risque de se transformer en novae avant.

De toute façon d'ici là, Hurd sera arrivé en version 1.0 et on aura la possibilité de s'exécuter sous forme d'entité logicielle, à 4000 fois la vitesse du réel, sans qu'on ait besoin de dormir, dans des environnements où l'on pourra simuler tout ce dont on a envie.

Les mauvaises langues feront remarquer que ça ne durera que 8 minutes.

«Faut pas oublier que l'uniformisation nuit aussi au progrès...»
Alors là je suis clairement pas d'accord, bien que j'imagine que c'est Windows qui est visé par cette affirmation (et encore les défauts de Windows sont plus du à la volonté de Microsoft de faire un système destiné à la vaste majorité des neuneux, aux détriments des règles les plus élémentaires de sécurité, et que le tout est jalousement gardé sous secret). Toujours est-il que standardiser, n'est ce pas d'une certaine façon uniformiser (la préhistoire du Web, avec chaque navigateur ayant sa propre version du HTML) ? On déduirait presque un syllogisme assez paradoxal, dont je me garderais bien de faire.

Pourquoi en serait-il différent avec un système d'exploitation ? Il est loin le temps où un système pouvait tenir sur une ROM de 512K (Aaaah, l'Amiga). Compte tenu de la diversité des matériels, pour concevoir un système cohérent et des applications qui s'intégrent harmonieusement, il faut beaucoup de briques de bases, standards, pour éviter de perdre son temps à réinventer encore et toujours cette foutue roue. En tous les cas, il faut un peu plus que des primitives bas-niveaux pour afficher des formes 2D (Xlib) ou 3D (OpenGL).

C'est sûr que prévoir en 1984, ce qu'allait être en bureau en 2005, ça devrait être comme marcher dans une grotte avec une allumette dans les mains, quand bien même Xerox avait largement tracé les grandes lignes dans les années 70. Je suis d'ailleurs sûr que je ne ferais jamais mieux que le MIT, si je devais définir maintenant le bureau de 2025.

N'empêche le résultat est là : toute une floppée de window/desktop manager, avec leur pléthore de bibliothèques, framework multimédia (notamment le son, complètement oculté par X11), communication inter-process, etc., c.f http://en.wikipedia.org/wiki/X_Window_System#Common_criticisms_of_X(...)

D'un coté je trouve que les environnements Gnome, KDE, E17 vont dans le bon sens en proposant des solutions aux lacunes de X11. Mais bon, ce n'est rien de standard, et quelque chose me dit que la roue continuera de tourner pour un bon bout de temps encore, et qu'on aura pas finit de se plaindre de ce manque d'intégration.

Mais bon, c'est la philosophie du libre. Quand quelque chose ne me plait pas, je propose des corrections, si on en veut pas, je fais un fork. Ça conduit forcément à une certaine redondance, mais dans le monde du libre, soit on l'accepte, soit il vaut mieux voir ailleurs.

Il y a un livre en cours d'écriture sur la programmation, assez ambitieux, et qui couvre tous les aspects que tu énumères et bien plus encore (en français en plus).

Bon avant d'y aller, je te préviens quand même que c'est encore loin, très loin, d'être complet. En tous les cas, c'est ici que j'ai découvert LE langage de programmation ultime : le BrainFuck.

Sinon plus sérieusement, ce que tu cherches semble être se qu'on apprend pendant de longues années dans toutes les universités ou écoles d'ingénieurs du monde. Et encore, j'en connais certains, qui même après avoir suivit se cursus ne savent toujours pas coder (ok, je digresse).
--
Thierry
BF Lead Architect

> Linux qui ressemble trait pour trait à Windows
Ah ? avoir un format de package qui pourrait simplifier la vie des développeurs et des utilisateurs serait un pas vers Windows ? Beaucoup de points sont certes mauvais sous Windows, mais je doute que les concepteurs de ce genre d'outil ne sont pas au courant des lacunes qu'ont les installateurs de Windows. En tous les cas, leur FAQ est assez claire et leur format laisse une grande liberté au développeur (ce sont des scripts bash).

Inutile de préciser que le but de ce format n'est pas de remplacer les formats de packages RPM, DEB et co. Loin, mais alors très loin de là. Un des plus gros avantage que je peux voir, c'est de s'épargner la compilation du dernier logiciel de la mort qui tue, au lieu de se farcir la sainte trilogie "configure && make && make install" (et donc s'affranchir d'avoir un environnement de développement complet, notamment les lib qui sont parfois très très lourdes), car il y a beaucoup de chance à l'heure actuelle que les développeurs et les utilisateurs aient la même architecture (au hasard Linux/x86).

Le problème de la sécurité est un faux problème et la "pollution" de l'arbre des packages peut être évité en installant dans une arborescence spécifique (à la /usr/local pour les compilés main).

Cela permettra de tester rapidement un logiciel (comprendre: installer pour de bon pour ceux qui ne veulent pas se prendre la tête) et permettre aux puristes de l'installer aux petits oignons par la suite.

Si des personnes sont motivées pour fournir des packages adaptés à leur distribs, tant mieux. Mais le but n'est pas que de simplifier la vie des utilisateurs, mais ausi celle des développeurs, qui certainement ont autre chose à faire que de s'intéresser aux spécificités de chaques distribs.

C'est clair qu'il est temps qu'un format de package binaire simple (aussi bien pour les développeurs que pour les utilisateurs) se démocratise, pour pouvoir installer des applications tierces.

Je trouve aberrant d'avoir plusieurs packages différents pour une même architecture (au hasard Linux/x86) à cause des spécificités des formats de packages, quand en plus on doit supporter différentes architectures. Je pense que les développeurs ont vraiment autre chose à faire, et attendre qu'une bonne âme veuille bien packager leur appli pour une distrib, c'est une perte de temps et un gachis de ressource.

Il m'arrive souvent de vouloir tester la dernière version de tel ou tel logiciel, mais me taper 72 heures de compilation (avec parfois toutes les dépendances ...), pour moi qui ait une machine banale, un système banal, c'est clairement 71 heures 59 minutes et 50 secondes de trop.

Reste à espérer que ça se démocratise, et qu'on ne réinvente pas (trop) la roue avec 15000 installateur de packages. En tous les cas, ils ont l'air d'avoir compris la problématique les développeurs, ce qui me parait encourrageant. Au moins que de temps serait gagné pour certains, et de très loin pas les moins nombreux ...

Je viens d'utiliser pour la première fois msnsearch, et voici sur quoi je suis tombé en cliquant sur ton lien :
http://perso.b2b2c.ca/tpierron/msn_down.png(...)

Un Ctrl+R plus tard et tout à fonctionné, c'est dire la chance que j'ai eue pour avoir ce message. Un signe du destin à mon avis. <mauvaise langue>Les licences IIS sont-elles bridées à 20^W 10 utilisateurs ?</mauvaise langue>

Merci à tous, il fallait effectivement rajouter l'option user_xattr dans /etc/fstab de la partition où on veut activer le support des attributs étendus.

Merci encore, j'aurais pu chercher pendant lontemps cette option là.