Re: problème avec minidlna
On 01/29/2015 04:41 PM, Pierre Frenkiel wrote: bonjour à tous, je croyais avoir trouvé le serveur UPnP idéal, qui, contrairement à mediatomb, respecte l'arborescence des dossiers. Mais j'ai un gros problème avec l'affichage (c'est sur la freebox, mais ce serait sans doute pareil avec un autre client) Pour les fichiers(mp3 ou mp4) qui contiennent un tag décrivant le contenu multimédia, il utilise ce tag au lieu d'afficher le nom du fichier. Ainsi, au lieu du nom de fichier, j'ai pour des mp4: ¬extrait_ina pour des mp3: plage 02, ou track 02 Quand on a 20 fichiers pour lesquels l'affichage est identique, c'est assez difficile à utiliser... Ça me parait assez débile, mais je n'ai pas trouvé le moyen de corriger ça. et je n'ai trouvé dans aucun forum quelqu'un qui mentionne ce problème. Y a-t-il une solution avec minidlna, ou faut-il se tourner vers un autre serveur UPnP moins farfelu, s'il en existe (ushare par exemple ?) Salut, J'ai plutôt l'impression que le problème vient de tes tags non ? Pour les réarranger, tu peux utiliser : http://puddletag.sourceforge.net/ Cordialement, -- “One original thought is worth a thousand mindless quotings.” “Le vrai n'est pas plus sûr que le probable.” Diogene Laerce signature.asc Description: OpenPGP digital signature
Re: problème avec minidlna
On Thu, 29 Jan 2015, Diogene Laerce wrote: J'ai plutôt l'impression que le problème vient de tes tags non ? Pour les réarranger, tu peux utiliser : je ne crois pas. Ceux qui sont présents sont tout à fait classiques (pour les mp3: interprète, album title, track) Il faudrait les supprimer, ce qui me parait aberrant, car cette information peur être utile. Par exemple, elle est affichée par vlc) et de toutes façons, ce serait envisageable pour quelques fichiers, mais pas pour des dizaines, voire des centaines. Je trouve extraordinaire que l'on ne puisse pas dire au serveur: ne fouille pas dans mon fichier, contente-toi d'afficher son nom. Cordialement, -- Pierre Frenkiel
Re: problème avec minidlna
Salut, On 29/01/2015 17:33, Diogene Laerce wrote: On 01/29/2015 04:41 PM, Pierre Frenkiel wrote: bonjour à tous, je croyais avoir trouvé le serveur UPnP idéal, qui, contrairement à mediatomb, respecte l'arborescence des dossiers. Mais j'ai un gros problème avec l'affichage (c'est sur la freebox, mais ce serait sans doute pareil avec un autre client) Pour les fichiers(mp3 ou mp4) qui contiennent un tag décrivant le contenu multimédia, il utilise ce tag au lieu d'afficher le nom du fichier. Ainsi, au lieu du nom de fichier, j'ai pour des mp4: ¬extrait_ina pour des mp3: plage 02, ou track 02 Quand on a 20 fichiers pour lesquels l'affichage est identique, c'est assez difficile à utiliser... Ça me parait assez débile, mais je n'ai pas trouvé le moyen de corriger ça. et je n'ai trouvé dans aucun forum quelqu'un qui mentionne ce problème. Y a-t-il une solution avec minidlna, ou faut-il se tourner vers un autre serveur UPnP moins farfelu, s'il en existe (ushare par exemple ?) Salut, J'ai plutôt l'impression que le problème vient de tes tags non ? Pour les réarranger, tu peux utiliser : http://puddletag.sourceforge.net/ Cordialement, C'est mon avis aussi. J'utilise minidlna via ma TV, il m'affiche les noms des fichiers. Ce doit être ta freebox qui préfère afficher les tags plutôt que les noms des fichiers. Cordialement, Tristan -- Tristan Charbonneau Domisys - Materiel.net Administrateur système -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54ca63b6.9070...@domisys.com
Re: Faille critique découverte dans GLIBC
On 2015-01-28 23:16:48 +0100, Bernard Isambert wrote: Le 28/01/2015 20:59, Philippe Deleval a écrit : C'est une blague? A mon avis, tout programmeur utilisant la fonction de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n), le petit n fait la différence. Et ceux qui créé la fonction strcpy sont des criminels qui devraient être guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé l'informatique... Faut voir l'historique: strcpy date de l'origine du langage C, à un temps où on ne se préoccupait pas trop des problèmes de sécurité. Maintenant, la fonction strcpy devrait peut-être prendre le même chemin que gets. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150129103012.gb8...@xvii.vinc17.org
Re: Localhost
On 2015-01-28 17:52:37 +0100, Francois Lafont wrote: Merci pour ce lien que j'ai lu mais justement le point (enfin un des points) que tu soulèves ci-dessus n'est pas expliqué, enfin il me semble. Dans ton lien je vois ceci : So the only thing that needs to be secured for the correct resolution is that we don't mix up the localhost line with the foobar line. And the order of the line's entries is important, e.g. it must be: 127.0.0.1 foobar.bar.net foobar not 127.0.0.1 foobar foobar.bar.net » Mais l'auteur ne dit pas pourquoi « it must be ». C'est ce que dit aussi la page man hosts(5): IP_address canonical_hostname [aliases...] Ici, foobar.bar.net est le nom d'hôte canonique. Perso, je pensais qu'une ligne du type : adresse-IP était complètement équivalent à : adresse-IP Pourquoi est-ce que ce n'est pas le cas ? C'est équivalent pour la résolution directe, mais pas pour la résolution inverse. Dans la résolution inverse, la règle est de renvoyer le nom d'hôte canonique, qui est dans /etc/hosts le premier nom après l'adresse. Si je me souviens bien, le fait de mettre un shortname en premier casse la commande hostname avec certaines options (e.g. avec -f, on se retrouve avec un nom court au lieu du FQDN), mais ça peut dépendre des implémentations. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150129102524.ga8...@xvii.vinc17.org
Re: Faille critique découverte dans GLIBC
On 2015-01-28 20:59:50 +0100, Philippe Deleval wrote: C'est une blague? A mon avis, tout programmeur utilisant la fonction de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n), le petit n fait la différence. Enfin, strncpy n'est pas vraiment safe non plus. Un problème est que si le n est trop petit, le buffer n'est plus forcément terminé par un \0, ce qui peut être en soi un trou de sécurité: si on copie la chaîne contenue dans le buffer, cela peut donc copier des données au-delà du buffer, et on se retrouve donc avec des bugs du type heartbleed. La vraie solution est d'avoir une fonction qui fait un abort() quand le n est trop petit... et si le serveur est critique, on n'écrit pas en C. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150129105433.gc8...@xvii.vinc17.org
Re: Faille critique découverte dans GLIBC
Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?
J'ajouterais, dans un souci d'échange et de discussion, que le reboot ne
me semble pas si important que cela (aie, je prend un risque en disant
cela), pourquoi?
Les fichiers qui correspondent aux processus exécutés sur un système
Linux sont protégés en écriture, petit rappel:
$ cat read_bloquant.c FIN
# include stdio.h
int main (void)
{
read (0, NULL, sizeof(int));
/* En gros on exécute un appel système bloquant, on lit depuis l'entrée
standard, en général la console, NULL parce qu'on s'en fout du résultat
et le sizeof parce que ça fait plus cool qu'un 4 ou un 8 (et portable).
Donc tant qu'on n'entre pas un caractère (dac, un nombre (cela dit,
c'est du C, c'est pareil pour lui, chez moi il en mange 4 donc int = 4
octets, moins si caractère en dehors ascii et si console en UTF-8 par
ex) et qu'on n'appuie pas sur Entrée le programme attend */
exit (0);
}
FIN
Désolé si ça fait un peu cours et pour tout ceux qui savent déjà tout ça!
Donc on compile et on exécute:
$ gcc read_bloquant.c -o read_bloquant
$ ./read_bloquant
Ça y est, le processus attend.
Sur une autre console :
$ kate read_bloquant
(ou gedit, mousepad etc.)
Impossible de sauvegarder les modifs (on peut avec vim, allez savoir!).
Et possible lorsque le programme n'est pas exécuté.
Lorsque j'ai mis à jour la libc sur ma wheezy je n'ai pas eu de souci
particulier, virtualbox (qui n'était pas en exécution) s'est recompilé
son module, 2-3 petits trucs et c'était bon.
Ce que j'en conclus, c'est que sur mon système la mise à jour n'a
remplacé aucun fichier en cours d'utilisation donc que le reboot n'est
peut-être pas indispensable.
Toutefois, juste pour être sûr et si j'étais admin je viderais tout ce
qui est buffer/cache avant la mise à jour et également après tant qu'à
faire:
# echo 3 /proc/sys/vm/drop_caches
Et si ça swappe (c'est pas dit avec tout ces ordi à 8+ Gb de ram), je
tuerais quelque processus après avoir exécuté:
# echo 0 /proc/sys/vm/swappiness
Attention tout de même à ne pas exécuter cela sur un pc avec très peu de
mémoire mais de toute façon je suis même pas sûr que cette dernière
ligne aurait de l'effet dans ce cas.
Une dernière chose:
Un programme peut être lié à une ABI de la libc de façon statique ou
dynamique.
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre
autres grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6
qui est appelé chez moi), aucun problème tant que le programme utilise
un cache bien mis à jour (ce qui est normalement le cas mais c'est t'on
jamais d'où les 2 dernières commandes).
Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai
pas vérifié), alors là un reboot n'y fera rien, il faudra recompiler le
paquet, c'est d'ailleurs un des principaux désavantage des librairies
statiques (avec la quantité d'espace mémoire utilisée, l'avantage étant
un programme très légèrement plus rapide).
Voilà pour mes petites réflexion, s'il y a des erreurs de logique merci
de me corriger.
Cordialement/Bises...
--
mrr
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ca32ea$0$3190$426a7...@news.free.fr
Re: Localhost
On Thursday 29 January 2015 11:25:24 Vincent Lefevre wrote: Ici, foobar.bar.net est le nom d'hôte canonique. Le nom canonique (CNAME) CaNonical Name, et le FQDN sont-ils les mêmes ? Domaine = fruit.com Cname = www.fruit.com Alias de www.fruit.com = p. ex. apple Le nom canonique correspond à un alias. FQDN = marcel.fruit.com nom_hôte.nom_domaine FQDN messagerie = user@nom_hôte.nom_domaine C'est équivalent pour la résolution directe, mais pas pour la résolution inverse. Dans la résolution inverse, la règle est de renvoyer le nom d'hôte canonique, qui est dans /etc/hosts le premier nom après l'adresse. Si je me souviens bien, le fait de mettre un shortname en premier casse la commande hostname avec certaines options (e.g. avec -f, on se retrouve avec un nom court au lieu du FQDN), mais ça peut dépendre des implémentations. La résolution inverse : elle semble être sur l'IP. # host 192.168.0.5 5.0.168.192.in-addr.arpa domain name pointer ns1.fruit.com. Si c'est le cas, les noms littéraires après l'IP sont commutatifs. http://www.commentcamarche.net/contents/518-dns-systeme-de-noms-de-domaine http://www.networking4all.com/fr/support/noms+de+domaine/dns/archives+cname/ http://wiki.goldzoneweb.info/resolution_inverse -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201501291301.11487.andre_deb...@numericable.fr
Re: Faille critique découverte dans GLIBC
mrr wrote on Thu, Jan 29, 2015 at 02:17:32PM +0100
Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?
J'ajouterais, dans un souci d'échange et de discussion, que le
reboot ne me semble pas si important que cela (aie, je prend un
risque en disant cela), pourquoi?
Il faut juste penser à prévenir les utilisateurs suffisamment à
l'avance pour éviter de leur casser la baraque.
Dominique
Les fichiers qui correspondent aux processus exécutés sur un système
Linux sont protégés en écriture, petit rappel:
$ cat read_bloquant.c FIN
# include stdio.h
int main (void)
{
read (0, NULL, sizeof(int));
/* En gros on exécute un appel système bloquant, on lit depuis
l'entrée standard, en général la console, NULL parce qu'on s'en fout
du résultat et le sizeof parce que ça fait plus cool qu'un 4 ou un 8
(et portable). Donc tant qu'on n'entre pas un caractère (dac, un
nombre (cela dit, c'est du C, c'est pareil pour lui, chez moi il
en mange 4 donc int = 4 octets, moins si caractère en dehors ascii
et si console en UTF-8 par ex) et qu'on n'appuie pas sur Entrée le
programme attend */
exit (0);
}
FIN
Désolé si ça fait un peu cours et pour tout ceux qui savent déjà tout ça!
Donc on compile et on exécute:
$ gcc read_bloquant.c -o read_bloquant
$ ./read_bloquant
Ça y est, le processus attend.
Sur une autre console :
$ kate read_bloquant
(ou gedit, mousepad etc.)
Impossible de sauvegarder les modifs (on peut avec vim, allez savoir!).
Et possible lorsque le programme n'est pas exécuté.
Lorsque j'ai mis à jour la libc sur ma wheezy je n'ai pas eu de
souci particulier, virtualbox (qui n'était pas en exécution) s'est
recompilé son module, 2-3 petits trucs et c'était bon.
Ce que j'en conclus, c'est que sur mon système la mise à jour n'a
remplacé aucun fichier en cours d'utilisation donc que le reboot
n'est peut-être pas indispensable.
Toutefois, juste pour être sûr et si j'étais admin je viderais tout
ce qui est buffer/cache avant la mise à jour et également après tant
qu'à faire:
# echo 3 /proc/sys/vm/drop_caches
Et si ça swappe (c'est pas dit avec tout ces ordi à 8+ Gb de ram),
je tuerais quelque processus après avoir exécuté:
# echo 0 /proc/sys/vm/swappiness
Attention tout de même à ne pas exécuter cela sur un pc avec très
peu de mémoire mais de toute façon je suis même pas sûr que cette
dernière ligne aurait de l'effet dans ce cas.
Une dernière chose:
Un programme peut être lié à une ABI de la libc de façon statique ou
dynamique.
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir
entre autres grâce à strace que c'est
/lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est appelé chez moi),
aucun problème tant que le programme utilise un cache bien mis à
jour (ce qui est normalement le cas mais c'est t'on jamais d'où les
2 dernières commandes).
Si c'est statique (avec la libc ce doit être rare voire inexistant,
j'ai pas vérifié), alors là un reboot n'y fera rien, il faudra
recompiler le paquet, c'est d'ailleurs un des principaux désavantage
des librairies statiques (avec la quantité d'espace mémoire
utilisée, l'avantage étant un programme très légèrement plus
rapide).
Voilà pour mes petites réflexion, s'il y a des erreurs de logique
merci de me corriger.
Cordialement/Bises...
--
mrr
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ca32ea$0$3190$426a7...@news.free.fr
--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129134917.gb11...@telecom-paristech.fr
Re: Faille critique découverte dans GLIBC
Bonjour, J'ai bien aimé le passage en C, ça m'a rappelé de (trop) vieux souvenirs ;-) Le jeudi 29 janvier 2015 à 14:17, mrr a écrit : Un programme peut être lié à une ABI de la libc de façon statique ou dynamique. Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est appelé chez moi), aucun problème tant que le programme utilise un cache bien mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2 dernières commandes). Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me corriger) que la bibliothèque dynamique est chargée au démarrage du programme. Chacun des appels système sera donc fait selon la version installée à ce moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme ne profitera donc pas des corrections. Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet, c'est d'ailleurs un des principaux désavantage des librairies statiques (avec la quantité d'espace mémoire utilisée, l'avantage étant un programme très légèrement plus rapide). Oui, pour les liens statiques, aucun impact sans passer par une recompilation. C'est donc hors-champ. Un autre avantage des liens statiques, c'est le coté transportable du binaire, tu peux le lancer sur une machine qui ne dispose pas de toutes les bibliothèques nécessaires (puisque le programme « embarque » tous les bouts de bibliothèques dont il a besoin). Seb -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150129140619.gb13...@sebian.nob900.homeip.net
Re: Localhost
On 2015-01-29 13:01:11 +0100, andre_deb...@numericable.fr wrote: On Thursday 29 January 2015 11:25:24 Vincent Lefevre wrote: Ici, foobar.bar.net est le nom d'hôte canonique. Le nom canonique (CNAME) CaNonical Name, et le FQDN sont-ils les mêmes ? La question n'a pas de sens: un CNAME est associé à une adresse IP, alors que le FQDN est global à la machine. Or une machine a typiquement plusieurs adresses IP. Mais techniquement, le FQDN (de la machine) doit être un CNAME puisqu'il est obtenu en prenant le nodename de la machine, puis à partir de ce nodename, en prenant le premier nom de gethostbyname() ou le ai_canonname de getaddrinfo(). Domaine = fruit.com Cname = www.fruit.com Alias de www.fruit.com = p. ex. apple Le nom canonique correspond à un alias. FQDN = marcel.fruit.com nom_hôte.nom_domaine FQDN messagerie = user@nom_hôte.nom_domaine Le FQDN de la messagerie peut être encore autre chose: toutes les machines ne sont pas censées recevoir du mail de l'extérieur. C'est équivalent pour la résolution directe, mais pas pour la résolution inverse. Dans la résolution inverse, la règle est de renvoyer le nom d'hôte canonique, qui est dans /etc/hosts le premier nom après l'adresse. Si je me souviens bien, le fait de mettre un shortname en premier casse la commande hostname avec certaines options (e.g. avec -f, on se retrouve avec un nom court au lieu du FQDN), mais ça peut dépendre des implémentations. La résolution inverse : elle semble être sur l'IP. # host 192.168.0.5 5.0.168.192.in-addr.arpa domain name pointer ns1.fruit.com. Si c'est le cas, les noms littéraires après l'IP sont commutatifs. Attention, la commande host n'utilise pas /etc/hosts! Elle fait une résolution *DNS* inverse. En fait, par résolution inverse, j'entendais plutôt la fonction getaddrinfo (anciennement gethostbyname et gethostbyaddr), qui fait à la fois une résolution directe et une résolution inverse (peut-être un terme improprement choisi, mais ce que je veux dire c'est que cette fonction ne se contente pas de retourner seulement l'adresse IP, mais aussi d'autres infos comme le nom canonique). -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150129140345.ga20...@xvii.vinc17.org
Re: Faille critique découverte dans GLIBC
On Thursday 29 January 2015 14:17:32 mrr wrote: Ah, au fait, petite question. Après les commandes ci-dessus, faut-il que je fasse un reboot ? J'ajouterais, dans un souci d'échange et de discussion, que le reboot ne me semble pas si important que cela (aie, je prend un risque en disant cela), pourquoi? Les fichiers qui correspondent aux processus exécutés sur un système Linux sont protégés en écriture, petit rappel: [cut] Sous Wheezy, j'avais bien updaté glibc6, recompilé ghosttest.c et avais : Vulnerable J'ai fait un reboot = Not vulnerable. André -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201501291521.26865.andre_deb...@numericable.fr
problème avec minidlna
bonjour à tous, je croyais avoir trouvé le serveur UPnP idéal, qui, contrairement à mediatomb, respecte l'arborescence des dossiers. Mais j'ai un gros problème avec l'affichage (c'est sur la freebox, mais ce serait sans doute pareil avec un autre client) Pour les fichiers(mp3 ou mp4) qui contiennent un tag décrivant le contenu multimédia, il utilise ce tag au lieu d'afficher le nom du fichier. Ainsi, au lieu du nom de fichier, j'ai pour des mp4: ¬extrait_ina pour des mp3: plage 02, ou track 02 Quand on a 20 fichiers pour lesquels l'affichage est identique, c'est assez difficile à utiliser... Ça me parait assez débile, mais je n'ai pas trouvé le moyen de corriger ça. et je n'ai trouvé dans aucun forum quelqu'un qui mentionne ce problème. Y a-t-il une solution avec minidlna, ou faut-il se tourner vers un autre serveur UPnP moins farfelu, s'il en existe (ushare par exemple ?) Cordialement, -- Pierre Frenkiel
Re: problème avec minidlna
On Thu, 29 Jan 2015, Bernard Schoenacker wrote: voici un premier pas : http://homeserver-diy.net/wiki/index.php?title=Installer_et_configurer_MiniDLNA_sous_Debian_Squeeze merci de l'info.. mais il n'y a rien qui concerne le problème que j'ai exposé, pas plus que sur tous les autres sites décrivant l'installation de minidlna que j'ai consultés. Cordialement, -- Pierre Frenkiel
Re: problème avec minidlna
On 01/29/2015 05:55 PM, Pierre Frenkiel wrote: On Thu, 29 Jan 2015, Diogene Laerce wrote: J'ai plutôt l'impression que le problème vient de tes tags non ? Pour les réarranger, tu peux utiliser : je ne crois pas. Ceux qui sont présents sont tout à fait classiques (pour les mp3: interprète, album title, track) Il faudrait les supprimer, ce qui me parait aberrant, car cette information peur être utile. Par exemple, elle est affichée par vlc) et de toutes façons, ce serait envisageable pour quelques fichiers, mais pas pour des dizaines, voire des centaines. Justement si : tu peux grâce ce logiciel, sélectionner autant de fichiers que tu veux, vu qu'il traverse les répertoires, et lui demander de transférer le nom de fichier en nom de chanson par exemple, ou autre. Tu devrais y jeter un oeil, ça vaut vraiment le coup. ;) -- “One original thought is worth a thousand mindless quotings.” “Le vrai n'est pas plus sûr que le probable.” Diogene Laerce signature.asc Description: OpenPGP digital signature
Re: Faille critique découverte dans GLIBC
Le 28/01/2015 23:16, Bernard Isambert a écrit : Le 28/01/2015 20:59, Philippe Deleval a écrit : Bonjour à tous C'est une blague? A mon avis, tout programmeur utilisant la fonction de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n), le petit n fait la différence. Cordialement Philippe Deleval Et ceux qui créé la fonction strcpy sont des criminels qui devraient être guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé l'informatique... Ceux qui ont créé strcpy n'étaient sans doute pas conscients que le système qu'ils écrivaient et le langage qu'ils concevaient auraient une telle fortune, avaient-ils prévu Internet? Après tout, ma source sur C est signée Kernighan-Ritchie. C'est l'expérience qui a dégagé ce qui était plus ou moins bon. strcpy peut encore être utilisé sans danger par un programmeur qui sait ce qu'il fait et maîtrise la longiueur des chaînes qu'il manipule, je pnese que c'était la vocation première. Mais lire par strcpy une chaîne qui vient d'ailleurs, c'est un risque notoire! Cordialement Philippe Deleval (et non zorro, je ne sais pas monter à cheval!) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54ca9395.2070...@wanadoo.fr
Re: Faille critique découverte dans GLIBC
Salut Seb, Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est appelé chez moi), aucun problème tant que le programme utilise un cache bien mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2 dernières commandes). Oups, ça c'est de l'erreur de syntaxe (de logique aussi si on veut): s/c'est/sait Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me corriger) que la bibliothèque dynamique est chargée au démarrage du programme. Chacun des appels système sera donc fait selon la version installée à ce moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme ne profitera donc pas des corrections. Je vois, au 1er appel la librairie serait mappée en mémoire puis en quelque sorte détachée de sa source, à savoir le fichier sur le disque. Tu dois avoir raison, cela aurait également le mérite d'expliquer ma 1ère remarque, l'accès en écriture sur un fichier en cours d'exécution (bon, processus, dac mais on se comprend). Et ça expliquerait aussi le résultat d'André (message suivant). Par contre, ce qui me gène un peu c'est que cela signifierait que chaque processus en cours d'exécution aurait sa propre copie en mémoire. Ou il y a une autre possibilité de comprendre ta phrase qui me convient mieux, c'est qu'à chaque fois qu'une bibliothèque partagée est appelée pour la *1ère* fois, elle serait mappée dans l'espace virtuel pour tout le monde jusqu'à ce qu'il n'y ait plus aucun processus qui l'utilise et alors elle serait déchargée. De toute façon je vais essayer genre pour le fun = - créer un .so qui affiche Version initiale. - lancer un programme qui appelle .so puis qui se bloque. - modifier le .so pour qu'il affiche Version modifiée. - reprendre l'exécution. Et tant qu'à faire, lancer le programme 2 fois, avant et après modif. Si je fais ça rapidement je vous poste le résultat. Au passage, si quelqu'un pouvait m'expliquer le comportement de vim (en une phrase, je sais que c'est pas le sujet initial)? Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet, c'est d'ailleurs un des principaux désavantage des librairies statiques (avec la quantité d'espace mémoire utilisée, l'avantage étant un programme très légèrement plus rapide). Oui, pour les liens statiques, aucun impact sans passer par une recompilation. C'est donc hors-champ. Un autre avantage des liens statiques, c'est le coté transportable du binaire, tu peux le lancer sur une machine qui ne dispose pas de toutes les bibliothèques nécessaires (puisque le programme « embarque » tous les bouts de bibliothèques dont il a besoin). Exact, bien vu! Je crois au passage que c'est bien plus utilisé sur Windows, ça règle les problèmes de versions et on sait vraiment avec quoi on travaille. Linux est plus ambitieux mais parallèlement (et on en parlait récemment sur un autre thread) cela augmente la complexité du système de dépendances. Seb @ Sébastien (message précédent, je vais pas alourdir le fil de 3 messages juste pour ça): je crois avoir bien précisé que je n'étais pas sûr de moi et à aucun moment j'ai déconseillé le reboot (qui est manifestement utile d'après les réponses des uns et des autres). Update: - En réfléchissant aux autres librairies que fournit la glibc j'ai oublié de penser que c'est elle même qui fournit le chargeur de lien dynamique (via /lib/i386-linux-gnu/ld-2.13.so sur mon système) qui est lui même un objet partagé. Bon, même combat, il faut bien d'une façon ou d'une autre que le nouveau entre en action. Et d'une façon ou d'une autre c'est l'ancien qui charge le nouveau afin que ce dernier l'écrase. Ouais, du coup, _reboot_ ça me parle plus là. - De la page man de ld.so et à la section BOGUES: Actuellement, ld.so ne peut pas enlever un lien existant pour chercher des bibliothèques compatibles ou plus récentes. Ça revient à ce que tu disais Seb. Allez, bonne nuit tout le monde. -- mrr -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54ca99a9$0$3295$426a7...@news.free.fr
Re: Faille critique découverte dans GLIBC
On 29/01/2015 21:10, Philippe Deleval wrote: Le 28/01/2015 23:16, Bernard Isambert a écrit : Le 28/01/2015 20:59, Philippe Deleval a écrit : Bonjour à tous C'est une blague? A mon avis, tout programmeur utilisant la fonction de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n), le petit n fait la différence. Cordialement Philippe Deleval Et ceux qui créé la fonction strcpy sont des criminels qui devraient être guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé l'informatique... Ceux qui ont créé strcpy n'étaient sans doute pas conscients que le système qu'ils écrivaient et le langage qu'ils concevaient auraient une telle fortune, avaient-ils prévu Internet? Après tout, ma source sur C est signée Kernighan-Ritchie. C'est l'expérience qui a dégagé ce qui était plus ou moins bon. strcpy peut encore être utilisé sans danger par un programmeur qui sait ce qu'il fait et maîtrise la longiueur des chaînes qu'il manipule, je pnese que c'était la vocation première. Mais lire par strcpy une chaîne qui vient d'ailleurs, c'est un risque notoire! Un des trucs qui me plaît dans linux (ok, la libc c'est pas que linux, je sais) donc ce qui me plait c'est la liberté qu'on te donne, y compris la liberté de faire une bêtise. Essayez (ou pas en fait) le fameux rm -rf / et vous aurez droit à un gentil message qui vous préviendra que c'est dangereux. Je suis nostalgique, avant on pouvait détruire son système en paix :) Cordialement Philippe Deleval (et non zorro, je ne sais pas monter à cheval!) -- -- mrr -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54caa1da$0$3066$426a7...@news.free.fr
Re: Faille critique découverte dans GLIBC
mrr a écrit : Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me corriger) que la bibliothèque dynamique est chargée au démarrage du programme. Chacun des appels système sera donc fait selon la version installée à ce moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme ne profitera donc pas des corrections. Et c'est bien pour cela qu'il faut redémarrer les processus utilisant un exécutable (bibliothèque ou autre) mis à jour. Je vois, au 1er appel la librairie serait mappée en mémoire puis en Oui. quelque sorte détachée de sa source, à savoir le fichier sur le disque. Non, elle reste liée au fichier. C'est le principe du mapping. Même chose pour l'exécutable d'un programme qui tourne. Par contre, ce qui me gène un peu c'est que cela signifierait que chaque processus en cours d'exécution aurait sa propre copie en mémoire. Non, pas forcément, tant que la copie n'est pas modifiée. Ensuite seules les pages éventuellement modifiées par un processus font l'objet d'une copie séparée dans la mémoire virtuelle de ce processus. Ou il y a une autre possibilité de comprendre ta phrase qui me convient mieux, c'est qu'à chaque fois qu'une bibliothèque partagée est appelée pour la *1ère* fois, elle serait mappée dans l'espace virtuel pour tout le monde jusqu'à ce qu'il n'y ait plus aucun processus qui l'utilise et alors elle serait déchargée. Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers l'inode correspondant, au même titre que les liens durs dans les répertoires. La mise à jour fait pointer le nom du fichier vers un nouvel inode qui contient la nouvelle version du fichier, mais l'inode originel reste présent tant qu'il reste des liens, donc tant qu'il n'est pas fermé par les processus qui l'ont ouvert. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54caa225.5040...@plouf.fr.eu.org
Re: Faille critique découverte dans GLIBC
trolldi (en avance) Le 29/01/2015 21:09, Philippe Deleval a écrit : Le 28/01/2015 20:59, Philippe Deleval a écrit : C'est une blague? A mon avis, tout programmeur utilisant la fonction de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il travaille pour faute grave! strcpy peut encore être utilisé sans danger par un programmeur qui sait ce qu'il fait et maîtrise la longiueur des chaînes qu'il manipule, Conclusion évidente : vous voulez renvoyer pour faute grave un programmeur qui sait ce qu'il fait ! Excusez-moi, je n'ai pas pu m'empêcher de faire le rapprochement entre vos deux phrases ! C'était trop tentant ! /trolldi -- Bernard. 20 ans d'utilisation de Debian. Comme le temps passe... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54caab9e.3090...@taranig.net
Re: Localhost
Le 29/01/2015 11:25, Vincent Lefevre a écrit : Perso, je pensais qu'une ligne du type : adresse-IP était complètement équivalent à : adresse-IP Pourquoi est-ce que ce n'est pas le cas ? C'est équivalent pour la résolution directe, mais pas pour la résolution inverse. Dans la résolution inverse, la règle est de renvoyer le nom d'hôte canonique, qui est dans /etc/hosts le premier nom après l'adresse. Si je me souviens bien, le fait de mettre un shortname en premier casse la commande hostname avec certaines options (e.g. avec -f, on se retrouve avec un nom court au lieu du FQDN), mais ça peut dépendre des implémentations. Ok, effectivement, si sur une Debian Wheezy je mets 127.0.0.1 toto.domain.tld toto alors la commande « hostname -f » me renvoie toto et non toto.domain.tld ce qui prouve bien que l'ordre compte un petit peu. Et je veux bien croire que, dans certaines circonstances, ça puisse être la porte ouverte à d'éventuels problèmes. Merci pour ce contre exemple. À+ -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/maedi8$j65$1...@ger.gmane.org
Re: Faille critique découverte dans GLIBC
On 2015-01-30 01:45:47 +0100, Vincent Lefevre wrote: On 2015-01-30 00:30:29 +0100, Francois Lafont wrote: Si je comprends bien d'un côté cette zone n'est plus accessible via l'arborescence du filesystem car l'ancien inode n'existe plus. Du coup, cette zone du disque serait libre en quelques sortes ? Non, l'ancien inode existe toujours (je suppose qu'un processus qui a le fichier ouvert peut toujours faire un fstat sur le descripteur de fichier pour obtenir le numéro d'inode). Exemple avec un petit script zsh: zmodload zsh/stat echo foo tmp-file stat tmp-file | grep -E '^(inode|nlink) ' exec tmp-file stat -f 0 | grep -E '^(inode|nlink) ' rm tmp-file stat -f 0 | grep -E '^(inode|nlink) ' cat J'obtiens: inode 4940899 nlink 1 inode 4940899 nlink 1 inode 4940899 nlink 0 foo -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150130005530.ga16...@xvii.vinc17.org
Re: Localhost
On 2015-01-29 23:51:57 +0100, Francois Lafont wrote: Ok, effectivement, si sur une Debian Wheezy je mets 127.0.0.1 toto.domain.tld toto alors la commande « hostname -f » me renvoie toto et non toto.domain.tld ce qui prouve bien que l'ordre L'inverse je suppose. hostname -f va normalement prendre le premier nom de la ligne qui correspond au nodename. compte un petit peu. Et je veux bien croire que, dans certaines circonstances, ça puisse être la porte ouverte à d'éventuels problèmes. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150130002424.ga14...@xvii.vinc17.org
Re: [testing] tracker-extract et conso cpu
Le mardi 27 janvier 2015 à 22:30 +0100, Gaëtan PERRIER a écrit : Depuis quelques jours je constate que tracker-extract consomme énormément de CPU voir par moment tous les CPU. Est-ce de même chez vous ? Bonjour, j'ai eu un problème similaire, mais pas sur toutes mes machines. Il y a d'autres observations similaires dans le BTS (https://bugs.debian.org/612242). Je ne sais pas si le facteur clé est la vitesse du matériel ou la configuration de la machine. Amicalement, -- Charles Plessy Tsurumi, Kanagawa, Japon -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150130023026.ge11...@falafel.plessy.net
Re: Faille critique découverte dans GLIBC
On 2015-01-30 00:30:29 +0100, Francois Lafont wrote: Le 29/01/2015 22:12, Pascal Hambourg a écrit : Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers l'inode correspondant, au même titre que les liens durs dans les répertoires. La mise à jour fait pointer le nom du fichier vers un nouvel inode Tu parles bien de la mis à jour d'une lib ? Dans ce cas, je ne comprends pas trop ce que tu veux dire par nouvel inode. Par exemple, j'ai ça : ~$ touch /tmp/foo.so ~$ touch /tmp/foo.so.new-version ~$ ls -i /tmp/foo.so* 523294 /tmp/foo.so 523295 /tmp/foo.so.new-version # Je considère la commande ci-dessous comme une màj du fichier foo.so ~$ cp /tmp/foo.so.new-version /tmp/foo.so # Et je constate que le numéro d'inode de foo.so n'a pas bougé ? ~$ ls -i /tmp/foo.so* 523294 /tmp/foo.so 523295 /tmp/foo.so.new-version Mais une mise à jour ne fait pas un cp. Un cp va modifier un fichier si la destination existe, pas créer un nouveau fichier. Du coup, j'ai pas dû comprendre quelque chose dans ta phrase. qui contient la nouvelle version du fichier, mais l'inode originel reste présent Présent où ça ? Dans les « attributs » des processus en cours ? Présent sur le disque (et référencé par les processus). tant qu'il reste des liens, donc tant qu'il n'est pas fermé par les processus qui l'ont ouvert. Mais durant cette période transitoire où il reste encore des processus qui ont ouvert un fichier situé sur une zone A du disque, zone pointée par cet « ancien » inode, qu'en est-il de cette zone A du disque ? Est-elle disponible ou non ? Non, elle n'est toujours pas disponible. Le fichier existe toujours. Cf la page man unlink(2): unlink() deletes a name from the filesystem. If that name was the last link to a file and no processes have the file open, the file is deleted and the space it was using is made available for reuse. If the name was the last link to a file but any processes still have the file open, the file will remain in existence until the last file descriptor referring to it is closed. If the name referred to a symbolic link, the link is removed. Si je comprends bien d'un côté cette zone n'est plus accessible via l'arborescence du filesystem car l'ancien inode n'existe plus. Du coup, cette zone du disque serait libre en quelques sortes ? Non, l'ancien inode existe toujours (je suppose qu'un processus qui a le fichier ouvert peut toujours faire un fstat sur le descripteur de fichier pour obtenir le numéro d'inode). -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150130004547.gb14...@xvii.vinc17.org
Re: Faille critique découverte dans GLIBC
❦ 28 janvier 2015 20:59 +0100, Philippe Deleval philippe.dele...@wanadoo.fr : C'est une blague? A mon avis, tout programmeur utilisant la fonction de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n), le petit n fait la différence. Faire strncpy(hostname, name, strlen(name) + 1) est tout à fait inutile. Le problème n'est pas le strcpy, mais la taille allouée pour la structure incluant hostname qui était trop petite. -- If you tell the truth you don't have to remember anything. -- Mark Twain signature.asc Description: PGP signature
Re: Faille critique découverte dans GLIBC
On sort un peu (beaucoup) du sujet de cette liste mais ça m'intéresse alors du coup j'aurais quelques questions si c'est possible. Le 29/01/2015 22:12, Pascal Hambourg a écrit : Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers l'inode correspondant, au même titre que les liens durs dans les répertoires. La mise à jour fait pointer le nom du fichier vers un nouvel inode Tu parles bien de la mis à jour d'une lib ? Dans ce cas, je ne comprends pas trop ce que tu veux dire par nouvel inode. Par exemple, j'ai ça : ~$ touch /tmp/foo.so ~$ touch /tmp/foo.so.new-version ~$ ls -i /tmp/foo.so* 523294 /tmp/foo.so 523295 /tmp/foo.so.new-version # Je considère la commande ci-dessous comme une màj du fichier foo.so ~$ cp /tmp/foo.so.new-version /tmp/foo.so # Et je constate que le numéro d'inode de foo.so n'a pas bougé ? ~$ ls -i /tmp/foo.so* 523294 /tmp/foo.so 523295 /tmp/foo.so.new-version Du coup, j'ai pas dû comprendre quelque chose dans ta phrase. qui contient la nouvelle version du fichier, mais l'inode originel reste présent Présent où ça ? Dans les « attributs » des processus en cours ? (Pour le terme « attributs », désolé je ne connais pas le bon vocabulaire.) tant qu'il reste des liens, donc tant qu'il n'est pas fermé par les processus qui l'ont ouvert. Mais durant cette période transitoire où il reste encore des processus qui ont ouvert un fichier situé sur une zone A du disque, zone pointée par cet « ancien » inode, qu'en est-il de cette zone A du disque ? Est-elle disponible ou non ? Si je comprends bien d'un côté cette zone n'est plus accessible via l'arborescence du filesystem car l'ancien inode n'existe plus. Du coup, cette zone du disque serait libre en quelques sortes ? Mais d'un autre côté, on peut imaginer que le système se doit d'interdire toute écriture au niveau de cette zone du disque sans quoi les processus ouverts pourraient lire alors absolument n'importe quoi au niveau de cette zone et donc finalement cette zone mémoire n'est donc pas complètement disponible encore ? -- François Lafont -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/maefqg$o2t$1...@ger.gmane.org
Re: [testing] tracker-extract et conso cpu
Le Wed, 28 Jan 2015 11:22:59 +0100 Haricophile haricoph...@aranha.fr a écrit: Le mardi 27 janvier 2015 à 22:30 +0100, Gaëtan PERRIER a écrit : Bonjour, Depuis quelques jours je constate que tracker-extract consomme énormément de CPU voir par moment tous les CPU. Est-ce de même chez vous ? Tracker est une plaie qui ne devrait pas être installé par défaut. C'est un très bon outil quand on a un travail ou des besoins en rapport avec la gestion documentaire, sur un ordinateur fixe. Ça permet de faire des requêtes évoluées en ligne de commande avec SPARQL à travers les métadonnées et contenu des fichiers. Sur un portable ou un usage simple, ça bouffe non seulement du CPU mais aussi des I/O disque à n'en plus finir, ça plombe n'importe quel système en particulier si tu le laisse chercher dans les fichiers compressés, et n'est pas du tout adapté à un ordinateur portable. Voilà mon avis. Certes mais ce n'est pas un avis sur l'utilité ou non de tracker que je demandais ... ;) A+ Gaëtan -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150129234450.a157e8766f5985bc1407d...@neuf.fr
