Posté par Amand Tihon (page perso, ) le 12/02/2006 à 00:40. (lien). Évalué à 2.

Heureusement qu'on a inventé les MX secondaires :)

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 01/02/2006 à 21:17. (lien). Évalué à 1.

Je ne sais pas quelles versions sont disponibles en Sarge, mais ça fait quelques temps que les paquets se nomment "linux-image-...." et plus "kernel-image-..."

Peut-être est-ce la raison pour laquelle tu ne trouves plus ce que tu cherches ? :)

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 21/01/2006 à 18:21. (lien). Évalué à 2.

C'est exactement ce que je voulais dire.

Et c'est pour ça que moi-même, j'aime bien le numérique. Facile, rapide, pas cher après l'achat initial, et de qualité amplement suffisante pour mon utilisation (photos du Fosdem, du réveillon de Noël, de la manif contre les brevets logiciels, d'un anniversaire, ...)

Mais je crois qu'il reste et restera longtemps assez de personnes accro à l'argentique pour que la disparition de ce support ne soit pas immédiate.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 20/01/2006 à 18:00. (lien). Évalué à 6.

L'argentique mort, c'est vite dit.

Moi, je me demande combien de décennies il va falloir attendre avant de ne plus trouver de 24x36.

Après une tentative de passage au numérique (en Minolta, justement), mon père a comparé un tirage papier d'une image sortant d'un des derniers Canon 12Mpix, et celui obtenu depuis une diapo... Pour le moment en tout cas, c'est sans appel (je n'ose pas dire « ya pas photo » :-p)
Sur http://www.profil-couleur.com/pp/210-rvb.php on trouve des graphiques très intéressants, illustrant les problèmes de profondeurs de couleurs. Le premier, sRGB, est celui utilisé par tous les labos, et supporté par tous les APN. Le second, à peu près AdobeRGB, est utilisé en impression "pro" et supporté par les APN corrects. Le troisième correspond à l'argentique. Ces graphiques permettent de "voir" pourquoi une dia a tellement plus d'impact et de profondeur que le meilleur tirage numérique.

Le format APS, censé tuer le 24x36 à court terme, a fait long feu.

Un négatif abîmé se scanne malgré tout sans problème. Un CD ou un DVD gravé avec tes photos a une durée de vie moyenne de 3 à 5 ans... Et quand il est illisible, c'est foutu.

Alors bien sûr, le numérique va exploser. Mais je ne parierais certainement pas sur la mort imminente de l'argentique.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 20/01/2006 à 06:09. (lien). Évalué à 2.

Tiens, je croyais naïvement qu'au contraire, les réels permettaient toujours d'intercaler un nombre entre deux autres :)

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 19/01/2006 à 16:05. (lien). Évalué à 5.

Es-tu sûr de ne pas entourer ton expression sed par des guillemets simples ?

Parce que je viens de tester dans un terminal chez moi, et « ça juste marche. »

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 15/01/2006 à 08:42. (lien). Évalué à 6.

Alors c'est sûr et certain, la finalité de FTP n'est pas la même que celle de NFS. Effectivement, FTP ne permet pas tout ce qu'offre NFS.

Par contre, je maintiens, persiste et signe, j'ouvre sans problème dans mon éditeur de texte des fichiers présents sur un serveur FTP. Simplement, c'est fait au niveau applicatif par les kioslaves, et pas par le système. C'est ça que je voulais dire quand je parlais d'utiliser le FTP de manière transparente : je me fiche de savoir si ça se passe en local, FTP, sftp, NFS ou Samba, mes applications ne broncheront pas et j'éditerai sagement mon fichier. Je le fais rarement en FTP, mais je le fais tous les jours en fish://

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 15/01/2006 à 03:23. (lien). Évalué à 4.

Ça m'arrive très souvent, même si je préfère le faire en sftp ou en fish.

Et je le fais tant sous KDE qu'en console avec Midnight Commander.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 12/01/2006 à 20:42. (lien). Évalué à 8.

Tu as sans doute dans ton fichier xorg.conf, le clavier qui est configuré en "pc104" :

Option "XkbModel" "pc104"

Remplace ce "pc104" par "pc105" et relance X, ça devrait aller mieux.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 29/12/2005 à 09:35. (lien). Évalué à 4.

lukeg parle plutôt de Blood+, une série actuellement en cours, très fortement inspirée de Blood - The last vampire.

Pas de réel lien d'histoire entre les deux jusqu'à présent, mais je ne désespère pas que ça change.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 25/12/2005 à 17:12. (lien). Évalué à 2.

Un autre moyen en python est d'utiliser les métaclasses, ce qui permet de traiter le singleton comme n'importe quel autre type de classe au moment de l'instanciation.

J'ai sûrement du piquer l'idée ailleurs, et vous pouvez voir le principe sur http://wiki.alrj.org/SingletonMeta (pour garder l'indentation). Par contre, ça manque de dommentaire :)

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 23/12/2005 à 12:31. (lien). Évalué à 4.

La xlib, elle peut faire tant de round-trips qu'elle veut, ca n'empeche pas de faire du double buffering [...] alors pourquoi on n'en a toujours pas, toolkits / WM foireux ?

Toolkits qui ne tirent pas profit du backing-store.

Il me semble pas avoir déjà vu un affichage sans trainées sous X, c'est mieux sous les WM légers (style FVWM) parce que les décorations étaient plus légères, mais il y a des trainées quand même.

Décorations légères ou non, c'est le WM qui est chargé de dire aux applications quand elles doivent se redessiner. Il est donc évident que son rôle est important.

En enfin c'est certainement pas aux développeurs d'applications de gérer leur rafraichissement, sinon on est pas prêt de voir un affichage fluide !

Ben non, c'est le toolkit qui s'en charge.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 23/12/2005 à 09:05. (lien). Évalué à 4.

Permet-moi de reprendre ton argument Mozilla pour suivre ton raisonnement.

Voilà ma question : Que fallait-il changer à X pour que Mozilla affiche l'image plus vite ?

La réponse est évidente : X n'est pas en cause (ou très peu), il fallait changer l'application.

C'est pareil pour une fenêtre qui doit se redessiner quand une partie devient visible. Si l'application ne redessine pas sa fenêtre, tu as des traînées.

Et quand je dis « changer l'application, » je parle aussi de la xlib, qui implique toute une série de round-trips inutiles entre X, le WM et l'appli.

Les applications dont l'affichage est principalement statique (du point de vue de l'ordinateur : un navigateur change souvent de page et scrolle, mais reste immobile pendant de loooooongs moments pour le CPU) ont tout intérêt à utiliser une fonctionnalité que X offre depuis des années, le backing-store.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 23/12/2005 à 08:48. (lien). Évalué à 6.

Pourquoi pas ? À cause de l'OpenGL ?


xmoto est injouable sur mon portable (driver vesa). Bouger la souris dans le menu est déjà une gageure.
Voyons ce que dit glxinfo :

direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2


Mais si je le ssh depuis ma machine de bureau qui a une nvidia et ses drivers propriétaires, je peux jouer sans le moindre problème, c'est fluide.

Je n'ai bien sûr toujours pas de Direct Rendering dans ce cas, mais glxinfo me signale malgré tout ceci d'intéressant :

direct rendering: No
server glx vendor string: NVIDIA Corporation
server glx version string: 1.3


Et crois-moi, c'est accéléré.

Ça m'avait vachement surpris la première fois. Je montrais l'utilisation de X/ssh à un ami windowsien puis j'ai du dire quelque chose comme « évidemment, pour les trucs en 3D, ça marche pas. » J'ai voulu prouver mes dires, et on était tous les deux sur le cul...

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 23/12/2005 à 01:53. (lien). Évalué à 6.

Pour ça, tu peux spécifier plusieurs sections « ServerLayout » et utiliser l'option -layout au lancement de X.
Mais il faut toujours relancer X, tout ce que tu éviteras, ce sera la copie du xorg.conf.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 23/12/2005 à 00:40. (lien). Évalué à 10.

J'ai envie de rebondir sur ce commentaire pour apporter ma petite pierre personnelle à cette discussion.

J'entend très souvent des gens se plaindre de X, pour toutes sortes de raisons, généralement mauvaises. Aurélien me pardonnera d'utiliser aussi les remarques qu'il m'a faites sur IRC :)

Je vais tenter d'expliquer l'origine des remarques, et pourquoi elles sont infondées.

1. X est lent parce qu'il utilise le réseau, même en local.
(On la voit moins ces derniers temps, c'est vrai.)

Des sockets sont utilisés pour le dialogue entre les applications et le serveur X. Cela a porté certaines personnes à penser que retirer le support réseau de X permettrait une avancée en termes de vitesse, parce que le réseau est une couche inutile pour une utilisation en local.

Mais voilà : en local, X utilise les sockets UNIX, qui sont une des formes les plus rapides d'IPC sous linux. Keith Packard (vous savez, le type qui innove dans X depuis bien longtemps et qui veut que ce soit rapide) avait comparé l'utilisation des sockets UNIX avec celle de la mémoire partagée pour le dialogue applis-serveur. C'était sans appel...

2. X est lent parce qu'il dessine lentement.
Vous déplacez une fenêtre et celles qui se trouvent en dessous peinent à se mettre à jour, vous voyez des trainées. Vous en concluez que X est lent pour afficher un pixmap.

Pour voir si l'affichage d'un pixmap à l'écran est vraiment lent chez vous, je vous propose de lancer x11perf -copypixwin500, qui va afficher à l'écran un pixmap de 500x500 et mesurer le temps que ça prend. Chez moi, c'est environ 2000 affichages par seconde. Ce n'est donc pas ça qui est lent. Faites d'autres tests de x11perf pour vous convaincre, si nécessaire. Vous devriez en conclure que X est rapide. Très rapide.

3. Un serveur X par dessus OpenGL serait plus rapide
Peut-être un peu. On associe souvent (parfois inconsciemment) OpenGL et rapidité, et on oublie que ce n'est qu'une API, une manière d'attaquer le driver.
Par contre, c'est une API connue et maitrisée par de très nombreuses personnes et sensiblement identique pour tous les modèles de carte graphique, ce qui pourrait permettre un développement plus aisé. Faire du « Tout OpenGL » accélérera sans doute les effets spéciaux (transparence, déformation, exposé-like, ...), mais pas le reste. Ce qui sera accéléré par contre, c'est le développement sur une API connue.

4. X bouffe plein de RAM
Vous êtes gentiment connecté sur votre session X, et il vous vient tout à coup à l'idée de lancer un ps aux | grep X. Vous constatez alors que X utilise 285660 Ko, près de 280Mo. Woah !

Blâmez (si j'ose dire) votre soif d'avoir des applications ouvertes. Chaque application va demander au serveur X de lui allouer des pixmaps pour les fenêtres, les icones, les boutons, et plein d'autres choses. Tout ceci se retrouve compté pour X... Ajoutez à ça les zone de RAM vidéo qui sont mappées mais ne consomment pas de RAM système.

Vous pouvez faire le test très simplement (Note: Votre kilométrage peut varier, comme on dit.)
Toute instance de X étant fermée, faites un free -k dans une console et regardez la première valeur de la ligne +/- buffers/cache:. Elle vous indique la quantité de RAM réellement utilisée.
Dans une autre console, lancez juste X (pas startx ou xinit, juste X). Revenez sur la première console, relancez free -k et, ô miracle, X ne prend que 12 Mo ! Un examen attentif de la sortie de ps aux indique en outre que près de 10 Mo sont partagés. Pas très utile si vous n'avez qu'une session, mais intéressant pour ceux qui utilisent des terminaux distants. (Voir aussi le post de zero heure un peu plus bas.)

5. Le backing-store est la panacée, tout le monde doit l'utiliser
Ca commence à être possible, mais n'oubliez pas que si chaque fenêtre veut s'enregistrer dans le serveur X, le point 4 va recommencer à faire grincer des dents :)
Avec deux écrans, ma résolution est de 3648*1536, en 32bits. J'ai au strict minimum six bureaux remplis. Quantité de RAM nécessaire pour mettre tout ça en backing-store : 128Mo...

Le backing-store doit être utilisé là où il sera le plus utile, comme l'affichage d'images. Un mplayer ou une Konsole n'en ont pas besoin !

Mais alors pourquoi c'est lent ?

Principalement pour deux raisons.

La première, c'est que vos applications se redessinent lentement. Si je déplace une fenêtre à cheval sur le bureau (couleur unie), une konsole (fonte bitmap) et un konqueror, je n'ai des traînées qu'à un endroit : sur konqueror. Ici, le backing-store servirait bien.

La seconde raison, Aurélien l'a déjà évoquée : la xlib suce des huitres ! (mais non, c'est pas un troll)
Le protocole X est super, asynchrone, rapide... et la xlib est synchrone. Ça signifie que vos applis passent leur temps à attendre les réponses du serveur alors qu'elles pourraient s'en passer. Si ça se voit moins en local, c'est catastrophique dès que la latence grimpe un peu. XCB/XCL devraient permettre de corriger ce problème tout en gardant la compatibilité avec la xlib.

Je me permets une petite réflexion sous forme de questions pour terminer ce (trop) long post :
Pourquoi est-ce qu'à chaque troll sur Xorg (et avant lui, sur Xfree), ce sont les « mauvaises » critiques qui ressortent ?

Pourquoi personne ne s'étonne qu'il ne soit pas possible d'ajouter un écran à la volée, ou de passer d'un mode clone à un mode bureau étendu ?
Pourquoi faut il faire tant d'efforts pour brancher et configurer une tablette graphique ?
Pourquoi est-il tout simplement si complexe à configurer ?

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 22/12/2005 à 22:19. (lien). Évalué à 4.

Pour le /dev/input/eventX, si tu utilises udev, tu peux facilement le forcer sur une valeur "utilisable".

Tu trouveras une manière de faire sur http://floam.sh.nu/index.xhtml?page=guides&section=mx100(...) par exemple.

Ma configuration est très légèrement différente :

KERNEL="event*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e" NAME="input/event-mx1000" SYMLINK="input/%k"
KERNEL="mouse*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e" NAME="input/mouse-mx1000" SYMLINK="input/%k"

Il ne reste plus qu'à spécifier le nom du périphérique dans ton xorg.conf.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 22/12/2005 à 22:09. (lien). Évalué à 3.

Alors je dirais que ce n'est pas X qui est en cause, mais le WM ou les applis.

J'ai un 22" en 2048*1536 et un 19" en 1600*1200 en twinview, et avec mon ancien amd 1600+ (j'ai changé depuis) le changement de bureau était presque instantané. Et j'ai 10 bureaux, dont habituellement au moins 6 remplis...

PS: config de l'époque: AMD 1600+, 515Mo, GeForce 5700, KDE. Je ne crois pas que nos cartes graphiques seules impliquent une telle différence en utilisation 2D classique.

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 17/12/2005 à 16:09. (lien). Évalué à 5.

Je n'ai pas regardé pour les autres, mais seules les version de Wordpress antérieures à la 1.5 sont vulnérables, comme indiqué sur http://wordpress.org/development/2005/11/wordpress-is-secure(...)

[ Répondre ]

Posté par Amand Tihon (page perso, ) le 08/12/2005 à 00:04. (lien). Évalué à 5.

Mais y ajouter éditeur de code (la super intégration de kate dont tu parles) et suite bureautique (via le kpart koffice), c'est abusé :-/

Non, quand ils sont intégrés à konqueror, ce ne sont pas des éditeurs mais des afficheurs. Ils sont en mode lecture seule. Et c'est bien là que ça prend tout son sens, parce que tes préférences longuement peaufinées pour ton Kate, tu les retrouves dès que tu regardes un code source, d'où qu'il vienne (en local, sur un site web, en fish:// sur ton serveur, à l'intérieur d'un .tgz, ...)

En règle général, en mode "File Browser", un clic avec le bouton central appellera l'application externe associée, plutôt que le viewer interne. (Pour les critiques, il est évidemment possible de spécifier que par défaut, tel type de document doit toujours s'ouvrir avec l'appli externe, ou suivre les préférences de son "groupe" -> image/* en viewer intégré, video/* en externe, par exemple.)

[ Répondre ]