Salut !
Apr=E8s avoir installer FC5 (+gnome), je me suis rendu compte que mes cd
audio =E9taient bien automont=E9s sur le desktop, mais introuvable dans
le r=E9pertoire /media/ (l=E0 o=F9 sont mont=E9 traditionnelement les
volumes externe sous Fedora). Quelqu'un =E0 une id=E9e comment je
pourrais acc=E9der en lignes de commandes, =E0 mon cd audio ? De plus le
montage n'apparait pas il me semble dans mon /etc/fstab ou /etc/mtab.
Qu'est-ce qui est =E0 l'origine de ce montage particulier, FC5 ou gnome
?
Merci
C'est un problème simple de bufferisation en mode user.
Non, pas seulement.
Les players de cd audio ne se basent généralement pas sur cdparanoïa et résitent bien à des scheduling retardés.
Les lecteurs de CD audio font faire la conversion numérique-analogique par le lecteur de CD, qui envoie le tout directement en analogique à la carte son. Quand ce n'est pas disponible, il y a des craquements ; rares, évidemment, mais présents néanmoins.
... ce qui n'est pas vraiment la même chose...
Je ne sais pas bien pour KIO-slave, mais j'imagine que c'est assez proche de Gnome VFS dans le fonctionnement, et dans le cas de Gnome VFS, si, c'est _exactement_ la même chose qu'un filesystem en userland.
l'indien wrote in message <pan.2006.05.31.21.30.02.963491@magic.fr>:
C'est un problème simple de bufferisation en mode user.
Non, pas seulement.
Les players de cd
audio ne se basent généralement pas sur cdparanoïa et résitent bien à
des scheduling retardés.
Les lecteurs de CD audio font faire la conversion numérique-analogique par
le lecteur de CD, qui envoie le tout directement en analogique à la carte
son. Quand ce n'est pas disponible, il y a des craquements ; rares,
évidemment, mais présents néanmoins.
... ce qui n'est pas vraiment la même chose...
Je ne sais pas bien pour KIO-slave, mais j'imagine que c'est assez proche de
Gnome VFS dans le fonctionnement, et dans le cas de Gnome VFS, si, c'est
_exactement_ la même chose qu'un filesystem en userland.
C'est un problème simple de bufferisation en mode user.
Non, pas seulement.
Les players de cd audio ne se basent généralement pas sur cdparanoïa et résitent bien à des scheduling retardés.
Les lecteurs de CD audio font faire la conversion numérique-analogique par le lecteur de CD, qui envoie le tout directement en analogique à la carte son. Quand ce n'est pas disponible, il y a des craquements ; rares, évidemment, mais présents néanmoins.
... ce qui n'est pas vraiment la même chose...
Je ne sais pas bien pour KIO-slave, mais j'imagine que c'est assez proche de Gnome VFS dans le fonctionnement, et dans le cas de Gnome VFS, si, c'est _exactement_ la même chose qu'un filesystem en userland.
l'indien
On Wed, 31 May 2006 23:23:12 +0000, Nicolas George wrote:
l'indien wrote in message :
C'est un problème simple de bufferisation en mode user.
Non, pas seulement.
Pour en avoir écrit, je sais que si.
Les players de cd audio ne se basent généralement pas sur cdparanoïa et résitent bien à des scheduling retardés.
Les lecteurs de CD audio font faire la conversion numérique-analogique par le lecteur de CD, qui envoie le tout directement en analogique à la carte son. Quand ce n'est pas disponible, il y a des craquements ; rares, évidemment, mais présents néanmoins.
Les "vrais" lecteurs de CD ne font pas celà. J'ai écrit un soft (commercial) de lecture de CD sous Linux et je ne suis pas le seul à utiliser l'extraction audio numérique: XMMS et ses dérivés le font aussi, comme tous les programmes "sérieux". Le code pour implémenter celà n'est même pas plus complexe que celui nécessaire pour lire le CD en analogique...
... ce qui n'est pas vraiment la même chose...
Je ne sais pas bien pour KIO-slave, mais j'imagine que c'est assez proche de Gnome VFS dans le fonctionnement, et dans le cas de Gnome VFS, si, c'est _exactement_ la même chose qu'un filesystem en userland.
Euh, non, pas vraiment. Le VFS du noyau permet de maintenir une cohérence de caches, de buffers d'écritures, ... que ne permet pas à priori une librairie user sans aide spécifique du noyau. Il est notement impossible de controller finement les blocs devices depuis le mode user, du moins en utilisant les API de Linux existantes. Si ce n'était pas le cas, l'intégration du support des file-system en mode user dans le noyau serait complètement inutile. Il aurait été possible de développer une API de gestion fine des blocs device en mode user et d'implémenter le file-system entièrement en mode user, mais ce n'est pas la solution qui a été retenue, sans doute pour des raisons de performance.
Le VFS de Gnome est en fait très limité par rapport aux possibilité d'un vrai filesystem. De plus il n'est pas utilisable par les API standard du system (ie POSIX), ce qui limite énormément son champ d'application. Un file-system géré par le VFS du noyau est transparent pour ses utilisateurs, qu'il soit implémenté dans le noyau ou en mode user. C'est une chose que ne pourra jamais faire une librairie en mode user, c'est une limitation énorme.
On Wed, 31 May 2006 23:23:12 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2006.05.31.21.30.02.963491@magic.fr>:
C'est un problème simple de bufferisation en mode user.
Non, pas seulement.
Pour en avoir écrit, je sais que si.
Les players de cd
audio ne se basent généralement pas sur cdparanoïa et résitent bien
à des scheduling retardés.
Les lecteurs de CD audio font faire la conversion numérique-analogique
par le lecteur de CD, qui envoie le tout directement en analogique à la
carte son. Quand ce n'est pas disponible, il y a des craquements ; rares,
évidemment, mais présents néanmoins.
Les "vrais" lecteurs de CD ne font pas celà.
J'ai écrit un soft (commercial) de lecture de CD sous Linux et je ne suis
pas le seul à utiliser l'extraction audio numérique: XMMS et ses
dérivés le font aussi, comme tous les programmes "sérieux".
Le code pour implémenter celà n'est même pas plus complexe que celui
nécessaire pour lire le CD en analogique...
... ce qui n'est pas vraiment la même chose...
Je ne sais pas bien pour KIO-slave, mais j'imagine que c'est assez proche
de Gnome VFS dans le fonctionnement, et dans le cas de Gnome VFS, si,
c'est _exactement_ la même chose qu'un filesystem en userland.
Euh, non, pas vraiment.
Le VFS du noyau permet de maintenir une cohérence de caches, de buffers
d'écritures, ... que ne permet pas à priori une librairie user sans aide
spécifique du noyau. Il est notement impossible de controller finement
les blocs devices depuis le mode user, du moins en utilisant les API de
Linux existantes.
Si ce n'était pas le cas, l'intégration du support des file-system en
mode user dans le noyau serait complètement inutile.
Il aurait été possible de développer une API de gestion fine des blocs
device en mode user et d'implémenter le file-system entièrement en mode
user, mais ce n'est pas la solution qui a été retenue, sans doute pour
des raisons de performance.
Le VFS de Gnome est en fait très limité par rapport aux possibilité
d'un vrai filesystem. De plus il n'est pas utilisable par les API standard
du system (ie POSIX), ce qui limite énormément son champ d'application.
Un file-system géré par le VFS du noyau est transparent pour ses
utilisateurs, qu'il soit implémenté dans le noyau ou en mode user. C'est
une chose que ne pourra jamais faire une librairie en mode user, c'est une
limitation énorme.
On Wed, 31 May 2006 23:23:12 +0000, Nicolas George wrote:
l'indien wrote in message :
C'est un problème simple de bufferisation en mode user.
Non, pas seulement.
Pour en avoir écrit, je sais que si.
Les players de cd audio ne se basent généralement pas sur cdparanoïa et résitent bien à des scheduling retardés.
Les lecteurs de CD audio font faire la conversion numérique-analogique par le lecteur de CD, qui envoie le tout directement en analogique à la carte son. Quand ce n'est pas disponible, il y a des craquements ; rares, évidemment, mais présents néanmoins.
Les "vrais" lecteurs de CD ne font pas celà. J'ai écrit un soft (commercial) de lecture de CD sous Linux et je ne suis pas le seul à utiliser l'extraction audio numérique: XMMS et ses dérivés le font aussi, comme tous les programmes "sérieux". Le code pour implémenter celà n'est même pas plus complexe que celui nécessaire pour lire le CD en analogique...
... ce qui n'est pas vraiment la même chose...
Je ne sais pas bien pour KIO-slave, mais j'imagine que c'est assez proche de Gnome VFS dans le fonctionnement, et dans le cas de Gnome VFS, si, c'est _exactement_ la même chose qu'un filesystem en userland.
Euh, non, pas vraiment. Le VFS du noyau permet de maintenir une cohérence de caches, de buffers d'écritures, ... que ne permet pas à priori une librairie user sans aide spécifique du noyau. Il est notement impossible de controller finement les blocs devices depuis le mode user, du moins en utilisant les API de Linux existantes. Si ce n'était pas le cas, l'intégration du support des file-system en mode user dans le noyau serait complètement inutile. Il aurait été possible de développer une API de gestion fine des blocs device en mode user et d'implémenter le file-system entièrement en mode user, mais ce n'est pas la solution qui a été retenue, sans doute pour des raisons de performance.
Le VFS de Gnome est en fait très limité par rapport aux possibilité d'un vrai filesystem. De plus il n'est pas utilisable par les API standard du system (ie POSIX), ce qui limite énormément son champ d'application. Un file-system géré par le VFS du noyau est transparent pour ses utilisateurs, qu'il soit implémenté dans le noyau ou en mode user. C'est une chose que ne pourra jamais faire une librairie en mode user, c'est une limitation énorme.
Nicolas George
l'indien wrote in message :
J'ai écrit un soft (commercial) de lecture de CD sous Linux et je ne suis pas le seul à utiliser l'extraction audio numérique: XMMS et ses dérivés le font aussi, comme tous les programmes "sérieux". Le code pour implémenter celà n'est même pas plus complexe que celui nécessaire pour lire le CD en analogique...
Il n'est pas plus complexe, mais il produit des craquements, c'est ce que je dis depuis le début. Ces craquements sont rares, avec un système raisonnable ça devrait dans les un ou deux tous les 10 CD, mais ils sont néanmoins là.
Le VFS du noyau permet de maintenir une cohérence de caches, de buffers d'écritures, ... que ne permet pas à priori une librairie user sans aide spécifique du noyau. Il est notement impossible de controller finement les blocs devices depuis le mode user, du moins en utilisant les API de Linux existantes. Si ce n'était pas le cas, l'intégration du support des file-system en mode user dans le noyau serait complètement inutile. Il aurait été possible de développer une API de gestion fine des blocs device en mode user et d'implémenter le file-system entièrement en mode user, mais ce n'est pas la solution qui a été retenue, sans doute pour des raisons de performance.
Le VFS de Gnome est en fait très limité par rapport aux possibilité d'un vrai filesystem. De plus il n'est pas utilisable par les API standard du system (ie POSIX), ce qui limite énormément son champ d'application. Un file-system géré par le VFS du noyau est transparent pour ses utilisateurs, qu'il soit implémenté dans le noyau ou en mode user. C'est une chose que ne pourra jamais faire une librairie en mode user, c'est une limitation énorme.
Tout ce dont tu parles là, ce sont des détails d'implémentation, qui n'annulent pas ce que j'ai dit au début : sur le _principe_, c'est totalement la même chose.
l'indien wrote in message <pan.2006.06.01.22.49.03.466717@magic.fr>:
J'ai écrit un soft (commercial) de lecture de CD sous Linux et je ne suis
pas le seul à utiliser l'extraction audio numérique: XMMS et ses
dérivés le font aussi, comme tous les programmes "sérieux".
Le code pour implémenter celà n'est même pas plus complexe que celui
nécessaire pour lire le CD en analogique...
Il n'est pas plus complexe, mais il produit des craquements, c'est ce que je
dis depuis le début. Ces craquements sont rares, avec un système raisonnable
ça devrait dans les un ou deux tous les 10 CD, mais ils sont néanmoins là.
Le VFS du noyau permet de maintenir une cohérence de caches, de buffers
d'écritures, ... que ne permet pas à priori une librairie user sans aide
spécifique du noyau. Il est notement impossible de controller finement
les blocs devices depuis le mode user, du moins en utilisant les API de
Linux existantes.
Si ce n'était pas le cas, l'intégration du support des file-system en
mode user dans le noyau serait complètement inutile.
Il aurait été possible de développer une API de gestion fine des blocs
device en mode user et d'implémenter le file-system entièrement en mode
user, mais ce n'est pas la solution qui a été retenue, sans doute pour
des raisons de performance.
Le VFS de Gnome est en fait très limité par rapport aux possibilité
d'un vrai filesystem. De plus il n'est pas utilisable par les API standard
du system (ie POSIX), ce qui limite énormément son champ d'application.
Un file-system géré par le VFS du noyau est transparent pour ses
utilisateurs, qu'il soit implémenté dans le noyau ou en mode user. C'est
une chose que ne pourra jamais faire une librairie en mode user, c'est une
limitation énorme.
Tout ce dont tu parles là, ce sont des détails d'implémentation, qui
n'annulent pas ce que j'ai dit au début : sur le _principe_, c'est
totalement la même chose.
J'ai écrit un soft (commercial) de lecture de CD sous Linux et je ne suis pas le seul à utiliser l'extraction audio numérique: XMMS et ses dérivés le font aussi, comme tous les programmes "sérieux". Le code pour implémenter celà n'est même pas plus complexe que celui nécessaire pour lire le CD en analogique...
Il n'est pas plus complexe, mais il produit des craquements, c'est ce que je dis depuis le début. Ces craquements sont rares, avec un système raisonnable ça devrait dans les un ou deux tous les 10 CD, mais ils sont néanmoins là.
Le VFS du noyau permet de maintenir une cohérence de caches, de buffers d'écritures, ... que ne permet pas à priori une librairie user sans aide spécifique du noyau. Il est notement impossible de controller finement les blocs devices depuis le mode user, du moins en utilisant les API de Linux existantes. Si ce n'était pas le cas, l'intégration du support des file-system en mode user dans le noyau serait complètement inutile. Il aurait été possible de développer une API de gestion fine des blocs device en mode user et d'implémenter le file-system entièrement en mode user, mais ce n'est pas la solution qui a été retenue, sans doute pour des raisons de performance.
Le VFS de Gnome est en fait très limité par rapport aux possibilité d'un vrai filesystem. De plus il n'est pas utilisable par les API standard du system (ie POSIX), ce qui limite énormément son champ d'application. Un file-system géré par le VFS du noyau est transparent pour ses utilisateurs, qu'il soit implémenté dans le noyau ou en mode user. C'est une chose que ne pourra jamais faire une librairie en mode user, c'est une limitation énorme.
Tout ce dont tu parles là, ce sont des détails d'implémentation, qui n'annulent pas ce que j'ai dit au début : sur le _principe_, c'est totalement la même chose.
l'indien
On Fri, 02 Jun 2006 07:26:33 +0000, Nicolas George wrote:
l'indien wrote in message :
J'ai écrit un soft (commercial) de lecture de CD sous Linux et je ne suis pas le seul à utiliser l'extraction audio numérique: XMMS et ses dérivés le font aussi, comme tous les programmes "sérieux". Le code pour implémenter celà n'est même pas plus complexe que celui nécessaire pour lire le CD en analogique...
Il n'est pas plus complexe, mais il produit des craquements, c'est ce que je dis depuis le début. Ces craquements sont rares, avec un système raisonnable ça devrait dans les un ou deux tous les 10 CD, mais ils sont néanmoins là.
Uniquement sur des CD abimés. C'est à dire que ça donne le même comportement qu'un lecteur de salon, ce qui est acceptable pour la plupart des utilisations. Ce n'est pas acceptable pour du rip, je suis d'accord.
Le VFS du noyau permet de maintenir une cohérence de caches, de buffers d'écritures, ... que ne permet pas à priori une librairie user sans aide spécifique du noyau. Il est notement impossible de controller finement les blocs devices depuis le mode user, du moins en utilisant les API de Linux existantes. Si ce n'était pas le cas, l'intégration du support des file-system en mode user dans le noyau serait complètement inutile. Il aurait été possible de développer une API de gestion fine des blocs device en mode user et d'implémenter le file-system entièrement en mode user, mais ce n'est pas la solution qui a été retenue, sans doute pour des raisons de performance.
Le VFS de Gnome est en fait très limité par rapport aux possibilité d'un vrai filesystem. De plus il n'est pas utilisable par les API standard du system (ie POSIX), ce qui limite énormément son champ d'application. Un file-system géré par le VFS du noyau est transparent pour ses utilisateurs, qu'il soit implémenté dans le noyau ou en mode user. C'est une chose que ne pourra jamais faire une librairie en mode user, c'est une limitation énorme.
Tout ce dont tu parles là, ce sont des détails d'implémentation, qui n'annulent pas ce que j'ai dit au début : sur le _principe_, c'est totalement la même chose.
Ce n'est pas vraiment un détail d'implémentation que d'avoir un filesystem utilisable par tous les programmes existant sans modification ou d'avoir une librarie qui ne propose des accès qu'à certains programmes explicitement fait pour (et qui rend ces programmes incompatibles avec les systèmes POSIX "bruts"), à mon sens...
On Fri, 02 Jun 2006 07:26:33 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2006.06.01.22.49.03.466717@magic.fr>:
J'ai écrit un soft (commercial) de lecture de CD sous Linux et je ne
suis pas le seul à utiliser l'extraction audio numérique: XMMS et ses
dérivés le font aussi, comme tous les programmes "sérieux". Le code
pour implémenter celà n'est même pas plus complexe que celui
nécessaire pour lire le CD en analogique...
Il n'est pas plus complexe, mais il produit des craquements, c'est ce que
je dis depuis le début. Ces craquements sont rares, avec un système
raisonnable ça devrait dans les un ou deux tous les 10 CD, mais ils sont
néanmoins là.
Uniquement sur des CD abimés. C'est à dire que ça donne le même
comportement qu'un lecteur de salon, ce qui est acceptable pour la plupart
des utilisations.
Ce n'est pas acceptable pour du rip, je suis d'accord.
Le VFS du noyau permet de maintenir une cohérence de caches, de buffers
d'écritures, ... que ne permet pas à priori une librairie user sans
aide spécifique du noyau. Il est notement impossible de controller
finement les blocs devices depuis le mode user, du moins en utilisant
les API de Linux existantes.
Si ce n'était pas le cas, l'intégration du support des file-system en
mode user dans le noyau serait complètement inutile. Il aurait été
possible de développer une API de gestion fine des blocs device en mode
user et d'implémenter le file-system entièrement en mode user, mais ce
n'est pas la solution qui a été retenue, sans doute pour des raisons
de performance.
Le VFS de Gnome est en fait très limité par rapport aux possibilité
d'un vrai filesystem. De plus il n'est pas utilisable par les API
standard du system (ie POSIX), ce qui limite énormément son champ
d'application. Un file-system géré par le VFS du noyau est transparent
pour ses utilisateurs, qu'il soit implémenté dans le noyau ou en mode
user. C'est une chose que ne pourra jamais faire une librairie en mode
user, c'est une limitation énorme.
Tout ce dont tu parles là, ce sont des détails d'implémentation, qui
n'annulent pas ce que j'ai dit au début : sur le _principe_, c'est
totalement la même chose.
Ce n'est pas vraiment un détail d'implémentation que d'avoir un
filesystem utilisable par tous les programmes existant sans modification
ou d'avoir une librarie qui ne propose des accès qu'à certains
programmes explicitement fait pour (et qui rend ces programmes
incompatibles avec les systèmes POSIX "bruts"), à mon sens...
On Fri, 02 Jun 2006 07:26:33 +0000, Nicolas George wrote:
l'indien wrote in message :
J'ai écrit un soft (commercial) de lecture de CD sous Linux et je ne suis pas le seul à utiliser l'extraction audio numérique: XMMS et ses dérivés le font aussi, comme tous les programmes "sérieux". Le code pour implémenter celà n'est même pas plus complexe que celui nécessaire pour lire le CD en analogique...
Il n'est pas plus complexe, mais il produit des craquements, c'est ce que je dis depuis le début. Ces craquements sont rares, avec un système raisonnable ça devrait dans les un ou deux tous les 10 CD, mais ils sont néanmoins là.
Uniquement sur des CD abimés. C'est à dire que ça donne le même comportement qu'un lecteur de salon, ce qui est acceptable pour la plupart des utilisations. Ce n'est pas acceptable pour du rip, je suis d'accord.
Le VFS du noyau permet de maintenir une cohérence de caches, de buffers d'écritures, ... que ne permet pas à priori une librairie user sans aide spécifique du noyau. Il est notement impossible de controller finement les blocs devices depuis le mode user, du moins en utilisant les API de Linux existantes. Si ce n'était pas le cas, l'intégration du support des file-system en mode user dans le noyau serait complètement inutile. Il aurait été possible de développer une API de gestion fine des blocs device en mode user et d'implémenter le file-system entièrement en mode user, mais ce n'est pas la solution qui a été retenue, sans doute pour des raisons de performance.
Le VFS de Gnome est en fait très limité par rapport aux possibilité d'un vrai filesystem. De plus il n'est pas utilisable par les API standard du system (ie POSIX), ce qui limite énormément son champ d'application. Un file-system géré par le VFS du noyau est transparent pour ses utilisateurs, qu'il soit implémenté dans le noyau ou en mode user. C'est une chose que ne pourra jamais faire une librairie en mode user, c'est une limitation énorme.
Tout ce dont tu parles là, ce sont des détails d'implémentation, qui n'annulent pas ce que j'ai dit au début : sur le _principe_, c'est totalement la même chose.
Ce n'est pas vraiment un détail d'implémentation que d'avoir un filesystem utilisable par tous les programmes existant sans modification ou d'avoir une librarie qui ne propose des accès qu'à certains programmes explicitement fait pour (et qui rend ces programmes incompatibles avec les systèmes POSIX "bruts"), à mon sens...
