Le Tue, 06 Mar 2012 06:30:48 +1100,
Doug713705 écrivait :Le 05-03-2012, JKB nous expliquait dans
fr.comp.os.linux.debats :Hmm, je veux bien y croire mais quand même, il y a bien un enchainement
quelconque de circonstances qui a empéché cette mise à jour.
Testing est mouvante. Il faut donc assurer avec stable et unstable
pour boucher les trous.
Je n'ose imaginer ce que doit être unstable !
Je viens de faire la manipulation pour être sûr (sur un Acer Aspire
1700 au bios particulirèment foireux et non reconnu par eComStation
ou NetBSD).
Installation de debian/stable avec serveur ssh et paquets pour
portable et environnement de bureau puis mise à jour vers testing.
Aucun problème (et 1,5 Go de téléchargement pour une installation
par le réseau).
En revanche, je veux pouvoir triturer
facilement le FS en cas de problème.
Moi je préfère ne pas avoir de problème pour ne pas avoir à triturer.
Par ailleurs, j'ai déjà plantédes ReiserFS (sur des problèmes de mémoire, le bestiau est très
sensible à ça).
Je ne donne pas cher de n'importe quel FS dans ces conditions.
Quand la mémoire foire, tout devient possible.
Sauf que la probabilité de foirage est supérieure pour ReiserFS en
raison du volume de données en mémoire à taille de FS donnée.Je n'ai encore jamais planté de ext3 même après des
coupures de courant sur des volumes de plus d'un To.
Ah ? Moi j'ai réussi sans coupure de courant ni mémoire foireuse.
Comment donc ?
En ce qui concerne ext4, à chaque fois que je lis un article
sur ce truc, je ne me peux pas m'empécher de conclure que c'est une
bouse pire que ces prédecesseurs.
Ext4 fonctionne très bien.
De ce que j'en ai lu, niveau performance cela n'a pas l'air d'être tout
à fait ça.
Ce que je demande à un fs, ce n'est pas d'être rapide, c'est d'avoir
des performances acceptables en lecture et en écriture sur n'importe
quelle taille de fichiers. Et à chaque fois que j'ai regardé, ext3
ne se débrouillait pas si mal que ça. ext4 ne me pose pour l'instant
aucun problème. J'ai commencé à migrer des tours de disque en raid5
et 6 et je dois dire que ça ronronne.
Ben voilà, un truc foireux et non nécessaire qui s'invite tout seul par
dépendance, c'est typiquement le truc que je reproche à Debian et toutes
les distributions qui tentent de jouer aux devinettes quant aux
dependances.
Le truc s'invite parce que tu as un soft quelque part qui demande
une émulation OSS. Et l'outil d'installation, s'il est configuré
correctement, te laisse le choix entre tout ce qui te fournit cette
émulation (c'est un choix qui est fait lors de l'installation).
C'est toujours mieux que la gestion des dépendances de la slack.
Il me semble qu'Alsa a tout le necessaire pour gérer ça et je suis tout
à fait sûr d'avoir demandé à ce qu'il soit seul à prendre en charge
l'émulation OSS.
Le problème n'est pas l'émulation d'OSS par Alsa, mais le truc
intermédiaire entre ton gestionnaire de bureau et les applications
(histoire qu'une application ne verrouille pas /dev/dsp par
exemple).
Pour cela, il y a un certain nombre de daemons de esound à
pulseaudio en passant par une foultitude d'autres.
Je n'ai _jamais_ eu besoin de pulseaudio et pourtant j'en fait du bruit
avec tout un tas de programmes pour en générer.
Pulseaudio n'est pas là pour faire du bruit, il est là pour gérer
l'accès au machin qui fait du bruit.
Par ailleurs pulseaudio s'est invité lors de l'installation de Gnome3,
un truc sensé être moderne.
Comment un truc moderne peut-il encore avoir besoin d'une émulation OSS
?
Au hasard, /dev/dsp ?
Ma main a couper que nulle part dans la doc de Gnome3 on ne parle d'OSS,
sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y connais pas !
Le Tue, 06 Mar 2012 06:30:48 +1100,
Doug713705 <doug.letough@free.fr> écrivait :
Le 05-03-2012, JKB nous expliquait dans
fr.comp.os.linux.debats :
Hmm, je veux bien y croire mais quand même, il y a bien un enchainement
quelconque de circonstances qui a empéché cette mise à jour.
Testing est mouvante. Il faut donc assurer avec stable et unstable
pour boucher les trous.
Je n'ose imaginer ce que doit être unstable !
Je viens de faire la manipulation pour être sûr (sur un Acer Aspire
1700 au bios particulirèment foireux et non reconnu par eComStation
ou NetBSD).
Installation de debian/stable avec serveur ssh et paquets pour
portable et environnement de bureau puis mise à jour vers testing.
Aucun problème (et 1,5 Go de téléchargement pour une installation
par le réseau).
En revanche, je veux pouvoir triturer
facilement le FS en cas de problème.
Moi je préfère ne pas avoir de problème pour ne pas avoir à triturer.
Par ailleurs, j'ai déjà planté
des ReiserFS (sur des problèmes de mémoire, le bestiau est très
sensible à ça).
Je ne donne pas cher de n'importe quel FS dans ces conditions.
Quand la mémoire foire, tout devient possible.
Sauf que la probabilité de foirage est supérieure pour ReiserFS en
raison du volume de données en mémoire à taille de FS donnée.
Je n'ai encore jamais planté de ext3 même après des
coupures de courant sur des volumes de plus d'un To.
Ah ? Moi j'ai réussi sans coupure de courant ni mémoire foireuse.
Comment donc ?
En ce qui concerne ext4, à chaque fois que je lis un article
sur ce truc, je ne me peux pas m'empécher de conclure que c'est une
bouse pire que ces prédecesseurs.
Ext4 fonctionne très bien.
De ce que j'en ai lu, niveau performance cela n'a pas l'air d'être tout
à fait ça.
Ce que je demande à un fs, ce n'est pas d'être rapide, c'est d'avoir
des performances acceptables en lecture et en écriture sur n'importe
quelle taille de fichiers. Et à chaque fois que j'ai regardé, ext3
ne se débrouillait pas si mal que ça. ext4 ne me pose pour l'instant
aucun problème. J'ai commencé à migrer des tours de disque en raid5
et 6 et je dois dire que ça ronronne.
Ben voilà, un truc foireux et non nécessaire qui s'invite tout seul par
dépendance, c'est typiquement le truc que je reproche à Debian et toutes
les distributions qui tentent de jouer aux devinettes quant aux
dependances.
Le truc s'invite parce que tu as un soft quelque part qui demande
une émulation OSS. Et l'outil d'installation, s'il est configuré
correctement, te laisse le choix entre tout ce qui te fournit cette
émulation (c'est un choix qui est fait lors de l'installation).
C'est toujours mieux que la gestion des dépendances de la slack.
Il me semble qu'Alsa a tout le necessaire pour gérer ça et je suis tout
à fait sûr d'avoir demandé à ce qu'il soit seul à prendre en charge
l'émulation OSS.
Le problème n'est pas l'émulation d'OSS par Alsa, mais le truc
intermédiaire entre ton gestionnaire de bureau et les applications
(histoire qu'une application ne verrouille pas /dev/dsp par
exemple).
Pour cela, il y a un certain nombre de daemons de esound à
pulseaudio en passant par une foultitude d'autres.
Je n'ai _jamais_ eu besoin de pulseaudio et pourtant j'en fait du bruit
avec tout un tas de programmes pour en générer.
Pulseaudio n'est pas là pour faire du bruit, il est là pour gérer
l'accès au machin qui fait du bruit.
Par ailleurs pulseaudio s'est invité lors de l'installation de Gnome3,
un truc sensé être moderne.
Comment un truc moderne peut-il encore avoir besoin d'une émulation OSS
?
Au hasard, /dev/dsp ?
Ma main a couper que nulle part dans la doc de Gnome3 on ne parle d'OSS,
sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y connais pas !
Le Tue, 06 Mar 2012 06:30:48 +1100,
Doug713705 écrivait :Le 05-03-2012, JKB nous expliquait dans
fr.comp.os.linux.debats :Hmm, je veux bien y croire mais quand même, il y a bien un enchainement
quelconque de circonstances qui a empéché cette mise à jour.
Testing est mouvante. Il faut donc assurer avec stable et unstable
pour boucher les trous.
Je n'ose imaginer ce que doit être unstable !
Je viens de faire la manipulation pour être sûr (sur un Acer Aspire
1700 au bios particulirèment foireux et non reconnu par eComStation
ou NetBSD).
Installation de debian/stable avec serveur ssh et paquets pour
portable et environnement de bureau puis mise à jour vers testing.
Aucun problème (et 1,5 Go de téléchargement pour une installation
par le réseau).
En revanche, je veux pouvoir triturer
facilement le FS en cas de problème.
Moi je préfère ne pas avoir de problème pour ne pas avoir à triturer.
Par ailleurs, j'ai déjà plantédes ReiserFS (sur des problèmes de mémoire, le bestiau est très
sensible à ça).
Je ne donne pas cher de n'importe quel FS dans ces conditions.
Quand la mémoire foire, tout devient possible.
Sauf que la probabilité de foirage est supérieure pour ReiserFS en
raison du volume de données en mémoire à taille de FS donnée.Je n'ai encore jamais planté de ext3 même après des
coupures de courant sur des volumes de plus d'un To.
Ah ? Moi j'ai réussi sans coupure de courant ni mémoire foireuse.
Comment donc ?
En ce qui concerne ext4, à chaque fois que je lis un article
sur ce truc, je ne me peux pas m'empécher de conclure que c'est une
bouse pire que ces prédecesseurs.
Ext4 fonctionne très bien.
De ce que j'en ai lu, niveau performance cela n'a pas l'air d'être tout
à fait ça.
Ce que je demande à un fs, ce n'est pas d'être rapide, c'est d'avoir
des performances acceptables en lecture et en écriture sur n'importe
quelle taille de fichiers. Et à chaque fois que j'ai regardé, ext3
ne se débrouillait pas si mal que ça. ext4 ne me pose pour l'instant
aucun problème. J'ai commencé à migrer des tours de disque en raid5
et 6 et je dois dire que ça ronronne.
Ben voilà, un truc foireux et non nécessaire qui s'invite tout seul par
dépendance, c'est typiquement le truc que je reproche à Debian et toutes
les distributions qui tentent de jouer aux devinettes quant aux
dependances.
Le truc s'invite parce que tu as un soft quelque part qui demande
une émulation OSS. Et l'outil d'installation, s'il est configuré
correctement, te laisse le choix entre tout ce qui te fournit cette
émulation (c'est un choix qui est fait lors de l'installation).
C'est toujours mieux que la gestion des dépendances de la slack.
Il me semble qu'Alsa a tout le necessaire pour gérer ça et je suis tout
à fait sûr d'avoir demandé à ce qu'il soit seul à prendre en charge
l'émulation OSS.
Le problème n'est pas l'émulation d'OSS par Alsa, mais le truc
intermédiaire entre ton gestionnaire de bureau et les applications
(histoire qu'une application ne verrouille pas /dev/dsp par
exemple).
Pour cela, il y a un certain nombre de daemons de esound à
pulseaudio en passant par une foultitude d'autres.
Je n'ai _jamais_ eu besoin de pulseaudio et pourtant j'en fait du bruit
avec tout un tas de programmes pour en générer.
Pulseaudio n'est pas là pour faire du bruit, il est là pour gérer
l'accès au machin qui fait du bruit.
Par ailleurs pulseaudio s'est invité lors de l'installation de Gnome3,
un truc sensé être moderne.
Comment un truc moderne peut-il encore avoir besoin d'une émulation OSS
?
Au hasard, /dev/dsp ?
Ma main a couper que nulle part dans la doc de Gnome3 on ne parle d'OSS,
sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y connais pas !
> Quelqu'un sait quand les outils du genre fsck seront disponibles
> pour Btrfs, qu'on puisse commencer à l'utiliser couramment ?
Et bien figure toi que Slackware dispose d'un fsck pour btrfs.
Et dans le monde civilisé ? ;)
Comme je suppose que ce n'est pas le mainteneur Slackware qui l'a
développé tout seul dans son coin, ça veut dire que tous les outils
autour de Btrfs sont maintenant disponibles et qu'on peut l'utiliser en
vrai (y compris en cas de plantage de la machine) ?
> Quelqu'un sait quand les outils du genre fsck seront disponibles
> pour Btrfs, qu'on puisse commencer à l'utiliser couramment ?
Et bien figure toi que Slackware dispose d'un fsck pour btrfs.
Et dans le monde civilisé ? ;)
Comme je suppose que ce n'est pas le mainteneur Slackware qui l'a
développé tout seul dans son coin, ça veut dire que tous les outils
autour de Btrfs sont maintenant disponibles et qu'on peut l'utiliser en
vrai (y compris en cas de plantage de la machine) ?
> Quelqu'un sait quand les outils du genre fsck seront disponibles
> pour Btrfs, qu'on puisse commencer à l'utiliser couramment ?
Et bien figure toi que Slackware dispose d'un fsck pour btrfs.
Et dans le monde civilisé ? ;)
Comme je suppose que ce n'est pas le mainteneur Slackware qui l'a
développé tout seul dans son coin, ça veut dire que tous les outils
autour de Btrfs sont maintenant disponibles et qu'on peut l'utiliser en
vrai (y compris en cas de plantage de la machine) ?
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
Bah, s'il s'est trompé il pourra toujours prétendre que sa main était
une dépendance optionnelle inutile et que de toutes façons il ne
voulait pas s'en encombrer ;) .
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
Bah, s'il s'est trompé il pourra toujours prétendre que sa main était
une dépendance optionnelle inutile et que de toutes façons il ne
voulait pas s'en encombrer ;) .
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
Bah, s'il s'est trompé il pourra toujours prétendre que sa main était
une dépendance optionnelle inutile et que de toutes façons il ne
voulait pas s'en encombrer ;) .
Et puis pour faire du son unpeu plus sérieusement il y a JACK.
Et puis pour faire du son unpeu plus sérieusement il y a JACK.
Et puis pour faire du son unpeu plus sérieusement il y a JACK.
On 03/07/2012 01:41 AM, Doug713705 wrote:Et puis pour faire du son unpeu plus sérieusement il y a JACK.
C'est clairement à ça que je pensais ;)
On 03/07/2012 01:41 AM, Doug713705 wrote:
Et puis pour faire du son unpeu plus sérieusement il y a JACK.
C'est clairement à ça que je pensais ;)
On 03/07/2012 01:41 AM, Doug713705 wrote:Et puis pour faire du son unpeu plus sérieusement il y a JACK.
C'est clairement à ça que je pensais ;)
Le 06-03-2012, JKB nous expliquait dans
fr.comp.os.linux.debats :Le Tue, 06 Mar 2012 06:30:48 +1100,
Doug713705 écrivait :
Houlà, c'est trop vieux pour que je me souvienne des détails, ça date de
RedHat 7.1 (ou peut-être 7.3), c'est dire !
La seule chose dont je me souviens c'est que je me suis retrouvé avec un
répertoire lost+found garni de tonnes de fichiers avec des jolis
numéros en guise de nom et que je n'ai pas réussi à en récupérer la
moitié (de mémoire le processur de récupération était plus ou moins
manuel, donc trop long à mettre en oeuvre pour des données sans réèlles
valeurs).
Depuis, je n'ai jamais retouché à ext !
En ce qui concerne ext4, à chaque fois que je lis un article
sur ce truc, je ne me peux pas m'empécher de conclure que c'est une
bouse pire que ces prédecesseurs.
Ext4 fonctionne très bien.
De ce que j'en ai lu, niveau performance cela n'a pas l'air d'être tout
à fait ça.
Ce que je demande à un fs, ce n'est pas d'être rapide, c'est d'avoir
des performances acceptables en lecture et en écriture sur n'importe
quelle taille de fichiers. Et à chaque fois que j'ai regardé, ext3
ne se débrouillait pas si mal que ça. ext4 ne me pose pour l'instant
aucun problème. J'ai commencé à migrer des tours de disque en raid5
et 6 et je dois dire que ça ronronne.
Ah moi ce que je demande en plus de la fiabilité c'est les performances
les meilleures pour le type de fichiers que j'utilise le plus, c'est à
dire comme tout le monde, en grande majorité des fichiers de petites
tailles.
Rien de pire qu'un FS qui rame pour lire les n fichiers de
configuration et d'initialisation au démarage de tel ou tel
service/application.
Parce que bon, pour une machine de bureau ou un portable, c'est pas tous
les jours que je vais manipuler une archive de 42 To ou même déplacer
(changer de partition) un ou des films de quelques Go.
Par contre manipuler des fichiers de quelques Ko à quelques Mo, ça oui,
tous les jours.
Ben voilà, un truc foireux et non nécessaire qui s'invite tout seul par
dépendance, c'est typiquement le truc que je reproche à Debian et toutes
les distributions qui tentent de jouer aux devinettes quant aux
dependances.
Le truc s'invite parce que tu as un soft quelque part qui demande
une émulation OSS. Et l'outil d'installation, s'il est configuré
correctement, te laisse le choix entre tout ce qui te fournit cette
émulation (c'est un choix qui est fait lors de l'installation).
C'est toujours mieux que la gestion des dépendances de la slack.
Il me semble qu'Alsa a tout le necessaire pour gérer ça et je suis tout
à fait sûr d'avoir demandé à ce qu'il soit seul à prendre en charge
l'émulation OSS.
Le problème n'est pas l'émulation d'OSS par Alsa, mais le truc
intermédiaire entre ton gestionnaire de bureau et les applications
(histoire qu'une application ne verrouille pas /dev/dsp par
exemple).
Qué ? Sur ma présente Slackware j'utilise simultanément mpd, mplayer,
skype et aplay sans problème ! Aucun ne vérrouille quoi que ce soit
(enfin si mais une fois configuré alsa _seul_ s'en débrouille très bien)
Pour cela, il y a un certain nombre de daemons de esound à
pulseaudio en passant par une foultitude d'autres.
Tous plus inutiles les uns que les autres.
Aucun d'eux n'est installés chez moi.
Je n'ai _jamais_ eu besoin de pulseaudio et pourtant j'en fait du bruit
avec tout un tas de programmes pour en générer.
Pulseaudio n'est pas là pour faire du bruit, il est là pour gérer
l'accès au machin qui fait du bruit.
Oui et je n'ai jamais eu besoin de lui pour faire du bruit avec tous les
machins en même temps.
Au pire JACK peut être utile mais pulseaudio, je ne vois pas.
Par ailleurs pulseaudio s'est invité lors de l'installation de Gnome3,
un truc sensé être moderne.
Comment un truc moderne peut-il encore avoir besoin d'une émulation OSS
?
Au hasard, /dev/dsp ?
Ben /dev/dsp en lui même ne réclame rien.
C'est quoi ces applications qui réclament encore un truc obsolète 1à ans
après que tout le monde ait dit qu'il fallait arréter de l'utiliser ?
Ma main a couper que nulle part dans la doc de Gnome3 on ne parle d'OSS,
sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y connais pas !
Bah pas tant que ça, quelle application purement Gnome à besoin de
pulseaudio pour fonctionner convenablement ?
Quand je veux installer Gnome3, je veux installer _que_ Gnome3 et ses
dépendances pas autre chose.
Si Gnome3 a besoin de pulseaudio ça doit être écrit quelque part dans la
doc de Gnome. Dans le cas contraire je déduit que la version Debian de
Gnome à besoin de puleaudio quand la version upstream s'en passe
allègrement.
Le 06-03-2012, JKB nous expliquait dans
fr.comp.os.linux.debats :
Le Tue, 06 Mar 2012 06:30:48 +1100,
Doug713705 <doug.letough@free.fr> écrivait :
Houlà, c'est trop vieux pour que je me souvienne des détails, ça date de
RedHat 7.1 (ou peut-être 7.3), c'est dire !
La seule chose dont je me souviens c'est que je me suis retrouvé avec un
répertoire lost+found garni de tonnes de fichiers avec des jolis
numéros en guise de nom et que je n'ai pas réussi à en récupérer la
moitié (de mémoire le processur de récupération était plus ou moins
manuel, donc trop long à mettre en oeuvre pour des données sans réèlles
valeurs).
Depuis, je n'ai jamais retouché à ext !
En ce qui concerne ext4, à chaque fois que je lis un article
sur ce truc, je ne me peux pas m'empécher de conclure que c'est une
bouse pire que ces prédecesseurs.
Ext4 fonctionne très bien.
De ce que j'en ai lu, niveau performance cela n'a pas l'air d'être tout
à fait ça.
Ce que je demande à un fs, ce n'est pas d'être rapide, c'est d'avoir
des performances acceptables en lecture et en écriture sur n'importe
quelle taille de fichiers. Et à chaque fois que j'ai regardé, ext3
ne se débrouillait pas si mal que ça. ext4 ne me pose pour l'instant
aucun problème. J'ai commencé à migrer des tours de disque en raid5
et 6 et je dois dire que ça ronronne.
Ah moi ce que je demande en plus de la fiabilité c'est les performances
les meilleures pour le type de fichiers que j'utilise le plus, c'est à
dire comme tout le monde, en grande majorité des fichiers de petites
tailles.
Rien de pire qu'un FS qui rame pour lire les n fichiers de
configuration et d'initialisation au démarage de tel ou tel
service/application.
Parce que bon, pour une machine de bureau ou un portable, c'est pas tous
les jours que je vais manipuler une archive de 42 To ou même déplacer
(changer de partition) un ou des films de quelques Go.
Par contre manipuler des fichiers de quelques Ko à quelques Mo, ça oui,
tous les jours.
Ben voilà, un truc foireux et non nécessaire qui s'invite tout seul par
dépendance, c'est typiquement le truc que je reproche à Debian et toutes
les distributions qui tentent de jouer aux devinettes quant aux
dependances.
Le truc s'invite parce que tu as un soft quelque part qui demande
une émulation OSS. Et l'outil d'installation, s'il est configuré
correctement, te laisse le choix entre tout ce qui te fournit cette
émulation (c'est un choix qui est fait lors de l'installation).
C'est toujours mieux que la gestion des dépendances de la slack.
Il me semble qu'Alsa a tout le necessaire pour gérer ça et je suis tout
à fait sûr d'avoir demandé à ce qu'il soit seul à prendre en charge
l'émulation OSS.
Le problème n'est pas l'émulation d'OSS par Alsa, mais le truc
intermédiaire entre ton gestionnaire de bureau et les applications
(histoire qu'une application ne verrouille pas /dev/dsp par
exemple).
Qué ? Sur ma présente Slackware j'utilise simultanément mpd, mplayer,
skype et aplay sans problème ! Aucun ne vérrouille quoi que ce soit
(enfin si mais une fois configuré alsa _seul_ s'en débrouille très bien)
Pour cela, il y a un certain nombre de daemons de esound à
pulseaudio en passant par une foultitude d'autres.
Tous plus inutiles les uns que les autres.
Aucun d'eux n'est installés chez moi.
Je n'ai _jamais_ eu besoin de pulseaudio et pourtant j'en fait du bruit
avec tout un tas de programmes pour en générer.
Pulseaudio n'est pas là pour faire du bruit, il est là pour gérer
l'accès au machin qui fait du bruit.
Oui et je n'ai jamais eu besoin de lui pour faire du bruit avec tous les
machins en même temps.
Au pire JACK peut être utile mais pulseaudio, je ne vois pas.
Par ailleurs pulseaudio s'est invité lors de l'installation de Gnome3,
un truc sensé être moderne.
Comment un truc moderne peut-il encore avoir besoin d'une émulation OSS
?
Au hasard, /dev/dsp ?
Ben /dev/dsp en lui même ne réclame rien.
C'est quoi ces applications qui réclament encore un truc obsolète 1à ans
après que tout le monde ait dit qu'il fallait arréter de l'utiliser ?
Ma main a couper que nulle part dans la doc de Gnome3 on ne parle d'OSS,
sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y connais pas !
Bah pas tant que ça, quelle application purement Gnome à besoin de
pulseaudio pour fonctionner convenablement ?
Quand je veux installer Gnome3, je veux installer _que_ Gnome3 et ses
dépendances pas autre chose.
Si Gnome3 a besoin de pulseaudio ça doit être écrit quelque part dans la
doc de Gnome. Dans le cas contraire je déduit que la version Debian de
Gnome à besoin de puleaudio quand la version upstream s'en passe
allègrement.
Le 06-03-2012, JKB nous expliquait dans
fr.comp.os.linux.debats :Le Tue, 06 Mar 2012 06:30:48 +1100,
Doug713705 écrivait :
Houlà, c'est trop vieux pour que je me souvienne des détails, ça date de
RedHat 7.1 (ou peut-être 7.3), c'est dire !
La seule chose dont je me souviens c'est que je me suis retrouvé avec un
répertoire lost+found garni de tonnes de fichiers avec des jolis
numéros en guise de nom et que je n'ai pas réussi à en récupérer la
moitié (de mémoire le processur de récupération était plus ou moins
manuel, donc trop long à mettre en oeuvre pour des données sans réèlles
valeurs).
Depuis, je n'ai jamais retouché à ext !
En ce qui concerne ext4, à chaque fois que je lis un article
sur ce truc, je ne me peux pas m'empécher de conclure que c'est une
bouse pire que ces prédecesseurs.
Ext4 fonctionne très bien.
De ce que j'en ai lu, niveau performance cela n'a pas l'air d'être tout
à fait ça.
Ce que je demande à un fs, ce n'est pas d'être rapide, c'est d'avoir
des performances acceptables en lecture et en écriture sur n'importe
quelle taille de fichiers. Et à chaque fois que j'ai regardé, ext3
ne se débrouillait pas si mal que ça. ext4 ne me pose pour l'instant
aucun problème. J'ai commencé à migrer des tours de disque en raid5
et 6 et je dois dire que ça ronronne.
Ah moi ce que je demande en plus de la fiabilité c'est les performances
les meilleures pour le type de fichiers que j'utilise le plus, c'est à
dire comme tout le monde, en grande majorité des fichiers de petites
tailles.
Rien de pire qu'un FS qui rame pour lire les n fichiers de
configuration et d'initialisation au démarage de tel ou tel
service/application.
Parce que bon, pour une machine de bureau ou un portable, c'est pas tous
les jours que je vais manipuler une archive de 42 To ou même déplacer
(changer de partition) un ou des films de quelques Go.
Par contre manipuler des fichiers de quelques Ko à quelques Mo, ça oui,
tous les jours.
Ben voilà, un truc foireux et non nécessaire qui s'invite tout seul par
dépendance, c'est typiquement le truc que je reproche à Debian et toutes
les distributions qui tentent de jouer aux devinettes quant aux
dependances.
Le truc s'invite parce que tu as un soft quelque part qui demande
une émulation OSS. Et l'outil d'installation, s'il est configuré
correctement, te laisse le choix entre tout ce qui te fournit cette
émulation (c'est un choix qui est fait lors de l'installation).
C'est toujours mieux que la gestion des dépendances de la slack.
Il me semble qu'Alsa a tout le necessaire pour gérer ça et je suis tout
à fait sûr d'avoir demandé à ce qu'il soit seul à prendre en charge
l'émulation OSS.
Le problème n'est pas l'émulation d'OSS par Alsa, mais le truc
intermédiaire entre ton gestionnaire de bureau et les applications
(histoire qu'une application ne verrouille pas /dev/dsp par
exemple).
Qué ? Sur ma présente Slackware j'utilise simultanément mpd, mplayer,
skype et aplay sans problème ! Aucun ne vérrouille quoi que ce soit
(enfin si mais une fois configuré alsa _seul_ s'en débrouille très bien)
Pour cela, il y a un certain nombre de daemons de esound à
pulseaudio en passant par une foultitude d'autres.
Tous plus inutiles les uns que les autres.
Aucun d'eux n'est installés chez moi.
Je n'ai _jamais_ eu besoin de pulseaudio et pourtant j'en fait du bruit
avec tout un tas de programmes pour en générer.
Pulseaudio n'est pas là pour faire du bruit, il est là pour gérer
l'accès au machin qui fait du bruit.
Oui et je n'ai jamais eu besoin de lui pour faire du bruit avec tous les
machins en même temps.
Au pire JACK peut être utile mais pulseaudio, je ne vois pas.
Par ailleurs pulseaudio s'est invité lors de l'installation de Gnome3,
un truc sensé être moderne.
Comment un truc moderne peut-il encore avoir besoin d'une émulation OSS
?
Au hasard, /dev/dsp ?
Ben /dev/dsp en lui même ne réclame rien.
C'est quoi ces applications qui réclament encore un truc obsolète 1à ans
après que tout le monde ait dit qu'il fallait arréter de l'utiliser ?
Ma main a couper que nulle part dans la doc de Gnome3 on ne parle d'OSS,
sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y connais pas !
Bah pas tant que ça, quelle application purement Gnome à besoin de
pulseaudio pour fonctionner convenablement ?
Quand je veux installer Gnome3, je veux installer _que_ Gnome3 et ses
dépendances pas autre chose.
Si Gnome3 a besoin de pulseaudio ça doit être écrit quelque part dans la
doc de Gnome. Dans le cas contraire je déduit que la version Debian de
Gnome à besoin de puleaudio quand la version upstream s'en passe
allègrement.
Le 07-03-2012, Yliur nous expliquait dans
fr.comp.os.linux.debats :> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
Bah, s'il s'est trompé il pourra toujours prétendre que sa main était
une dépendance optionnelle inutile et que de toutes façons il ne
voulait pas s'en encombrer ;) .
:-D
N'empèche que ma main est sur le billot et que j'attends toujours la
moindre référence à OSS ou pulseaudio dans la doc de Gnome.
Le 07-03-2012, Yliur nous expliquait dans
fr.comp.os.linux.debats :
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
Bah, s'il s'est trompé il pourra toujours prétendre que sa main était
une dépendance optionnelle inutile et que de toutes façons il ne
voulait pas s'en encombrer ;) .
:-D
N'empèche que ma main est sur le billot et que j'attends toujours la
moindre référence à OSS ou pulseaudio dans la doc de Gnome.
Le 07-03-2012, Yliur nous expliquait dans
fr.comp.os.linux.debats :> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
Bah, s'il s'est trompé il pourra toujours prétendre que sa main était
une dépendance optionnelle inutile et que de toutes façons il ne
voulait pas s'en encombrer ;) .
:-D
N'empèche que ma main est sur le billot et que j'attends toujours la
moindre référence à OSS ou pulseaudio dans la doc de Gnome.
Le Tue, 06 Mar 2012 06:30:48 +1100,
Doug713705 écrivait :
Houlà, c'est trop vieux pour que je me souvienne des détails, ça date de
RedHat 7.1 (ou peut-être 7.3), c'est dire !
Je parle d'une distribution fiable, pas d'un truc comme ça. La
dernière Redhat que j'avais en production, je l'ai viré à la suite
d'un foirage total d'une mise à jour (7.3 vers 8.0) et seule ma
flemme m'avait dissuadé de ne pas la virer au passage de 6.2 vers
7.0.
La seule chose dont je me souviens c'est que je me suis retrouvé avec un
répertoire lost+found garni de tonnes de fichiers avec des jolis
numéros en guise de nom et que je n'ai pas réussi à en récupérer la
moitié (de mémoire le processur de récupération était plus ou moins
manuel, donc trop long à mettre en oeuvre pour des données sans réèlles
valeurs).
Depuis, je n'ai jamais retouché à ext !
À l'époque, c'était ext2, pas ext3. Pour avoir un support ext3? il
fallait parcher le noyau soi-même comme un grand. ext2 n'était pas
journalisé (et les options de montage de ext3 par défaut chez redhat
sont dangereuses, au moins quand j'avais regardé ce point).
En ce qui concerne ext4, à chaque fois que je lis un article
sur ce truc, je ne me peux pas m'empécher de conclure que c'est une
bouse pire que ces prédecesseurs.
Ext4 fonctionne très bien.
De ce que j'en ai lu, niveau performance cela n'a pas l'air d'être tout
à fait ça.
Ce que je demande à un fs, ce n'est pas d'être rapide, c'est d'avoir
des performances acceptables en lecture et en écriture sur n'importe
quelle taille de fichiers. Et à chaque fois que j'ai regardé, ext3
ne se débrouillait pas si mal que ça. ext4 ne me pose pour l'instant
aucun problème. J'ai commencé à migrer des tours de disque en raid5
et 6 et je dois dire que ça ronronne.
Ah moi ce que je demande en plus de la fiabilité c'est les performances
les meilleures pour le type de fichiers que j'utilise le plus, c'est à
dire comme tout le monde, en grande majorité des fichiers de petites
tailles.
Rien de pire qu'un FS qui rame pour lire les n fichiers de
configuration et d'initialisation au démarage de tel ou tel
service/application.
Franchement, si tu vois la différence entre un daemon qui démarre
sur du ReiserFS et la même chose en XFS ou ext3/4, tu es doué. Je
veux bien discuter pour un serveur de mail ou de news, mais pour un
système standard, c'est de la sodomie de diptère sans vaseline.
Parce que bon, pour une machine de bureau ou un portable, c'est pas tous
les jours que je vais manipuler une archive de 42 To ou même déplacer
(changer de partition) un ou des films de quelques Go.
Par contre manipuler des fichiers de quelques Ko à quelques Mo, ça oui,
tous les jours.
Mais pas assez pour voir une réelle différence entre un ext3 et
autre chose.
Ben voilà, un truc foireux et non nécessaire qui s'invite tout seul par
dépendance, c'est typiquement le truc que je reproche à Debian et toutes
les distributions qui tentent de jouer aux devinettes quant aux
dependances.
Le truc s'invite parce que tu as un soft quelque part qui demande
une émulation OSS. Et l'outil d'installation, s'il est configuré
correctement, te laisse le choix entre tout ce qui te fournit cette
émulation (c'est un choix qui est fait lors de l'installation).
C'est toujours mieux que la gestion des dépendances de la slack.
Il me semble qu'Alsa a tout le necessaire pour gérer ça et je suis tout
à fait sûr d'avoir demandé à ce qu'il soit seul à prendre en charge
l'émulation OSS.
Le problème n'est pas l'émulation d'OSS par Alsa, mais le truc
intermédiaire entre ton gestionnaire de bureau et les applications
(histoire qu'une application ne verrouille pas /dev/dsp par
exemple).
Qué ? Sur ma présente Slackware j'utilise simultanément mpd, mplayer,
skype et aplay sans problème ! Aucun ne vérrouille quoi que ce soit
(enfin si mais une fois configuré alsa _seul_ s'en débrouille très bien)
Euh, non. Il faut jackd/pulseaudio/whatever pour que ça marche
correctement dans tous les cas.
Pour cela, il y a un certain nombre de daemons de esound à
pulseaudio en passant par une foultitude d'autres.
Tous plus inutiles les uns que les autres.
Aucun d'eux n'est installés chez moi.
Pas 'inutiles'. Disons simplement que tu n'es jamais tombé sur un
cas un peu particulier. Par ailleurs, tous ces daemons permettent de
gérer les droits sur les devices. Ça peut être très pratique en cas
de partage d'une machine entre plusieurs utilisateurs.
Je n'ai _jamais_ eu besoin de pulseaudio et pourtant j'en fait du bruit
avec tout un tas de programmes pour en générer.
Pulseaudio n'est pas là pour faire du bruit, il est là pour gérer
l'accès au machin qui fait du bruit.
Oui et je n'ai jamais eu besoin de lui pour faire du bruit avec tous les
machins en même temps.
Au pire JACK peut être utile mais pulseaudio, je ne vois pas.
Il y a des gens qui n'aiment pas jackd. Pour tout un tas de bonnes
ou de mauvaises raisons.
Par ailleurs pulseaudio s'est invité lors de l'installation de Gnome3,
un truc sensé être moderne.
Comment un truc moderne peut-il encore avoir besoin d'une émulation OSS
?
Au hasard, /dev/dsp ?
Ben /dev/dsp en lui même ne réclame rien.
C'est quoi ces applications qui réclament encore un truc obsolète 1à ans
après que tout le monde ait dit qu'il fallait arréter de l'utiliser ?
Je n'ai pas de liste sous la main. Mais de toute façon, même avec
les applications qui utilisent nativement alsa, les mêmes problèmes
sont là.
Ma main a couper que nulle part dans la doc de Gnome3 on ne parle d'OSS,
sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y connais pas !
Bah pas tant que ça, quelle application purement Gnome à besoin de
pulseaudio pour fonctionner convenablement ?
Quand je veux installer Gnome3, je veux installer _que_ Gnome3 et ses
dépendances pas autre chose.
Si le choix de debian ne te plaît pas, ce qui est ton droit le plus
strict, tu peux construire ton paquet depuis les sources.
La
dépendance de gnome3 n'est pas plus aberrante que ça. Si tu veux un
truc plus léger, il y a une foultitude et demi d'autres
gestionnaires de bureau.
Si Gnome3 a besoin de pulseaudio ça doit être écrit quelque part dans la
doc de Gnome. Dans le cas contraire je déduit que la version Debian de
Gnome à besoin de puleaudio quand la version upstream s'en passe
allègrement.
Essaie de compiler gnome3 depuis les sources.
Le Tue, 06 Mar 2012 06:30:48 +1100,
Doug713705 <doug.letough@free.fr> écrivait :
Houlà, c'est trop vieux pour que je me souvienne des détails, ça date de
RedHat 7.1 (ou peut-être 7.3), c'est dire !
Je parle d'une distribution fiable, pas d'un truc comme ça. La
dernière Redhat que j'avais en production, je l'ai viré à la suite
d'un foirage total d'une mise à jour (7.3 vers 8.0) et seule ma
flemme m'avait dissuadé de ne pas la virer au passage de 6.2 vers
7.0.
La seule chose dont je me souviens c'est que je me suis retrouvé avec un
répertoire lost+found garni de tonnes de fichiers avec des jolis
numéros en guise de nom et que je n'ai pas réussi à en récupérer la
moitié (de mémoire le processur de récupération était plus ou moins
manuel, donc trop long à mettre en oeuvre pour des données sans réèlles
valeurs).
Depuis, je n'ai jamais retouché à ext !
À l'époque, c'était ext2, pas ext3. Pour avoir un support ext3? il
fallait parcher le noyau soi-même comme un grand. ext2 n'était pas
journalisé (et les options de montage de ext3 par défaut chez redhat
sont dangereuses, au moins quand j'avais regardé ce point).
En ce qui concerne ext4, à chaque fois que je lis un article
sur ce truc, je ne me peux pas m'empécher de conclure que c'est une
bouse pire que ces prédecesseurs.
Ext4 fonctionne très bien.
De ce que j'en ai lu, niveau performance cela n'a pas l'air d'être tout
à fait ça.
Ce que je demande à un fs, ce n'est pas d'être rapide, c'est d'avoir
des performances acceptables en lecture et en écriture sur n'importe
quelle taille de fichiers. Et à chaque fois que j'ai regardé, ext3
ne se débrouillait pas si mal que ça. ext4 ne me pose pour l'instant
aucun problème. J'ai commencé à migrer des tours de disque en raid5
et 6 et je dois dire que ça ronronne.
Ah moi ce que je demande en plus de la fiabilité c'est les performances
les meilleures pour le type de fichiers que j'utilise le plus, c'est à
dire comme tout le monde, en grande majorité des fichiers de petites
tailles.
Rien de pire qu'un FS qui rame pour lire les n fichiers de
configuration et d'initialisation au démarage de tel ou tel
service/application.
Franchement, si tu vois la différence entre un daemon qui démarre
sur du ReiserFS et la même chose en XFS ou ext3/4, tu es doué. Je
veux bien discuter pour un serveur de mail ou de news, mais pour un
système standard, c'est de la sodomie de diptère sans vaseline.
Parce que bon, pour une machine de bureau ou un portable, c'est pas tous
les jours que je vais manipuler une archive de 42 To ou même déplacer
(changer de partition) un ou des films de quelques Go.
Par contre manipuler des fichiers de quelques Ko à quelques Mo, ça oui,
tous les jours.
Mais pas assez pour voir une réelle différence entre un ext3 et
autre chose.
Ben voilà, un truc foireux et non nécessaire qui s'invite tout seul par
dépendance, c'est typiquement le truc que je reproche à Debian et toutes
les distributions qui tentent de jouer aux devinettes quant aux
dependances.
Le truc s'invite parce que tu as un soft quelque part qui demande
une émulation OSS. Et l'outil d'installation, s'il est configuré
correctement, te laisse le choix entre tout ce qui te fournit cette
émulation (c'est un choix qui est fait lors de l'installation).
C'est toujours mieux que la gestion des dépendances de la slack.
Il me semble qu'Alsa a tout le necessaire pour gérer ça et je suis tout
à fait sûr d'avoir demandé à ce qu'il soit seul à prendre en charge
l'émulation OSS.
Le problème n'est pas l'émulation d'OSS par Alsa, mais le truc
intermédiaire entre ton gestionnaire de bureau et les applications
(histoire qu'une application ne verrouille pas /dev/dsp par
exemple).
Qué ? Sur ma présente Slackware j'utilise simultanément mpd, mplayer,
skype et aplay sans problème ! Aucun ne vérrouille quoi que ce soit
(enfin si mais une fois configuré alsa _seul_ s'en débrouille très bien)
Euh, non. Il faut jackd/pulseaudio/whatever pour que ça marche
correctement dans tous les cas.
Pour cela, il y a un certain nombre de daemons de esound à
pulseaudio en passant par une foultitude d'autres.
Tous plus inutiles les uns que les autres.
Aucun d'eux n'est installés chez moi.
Pas 'inutiles'. Disons simplement que tu n'es jamais tombé sur un
cas un peu particulier. Par ailleurs, tous ces daemons permettent de
gérer les droits sur les devices. Ça peut être très pratique en cas
de partage d'une machine entre plusieurs utilisateurs.
Je n'ai _jamais_ eu besoin de pulseaudio et pourtant j'en fait du bruit
avec tout un tas de programmes pour en générer.
Pulseaudio n'est pas là pour faire du bruit, il est là pour gérer
l'accès au machin qui fait du bruit.
Oui et je n'ai jamais eu besoin de lui pour faire du bruit avec tous les
machins en même temps.
Au pire JACK peut être utile mais pulseaudio, je ne vois pas.
Il y a des gens qui n'aiment pas jackd. Pour tout un tas de bonnes
ou de mauvaises raisons.
Par ailleurs pulseaudio s'est invité lors de l'installation de Gnome3,
un truc sensé être moderne.
Comment un truc moderne peut-il encore avoir besoin d'une émulation OSS
?
Au hasard, /dev/dsp ?
Ben /dev/dsp en lui même ne réclame rien.
C'est quoi ces applications qui réclament encore un truc obsolète 1à ans
après que tout le monde ait dit qu'il fallait arréter de l'utiliser ?
Je n'ai pas de liste sous la main. Mais de toute façon, même avec
les applications qui utilisent nativement alsa, les mêmes problèmes
sont là.
Ma main a couper que nulle part dans la doc de Gnome3 on ne parle d'OSS,
sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y connais pas !
Bah pas tant que ça, quelle application purement Gnome à besoin de
pulseaudio pour fonctionner convenablement ?
Quand je veux installer Gnome3, je veux installer _que_ Gnome3 et ses
dépendances pas autre chose.
Si le choix de debian ne te plaît pas, ce qui est ton droit le plus
strict, tu peux construire ton paquet depuis les sources.
La
dépendance de gnome3 n'est pas plus aberrante que ça. Si tu veux un
truc plus léger, il y a une foultitude et demi d'autres
gestionnaires de bureau.
Si Gnome3 a besoin de pulseaudio ça doit être écrit quelque part dans la
doc de Gnome. Dans le cas contraire je déduit que la version Debian de
Gnome à besoin de puleaudio quand la version upstream s'en passe
allègrement.
Essaie de compiler gnome3 depuis les sources.
Le Tue, 06 Mar 2012 06:30:48 +1100,
Doug713705 écrivait :
Houlà, c'est trop vieux pour que je me souvienne des détails, ça date de
RedHat 7.1 (ou peut-être 7.3), c'est dire !
Je parle d'une distribution fiable, pas d'un truc comme ça. La
dernière Redhat que j'avais en production, je l'ai viré à la suite
d'un foirage total d'une mise à jour (7.3 vers 8.0) et seule ma
flemme m'avait dissuadé de ne pas la virer au passage de 6.2 vers
7.0.
La seule chose dont je me souviens c'est que je me suis retrouvé avec un
répertoire lost+found garni de tonnes de fichiers avec des jolis
numéros en guise de nom et que je n'ai pas réussi à en récupérer la
moitié (de mémoire le processur de récupération était plus ou moins
manuel, donc trop long à mettre en oeuvre pour des données sans réèlles
valeurs).
Depuis, je n'ai jamais retouché à ext !
À l'époque, c'était ext2, pas ext3. Pour avoir un support ext3? il
fallait parcher le noyau soi-même comme un grand. ext2 n'était pas
journalisé (et les options de montage de ext3 par défaut chez redhat
sont dangereuses, au moins quand j'avais regardé ce point).
En ce qui concerne ext4, à chaque fois que je lis un article
sur ce truc, je ne me peux pas m'empécher de conclure que c'est une
bouse pire que ces prédecesseurs.
Ext4 fonctionne très bien.
De ce que j'en ai lu, niveau performance cela n'a pas l'air d'être tout
à fait ça.
Ce que je demande à un fs, ce n'est pas d'être rapide, c'est d'avoir
des performances acceptables en lecture et en écriture sur n'importe
quelle taille de fichiers. Et à chaque fois que j'ai regardé, ext3
ne se débrouillait pas si mal que ça. ext4 ne me pose pour l'instant
aucun problème. J'ai commencé à migrer des tours de disque en raid5
et 6 et je dois dire que ça ronronne.
Ah moi ce que je demande en plus de la fiabilité c'est les performances
les meilleures pour le type de fichiers que j'utilise le plus, c'est à
dire comme tout le monde, en grande majorité des fichiers de petites
tailles.
Rien de pire qu'un FS qui rame pour lire les n fichiers de
configuration et d'initialisation au démarage de tel ou tel
service/application.
Franchement, si tu vois la différence entre un daemon qui démarre
sur du ReiserFS et la même chose en XFS ou ext3/4, tu es doué. Je
veux bien discuter pour un serveur de mail ou de news, mais pour un
système standard, c'est de la sodomie de diptère sans vaseline.
Parce que bon, pour une machine de bureau ou un portable, c'est pas tous
les jours que je vais manipuler une archive de 42 To ou même déplacer
(changer de partition) un ou des films de quelques Go.
Par contre manipuler des fichiers de quelques Ko à quelques Mo, ça oui,
tous les jours.
Mais pas assez pour voir une réelle différence entre un ext3 et
autre chose.
Ben voilà, un truc foireux et non nécessaire qui s'invite tout seul par
dépendance, c'est typiquement le truc que je reproche à Debian et toutes
les distributions qui tentent de jouer aux devinettes quant aux
dependances.
Le truc s'invite parce que tu as un soft quelque part qui demande
une émulation OSS. Et l'outil d'installation, s'il est configuré
correctement, te laisse le choix entre tout ce qui te fournit cette
émulation (c'est un choix qui est fait lors de l'installation).
C'est toujours mieux que la gestion des dépendances de la slack.
Il me semble qu'Alsa a tout le necessaire pour gérer ça et je suis tout
à fait sûr d'avoir demandé à ce qu'il soit seul à prendre en charge
l'émulation OSS.
Le problème n'est pas l'émulation d'OSS par Alsa, mais le truc
intermédiaire entre ton gestionnaire de bureau et les applications
(histoire qu'une application ne verrouille pas /dev/dsp par
exemple).
Qué ? Sur ma présente Slackware j'utilise simultanément mpd, mplayer,
skype et aplay sans problème ! Aucun ne vérrouille quoi que ce soit
(enfin si mais une fois configuré alsa _seul_ s'en débrouille très bien)
Euh, non. Il faut jackd/pulseaudio/whatever pour que ça marche
correctement dans tous les cas.
Pour cela, il y a un certain nombre de daemons de esound à
pulseaudio en passant par une foultitude d'autres.
Tous plus inutiles les uns que les autres.
Aucun d'eux n'est installés chez moi.
Pas 'inutiles'. Disons simplement que tu n'es jamais tombé sur un
cas un peu particulier. Par ailleurs, tous ces daemons permettent de
gérer les droits sur les devices. Ça peut être très pratique en cas
de partage d'une machine entre plusieurs utilisateurs.
Je n'ai _jamais_ eu besoin de pulseaudio et pourtant j'en fait du bruit
avec tout un tas de programmes pour en générer.
Pulseaudio n'est pas là pour faire du bruit, il est là pour gérer
l'accès au machin qui fait du bruit.
Oui et je n'ai jamais eu besoin de lui pour faire du bruit avec tous les
machins en même temps.
Au pire JACK peut être utile mais pulseaudio, je ne vois pas.
Il y a des gens qui n'aiment pas jackd. Pour tout un tas de bonnes
ou de mauvaises raisons.
Par ailleurs pulseaudio s'est invité lors de l'installation de Gnome3,
un truc sensé être moderne.
Comment un truc moderne peut-il encore avoir besoin d'une émulation OSS
?
Au hasard, /dev/dsp ?
Ben /dev/dsp en lui même ne réclame rien.
C'est quoi ces applications qui réclament encore un truc obsolète 1à ans
après que tout le monde ait dit qu'il fallait arréter de l'utiliser ?
Je n'ai pas de liste sous la main. Mais de toute façon, même avec
les applications qui utilisent nativement alsa, les mêmes problèmes
sont là.
Ma main a couper que nulle part dans la doc de Gnome3 on ne parle d'OSS,
sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y connais pas !
Bah pas tant que ça, quelle application purement Gnome à besoin de
pulseaudio pour fonctionner convenablement ?
Quand je veux installer Gnome3, je veux installer _que_ Gnome3 et ses
dépendances pas autre chose.
Si le choix de debian ne te plaît pas, ce qui est ton droit le plus
strict, tu peux construire ton paquet depuis les sources.
La
dépendance de gnome3 n'est pas plus aberrante que ça. Si tu veux un
truc plus léger, il y a une foultitude et demi d'autres
gestionnaires de bureau.
Si Gnome3 a besoin de pulseaudio ça doit être écrit quelque part dans la
doc de Gnome. Dans le cas contraire je déduit que la version Debian de
Gnome à besoin de puleaudio quand la version upstream s'en passe
allègrement.
Essaie de compiler gnome3 depuis les sources.
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
Bah, s'il s'est trompé il pourra toujours prétendre que sa main était
une dépendance optionnelle inutile et que de toutes façons il ne
voulait pas s'en encombrer ;) .
:-D
N'empèche que ma main est sur le billot et que j'attends toujours la
moindre référence à OSS ou pulseaudio dans la doc de Gnome.
Les applications de gnome demandent au choix : jackd, esound,
pulseaudio (j'en oublie certainement). Le choix actuel de debian,
c'est pulseaudio (et il y a des raisons à cela). Tu peux
parfaitement compiler un gnome3 upstream sans l'un de ces outils. Il
y a simplement des choses qui ne fonctionneront pas.
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
Bah, s'il s'est trompé il pourra toujours prétendre que sa main était
une dépendance optionnelle inutile et que de toutes façons il ne
voulait pas s'en encombrer ;) .
:-D
N'empèche que ma main est sur le billot et que j'attends toujours la
moindre référence à OSS ou pulseaudio dans la doc de Gnome.
Les applications de gnome demandent au choix : jackd, esound,
pulseaudio (j'en oublie certainement). Le choix actuel de debian,
c'est pulseaudio (et il y a des raisons à cela). Tu peux
parfaitement compiler un gnome3 upstream sans l'un de ces outils. Il
y a simplement des choses qui ne fonctionneront pas.
> Ma main a couper que nulle part dans la doc de Gnome3 on ne parle
> d'OSS, sauf dans la version Debian, bien sûr.
Ça, c'est de la mauvaise foi caractérisée ou je ne m'y
connais pas !
Bah, s'il s'est trompé il pourra toujours prétendre que sa main était
une dépendance optionnelle inutile et que de toutes façons il ne
voulait pas s'en encombrer ;) .
:-D
N'empèche que ma main est sur le billot et que j'attends toujours la
moindre référence à OSS ou pulseaudio dans la doc de Gnome.
Les applications de gnome demandent au choix : jackd, esound,
pulseaudio (j'en oublie certainement). Le choix actuel de debian,
c'est pulseaudio (et il y a des raisons à cela). Tu peux
parfaitement compiler un gnome3 upstream sans l'un de ces outils. Il
y a simplement des choses qui ne fonctionneront pas.