Alors je t'aide: FUD: Fear Uncertainty and Doubt, donc quand Gabe Newell "Windows 8 is a catastrophe for everyone in the PC space.", ça c'est du FUD: une affirmation pour faire peur sans réelle justification.
Quand un dev dit on a 315FPS dans X et 303FPS dans Y, ça ce n'est pas du FUD, c'est une information.
Pour le reste je suis d'accord avec toi, Valve a tout intérêt à ce que d'autre producteurs de jeux fassent la même chose: avant de se battre pour avoir la plus grosse part du gâteau, il faut faire le gâteau!
Je suis intervenu sur la mailing list de Phoronix, car certains points de Paul Davis me paraissaient un peu "rapide":
En résumé je trouvais que bien que la mémoire partagée n'utilise pas d'appel système mais qu'il faut bien utiliser des IPC en plus et que le tout 'pull' ne me parait pas satisfaisant dans tout les cas (jeux par exemple) et donc des modifs du kernel pourraient être intéressant.
Apparemment quasiment tout les points de l'auteur de KLANG m'ont l'air mort, mais il y aurait quand même quelque chose a faire: Paul Davis trouverait super d'avoir une modification d'ALSA pour supporter aussi une interface à la CoreAudio..
Si je ne me trompes pas ça revient à importer une partie de ce que fait PulseAudio dans le kernel pour une meilleure efficacité..
Dommage que l'auteur de KLANG n'ai pas eu cette discussion avec Paul Davis avant de démarrer KLANG, ça aurait pu être un projet intéressant!
Ton commentaire n'est pas faux, mais Paul Davis précise que le système en question n'utilise pas ALSA donc pour ce cas précis ça n'est pas un problème, mais je suis d'accord: dans le cas générique le calcul entier ça pose des problèmes.
Aussi Paul Davis précise qu'il y a deux façons d'avoir des systèmes audio: le pull (la carte son annonce qu'elle a besoin de données supplémentaire et les applis fournissent), le push: les applis fournissent les données et précise que le pull est le plus répandu et qu'avec une bufferisation ont peu faire du push sur du pull mais pas l'inverse.
Sauf que une appli voulant 1) que le son prenne peu de ressources 2) avoir quand même une faible latence (par exemple un jeu) ne me parait pas bien servi par ni par un pull (car pour la faible latence il faut définir des buffers de petite taille donc beaucoup d'interruption) ni par un push bufferisé sur du pull, donc un kernel qui fasse du pull (parfait pour les applis pro de multiplexage) et du push (bien pour les jeux) ça ne me choquerait pas..
Ceci dit j'ai tout faux sur l'utilisation du calcul flottant dans sa réponse à Paul Davis, le développeur de KLANG donne plus de précision: KLANG utilisera du calcul entier pour faire le muxing, cf sa réponse dans le lien donné par tinram (merci): http://ardour.org/pd_on_klang
Apparemment ils ont décidé de continuer à en discuter sur phoronix, dommage vu la qualité des "contributeurs" de Phoronix (à peu près un gars qui cherche a comprendre le sujet pour 10 trolleur), ça ne devrait pas aider.
Bon je ne suis pas qualifié pour commenter les remarque de Paul Davis, mais je ne vois pas comment une implémentation dans le kernel peut être moins efficace que de l'inter-application audio à moins qu'ils utilisent de la mémoire partagée et encore la mémoire partagée ce n'est pas suffisant: il faut aussi utiliser des instructions de synchronisation qui passent par le kernel, alors..
Pour les calculs flottants autant le x87 n'est pas dispo de base, mais le sse devrait l'être non ?
Ce n'est pas un problème de disponibilité du calcul flottant sur le CPU, c'est la possibilité/l'autorisation d'utiliser ces instructions dans le noyau Linux qui est le problème: les devs de Linux interdisent d'utiliser le calcul flottant dans le noyau si mes souvenirs sont bon, ce qui n'est pas le cas du noyau FreeBSD.
l'optimiser pourrait être une solution au lieu de réinventer la roue
Si tu lisais le journal, tu éviterais de faire des commentaires "bateau", JACK est en espace utilisateur, ce qui a un surcoût en latence donc pour compenser il faut diminuer la taille des buffers d'où une utilisation de CPU importante.
"L'optimisation" serait donc de mettre JACK dans le kernel, ce qui est un changement radical de conception, et il n'est pas sûr du tout que Linus accepterait d'intégrer le code (c'est vrai aussi pour KLANG)..
Sa description du projet KLANG est intéressante, mais il y va y avoir plusieurs difficultés:
- le module KLANG utilisera probablement des calculs flottants donc l'intégrer dans le kernel Linux sera "mission impossible"TM.
il a choisi d'étendre l'API d'OSSv4, mais est-ce une API utilisée dans le monde Linux?
Je n'en ai pas l'impression, j'ai l'impression qu'elle est juste fournie pour la compatibilité avec les vieux programmes..
Bref j'ai l'impression que s'il va au bout son projet devrait avoir du succès dans le monde BSD mais dans le monde Linux ça m'étonnerait..
Il y a d'autres langages qui ont ça, mais bon ne me demande pas lesquels ce n'est une fonctionnalité que je retiens (pas grand intérêt)..
Par contre un langage avec un comportement sain des entiers (exception de dépassement ou big Int) ça c'est intéressant (mais pas si fréquent que ça malheureusement) coffeescript étant une surcouche de javascript ne l'a pas d'ailleurs.
Prix coûtant pour le constructeur tu es sûr?
Google je vois bien son intérêt de vendre a prix coûtant, mais Asus là je ne vois pas bien pourquoi ils vendraient sans bénéfice..
Note que là tu parles du code intégré dans le kernel..
Le rootkit du départ venait d'une application, là il devrait y avoir moyen de se protéger: je pense un modèle à la Android où les applications doivent déclarer les permissions qu'ils vont utiliser (enfin il me semble).
Bof, tu connais le "The Underhanded C Contest"?
Le but est de coder des fonctionnalités cachées dans du code, et certaines des solutions sont vraiment très ingénieuses!
Avoir les sources n'est donc pas vraiment une garantie, je pense que c'est à l'OS de fournir un modèle de sécurité suffisamment robuste pour qu'un exécutable (open source ou pas) ne puisse pas introduire de rootkit.
Après la sécurité c'est rarement pratique et donc souvent désactivé cf SELinux..
Je dois être une star du rock qui s'ignore alors: j'achète toujours des lunettes qui colorent en doré: comme ça j'ai l'impression qu'il fait beau en permanence.
Coloré en rouge, c'est sûr que ça me tente moins.
Hum, l'ordi de ma femme (avec Vista) s'est trouvé vérolé, mais étant donné qu'elle avait installé elle-même une application pourrie, j'ai du mal a blâmer Microsoft.
Linux ayant une part de marché ridicule au niveau du desktop est effectivement 'protégé', m'enfin bon, pas de quoi se vanter.
Bah, non KDE n'est pas mieux, ils activent par défaut des trucs pas prêt donc il vaut mieux utiliser des distributions qui stabilisent KDE..
Fondamentalement ça revient au même problèmes du libre: les intérêts des devs avant ceux des utilisateurs, ça se traduit juste un peu différemment entre KDE et Gnome.
Posté par reno .
En réponse à la dépêche Rekonq 1.0.
Évalué à 6.
dès qu'on parle d'ajout de fonctionalités un peu bas niveau
Là ou je trouve ça surprenant c'est que Chrome (donc WebKit) supporte l'isolation de Flash dans un processus séparé, et Rekonq utilise WebKit..
Donc ce n'est pas vraiment l'ajout d'une fonctionnalité "from scratch" mais l'intégration/l'activation d'une fonctionnalité qui existe dans une autre version du moteur.
Dans tes critiques, tu as oublié Gnome et KDE qui démontrent bien le problème du dev libre: c'est beaucoup plus amusant de suivre la tendance du moment que de polir l'existant.
Sinon pour ta critique de Linus je trouve que tu exagère: tu n'as pas l'impression qu'il bosse déjà à plein temps pour le monde du libre (ok il est payé pour, mais il fait du super boulot!)?
Et en plus il a initié git!!
Il ne peut pas tout faire à lui tout seul.
D'autant plus qu'à mon avis les cartes son, ça doit quand même être plus simple que les cartes graphiques et que la raison principale pour laquelle ça ne marche pas ce n'est pas la complexité technique mais c'est la même que le débat rpm/deb: des stupides querelle de chapelle.
J'ai tendance à dire que le desktop Linux ça sera bien a peu près en même temps qu'il y aura un système de packaging unifié pour les distributions.
Oui, c'est bien ce qui me fait dire que ce n'est pas la qualité de Windows8 qui est en question.
Après à mon Valve se réveille trop tard: faire de Linux un concurrent sérieux pour les jeux desktop c'est énormément de travail et il faut que Linux soit préinstallé sur des PCs, un budget marketing énorme etc.
"mature et répandu" Linux pour le desktop? Je ne suis pas convaincu.
[^] # Re: FUD
Posté par reno . En réponse au journal Banc d’essai OpenGL/Direct3D de Source engine par Valve. Évalué à 10.
Alors je t'aide: FUD: Fear Uncertainty and Doubt, donc quand Gabe Newell "Windows 8 is a catastrophe for everyone in the PC space.", ça c'est du FUD: une affirmation pour faire peur sans réelle justification.
Quand un dev dit on a 315FPS dans X et 303FPS dans Y, ça ce n'est pas du FUD, c'est une information.
Pour le reste je suis d'accord avec toi, Valve a tout intérêt à ce que d'autre producteurs de jeux fassent la même chose: avant de se battre pour avoir la plus grosse part du gâteau, il faut faire le gâteau!
[^] # Re: Paul Davis se fâche
Posté par reno . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 10.
Je suis intervenu sur la mailing list de Phoronix, car certains points de Paul Davis me paraissaient un peu "rapide":
En résumé je trouvais que bien que la mémoire partagée n'utilise pas d'appel système mais qu'il faut bien utiliser des IPC en plus et que le tout 'pull' ne me parait pas satisfaisant dans tout les cas (jeux par exemple) et donc des modifs du kernel pourraient être intéressant.
Et bien il m'a répondu fort poliment:
http://phoronix.com/forums/showthread.php?72625-KLANG-A-New-Linux-Audio-System-For-The-Kernel&p=278764#post278764
Apparemment quasiment tout les points de l'auteur de KLANG m'ont l'air mort, mais il y aurait quand même quelque chose a faire: Paul Davis trouverait super d'avoir une modification d'ALSA pour supporter aussi une interface à la CoreAudio..
Si je ne me trompes pas ça revient à importer une partie de ce que fait PulseAudio dans le kernel pour une meilleure efficacité..
Dommage que l'auteur de KLANG n'ai pas eu cette discussion avec Paul Davis avant de démarrer KLANG, ça aurait pu être un projet intéressant!
[^] # Re: Il ne manque pas une info?
Posté par reno . En réponse au journal Banc d’essai OpenGL/Direct3D de Source engine par Valve. Évalué à 3.
Vrai et faux: si tu utilise OpenGL comme à ses débuts, ton application ne pourra pas exploiter efficacement la carte vidéo.
[^] # Re: Je vois plusieurs difficultés:
Posté par reno . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 5.
Ton commentaire n'est pas faux, mais Paul Davis précise que le système en question n'utilise pas ALSA donc pour ce cas précis ça n'est pas un problème, mais je suis d'accord: dans le cas générique le calcul entier ça pose des problèmes.
Aussi Paul Davis précise qu'il y a deux façons d'avoir des systèmes audio: le pull (la carte son annonce qu'elle a besoin de données supplémentaire et les applis fournissent), le push: les applis fournissent les données et précise que le pull est le plus répandu et qu'avec une bufferisation ont peu faire du push sur du pull mais pas l'inverse.
Sauf que une appli voulant 1) que le son prenne peu de ressources 2) avoir quand même une faible latence (par exemple un jeu) ne me parait pas bien servi par ni par un pull (car pour la faible latence il faut définir des buffers de petite taille donc beaucoup d'interruption) ni par un push bufferisé sur du pull, donc un kernel qui fasse du pull (parfait pour les applis pro de multiplexage) et du push (bien pour les jeux) ça ne me choquerait pas..
Après je ne suis pas spécialiste en audio!
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par reno . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 2.
Avec le smiley j'ai cru que c'était une plaisanterie..
Effectivement je compte C# parmi les langages avec un comportement sain pour les entiers.
[^] # Re: Tout dans le kernel?
Posté par reno . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 5.
Pas sûr que ça soit la vrai raison, ça peut être lié à l'histoire d'OSS dans Linux aussi..
[^] # Re: Je vois plusieurs difficultés:
Posté par reno . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 6.
Ceci dit j'ai tout faux sur l'utilisation du calcul flottant dans sa réponse à Paul Davis, le développeur de KLANG donne plus de précision: KLANG utilisera du calcul entier pour faire le muxing, cf sa réponse dans le lien donné par tinram (merci): http://ardour.org/pd_on_klang
Apparemment ils ont décidé de continuer à en discuter sur phoronix, dommage vu la qualité des "contributeurs" de Phoronix (à peu près un gars qui cherche a comprendre le sujet pour 10 trolleur), ça ne devrait pas aider.
Bon je ne suis pas qualifié pour commenter les remarque de Paul Davis, mais je ne vois pas comment une implémentation dans le kernel peut être moins efficace que de l'inter-application audio à moins qu'ils utilisent de la mémoire partagée et encore la mémoire partagée ce n'est pas suffisant: il faut aussi utiliser des instructions de synchronisation qui passent par le kernel, alors..
[^] # Re: Je vois plusieurs difficultés:
Posté par reno . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 3.
Ce n'est pas un problème de disponibilité du calcul flottant sur le CPU, c'est la possibilité/l'autorisation d'utiliser ces instructions dans le noyau Linux qui est le problème: les devs de Linux interdisent d'utiliser le calcul flottant dans le noyau si mes souvenirs sont bon, ce qui n'est pas le cas du noyau FreeBSD.
[^] # Re: Jack et le temps réel
Posté par reno . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 7.
Si tu lisais le journal, tu éviterais de faire des commentaires "bateau", JACK est en espace utilisateur, ce qui a un surcoût en latence donc pour compenser il faut diminuer la taille des buffers d'où une utilisation de CPU importante.
"L'optimisation" serait donc de mettre JACK dans le kernel, ce qui est un changement radical de conception, et il n'est pas sûr du tout que Linus accepterait d'intégrer le code (c'est vrai aussi pour KLANG)..
# Je vois plusieurs difficultés:
Posté par reno . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 4.
Sa description du projet KLANG est intéressante, mais il y va y avoir plusieurs difficultés:
- le module KLANG utilisera probablement des calculs flottants donc l'intégrer dans le kernel Linux sera "mission impossible"TM.
Bref j'ai l'impression que s'il va au bout son projet devrait avoir du succès dans le monde BSD mais dans le monde Linux ça m'étonnerait..
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par reno . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 2.
Pas d'accord: si le '< <' en lui même ne m’impressionne pas beaucoup, C# est vraiment impressionnant dommage que ce soit une technologie Microsoft.
# Bof du sucre syntaxique sans grand intéret
Posté par reno . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 3.
Il y a d'autres langages qui ont ça, mais bon ne me demande pas lesquels ce n'est une fonctionnalité que je retiens (pas grand intérêt)..
Par contre un langage avec un comportement sain des entiers (exception de dépassement ou big Int) ça c'est intéressant (mais pas si fréquent que ça malheureusement) coffeescript étant une surcouche de javascript ne l'a pas d'ailleurs.
[^] # Re: Tous les logiciels closed source sont des rootkits potentiels
Posté par reno . En réponse au journal Ubisoft fait mieux que Sony. Évalué à 3.
Tu retardes pour 2 raisons:
1) ta remarque a déjà été faite
2) trusting the trust est obsolète:
http://linuxfr.org/nodes/95008/comments/1373078
[^] # Re: Tiens oui, parlons aussi du prix
Posté par reno . En réponse au journal GNOME 4.0 et GNOME OS prévus pour 2014 : abandon du pc, (même si on en était pas loin avec Gnome3). Évalué à 6.
Prix coûtant pour le constructeur tu es sûr?
Google je vois bien son intérêt de vendre a prix coûtant, mais Asus là je ne vois pas bien pourquoi ils vendraient sans bénéfice..
[^] # Re: Tous les logiciels closed source sont des rootkits potentiels
Posté par reno . En réponse au journal Ubisoft fait mieux que Sony. Évalué à 5.
Tu retardes: il suffit d'utiliser 2 compilateurs indépendants
[^] # Re: Tous les logiciels closed source sont des rootkits potentiels
Posté par reno . En réponse au journal Ubisoft fait mieux que Sony. Évalué à 2.
Note que là tu parles du code intégré dans le kernel..
Le rootkit du départ venait d'une application, là il devrait y avoir moyen de se protéger: je pense un modèle à la Android où les applications doivent déclarer les permissions qu'ils vont utiliser (enfin il me semble).
[^] # Re: Tous les logiciels closed source sont des rootkits potentiels
Posté par reno . En réponse au journal Ubisoft fait mieux que Sony. Évalué à 10.
Bof, tu connais le "The Underhanded C Contest"?
Le but est de coder des fonctionnalités cachées dans du code, et certaines des solutions sont vraiment très ingénieuses!
Avoir les sources n'est donc pas vraiment une garantie, je pense que c'est à l'OS de fournir un modèle de sécurité suffisamment robuste pour qu'un exécutable (open source ou pas) ne puisse pas introduire de rootkit.
Après la sécurité c'est rarement pratique et donc souvent désactivé cf SELinux..
[^] # Re: seconde zone
Posté par reno . En réponse au journal Valve prend Linux au sérieux. Évalué à 2.
Je dois être une star du rock qui s'ignore alors: j'achète toujours des lunettes qui colorent en doré: comme ça j'ai l'impression qu'il fait beau en permanence.
Coloré en rouge, c'est sûr que ça me tente moins.
[^] # Re: Ah les rumeurs...
Posté par reno . En réponse au journal Microsoft est-il en train de se suicider ?. Évalué à 5.
Hum, j'en connais plein qui sont resté sur la version d'avant le ribbon car ils n'aiment pas du tout le ribbon!
XP/7 je suis d'accord: les changements sont assez mineurs.
[^] # Re: Pilote AMD
Posté par reno . En réponse au journal Linux a des défauts sur le bureau. Évalué à 0.
Hum, l'ordi de ma femme (avec Vista) s'est trouvé vérolé, mais étant donné qu'elle avait installé elle-même une application pourrie, j'ai du mal a blâmer Microsoft.
Linux ayant une part de marché ridicule au niveau du desktop est effectivement 'protégé', m'enfin bon, pas de quoi se vanter.
[^] # Re: Assez d'accord
Posté par reno . En réponse au journal Linux a des défauts sur le bureau. Évalué à 2.
Bah, non KDE n'est pas mieux, ils activent par défaut des trucs pas prêt donc il vaut mieux utiliser des distributions qui stabilisent KDE..
Fondamentalement ça revient au même problèmes du libre: les intérêts des devs avant ceux des utilisateurs, ça se traduit juste un peu différemment entre KDE et Gnome.
[^] # Re: Rekonq
Posté par reno . En réponse à la dépêche Rekonq 1.0. Évalué à 6.
Là ou je trouve ça surprenant c'est que Chrome (donc WebKit) supporte l'isolation de Flash dans un processus séparé, et Rekonq utilise WebKit..
Donc ce n'est pas vraiment l'ajout d'une fonctionnalité "from scratch" mais l'intégration/l'activation d'une fonctionnalité qui existe dans une autre version du moteur.
# Assez d'accord
Posté par reno . En réponse au journal Linux a des défauts sur le bureau. Évalué à 6.
Dans tes critiques, tu as oublié Gnome et KDE qui démontrent bien le problème du dev libre: c'est beaucoup plus amusant de suivre la tendance du moment que de polir l'existant.
Sinon pour ta critique de Linus je trouve que tu exagère: tu n'as pas l'impression qu'il bosse déjà à plein temps pour le monde du libre (ok il est payé pour, mais il fait du super boulot!)?
Et en plus il a initié git!!
Il ne peut pas tout faire à lui tout seul.
D'autant plus qu'à mon avis les cartes son, ça doit quand même être plus simple que les cartes graphiques et que la raison principale pour laquelle ça ne marche pas ce n'est pas la complexité technique mais c'est la même que le débat rpm/deb: des stupides querelle de chapelle.
J'ai tendance à dire que le desktop Linux ça sera bien a peu près en même temps qu'il y aura un système de packaging unifié pour les distributions.
[^] # Re: Rekonq
Posté par reno . En réponse à la dépêche Rekonq 1.0. Évalué à 2.
Un plugin qui fait planter le navigateur? Tiens je croyais qu'on était en 2012!
Bon après pour une version 1.0 ça peut encore se comprendre.
[^] # Re: Explications ?
Posté par reno . En réponse au journal Valve prend Linux au sérieux. Évalué à 2.
Oui, c'est bien ce qui me fait dire que ce n'est pas la qualité de Windows8 qui est en question.
Après à mon Valve se réveille trop tard: faire de Linux un concurrent sérieux pour les jeux desktop c'est énormément de travail et il faut que Linux soit préinstallé sur des PCs, un budget marketing énorme etc.
"mature et répandu" Linux pour le desktop? Je ne suis pas convaincu.