tgl a écrit 1743 commentaires

> Cairo a un rendu très joli, mais va à peu près aussi vite qu'une
> tortue unijambiste dans la mélasse.

Comparé à quoi, dans quel contexte ? Bref, qu'est ce qui te fait dire ça ?

Je suis curieux, parceque bon, du Cairo y'en a qui s'est immicé un peu partout sur mon desktop depuis gtk+-2.8, sans que j'ai pour autant l'impression d'une quelconque régression.

Et puis aussi, j'avais il y a qlqs temps comparé au niveau de Poppler (le moteur de rendu PDF utilisé par Evince et d'autres) le backend Cairo et le backend Splash (celui hérité de XPDF), et j'avais trouvé que Cairo s'en sortait plutôt mieux (les pages un peu compliquées apparaissaient, à vue de nez, plus rapidement).

Bon, y'a rien de bien scientifique là dedans, mais comme ça là j'ai pas vraiment l'impression que Cairo soit la grosse bouse que tu décris. Ou bien est-ce que c'est ma machine (Pentium M 1,5MHz avec une Radeon r200) qui est trop rapide pour que je m'en rende compte ?

Je suis pas sûr de mon coup, mais moi il me semblait que si tes modules Alsa étaient explicitement configurés, alors la numérotation des cartes suivait. Je pense en particulier à cette option :
options snd-intel8x0 index=0
(ou assimilé... ici ça dit que la carte gérée par le drivers intel8x0 est la n°0, donc celle qui deviendra "dsp")


Mais enfin bref, si tu t'en sors pas sur la config Alsa, tu dois effectivement pouvoir corriger le tir côté Udev.
Déjà, il faut que tu collectes quelques infos sur les cartes :
% udevinfo -a -p $(udevinfo -q path -n /dev/dsp)
% udevinfo -a -p $(udevinfo -q path -n /dev/dsp1)
Ça devrait te donner des idées de critères qui les différencient, comme par exemple le nom du DRIVER.

Ensuite, il faut que tu te fasses des règles qui forcent la numérotation de ton choix. Genre dans un fichier /etc/udev/rules.d/10-alsa.rules (le "10" est important, ça doit être un nombre plus petit que l'indice associé au règles standards) :
KERNEL="dsp*", DRIVER="Driver carte #0", NAME="sound/dsp", SYMLINK+="dsp", GROUP="audio"
KERNEL="dsp*", DRIVER="Driver carte #1", NAME="sound/dsp1", SYMLINK+="dsp1", GROUP="audio"

Et puis après tu peux tester ces règles avant de rebooter :
% udevtest /class/sound/dsp/
% udevtest /class/sound/dsp1/
Évidemment, le résultat est intéressant surtout si tu as inversé la numérotation par rapport à ce qui c'était fait automatiquement quand tu as booté...


Bon mais enfin quoi qu'il en soit, je te conseille vraiment de d'abord chercher si tu peux pas régler ça côté Alsa, ça sera plus simple. Parceque là avec Udev, même si tu as changé la numérotation des /dev/dsp*, il reste tous les autres devices aussi, et de faire l'ensemble ça devient franchement crado je trouve. Pour info, voilà l'intégralité de mon /etc/modules.d/alsa, avec deux cartes (bon ok, pas tout à fait vu que la 2ème c'est un modem, mais enfin ça devrais quand même te donner des idées) :

# ALSA portion
alias char-major-116 snd
# OSS/Free portion
alias char-major-14 soundcore

## ALSA portion
alias snd-card-0 snd-intel8x0
alias snd-card-1 snd-intel8x0m
## OSS/Free portion
alias sound-slot-0 snd-card-0
alias sound-slot-1 snd-card-1
## Fix card number whatever the modules loading order is
options snd-intel8x0 index=0
options snd-intel8x0m index=1

# OSS/Free portion - card #1
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
## OSS/Free portion - card #2
## alias sound-service-1-0 snd-mixer-oss
## alias sound-service-1-3 snd-pcm-oss
## alias sound-service-1-12 snd-pcm-oss

alias /dev/mixer snd-mixer-oss
alias /dev/dsp snd-pcm-oss
alias /dev/midi snd-seq-oss

# Set this to the correct number of cards.
options snd cards_limit=2

...c'est GTK+. Et puis il est très bien ce dialogue, une fois qu'on a fait l'effort de s'y habituer.

M'enfin quoi qu'il en soit, si vraiment il ne te plait pas, tu peux essayer ça :
http://forums.mozillazine.org/viewtopic.php?p=1783468#178346(...)
(J'ai testé et ça marche. Passe bien par la phase "désactiver une extension quelconque avant de redémarrer" par contre, moi j'avais zappé à la première lecture...)

Donc si tu ne recompile pas pour de multiple essais un logiciel, tu peut tres bien supprimer les sources puisque de toute maniere à la maj tu telechargeras les nouvelle et les precedentes ne te serviront plus.

Tu oublies les révisions de paquets (le X dans "paquet-1.2.3-rX")...

Une rapide inspections de la liste des ebuilds actuellement dans l'arbre Portage montre que le numéro de révision moyen est de 0,39 (en comptant 0 quand il n'y en a pas, et en virant les rares cas pathologiques où ce numéro n'est pas un vrai compteur mais par exemple une date). Ça veut dire qu'il y a 39% de chances qu'un paquet donné se retrouve plus tard "bumpé", genre pour corriger un bug, etc. Évidemment, dans la quasi totalité des cas, ce bump utilisera la même archive de sources que la révision précédente. Ça veut aussi dire que, si tu fais tes mises à jours régulièrement (et passe donc par toutes les révisions), quand tu effaces l'archive des sources d'un programme installé, tu as 39% de chances d'avoir à la re-télécharger plus tard.

Bon, on peut contester l'exactitude de ces stats (par exemple, on ne passera pas par les révisions qui continuent d'apparaitre sur une version 1.2.3 quand on est de toute façon déjà en train d'utiliser la 1.3.4, ce genre de choses...), mais ça donne quand même un ordre de grandeur. À tout effacer n'importe comment, et si on se tient à jour, on augmente, inutilement, d'environ un tiers notre consommation de la bande passante des miroirs. Ça n'est pas acceptable.

Heureusement, il y a pour nous aider à rester respectueux des miroirs, sans pour autant laisser notre répertoire "distfiles" gonfler indéfiniment, des outils dédiés au nettoyage parcimonieux de ces sources téléchargées. Je te laisse par exemple regarder celui ci, qui est maintenant dans gentoolkit :
http://forums.gentoo.org/viewtopic-t-381258.html

> Source?

Nan mais il ne parle pas de la fçon dont le projet KDE va faire ses release pour la 4.x, mais de la façon dont il est packagé sous Gentoo. Pour l'instant, on est en transition, et coexistent des paquets monolythiques et des paquets splités. Et à partir de la 4.0, il n'y aura plus que des paquets splités.
http://www.gentoo.org/doc/en/kde-split-ebuilds.xml

> Je connaissais pas ce dispatch-conf, je vais aller voir ca de ce pas.

J'ai tenté il y a qlqs temps sur f.g.o une explication du fonctionnement de dispatch-conf :
http://forums.gentoo.org/viewtopic-p-2696449.html#2696449
Ça peut éventuellement t'aider à comprendre en quoi il diffère de etc-update, et pourquoi il est à mon avis largement mieux...

D'après cette page [1], la TOB date de 1975, donc y'en a encore pour un sacré bout de temps avant qu'elle tombe dans le domaine publique. En fait, des 5 comparées là, il n'y a que la TSC qui est suffisament ancienne. Et encore, lui parle d'une édition de 1978, donc pas libre, mais c'est justement une révision de celle de 1910 dispo dans Sword. (Je conseille cet article aux curieux d'ailleurs... Enfin perso, bien qu'athé et peu au fait des questions bibliques, j'ai trouvé ça intéressant comme lecture.)

[1] http://hem.passagen.se/pasteur/lumieredumonde.htm

L'universalité selon Debian, c'est une volonté de combler toutes les attentes de chacun, et pas seulement les attentes communes à tous. Ça n'est effectivement pas la même notion d'universalité que celle revendiquée par les encyclopédistes, qui visaient eux plutôt à laisser une ½uvre qui serait acceptable par tous dans sa globalité. Peut-être que dans le cas Debian, c'est plutôt d'exhaustivité qu'il faudrait parler, mais bon ça sonne moins bien...

Quoi qu'il en soit, la mise à disposition de ces textes et logiciels fait manifestement partie des attentes de certains (une minorité selon http://popcon.debian.org, mais pas un groupe complètement marginal non plus), et dans la mesure où elle est possible dans le respect du contrat social et des critères de licence, et dans celle où il y a des volontaires pour s'en charger, il n'y a aucune raison que Debian s'en prive.

Est-elle religieusement prosélite pour autant ? Non, pas plus qu'elle est pro-Sun en distribuant OOo et en compilant sa distrib' pour Sparc, ou pro-quoi-que-ce-soit en général. Il ne faut pas prêter à Debian toutes les intentions des auteurs des oeuvres (logiciels, textes, etc.) dont elle se fait le relais (avoue que ça ferait d'elle un cas de schizophrènie plutôt inquiétant si c'était le cas...). Debian offre juste un large panel de possibilités, parmi lesquelles chacun est libre de faire ses choix.

Mais pourquoi donc leur soft ne sert qu'à la bible...
Effectivement la traduction n'est pas directe, mais je pense que c'est de l'évangélisation qu'il s'agit

Bien sûr qu'il s'agit d'évangélisation, et que c'est avec en tête la Bible, et d'autres textes chrétiens, que les softs du projet Sword ont été écrits. Ceci dit, Sword les a fait libres, ouvrant ainsi à tous la possibilité de les utiliser à d'autres fins. À partir de là, ce sont, objectivement, juste des logiciels libres comme les autres.

on ne peut pas porter la laïcité jusqu'à demander la séparation de DLFP et de l'église

Je crois surtout qu'il ne faut pas confondre laïcité et négation de la religion. La religion existe, c'est comme ça, et tu vois, on en parle même à l'école publique, ou bien au café du coin, ou sur DLFP, sans que ça en fasse pour autant des succursales du Vatican, ni que les principes de la laïcité en soient aucunement ébranlés.

que Debian distribue quelque chose qui se réclame de "furthering the Kingdom of our God" ça me fait bizarre et pour tout dire je suis carément contre

Perso je ne vois aucune contradiction avec les principes de Debian :
http://www.us.debian.org/social_contract
Debian ne fait pas de discrimination entre les logiciels d'après les intentions de leurs auteurs, et ça me parait très bien. C'est le genre de choses qui doivent être laissées à l'utilisateur, en son âme et conscience. Par exemple, moi quand j'en ai la possibilité j'ai tendance à privilégier les softs communautaires face à ceux simplement libérés par une grosse boîte qui veux rogner un peu les marges de son concurrent. Bon, ça vaut ce que ça vaut, mais quoi qu'il en soit c'est mon choix personnel et je n'attends pas de ma distrib' qu'elle l'impose à tous.

Comme quoi, avec Debian, on est quand même loin de Diderot et de l'Encyclopédie.

...et de beaucoup d'autres choses n'ayant rien à voir non plus.

Argh, il commence à sentir le renfermé ce bug :/

Sinon pour Automarks, le principal problème que je rencontre (répertoires) a déjà été signalé à l'auteur en fait (discussions sur la page addons.mozilla.org et ailleurs). Mais bon, même sans ce soucis là, ça vaudrait pas une vrai implémentation direct dans Autocomplete : ce que fait l'extension, c'est juste copier toutes les URLs bookmarkées dans l'historique, c'est quand même crado. Et puis il faut le déclencher manuellement en clickant une ch'tite entrée dans un menu, et puis ça disparait rapidement si tu gardes ton historique que qlqs jours, et ça reste pas en synchro avec les bookmarks ajoutés par la suite, etc., donc c'est vraiment bof bof en fait.

Enfin bon, tant pis, c'est pas aujourd'hui que je vais me mettre à la programmation XPcom, donc je vais prendre mon mal en patience...

Ok, je vois ce que tu voulais dire maintenant.

« visiblement, ce n'en est pas une. Le post ci-dessus prouve cela »
En fait même pas, le post si dessus ne prouve pas grand chose puisqu'il liste juste les dépendances que cet utilisateurs n'avait pas d'installées (c'est une sortie de "emerge -p klive").

Mais ça ne comprends pas :
- d'éventuelles autres dépendances qu'il aurait eu de déjà installées ;
- des choses éventuellement nécéssaires aussi mais qui sous Gentoo ne sont jamais explicitées dans les dépendances parcequ'elles sont obligatoirement installées sur tous les systèmes (le genre glibc, etc.).

Le plus simple pour avoir les dépendances du paquet Gentoo, c'est encore de regarder l'ebuild, et il ne liste que Python et Twisted (les autres trucs cités au dessus étant des dépendances indirectes venant de Twisted).

Mais pour en revenir à "cron", je confirme qu'il n'y en a nul besoin (j'ai même lu les sources pour vérifier cette fois). Le paquet installe les fichiers suivants :
/usr/share/doc/klive-0.16/README.gz
/usr/share/klive/klive.tac
/etc/init.d/klive
...où le script d'init lance twisted sur le klive.tac et puis voilà, après ça tourne. Bref, faut pas hésiter à se faire une installation manuelle, ou un paquet, c'est vraiment trivial.

Il ne parle pas d'une dépendance du paquet mais plutôt d'un logiciel requis pour que l'application fonctionne. »

Elle me parait bien subtile ta distinction : pour moi, si c'est requis pour un bon fonctionnement, ça devrait être une dépendance du paquet, non ?

Enfin quoi qu'il en soit, KLive marche très bien chez moi depuis des mois alors que je n'utilise que fcron. Les gens qui voudraient voir comment il est installé et lancé sous Gentoo pour faire pareil avec leur mimines, ou pour faire un paquet pour leur distrib', peuvent jeter un oeil à l'ebuild et à l'init script qui sont ici :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/app-mis(...)
http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/app-mis(...)

Celle là je l'utilise déjà en fait (et je la recommande aussi, enfin perso j'aime bien son comportement). Mais malheureusement, c'est toujours uniquement une complétion d'après l'historique, et pas d'après les URLs bookmarkés, bref c'est pas encore mon Graal.

Merci quand même ;-)

Deux solutions :

- utiliser un noyau -ck ou dérivé (-archck, certains noyaux de distribs, etc.), qui propose une politique de scheduling CPU dite "ISO", proche du temps réel ("RR") sans pour autant être aussi dangereuse (realtime sur une certaine part du temps CPU, et normal au delà), et qui est donc accessible par les simples utilisateurs. En fait, quand un programme essaye de passer en "RR" mais n'a pas les privilèges pour, il tombe en "ISO", donc c'est vraiment bien pratique (ou sinon, on peut forcer cette politique pour un processus avec 'schedtools' ou 'toolsched').
http://members.optusnet.com.au/ckolivas/kernel/

- profiter de ce que dans les noyaux >=2.6.12, l'accès au temps réel à été ajouté aux "rlimits". C'est configurable, par exemple, avec un petit programme qu'on trouve sur cette hideuse page web tout droit débarquée du milieu des années 90 :
http://www.physics.adelaide.edu.au/~jwoithe/

Des fois que tu lirais encore les réponse à ce journal, je suis tombé récemment sur qlqs bloggueries de devs Gentoo qui jouent avec Xgl, dont celle là qui peut être intéressante aussi pour d'autres distribs :
http://www.hboeck.de/item/266

Bon ceci dit, ça reste vraiment expérimental :

Problems so far:
* Crashes all the time.
* Keyboard sometimes doesn't work, not deterministic.
* Most effects (e. g. cube, expose, zoom) not running yet.

Enfin, il ya pas mal de parametres et/ou d'extensions qui font des trucs sympa avec la barre d'url [...] j'ai la flemme pour les liens la :)

Un truc que j'ai souvent cherché, mais sans succès, c'est à activer la complétion sur les URLs bookmarkées (en plus de celles de l'historique donc). Galeon se comportait ainsi, et ça me manque... sniff ;(

En fait j'ai juste trouvé une extension, "AutoMarks", qui ne fonctionne pour que si les bookmarks ne sont pas rangés dans des dossiers, donc vraiment pas terrible.

Donc voilà, si tu connais une astuce dans ce genre, et que t'as une minute non flemmarde pour m'en faire profiter, je t'en serai infiniment reconnaissant et tout et tout.

J'ai régulièrement des segfaults après des décès quand je joue avec des petites équipes. Je crois que ça viens de là (parceque "vers.size()", il vaut toujours 6, d'où possibilité de sélectionner des vers qui n'existent pas) :

--- team/team.cpp.orig
+++ team/team.cpp
@@ -301,9 +301,9 @@
 void Team::SelectCharacterIndex (uint index)
 {
   // Ver mort ?
-  assert (index < vers.size());
+  assert (index < game_mode.max_characters);
   if (vers.at(index).IsDead()) {
-    int i = (++index)%vers.size();
+    int i = (++index)%game_mode.max_characters;
     SelectCharacterIndex(i);
     return;
   }

Mais j'ai à peine testé ceci dit, donc à prendre avec des pincettes... Et puis y'a d'autres bizarreries toujours autour de la "sélection du prochain vers à jouer", genre souvent un vers joue plusieurs fois avant que le tour n'arrive à un de ses coéquipiers (peut-être Team::NextCharacterIndex() ou Team::internal_NextCharacter(), dont je comprends pas trop pourquoi elles n'incrémentent qu'en cas de vers mort). Mais j'ai pas beaucoup cherché, c'est juste une vague piste...

Toutes ces histoires d'écologie, d'économie solidaire et de paysans de l'Himalaya, bah moi ça me donne bien envie de m'acheter un lave-linge...

> Mais comment fait il pour être si actif ?! :-)

Il ne passe pas par la case LinuxFR.

mmmh, nan, ça suffit pas à tout expliquer... il doit avoir des nègres...

> En même temps, je préfèrerai prendre un T60

Le p'tit nouveau d'IBM avec un Cell dedans ? C'est vrai qu'il a l'air sympa, mais il est gros quand même, enfin, heureusement qu'il a des roulettes quoi... :)
http://www.linuxdevices.com/files/misc/Mercury_Cell_Eval_Sys(...)

À tiens, un autre truc qui devrait t'être bien plus utile que les ebuild Gentoo en fait, c'est JhBuild :
http://wiki.x.org/wiki/JhBuildInstructions
Ça permet d'automatiser le build des modules, en prenant en compte les dépendances définies par les devs de Xorg :
http://cvs.freedesktop.org/xorg/util/modular/xorg.modules?re(...)
Tu choisis les modules cibles qui t'intérressent, et le reste devrait suivre tout seul. Ça risque de ne pas t'occuper toute tes vacances du coup :)

> la portion suffisante de X qui m'est utile (le serveur, le pilote pour
> ma carte, le serveur de fontes, et c'est tout)

Tu es sûr que c'est tout ? Pour info, sous Gentoo le méta-paquet de base comprend ça :

# Server
RDEPEND="${RDEPEND}
>=x11-base/xorg-server-1.0.0"

# Common Applications
RDEPEND="${RDEPEND}
>=x11-apps/mesa-progs-6.4.1
>=x11-apps/setxkbmap-1
>=x11-apps/xauth-1
>=x11-apps/xhost-1
>=x11-apps/xinit-1
>=x11-apps/xmodmap-1
>=x11-apps/xrandr-1"

# Common Libraries - move these to eclass eventually
RDEPEND="${RDEPEND}
>=x11-libs/libSM-1
>=x11-libs/libXcomposite-0.2.2.2
>=x11-libs/libXcursor-1.1.5.2
>=x11-libs/libXdamage-1.0.2.2
>=x11-libs/libXfixes-3.0.1.2
>=x11-libs/libXv-1
>=x11-libs/libXxf86dga-1
>=x11-libs/libXinerama-1
>=x11-libs/libXScrnSaver-1
xprint? ( >=x11-libs/libXp-1 )"

# Some fonts
RDEPEND="${RDEPEND}
>=media-fonts/font-bh-ttf-1
>=media-fonts/font-adobe-utopia-type1-1
>=media-fonts/font-bitstream-type1-1"

Et là dedans, les libs et les autres utilitaires ont bien sûr leurs propres dépendances aussi (autres libs, modules du serveur, headers, etc.). Et il faut ajouter, en plus des drivers de la carte auquel tu as déjà pensé, des drivers d'input (au moins xf86-input-keyboard et xf86-input-mouse). Bon y'a aussi des trucs dont tu peux probablement te passer (mesa-progs, xrandr, etc.), mais ça laisse quand même, mis bout-à-bout, quelques dizaines de paquets nécéssaires pour obtenir un X11 qui se lance et permet effectivement de faire tourner tes applis.

Si tu veux jeter un oeil aux dépendances des paquets Gentoo, tu peux parcourir le CVS :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/
Par exemple pour le xorg-server :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/x11-base/xorg-serv(...)

Quant à Gentoo, ça en est là :

Une collection de ~290 ebuilds (càd un par archive upstream), qui offre une alternative au monolythique xorg-x11-6.x (le 6.9 étant quand même packagé lui aussi). Sur cet ensemble, perso j'en ai 98 d'installés (ceux listés par un meta-paquet censé offrir un X11 de base, plus les drivers pour ma machine, et qlqs petits utilitaires que j'ai ajouté au fur et à mesure quand j'en ai eu besoin).

Ces paquets sont encore masqués, mais les tests publiques avec les RC ont commencé il y a qlqs mois, et aujourd'hui ça marche globalement très bien. C'est plus au niveau des dépendances des autres ebuilds utilisant X11 qu'il y a encore des choses à corriger/affiner.

Globalement, ça fait un bon gain de temps de compil' et d'espace occupé, donc je trouve ça vraiment bienvenu (sans compter que les futures mises à jours et corrections de bugs n'imposeront pas une recompilation de l'ensemble de la bestiole, ce qui sera très appréciable).

Par exemple :

% cat devnull
#!/bin/sh
echo "on me voit"
# sauvegarde de stdout et redirection vers /dev/null
exec 3>&1 1>/dev/null
echo "on ne me voit plus"
# restauration de stdout et ménage de la sauvegarde
exec 1>&3 3>&-
echo "on me voit à nouveau"

% ./devnull
on me voit
on me voit à nouveau

Évidemment, c'est le même principe si tu veux aussi supprimer la sortie d'erreur, c'est à dire :

...
# sauvegarde de stdout et stderr, et redirection vers /dev/null
exec 3>&1 4>&2 &>/dev/null
...
# restauration de stdout et stderr, et ménage des sauvegardes
exec 1>&3 2>&4 3>&- 4>&-
...

...sont deux mots clefs qui devraient te mettre sur la voie. Je m'avancerai pas trop parceque, faute de SMP ici, j'y connais pas grand chose, m'enfin bon ça te donne toujours qqch à googler. Tu peux jeter un oeil sur /usr/src/linux/Documentation/cpusets.txt aussi.

Ah ouais, et puis enfin, tu dois pouvoir te servir de l'utilitaire "schedtool" pour changer le "masque d'affinité" de tes processus, et puis pourquoi aussi pas de "schedtoold" pour automatiser un peu tout ça (jamais testé pour cet usage ceci dit) :
http://freequaos.host.sk/schedtool/
http://www.darav.de/schedtoold.html