Christophe Fergeau a écrit 1255 commentaires

Parce que quand linus a commencé à utiliser bitkeeper, c'était le seul qui correspondait à ses critères (qui sont principalement la possibilité de developpement distribué, et un système de gestion de fusion de différentes branches en provenance de divers endroits très puissant). Aujourd'hui, je pense que arch pourrait convenir pour cela, mais n'ayant pas testé bitkeeper, il est possible que celui-ci soit plus performant/plus rapide que arch pour ce genre de scénario. De toute façon, à l'époque où linus a fait son choix, bitkeeper était probablement le seul outil viable pour faire ce qu'il voulait. Et même aujourd'hui, arch n'est pas assez mature pour un projet de la taille du noyau à mon avis.

Pour arch, tu n'as pas besoin de serveur, il te suffit d'avoir un accés sftp/http/ftp sur un serveur pour pouvoir publier l'historique intégral de ton module. Par contre il faut ensuite que le client qui va bien soit installé sur les machines clientes dans une version suffisamment à jour, et ça c'est un autre problème ;) (les fonctionnalités et la syntaxe en ligne de commande de tla ont tendance à bouger assez rapidement).

Je crois que pour l'instant, y a pas d'utilisation du tout de l'accélération hardware des cartes graphiques, tout est fait en software, d'où grosse lenteur.

Y a un truc à pas oublier avec l'adsl, c'est que ça n'est pas seulement une connexion haut débit, mais surtout (du moins pour moi), une connexion illimitée qui ne monopolise pas la ligne téléphonique. Pour moi, c'est beaucoup plus important que le débit brut. C'est quand meme beaucoup plus confortable de lancer sa connexion au démarrage et de ne plus y penser que de devoir attendre 1 minute que la connexion par modem s'établisse, de devoir se déconnecter pour téléphoner, ...

Parce que rhythmbox ne contient pas de code du tout spécifique à un format audio, il se repose entièrement sur gstreamer pour ça. Si gstreamer a un support buggé des streams ogg, il en sera de meme pour rhythmbox. Et le fait qu'un format soit parfaitement supporté ou non ne dépend pas uniquement de la dispo des specs, mais aussi du nb de personnes codant sur un projet, et du temps qu'elles ont pour coder dessus, ainsi que de leurs priorités.

> C'est d'ailleur dingue, que les lecteur libres négligent ce format libre...

C'est à cause d'un bug dans gstreamer, qui est dur à corriger je crois. Libre à toi de faire en sorte que ce format libre soit parfaitemnet supporté... (Rhythmbox gère sans problème l'ogg et le flac pour les morceaux non streamés)

Les radios ogg ne fonctionnent pas avec rhythmbox.

Ah, et le petit nouveau Muine qui tente un nouveau genre d'interface

Ah ? Ca fait super longtemps que j'utilise les versions cvs, et j'ai pas vraiment eu de pb avec, en tout cas rien de ressemblant à ce que tu décris. Peut être esound/alsa/les gnome sound events qui foutent la merde.
Pour les logiciels du même genre, y a juk et jamboree

C'est probablement un post que personne ne lira, mais...
http://www.le-hacker.org/papers/gobject/index.html(...)

vaut mieux contribuer à rhythmbox ;) (www.rhythmbox.org)

Un programme en gtk2 pour retagger des fichiers et qui utilise gstreamer
(c'est cool les journaux comme ça, je peux caser les programmes que je peux pas écrire par manque de temps ;)

Pour la durée, j'aurais grandement préféré le film en 2*1h30, le film était bien, mais au bout de 1h10/1h20 j'ai commencé un peu à décrocher (j'aime pas les films longs d'une manière générale)

config.log peut te donner des indices...
si t'as installé la glib à partir des sources, tu peux avoir besoin de régler PKG_CONFIG_PATH pour qu'il pointe sur /usr/local/lib/pkgconfig

Y a aussi un truc qui arrive des fois, c'est un utilisateur (ou un groupe d'utilisateurs) qui fait "si qqu'un ajoute telle fonctionnalité qui me manque beaucoup à tel programme et que la fonctionnalité est intégrée, alors je suis prêt à lui filer xxx dollars en échange". En général ça motive certaines personnes pour bosser sur la fonctionnalité en question :)

Au sujet des courbes similaires, je suis tombé sur http://www.inkstain.net/fleck/archives/000742.html(...) récemment, c'était assez amusant ;)

Ca change quoi que les groupes n'existent plus ? Les membres du groupe sont encore en vie... En plus, pour les Pink Floyd, a priori ils n'ont pas "officiellement" arrêté.

Ok, ok désolé :)

Comme je disais dans un message précédent :

> (enfin d'après ce que j'ai compris, xine fait ça, si ca se trouve j'ai super mal
> compris, merci de me corriger si je raconte n'importe quoi)

Tiens, tant qu'on est en plein troll, les threads c'est complexe donc à fuir autant que possible (sans faire non plus des trucs super laids uniquement dans le but d'éviter d'utiliser des threads).

Après les claviers qui se blo il y a les navigateurs qui coupent les phrases ?
Mon message c'étiat pas "lancer plein de threads" sans rien après, c'était "lancer plein de threads qui s'occupent tous de remplir le buffer de la carte son en espérant qu'il y en ait un qui soit schedulé à temps"

Enfin on va pas épiloguer, perso je trouve ça tout pourri, toi tu as l'air de trouver ça particulièrement subtil et élégant, chacun ses gouts ;)

J'ai pas non plus dit que le scheduler du 2.4 était complètement pourri, j'ai surtout dit qu'il avait des comportements suboptimaux dans certains cas, en particulier des temps de latence qui peuvent etre assez eleves (il a d'ailleurs été en grande partie réécrit dans le 2.6, et les patchs low latency et preemptible kernel du 2.6 tentent aussi de diminuer ces temps de latence, donc y avait bien des petits pb de ce cote là, non ? ;).
Par "tricher", je veux dire que c'est inutilement bourrin, et que c'est pas très joli. Ils sont redondants dans le sens où ils font la même chose, et leur seule raison d'être, c'est qu'un seul thread n'est pas suffisant pour obtenir une lecture fluide. Ca denote donc un certain manque au niveau de l'os si on est obligé de recourir à de telles techniques pour s'assurer des performances acceptables... (je me limite à la lecture de musique, j'y connais pas grand chose en vidéo, et en plus le support de vidéo dans gstreamer est moins avancé que le son).

Pour rhythmbox, si tu veux éviter les pb avec gstreamer, tu peux le recompiler pour qu'il utilise xine (c'est ce que je faisais au temps du 2.4)

Dans ton 2.6, t'as activé tout ce qui est preempt et low latency ?

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

C'est un autre problème alors ;) Toujours est-il que moi j'avais des pbs au temps du 2.4, et que maintenant c'est beaucoup mieux (faudrait que je refasse des tests approfondis pour être catégorique).

>On le fait bien avec xine ou mplayer... pourquoi gstreamer aurait-il "besoin" d'un 2.6 ?

Relis le thread 2/3 fois, j'aime pas trop me répéter... J'ai rien contre expliquer les points pas clairs dans ce que je raconte par contre ;)

Encore une fois, le multithreading intervient parce que d'après ce qu'on m'a dit, certaines applis qui jouent de l'audio lancent plusieurs threads à la fois font tous la meme chose, c'est à dire remplir le buffer de la carte son. Pour le noyau 2.4, un thread = un process, donc plus si t'as plusieurs threads qui tentent de faire la meme chose (remplir le buffer de ta carte son), eh bien tu as tout simplement plus de chance que la chose en question soit faite rapidement...
Et avoir plusieurs threads qui se font concurrence pour faire exactement la même chose uniquement pour être sûr que le noyau daignera donner la main à l'appli avant qu'il ne soit trop tard, je n'appelle pas vraiment ça être « codée de manière plus intelligente que gstreamer » et « profiter au mieux des ressources d'une machine ». C'est uniquement un gros hack pas beau à mes yeux, même s'il a le mérite de très bien fonctionner d'un point de vue utilisateur (c'est assez malin aussi comme hack je trouve, mais ca ne le pas acceptable pour autant).

Pour l'histoire de mp3->disque, j'en parlais justement pour prouver que gstreamer n'est pas "lent" d'un point de vue décodage et tout ça, mais que les problèmes apparaissaient effectivement des qu'il s'agit de jouer un son en continu. Pour moi "lent" ca signifie qu'il utilise 100% du cpu et n'arrive meme pas à produire suffisamment de données. Là on n'est pas dans ce cas de figure comme le montre le test mp3->disque

Et donc, si c'est tout de la faute de gstreamer, comment expliques-tu qu'il n'y ait plus de pb avec un noyau 2.6 ?

Non non, je parlais de trucs du style "lancer plein de threads qui s'occupent tous de remplir le buffer de la carte son en espérant qu'il y en ait un qui soit schedulé à temps"