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é
Bien qu'il existe une compatibilite OSS, de plus en plus de logiciels sont, de nos jours, ALSA only, ce qui implique un effort de portage supplementaire pour les autres OS.
est-ce a dire que la couche de compatibilite OSS que l'on trouve dans ALSA va disparaitre ?
Gni ? C'est au dev de l'application de faire en sorte de proposer les deux (OSS et ALSA). La plupart du temps il suffit de proposer un patch pour une telle alternative, mais parfois l'on tombe sur un type bouche pour qui seul Linux a le droit de faire tourner son soft.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2010-02-01, debug this fifo wrote:
Bruno Ducrot wrote:
Bien qu'il existe une compatibilite OSS, de plus en plus de logiciels sont,
de nos jours, ALSA only, ce qui implique un effort de portage supplementaire
pour les autres OS.
est-ce a dire que la couche de compatibilite OSS que l'on trouve
dans ALSA va disparaitre ?
Gni ? C'est au dev de l'application de faire en sorte de proposer les
deux (OSS et ALSA). La plupart du temps il suffit de proposer un
patch pour une telle alternative, mais parfois l'on tombe sur un type
bouche pour qui seul Linux a le droit de faire tourner son soft.
A plus,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bien qu'il existe une compatibilite OSS, de plus en plus de logiciels sont, de nos jours, ALSA only, ce qui implique un effort de portage supplementaire pour les autres OS.
est-ce a dire que la couche de compatibilite OSS que l'on trouve dans ALSA va disparaitre ?
Gni ? C'est au dev de l'application de faire en sorte de proposer les deux (OSS et ALSA). La plupart du temps il suffit de proposer un patch pour une telle alternative, mais parfois l'on tombe sur un type bouche pour qui seul Linux a le droit de faire tourner son soft.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Nicolas George
Bruno Ducrot , dans le message <4b680010$0$17497$, a écrit :
OSS lui-meme, franchement, je n'en ai aucune idee. Ca peut etre une grosse daube sous Linux, et peut-etre qu'il est bien de remplacer par un autre systeme mieux concu. Mais une autre alternative aurait ete de stabiliser, ou bien de proposer des extensions a OSS, ce qui aurait arranger tout le monde.
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.
Bruno Ducrot , dans le message
<4b680010$0$17497$ba4acef3@news.orange.fr>, a écrit :
OSS lui-meme, franchement, je n'en ai aucune idee. Ca peut
etre une grosse daube sous Linux, et peut-etre qu'il est bien
de remplacer par un autre systeme mieux concu. Mais une autre
alternative aurait ete de stabiliser, ou bien de proposer des
extensions a OSS, ce qui aurait arranger tout le monde.
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.
Bruno Ducrot , dans le message <4b680010$0$17497$, a écrit :
OSS lui-meme, franchement, je n'en ai aucune idee. Ca peut etre une grosse daube sous Linux, et peut-etre qu'il est bien de remplacer par un autre systeme mieux concu. Mais une autre alternative aurait ete de stabiliser, ou bien de proposer des extensions a OSS, ce qui aurait arranger tout le monde.
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.
Bruno Ducrot
On 2010-01-29, Nicolas George wrote:
Bruno Ducrot , dans le message <4b62ca0a$0$17481$, a écrit :
Pourquoi s'aligner ? Il y a deja mieux depuis des lustres avec kevent.
kevent fonctionne à l'envers de la méthode Unix standard, ce qui le rend difficile à intégrer dans des codes portables.
J'ai beau lire cette phrase un bon million de fois, je ne comprends pas ce que tu veux dire exactement. Plus precisemment, en quoi kevent fonctionne a l'envers de la methode Unix standard ? En fait, je n'ai pas ta definition de la methode Unix standard, ce qui explique que je ne comprends rien.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2010-01-29, Nicolas George wrote:
Bruno Ducrot , dans le message
<4b62ca0a$0$17481$ba4acef3@news.orange.fr>, a écrit :
Pourquoi s'aligner ? Il y a deja mieux depuis des lustres avec kevent.
kevent fonctionne à l'envers de la méthode Unix standard, ce qui le rend
difficile à intégrer dans des codes portables.
J'ai beau lire cette phrase un bon million de fois, je ne comprends pas
ce que tu veux dire exactement. Plus precisemment, en quoi kevent
fonctionne a l'envers de la methode Unix standard ? En fait, je n'ai
pas ta definition de la methode Unix standard, ce qui explique que je ne
comprends rien.
A plus,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bruno Ducrot , dans le message <4b62ca0a$0$17481$, a écrit :
Pourquoi s'aligner ? Il y a deja mieux depuis des lustres avec kevent.
kevent fonctionne à l'envers de la méthode Unix standard, ce qui le rend difficile à intégrer dans des codes portables.
J'ai beau lire cette phrase un bon million de fois, je ne comprends pas ce que tu veux dire exactement. Plus precisemment, en quoi kevent fonctionne a l'envers de la methode Unix standard ? En fait, je n'ai pas ta definition de la methode Unix standard, ce qui explique que je ne comprends rien.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Nicolas George
Bruno Ducrot , dans le message <4b682b3b$0$969$, a écrit :
Plus precisemment, en quoi kevent fonctionne a l'envers de la methode Unix standard ?
On utilise kevent pour manipuler des file descriptors. La doctrine Unix standard, c'est que tout peut se manipuler comme un file descriptor, et donc s'intégrer à une boucle poll habituelle.
Bruno Ducrot , dans le message <4b682b3b$0$969$ba4acef3@news.orange.fr>,
a écrit :
Plus precisemment, en quoi kevent
fonctionne a l'envers de la methode Unix standard ?
On utilise kevent pour manipuler des file descriptors. La doctrine Unix
standard, c'est que tout peut se manipuler comme un file descriptor, et donc
s'intégrer à une boucle poll habituelle.
Bruno Ducrot , dans le message <4b682b3b$0$969$, a écrit :
Plus precisemment, en quoi kevent fonctionne a l'envers de la methode Unix standard ?
On utilise kevent pour manipuler des file descriptors. La doctrine Unix standard, c'est que tout peut se manipuler comme un file descriptor, et donc s'intégrer à une boucle poll habituelle.
Bruno Ducrot
On 2010-02-02, Nicolas George wrote:
Bruno Ducrot , dans le message <4b680010$0$17497$, a écrit :
OSS lui-meme, franchement, je n'en ai aucune idee. Ca peut etre une grosse daube sous Linux, et peut-etre qu'il est bien de remplacer par un autre systeme mieux concu. Mais une autre alternative aurait ete de stabiliser, ou bien de proposer des extensions a OSS, ce qui aurait arranger tout le monde.
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.
Je ne connais pas assez ALSA. Si je comprends bien, il n'y a pas de device associe a une carte son ? C'est tout, sauf unixien comme approche.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2010-02-02, Nicolas George wrote:
Bruno Ducrot , dans le message
<4b680010$0$17497$ba4acef3@news.orange.fr>, a écrit :
OSS lui-meme, franchement, je n'en ai aucune idee. Ca peut
etre une grosse daube sous Linux, et peut-etre qu'il est bien
de remplacer par un autre systeme mieux concu. Mais une autre
alternative aurait ete de stabiliser, ou bien de proposer des
extensions a OSS, ce qui aurait arranger tout le monde.
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.
Je ne connais pas assez ALSA. Si je comprends bien, il n'y a pas de
device associe a une carte son ? C'est tout, sauf unixien comme
approche.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bruno Ducrot , dans le message <4b680010$0$17497$, a écrit :
OSS lui-meme, franchement, je n'en ai aucune idee. Ca peut etre une grosse daube sous Linux, et peut-etre qu'il est bien de remplacer par un autre systeme mieux concu. Mais une autre alternative aurait ete de stabiliser, ou bien de proposer des extensions a OSS, ce qui aurait arranger tout le monde.
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.
Je ne connais pas assez ALSA. Si je comprends bien, il n'y a pas de device associe a une carte son ? C'est tout, sauf unixien comme approche.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Nicolas George
Bruno Ducrot , dans le message <4b682f9c$0$17488$, a écrit :
Je ne connais pas assez ALSA. Si je comprends bien, il n'y a pas de device associe a une carte son ?
Il y a un device, évidemment, mais on n'est pas censé s'en servir directement, seulement par le biais d'une bibliothèque qui fournit toutes les fonctionnalités qui manquent à OSS et qu'on ne veut en aucun cas voir implémentées dans le noyau.
Bruno Ducrot , dans le message
<4b682f9c$0$17488$ba4acef3@news.orange.fr>, a écrit :
Je ne connais pas assez ALSA. Si je comprends bien, il n'y a pas de
device associe a une carte son ?
Il y a un device, évidemment, mais on n'est pas censé s'en servir
directement, seulement par le biais d'une bibliothèque qui fournit toutes
les fonctionnalités qui manquent à OSS et qu'on ne veut en aucun cas voir
implémentées dans le noyau.
Bruno Ducrot , dans le message <4b682f9c$0$17488$, a écrit :
Je ne connais pas assez ALSA. Si je comprends bien, il n'y a pas de device associe a une carte son ?
Il y a un device, évidemment, mais on n'est pas censé s'en servir directement, seulement par le biais d'une bibliothèque qui fournit toutes les fonctionnalités qui manquent à OSS et qu'on ne veut en aucun cas voir implémentées dans le noyau.
Bruno Ducrot
On 2010-02-02, Nicolas George wrote:
Bruno Ducrot , dans le message <4b682b3b$0$969$, a écrit :
Plus precisemment, en quoi kevent fonctionne a l'envers de la methode Unix standard ?
On utilise kevent pour manipuler des file descriptors. La doctrine Unix standard, c'est que tout peut se manipuler comme un file descriptor, et donc s'intégrer à une boucle poll habituelle.
Pourtant, kqueue() renvoie un file descriptor, que l'on peut integrer a une boucle poll si l'on veut. Un kevent() sera cependant necessaire pour obtenir l'info desiree au lieu d'un classique read (comme pour signalfd).
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2010-02-02, Nicolas George wrote:
Bruno Ducrot , dans le message <4b682b3b$0$969$ba4acef3@news.orange.fr>,
a écrit :
Plus precisemment, en quoi kevent
fonctionne a l'envers de la methode Unix standard ?
On utilise kevent pour manipuler des file descriptors. La doctrine Unix
standard, c'est que tout peut se manipuler comme un file descriptor, et donc
s'intégrer à une boucle poll habituelle.
Pourtant, kqueue() renvoie un file descriptor, que l'on peut integrer a
une boucle poll si l'on veut. Un kevent() sera cependant necessaire pour
obtenir l'info desiree au lieu d'un classique read (comme pour signalfd).
A plus,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bruno Ducrot , dans le message <4b682b3b$0$969$, a écrit :
Plus precisemment, en quoi kevent fonctionne a l'envers de la methode Unix standard ?
On utilise kevent pour manipuler des file descriptors. La doctrine Unix standard, c'est que tout peut se manipuler comme un file descriptor, et donc s'intégrer à une boucle poll habituelle.
Pourtant, kqueue() renvoie un file descriptor, que l'on peut integrer a une boucle poll si l'on veut. Un kevent() sera cependant necessaire pour obtenir l'info desiree au lieu d'un classique read (comme pour signalfd).
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Nicolas George
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.
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.
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.
Bruno Ducrot
On 2010-02-02, Nicolas George wrote:
Bruno Ducrot , dans le message <4b682f9c$0$17488$, a écrit :
Je ne connais pas assez ALSA. Si je comprends bien, il n'y a pas de device associe a une carte son ?
Il y a un device, évidemment,
Ok. J'ai eu peur, un moment, que ca ne passe par un sous-repertoire de /proc.
mais on n'est pas censé s'en servir directement, seulement par le biais d'une bibliothèque
La bibliotheque intrege l'open() necessaire sur un device.
L'application accede donc directement a un device, tout comme pour OSS. Sauf que ALSA c'est plus propre parce que c'est cachee par un wrapper.
qui fournit toutes les fonctionnalités qui manquent à OSS et qu'on ne veut en aucun cas voir implémentées dans le noyau.
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 ?
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.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2010-02-02, Nicolas George wrote:
Bruno Ducrot , dans le message
<4b682f9c$0$17488$ba4acef3@news.orange.fr>, a écrit :
Je ne connais pas assez ALSA. Si je comprends bien, il n'y a pas de
device associe a une carte son ?
Il y a un device, évidemment,
Ok. J'ai eu peur, un moment, que ca ne passe par un sous-repertoire de
/proc.
mais on n'est pas censé s'en servir
directement, seulement par le biais d'une bibliothèque
La bibliotheque intrege l'open() necessaire sur un device.
L'application accede donc directement a un device, tout comme
pour OSS. Sauf que ALSA c'est plus propre parce que c'est
cachee par un wrapper.
qui fournit toutes
les fonctionnalités qui manquent à OSS et qu'on ne veut en aucun cas voir
implémentées dans le noyau.
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 ?
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.
A plus,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bruno Ducrot , dans le message <4b682f9c$0$17488$, a écrit :
Je ne connais pas assez ALSA. Si je comprends bien, il n'y a pas de device associe a une carte son ?
Il y a un device, évidemment,
Ok. J'ai eu peur, un moment, que ca ne passe par un sous-repertoire de /proc.
mais on n'est pas censé s'en servir directement, seulement par le biais d'une bibliothèque
La bibliotheque intrege l'open() necessaire sur un device.
L'application accede donc directement a un device, tout comme pour OSS. Sauf que ALSA c'est plus propre parce que c'est cachee par un wrapper.
qui fournit toutes les fonctionnalités qui manquent à OSS et qu'on ne veut en aucun cas voir implémentées dans le noyau.
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 ?
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.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Bruno Ducrot
On 2010-02-02, Nicolas George 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.
Possible. Je dois avouer que ce n'est pas tres explicite dans la doc, compare a la page man de signalfs.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2010-02-02, Nicolas George 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.
Possible. Je dois avouer que ce n'est pas tres explicite dans la doc,
compare a la page man de signalfs.
A plus,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
