Alan_T a écrit 242 commentaires

Justement, moi je suis sous 2.6 depuis le 2.6.0-test6 et j'ai encore des problèmes !!!

Et puis, de toute façon, comme le faisait très justement remarquer quelqu'un d'autre, le 2.4 devrait suffire pour regarder un film. On le fait bien avec xine ou mplayer... pourquoi gstreamer aurait-il "besoin" d'un 2.6 ?

Je ne vois vraiment pas ce que vient faire le multi-threading là dedans !!!

Le principe des threads est de profiter au mieux des ressources d'une machine (qu'elle soit mono ou multi processeur, ou encore qu'elle possède un support à l'hyper-threading). Mais cela n'explique en rien pourquoi Gstreamer est lent... ou alors je n'ai pas compris.

Le fait que l'appli machin arrive à séparer la décompression vidéo en plusieurs threads concurrents montre seulement qu'elle est codée de manière plus intelligente que gstreamer (d'ailleurs, je ne suis pas sûr que gstreamer soit mono-threadé !!!). Mais, cela n'explique pas les saccades dans la lecture des fichiers audio ou vidéo.

Personnellement, je me base sur les logiciels i-Tunes et le display vidéo intégré dans gnome. Et, soit les deux applis sont programmées n'importe comment, soit gstreamer est totalement à revoir au niveau de la performance....

Enfin, pour ton exemple du mp3, je te signale que le fait qu'il traduise un fichier mp3 en moins de temps qu'il ne met à le jouer, montre simplement que le problème de gstreamer repose principalement au niveau du temps-réel. C'est à dire qu'il n'arrive pas à délivrer le son voulu au moment voulu... Donc, tout leur cinéma sur leur "low-latency" est à revoir... ce qui est possible d'ailleurs, mais je n'ai pas encore été voir le code...

Je ne vois pas de problème dans mon noyau lorsque j'utilise xmms, xine ou mplayer. C'est totalement fluide.... en 2.4.x ou en 2.6.x (je suis sous 2.6.1 avec le préemptif).

Mais lorsque j'utilise gstreamer, cela saute, cela cafouille, et des fois cela plante... D'où cela vient-il ? La faute aux codecs ? Ou l'architecture est encore à revoir ?

Ce qui m'étonne le plus, c'est que dans l'article sur OSNews, je m'attendais à voir au moins un passage sur: "Bon, pour l'instant les perfs sont pas grandioses à cause de ..., on va améliorer ça dans l'avenir en faisant ...".

Mais là, RIEN ! Pas même la moindre remarque sur le fait que cela rame tout de même considérablement (et ne dis pas le contraire, je ne vois pas pourquoi le 2.4 aurait du mal à jouer du son ou afficher une vidéo tout ça à cause de problème de scheduling... la complexité du scheduler n'est rien devant la décompression vidéo ou audio).

Alors, je suis _un_peu_ étonné ! Voila !

Dites, il n'y a que moi qui trouves que gstreamer est complétement lent ?

Pour le son ou la video, cela rame (meme sans utiliser tout le proc). Alors que Xine ou Xmms s'en débrouillent très bien ?

Est-ce de ma faute ou quelqu'un d'autre a remarqué ce genre de comportement ?

> Je ne dis pas que c'est mal... mais ce n'est donc pas très nouveau.

Comme tu dis, c'était déjà comme ça avant (des entreprises comme Microsoft ne prennent pas forcément des pincettes avec leurs travailleurs), mais là la différence c'est que le client est protégé et qu'on peut avoir des circuits parallèles dans lesquels l'économie est basée sur d'autres valeurs que l'argent.

Cependant, ta comparaison du système économique de l'Open Source avec le capitalisme est discutable sur plusieurs points (mais je ne vais pas développer ici), tout comme la comparaison au système économique communautaire mis en place par le régime soviétique (collectivisation forcée des moyens de productions).

Je pense vraiment que l'Open Source ouvre une voie différente qui est orthogonale aux mouvement qui ont déjà existé auparavant (cependant, je ne clame pas que l'Open Source est la panacée!!! Ce système a ses limitations, notamment en ce qui concerne son domaine d'application).

Pour en revenir au problème du développeur/travailleur, je pense que croire que le modèle de l'Open Source est faite pour protéger le codeur est une mauvaise hypothèse. Le modèle de l'Open Source protège... le code (et par conséquent le logiciel).

Le problème de la protection du développeur/travailleur n'est pas géré par le modèle de l'Open Source... À toi de voir si un syndicat ou un système prise de participation (à travers des actions de la société) est le meilleurs moyen... :)

Hum, c'est encore un peu tôt pour le dire...

On en est au début, personne n'a encore exploré les limites du modèle économique des logiciels à sources ouvertes. L'avenir nous le dira. :)

Non. Cela ne marcherai pas.

Juste pour ajouter que lancer un logiciel libre au début se fait à perte (forcément). Mais, il s'agit d'une prise de risque (Le projet est-il intéressant ? Sera-t-on rejoint par d'autres entreprises plus tard ? ...). Sur un très grand nombre de projets libres, seuls un tout petit nombre atteint le stade d'Apache, Linux, gcc, ou autre... Pourtant, à chaque fois, ils ont été commencé par des développeurs dans leur coin qui on su faire ce qu'il fallait (et qui ont certainement eut une part de chance aussi).

> Je parlais de "théorie" pour la vente de développement libre qui réponds à un besoin
> d'un client ce n'est pas la meme chose;

Ok, j'avais effectivement mal compris... Donc, tu voulais dire que les logiciels qui s'addressent à des particuliers ont du mal à trouver leur place dans l'économie du libre...

Et bien, oui c'est vrai... mais la question ici serait: "Est-ce que ce ne serait pas justement la limite du monde libre ?". Je pense sincérement qu'il n'y a pas de modèle économique valable en Open Source pour ce genre de logiciels (et je pense que c'est aussi ton avis).

J'ai même une théorie qui dit que lorsqu'on se place à un niveau micro-économique (c'est à dire au niveau d'une économie de type "individus" et pas de type "entreprises" ou "communauté") l'argent n'a plus vraiment court dans le monde du libre. On crée une économie de troc: "Tu me fournis du code, je te fais ton site web ou je fais la hot-line sur les news.". L'argent n'a pas vraiment court à ce niveau économique (on le remplace par d'autres valeurs).

Bref, je suis d'accord avec toi. :)

Théorie ???

Je pense que tu devrais sortir un peu de ta coquille ! :)

Tout d'abord, il faut rappeller que cette économie (logiciel + sources contre argent) existait bien avant l'Open Source. C'était le modèle de base des entreprises SSII (services informatiques).

Ensuite, on commence à compter en terme de milliards d'euros le chiffre d'affaire généré autours des logiciels libres de nos jours. Je peux donner les exemples suivants:

- IBM paye un certains nombre de développeurs sur le noyau Linux et sur Apache. En contre partie, IBM dégage un bénéfice assez conséquent en vendant des serveur Web professionnels qui font tourner le couple Linux+Apache. IBM a à la fois l'avantage de ne payer que quelques développeurs (et non une équipe complète qui développerait un OS propriétaire) tout en bénéficiant de toutes les améliorations apportées par les autres partenaires (Oracle par exemple, mais la liste est longue), mais IBM peut aussi décider de focaliser l'attention de ses développeurs sur une fonctionnalité précise qui lui fait défaut dans sa gamme de produits (il garde donc un certain contrôle (non-bloquant) sur le développement de ces logiciels qui est à la mesure du nombre de développeurs investit dans le projet).

- RedHat/Mandrake/Suse payent eux aussi un certains nombre de développeurs du noyau ou des desktops (Gnome par exemple). En contre partie, ils dégagent du bénéfice non pas avec la vente de leur distribution, mais avec les services qui vont autours (maintenance, patchs de sécurité, hot-line, etc). Le fait d'avoir, comme IBM, un certains poids sur l'orientation des développements des principaux éléments d'une distribution leur permet d'améliorer leur produit (et éventuellement leurs services... car moins de bugs ---> moins de travail pour eux).

- Oracle paye aussi un certains nombre de développeurs kernel (même si Linus n'arrete pas de critiquer leur code sur la LKM :). Le bénéfice d'Oracle est aussi de pouvoir avoir un logiciel de base de données qui sache tirer parti un maximum du noyau sur lequel il tourne (et éventuellement d'intégrer dans le noyau des améliorations qui permettront a ses logiciels de tourner plus efficacement).

- Sun Microsystem finance une grande partie du projet Open Office. Dans ce cas, le modèle de développement varie légèrement car il y a une version totalement Open Source et une version qui contient un certain nombre de modification qui est vendue par Sun. Comme dans les cas précédent, Sun, avec une équipe de développement réduite, peut se permettre d'avancer beaucoup plus vite car ils bénéficient de l'aide de la communauté Open Source, mais aussi d'autres entreprises qui veulent développer des fonctionnalités particulières pour leurs besoins propres.

- Apple, enfin, avec MacOS X qui finance une grande partie des développeurs FreeBSD plus certains projets annexes... L'intêret d'Apple est très similaire à celui d'IBM, mais l'approche est légérement différente.


Bref, tu comprendras que je suis étonné que tu me dises que tout ceci est une "théorie" alors que les faits sont là (et en espèce sonnante et trébuchante !!! :).

S'il y va un jour, qu'il y reste !!!

Bon, c'est pas tout ça mais ----> [] :)

Je pense que c'est au contraire exactement l'esprit Open Source... Une personne physique ou une entreprise a besoin d'une fonctionnalité et offre un salaire (ou une récompense) pour faire ce travail. Comme n'importe qui peut accèder au code, n'importe qui peut se porter volontaire ou faire le travail... Évidemment, ceux qui connaissent bien le code de ce logiciel (les auteurs originaux par exemple) ont un avantage indéniable sur les autres, mais ils ne peuvent bloquer les tentatives des autres (au contraire des logiciels à sources fermées).

En fait, tout vient du fait que les systèmes économiques des logiciels à sources fermées et celui des logiciels à sources ouvertes sont totallement différent.

Avec les logiciels à sources fermées, on vend le logiciel comme un produit manufacturé (comme une voiture, un tableau, ou autre). Le problème, c'est que même si le développement de ce logiciel coûte cher (du moins c'est ce que l'on suppose), la fabrication (lire la "duplication") de ce logiciel ne coûte quasiment rien. Les bénéfices, lorsqu'il s'agit d'un logiciel très grand public, sont donc vraiment monstrueux et très souvent en défaveur du client.

Avec un logiciel à source ouverte, on vend son travail. C'est à dire que ce que le client paye, c'est le temps que va passer un développeur (ou une équipe de développeurs) pour réaliser le logiciel. À la fin, le client a son logiciel (ou sa fonctionnalité) et les sources qui vont avec. Le programmeur, lui, a été payé durant le moment où il a travaillé pour ce client. La seule capitalisation que peut faire ici le programmeur est l'expérience qu'il possède du logiciel qu'il a codé (on viendra préferablement le chercher pour lui demander de coder quelque chose pour ce logiciel, ou pour le maintenir car il n'a pas besoin de découvrir le logiciel en question).

On remarque tout de suite que dans le modèle économique des logiciels ouverts, offrir de l'argent pour un travail est tout à fait pertinent et, en prime, bénéficie à tout le monde (je veux une fonctionnalité précise, mais au final tout le monde pourra l'utiliser). On peut imaginer, donc, des groupes d'interet se former autours de projets commun. Par exemple, une bonne suite de logiciels bureautique (cf Open Office), ou un serveur web efficace (cf Apache avec des financements d'IBM qui l'utilise sur ses serveurs), etc.

Donc, je pense qu'au contraire, Mark Shuttleworth a tout à fait compris le principe de l'Open Source...

Cela dépend de quelle version tu parts. Si c'est la 0.5, il va falloir que tu fasses pas mal de ménage, mais si c'est une version rel;ativement récente, cela ne devrait pas poser de problème.

C'est vrai que RMS a son caractère... Il aime bien jouer le rôle de patriarche (le parain ?). Enfin, c'est aussi à cause de ce caractère que Linux est sorti (et pas Hurd).

> ...au détriment d'une solution plus locale et plus libre...

Peut-être qu'en ce moment en Chine, libérer les logiciels n'est pas vraiment le plus urgent.

Libérer les gens serait déjà un bon premier pas (et respecter les droits de l'homme aussi, pourquoi pas!).

Comme le code est ouvert et que les codeurs du noyau se reviewent entre eux, l'un des autres codeurs du noyau détecterait le problème. Je pense qu'il faudrait corrompre un bon nombre de codeurs du noyau pour pouvoir faire ce que tu dis (et même dans ce cas, comme le code est lisible par tous, quelqu'un d'extérieur pourrait trouver la faille).

De toute façon, de plus en plus de gens ont intêret à ce que Linux fonctionne bien. Des personnes privées, mais aussi des entreprises comme IBM, Motorola, et même Intel. Alors, cette éventualité est tout de même assez marginale.

Pour information:

Larry McVoy wrote:
> On Wed, Nov 05, 2003 at 04:48:09PM -0600, Chad Kitching wrote:
>>From: Zwane Mwaikambo
>>>+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
>>>+ retval = -EINVAL;
>>
>>That looks odd
>>
>>
>>Setting current->uid to zero when options __WCLONE and __WALL are set?
>>The >>retval is dead code because of the next line, but it looks like an attempt
>>to backdoor the kernel, does it not?
>
>
> It sure does. Note "current->uid = 0", not "current->uid == 0".
> Good eyes, I missed that. This function is sys_wait4() so by passing in
> __WCLONE|__WALL you are root. How nice.

Konichiwa Erwan-san,
J'ai essayé d'apprendre le japonais aussi, mais par manque de temps, je n'ai jamais atteint les kanji, l'hiragana et le katakana ont eut raison du peu de temps que mon travail me laisse. Cela dit, je continue régulièrement de faire des tentatives et je ne désespère pas qu'un jour peut-être.... :)

Et puis, oui, le japonais est une langue superbe ! D"une part à cause de la culture qui va avec (j'ai dernièrement été à un concert de Koto, c'est très surprenant et pas désagréable du tout) mais aussi parcequ'elle nous sort un peu de la gangue des langues européenes, qui à force d'être pareilles, nous enferment dans des préjugés linguistiques.

Cela dit, on parle de programmation ici, de documentation technique. Je ne sais pas si tu as essayé de lire des manuels techniques en japonais (tu l'as sûrement fait), mais c'est quasiment exclusivement du katakana et bien souvent la transcription phonétique de mots anglais.

Pour ce qui est de la littérature... OUI, mille fois oui ! Lire en langue originale est incomparable, c'est d'ailleurs en tentant l'aventure que l'on se rend compte que très peu de romans sont traduits correctement. Certains se plaignent des sous-titres au cinéma, mais les livres subissent hélas le même sort.

Ensuite, oui, je parle le danois... pas aussi bien que je le voudrais, mais j'arrive à tailler la bavette avec mes amis danois (parceque je suis au Danemark et que même s'ils parlent parfaitement anglais je trouve que ce serait irrespectueux de ne pas parler leur langue, même si beaucoup sont très surpris qu'un français apprenne le danois).

Bref, bref, tout ça pour dire que je suis pour le multi-linguisme. Mais là en l'occurrence on parle d'un domaine qui est technique, un domaine qui a sa propre culture... et donc sa propre langue. La base de cette langue est effectivement l'anglais, mais va parler de "scheduler O(1)" à un agrégé de littérature anglaise de Cambridge, je suis pret à parier qu'il te regardera bizarrement !

Mais ce que je trouve scandaleux par-dessus tout, c'est qu'en traduisant des parties aussi sensibles que les aides du noyau, les erreurs du compilateur ou du noyau, on n'aide en rien cette communauté. Au contraire, on détruit peu à peu ce qui la lie, ce qui maintient un semblant de cohésion entre ces allemands, ces japonais, ces chinois, ces canadiens, ces français, ces finnois, etc... C'est à dire UNE LANGUE COMMUNE.

Si tu ne comprends pas ce qui m'a faché tout rouge à présent, je ne sais plus comment l'exprimer à présent !!!

Où vois-tu de l'élitisme dans mon post ???

Le fait de ne pas parler d'autres langues est typiquement Français, dans des tas d'autres pays européens, n'importe quel péquin parle couramment anglais. J'habite et je travaille au Danemark en ce moment, et je peux te dire que le conducteur du bus que je prend le matin est aussi bon que moi en anglais.

C'est clair:

char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

Non ???? Peut-être qu'un petit commentaire aiderait. :)

Mouais, je croyais que tu étais pour la compréhension du plus grand nombre.... Je te signale que nous sommes ici sur un forum qui est censé être francophone. Personnellement, j'ai suivis les règles (sauf pour mon orthopgraphe de "langage" je l'avoue mais j'étais de bone foi), peut-être ferais-tu bien d'en faire autant ! Cela te permettra de mettre en application les grands principes dont tu nous a parlé plus haut. :)

Houla, moi qui croyait que j'écrivais français ! :)

Merci pour la correction.

J'arrive à reconnaître le basque, mais j'avoue mal le comprendre. Et puis, les méthodes de l'ETA me donnent un appriori négatif sur cette langue....

C'est exactement ça ! :)

Je suis heureux de ne pas être le seul !!!!

Je crois que tu ne vois pas le mal qui peut être fait ici. Je vais donc enfoncer un peu le clou.

il se trouve que j'aide un peu les débutants sur la liste d'aide de Léa. De temps à autre un débutant débarque et pose des questions sur un problème de compilation et il donne (en toute bonne foi) des messages d'erreurs en _français_.

Comment veux-tu que je puisse l'aider ?

Mon compilateur, comme celui de tout ceux qui font un tant soit peu de développement est en anglais (car quand je rencontre une erreur, un simple copier/coller dans Google/Linux me donne une réponse pertinente).

Il va falloir que j'essaye de retrouver le message d'erreur original ? Hum, quand c'est possible... car la plupart du temps, c'est de la traduction complétement au mot à mot et qui a complétement perdu le sens original.

Bref, au final, le débutant n'aura jamais son bug fixé et il est possible que ce bug (peut-être intéressant) ne remontera jamais jusqu'aux développeurs que cela pourrait intéresser...

L'impact de ces traductions est plus important que tu ne le crois, les développeurs ont _besoin_ du retour des utilisateurs pour progresser. Traduire ces messages d'erreurs "profonds", c'est couper la chaîne. Autant, pour les messages d'erreurs du genre "Votre serveur SMTP ne répond pas", je trouve cela normal, autant les outils de développement DOIVENT rester dans une langue unique.