Caché bien profond dans System Settings»Comportement des fenêtres, quelque-part dans un onglet, en bas, une case à cocher. (oui oui, super facile à trouver, mais vu que ça déroute Madame Michu, heureusement que c'est pas marqué trop grand. Perso, j'aurais rajouté un petit message d'explication sur le machin).
Les gens aiment troller pour dire que PuleAudio c'est lourd et nul justement parce qu'il propose de streamer le son en réseau, fonctionnalité qu'ils jugent inutile.
Donc oui, c'est possible avec PulseAudio, normalement de manière graphique (du moins sous GNOME, je ne sais pas s'il y a une bonne intégration à KDE).
Plus encore un léger avantage à PulseAudio : il y a toute son infrastructure en-dessous, donc on peut rediriger la sortie «Musique de fond» d'un jeu vers le haut-parleur droit du casque de l'ordinateur du salon, si on veut.
Attention, il faut différencier KDE, KDE SC et la KDE Platform.
KDE, sans rien derrière, c'est la communauté de dev. ownCloud en fait partie car ce sont des devs de KDE qui travaillent dessus, il a été présenté au Camp KDE, il est hébergé chez KDE, présenté sur le dot KDE, etc.
KDE SC et KDE Platform sont bien les briques de base de l'environnement bureau graphique lui-même.
En clair, KDE est bien, mais vraiment bien plus qu'un DE. C'est toute une philosophie, une communauté de personnes ayant une même vision :) .
Ce sont des devs KDE, pas des sysadmins, ni des kernel hackers. Je pense donc que ce ne sera pas un nouveau fs ni l'utilisation d'un fs distribué (KDE et ownCloud doivent être utilisables par Madame Michu).
Je pense, mais je n'en sais pas grand-chose, que ce sera simplement une synchronisation/partage entre les serveurs par HTTP (requêtes XML, JSON, etc). Le but est simplement de permettre à Monsieur Martin de récupérer directement sur son Cloud la vidéo du mariage de Madame Jacqueline, sans devoir les télécharger sur son ordinateur personnel puis les renvoyer.
Pour le cloud, je ne sais pas. Peut-être une allusion à l'informatique dans les nuages, du point de vue «je partage mes données», ainsi que web 2.0 (on partage des choses, on participe), etc.
Je pencherais pour la 2eme solution. À ce que je vois dans le Git de Mesa, il y a un pilote Nouveau (basé sur Gallium, peu de fichiers), et plein de pilotes ATI (r300, r600, radeon, r300g, r600g).
En fait, il me semble que les cartes nVidia sont bien plus compatibles entre elles, c'est à dire qu'il n'y a que des différences mineures entre deux cartes, même éloignées dans le temps.
Du côté d'ATI, ils aiment bien refaire l'architecture de leurs cartes de temps en temps. On a les Radeon r200-r500, puis ils ont fait les HD (r600 et r700), puis ils ont fait les Evergreen (Radeon HD 5xxx, sorties en septembre).
Il y a donc 3 pilotes ATI à maintenir, et un seul Nouveau.
Il y a aussi le fait que le pilote ATI est déjà beaucoup utilisé. Ils ne peuvent pas supprimer leur pilote ATI basé uniquement sur Mesa pour se concentrer sur Gallium, du fait qu'il est encore très utilisé. Du côté de Nouveau, comme presque personne ne l'utilise (ils font tout pour), ils peuvent faire un peu ce qu'ils veulent.
J'ai testé avec le noyau 2.6.34, Ubuntu 10.04 utilise le 2.6.32 (si je me souviens bien).
Et sachant que Nouveau a été un beau chanté pour le 2.6.33, puis à nouveau un gros chantier pour le 2.6.34, je peux comprendre qu'être deux versions du noyau en retard pour nouveau amène des problèmes.
Il y a aussi le fait que Ubuntu 10.04 n'a pas le dernier Mesa, DRM, etc. C'est le problème des trucs en développement : ça change vite.
(mais j'avoue, j'ai réussi à faire freezer mon PC avec Nouveau, mais je ne me souviens plus comment (j'ai activé des effets Kwin au hasard)).
Il existe ownCloud, du projet KDE, en C++/Qt et PHP côté serveur. C'est encore expérimental, mais les fonctionnalités sont alléchantes (et elles marchent déjà pour certaine) :
* Partage de fichier
* Le serveur est hébergé chez toi
* Accessible en HTTP tout naturel
* Possibilité de sauvegarder la configuration des applis KDE là-dessus (un peu comme FireFox et ses bookmarks, sauf qu'ici c'est tout l'environnement)
Les fonctionnalités à venir comprendront la sauvegarde de la BDD de Nepomuk, etc.
Mais bien entendu, comme je le dis toujours, KDE c'est trop libre et communautaire pour qu'on en parle quand ils font des trucs bien [/troll].
Oui, je suis désolé, mes infos datent énormément (début 2009, c'est dire). La dernière fois que j'ai utilisé ce fichier, c'est quand j'ai créé un script proof-of-concept pour le centre de configuration de l'environnement bureau de Logram, plusieurs semaines avant son premier anniversaire (donc en mars 2009).
Depuis, les options ont changé, mes souvenirs se sont effacés (/etc/laptop_mode.conf n'existe pas, je voulais parler de /etc/laptop-mode/laptop-mode.conf, mais en mettant un fichier à la racine de /etc, j'était sûr d'être compris).
Si quelque-chose ressemble à *SpinDown, dans une section parlant du disque dur, y'a des chances que ce soit bon.
Il fut un temps (j'espère que c'est corrigé) où au moins Ubuntu claquait les disques durs en moins d'un an. C'était une simple erreur : leur installateur détectait un portable, installait le laptop_mode, et configurait le disque dur pour s'éteindre au bout d'une seconde d'utilisation.
Manque de bol, HAL (ou ext*) avait besoin d'y écrire toutes les 2 secondes. Hahaha, donc toutes les deux secondes, le DD se rallume, écrit quelques octets, et s'éteint.
Au boit de quelques mois et de plus de 2000 cycles d'allumage/extinction, il décidait qu'il en avait marre et ne se rallumait pas.
Le problème est facilement détectable : écoutez attentivement votre disque. S'il faut de petits "clacs" métalliques toutes les 2 secondes (ou 5), c'est que la fonction tueuse est activée.
Pour corriger le problème : éditer /etc/laptop_mode.conf, ou quelque-chose comme ça. A un endroit, ça parle de hdparm -S. Remplacez le 1 ou le 2 par une grande valeur (man hdparm pour voir), genre 100 ou 200. Pour désactiver l'économie d'énergie, utilisez 0.
Il se peut également que certains BIOS mettent cette valeur à 1 tout seuls, auquel cas le problème touche également Windows. Il suffit de lancer un petit «hdparm -S 0 /dev/sd?» au démarrage de l'ordinateur (/etc/rc.local sous ArchLinux). La course à l'autonomie peut tenter les fabriquants de faire ce genre de choses (un netbook par exemple est généralement prévu pour être utilisé à peu près une heure par jour, auquel cas le DD tient juste un peu plus de deux ans).
Je suis l'heureux possesseur de l'ordinateur portable (ou plutôt netbook) fait pour le geek : le Gateway.
Côté extérieur, on a un superbe écran 11,1" de 1366x768 pixels, bien lumineux et utilisable dehors. Le boitier est léger.
A l'intérieur, on a une carte graphique ATI Radeon X1270 (RS690m), qui marche impec avec les pilotes libres (si on désactive KMS qui a quelques problèmes de corruption mémoire dessus). La carte wifi est reconnue immédiatement, le disque est spacieux (160Gio et pas si lent que ça). Les touches de fonction (son, écran, commande du touchpad, réseau) fonctionnent impeccablement.
Le tout testé sous une ArchLinux avec KDE dessus (oui oui oui, KDE tourne au poil dans 784Mio de RAM (1024 - la mémoire partagée de la carte graphique).
Summum de la geekerie : il est entièrement démontable. Envie de changer l'AMD Athlon 64 L110 (monocoeur 1,2Ghz) par un puissant AMD Athlon 64 L510 (dual coeur 1,6Ghz avec SSE3) ? C'est par ici : http://ftp.packardbell.com/pub/itemnr/CS065A00/dot_ma_disass(...)
Donc oui, on peut démonter tout le netbook : RAM, disque dur, carte réseau, clavier, carte mère, processeur (qui n'est pas soudé, on peut le changer), mais également la dalle LCD (pas juste l'écran, non non non, on retire même le rétro-éclairage).
C'est donc un netbook très évolutif (on peut y mettre 4Gio de RAM, un double-coeur 1,6Ghz, un DD de 1Tio si on veut), et normalement pas trop difficile à réparer (si le disque claque, ça se change. Si la RAM claque, ça se change. Si le proc claque, ça se change aussi).
Perso, je l'ai acheté pour moins de 300€ chez rueducommerce, avec la garantie retour de 1 an (qui m'a déjà servi pour un Hercules eCafé dont la batterie m'a laché deux mois après l'achat. Un mail et un colit, et je recois un bon d'achat de 220€ qui m'a permis d'acheter mon dot MA).
Pour le moment, j'utilise ce netbook comme ordinateur principal. Il est assez rapide pour ça, et son écran est un pur bonheur (j'ai également connecté un bon vieux LCD de 1280x1024 sur sa sortie VGA, que j'utilise comme extension de bureau (écran placé au-dessus, on sait régler sa position avec XRandR).
Client satisfait donc :) (mais bon, ça m'a aussi pris 1 mois pour le trouver).
Ça dépend des dépôts. ReiserFS est conçu pour ce genre de choses, donc je veux bien croire que ça aille vite. Il faut aussi compter l'age de l'installation d'ArchLinux. Mon premier update s'est fait en quelques secondes, alors que je suis maintenant à près d'une minute (avec le système inutilisable à cause des IO).
2)
Justement, tu prends en fait la 2e solution. Pour obtenir les dépendances d'un paquet, tu dois faire une requête. Pour chaque dépendance, tu dois prendre leurs dépendances, et ainsi de suite. Finalement, tu te retrouves avec une quantité impressionnante de requêtes sur ta BDD.
Tu peux également faire un gros SELECT qui te ramène toutes les deps, ce qui est justement ma solution 1.
3)
Non, je ne mélange pas. Je parle en fait d'accès, et je n'oppose pas le mmap contre l'accès séquentiel, mais bien l'idée «Je passe par une lib tier à laquelle je parle en requête textuelle» par rapport à «Je fait tout moi-même, sans couche d'abstraction». Sauf que les fichiers mmapés ont également comme avantage d'être plus rapides et d'utiliser moins de RAM (le noyau les considère comme un swap supplémentaire, et utilise un chemin de code rapide et optimisé pour lire les pages, au lieu de passer par des syscalls lents et répétitifs).
4)
La base de donnée est écrite par Setup lui-même (il récupère du serveur des fichiers de texte comme ceux utilisés par Debian, donc en gros du INI). Il n'y a donc aucun problème d'edianess ou d'alignement, le compilateur se charge de tout.
Le fait que ce soit illisible par d'autres programmes n'est pas embêtant pour deux points. Premièrement, Setup utilise une bibliothèque, donc un programme qui veut gérer des paquets utilise cette bibliothèque. Deuxièmement, ce n'est pas comme si c'était un fichier de configuration ou un dépôt de mails, devant être lu par tout le monde. C'est le cache de Setup, ça doit juste être rapide et sûr.
Si un programme devait néanmoins lire la liste des paquets installés, il lui suffit de lire /var/cache/lgrpkg/db/installed_packages.list. C'est un fichier INI lisible avec un QSettings. Setup lit ce fichier quand il reconstruit sa base de donnée (oui, ma BDD a comme problème d'être en lecture seule, donc quand on met à jour, il faut l'effacer et la reconstruire. Ça prend 6 secondes pour y mettre les 27 000 paquets de Sid).
En effet, j'ai été regarder dans le dossier /var/lib/pacman, et ça fait peur. Je n'y étais jamais allé, merci de me faire découvrir pourquoi la moitié des inodes de ma partition sont déjà pris, et pourquoi un pacman -Sy prend tant de temps.
Sinon, le SQL peut être très rapide, j'ai eu l'occasion de beaucoup de tester. Il y a un an, j'avais fait un gestionnaire de paquet (j'aime développer des gestionnaires de paquets :-° ) qui utilisant une base SQLite, en passant par QtSql.
Alors oui, il y a des requêtes un peu lourdes, mais assez efficaces. Mais il y a aussi le problème des multiples requêtes.
Par exemple, tu dois résoudre les dépendances d'un paquet. Pour cela, deux solution :
* Une grosse requête qui te dump la table packages_deps, et tu traite le tout en C++. Grosse consommation de RAM
* Plein de petites requêtes quand t'en a besoin
Oui, complexité O(nombre de dépendances), très rapide. Du C pur*, pas d'accès à une BDD, c'est indexé, etc.
En fait, une base de donnée binaire fait-maison est la solution la plus rapide qu'il soit, car c'est adapté au problème. Maintenant, obtenir cette rapidité est difficile (perso : 2 mois de réflexion au moins).
Le résultat : à la sortie de Setup 0.1-alpha2, je ferai une vidéo montrant l'instantanéité de tous les traitements de Setup, malgré le fait qu'il utilise un solveur à graphe orienté : http://logram-project.org/news-2-66-1-un-nouveau-solveur-de-(...) . (Solveur d'ailleurs pas encore optimisé, qui compare des chaînes de caractère. Je dois encore faire en sortie qu'il compare des index de chaînes, sachant que toutes les chaines de caractères de la BDD sont indexées).
*Sauf l'ajout à une QList, mais il est possible de ne pas utiliser cette fonction et donc de ne pas avoir ce confort qu'on paie côté perfs.
Il y a quelques temps, alors que je me baladais sur le site, je suis tombé sur http://git.chakra-project.org , une installation de Gitorious sur leurs serveurs.
J'ai parcouru ses sources il y a quelques temps, et c'est un gestionnaire de paquets intéressant. J'ai toutefois relevé quelques problèmes (sachant que je développe aussi un gestionnaire de paquets) :
* Ils utilisent une base de donnée SQLite, qu'ils interrogent en SQL. Ça va les tuer du côté des performances, car le moindre accès à la BDD passe par la création d'une requête SQL, puis son parsing. Ils seront obligés de faire de grosses requêtes (mais pas souvent), puis du traitement du côté C++ pour rattraper le coup.
* Leur solveur de dépendance est un peu trop proche de celui de pacman, c'est à dire «quick and dirty» : on trouve les dépendances, on retire les conflits, et si ça marche pas, on geule. Ça marche bien dans 99% des cas, mais si on a un truc complexe, ça ne va plus.
Par contre, ils ont une belle implémentation des delta-packages, en utilisant XDelta (rapide et efficace, même si moins efficace que bsdiff).
Le code est propre et agréable à lire. Il ne me semble pas qu'il manque trop de fonctionnalités, j'ai lu sur le site qu'ils l'ont testé et que ça marche.
Wait & see donc, mais ça pourrait être intéressant.
J'ai déjà lu ça, mais ce qui m'intéresse, c'est de voir comment se débrouille mon LLVMC qui est quand-même intéressant du fait qu'il n'optimise qu'une seule fois (la compilation est extrêmement rapide, ça défile aussi vite qu'un simple sed un peu recherché).
Le fait que l'optimisation soit faite sur le bytecode final permet de mieux optimiser, d'inliner des fonctions, de propager des constantes, etc. Le LTO, ça marche vraiment, même si on se dit que ça ne sert que dans peu de cas.
Exemple, j'ai dans Setup une fonction nommée matchVersion, qui vérifie qu'une version correspond à une autre comme on veut (en clair, si on lui passe "1.3.4", >=, "1.3.0", elle retourne true). Le truc que j'envoie au milieu est un simple INT, représentant l'opération.
Une partie de mon écriveur de base de donnée s'occupe de rechercher une version exacte. Il envoie donc toujours DEPEND_OP_EQ (le ==). Problème, sans LTO, matchVersion est dans un autre fichier.
Avec LTO, LLVM me détecte que j'envoie une valeur immédiate. Il va alors m'inliner cette fonction, me retirer les ifs qu'il y a dedans, retirer la fonction que je n'appelle donc pas, supprimer une variable inutilisée, inliner une autre fonction dedans, en appliquant le même traitement.
Finalement, un «setup update» passe de 1,2 secondes à 0,8. Pas mal non ?
Alors oui, Clang supporte l'option -O4 qui fait aussi du LTO .. uniquement sur Darwin. En effet, le toolchain Clang sous Linux est encore minimal (en gros : passer le plus vite possible en ELF et appeler les outils de GCC), le gain est donc minimal. Mon LLVMC reste le plus longtemps en bitcode LLVM, et compare donc bien mieux les différences entre GCC et LLVM.
C'est effectivement intéressant, mais il me semble (ce n'est pas clairement marqué, je me base sur un «LLVM GCC frontend») qu'ils utilisent llvm-gcc pour leurs tests, pas Clang.
Et la vitesse gagnée vient justement de Clang, car c'est la partie «font-end» de GCC qui est lente. Il faut également voir si Clang ne produit pas du code que LLVM sait mieux optimiser.
J'avais une fois fait un test sur un programme moyen (400 lignes de C, mais un truc tordu qui construit un suffix-tree puis fait plein d'opérations dessus), et ce programme compilé avec Clang s'exécutait en un peu moins de 0,9 secondes, et un peu plus de 1,1 seconds avec GCC.
Je devrai aussi tester tout ça, avec mon support des optimisations à la liaison, sur un programme qui mouline bien (genre Lame, et ceux que Phoronix utilise pour ses tests de compilateurs). J'ai déjà essayé avec Yafaray, mais il ne veut pas se compiler, même avec GCC. Je donnerai des nouvelles.
Mais la partie «dépêche» est peut-être un peu courte (juste le début, présentation de LLVM, et l'annonce que Clang supporte le C++).
Sinon, pour ceux qui voudraient reproduire mes benchmarks, il faut suivre la documentation que j'ai donné près du lien «pour les hardcore hackers». Dans ce lien, ils vous parleront d'un fichier «tablegen». Au lieu de vous arracher les cheveux à retrouver comment j'ai fait, voici le mien : http://logram-project.org/pastebin-3-n49c4d9a46717.html .
D'ailleurs, j'ai réussi à compiler Neverball avec :) . Ça marche très bien et il est jouable en 640x480 toutes options désactivées (on sent la carte ATI intégrée avec pilotes libres et le L110 ici, gcc faisant la même chose).
En fait, il ne faut pas encore trop évaluer la qualité de Setup sur cette partie, qui n'est encore que minimale.
Si tu veux installer nginx et nginx-mod-smtp, et qu'il n'y a pas d'autres paquets, il faut alors attendre que le premier soit fini, c'est à dire n'installer qu'un paquet à la fois. La partie du code qui ordonnera les paquets détectera ça et abaissera automatiquement les installations en parallèle (et pour ceux qui diraient «oui mais alors, ça ralenti également le reste de la liste», ben s'il y a d'autres paquets dans la liste, le problème ne se pose pas, donc on ne réduit rien du tout).
Cette partie du code sera tout un optimiseur, qui remplira grosso-modo les fonctions suivantes :
* S'arranger pour regrouper les paquets qui proviennent d'un CD ensemble, pour éviter les Insérez le CD 1, Insérez le CD 2, Insérez le CD 1, etc
* Mélanger le plus possible les paquets des autres dépôts, pour pouvoir télécharger depuis autant de serveurs que possible si on DL beaucoup de paquets à la fois
* Commencer la liste par N (où N est le nombre de DL en parallèle) gros paquets sur des dépôts différents, de préférence, puis placer tous ceux venant des CD. Ainsi, pendant le téléchargement, l'utilisateur peut s'amuser à rentrer les CD
* Mettre les dépôts lents au début, les gros fichiers au début, pour éviter que le téléchargement se passe en 10 seconde puis qu'on attente 2h qu'un paquet de 300Mio soit DL depuis un serveur lent
* Encore quelques détails pour les CD en prenant éventuellement en compte le temps de seek du CD (classer les paquets par ordre alphabétique, sachant que c'est dans cet ordre (plus ou moins) que mkisofs les place sur le CD, mais là je ne suis pas sûr).
* Correction des problèmes cités plus haut : gérer les predepends.
Le but de la manoeuvre est de tirer le maximum de tout ce qui tourne autour de l'installation. Maintenir la liste des paquets téléchargés mais pas encore installés la plus importante possible, pour que l'installation aille au maximum de ce que l'ordi permet. Les différents dépôts et mirroirs doivent être les plus utilisés possible, en même temps. Quand aux CD, c'est une question de confort que de ne pas avoir à constamment changer de CD. Et comme je compte à un moment où à un autre distribuer Logram sur CD (+DVD ou quelques CD pour le dépôt), il faut que ce soit bien géré.
Ah oui, il faut aussi optimiser l'accès aux fichiers locaux. Ceux-là, comme ils sont quasiment instantanés, on les met entre les gros DL du début et les premiers CD. Ainsi, on peut commencer à installer très rapidement, pendant qu'on lit des CD et qu'on DL.
Toute une science. Je sens que je vais passez des jours à ce que ça marche bien :) (mais quand ce sera fait, ce sera une des killer-features de Setup).
J'utilise libarchive pour décompresser les archives, et il s'en fiche que xorg.conf.d n'existe pas, il le crée dans ce cas.
En fait, j'ai prévu le machin pour fonctionner dans 98% des cas, et être très rapide. Les 2% des cas restant peuvent soit être contournés (/etc/nginx/conf.d à la place de /etc/nginx/nginx.conf, etc), soit on adapte le solveur.
Par exemple, on sait qu'on va installer disons 2 paquets à la fois. Si le paquet nginx-mod-smtp pré-dépend de nginx, alors la liste des paquets installés (PackageList pour ceux qui lisent le code, ça se trouve sur Gitorious.org, projet "logram") va ordonner les paquets pour s'assurer que nginx sera au moins deux positions avant dans la liste par rapport à nginx-mod-smtp.
Ainsi, ce dernier paquet sait que nginx est d'office installé, et peut fonctionner :) .
Ça existe, il y a déjà pas mal de monde qui y a pensé. Le gestionnaire de paquets, Setup, que je développe, en est au moins un qui fonctionne comme cela.
Il télécharge les paquets et les installe en même temps, sachant qu'on peut également télécharger plusieurs paquets en même temps et en installer plusieurs en même temps.
Pour copier des fichiers, pas besoin d'avoir les dépendances déjà installées. Le seul problème est qu'un paquet peut vouloir modifier une de ses dépendances (mais ça pue, par exemple, on n'écrit pas dans /etc/X11/xorg.conf, on ajoute un fichier dans /etc/X11/xorg.conf.d. Plus de problèmes).
Pour cela, il y a les triggers, qui sont des scripts lancés séquentiellement une fois tous les paquets installés. Par contre, l'ordre des triggers les uns par rapport aux autres n'est pas assuré. Là, des modifications globales sont permises, comme un ldconfig, etc.
Les scripts de postinst et preinst sont eux exécuté juste après l'installation du paquet, par un processus Bash lancé par le thread qui installe le paquet. Ce script ne peut toucher qu'au paquet en cours d'installation (envoi de communications, un système à la debconf mais en mieux intégré, configuration en fonction de l'ordinateur sur lequel le paquet est installé (architecture, paramètres réseau), etc).
Et en effet, ça aide vraiment. Je bootstrap Logram en moins d'une minute, en installant build-essential (qui ramène logram-minimal-core). C'est un système qui ne démarre pas, mais qui contient Bash, les binutils, util-linux-ng, xz, tar, bzip2, less, sed, grep, etc.
Une petite visite de mon site perso, en particulier cette page : http://logram-project.org/packages-4-1.html , te montrera ce que contient ce paquet. Le site en lui-même présente Setup. J'ai également des journaux qui en parlent ainsi qu'une dépêche.
Il est bien à gauche du menu dans lequel il se trouve. Les menus de KDevelop sont architecturés un peu spécialement du fait de la modularité du machin. J'admets que ce n'est pas beau, mais c'est pratique d'avoir toujours les mêmes menus aux mêmes endroits (ceux qui ont utilisé Konqueror en faisant autre-chose que juste du web comprendront).
2) Pourquoi y'a un menu DTD ?
Je ne sais pas, il est vide.
3) Pourquoi y'a des onglets au même niveau que les menus ?
Parce qu'ils changent l'espace de travail (barre d'outils, documents ouvertes) mais pas les menus, et que la place doit être faite pour le code, pas l'interface. Donc on les met là où il y a de la place.
4) Pourquoi on a l'impression que tous les widgets flottent un peu partout n'importe comment ?
Parce que tu es habitué aux interfaces simplistes et pauvres en GTK qui obligent d'ouvrir 3 fenêtres différentes avec 6 niveaux de menus pour avoir la même chose (non je ne vise pas GIMP).
5) Pourquoi faut tourner la tête dans 3 sens différents pour pouvoir tout lire ?
Parce qu'on n'a pas besoin de toute lire en même temps, généralement. On code tranquillement, avec la doc à côté, et on peut ouvrir d'autres fichiers :) .
6) Pourquoi les flèches de l'arbo sont aussi petites ? (ça doit être pratique à cliquer)
Parce que KDE est configurable et que j'aime les petites flèches, tout simplement. On peut aussi mettre des + , choisir la taille des flèches, etc.
7) Pourquoi y'a 2 champs textes côte à côte en haut ? pour se tromper plus facilement ?
Y'en a un avec «Quick Open...» dedans qui permet de rapidement ouvrir un fichier en fonction de ce qu'on tape dedans. L'autre permet de naviguer de fonction en fonction dans le fichier courant.
8) Pourquoi y'a des boutons flèches dans tous les sens ?
Y'a que deux boutons flèches, c'est raisonnable. Les autres flèches viennent du fait que j'ai rétréci la fenêtre au maximum (on ne voit pas toute la largeur du menu, il manque un bout d'onglet, les barres d'outils ne rentrent pas).
En 1280x1024, ça rentre impeccablement et il n'y a plus de flèches.
9) Pourquoi y'a des boutons en haut, sur les côtés, et en dessous de chaque panel ?
Chaque bouton permet d'ouvrir/fermer un panel. Par exemple, si je clique sur le bouton Projects à gauche, ça me ferme le panel Projects et je gagne de la place.
Les panels peuvent être changés de côtés, et même transformés en panels flottants (hors de la fenêtre).
10) Pourquoi le tooltip est blanc sur fond blanc ?
Si ça avait été une autre couleur, t'aurais demandé «Pourquoi les tooltips sont en rose sur fond blanc avec du texte noir dedans ? Pour bien nous pêter les yeux ?».
Le contour est suffisamment gros pour qu'on le voie. Le but de KDevelop est d'être utilisable.
11) Pourquoi l'indicateur de ligne/col est en haut à côté des onglets ?
Parce qu'une barre des tâches occuperait 20px de haut sur toute la largeur de la fenêtre et qu'il faut mettre ça là où il y a de la place, toujours dans un soucis d'optimisation de l'espace.
De plus, comme on change souvent de document, l'oeil a l'habitude de se balader dans cette zone, donc c'est justement mieux placé à l'utilisation que si c'était en bas.
12) Pourquoi y'a un panel 'Projects' et un autre 'Project Selection' ?
J'avoue que je ne sais pas trop. On peut ouvrir plusieurs projets, et il me semble qu'on peut alors choisir dans Project Selection quels projets afficher dans l'arbre au-dessus.
13) Pourquoi y'a tellement de couleurs dans la coloration syntaxique qu'on met 2 heures à comprendre quelle couleur correspond à quoi ?
Chaque variable a sa couleur, et ça met un peu de gaité dans le code :) .
Ce qui n'est pas variable a des couleurs facilement reconnaissable. Gras pour les mots-clefs, bleu clair pour les types génériques (void, int, bool, double, etc), bleu marine pour une fonction membre (en gras si elle est à nous).
Donc non, c'est au contraire une très belle interface conçue avec la plus grande attention (KDevelop était stable depuis 1 an, j'ai suivi sur le SVN cette dernière année, et plus de 50% des commits visaient à rendre l'interface utilisable).
KDevelop, on l'essaie pendant 10 minutes qu'on ne veut plus le quitter. Tout est sous la main, là où on veut, et c'est relativement rapide.
C'est normalement en passant par Projects»Open/Import.... Là, tu clique sur ton fichier CMakeLists.txt principal (ou le fichier .pro si le plugin QMake est installé), et ça roule.
J'ai aussi un Kimsufi, du type XL, première location il y a un peu plus d'un an. De ce temps là, avant la crise, ils étaient mieux pour moins cher (je crois que j'ai 2Gio de RAM, un Pentium 4 HT à 3Ghz, un gros disque, etc).
Ma configuration fait plus ou moins ce que la tienne fait, sauf que c'est rapide comme la foudre et tout léger (sur le 2Gio de RAM, plus d'un Gio disponible pour le cache) :
* nginx, que je conseille, qui permet de servir des pages statiques et des sites dynamiques en Fastcgi. J'ai un site Django qui tourne, sans aucun problème (logram-project.org), super rapidement. J'ai aussi un site PHP qui tourne (Postfix Admin). Donc, nginx sait faire tout ça, et sans avoir besoin d'un lourd Apache.
* Côté BDD, c'est du MySQL, configuration par défaut de Debian, pas tweaké, rien. Il marche super bien, peut enchaîner 3000 requêtes par seconde sans flancher, c'est bon
* J'ai un postfix, qui tourne avec tout ce qu'il faut pour avoir un accès SMTP, SMTPS, IMAP, IMAPS, il utilise une BDD MySQL pour gérer les boîtes mails, un SpamAssassin s'occupe du spam.
* Il y a aussi un serveur Subversion que j'utilise tout simplement avec le protocole svn://, pas besoin de proxy.
* Bien entendu, un serveur SSH tourne aussi
* Il y a eu a un moment un serveur Git, mais j'utilise maintenant Gitorious
Le serveur est donc relativement bourré, et il y a encore de la place libre malgré tout ce qu'il doit faire (par exemple, un serveur de jeu Tremulous marche parfaitement dessus pour les soirées jeu).
Donc mon conseil : Apache n'est pas obligatoire, et nginx est immensément plus rapide. Amusez-vous à jouer sur logram-project.org (pas de panique, y'a pas de pub sur le site, je ne gagne rien à ce que vous veniez), les pages sont rapides, même avec une dizaine d'accès concurrents.
Je vous propose de profiter que je suis un gros fanboy qui passe ses journées à «svn log -v -rBASE:HEAD» tous ses checkouts de parties de KDE. Je pourrais, plus ou moins une fois par semaine, envoyer une dépêche résumant et expliquant ce qu'il s'est passé dans l'univers de KDE (le coeur lui-même, mais également Amarok, Rekonq, KDevelop, etc).
Ça pourrait être intéressant, mais il faut éviter que le site se KDEise trop (sinon les utilisateurs de GNOME pourraient se sentir délaissés, mais ils n'auront alors qu'à créer leur commit-digest à eux).
J'en profite également pour demander s'il ne serait pas possible d'autoriser les balises img dans les dépêches, parce que j'ai toujours plein de choses à montrer, et que comme c'est validé, vous pouvez toujours vérifier ce qu'on met dedans.
Par exemple, pour ma dépêche sur les 2 ans de Logram (ayant ramené moins de 10% des gens qui étaient venus l'année dernière), j'aurais bien ajouté une dizaine de petits screenshots (pour que ça reste léger) montrant un peu ce qu'est Logram, parce que les gens n'ont pas spécialement envie de fouiller un site web pour en trouver.
Voilà. Sinon, pour le site en Ruby, j'ai hâte de voir ce que ça va donner, et j'espère qu'il marchera bien. Je tiens à signaler que si par hasard, vous vous rendez compte que ça ne marche pas, je conseille Django (déjà, on peut créer son schéma de base de donnée aux petits oignons, donc pas besoin de scripts de migration). Là, j'aurais pu vous aider. Visitez http://www.logram-project.org pour voir ce que Django permet, le code est disponible sous AGPLv3 (onglet «Développez», puis «Dépôt en ligne», vous arrivez sur Gitorious, c'est «website»).
Il y a des vidéos à certains endroits, mais j'admets qu'une galerie manque un peu (en n'en a encore jamais eu besoin). Je te conseille de lire les news et leurs commentaires, je laisse de temps en temps une vidéo dedans.
Il y a aussi un des cinq derniers sujets sur le forum qui contient deux vidéos, mais du tout début de Logram Distrib.
[^] # Re: Tiling ?
Posté par steckdenis (site web personnel) . En réponse au journal Kde 4.4.90 est sorti. Évalué à 6.
# PulseAudio
Posté par steckdenis (site web personnel) . En réponse au journal Audio sous Linux. Évalué à 10.
Donc oui, c'est possible avec PulseAudio, normalement de manière graphique (du moins sous GNOME, je ne sais pas s'il y a une bonne intégration à KDE).
Plus encore un léger avantage à PulseAudio : il y a toute son infrastructure en-dessous, donc on peut rediriger la sortie «Musique de fond» d'un jeu vers le haut-parleur droit du casque de l'ordinateur du salon, si on veut.
[^] # Re: Structuration
Posté par steckdenis (site web personnel) . En réponse à la dépêche Sortie d'ownCloud 1.0. Évalué à 7.
KDE, sans rien derrière, c'est la communauté de dev. ownCloud en fait partie car ce sont des devs de KDE qui travaillent dessus, il a été présenté au Camp KDE, il est hébergé chez KDE, présenté sur le dot KDE, etc.
KDE SC et KDE Platform sont bien les briques de base de l'environnement bureau graphique lui-même.
En clair, KDE est bien, mais vraiment bien plus qu'un DE. C'est toute une philosophie, une communauté de personnes ayant une même vision :) .
[^] # Re: ha vi :-)
Posté par steckdenis (site web personnel) . En réponse à la dépêche Sortie d'ownCloud 1.0. Évalué à 4.
Je pense, mais je n'en sais pas grand-chose, que ce sera simplement une synchronisation/partage entre les serveurs par HTTP (requêtes XML, JSON, etc). Le but est simplement de permettre à Monsieur Martin de récupérer directement sur son Cloud la vidéo du mariage de Madame Jacqueline, sans devoir les télécharger sur son ordinateur personnel puis les renvoyer.
Pour le cloud, je ne sais pas. Peut-être une allusion à l'informatique dans les nuages, du point de vue «je partage mes données», ainsi que web 2.0 (on partage des choses, on participe), etc.
[^] # Re: Radeon libre hors compétition?
Posté par steckdenis (site web personnel) . En réponse au journal Test grandeur nature de Nouveau + KDE SC 4.5. Évalué à 3.
En fait, il me semble que les cartes nVidia sont bien plus compatibles entre elles, c'est à dire qu'il n'y a que des différences mineures entre deux cartes, même éloignées dans le temps.
Du côté d'ATI, ils aiment bien refaire l'architecture de leurs cartes de temps en temps. On a les Radeon r200-r500, puis ils ont fait les HD (r600 et r700), puis ils ont fait les Evergreen (Radeon HD 5xxx, sorties en septembre).
Il y a donc 3 pilotes ATI à maintenir, et un seul Nouveau.
Il y a aussi le fait que le pilote ATI est déjà beaucoup utilisé. Ils ne peuvent pas supprimer leur pilote ATI basé uniquement sur Mesa pour se concentrer sur Gallium, du fait qu'il est encore très utilisé. Du côté de Nouveau, comme presque personne ne l'utilise (ils font tout pour), ils peuvent faire un peu ce qu'ils veulent.
[^] # Re: Nouveau
Posté par steckdenis (site web personnel) . En réponse au journal Test grandeur nature de Nouveau + KDE SC 4.5. Évalué à 4.
Et sachant que Nouveau a été un beau chanté pour le 2.6.33, puis à nouveau un gros chantier pour le 2.6.34, je peux comprendre qu'être deux versions du noyau en retard pour nouveau amène des problèmes.
Il y a aussi le fait que Ubuntu 10.04 n'a pas le dernier Mesa, DRM, etc. C'est le problème des trucs en développement : ça change vite.
(mais j'avoue, j'ai réussi à faire freezer mon PC avec Nouveau, mais je ne me souviens plus comment (j'ai activé des effets Kwin au hasard)).
[^] # Re: oui (on veut) mais non (pas celui-la)
Posté par steckdenis (site web personnel) . En réponse à la dépêche SparkleShare pour partager vos fichiers sur internet. Évalué à 2.
Il existe ownCloud, du projet KDE, en C++/Qt et PHP côté serveur. C'est encore expérimental, mais les fonctionnalités sont alléchantes (et elles marchent déjà pour certaine) :
* Partage de fichier
* Le serveur est hébergé chez toi
* Accessible en HTTP tout naturel
* Possibilité de sauvegarder la configuration des applis KDE là-dessus (un peu comme FireFox et ses bookmarks, sauf qu'ici c'est tout l'environnement)
Les fonctionnalités à venir comprendront la sauvegarde de la BDD de Nepomuk, etc.
Mais bien entendu, comme je le dis toujours, KDE c'est trop libre et communautaire pour qu'on en parle quand ils font des trucs bien [/troll].
[^] # Re: Question ouverte ... et Windows ?
Posté par steckdenis (site web personnel) . En réponse au journal Ordinateur portable = Ordinateur jetable. Évalué à 2.
Depuis, les options ont changé, mes souvenirs se sont effacés (/etc/laptop_mode.conf n'existe pas, je voulais parler de /etc/laptop-mode/laptop-mode.conf, mais en mettant un fichier à la racine de /etc, j'était sûr d'être compris).
Si quelque-chose ressemble à *SpinDown, dans une section parlant du disque dur, y'a des chances que ce soit bon.
[^] # Re: Question ouverte ... et Windows ?
Posté par steckdenis (site web personnel) . En réponse au journal Ordinateur portable = Ordinateur jetable. Évalué à 8.
Manque de bol, HAL (ou ext*) avait besoin d'y écrire toutes les 2 secondes. Hahaha, donc toutes les deux secondes, le DD se rallume, écrit quelques octets, et s'éteint.
Au boit de quelques mois et de plus de 2000 cycles d'allumage/extinction, il décidait qu'il en avait marre et ne se rallumait pas.
Le problème est facilement détectable : écoutez attentivement votre disque. S'il faut de petits "clacs" métalliques toutes les 2 secondes (ou 5), c'est que la fonction tueuse est activée.
Pour corriger le problème : éditer /etc/laptop_mode.conf, ou quelque-chose comme ça. A un endroit, ça parle de hdparm -S. Remplacez le 1 ou le 2 par une grande valeur (man hdparm pour voir), genre 100 ou 200. Pour désactiver l'économie d'énergie, utilisez 0.
Il se peut également que certains BIOS mettent cette valeur à 1 tout seuls, auquel cas le problème touche également Windows. Il suffit de lancer un petit «hdparm -S 0 /dev/sd?» au démarrage de l'ordinateur (/etc/rc.local sous ArchLinux). La course à l'autonomie peut tenter les fabriquants de faire ce genre de choses (un netbook par exemple est généralement prévu pour être utilisé à peu près une heure par jour, auquel cas le DD tient juste un peu plus de deux ans).
# Gateway / Packard Bell DOT MA
Posté par steckdenis (site web personnel) . En réponse au journal Ordinateur portable = Ordinateur jetable. Évalué à 6.
Je suis l'heureux possesseur de l'ordinateur portable (ou plutôt netbook) fait pour le geek : le Gateway.
Côté extérieur, on a un superbe écran 11,1" de 1366x768 pixels, bien lumineux et utilisable dehors. Le boitier est léger.
A l'intérieur, on a une carte graphique ATI Radeon X1270 (RS690m), qui marche impec avec les pilotes libres (si on désactive KMS qui a quelques problèmes de corruption mémoire dessus). La carte wifi est reconnue immédiatement, le disque est spacieux (160Gio et pas si lent que ça). Les touches de fonction (son, écran, commande du touchpad, réseau) fonctionnent impeccablement.
Le tout testé sous une ArchLinux avec KDE dessus (oui oui oui, KDE tourne au poil dans 784Mio de RAM (1024 - la mémoire partagée de la carte graphique).
Summum de la geekerie : il est entièrement démontable. Envie de changer l'AMD Athlon 64 L110 (monocoeur 1,2Ghz) par un puissant AMD Athlon 64 L510 (dual coeur 1,6Ghz avec SSE3) ? C'est par ici : http://ftp.packardbell.com/pub/itemnr/CS065A00/dot_ma_disass(...)
Donc oui, on peut démonter tout le netbook : RAM, disque dur, carte réseau, clavier, carte mère, processeur (qui n'est pas soudé, on peut le changer), mais également la dalle LCD (pas juste l'écran, non non non, on retire même le rétro-éclairage).
C'est donc un netbook très évolutif (on peut y mettre 4Gio de RAM, un double-coeur 1,6Ghz, un DD de 1Tio si on veut), et normalement pas trop difficile à réparer (si le disque claque, ça se change. Si la RAM claque, ça se change. Si le proc claque, ça se change aussi).
Perso, je l'ai acheté pour moins de 300€ chez rueducommerce, avec la garantie retour de 1 an (qui m'a déjà servi pour un Hercules eCafé dont la batterie m'a laché deux mois après l'achat. Un mail et un colit, et je recois un bon d'achat de 220€ qui m'a permis d'acheter mon dot MA).
Pour le moment, j'utilise ce netbook comme ordinateur principal. Il est assez rapide pour ça, et son écran est un pur bonheur (j'ai également connecté un bon vieux LCD de 1280x1024 sur sa sortie VGA, que j'utilise comme extension de bureau (écran placé au-dessus, on sait régler sa position avec XRandR).
Client satisfait donc :) (mais bon, ça m'a aussi pris 1 mois pour le trouver).
[^] # Re: Gestionnaire de paquets de Chakra
Posté par steckdenis (site web personnel) . En réponse au journal Chakra se sépare d'Arch. Évalué à 3.
1)
Ça dépend des dépôts. ReiserFS est conçu pour ce genre de choses, donc je veux bien croire que ça aille vite. Il faut aussi compter l'age de l'installation d'ArchLinux. Mon premier update s'est fait en quelques secondes, alors que je suis maintenant à près d'une minute (avec le système inutilisable à cause des IO).
2)
Justement, tu prends en fait la 2e solution. Pour obtenir les dépendances d'un paquet, tu dois faire une requête. Pour chaque dépendance, tu dois prendre leurs dépendances, et ainsi de suite. Finalement, tu te retrouves avec une quantité impressionnante de requêtes sur ta BDD.
Tu peux également faire un gros SELECT qui te ramène toutes les deps, ce qui est justement ma solution 1.
3)
Non, je ne mélange pas. Je parle en fait d'accès, et je n'oppose pas le mmap contre l'accès séquentiel, mais bien l'idée «Je passe par une lib tier à laquelle je parle en requête textuelle» par rapport à «Je fait tout moi-même, sans couche d'abstraction». Sauf que les fichiers mmapés ont également comme avantage d'être plus rapides et d'utiliser moins de RAM (le noyau les considère comme un swap supplémentaire, et utilise un chemin de code rapide et optimisé pour lire les pages, au lieu de passer par des syscalls lents et répétitifs).
4)
La base de donnée est écrite par Setup lui-même (il récupère du serveur des fichiers de texte comme ceux utilisés par Debian, donc en gros du INI). Il n'y a donc aucun problème d'edianess ou d'alignement, le compilateur se charge de tout.
Le fait que ce soit illisible par d'autres programmes n'est pas embêtant pour deux points. Premièrement, Setup utilise une bibliothèque, donc un programme qui veut gérer des paquets utilise cette bibliothèque. Deuxièmement, ce n'est pas comme si c'était un fichier de configuration ou un dépôt de mails, devant être lu par tout le monde. C'est le cache de Setup, ça doit juste être rapide et sûr.
Si un programme devait néanmoins lire la liste des paquets installés, il lui suffit de lire /var/cache/lgrpkg/db/installed_packages.list. C'est un fichier INI lisible avec un QSettings. Setup lit ce fichier quand il reconstruit sa base de donnée (oui, ma BDD a comme problème d'être en lecture seule, donc quand on met à jour, il faut l'effacer et la reconstruire. Ça prend 6 secondes pour y mettre les 27 000 paquets de Sid).
[^] # Re: Gestionnaire de paquets de Chakra
Posté par steckdenis (site web personnel) . En réponse au journal Chakra se sépare d'Arch. Évalué à 1.
En effet, j'ai été regarder dans le dossier /var/lib/pacman, et ça fait peur. Je n'y étais jamais allé, merci de me faire découvrir pourquoi la moitié des inodes de ma partition sont déjà pris, et pourquoi un pacman -Sy prend tant de temps.
Sinon, le SQL peut être très rapide, j'ai eu l'occasion de beaucoup de tester. Il y a un an, j'avais fait un gestionnaire de paquet (j'aime développer des gestionnaires de paquets :-° ) qui utilisant une base SQLite, en passant par QtSql.
Alors oui, il y a des requêtes un peu lourdes, mais assez efficaces. Mais il y a aussi le problème des multiples requêtes.
Par exemple, tu dois résoudre les dépendances d'un paquet. Pour cela, deux solution :
* Une grosse requête qui te dump la table packages_deps, et tu traite le tout en C++. Grosse consommation de RAM
* Plein de petites requêtes quand t'en a besoin
Les deux solutions sont lentes. Je t'invite à regarder comment on peut gérer ça élégamment avec des fichiers mappés : http://gitorious.org/logram/setup/blobs/master/libpackage/da(...) .
Oui, complexité O(nombre de dépendances), très rapide. Du C pur*, pas d'accès à une BDD, c'est indexé, etc.
En fait, une base de donnée binaire fait-maison est la solution la plus rapide qu'il soit, car c'est adapté au problème. Maintenant, obtenir cette rapidité est difficile (perso : 2 mois de réflexion au moins).
Le résultat : à la sortie de Setup 0.1-alpha2, je ferai une vidéo montrant l'instantanéité de tous les traitements de Setup, malgré le fait qu'il utilise un solveur à graphe orienté : http://logram-project.org/news-2-66-1-un-nouveau-solveur-de-(...) . (Solveur d'ailleurs pas encore optimisé, qui compare des chaînes de caractère. Je dois encore faire en sortie qu'il compare des index de chaînes, sachant que toutes les chaines de caractères de la BDD sont indexées).
*Sauf l'ajout à une QList, mais il est possible de ne pas utiliser cette fonction et donc de ne pas avoir ce confort qu'on paie côté perfs.
# Gestionnaire de paquets de Chakra
Posté par steckdenis (site web personnel) . En réponse au journal Chakra se sépare d'Arch. Évalué à 7.
Le projet akabei ( http://git.chakra-project.org/akabei ) contient leur gestionnaire de paquets.
J'ai parcouru ses sources il y a quelques temps, et c'est un gestionnaire de paquets intéressant. J'ai toutefois relevé quelques problèmes (sachant que je développe aussi un gestionnaire de paquets) :
* Ils utilisent une base de donnée SQLite, qu'ils interrogent en SQL. Ça va les tuer du côté des performances, car le moindre accès à la BDD passe par la création d'une requête SQL, puis son parsing. Ils seront obligés de faire de grosses requêtes (mais pas souvent), puis du traitement du côté C++ pour rattraper le coup.
* Leur solveur de dépendance est un peu trop proche de celui de pacman, c'est à dire «quick and dirty» : on trouve les dépendances, on retire les conflits, et si ça marche pas, on geule. Ça marche bien dans 99% des cas, mais si on a un truc complexe, ça ne va plus.
Par contre, ils ont une belle implémentation des delta-packages, en utilisant XDelta (rapide et efficace, même si moins efficace que bsdiff).
Le code est propre et agréable à lire. Il ne me semble pas qu'il manque trop de fonctionnalités, j'ai lu sur le site qu'ils l'ont testé et que ça marche.
Wait & see donc, mais ça pourrait être intéressant.
[^] # Re: Bench entre GCC et LLVM
Posté par steckdenis (site web personnel) . En réponse au journal Clang++ est prêt. Évalué à 3.
Le fait que l'optimisation soit faite sur le bytecode final permet de mieux optimiser, d'inliner des fonctions, de propager des constantes, etc. Le LTO, ça marche vraiment, même si on se dit que ça ne sert que dans peu de cas.
Exemple, j'ai dans Setup une fonction nommée matchVersion, qui vérifie qu'une version correspond à une autre comme on veut (en clair, si on lui passe "1.3.4", >=, "1.3.0", elle retourne true). Le truc que j'envoie au milieu est un simple INT, représentant l'opération.
Une partie de mon écriveur de base de donnée s'occupe de rechercher une version exacte. Il envoie donc toujours DEPEND_OP_EQ (le ==). Problème, sans LTO, matchVersion est dans un autre fichier.
Avec LTO, LLVM me détecte que j'envoie une valeur immédiate. Il va alors m'inliner cette fonction, me retirer les ifs qu'il y a dedans, retirer la fonction que je n'appelle donc pas, supprimer une variable inutilisée, inliner une autre fonction dedans, en appliquant le même traitement.
Finalement, un «setup update» passe de 1,2 secondes à 0,8. Pas mal non ?
Alors oui, Clang supporte l'option -O4 qui fait aussi du LTO .. uniquement sur Darwin. En effet, le toolchain Clang sous Linux est encore minimal (en gros : passer le plus vite possible en ELF et appeler les outils de GCC), le gain est donc minimal. Mon LLVMC reste le plus longtemps en bitcode LLVM, et compare donc bien mieux les différences entre GCC et LLVM.
[^] # Re: Bench entre GCC et LLVM
Posté par steckdenis (site web personnel) . En réponse au journal Clang++ est prêt. Évalué à 3.
C'est effectivement intéressant, mais il me semble (ce n'est pas clairement marqué, je me base sur un «LLVM GCC frontend») qu'ils utilisent llvm-gcc pour leurs tests, pas Clang.
Et la vitesse gagnée vient justement de Clang, car c'est la partie «font-end» de GCC qui est lente. Il faut également voir si Clang ne produit pas du code que LLVM sait mieux optimiser.
J'avais une fois fait un test sur un programme moyen (400 lignes de C, mais un truc tordu qui construit un suffix-tree puis fait plein d'opérations dessus), et ce programme compilé avec Clang s'exécutait en un peu moins de 0,9 secondes, et un peu plus de 1,1 seconds avec GCC.
Je devrai aussi tester tout ça, avec mon support des optimisations à la liaison, sur un programme qui mouline bien (genre Lame, et ceux que Phoronix utilise pour ses tests de compilateurs). J'ai déjà essayé avec Yafaray, mais il ne veut pas se compiler, même avec GCC. Je donnerai des nouvelles.
[^] # Re: un modo dans les parages?
Posté par steckdenis (site web personnel) . En réponse au journal Clang++ est prêt. Évalué à 4.
Mais la partie «dépêche» est peut-être un peu courte (juste le début, présentation de LLVM, et l'annonce que Clang supporte le C++).
Sinon, pour ceux qui voudraient reproduire mes benchmarks, il faut suivre la documentation que j'ai donné près du lien «pour les hardcore hackers». Dans ce lien, ils vous parleront d'un fichier «tablegen». Au lieu de vous arracher les cheveux à retrouver comment j'ai fait, voici le mien : http://logram-project.org/pastebin-3-n49c4d9a46717.html .
D'ailleurs, j'ai réussi à compiler Neverball avec :) . Ça marche très bien et il est jouable en 640x480 toutes options désactivées (on sent la carte ATI intégrée avec pilotes libres et le L110 ici, gcc faisant la même chose).
[^] # Re: Installation des paquets et des dépendances
Posté par steckdenis (site web personnel) . En réponse à la dépêche CUDF, ou la résolution de dépendances universelle. Évalué à 2.
Si tu veux installer nginx et nginx-mod-smtp, et qu'il n'y a pas d'autres paquets, il faut alors attendre que le premier soit fini, c'est à dire n'installer qu'un paquet à la fois. La partie du code qui ordonnera les paquets détectera ça et abaissera automatiquement les installations en parallèle (et pour ceux qui diraient «oui mais alors, ça ralenti également le reste de la liste», ben s'il y a d'autres paquets dans la liste, le problème ne se pose pas, donc on ne réduit rien du tout).
Cette partie du code sera tout un optimiseur, qui remplira grosso-modo les fonctions suivantes :
* S'arranger pour regrouper les paquets qui proviennent d'un CD ensemble, pour éviter les Insérez le CD 1, Insérez le CD 2, Insérez le CD 1, etc
* Mélanger le plus possible les paquets des autres dépôts, pour pouvoir télécharger depuis autant de serveurs que possible si on DL beaucoup de paquets à la fois
* Commencer la liste par N (où N est le nombre de DL en parallèle) gros paquets sur des dépôts différents, de préférence, puis placer tous ceux venant des CD. Ainsi, pendant le téléchargement, l'utilisateur peut s'amuser à rentrer les CD
* Mettre les dépôts lents au début, les gros fichiers au début, pour éviter que le téléchargement se passe en 10 seconde puis qu'on attente 2h qu'un paquet de 300Mio soit DL depuis un serveur lent
* Encore quelques détails pour les CD en prenant éventuellement en compte le temps de seek du CD (classer les paquets par ordre alphabétique, sachant que c'est dans cet ordre (plus ou moins) que mkisofs les place sur le CD, mais là je ne suis pas sûr).
* Correction des problèmes cités plus haut : gérer les predepends.
Le but de la manoeuvre est de tirer le maximum de tout ce qui tourne autour de l'installation. Maintenir la liste des paquets téléchargés mais pas encore installés la plus importante possible, pour que l'installation aille au maximum de ce que l'ordi permet. Les différents dépôts et mirroirs doivent être les plus utilisés possible, en même temps. Quand aux CD, c'est une question de confort que de ne pas avoir à constamment changer de CD. Et comme je compte à un moment où à un autre distribuer Logram sur CD (+DVD ou quelques CD pour le dépôt), il faut que ce soit bien géré.
Ah oui, il faut aussi optimiser l'accès aux fichiers locaux. Ceux-là, comme ils sont quasiment instantanés, on les met entre les gros DL du début et les premiers CD. Ainsi, on peut commencer à installer très rapidement, pendant qu'on lit des CD et qu'on DL.
Toute une science. Je sens que je vais passez des jours à ce que ça marche bien :) (mais quand ce sera fait, ce sera une des killer-features de Setup).
[^] # Re: Installation des paquets et des dépendances
Posté par steckdenis (site web personnel) . En réponse à la dépêche CUDF, ou la résolution de dépendances universelle. Évalué à 2.
En fait, j'ai prévu le machin pour fonctionner dans 98% des cas, et être très rapide. Les 2% des cas restant peuvent soit être contournés (/etc/nginx/conf.d à la place de /etc/nginx/nginx.conf, etc), soit on adapte le solveur.
Par exemple, on sait qu'on va installer disons 2 paquets à la fois. Si le paquet nginx-mod-smtp pré-dépend de nginx, alors la liste des paquets installés (PackageList pour ceux qui lisent le code, ça se trouve sur Gitorious.org, projet "logram") va ordonner les paquets pour s'assurer que nginx sera au moins deux positions avant dans la liste par rapport à nginx-mod-smtp.
Ainsi, ce dernier paquet sait que nginx est d'office installé, et peut fonctionner :) .
[^] # Re: Installation des paquets et des dépendances
Posté par steckdenis (site web personnel) . En réponse à la dépêche CUDF, ou la résolution de dépendances universelle. Évalué à 4.
Ça existe, il y a déjà pas mal de monde qui y a pensé. Le gestionnaire de paquets, Setup, que je développe, en est au moins un qui fonctionne comme cela.
Il télécharge les paquets et les installe en même temps, sachant qu'on peut également télécharger plusieurs paquets en même temps et en installer plusieurs en même temps.
Pour copier des fichiers, pas besoin d'avoir les dépendances déjà installées. Le seul problème est qu'un paquet peut vouloir modifier une de ses dépendances (mais ça pue, par exemple, on n'écrit pas dans /etc/X11/xorg.conf, on ajoute un fichier dans /etc/X11/xorg.conf.d. Plus de problèmes).
Pour cela, il y a les triggers, qui sont des scripts lancés séquentiellement une fois tous les paquets installés. Par contre, l'ordre des triggers les uns par rapport aux autres n'est pas assuré. Là, des modifications globales sont permises, comme un ldconfig, etc.
Les scripts de postinst et preinst sont eux exécuté juste après l'installation du paquet, par un processus Bash lancé par le thread qui installe le paquet. Ce script ne peut toucher qu'au paquet en cours d'installation (envoi de communications, un système à la debconf mais en mieux intégré, configuration en fonction de l'ordinateur sur lequel le paquet est installé (architecture, paramètres réseau), etc).
Et en effet, ça aide vraiment. Je bootstrap Logram en moins d'une minute, en installant build-essential (qui ramène logram-minimal-core). C'est un système qui ne démarre pas, mais qui contient Bash, les binutils, util-linux-ng, xz, tar, bzip2, less, sed, grep, etc.
Une petite visite de mon site perso, en particulier cette page : http://logram-project.org/packages-4-1.html , te montrera ce que contient ce paquet. Le site en lui-même présente Setup. J'ai également des journaux qui en parlent ainsi qu'une dépêche.
Voilà, j'ai assez fait ma pub.
[^] # Re: Interface de l'enfer
Posté par steckdenis (site web personnel) . En réponse à la dépêche Sortie de KDevelop 4.0. Évalué à 6.
1) Pourquoi le menu File est au milieu ?
Il est bien à gauche du menu dans lequel il se trouve. Les menus de KDevelop sont architecturés un peu spécialement du fait de la modularité du machin. J'admets que ce n'est pas beau, mais c'est pratique d'avoir toujours les mêmes menus aux mêmes endroits (ceux qui ont utilisé Konqueror en faisant autre-chose que juste du web comprendront).
2) Pourquoi y'a un menu DTD ?
Je ne sais pas, il est vide.
3) Pourquoi y'a des onglets au même niveau que les menus ?
Parce qu'ils changent l'espace de travail (barre d'outils, documents ouvertes) mais pas les menus, et que la place doit être faite pour le code, pas l'interface. Donc on les met là où il y a de la place.
4) Pourquoi on a l'impression que tous les widgets flottent un peu partout n'importe comment ?
Parce que tu es habitué aux interfaces simplistes et pauvres en GTK qui obligent d'ouvrir 3 fenêtres différentes avec 6 niveaux de menus pour avoir la même chose (non je ne vise pas GIMP).
5) Pourquoi faut tourner la tête dans 3 sens différents pour pouvoir tout lire ?
Parce qu'on n'a pas besoin de toute lire en même temps, généralement. On code tranquillement, avec la doc à côté, et on peut ouvrir d'autres fichiers :) .
6) Pourquoi les flèches de l'arbo sont aussi petites ? (ça doit être pratique à cliquer)
Parce que KDE est configurable et que j'aime les petites flèches, tout simplement. On peut aussi mettre des + , choisir la taille des flèches, etc.
7) Pourquoi y'a 2 champs textes côte à côte en haut ? pour se tromper plus facilement ?
Y'en a un avec «Quick Open...» dedans qui permet de rapidement ouvrir un fichier en fonction de ce qu'on tape dedans. L'autre permet de naviguer de fonction en fonction dans le fichier courant.
8) Pourquoi y'a des boutons flèches dans tous les sens ?
Y'a que deux boutons flèches, c'est raisonnable. Les autres flèches viennent du fait que j'ai rétréci la fenêtre au maximum (on ne voit pas toute la largeur du menu, il manque un bout d'onglet, les barres d'outils ne rentrent pas).
En 1280x1024, ça rentre impeccablement et il n'y a plus de flèches.
9) Pourquoi y'a des boutons en haut, sur les côtés, et en dessous de chaque panel ?
Chaque bouton permet d'ouvrir/fermer un panel. Par exemple, si je clique sur le bouton Projects à gauche, ça me ferme le panel Projects et je gagne de la place.
Les panels peuvent être changés de côtés, et même transformés en panels flottants (hors de la fenêtre).
10) Pourquoi le tooltip est blanc sur fond blanc ?
Si ça avait été une autre couleur, t'aurais demandé «Pourquoi les tooltips sont en rose sur fond blanc avec du texte noir dedans ? Pour bien nous pêter les yeux ?».
Le contour est suffisamment gros pour qu'on le voie. Le but de KDevelop est d'être utilisable.
11) Pourquoi l'indicateur de ligne/col est en haut à côté des onglets ?
Parce qu'une barre des tâches occuperait 20px de haut sur toute la largeur de la fenêtre et qu'il faut mettre ça là où il y a de la place, toujours dans un soucis d'optimisation de l'espace.
De plus, comme on change souvent de document, l'oeil a l'habitude de se balader dans cette zone, donc c'est justement mieux placé à l'utilisation que si c'était en bas.
12) Pourquoi y'a un panel 'Projects' et un autre 'Project Selection' ?
J'avoue que je ne sais pas trop. On peut ouvrir plusieurs projets, et il me semble qu'on peut alors choisir dans Project Selection quels projets afficher dans l'arbre au-dessus.
13) Pourquoi y'a tellement de couleurs dans la coloration syntaxique qu'on met 2 heures à comprendre quelle couleur correspond à quoi ?
Chaque variable a sa couleur, et ça met un peu de gaité dans le code :) .
Ce qui n'est pas variable a des couleurs facilement reconnaissable. Gras pour les mots-clefs, bleu clair pour les types génériques (void, int, bool, double, etc), bleu marine pour une fonction membre (en gras si elle est à nous).
Donc non, c'est au contraire une très belle interface conçue avec la plus grande attention (KDevelop était stable depuis 1 an, j'ai suivi sur le SVN cette dernière année, et plus de 50% des commits visaient à rendre l'interface utilisable).
KDevelop, on l'essaie pendant 10 minutes qu'on ne veut plus le quitter. Tout est sous la main, là où on veut, et c'est relativement rapide.
[^] # Re: Comment qu'on importe des projets cmake/qmake ?
Posté par steckdenis (site web personnel) . En réponse à la dépêche Sortie de KDevelop 4.0. Évalué à 2.
C'est normalement en passant par Projects»Open/Import.... Là, tu clique sur ton fichier CMakeLists.txt principal (ou le fichier .pro si le plugin QMake est installé), et ça roule.
# Mon expérience
Posté par steckdenis (site web personnel) . En réponse au journal Apache vs Cherokee / PostgreSQL vs MySql. Évalué à 2.
J'ai aussi un Kimsufi, du type XL, première location il y a un peu plus d'un an. De ce temps là, avant la crise, ils étaient mieux pour moins cher (je crois que j'ai 2Gio de RAM, un Pentium 4 HT à 3Ghz, un gros disque, etc).
Ma configuration fait plus ou moins ce que la tienne fait, sauf que c'est rapide comme la foudre et tout léger (sur le 2Gio de RAM, plus d'un Gio disponible pour le cache) :
* nginx, que je conseille, qui permet de servir des pages statiques et des sites dynamiques en Fastcgi. J'ai un site Django qui tourne, sans aucun problème (logram-project.org), super rapidement. J'ai aussi un site PHP qui tourne (Postfix Admin). Donc, nginx sait faire tout ça, et sans avoir besoin d'un lourd Apache.
* Côté BDD, c'est du MySQL, configuration par défaut de Debian, pas tweaké, rien. Il marche super bien, peut enchaîner 3000 requêtes par seconde sans flancher, c'est bon
* J'ai un postfix, qui tourne avec tout ce qu'il faut pour avoir un accès SMTP, SMTPS, IMAP, IMAPS, il utilise une BDD MySQL pour gérer les boîtes mails, un SpamAssassin s'occupe du spam.
* Il y a aussi un serveur Subversion que j'utilise tout simplement avec le protocole svn://, pas besoin de proxy.
* Bien entendu, un serveur SSH tourne aussi
* Il y a eu a un moment un serveur Git, mais j'utilise maintenant Gitorious
Le serveur est donc relativement bourré, et il y a encore de la place libre malgré tout ce qu'il doit faire (par exemple, un serveur de jeu Tremulous marche parfaitement dessus pour les soirées jeu).
Donc mon conseil : Apache n'est pas obligatoire, et nginx est immensément plus rapide. Amusez-vous à jouer sur logram-project.org (pas de panique, y'a pas de pub sur le site, je ne gagne rien à ce que vous veniez), les pages sont rapides, même avec une dizaine d'accès concurrents.
[^] # Re: Et sinon...
Posté par steckdenis (site web personnel) . En réponse au journal Xorg 1.8: épatant ?. Évalué à 2.
Ce problème m'arrive de temps en temps avec Konqueror, je retourne en arrière et récupère tout mon texte exactement comme il était :-) .
/Troll
# KDE commit digest
Posté par steckdenis (site web personnel) . En réponse au journal Faut-il supprimer la tribune ? (suite). Évalué à 5.
Je vous propose de profiter que je suis un gros fanboy qui passe ses journées à «svn log -v -rBASE:HEAD» tous ses checkouts de parties de KDE. Je pourrais, plus ou moins une fois par semaine, envoyer une dépêche résumant et expliquant ce qu'il s'est passé dans l'univers de KDE (le coeur lui-même, mais également Amarok, Rekonq, KDevelop, etc).
Ça pourrait être intéressant, mais il faut éviter que le site se KDEise trop (sinon les utilisateurs de GNOME pourraient se sentir délaissés, mais ils n'auront alors qu'à créer leur commit-digest à eux).
J'en profite également pour demander s'il ne serait pas possible d'autoriser les balises img dans les dépêches, parce que j'ai toujours plein de choses à montrer, et que comme c'est validé, vous pouvez toujours vérifier ce qu'on met dedans.
Par exemple, pour ma dépêche sur les 2 ans de Logram (ayant ramené moins de 10% des gens qui étaient venus l'année dernière), j'aurais bien ajouté une dizaine de petits screenshots (pour que ça reste léger) montrant un peu ce qu'est Logram, parce que les gens n'ont pas spécialement envie de fouiller un site web pour en trouver.
Voilà. Sinon, pour le site en Ruby, j'ai hâte de voir ce que ça va donner, et j'espère qu'il marchera bien. Je tiens à signaler que si par hasard, vous vous rendez compte que ça ne marche pas, je conseille Django (déjà, on peut créer son schéma de base de donnée aux petits oignons, donc pas besoin de scripts de migration). Là, j'aurais pu vous aider. Visitez http://www.logram-project.org pour voir ce que Django permet, le code est disponible sous AGPLv3 (onglet «Développez», puis «Dépôt en ligne», vous arrivez sur Gitorious, c'est «website»).
[^] # Re: pourquoi ? (troll inside)
Posté par steckdenis (site web personnel) . En réponse à la dépêche Le projet Logram fête ses deux ans. Évalué à 1.
Il y a aussi un des cinq derniers sujets sur le forum qui contient deux vidéos, mais du tout début de Logram Distrib.