Guillaume Denry a écrit 2954 commentaires

Quel troll ? On ne peut plus mettre Qt et GTK+ en face, Qt4 englobe bien plus de technos que GTK+ et est bien bien plus adapté pour les applications multiplatformes.

Waouh, ça en jette. Bon ça n'arrête pas de bouger, ça fait un peu mal à la tête au bout d'un moment si tu veux te faire une soirée photo en famille, mais le design est d'enfer !

"- Tu vas voir bébé, je vais te mettre le feu !"
*click* tuuuuut tuuuut
"Bah.. qu'est-ce que j'ai dit ?"

man humour

Non, désolé, je ne pense pas qu'un monopole public puisse être optimal, ce par conception : pas de bâton (impossible de sanctionner si tu ne bosse pas), pas de carotte (pas d'incitation à optimiser).

Je suis plutôt favorable aux entreprises publiques (je trouve que l'inhumanité des entreprises privées est un horrible cancer dans notre société, leur raison de vivre étant de se faire un maximum de pognon), mais c'est vrai qu'il faut reconnaître qu'il manque -en tout cas en France- un système de contraintes, de mérite (j'aime pas trop ce mot mais là je trouve qu'il s'applique bien) et qu'il y a une certaine impunité qui me semble vraiment néfaste à nos entreprises publiques.
J'en veux pour preuve ma compagne qui se défonce au lycée et à la maison pour faire et dispenser des cours nickels et voit à côté des collègues qui ressortent les mêmes cours poussiéreux tous les ans et qui en branlent pas une, qui sont systématiquement en retard de 15 minutes à chaque cours, etc. Là y'a un VRAI problème. Tant qu'on prendra pas ce problème à bras le corps, le public gardera l'image déplorable qu'il a.

Je comprends maintenant le rythme de sortie des versions de debian => essayer de reculer au maximum ce moment fatidique.
(je me moque mais je tiens à préciser que j'ai plussé le post sur Kikoolol Keke plus haut:)

Est-ce qu'on peut accorder du crédit à des propos pour ce qu'ils sont intrinsèquement ou est-ce que le crédit est à géométrie variable suivant la personne qui les émet ?

Moi j'opte pour "Loutre Lubrique"
Ah mais non, loutre en anglais, c'est otter, merde...

Yep, avec pourquoi pas un moyen de voir l'historique des modifications comme dans Wikipedia.
(cela dit, je vois au moins un cas ou deux où ça pourrait poser problème : genre tu réponds de façon très virulente à un post à cause d'un gros malentendu, tu te corriges rapidement mais ton post très virulent sera toujours là alors que c'était un problème de compréhension)

J'aurais préféré un moyen de pouvoir re-éditer ses propres posts. Pour les typos par exemple...

Merci pour ce long compte-rendu.
Je vais la faire bien plus breve; apres test, l'impression generale qui se degage de ce navigateur c'est la vitesse ! Pfioou que tout cela est rapide, le chargement, le zoom et le scrolling en particulier ! C'est vraiment chouette.

En gros ton message était clair et les gens qui l'ont mal compris sont des imbéciles. Sympa pour eux. Ton mépris est pathétique.

Ouais bah j'ai rien dit, j'ai des tonnes d'emmerdes avec le site nvidia en particulier donc oubliez mon message :)

Bah les 177.68 sont toujours pas dispo sur le site de nvidia par contre. Alors je ne sais pas où tu les as trouvé.

C'est un canard, pour une simple et bonne raison : il traîne souvent dans le COIN.

et j'ai trouvé la gestion des diverses étapes de construction par CMake désastreuse

Ouais, c'est sûr que devoir rajouter une ligne pour chaque fichier mocable c'est pas terrible (Bon en réalité, y'a quand même moyen de s'en passer en utilisant QT4_AUTOMOC et ça demande de changer légèrement sa façon d'inclure les headers, regarde les projets dans KDE4, ils ajoutent pas chaque fichier mocable dans le CMakeLists.txt), mais sinon pour tout le reste je trouve que tu exagères; cmake pour compiler du Qt, c'est quand même le panard, ça roule quasiment tout seul.

Je maintiens un petit logiciel libre de chat utilisé par quelques dizaines (voire centaines les jours de grande forme) de personnes, j'ai déjà eu des réactions assez dédaigneuses de la part d'utilisateurs qui adoptent une attitude plutôt clientéliste vis-à-vis de ce logiciel qui ne leur à rien coûté.
Personnellement pour moi, ça a toujours été direction poubelle. Je n'écoute même pas. C'est même parfois un plaisir de les envoyer sur les roses (côté épines également).
En tant qu'utilisateur du libre, j'ai une attitude de respect envers les gens qui donnent de leur temps libre pour les autres, peu importe si ces gens font des excès d'orgueil parfois, peu importe s'ils cherchent un peu trop de reconnaissance, après tout, je profite de leur travail sans coût, la moindre des choses c'est de leur témoigner du respect.

T'as lu le journal ?
Tiens, cadeau http://fr.wikipedia.org/wiki/SCons

Mais si c'est ça la communauté, ça ne donne pas envie de s'y aventurer ...

Tant mieux on a pas besoin de quelqu'un qui tire de grandes généralités sur une communauté de centaines de milliers de personnes à partir des réactions d'un ou deux développeurs.

C'est la où ça coince pour moi : les projets doivent être utilisables car je diffuse les fichiers projets, très utilisés.

Oui, cmake est non seulement un générateur de projets mais il ne faut pas se leurrer, il est nécessaire à toute personne désirant bosser sérieusement sur le projet.
Pour moi, c'est très loin d'être rédhibitoire vu la simplicité extrême de l'installation et de l'utilisation de cmake. (sous windows, l'installeur se charge même d'inscrire ce qu'il faut dans les variables d'environnement (comme le PATH) à ta place)
De toute façon, c'est illogique et fastidieux de distribuer par exemple une solution MSVC générée à partir de cmake à un développeur, attendre un patch de sa part et ré-intégrer les éventuels nouveaux fichiers (ou optimisations) de cette solution dans le(s) CMakeLists.txt.
=> Tout le monde bosse sur les CMakeLists.txt, les .sln/.vcproj ne sont plus jamais modifiés (en tout cas, pas de façon pérenne, juste pour des petits tests) mais juste utilisés, c'est ainsi que se conçoit l'utilisation de cmake. Et le traitement platform-specific doit être réalisé en amont dans les CMakeLists.txt grâce aux directives adéquates.
Pour le fichier CMakeLists.txt par répertoire source, bien sûr que non ce n'est pas nécessaire. La pratique qu'on trouve le plus souvent, c'est de créer un CMakeLists.txt par projet (une lib statique, dynamique, une application, un plugin, etc) et il est de toute façon toujours possible de référencer les sources de façon relative par rapport à la location du CMakeLists.txt.
Bref, vous l'avez compris, je suis fan :). Surtout que cmake se bonifie vraiment avec le temps, on trouve le support de plus en plus de bibliothèques tierces dans share/modules.
Le seul reproche que j'ai à lui faire, c'est sa documentation qui manque d'exemples et souvent d'explications.

cmake te génère ce que tu veux, tant que le générateur pour la platforme en question existe.
Et actuellement, toutes les versions de Visual Studio sont supportées.
A partir de tes fichiers CMakeLists.txt (qui sont les fichiers projets de cmake, ceux que tu écris amoureusement et avec soin), cmake te génère donc des solutions/Makefile/projets Kdevelop/etc
Bon par contre, il ne faut pas être trop regardant sur les projets générés, les fichiers du projet sont par exemple des chemins absolus, mais ça n'a aucune espèce d'importance car les solutions/projets/Makefile sont considérés comme "jetables" et valable uniquement là où tu les as générés; tu ne peux pas filer ta solution/Makefile a quelqu'un et espérer qu'elle/il fonctionne chez lui, non, il doit lui aussi installer cmake et l'exécuter pour se générer son propre projet.
Scons doit probablement faire la même chose que cmake.
Avec cmake par contre, pas de python à installer.

Là où j'ai l'impression que Scons permet de faire tout et n'importe quoi, cmake s'est "simplement contenté" de factoriser des concepts communs à tous les systèmes de builds afin de les proposer dans un ensemble de variables/commandes, en saupoudrant le tout de notions de règles de dépendances, des règles de constructions. On peut bien sûr sortir du cadre classique de cmake et faire appels à des programmes externes mais globalement, ces utilisations spécifiques et les connaissances "métier" associées sont factorisées au sein de modules FindXXX.cmake qui permettent de ne pas réinventer la roue à chaque fois.
Bref, en ce qui concerne Scons, trop de liberté pour un système de build, je ne suis pas convaincu que ce soit réellement un avantage.

Absolument. D'ailleurs les alliés n'auraient jamais dû se casser le cul à chiffrer leurs communications pendant la guerre puisqu'ils ne maîtrisaient pas non plus la sécurité de leurs correspondants, hein. Alors autant tout balancer en clair.

Ouais mais si tu pars du principe que la machine du correspondant est compromise....
On peut aussi dire que le système de protection des entrepôts de la banque centrale américaine est là pour faire joli parce que si on connaît le moyen d'y rentrer alors il sert à rien.
Super.

Faire semblant du contraire avec différents moyens comme le chiffrement c'est jouer à l'autruche.

Gné ? Et PGP/GPG c'est pour faire joli ?