Ca veut pas dire grand chose ce que tu racontes la, tu sens fort le linuxien qui se rend compte que son systeme est pas parfait et fait donc diversion pour eviter la critique.
La situation de la stack sonore linux est un gros merdier ingerable, que ca te plaise ou non. Le simple fait d'avoir 3 API kernel est deja une aberration. Tout le monde sait tres bien pourquoi on en est arrive la, c'est pas trop le sujet en fait.
Surtout quand on compare a la concurrence qui a une api qui juste marche depuis 15 ans.
Ce qui me choque dans ce graphe, c'est pas les boites grises (frameworks haut niveau), c'est les boite de couleurs, et surtout le fait que chaque boite grise est connectee a chaque boite de couleur et a chaque autre boite grise.
Dans un monde ideal, t'aurais une box de couleur, autant de box grise que tu veux, les box grises connectee a la box de couleur et basta. Le fait d'etre oblige d'ecrire 25 couches de compatibilite avec le reste du monde denote d'un serieux probleme d'architectures, tu trouve pas? Et ca c'est pas de la modularite vu qu'il faut explicitement supporter tout le reste du monde sous peine d'avoir un truc qui pete qq part chez un utilisateur.
Et meme avec ca, ca a jamais vraiment marche a 100% non plus.
Les serveurs de sons n'ont pas entierement resolu le probleme vu que personne n'a jamais reussi a se mettre d'accord sur une api. Ce qu'ils ont surtout reussi a faire c'est transformer un probleme bas niveau en un probleme haut niveau de jungle d'API.
Surtout a la grande epoque ou tu te retrouve avec arts ET esd parce que telle appli supportait l'un et pas l'autre et inversement, oblige d'en tuer un pour relancer l'autre, et entre temps t'as machin qui a fait pouic pouic et qui squatte le canal OSS et du coup ton serveur de son se retrouve le bec dans l'eau a pas faire de son etc.
PulseAudio vient mettre de l'ordre la dedans, mais ca resoud surtout le probleme en tapant sur la table et en disant "bon les gars, on arrete les conneries et tout le monde utilise le meme serveur de son maintenant", vu que pulse audio doit toujours supporter alsa/oss et les 450 000 frameworks sonore.
Et ca a pris quoi, 10 ans pour en arriver la?
Certes, ya de l'activite, mais je suis pas sur que le resultat soit super brillant dans le domaine du son...
bon en même temps le graphe vient de blogs.adobe.com...
Ouais, ben en attendant je pense que la gars a une connaissance de la stack multimedia linux un peu plus approfondie que toi...
on teste des solutions, on récupère ce qui marche bien
C'est vrai pour pas mal d'aspect du development linux, mais en ce qui concerne le son, c'est surtout une grosse dose de NIH syndrom couple a une envie frenetique de tout peter pour un truc qui brille tous les 6 mois.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Cela dépend des cas...
Posté par pasScott pasForstall . En réponse au journal Linux ou POSIX ?. Évalué à 1.
La situation de la stack sonore linux est un gros merdier ingerable, que ca te plaise ou non. Le simple fait d'avoir 3 API kernel est deja une aberration. Tout le monde sait tres bien pourquoi on en est arrive la, c'est pas trop le sujet en fait.
Surtout quand on compare a la concurrence qui a une api qui juste marche depuis 15 ans.
Ce qui me choque dans ce graphe, c'est pas les boites grises (frameworks haut niveau), c'est les boite de couleurs, et surtout le fait que chaque boite grise est connectee a chaque boite de couleur et a chaque autre boite grise.
Dans un monde ideal, t'aurais une box de couleur, autant de box grise que tu veux, les box grises connectee a la box de couleur et basta. Le fait d'etre oblige d'ecrire 25 couches de compatibilite avec le reste du monde denote d'un serieux probleme d'architectures, tu trouve pas? Et ca c'est pas de la modularite vu qu'il faut explicitement supporter tout le reste du monde sous peine d'avoir un truc qui pete qq part chez un utilisateur.
Et meme avec ca, ca a jamais vraiment marche a 100% non plus.
Les serveurs de sons n'ont pas entierement resolu le probleme vu que personne n'a jamais reussi a se mettre d'accord sur une api. Ce qu'ils ont surtout reussi a faire c'est transformer un probleme bas niveau en un probleme haut niveau de jungle d'API.
Surtout a la grande epoque ou tu te retrouve avec arts ET esd parce que telle appli supportait l'un et pas l'autre et inversement, oblige d'en tuer un pour relancer l'autre, et entre temps t'as machin qui a fait pouic pouic et qui squatte le canal OSS et du coup ton serveur de son se retrouve le bec dans l'eau a pas faire de son etc.
PulseAudio vient mettre de l'ordre la dedans, mais ca resoud surtout le probleme en tapant sur la table et en disant "bon les gars, on arrete les conneries et tout le monde utilise le meme serveur de son maintenant", vu que pulse audio doit toujours supporter alsa/oss et les 450 000 frameworks sonore.
Et ca a pris quoi, 10 ans pour en arriver la?
Certes, ya de l'activite, mais je suis pas sur que le resultat soit super brillant dans le domaine du son...
bon en même temps le graphe vient de blogs.adobe.com...
Ouais, ben en attendant je pense que la gars a une connaissance de la stack multimedia linux un peu plus approfondie que toi...
on teste des solutions, on récupère ce qui marche bien
C'est vrai pour pas mal d'aspect du development linux, mais en ce qui concerne le son, c'est surtout une grosse dose de NIH syndrom couple a une envie frenetique de tout peter pour un truc qui brille tous les 6 mois.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.