IsNotGood a écrit 5009 commentaires

Prend une Gentoo alors.
Bouffer du cpu pour compiler des truc qui sont déjà compilés ce n'est pas kiffe.

> Il lit des mp3/ogg/flac/wav sur le dd/http/ftp directement pulseaudio ?

Non, ce n'est pas son boulot. C'est "seulement" un serveur de son. Donc ce n'est pas un remplaçant à Gstreamer par exemple.

> PulseAudio a une interface de programmation simple bien intégrée à KDE ? D'après ce que j'ai vu non.

Et alors ?
KDE peut bien se sortir les doigts du cul ou ils ne font qu'attendre que tout le boulot soit mâché ?

> Donc aucun rapport entre Phonon et PulseAudio. (A part qu'on pourrait utiliser PulseAudio en backend de Phonon pour la sortie des sons)

Aucun. PulseAudio fait des trucs que ne permet pas Phonon. A moins que Phonon ait déjà prévu toutes les fonctionnalités de PulseAudio dans son API, mais je n'y crois pas deux secondes.

> Il y a eu une discussion animée il y a quelques semaines sur l'intérêt d'utiliser pulseaudio et les problèmes que ca poserait

C'est ici :
http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)

Une réponse de Lennart Poettering sur les incompréhensions et FUD divers (ce qui est bien normal puisque peu connaissent PulseAudio). Très intéressant :
http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)

Sinon, c'est comme d'hab, il y a les "emmerdeurs". Ceux qui ne veulent pas d'un daemon et ne veulent que dmix mais oublient que dmix est un daemon, ceux qui ne veulent pas que PulseAudio utilise plus de 0,000001 % de leur cpu ni plus de 1 Ko, ceux qui seraient prêt à tuer père et mère pour que les facilités mixer de leur carte son soient utiliséee, etc....
Du très classique. Mais qui a fini par énerver Lennart Poettering :
http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)

Dude, what's wrong with you?

Réponse de Jeff Waugh :
http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)

At this point Lennart, I think there's a pretty clear consensus emerging, and you have the option to ignore the statistical (and emotional) outliers. :-)

Bref, PulseAudio est globalement accèpté et j'aurais beaucoup de mal à croire que PulseAudio ne soit pas dans Gnome 2.22 (voire 2.24 au pire).
Fedora est passé à PulseAudio. SuSE passe actuellement à PulseAudio. Mandriva semble faire de même.

> Ben ça l'utilisera via un plugin phonon si ça en vaut la peine (sinon on passe par libxine pour pas se faire chier)

Ça a l'air cool.

> Au passage, phonon ça gère aussi la vidéo...

Super.


Inutile de discuter. On verra dans quelques mois/années. Il y aura peu d'applis KDE qui utiliseront Phonon. Mais bon, c'est super Phonon.

Comme le téléphone portable à ses débuts...
M'enfin, tu peux resté accroché à ce que tu utilises.

C'est "marrant" de voir tout le buzz que fait Compiz alors que ça n'apporte rien. C'est joli, c'est tout (et c'est déjà très bien).

PulseAudio, ce n'est pas joli, ça apporte des solutions.

Par exemple on me contacte sur ekiga. Je branche à chaud mon casque audio usb et j'envois le son sur le casque (et que pour ekiga). Puis un pote arrive et je veux qu'il profite de la discussion en cours. J'envoie le son sur les haut-parleur (ou je débranche mon casque usb).

C'est une vraie solution à un vrai problème. Problème que peut avoir l'utilisateur lambda. Ou alors l'utilisateur lambda n'utilise pas ekiga, n'a pas de casque audio, etc...

> Tu ciblerais pas phonon par hasard ?

Tu m'as mal lu, ce n'est pas par hasard.

> Je vois nulle part sur pulseaudio de garantie d'API et d'ABI stable pour au moins 4 ans, voire plus.

Car KDE a la garantie pour tout ce qu'utilise KDE ?
Qt4 (la plus grosse brique), tu as une garantie ?
OK, on vient d'apprendre que KDE n'utilisera pas PulseAudio avant 4 ou 5 ans...
PulseAudio va être intégré à Gnome dans les mois (voire semaines) à venir.

Les diapos d'une présentation de pulseaudio :
http://0pointer.de/public/pulseaudio-presentation-lca2007.pd(...)

What can we do?
[...]
- We should stop abstracting abstracted abstraction layers

Tout allusion à un "truc" ne serait pas un hazard.

C'est le diaporama de cette présentation (voir les deux (vidéo et diaporama) en même temps est cool) :
http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talk(...)

Ça marche chez moi avec mplayer et totem (version 2.16).

> tu crois que Linux aura plus de chances avec l'OPLC ??

Avec le "marché" actuel, le matos actuellement disponible, etc, je pense que oui.

> Mandriva a beaucoup investi (l'un des principaux mainteneurs de KDE est là-bas depuis qq mois).

Impressionnant. Mais Mandriva a plus investi dans des bêtises comme Mandriva Club.

> En plus, le fait que le gouvernement Nigerian ait payé le contrat montre que Microsoft a du avancer les brousoufs.

Et ?
Oui MS est bourré de tune que c'est un problème majeur pour le concurrencer.
Mais Red Hat/Fedora fait de même. L'OS pour OLPC est "offert". Red Hat paye plusieurs développeurs (et pas seulement 1 comme Mandriva) qui ne bossent que sur OLPC (et pleins d'autres qui bossent sur OLPC en pointillé).

Puisque je me fais moinser, je vais expliquer si jamais les gens n'ont pas compris.

Comme il y a "Mandriva" dans le post précédent, il y a 90 % de chance que ce soit ça qui dérange :
- "Mandriva c'est fait baisé."

Le boss de Mandriva doit probablement penser qu'il s'est fait enculé. Donc...

Que Mandriva porte la distribution Mandriva sur Classmate, c'est très bien. C'est un hardware, Mandriva fournit un OS libre, c'est nickel.
Que Mandriva espère faire du couple Mandriva/Classmate un concurrent de OLPC est une connerie. Au moins pour l'instant (vu le type de demande actuel, vu le mato disponible actuel, vu que Windows n'existe pas sur OLPC, etc).
Certes, il faut accèpter que OLPC soit concurrencé. Évidemment. Et aussi par MS. Évidemment. Et il n'y a pas à s'offusquer que MS fournisse son OS gratuitement.
Mais concurrencer OLPC, sur son "marché", avec Classmate est une connerie pour une société qui vit du libre.
Plus il y a de OLPC, plus il y aura de serveurs Mandriva ou desktops Mandriva à l'avenir dans les pays émergeant. Plus il y a de Classmate, plus il y a d'opportunité pour MS de diffuser Windows, moins il y aura de serveur/desktop Mandriva à l'avenir.

OK, l'OS de OLPC est fournit principalement par Red Hat/Fedora qui sont des concurrents de Mandriva. Et alors ?
OLPC est du hardware. Mandriva doit probablement pouvoir demander des versions sans OS pour y installer le sien (MS va probablement le faire). Il y a une belle opportunité ici. OLPC/XO cible les enfants. Peut-être que Mandriva peut faire une distribution qui cible les ados ou plus avec une distribution spécifique, plus orienté ligne de commande, plus "un pied dans le monde Unix". Ou même tout simplement proposer une alternative car certains vont probablement se lasser de XO.

Ça c'est pénétrer les pays émergeant sans se tirer une balle dans le pied comme vient de le faire Mandriva.

Il y a un truc très étrange. Probablement des millions de OLPC vont être diffusé, et il y a que Red Hat/Fedora qui propose quelques de sérieux (pas seulement un truc de "geek"). Il y a largement la place pour un autre distributeur de proposer une alternative. Ça serait beaucoup plus intelligent que de pousser Classmate.

Classmate c'est que du bonheur pour Windows. C'est que du bonheur pour saboter OLPC et la diffusion du libre. Pas seulement du logiciel libre, mais l'idée globale du libre.
Mandriva c'est fait baisé.

Il y aura Windows pour OLPC. Mais ça prendra plus de temps et ne sera probablement pas aussi sexy et/ou adapté (la cible est des enfants)

C'est très bien d'avoir cette posibilité. Pas de problème.
Mais ce n'est pas spécifique à FreeBSD (contrairement à ce que tu laisses croire) et c'est assez commun dans Linux. Voila ce que je veux dire.

Juste un exemple, koji de Fedora :
http://koji.fedoraproject.org/koji/

Il va chercher dans le cvc :
http://cvs.fedoraproject.org/viewcvs/

Tu peux installer koji en local sur ta bécane ainsi tu peux aussi construire les paquets que le développeur trouve "risqué".

M'enfin, la branche Rawhide fait très bien l'affaire.

> c'est vrai que c'est un doublon inutile et plus compliqué que l'original.

C'est clairement un doublon. Ça vient de "to encode" (anglais) qui veut coder. C'est du franglais bien stupide.

> Même nos immortels qui ne sont pourtant pas des "geeks" le mettent dans leur dictionnaire :-)

Le français est une langue vivante, il faut suivre les usages qui en sont fait. Même quand c'est stupide.

> encodage UTF-8

codage UTF-8.

Demande je vais encoder en Java pour enlargir les plateformes supportées. Faut que je désencode du mp3 pour l'encoder en vorbis.

Dites coder.

Mouaif. Tu fais ça pour deux ou trois paquets.

Sinon il y a plusieurs distributions qui le propose aussi. On en parle peu car c'est très limité comme cible. Surtout que les paquets sont déjà compilés...
Toutes les versions ne sont pas compilées, c'est le mainteneur qui décide si ses modifications peuvent être testées avec un risque raisonnable. Tester tout ce qui se passe sur un CVS sans discernement n'est pas une bonne idée. Vraiment pas.

> Tu disais que c'etait stupide d'avoir 2 specifications pour un même domaine,

Non. Je disais qu'il était stupide d'avoir 2 standards pour un même domaine.
OOXML et ODF sont deux standards différents. Évidemment que se sont aussi deux spécifications différences, mais ça c'est une conséquence.
Xhtml 1 et Xhtml 2 font parti du même standard (d'où le soucis très élevé de compatibilité ascendante, etc).

> Je te laisse en tirer tes conclusions.

Ne fais pas de tes conclusions mes conclusions.

> Sauf que la il s'agit bien de DEUX standards.

Non. Xhtml 2 fait hypra attention à ce que les navigateur xhtml 1 puissent lire du xhtml 2. C'est ainsi car c'est le même standard. C'est une quasi obligation.
OOXML en a rien à foutre qu'un lecteur ODF ne puisse lire du OOXML. Ceci car OOXML et ODF sont des standards différents.

> "il ne doit en rester qu'une"

J'ai dit ça ?

> Maintenant si tu défend tes convictions je te suggère de partir en guerre contre HTML 5.

Et ? Il y a des travaux, voilà, j'ai rien de plus à dire. Des spécifications d'html il y en a plusieurs, des versions spécialisées aussi, etc... Mais c'est le même standard. Je n'ai pas un navigateur pour html 4, un autre pour xhtml, un autre pour xhtml 2, un autre pour xhtml 5, etc... Si j'ai un "lecteur" xhtml 2 ou 5, il sait lire aussi du xhtml 1 (à quelques détails près).
Par contre il y aura des suites bureautique pour OOXML et des suites bureautiques pour ODF. Si j'ai un "lecteur" ODF, rien ne garantit qu'il peut lire du OOXML (et vice versa).

Tu ne veux pas comprendre, ben ne comprends pas.

> CDF, qui apporterait une totale compatibilité avec les formats de MSOffice (il ne précise pas comment).

Ça semble une arnaque. CDF permet d'utiliser d'autre format. Donc on devrait pouvoir mettre un document OOXML (ou n'importe quoi) dans CDF.
Si CDF est compatible OOXML, il l'est au moins autant avec ODF.

Tu nous fais des arguments à la pBpG.
Oui, xhtml évolue. Avoir UN standard pour les pages web, n'implique pas que ce standard ne doive pas évoluer. ODF est un standard. OOXML n'est pas une évolution de ODF. Je me trompe ?

1.1.2. Backwards compatibility :
http://www.w3.org/TR/xhtml2/introduction.html#backCompat

Because earlier versions of HTML were special-purpose languages, it was necessary to ensure a level of backwards compatibility with new versions so that new documents would still be usable in older browsers. However, thanks to XML and style sheets, such strict element-wise backwards compatibility is no longer necessary, since an XML-based browser, of which at the time of writing means more than 95% of browsers in use, can process new markup languages without having to be updated. Much of XHTML 2 works already in existing browsers; much, but not all: just as when forms and tables were added to HTML, and people had to wait for new version of browsers before being able to use the new facilities, some parts of XHTML 2, principally XForms and XML Events, still require user agents that understand that functionality.

Tu me donnes le rapport avec OOXML et ODF ?

Si la compatibilité est si importante, alors que MS reste à l'ancien format.

> 2.6.24 de Linux qui devrait sortir d'ici moins de deux mois

J'ai du mal à le croire. Le patch rc1 est un record en taille (à la grande surprise de Linus) :
http://article.gmane.org/gmane.linux.kernel/594585

it really is quite impressive.

Si je me trompe, tant mieux.

J'y pense maintenant.
Ce qui est marrant avec ton argument, c'est que MS n'arrête pas de dire qu'il faut des standards (pour un même domaine). Je ne revient pas sur la stupidité du truc, c'est comme dire qu'il faut plusieurs html (par exemple optimisé IE et optimisé Firefox...). Pour des formats de donnés (donc l'intéropérabilité) c'est définitivement une connerie.

Mais MS dit "il faut des standards", mais n'oublie pas d'ajouter "compatible avec nous". Très commique.

> Tu esperes que les gens vont migrer sans l'assurance d'etre compatible avec 85% du marche ? Tu reves.

En passant, MS sort des trucs qui ne sont pas compatible avec 85 % du marché. MS sort silverlight et ce n'est pas compatible flash par exemple.

C'est très très discutable.
Je suis très très favorable a assurer la compatibilité avec OOXML au mieux. Comme il y a Samba. Mais ça ne doit pas être la priorité. La priorité c'est l'excellence. Il ne faut pas perdre notre "âme".

Es-ce que pdf est très compatible OOXML ? Je ne crois pas et pourtant ça n'empêche pas pdf d'être très utilisé. Et HTML ? Ce n'est pas très compatible OOXML ...

La compatibilité entre format OOXML et ODF est satisfaisante. Évidemment avec l'utilisation d'un convertisseur. Au moins 95 % des documents sous OOXML (ou l'ancien format de MS) peut être converti en ODF sans gros bobo.

Le format ODF va évidemment encore évoluer. Mais ce dont à réellement besoin ODF, c'est d'une suite qui roxe et beaucoup plus ergonomique. C'est en cours. C'est beaucoup plus important que d'intégrer à ODF les conneries de OOXML.

Le bench fait par FreeBSD est très bien, et je ne passe pas que celui qui a fait le bench est malhonnète.

Lors des premiers benchs, FreeBSD a révélé un bug dans glibc. Grand merci à FreeBSD. Mais ça date de Mars 2007 environ !
Maintenant, 6 mois après, FreeBSD nous fait "TATA : on met une branlée à Linux !" et communique beaucoup sur ça car FreeBSD sort sa version 7.0.

Ce n'est pas cool et limite puant. Linux doit foutre une branlée à FreeBSD dans pleins d'autres benchs. Mais quand Linux sort, Linux ne dit pas "TATA : on met une branlée à FreeBSD !".

> Ben justement, si tu les lis, selon eux ODF n'est pas vraiment ouvert.

Tout ça c'est du FUD.
Es-ce que KDE se plaind ?
Es-ce que IBM qui participe massivement à ODF maintenant gueule ?
Tout est public, arrêtons avec ces conneries.

> faut croire qu'ils savent de quoi ils parlent...

Je crois que la machine lobbying de MS marche à plein et que certains ont perdu leur âme.

On a Miguel de Icaza qui dit qu'OOXML est un superbe standard. D'autre sont là pour ternir l'image d'ODF.