Cela fais la cinquième fois que audacity se plante ce matin.
On peut difficilement dire que fedora est stable, 2 release par an et
toujours des versions beta.
Linux est mal parti, fedora instable, debian en retard, trop de version
incompatible, des packages trop différent, gnome, kde...
Impossible ou très difficile a installer et a maintenir sur 500 pc par
exemple.
A++
André
OSS est basé sur une erreur de conception fondamentale : celle de compter sur un accès direct des applications aux devices exposés par le noyau. Proposer des extensions dans ces conditions est tout simplement impossible.
Pourquoi pas (c'est une question pas un troll) ? FreeBSD utilisent des devices clonés pour le son. Ici on peut depuis longtemps mixer différentes sources sans aucun soucis, jouer du son sur plusieurs canaux et tout même si le matériel ne le supporte pas. Et depuis FreeBSD 8.0 il y a un equalizer.
Sans avoir besoin d'un obscur démon comme pulse audio (toujours pas compris à quoi ça peut bien servir).
C'est fait par le noyau et alors ?
Nicolas George :
OSS est basé sur une erreur de conception fondamentale : celle de compter
sur un accès direct des applications aux devices exposés par le noyau.
Proposer des extensions dans ces conditions est tout simplement impossible.
Pourquoi pas (c'est une question pas un troll) ?
FreeBSD utilisent des devices clonés pour le son. Ici on peut depuis
longtemps mixer différentes sources sans aucun soucis, jouer du son
sur plusieurs canaux et tout même si le matériel ne le supporte pas.
Et depuis FreeBSD 8.0 il y a un equalizer.
Sans avoir besoin d'un obscur démon comme pulse audio (toujours pas
compris à quoi ça peut bien servir).
OSS est basé sur une erreur de conception fondamentale : celle de compter sur un accès direct des applications aux devices exposés par le noyau. Proposer des extensions dans ces conditions est tout simplement impossible.
Pourquoi pas (c'est une question pas un troll) ? FreeBSD utilisent des devices clonés pour le son. Ici on peut depuis longtemps mixer différentes sources sans aucun soucis, jouer du son sur plusieurs canaux et tout même si le matériel ne le supporte pas. Et depuis FreeBSD 8.0 il y a un equalizer.
Sans avoir besoin d'un obscur démon comme pulse audio (toujours pas compris à quoi ça peut bien servir).
C'est fait par le noyau et alors ?
talon
Nicolas George <nicolas$ wrote:
Bruno Ducrot , dans le message <4b683885$0$952$, a écrit : > Pourtant, kqueue() renvoie un file descriptor
Alors je retire ce point, mais j'ajoute que la doc est mal écrite.
Ca au moins, c'est vrai. http://wiki.netbsd.se/kqueue_tutorial http://blog.julipedia.org/2004/10/example-of-kqueue.html ou en français http://www.unixgarden.com/index.php/administration-reseau/kqueuekevent-efficient-convivial-polling
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
Bruno Ducrot , dans le message <4b683885$0$952$ba4acef3@news.orange.fr>,
a écrit :
> Pourtant, kqueue() renvoie un file descriptor
Alors je retire ce point, mais j'ajoute que la doc est mal écrite.
Ca au moins, c'est vrai.
http://wiki.netbsd.se/kqueue_tutorial
http://blog.julipedia.org/2004/10/example-of-kqueue.html
ou en français
http://www.unixgarden.com/index.php/administration-reseau/kqueuekevent-efficient-convivial-polling
Bruno Ducrot , dans le message <4b683885$0$952$, a écrit : > Pourtant, kqueue() renvoie un file descriptor
Alors je retire ce point, mais j'ajoute que la doc est mal écrite.
Ca au moins, c'est vrai. http://wiki.netbsd.se/kqueue_tutorial http://blog.julipedia.org/2004/10/example-of-kqueue.html ou en français http://www.unixgarden.com/index.php/administration-reseau/kqueuekevent-efficient-convivial-polling
--
Michel TALON
Nicolas George
Bruno Ducrot , dans le message <4b683c4e$0$938$, a écrit :
L'application accede donc directement a un device
Dans le binaire chargé en mémoire oui. Dans le code source, qui est ce qui importe, non.
Possible, et qu'est-ce qui empeche de fabriquer une bibliotheque cachant tous ces open() sur des devices que l'on ne veut pas voir, et utilisant exclusivement OSS, tout en fournissant les fonctionnalites manquantes en user space ?
Rien ne l'empêche. C'est l'avantage d'une bibliothèque : on peut changer le comportement interne sans rien casser. Mais si on fait ça, on se retrouve avec des crétins qui croient savoir mieux faire que les autres et accèdent directement aux device, et on perd tous les avantages d'avoir une bibliothèque.
Bon. Il faudrait que je regarde plus en detail la bibliotheque fournit par ALSA, parce que, pour l'instant, je ne vois pas l'interet.
Parmi les quelques fonctionnalités qui sont présentes dans ALSA, du fait de sa structure en bibliothèque, et qui sont à ma connaissance absente d'OSS : mixage logiciel basse latence sans serveur, rééchantillonage, configuration avancée programmable, capture des flux joués, etc.
Bruno Ducrot , dans le message <4b683c4e$0$938$ba4acef3@news.orange.fr>,
a écrit :
L'application accede donc directement a un device
Dans le binaire chargé en mémoire oui. Dans le code source, qui est ce qui
importe, non.
Possible, et qu'est-ce qui empeche de fabriquer une bibliotheque cachant
tous ces open() sur des devices que l'on ne veut pas voir, et utilisant
exclusivement OSS, tout en fournissant les fonctionnalites manquantes en
user space ?
Rien ne l'empêche. C'est l'avantage d'une bibliothèque : on peut changer le
comportement interne sans rien casser. Mais si on fait ça, on se retrouve
avec des crétins qui croient savoir mieux faire que les autres et accèdent
directement aux device, et on perd tous les avantages d'avoir une
bibliothèque.
Bon. Il faudrait que je regarde plus en detail la bibliotheque fournit
par ALSA, parce que, pour l'instant, je ne vois pas l'interet.
Parmi les quelques fonctionnalités qui sont présentes dans ALSA, du fait de
sa structure en bibliothèque, et qui sont à ma connaissance absente d'OSS :
mixage logiciel basse latence sans serveur, rééchantillonage, configuration
avancée programmable, capture des flux joués, etc.
Bruno Ducrot , dans le message <4b683c4e$0$938$, a écrit :
L'application accede donc directement a un device
Dans le binaire chargé en mémoire oui. Dans le code source, qui est ce qui importe, non.
Possible, et qu'est-ce qui empeche de fabriquer une bibliotheque cachant tous ces open() sur des devices que l'on ne veut pas voir, et utilisant exclusivement OSS, tout en fournissant les fonctionnalites manquantes en user space ?
Rien ne l'empêche. C'est l'avantage d'une bibliothèque : on peut changer le comportement interne sans rien casser. Mais si on fait ça, on se retrouve avec des crétins qui croient savoir mieux faire que les autres et accèdent directement aux device, et on perd tous les avantages d'avoir une bibliothèque.
Bon. Il faudrait que je regarde plus en detail la bibliotheque fournit par ALSA, parce que, pour l'instant, je ne vois pas l'interet.
Parmi les quelques fonctionnalités qui sont présentes dans ALSA, du fait de sa structure en bibliothèque, et qui sont à ma connaissance absente d'OSS : mixage logiciel basse latence sans serveur, rééchantillonage, configuration avancée programmable, capture des flux joués, etc.
Nicolas George
Patrick Lamaizière , dans le message <hk9f42$2d4d$, a écrit :
C'est fait par le noyau et alors ?
Il faut croire. Ce qui est une horreur absolue.
Patrick Lamaizière , dans le message <hk9f42$2d4d$1@news.davenulle.org>,
a écrit :
debug this fifo , dans le message <hk9h75$gpj$, a écrit :
pourquoi ?
Parce qu'on ne met pas du code complexe et gourmand en puissance de calcul dans le noyau à moins d'en avoir absolument besoin. Le code dans le noyau est soumis à tout un tas de particularités (non-swappable, scheduling différent, absence de protection mémoire) qui font qu'il faut absolument éviter ce petit jeu. Et je ne parle même pas d'aller lire des fichiers de configuration chez l'utilisateur.
debug this fifo , dans le message <hk9h75$gpj$1@speranza.aioe.org>, a
écrit :
pourquoi ?
Parce qu'on ne met pas du code complexe et gourmand en puissance de calcul
dans le noyau à moins d'en avoir absolument besoin. Le code dans le noyau
est soumis à tout un tas de particularités (non-swappable, scheduling
différent, absence de protection mémoire) qui font qu'il faut absolument
éviter ce petit jeu. Et je ne parle même pas d'aller lire des fichiers de
configuration chez l'utilisateur.
debug this fifo , dans le message <hk9h75$gpj$, a écrit :
pourquoi ?
Parce qu'on ne met pas du code complexe et gourmand en puissance de calcul dans le noyau à moins d'en avoir absolument besoin. Le code dans le noyau est soumis à tout un tas de particularités (non-swappable, scheduling différent, absence de protection mémoire) qui font qu'il faut absolument éviter ce petit jeu. Et je ne parle même pas d'aller lire des fichiers de configuration chez l'utilisateur.
Patrick Lamaizière
Nicolas George :
C'est fait par le noyau et alors ?
Il faut croire. Ce qui est une horreur absolue.
C'est relatif, j'ai lu que faire du filtrage de chaîne comme le fait netfilter est aussi une horreur absolue.
Au moins ça permet d'écouter de la zique avec une charge de 10 sans que ça sourcille. J'en demande pas plus en fait. Pour ce qu'ai pu en voir lors de mes essais en jouant sur la qualité du feeder, la charge induite sur le système est faible voire négligeable.
Nicolas George :
C'est fait par le noyau et alors ?
Il faut croire. Ce qui est une horreur absolue.
C'est relatif, j'ai lu que faire du filtrage de chaîne comme le fait
netfilter est aussi une horreur absolue.
Au moins ça permet d'écouter de la zique avec une charge de 10 sans que
ça sourcille. J'en demande pas plus en fait. Pour ce qu'ai pu en voir
lors de mes essais en jouant sur la qualité du feeder, la charge
induite sur le système est faible voire négligeable.
C'est relatif, j'ai lu que faire du filtrage de chaîne comme le fait netfilter est aussi une horreur absolue.
Au moins ça permet d'écouter de la zique avec une charge de 10 sans que ça sourcille. J'en demande pas plus en fait. Pour ce qu'ai pu en voir lors de mes essais en jouant sur la qualité du feeder, la charge induite sur le système est faible voire négligeable.
debug this fifo
Nicolas George wrote:
Parce qu'on ne met pas du code complexe et gourmand en puissance de calcul dans le noyau à moins d'en avoir absolument besoin. Le code dans le noyau est soumis à tout un tas de particularités (non-swappable, scheduling différent, absence de protection mémoire) qui font qu'il faut absolument éviter ce petit jeu. Et je ne parle même pas d'aller lire des fichiers de configuration chez l'utilisateur.
donc l'avenir est aux microkernels genre minix/hurd.
Nicolas George wrote:
Parce qu'on ne met pas du code complexe et gourmand en puissance de calcul
dans le noyau à moins d'en avoir absolument besoin. Le code dans le noyau
est soumis à tout un tas de particularités (non-swappable, scheduling
différent, absence de protection mémoire) qui font qu'il faut absolument
éviter ce petit jeu. Et je ne parle même pas d'aller lire des fichiers de
configuration chez l'utilisateur.
donc l'avenir est aux microkernels genre minix/hurd.
Parce qu'on ne met pas du code complexe et gourmand en puissance de calcul dans le noyau à moins d'en avoir absolument besoin. Le code dans le noyau est soumis à tout un tas de particularités (non-swappable, scheduling différent, absence de protection mémoire) qui font qu'il faut absolument éviter ce petit jeu. Et je ne parle même pas d'aller lire des fichiers de configuration chez l'utilisateur.
donc l'avenir est aux microkernels genre minix/hurd.
Nicolas George
Patrick Lamaizière , dans le message <hk9hhb$2gl5$, a écrit :
Au moins ça permet d'écouter de la zique avec une charge de 10 sans que ça sourcille.
On peut avoir ça avec ALSA aussi, il suffit de régler la priorité relative entre ce qui joue de la musique et ce qui charge le système.
J'en demande pas plus en fait. Pour ce qu'ai pu en voir lors de mes essais en jouant sur la qualité du feeder, la charge induite sur le système est faible voire négligeable.
Encore heureux, avec un PC actuel. Mais tout n'est pas un PC actuel.
Patrick Lamaizière , dans le message <hk9hhb$2gl5$1@news.davenulle.org>,
a écrit :
Au moins ça permet d'écouter de la zique avec une charge de 10 sans que
ça sourcille.
On peut avoir ça avec ALSA aussi, il suffit de régler la priorité relative
entre ce qui joue de la musique et ce qui charge le système.
J'en demande pas plus en fait. Pour ce qu'ai pu en voir
lors de mes essais en jouant sur la qualité du feeder, la charge
induite sur le système est faible voire négligeable.
Encore heureux, avec un PC actuel. Mais tout n'est pas un PC actuel.
Patrick Lamaizière , dans le message <hk9hhb$2gl5$, a écrit :
Au moins ça permet d'écouter de la zique avec une charge de 10 sans que ça sourcille.
On peut avoir ça avec ALSA aussi, il suffit de régler la priorité relative entre ce qui joue de la musique et ce qui charge le système.
J'en demande pas plus en fait. Pour ce qu'ai pu en voir lors de mes essais en jouant sur la qualité du feeder, la charge induite sur le système est faible voire négligeable.
Encore heureux, avec un PC actuel. Mais tout n'est pas un PC actuel.
JKB
Le 02-02-2010, ? propos de Re: marre de fedora, debug this fifo ?crivait dans fr.comp.os.linux.debats :
Nicolas George wrote:
Parce qu'on ne met pas du code complexe et gourmand en puissance de calcul dans le noyau à moins d'en avoir absolument besoin. Le code dans le noyau est soumis à tout un tas de particularités (non-swappable, scheduling différent, absence de protection mémoire) qui font qu'il faut absolument éviter ce petit jeu. Et je ne parle même pas d'aller lire des fichiers de configuration chez l'utilisateur.
donc l'avenir est aux microkernels genre minix/hurd.
Certainement pas. Ils impliquent des changements de contextes trop nombreux. Regarde un peu la différence entre un linux natif et un mklinux...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 02-02-2010, ? propos de
Re: marre de fedora,
debug this fifo ?crivait dans fr.comp.os.linux.debats :
Nicolas George wrote:
Parce qu'on ne met pas du code complexe et gourmand en puissance de calcul
dans le noyau à moins d'en avoir absolument besoin. Le code dans le noyau
est soumis à tout un tas de particularités (non-swappable, scheduling
différent, absence de protection mémoire) qui font qu'il faut absolument
éviter ce petit jeu. Et je ne parle même pas d'aller lire des fichiers de
configuration chez l'utilisateur.
donc l'avenir est aux microkernels genre minix/hurd.
Certainement pas. Ils impliquent des changements de contextes trop
nombreux. Regarde un peu la différence entre un linux natif et un
mklinux...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 02-02-2010, ? propos de Re: marre de fedora, debug this fifo ?crivait dans fr.comp.os.linux.debats :
Nicolas George wrote:
Parce qu'on ne met pas du code complexe et gourmand en puissance de calcul dans le noyau à moins d'en avoir absolument besoin. Le code dans le noyau est soumis à tout un tas de particularités (non-swappable, scheduling différent, absence de protection mémoire) qui font qu'il faut absolument éviter ce petit jeu. Et je ne parle même pas d'aller lire des fichiers de configuration chez l'utilisateur.
donc l'avenir est aux microkernels genre minix/hurd.
Certainement pas. Ils impliquent des changements de contextes trop nombreux. Regarde un peu la différence entre un linux natif et un mklinux...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
