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.
Tu as tout à fait raison et comme l'affichage en déporté en LAN et en WAN ce n'est pas la même chose (RTT très différent), et que sur un client léger ou un client lourd ça change aussi beaucoup de chose, pour supporter le principe "Unix" d'un outil qui ne fait qu'une seule chose mais qui le fait bien je propose:
- 1 serveur d'affichage en local
- 1 protocole d'affichage déporté en LAN pour client léger
- 1 protocole d'affichage déporté en LAN pour client lourd
- 1 protocole d'affichage déporté en WAN pour client léger
- 1 protocole d'affichage déporté en WAN pour client lourd
Ben voyons et le fait que son business dépend d'un app store et que Windows8 va intégrer un app store Microsoft n'a rien à voir à l'affaire!
Vista a été une catastrophe, mais Microsoft s'en est très bien sorti, il a juste vendu du XP avant de sortir Windows7.
Si Windows8 se plante, les gens resteront sous Windows7 en attendant Windows9, je ne vois pas pourquoi ils passeraient sous Linux cette fois-ci, quand ils ne l'ont pas fait pour Vista!
[^] # 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.
[^] # Re: Pinaillage
Posté par reno . En réponse au journal Wayland 0.95 est sorti !. Évalué à 4.
Tu as tout à fait raison et comme l'affichage en déporté en LAN et en WAN ce n'est pas la même chose (RTT très différent), et que sur un client léger ou un client lourd ça change aussi beaucoup de chose, pour supporter le principe "Unix" d'un outil qui ne fait qu'une seule chose mais qui le fait bien je propose:
- 1 serveur d'affichage en local
- 1 protocole d'affichage déporté en LAN pour client léger
- 1 protocole d'affichage déporté en LAN pour client lourd
- 1 protocole d'affichage déporté en WAN pour client léger
- 1 protocole d'affichage déporté en WAN pour client lourd
[^] # Re: yum install openswan
Posté par reno . En réponse au message IPsec. Évalué à 2.
Il a dit la doc de RedHat, donc on peut interpréter RHEL ou Fedora et s'il est à la recherche de doc, je dirais Fedora.
[^] # Re: quelques questions
Posté par reno . En réponse au journal "droit au mariage à tous les couples sans distinction de sexe ni de genre". Évalué à 3.
Et le mariage dans une fratrie pour les homos?
D'après tes arguments ça devrait être autorisé, mais je pense que ça ne sera pas la cas!
[^] # Re: quelques questions
Posté par reno . En réponse au journal "droit au mariage à tous les couples sans distinction de sexe ni de genre". Évalué à 3.
Ouaip, c'était une idée de la droite pour torpiller l'idée que l'union civile ouverte aux homos soit un équivalent du mariage.
[^] # Re: Explications ?
Posté par reno . En réponse au journal Valve prend Linux au sérieux. Évalué à 10.
Ben voyons et le fait que son business dépend d'un app store et que Windows8 va intégrer un app store Microsoft n'a rien à voir à l'affaire!
Vista a été une catastrophe, mais Microsoft s'en est très bien sorti, il a juste vendu du XP avant de sortir Windows7.
Si Windows8 se plante, les gens resteront sous Windows7 en attendant Windows9, je ne vois pas pourquoi ils passeraient sous Linux cette fois-ci, quand ils ne l'ont pas fait pour Vista!