D'après l'auteur de cette page, les "frame buffers" sont actuellement incompatibles avec le suspend-to-ram. C'est justement mon cas : j'ai essayé avec radeonfb (étant donné que j'ai une radeon mobility) et vesafb, sans réussir.
Ici sur un disque de portable à 5400 t/min (je crois), je viens de mesurer que ~480Mo étaient restaurés en ~22 secondes. Un peu plus rapide que toi donc. Est-ce que tu utilises bien la compression LZF ?
J'utilise bien la compression, par contre je souffre d'un disque qui tourne en 4200 tr/min... Mais, vu le confort apporté par la restauration (conservation du cache), je m'en contente largement !
Et puis sinon, j'utilise aussi le "suspend to RAM" quand c'est pour hiberner juste qlqs heures, genre une nuit ou le temps d'un trajet maison<-->taf. Là c'est vraiment une question de 2 ou 3 secondes pour suspendre ou réveiller, c'est franchement agréable.
Par contre, je n'ai pas encore réussi à utiliser le "suspend to ram". Peut-être que je n'ai simplement pas assez persévéré. Tu utilises aussi le script hibernate pour ça ?
De mon côté, je l'utilise depuis plusieurs mois avec succès, et maintenant je trouve ça indispensable. Effectivement, un patch du noyau, une ligne de conf pour le bootloader, et en plus le script "hibernate" de http://www.suspend2.net(...) suffisent.
Concernant les drivers, ce n'est plus si terrible que ça a été : il y a un an encore, impossible de suspendre avec un seveur X lancé. Dorénavant, je n'ai rien de particulier à faire.
Les modules usb représentent apparemment le plus gros problème actuel pour la suspension, à cause des débranchements éventuels quand la machine est éteinte. Le script en question les décharge à la suspension et les recharge au réallumage. Je n'ai pas de soucis avec les autres pilotes sur mon portable (touchpad, carte graphique, carte son, etc , dans un compaq presario p4m). J'ajouterai que l'implémentation de http://www.suspend2.net(...) ne dépend pas de l'acpi (pas plus que celle de windows je crois). Ce n'est donc pas un souci, d'autant plus que les dernières versions des noyaux fournissent un support assez satisfaisant de l'acpi.
Ensuite, en ce qui concerne la vitesse, je trouve le gain considérable. C'est vrai que linux a tendance à utliser la ram à fond dès qu'on utilise la machine depuis un bon moment. Chez moi, c'est une image de 500 mo (pour 768mo de ram) en moyenne qui est écrite à la suspension puis lue au démarrage (contrairement à windows qui occupe plutôt de l'ordre de 200 mo, fuites exceptées). Sachant que le disque de mon portable fait du 20 mo/sec, ça fait une trentaine de secondes pour la suspension et autant pour la reprise. Même si on est loin des 5 secondes, c'est toujours beaucoup plus rapide qu'un démarrage à froid, qui se compte en minutes,en comptant le démarrage ultérieur des applications...
En fait, c'est particulièrement confortable à l'usage. On profite en effet de toutes les mises en cache précédentes et les applications réagissent ou se lancent de manière très réactive.
Pour finir, je ne saurais que conseiller aux motivés de se lancer, c'est vraiment pratique.
Pour avoir validé quelques pages en html 4.01, j'ai rencontré pas mal d'erreurs comme ça. Souvent c'était parce que j'avais imbriqué des balises de structure (<p>, <ul>, <div>...) à l'intérieur de balises de style (<font>...), alors que c'est interdit par les spécifications.
en résumé :
<font...><ul>...</ul></font> est invalide et te donne l'erreur citée
Si tu es dans ce cas, c'était sans doute pour appliquer un style à plusieurs éléments en même temps. La solution, c'est les css !
Si arts n'est pas dans la liste des moteurs, c'est peut-être parce que ta distribution a prévu une package à part.
A moins que tu ais compilé amarok par le cvs et que le script de configuration n'ait pas trouvé arts pour une raison qui m'échappe...
"artsdsink" correspond à l'utilisation de la sortie arts pour la moteur gstreamer.
Tu devrais aussi avoir le "moteur" arts, utilisable à la place de gstreamer. Ca semble l'option la plus cohérente avec kde, mais comme on peut s'en convaincre sur le site d'Amarok [1] et plus précisément sur la page consacrée aux moteurs [2], le moteur artsd n'est pas maintenu régulièrement. C'est peut-être aussi le cas du plugin artsdsink pour gstreamer, ce qui expliquerait tes problèmes.
En fait, soit tu utilises le moteur artsd directement, soit tu utilises le plugin alsasink pour gstreamer en corrigeant le problème dont tu parles (/dev/dsp occupé).
Pour cela, tu peux t'en sortir en suivant les instructions données dans le wiki d'Amarok [3]. En gros, arts monopolise ta carte son. Il faut utiliser un mixeur appelé "dmix", qui se chargera d'accepter à la fois les requêtes de son d'arts et d'amarok via alsasink.
C'est effectivement le cas (le uPnP permet à msn de demander lui-même quels ports le routeur doit forwarder, ces ports étant choisis aléatoirement dans une certaine plage il me semble), mais malheureusement on n'a pas toujours un tel routeur, ou il se peut qu'on ait pas accès à la machine qui sert de routeur/firewall ...
C'est entre autres pour ça que je faisais allusion au ports utilisés. Par exemple, je voulais ces derniers temps faire de la visioconférence avec mes parents, et il se trouve que le routeur/firewall du réseau sur lequel je suis branché ne laisse pas passer (ou ne "forwarde" pas) les ports utilisés pour la visio par msn. Donc ça ne marche simplement pas.
Par contre la fonction webcam seule marche (et pour le son j'utilise skype qui passe aussi).
Autre particularité : la webcam peut être diffusée à plus d'une personne en même temps. Je ne m'en sers pas personnellement, mais il y a sans doute des situations où ça doit présenter un intérêt.
Pour vous mettre d'accord, il faut distinguer deux fonctions de msn :
- la visioconférence, c'est-à-dire la vidéo et le son (envoyés sur des ports TCP/UDP spécifiques). Celle-ci marche en effet très bien dans les deux sens avec la dernière version beta.
- la fonction webcam (bel et bien une fonction à part dans msn; l'image est envoyé par des ports traditionnels, avec un protocole différent de celui de la visioconférence ) : dans les dernières betas, la réception fonctionne, mais pas l'envoi.
L'arrivée de cette version 7 sous Linux ne m'émoit pas plus que cela, étant donnée la très grande qualité de kpdf en particulier dans sa dernière mouture. On y trouve des fonctions de recherche, le copier/coller dans le texte, l'affichage des pages en continu (la fin de la page courante et le début de la suivante), un affichage progressif des polices (un peu comme un image jpeg qui devient nette progressivement au chargement, ce qui permet un défilement très rapide dans les longs documents pdf), et une barre à gauche pour afficher les aperçus des pages ou la table des matières.
Par contre, je suis étonné qu'apparaisse cette version 7 sous Linux tandis qu'elle n'est pas disponible sur les windows 95/98/Me... Pourtant, il est clair que la version 6 est un monstre de lourdeur pour les machines souvent un peu anciennes qui tournent avec ces os.
A mon avis, cela peut signifier deux choses : soit Linux a vraiment une importance suffisante pour faire bouger un éditeur comme Adobe, soit le développement de cette version n'a en fait que peu de choses à voir avec la version 7 sous windows, à part l'apparence. Elle ne serait alors que le résultat d'un travail entamé depuis la version 5, soit il y a un petit moment déjà !
Un swap est nécessaire pour utiliser les fonctions d'hibernation comme "software suspend 2" [1]. Dans ce cas, quand tu appelles l'hibernation, le noyau copie les données contenues dans la mémoire vive sur le swap, et éteint l'ordinateur. Quand tu le rallumes, il se trouve exactement dans l'état où tu l'as laissé, d'où un gain de temps : il n'y a pas à recharger le gestionnaire de fenêtres ou un autre programme déjà utilisé auparavant.
Par contre, tu peux créer un swap sans pour autant avoir une partition dédiée. A la place, un simple fichier sur une partition traditionnelle (montée sur / par exemple) fait l'affaire. Ca s'appelle un "swapfile". On peut même combiner une partition de swap et un "swapfile", si la première s'avère trop petite. Voir le lien [2].
[1] http://www.suspend2.net/(...)
P.S. : Après avoir jeté un coup d'oeil sur ce site, je me rends compte qu'une nouvelle version (encore en test, sortie hier) permet de s'affranchir du swap...
> Je suis même tombé sur des PDF sur Latex (officiel donc généré par pdflatex) qui ne passait pas bien avec xpdf !! Un comble...
A la base (je veux dire avec une distribution latex traditionnelle), Latex ne produit pas du pdf, mais du dvi, qui est ensuite traduit en ps pour être imprimé (c'est le but premier de Latex), puis éventuellement en pdf. Et effectivement, sans une ligne ou deux d'options pour les polices, le pdf que tu obtiendras avec cette démarche est parfois "sale" sur xpdf et consorts [1], alors que ça passe avec Acrobat Reader. Je m'y suis confronté.
Après, je ne sais pas exactement de quels documents tu parles, ni comment tu les as obtenus, mais en tout cas je ne vois pas pourquoi ce serait forcément un "comble". Si tu pouvais préciser...
J'utilise la distribution SourceMage (distrib source), avec simpleinit-msb et udev.
Je ne suis pas spécialiste dans le domaine, mais j'ai pris quelques minutes pour regarder comment c'est organisé :
- Je n'ai jamais compilé le support du devfs dans le noyau.
- J'ai un runlevel nommé "%DEV" qui est lancé en tout premier par simpleinit-msb, contenant un unique script qui s'occupe de udev :
Il monte /sys, /proc, puis un ramfs dans /dev. Voilà la fonction appelée dans ce fichier (udev_root est sur /dev/ dans udev.conf):
start_udev()
{ (
. /etc/udev/udev.conf
# mount sysfs
echo "Mounting sysfs at /sys"
mount -n -t sysfs none /sys
# mount proc
echo "Mounting /proc"
mount -n -t proc none /proc
echo "Mounting ramfs at $udev_root"
mount -n -t ramfs none $udev_root
# create some needed stuff
ln -s /proc/self/fd $udev_root/fd
ln -s /dev/fd/0 $udev_root/stdin
ln -s /dev/fd/1 $udev_root/stdout
ln -s /dev/fd/2 $udev_root/stderr
mkdir $udev_root/shm
mkdir $udev_root/pts
# propogate /udev from /sys - we only need this while we do not
# have initramfs and an early user-space with which to do early
# device bring up
echo "Creating initial udev device nodes"
/sbin/udevstart
if [ -f /etc/udev/udev.missing ]; then
echo "Processing /etc/udev/udev.missing"
cd /dev
while read line; do
if [ "${line:0:1}" == "#" ]; then continue; fi
for ((i=0; i<7; i++)); do
val[$i]=${line%%:*}
line=${line#*:}
done
if [ "${val[1]}" == "d" ]; then
mkdir ${val[0]}
else
mknod ${val[0]} ${val[1]} ${val[2]} ${val[3]}
fi
chmod ${val[4]} ${val[0]}
chown ${val[5]}:${val[6]} ${val[0]}
done < /etc/udev/udev.missing
cd /
fi
echo "Telling init to reopen file descriptors"
kill -USR1 1
echo "Starting udevd"
/sbin/udevd &
) }
L'init se poursuit ensuite avec les autres runlevels.
J'espère t'avoir été utile. N'hésite pas à demander des précisions.
Avec l'ACPI, l'action des boutons "Power", "Mise en veille" et même du petit bouton qui détecte la fermeture de l'écran sont paramétrables.
Tout se passe dans le dossier /etc/acpi/events. Tu peux par exemple y créer le fichier 'power' qui contiendra :
event=button[ /]power
action=sudo halt
Ainsi, quand le bouton power est pressé, le programme 'halt' est appelé, et ta machine s'éteint. On peut faire des choses semblables avec la fermeture de l'écran. Dans ton cas, puisque tu dis que ton PC se met en veille quand tu fermes l'écran, c'est qu'il y a peut-être un fichier du même type qui appelle la mise en veille. Tu ferais donc bien de vérifier.
Dans tous les cas, tout cela est géré par 'acpid' (qui dois donc être installé), et tu en sauras donc plus en tapant 'man acpid'.
Ah j'ai enfin résolu le problème. Je poste donc au cas où quelqu'un ait le même...
Il m'a fallu activer l'option "halo par sous-pixellisation" dans les options de lissage des polices de KDE (Centre de configuration > Apparence et Thèmes > Polices > Configurer > Activer le halo par sous-pixellisation).
Maintenant, OpenOffice s'affiche parfaitement quelle que soit la police choisie pour l'interface.
Au passage, l'affichage des polices sur l'écran de mon portable a gagné (très légèrement) en lisibilité.
Effectivement, ça résout le problème. Par contre on peut laisser la ligne :
\usepackage[T1]{fontenc}
Il suffit de rajouter celle que tu suggères en plus.
Suite à ta suggestion, j'ai fureté sur les sites qui parlait de pslatex, et j'ai trouvé une autre solution, qui a l'avantage de garder les polices d'origine de Latex (que je trouve assez agréables quand elles sont bien affichées). Il faut utiliser :
\usepackage[T1]{fontenc}
\usepackage{ae,aecompl,aeguill}
La deuxième ligne adapte la police "European Modern Computer" au standard T1, aeguill rajoute en particulier les guillemets.
\title{Dispersion et filage des nanotubes de carbone}
\author{\textsc{Philippe Poulin} , Centre de Recherches \textsc{Paul Pascal} (CRPP)}
\date{Séminaire du MIP : 30 novembre 2004}
Justement la copie d'écran est réalisée avec cette option activée !
Par contre, ta suggestion m'a refait tester les options, et je viens de trouver une solution :
J'ai désactivé l'option "polices du système pour l'interface utilisateur" (menu options/OOo/Accessibilité), puis j'ai utilisé la table de remplacement (menu options/OOo/Polices) pour remplacer la police "Andale Sans UI" utilisée par défaut d'après la FAQ par "Verdana" : et là, ça marche !
Par contre, ça ne fonctionne pas avec "Bitstream Vera Sans" (qui est ma police système) ou encore "Times New Roman". Il me semble que c'est un problème de taillle de polices. En effet, si je diminue l'échelle dans "menu options/OOo/Affichage", les bugs réapparaissent...
En tout cas, merci de m'avoir aidé à refaire des essais !
Le lien que tu fournis est très instructif ! [1] J'ai apprécié d'y apprendre une des raisons pour lesquelles Internet Explorer n'est plus vraiment maintenu/développé. Je vous laisse la découvrir... Toute la stratégie de Microsoft s'éclaire !
Je me suis posé une question similaire à un moment, à ceci près que pour moi le but était l'accès depuis 2 PC différents...
La solution que j'ai trouvée est d'utiliser le protocole imap plutôt que pop3. Beaucoup de fournisseurs d'adresse mail porposent les deux. En pop3, ton lecteur de mail télécharge chaque message et le détruit du serveur (sauf options particulières). En Imap, le serveur joue un plus grand rôle : le logiciel ne télécharge que les en-têtes, puis les messages quand tu les ouvres seulement, et sans les effacer du serveur. En gros, tes deux logiciels de mail partageront la même base de données, puique c'est sur le serveur de mail qu'elle se trouve !
Néanmoins, avec une connexion bas débit, c'est peut-être pas la solution idéale. Sinon, je pense qu'elle mérite d'être essayée.
[^] # Re: oui et non
Posté par tipote . En réponse au message suspend to disk. Évalué à 1.
D'après l'auteur de cette page, les "frame buffers" sont actuellement incompatibles avec le suspend-to-ram. C'est justement mon cas : j'ai essayé avec radeonfb (étant donné que j'ai une radeon mobility) et vesafb, sans réussir.
[^] # Re: oui et non
Posté par tipote . En réponse au message suspend to disk. Évalué à 1.
Par contre, je n'ai pas encore réussi à utiliser le "suspend to ram". Peut-être que je n'ai simplement pas assez persévéré. Tu utilises aussi le script hibernate pour ça ?
[^] # Re: oui et non
Posté par tipote . En réponse au message suspend to disk. Évalué à 3.
De mon côté, je l'utilise depuis plusieurs mois avec succès, et maintenant je trouve ça indispensable. Effectivement, un patch du noyau, une ligne de conf pour le bootloader, et en plus le script "hibernate" de http://www.suspend2.net(...) suffisent.
Concernant les drivers, ce n'est plus si terrible que ça a été : il y a un an encore, impossible de suspendre avec un seveur X lancé. Dorénavant, je n'ai rien de particulier à faire.
Les modules usb représentent apparemment le plus gros problème actuel pour la suspension, à cause des débranchements éventuels quand la machine est éteinte. Le script en question les décharge à la suspension et les recharge au réallumage. Je n'ai pas de soucis avec les autres pilotes sur mon portable (touchpad, carte graphique, carte son, etc , dans un compaq presario p4m). J'ajouterai que l'implémentation de http://www.suspend2.net(...) ne dépend pas de l'acpi (pas plus que celle de windows je crois). Ce n'est donc pas un souci, d'autant plus que les dernières versions des noyaux fournissent un support assez satisfaisant de l'acpi.
Ensuite, en ce qui concerne la vitesse, je trouve le gain considérable. C'est vrai que linux a tendance à utliser la ram à fond dès qu'on utilise la machine depuis un bon moment. Chez moi, c'est une image de 500 mo (pour 768mo de ram) en moyenne qui est écrite à la suspension puis lue au démarrage (contrairement à windows qui occupe plutôt de l'ordre de 200 mo, fuites exceptées). Sachant que le disque de mon portable fait du 20 mo/sec, ça fait une trentaine de secondes pour la suspension et autant pour la reprise. Même si on est loin des 5 secondes, c'est toujours beaucoup plus rapide qu'un démarrage à froid, qui se compte en minutes,en comptant le démarrage ultérieur des applications...
En fait, c'est particulièrement confortable à l'usage. On profite en effet de toutes les mises en cache précédentes et les applications réagissent ou se lancent de manière très réactive.
Pour finir, je ne saurais que conseiller aux motivés de se lancer, c'est vraiment pratique.
# Mon expérience...
Posté par tipote . En réponse au message validation XHTML. Évalué à 1.
en résumé :
<font...><ul>...</ul></font> est invalide et te donne l'erreur citée
Si tu es dans ce cas, c'était sans doute pour appliquer un style à plusieurs éléments en même temps. La solution, c'est les css !
[^] # Re: Choisi carrement un autre moteur
Posté par tipote . En réponse au message Problème sur amaroK. Évalué à 1.
A moins que tu ais compilé amarok par le cvs et que le script de configuration n'ait pas trouvé arts pour une raison qui m'échappe...
[^] # Re: Choisi carrement un autre moteur
Posté par tipote . En réponse au message Problème sur amaroK. Évalué à 1.
Tu devrais aussi avoir le "moteur" arts, utilisable à la place de gstreamer. Ca semble l'option la plus cohérente avec kde, mais comme on peut s'en convaincre sur le site d'Amarok [1] et plus précisément sur la page consacrée aux moteurs [2], le moteur artsd n'est pas maintenu régulièrement. C'est peut-être aussi le cas du plugin artsdsink pour gstreamer, ce qui expliquerait tes problèmes.
En fait, soit tu utilises le moteur artsd directement, soit tu utilises le plugin alsasink pour gstreamer en corrigeant le problème dont tu parles (/dev/dsp occupé).
Pour cela, tu peux t'en sortir en suivant les instructions données dans le wiki d'Amarok [3]. En gros, arts monopolise ta carte son. Il faut utiliser un mixeur appelé "dmix", qui se chargera d'accepter à la fois les requêtes de son d'arts et d'amarok via alsasink.
Bon courage, je reste à disposition.
[1] http://amarok.kde.org/(...)
[2] http://amarok.kde.org/wiki/index.php/Audio_Engine_Comparison(...)
[3] http://amarok.kde.org/wiki/index.php/Setting_up_Dmix_for_ALSA(...)
[^] # Re: En attendant...
Posté par tipote . En réponse au journal Le support des vidéos avec le protocole MSN.. Évalué à 1.
[^] # Re: En attendant...
Posté par tipote . En réponse au journal Le support des vidéos avec le protocole MSN.. Évalué à 1.
Par contre la fonction webcam seule marche (et pour le son j'utilise skype qui passe aussi).
Autre particularité : la webcam peut être diffusée à plus d'une personne en même temps. Je ne m'en sers pas personnellement, mais il y a sans doute des situations où ça doit présenter un intérêt.
[^] # Re: En attendant...
Posté par tipote . En réponse au journal Le support des vidéos avec le protocole MSN.. Évalué à 1.
- la visioconférence, c'est-à-dire la vidéo et le son (envoyés sur des ports TCP/UDP spécifiques). Celle-ci marche en effet très bien dans les deux sens avec la dernière version beta.
- la fonction webcam (bel et bien une fonction à part dans msn; l'image est envoyé par des ports traditionnels, avec un protocole différent de celui de la visioconférence ) : dans les dernières betas, la réception fonctionne, mais pas l'envoi.
[^] # Re: Linux plus important que windows 95/98/Me ?
Posté par tipote . En réponse à la dépêche Retour d'Adobe sur les plates-formes Linux ?. Évalué à 2.
# Linux plus important que windows 95/98/Me ?
Posté par tipote . En réponse à la dépêche Retour d'Adobe sur les plates-formes Linux ?. Évalué à 5.
Par contre, je suis étonné qu'apparaisse cette version 7 sous Linux tandis qu'elle n'est pas disponible sur les windows 95/98/Me... Pourtant, il est clair que la version 6 est un monstre de lourdeur pour les machines souvent un peu anciennes qui tournent avec ces os.
A mon avis, cela peut signifier deux choses : soit Linux a vraiment une importance suffisante pour faire bouger un éditeur comme Adobe, soit le développement de cette version n'a en fait que peu de choses à voir avec la version 7 sous windows, à part l'apparence. Elle ne serait alors que le résultat d'un travail entamé depuis la version 5, soit il y a un petit moment déjà !
Qu'en pensez-vous ?
# Pour la mise en veille
Posté par tipote . En réponse au message Intérêt du Swap. Évalué à 1.
Un swap est nécessaire pour utiliser les fonctions d'hibernation comme "software suspend 2" [1]. Dans ce cas, quand tu appelles l'hibernation, le noyau copie les données contenues dans la mémoire vive sur le swap, et éteint l'ordinateur. Quand tu le rallumes, il se trouve exactement dans l'état où tu l'as laissé, d'où un gain de temps : il n'y a pas à recharger le gestionnaire de fenêtres ou un autre programme déjà utilisé auparavant.
Par contre, tu peux créer un swap sans pour autant avoir une partition dédiée. A la place, un simple fichier sur une partition traditionnelle (montée sur / par exemple) fait l'affaire. Ca s'appelle un "swapfile". On peut même combiner une partition de swap et un "swapfile", si la première s'avère trop petite. Voir le lien [2].
[1] http://www.suspend2.net/(...)
P.S. : Après avoir jeté un coup d'oeil sur ce site, je me rends compte qu'une nouvelle version (encore en test, sortie hier) permet de s'affranchir du swap...
[2] Une page donnée par google qui donne les commandes pour obtenir un "swapfile" : http://dev.panopticsearch.com/swapfile-notes.html(...)
[^] # Re: Avantages par rapport à XPDF ?
Posté par tipote . En réponse au journal Acrobat Reader 7. Évalué à 1.
- Même s'il s'agit de documents "officiels", il n'est pas obligé que pdflatex ait utilisé, mais peut-être la chaîne latex - dvips - ps2pdf
- sans les bonnes options sur les polices notamment, et même avec pdflatex, tu peux obtenir un pdf "sale".
[^] # Re: Avantages par rapport à XPDF ?
Posté par tipote . En réponse au journal Acrobat Reader 7. Évalué à 2.
A la base (je veux dire avec une distribution latex traditionnelle), Latex ne produit pas du pdf, mais du dvi, qui est ensuite traduit en ps pour être imprimé (c'est le but premier de Latex), puis éventuellement en pdf. Et effectivement, sans une ligne ou deux d'options pour les polices, le pdf que tu obtiendras avec cette démarche est parfois "sale" sur xpdf et consorts [1], alors que ça passe avec Acrobat Reader. Je m'y suis confronté.
Après, je ne sais pas exactement de quels documents tu parles, ni comment tu les as obtenus, mais en tout cas je ne vois pas pourquoi ce serait forcément un "comble". Si tu pouvais préciser...
[1] http://linuxfr.org/forums/10/6010.html(...)
[^] # Re: Mon expérience sur SourceMage
Posté par tipote . En réponse au message simpleinit-msb et udev. Évalué à 1.
Bon courage !
[^] # Re: dans le bios
Posté par tipote . En réponse au message probleme acpi. Évalué à 2.
# Mon expérience sur SourceMage
Posté par tipote . En réponse au message simpleinit-msb et udev. Évalué à 1.
Je ne suis pas spécialiste dans le domaine, mais j'ai pris quelques minutes pour regarder comment c'est organisé :
- Je n'ai jamais compilé le support du devfs dans le noyau.
- J'ai un runlevel nommé "%DEV" qui est lancé en tout premier par simpleinit-msb, contenant un unique script qui s'occupe de udev :
Il monte /sys, /proc, puis un ramfs dans /dev. Voilà la fonction appelée dans ce fichier (udev_root est sur /dev/ dans udev.conf):
start_udev()
{ (
. /etc/udev/udev.conf
# mount sysfs
echo "Mounting sysfs at /sys"
mount -n -t sysfs none /sys
# mount proc
echo "Mounting /proc"
mount -n -t proc none /proc
echo "Mounting ramfs at $udev_root"
mount -n -t ramfs none $udev_root
# create some needed stuff
ln -s /proc/self/fd $udev_root/fd
ln -s /dev/fd/0 $udev_root/stdin
ln -s /dev/fd/1 $udev_root/stdout
ln -s /dev/fd/2 $udev_root/stderr
mkdir $udev_root/shm
mkdir $udev_root/pts
# propogate /udev from /sys - we only need this while we do not
# have initramfs and an early user-space with which to do early
# device bring up
echo "Creating initial udev device nodes"
/sbin/udevstart
if [ -f /etc/udev/udev.missing ]; then
echo "Processing /etc/udev/udev.missing"
cd /dev
while read line; do
if [ "${line:0:1}" == "#" ]; then continue; fi
for ((i=0; i<7; i++)); do
val[$i]=${line%%:*}
line=${line#*:}
done
if [ "${val[1]}" == "d" ]; then
mkdir ${val[0]}
else
mknod ${val[0]} ${val[1]} ${val[2]} ${val[3]}
fi
chmod ${val[4]} ${val[0]}
chown ${val[5]}:${val[6]} ${val[0]}
done < /etc/udev/udev.missing
cd /
fi
echo "Telling init to reopen file descriptors"
kill -USR1 1
echo "Starting udevd"
/sbin/udevd &
) }
L'init se poursuit ensuite avec les autres runlevels.
J'espère t'avoir été utile. N'hésite pas à demander des précisions.
[^] # Re: dans le bios
Posté par tipote . En réponse au message probleme acpi. Évalué à 1.
Avec l'ACPI, l'action des boutons "Power", "Mise en veille" et même du petit bouton qui détecte la fermeture de l'écran sont paramétrables.
Tout se passe dans le dossier /etc/acpi/events. Tu peux par exemple y créer le fichier 'power' qui contiendra :
event=button[ /]power
action=sudo halt
Ainsi, quand le bouton power est pressé, le programme 'halt' est appelé, et ta machine s'éteint. On peut faire des choses semblables avec la fermeture de l'écran. Dans ton cas, puisque tu dis que ton PC se met en veille quand tu fermes l'écran, c'est qu'il y a peut-être un fichier du même type qui appelle la mise en veille. Tu ferais donc bien de vérifier.
Dans tous les cas, tout cela est géré par 'acpid' (qui dois donc être installé), et tu en sauras donc plus en tapant 'man acpid'.
Cordialement.
[^] # Re: une petite idée
Posté par tipote . En réponse au message Polices des menus de Openoffice mal affichées. Évalué à 2.
Il m'a fallu activer l'option "halo par sous-pixellisation" dans les options de lissage des polices de KDE (Centre de configuration > Apparence et Thèmes > Polices > Configurer > Activer le halo par sous-pixellisation).
Maintenant, OpenOffice s'affiche parfaitement quelle que soit la police choisie pour l'interface.
Au passage, l'affichage des polices sur l'écran de mon portable a gagné (très légèrement) en lisibilité.
[^] # Re: une petite idée
Posté par tipote . En réponse au message Polices des menus de Openoffice mal affichées. Évalué à 1.
[^] # Re: Source ?
Posté par tipote . En réponse au message Polices mal alignées dans xpdf. Évalué à 1.
\usepackage[T1]{fontenc}
Il suffit de rajouter celle que tu suggères en plus.
Suite à ta suggestion, j'ai fureté sur les sites qui parlait de pslatex, et j'ai trouvé une autre solution, qui a l'avantage de garder les polices d'origine de Latex (que je trouve assez agréables quand elles sont bien affichées). Il faut utiliser :
\usepackage[T1]{fontenc}
\usepackage{ae,aecompl,aeguill}
La deuxième ligne adapte la police "European Modern Computer" au standard T1, aeguill rajoute en particulier les guillemets.
Merci beaucoup !
[^] # Re: Source ?
Posté par tipote . En réponse au message Polices mal alignées dans xpdf. Évalué à 1.
\documentclass[a4paper]{article}
\usepackage[francais]{babel}
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[dvips,final]{graphicx}
\title{Dispersion et filage des nanotubes de carbone}
\author{\textsc{Philippe Poulin} , Centre de Recherches \textsc{Paul Pascal} (CRPP)}
\date{Séminaire du MIP : 30 novembre 2004}
\begin{document}
\maketitle
\section*{Introduction}
...
[^] # Re: une petite idée
Posté par tipote . En réponse au message Polices des menus de Openoffice mal affichées. Évalué à 2.
Par contre, ta suggestion m'a refait tester les options, et je viens de trouver une solution :
J'ai désactivé l'option "polices du système pour l'interface utilisateur" (menu options/OOo/Accessibilité), puis j'ai utilisé la table de remplacement (menu options/OOo/Polices) pour remplacer la police "Andale Sans UI" utilisée par défaut d'après la FAQ par "Verdana" : et là, ça marche !
Par contre, ça ne fonctionne pas avec "Bitstream Vera Sans" (qui est ma police système) ou encore "Times New Roman". Il me semble que c'est un problème de taillle de polices. En effet, si je diminue l'échelle dans "menu options/OOo/Affichage", les bugs réapparaissent...
En tout cas, merci de m'avoir aidé à refaire des essais !
[^] # Re: ceci est un titre
Posté par tipote . En réponse au message fragmentation. Évalué à 1.
[1] http://www.joelonsoftware.com/articles/APIWar.html(...)
# Imap
Posté par tipote . En réponse au message Portabilité de mail sous Linux et Win. Évalué à 2.
La solution que j'ai trouvée est d'utiliser le protocole imap plutôt que pop3. Beaucoup de fournisseurs d'adresse mail porposent les deux. En pop3, ton lecteur de mail télécharge chaque message et le détruit du serveur (sauf options particulières). En Imap, le serveur joue un plus grand rôle : le logiciel ne télécharge que les en-têtes, puis les messages quand tu les ouvres seulement, et sans les effacer du serveur. En gros, tes deux logiciels de mail partageront la même base de données, puique c'est sur le serveur de mail qu'elle se trouve !
Néanmoins, avec une connexion bas débit, c'est peut-être pas la solution idéale. Sinon, je pense qu'elle mérite d'être essayée.