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 :)
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 !
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.
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...
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.
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 ?
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.
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.)
Quand j'ai installé Linux sur le PC de mon père qui était sous Win98, je lui ai mis un bureau KDE. Mplayer, Kmail, bidule, machine, tout configuré. Il se débrouillait sous Windows, comme n'importe quelle personne un tout petit peu curieuse se débrouille.
Mais je ne lui ai rien expliqué ! Je lui ai demandé (s'il était d'accord) de tout découvrir par lui-même. Qu'il fouille le menu, qu'il trouve tout seul quelle est l'icône sur laquelle cliquer pour ses mails, comment surfer, etc.
Le lendemain soir, il m'a dit qu'il avait trouvé ses repères. Il m'a demandé comment passer mplayer en plein écran, et m'a appris qu'on pouvait faire un drag/drop depuis une entrée du menu K vers kicker... Je n'y avais jamais pensé, et lui a trouvé ça tout à fait naturel.
Il y a des choses "complexes" sous linux (ah... Debian), comme configurer le réseau, qu'il ne sait pas faire. Mais qu'il ne savait pas faire sous Windows non plus.
L'un dans l'autre, tout ce qu'il avait pris l'habitude d'utiliser sous Windows, il l'a retrouvé dans son KDE. Et sans explications de ma part.
Quand j'ai besoin de recompiler un paquet debian, c'est normalement parce que les options choisies ne me conviennent pas ou pour installer une nouvelle version mineure, et c'est très rare.
Dans ces cas-là, je suis plutôt adepte de dpkg-buildpackage, précédé d'un "dch -v blabla". Comme version, je donne habituellement un truc très légèrement plus grand que la version debian actuelle, pour qu'il ne soit automatiquement installé que si quelque chose de neuf arrive officiellement.
Un bon choix dans la version (un meilleur choix que "blabla" en tout cas) permet de prévoir de manière assez fine le comportement du paquet maison.
- Je veux, lorsque la version 2.0 arrive, mais pas avant, que le paquet officiel remplace le mien : je mets 1.9.9-0.alrj.1
- Ça concerne un bug que j'ai reporté, et l'auteur m'a affirmé que ce serait résolu dans le prochain upload : j'ajoute juste .alrj.1 à la version officielle (1.2.3-4 -> 1.2.3-4.alrj.1)
De manière générale, toutes les versions de mes paquets contiennent "alrj' dans la partie concernant la révision, ça permet de voir rapidement si c'est un paquet maison ou non.
Mais je ne m'amuse pas à compiler tous mes paquets pour les optimiser : en x86_64, il n'y a pas un lourd passé avec lequel il faut rester compatible :)
Je ne pense pas que les tarifs de Belgacom soient anti-compétitifs (corrigez-moi si je me trompe). Environ 40¤/mois pour un quota de 10Go, IP statique impossible, port 25 en sortie limité au relay Belgacom, vitesses de 4M/256k.
Pour 65¤, mêmes caractéristiques sauf le quota qui passe à 30Go. Je ne crois pas qu'ils vendent à perte...
C'est le prix de la mise en place d'un réseau parallèle qui pose problème.
Le dégroupage en Belgique existe bel et bien (appelé BRUO). Belgacom place la paire DSL à ceux qui le demandent, libre à eux après d'installer des DSLAM et des fibres pour que tout ça fonctionne. Et c'est là le problème : aucun FAI n'est capable d'investir la somme nécessaire pour offrir un dégroupage plus ou moins généralisé. Ça vient, mais tout doucement, voyez Scarlet One.
Donc pour le moment, ce qu'on voit partout, ce sont des abonnements appelés BROBA : le FAI loue l'infrastructure à Belgacom et a le choix entre plusieurs profils de vitesse.
Comme les possibilités en BRUO et BROBA sont à peu de choses près identiques, les providers proposent du BROBA, qui leur revient infiniment moins cher.
Mais le dégroupage existe depuis au moins aussi longtemps qu'en France, il me semble.
Mais l'article dont tu donnes le lien parle de « supporter KDE dans OpenSuSE », leur décision du jour est peut d'être de le supporter (dans le sens de fournir du support) aussi pour les versions Enterprise ?
Si je n'ai rien compris à l'histoire, merci de m'éclairer :)
Tu dois normalement avoir un fichier /etc/qemu-ifup qui se charge de ça. Chez moi :
allergy@hali:~$ cat /etc/qemu-ifup
#!/bin/sh
echo "Setting $1 user..."
sudo -p "Password for $0:" /usr/sbin/tunctl -u 'allergy' -t $1
echo "Activating link for $1..."
sudo -p "Password for $0:" /bin/ip link set $1 up
echo "Adding IP address on $1..."
sudo -p "Password for $0:" /bin/ip addr add 172.16.0.10/24 dev $1
echo "Done."
Dans l'ordre:
- création du tun0 (passé en argument) avec tunctl
- activation de l'interface
- ajout de l'ip
Je n'ai jamais vraiment utilisé ifconfig, lui ayant toujours préféré iproute.
À mon avis, ton problème vient soit de la création de l'interface, qui se fait avec tunctl, soit de l'utilisation de ifconfig.
Tu peux, au choix:
- taper « !gcc » suivi d'un appui sur Enter, pour rappeler la dernière commande commençant par « gcc ». Libre à toi d'encore raccourcir, si « !g » suffit. Avec zsh, tu peux même utiliser « !gcc [tab] » pour avoir accès la la ligne complète et la modifier avant de l'exécuter.
- Écrire un petit script (build.sh ?) qui s'occupe de tout.
- Écrire un Makefile pour chaque projet, solution la plus standard.
[^] # Re: Quel Blood ?
Posté par Amand Tihon (site web personnel) . En réponse au journal les animés utilisent linux. Évalué à 4.
Pas de réel lien d'histoire entre les deux jusqu'à présent, mais je ne désespère pas que ça change.
[^] # Re: Ajout du Python ?
Posté par Amand Tihon (site web personnel) . En réponse au journal Article sur la programmation C++. Évalué à 2.
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 :)
[^] # Re: Cher Père Noël...
Posté par Amand Tihon (site web personnel) . En réponse à la dépêche X11R7.0 sous le sapin de Noël. Évalué à 4.
Toolkits qui ne tirent pas profit du backing-store.
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.
Ben non, c'est le toolkit qui s'en charge.
[^] # Re: Cher Père Noël...
Posté par Amand Tihon (site web personnel) . En réponse à la dépêche X11R7.0 sous le sapin de Noël. Évalué à 4.
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.
[^] # Re: Cairo and co...
Posté par Amand Tihon (site web personnel) . En réponse à la dépêche X11R7.0 sous le sapin de Noël. Évalué à 6.
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...
[^] # Re: Cher Père Noël...
Posté par Amand Tihon (site web personnel) . En réponse à la dépêche X11R7.0 sous le sapin de Noël. Évalué à 6.
Mais il faut toujours relancer X, tout ce que tu éviteras, ce sera la copie du xorg.conf.
[^] # Re: Cher Père Noël...
Posté par Amand Tihon (site web personnel) . En réponse à la dépêche X11R7.0 sous le sapin de Noël. Évalué à 10.
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 ?
[^] # Re: Killer feature
Posté par Amand Tihon (site web personnel) . En réponse à la dépêche X11R7.0 sous le sapin de Noël. Évalué à 4.
Tu trouveras une manière de faire sur http://floam.sh.nu/index.xhtml?page=guides§ion=mx100(...) par exemple.
Ma configuration est très légèrement différente :
Il ne reste plus qu'à spécifier le nom du périphérique dans ton xorg.conf.
[^] # Re: Cher Père Noël...
Posté par Amand Tihon (site web personnel) . En réponse à la dépêche X11R7.0 sous le sapin de Noël. Évalué à 3.
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.
# WordPress
Posté par Amand Tihon (site web personnel) . En réponse au journal ATTENTION à vos serveurs web, des worms(vers) circule !. Évalué à 5.
[^] # Re: On parle bien du même KDE ?
Posté par Amand Tihon (site web personnel) . En réponse au journal J'ai quitté Gnome pour KDE. Évalué à 5.
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.)
[^] # Re: KDE ou GNOME pour débutant ?
Posté par Amand Tihon (site web personnel) . En réponse au journal J'ai quitté Gnome pour KDE. Évalué à 5.
Quand j'ai installé Linux sur le PC de mon père qui était sous Win98, je lui ai mis un bureau KDE. Mplayer, Kmail, bidule, machine, tout configuré. Il se débrouillait sous Windows, comme n'importe quelle personne un tout petit peu curieuse se débrouille.
Mais je ne lui ai rien expliqué ! Je lui ai demandé (s'il était d'accord) de tout découvrir par lui-même. Qu'il fouille le menu, qu'il trouve tout seul quelle est l'icône sur laquelle cliquer pour ses mails, comment surfer, etc.
Le lendemain soir, il m'a dit qu'il avait trouvé ses repères. Il m'a demandé comment passer mplayer en plein écran, et m'a appris qu'on pouvait faire un drag/drop depuis une entrée du menu K vers kicker... Je n'y avais jamais pensé, et lui a trouvé ça tout à fait naturel.
Il y a des choses "complexes" sous linux (ah... Debian), comme configurer le réseau, qu'il ne sait pas faire. Mais qu'il ne savait pas faire sous Windows non plus.
L'un dans l'autre, tout ce qu'il avait pris l'habitude d'utiliser sous Windows, il l'a retrouvé dans son KDE. Et sans explications de ma part.
[^] # Re: tout à fait hors sujet...
Posté par Amand Tihon (site web personnel) . En réponse au journal Firefox 1.5, le boulet!. Évalué à 4.
# Ma vie à moi
Posté par Amand Tihon (site web personnel) . En réponse au journal apt-build : gadget ou pas ? votre avis à vous ?!. Évalué à 5.
Dans ces cas-là, je suis plutôt adepte de dpkg-buildpackage, précédé d'un "dch -v blabla". Comme version, je donne habituellement un truc très légèrement plus grand que la version debian actuelle, pour qu'il ne soit automatiquement installé que si quelque chose de neuf arrive officiellement.
Un bon choix dans la version (un meilleur choix que "blabla" en tout cas) permet de prévoir de manière assez fine le comportement du paquet maison.
- Je veux, lorsque la version 2.0 arrive, mais pas avant, que le paquet officiel remplace le mien : je mets 1.9.9-0.alrj.1
- Ça concerne un bug que j'ai reporté, et l'auteur m'a affirmé que ce serait résolu dans le prochain upload : j'ajoute juste .alrj.1 à la version officielle (1.2.3-4 -> 1.2.3-4.alrj.1)
De manière générale, toutes les versions de mes paquets contiennent "alrj' dans la partie concernant la révision, ça permet de voir rapidement si c'est un paquet maison ou non.
Mais je ne m'amuse pas à compiler tous mes paquets pour les optimiser : en x86_64, il n'y a pas un lourd passé avec lequel il faut rester compatible :)
[^] # Re: -
Posté par Amand Tihon (site web personnel) . En réponse au journal mv redhat debian. Évalué à 6.
Je regrette, c'est un abus de langage.
Nous devons balancer les [inutile] :)
[^] # Re: Ruby ?
Posté par Amand Tihon (site web personnel) . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 2.
Je crois que si tout KDE (Qt compris ?) était codé en python, personne ne l'utiliserait :)
Des nouveaux modules python, codés au départ en python, sont ensuite recodés en C pour une question de performances.
[^] # Re: Ruby ?
Posté par Amand Tihon (site web personnel) . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 4.
Je ne pense pas.
Autant j'aime beaucoup python (à défaut de connaître Ruby) et trouve PyQt très agréable, autant je suis heureux que KDE ne soit pas interprété :)
[^] # Re: free ?
Posté par Amand Tihon (site web personnel) . En réponse au journal STOP aux quotas en Belgique. Évalué à 3.
Pour 65¤, mêmes caractéristiques sauf le quota qui passe à 30Go. Je ne crois pas qu'ils vendent à perte...
C'est le prix de la mise en place d'un réseau parallèle qui pose problème.
[^] # Re: free ?
Posté par Amand Tihon (site web personnel) . En réponse au journal STOP aux quotas en Belgique. Évalué à 5.
Le dégroupage en Belgique existe bel et bien (appelé BRUO). Belgacom place la paire DSL à ceux qui le demandent, libre à eux après d'installer des DSLAM et des fibres pour que tout ça fonctionne. Et c'est là le problème : aucun FAI n'est capable d'investir la somme nécessaire pour offrir un dégroupage plus ou moins généralisé. Ça vient, mais tout doucement, voyez Scarlet One.
Donc pour le moment, ce qu'on voit partout, ce sont des abonnements appelés BROBA : le FAI loue l'infrastructure à Belgacom et a le choix entre plusieurs profils de vitesse.
Comme les possibilités en BRUO et BROBA sont à peu de choses près identiques, les providers proposent du BROBA, qui leur revient infiniment moins cher.
Mais le dégroupage existe depuis au moins aussi longtemps qu'en France, il me semble.
[^] # Re: meuh
Posté par Amand Tihon (site web personnel) . En réponse au message console virtuelle en plein écran. Évalué à 3.
video=vesa:1280x1024-16@60
[^] # Re: Heu
Posté par Amand Tihon (site web personnel) . En réponse au journal Novell reconsidère sa décision. Évalué à 2.
Mais l'article dont tu donnes le lien parle de « supporter KDE dans OpenSuSE », leur décision du jour est peut d'être de le supporter (dans le sens de fournir du support) aussi pour les versions Enterprise ?
Si je n'ai rien compris à l'histoire, merci de m'éclairer :)
[^] # Re: qemu-ifup, tunctl
Posté par Amand Tihon (site web personnel) . En réponse au message impossible d'utiliser /dev/net/tun0. Évalué à 4.
# qemu-ifup, tunctl
Posté par Amand Tihon (site web personnel) . En réponse au message impossible d'utiliser /dev/net/tun0. Évalué à 3.
allergy@hali:~$ cat /etc/qemu-ifup
#!/bin/sh
echo "Setting $1 user..."
sudo -p "Password for $0:" /usr/sbin/tunctl -u 'allergy' -t $1
echo "Activating link for $1..."
sudo -p "Password for $0:" /bin/ip link set $1 up
echo "Adding IP address on $1..."
sudo -p "Password for $0:" /bin/ip addr add 172.16.0.10/24 dev $1
echo "Done."
Dans l'ordre:
- création du tun0 (passé en argument) avec tunctl
- activation de l'interface
- ajout de l'ip
Je n'ai jamais vraiment utilisé ifconfig, lui ayant toujours préféré iproute.
À mon avis, ton problème vient soit de la création de l'interface, qui se fait avec tunctl, soit de l'utilisation de ifconfig.
# plein de solutions
Posté par Amand Tihon (site web personnel) . En réponse au message routine xterm. Évalué à 2.
- taper « !gcc » suivi d'un appui sur Enter, pour rappeler la dernière commande commençant par « gcc ». Libre à toi d'encore raccourcir, si « !g » suffit. Avec zsh, tu peux même utiliser « !gcc [tab] » pour avoir accès la la ligne complète et la modifier avant de l'exécuter.
- Écrire un petit script (build.sh ?) qui s'occupe de tout.
- Écrire un Makefile pour chaque projet, solution la plus standard.
[^] # Re: J'applaudis !
Posté par Amand Tihon (site web personnel) . En réponse au journal Du problème des gros projets. Évalué à 3.
Mais je trouve pour le moins surprenant de se plaindre du manque de diversité d'une distribution Linux !