> Les deux ont leurs arguments, les deux ont le même objectifs, et les deux s'y tiennes
J'ai bien compris. Je tenais seulement à dire que s'ils n'ont pas les mêmes objectifs, on ne peut pas en conclure qu'ils n'ont pas un soucis de la qualité aussi élevé.
> Bon bah je vais corriger un peu mon commentaire. Après lecture du message suivant -- http://linuxfr.org/comments/746741.html#746741 -- j'ai été intrigué par la remarque de Clearstream affirmant que BSD n'était pas compatible GPL
Je n'ai pas dit tout à fait ça. J'ai dit :
- "la licence BSD est incompatible avec du code GPL."
Si le projet est sous BSD, le code doit respecter la licence du projet. Si le code est sous GPL, ça coince.
Si le projet est sous GPL, le code doit respecter la licence du projet. Si le code est sous BSD ou GPL, c'est OK.
Je dis peut-être des conneries car je ne connais pas sur le bout des doigts HAL, mais j'ai l'impression que tu te trompes de cible.
Du moins si l'objectif est de gérer les périphériques USB.
D'ailleurs Fedora va retirer kudzu pour tout faire avec HAL (pour FC6 ou FC7).
Et il manque un outil pour configurer les fichiers hdi !
Reconnaissons que la tâche est beaucoup plus compliqué mais l'outil est également beaucoup plus puissant.
Je ne vais pas ici te faire un topo sur HAL. Je te conseille vivement de te renseigner sur HAL.
Pour /etc/fstab, la décision a été prise de ne plus l'éditer pour les périphériques amovible. Sous gnome c'est gnome-volume-manager qui monte ou démonte les périphériques et on peut le faire à la main avec gnome-mount. Ce n'est pas une solution qu'il m'emballe, mais l'autre avait de sérieux problèmes techniques.
J'avais mal interprété la news, tu as brillament éclairi les choses.
> * La méthode principale de QA (quality assurance), en simplifiant à peine, est pour Debian le testage intensif à grande échelle et la correction systématique des RC bugs ; pour OpenBSD, ce serait plutôt re-audit permanent du source, son "nettoyage" progressif, et l'intégration régulière, dans ce code, de nouvelles méthodes de renforcement.
Je n'aime pas quand on dit que tel projet est plus centré sur la qualité qu'un autre (ce qui n'est pas ton propos il me semble).
Si on prend Ubuntu ou Fedora, la qualité n'est pas négligée. Simplement ces distributions ont aussi d'autres exigences (faire évoluer le logiciel libre, explorer de nouvelles voix, faire un bureau exitant, "rester dans la compétition"). En considérant les contraintes et les ressources disponibles, la qualité est formidable. Ce n'est qu'en parti dû aux distributions et le mérite en revient principalement aux développeurs des projets respectifs qu'on retrouvent dans les distributions.
La qualité ne se résume pas à : "j'intègre ça car c'est stable, je n'intègre pas ça car ce n'est pas stable". Ca c'est une politique pour délivrer quelque chose de stable. Les distributions "professionnelles" le font.
La qualité est un soucis permanent qu'on "s'inflige", qu'on soit en phase de développement ou sur un vieu logiciel dont la fiabilité est le critère numéro un.
Compte-tenu de la rapidité d'évolution de Linux, Linux serait un désastre s'il n'avait de hautes exigences qualités.
Sans pouvoir l'affirmer, je pense que Linux a autant le soucis de la qualité que les *BSD. Mais Linux est moins centré sur la stabilité.
Pour faire une analogie, les équipes qui construisent des F1 ont des critères de qualités extrèmement élevés. Mais comme elles ont la contrainte de devoir gagner des courses, ben la F1 a une durée de vie ridicule.
> D'ailleurs, certains projets "externes" au noyau ont été mis en place sous Linux pour mettre un peu d'ordre (e.g. : http://janitor.kernelnewbies.org/ ),
Heu, non, http://janitor.kernelnewbies.org/ n'a pas ce rôle. Mais c'est un excellent travail pour ceux qui veulent s'initier au développement de Linux (ça c'est le rôle de janitor).
> alors que c'est fait directement par les développeurs du noyau sur les Net/OpenBSD (je ne connais pas bien FreeBSD).
C'est aussi fait par les développeur Linux. Mais ils ne vons pas refuser un coup de main de janitor.
> Avant l’acception de tout code dans le noyau ou le userland, celui-ci doit être étudié, validé, codé et « propre », afin d’assurer sa pérennité, il est donc audité par les développeurs, et met très longtemps avant d’être intégré dans le CVS, et encore plus à rentrer dans la branche stable du développement.
Pour ce qui est du noyau, demande l'avis de Reiser. Linux audite aussi le code, etc...
Il peut être très long (plusieurs mois, voire années) pour être intégré à Linux.
> La réutilisation du code est grandement facilitée
Sauf que la licence BSD est incompatible avec du code GPL. Heureusement beaucoup de driver sous Linux ont la double licence (BSD/GPL).
Juste pour info, c'est Xavier qui a insisté pour que je réponde à son commentaire : http://linuxfr.org/comments/746145,1.html
Certe, je n'étais pas obligé et ton commentaire n'est pas "inspiré" uniquement par ce dernier thread.
> Déjà ca ne fait que mettre en version N-1 et donc mettre un retard "constant"
Sur une version oui. Sur une succession de version non.
Comment avoir des retours d'utilisateur s'il reste en version N-1 ?
Pour que le logiciel libre évolue vite, il faut des utilisateurs sur la dernière version. Pas sur une version qui a peu d'intérêt pour les développeurs.
> et encore xorg 7.1 est une sorte d'exception
Pas du tout. C'est récurrent comme problème.
> pour xorg 7.0 que je me souvienne j'ai pas eu de probleme
Il y en a eu.
> De plus les développeurs du drivers NVIDIA aident activement Xorg
Bof. En tout cas ils n'aident pour avoir des drivers libres.
> ils ont poussés à inclure dans Xorg une modification qui a rendu le driver NVIDIA incompatible avec Xorg 7.1!
C'est juste. La motivation première de Nvidia, n'est pas la "communauté" mais les distributions "professionnelles" qui sortent bien après les distributions les plus "hypes".
> En plus X11R7.1 est relativement récent, est-on vraiment à 6mois
Trois mois je crois. Largement assez pour porter les drivers. D'ailleurs tous les drivers libres était OK dès la sortie de Xorg 7.1.
Je crois que tu n'as pas lu ou pas assez attentivement l'article de lwn.
Jusqu'à maintenant, Fedora ne se souciait en aucun cas des drivers propriétaires. Il y a peu (avec la sortie de Xorg 7.1), Fedora a pris une décision en prenant en compte les drivers propriétaires. Fedora allait fournir Xorg 7.1 en mise à jours de FC5, mais c'est rétracté car des utilisateurs de drivers proprios ont gueulé.
C'est nouveau, et selon moi regrettable car on a privilégié les utilisateurs de drivers propriétaires sur les utilisateurs de drivers libres. On a retirer de la liberté au libre.
Par rapport à Fedora, il faut relativer. Cette décision ne dicte pas les décisions à venir.
Plusieures choses :
* pour les mises à jours de sécurité ou bug important, Fedora montera toujours en version. Donc si un trou de sécurité est trouvé dans Xorg 7.0, Fedora fournira Xorg 7.1 comme correctif. Pas de backport.
* Mike Harris, mainteneur de Xorg pour Fedora, voulait Xorg 7.1 dans FC5. Le remplaçant de Mike Harris (ce dernier est parti prendre des vacances prolongées, merci à lui pour son excellent travail) ne met pas Xorg 7.1 pour FC5 dans ses priorités (c'est 2 ou 3 jours de boulot) et préfère se concentrer sur FC6 (actuellement en développement). Si ça ne tenait qu'à lui, il ne le fairait pas (pour ce cas spécifique) et ça n'a rien à voir avec les drivers proprio.
* Lors de cette épisode, Rawhide avait Xorg 7.1 depuis longtemps, FC6 test2 était sorti avec Xorg 7.1. Donc Xorg 7.1 était assez intensivement testé même sans la disposition de Xorg 7.1 dans FC5.
* Cette décision de ne pas fournir temporairement Xorg 7.1, n'impacte en rien les développeurs. D'ailleurs la branche testing (celle utilisée pour tester les mises à jour) reste totalement ouverte à toute chose qui peuvent casser les drivers proprio. Si Mike Harris n'avait pas quitté Red Hat, c'est là que serait Xorg 7.1 pour FC5. Et si un trou de sécurité était trouvé dans Xorg, ce même Xorg 7.1 (avec la dernier version CVS qui a le correctif) se serait retrouvé dans les mises à jour.
Afin, il y a quelques travaux sur http://www.livna.org/ (qui fournit des paquets pour les drivers Nvidia proprio et autres) pour que lorsque le driver proprio est installé, une mise à jours de Xorg ne soit pas possible sans que le driver n'ait pas été mis à jours pour la nouvelle version du serveur. C'est très facile à faire.
Malheureusement tout le monde n'utilise pas livna mais récupère les drivers sur le site de Nvidia. Dommage que NVidia ne fournisse pas ses drivers au format rpm ou dpkg pour ne pas avoir ce problème (surtout que c'est fait pour ça).
Sinon les utilisateurs de drivers libres se sentirait un peu moins en otage de drivers proprio et pour FC5 serait déjà sous Xorg 7.1.
> En effet, je dois être naïf pour avoir laissé ces commentaires en espérant une réponse sensée et constructive.
Tu parles des librairies wrappées par Qt et tu n'es même pas allez vérifier. Pourtant avec un "rpm -q --requires" ou un ldd ça se fait vite. Une ligne de commande seulement.
Je ne voulais pas répondre à ton commentaire au début. T'as demandé une réponse, je l'ai fait et voilà.
Si tu voulais du "oui, oui, oui", t'as frappé à la mauvaise.
> gst devrait déjà faire ses preuves pour les besoins de base
C'est fait, c'est utilisé par Gnome depuis plus d'un an qui n'utilise que Gstreamer.
Notes que Phonon n'a toujours pas fait ses preuves...
> cf les commentaires plus haut
Apparament la personne a oublié d'ajouter des plugins. Si elle ne veut pas se renseigner avant d'utiliser quelque chose, Gstreamer n'y est pour rien. Les modules sont à un click de la page d'accueil du site de Gstreamer.
Tu crois que Gstreamer ne supporte pas mp3 car quelqu'un le dit ?
Mp3 est supporté par Gstreamer depuis la nuit des temps.
Tu crois que Gstreamer ne supporte pas le réseau car quelqu'un le dit ?
Gstreamer support tcp, udp, gnomevfs (il ne tient qu'à KDE de faire l'équivalent), et rtp*. Un exemple qu'il y a plus d'un an : http://linuxfr.org/comments/581662.html#581662
Rhythmbox qui utilise gstreamer permet d'écouter la radio sur internet et rtp* pour les videos real.
Tu crois que Gstreamer ne supporte pas les DVD car quelqu'un le dit ?
Gstreamer supporte les dvds cryptés ou pas depuis longtemps. A vu de nez peut-être depuis au moins 2 ans.
T'es un peu naïf.
Sur ma bécane, j'ai 82 modules offrant 487 fonctionnalités. Il manque principalement le support pour dvb.
> L'avantage est _jutement_ de ne pas s'enchaîner à un élément extérieur non maîtrisé.
Le développeur est enchaîné à Phonon dont l'api ne doit pas bouger durant en gros 5 ans (la durée de vie de KDE 4) et Phonon est enchaîné aux frameworks.
> L'avantage est _jutement_ de ne pas s'enchaîner à un élément extérieur non maîtrisé.
Et Arts, qui le développait ? Ce n'était pas KDE par hazard ?
Ben oui. On a vu ce que ça a donné.
Ce n'est pas parce que KDE fait quelque chose que c'est forcément parfait ou mieux que les autres.
> L'API de phonon pourra être étendue au fil des avancées des backends
Des extensions seulement. Si une fonctionnalité casse la compatibilité, il faudra attendre KDE 5 (au moins 5 ans).
Et si personne veut étendre Phonon comme c'est arrivé avec Arts ?
Je répète, ce n'est pas parce que KDE gère le projet que tout est forcément rose.
> mais sera toujours sous contrôle.
Super.
Comme ce n'est fait que pour le framework multimédia, je peux en conclure que tout le reste n'est pas sous contrôle.
> Et non, ce n'est pas un travail surhumain de maintenir phonon.
Arts non plus ce n'était pas un travail surhumain.
> QT est la librairie de base des programmateurs KDE (avec kdelibs), qui permet (entre autres) d'avoir une API/ABI stable et unifiée au dessus de plein de libs (Xlib, libpng, libxml, ...) [ réponse à
Vérifies toi même, les libs que j'ai sité ne sont pas "wrappées" par Qt (je n'ai pas sité Xlib). Qt wrappe presque rien (vérifies toi même).
> J'imagine même que la plupart des plugins de gestion des backends seront maintenus par un gars de l'équipe de dev du backend concerné.
Ben si les autres s'en chargent... C'est rien comme boulot. Ils doivent bosser sur leur frameword ET sur Phonon maintenant. Pour KDE c'est que du bonheur surtout que tu dois penser que les développeurs de framework n'ont que ça a foutre.
> - Le "plus petit dénominateur commun" de gst/xine/mplayer est quand même énorme : lire des vidéos, des sons, streaming, mixer, equalizer, effets vidéo, ... tout le nécessaire pour la quasi totalité des applications desktop (knotify, amarok, kaffeine, kmix, krec, ...),
Donc tous les développements actuels sur les frameworks sont inutiles puisqu'il y a déjà tout le nécessaire selon toi.
J'imagine que quand les autres fairont mieux, tu vas te persuader que c'est inutile car t'as déjà "tout le nécessaire pour la quasi totalité des applications desktop".
> Pour la MAO, il vaut mieux de toute façon passer par jack que gst/xine.
Jack ne fait pas la vidéo. Gstreamer oui. Quand avec Gstreamer et une bête caméra USB à 2 sous on pourra éditer ses propres films, ajouter des commentaires ou une musique de fond en deux cliques tu vas penser que c'est inutile pour l'utilisateur moyen. Au mieux KDE offrira ça par défaut dans KDE 5. Pas avant 5 ans...
> - Comme dit plus haut, c'est du "sucre" pour les développeurs
Il vont peut-être s'économiser 10 lignes de code pour rester enchaîné à Phonon. Au moins avec ce sucre ils ne risque pas grossir.
> à part des soucis en moins dans amarok quand gstreamer change d'API
Ce qui arrive tout les ans (13 mois entre 0.8 et 0.10) et le rythme va forcément décroitre. Si ton appli est simple (type une appli qui utilise Phonon), c'est l'affaire de 1 jour maximum pour passer de Gstreamer 0.8 à 0.10 et avoir plus de fonctionnalité. Avec Phonon pour avoir plus de fonctionnalité, il faut "seulement" que tu changes complètement d'API.
> Maintenant, clearstream, qu'est-ce qui te révolte tant ?
> je sais pas comment vous faîtes parce que les news (une grosse dizaine en 2 ans, pas terrible) que j'ai proposées ont toujours été :
> - acceptées (avec éventuellement des corrections) - 90% des cas
Parce que t'on profile est dans le politiquement correct de Linuxfr.
Linuxfr est souvant abhérant dans sa modération. Par exemple Red Hat qui achete à 50 million de $ Netscape Directory Serveur et annonce le mettre en libre prochainement, ben ça passe en seconde page (et même pas dans la catégorie Red Hat ; bonjour la reconnaissance). Faire une connerie, ça arrive à tout le monde. Mais les modérateurs dans leur "grande sagesse" n'ont pas voulu la corriger ! Par contre une beta de l'installeur Debian ou un contrat de 1 million pour Mandriva, ça passe en première page. On a atteind le sommet avec SuSE où Linuxfr trouvait toujours de nouveaux prétextes pour ne pas passer les news SuSE (on ne le fait pas à cause de Yast, c'est car on refuse les news de distributions payantes, etc). Pourtant SuSE était (et est toujours) un acteur majeur du libre et les utilisateurs de SuSE sont manifestement des utilisateurs de logiciel libre. Aujourd'hui linuxfr n'a toujours pas fait de section Fedora. Pratiquement tous les autres sites l'ont fait mais toujours pas Linuxfr. Pourquoi ? Parce qu'ils ne veulent pas. Bien sûr qu'ils vont trouver une raison à ça. Que les utilisateurs de Fedora disent utiliser Fedora et non Red Hat, ils s'en foutent.
C'est comme ça depuis longtemps et ça restera comme ça. Les modérateurs sont accèptés que s'ils sont politiquement correct selon l'interprétation de Linuxfr. Ceux qui n'ont pas l'esprit linuxfr sentent intuitivement qu'il leur est inutile de proposer une news. Donc ils confortent l'esprit linuxfr et l'aparente équité affiché via les stats de news refusées.
Pourquoi en discuter, ça fait la cinquantième fois que le sujet revient sur le tapis, ça fait la cinquantième fois que des contributeurs en news dirent qu'ils ne refairont pas de news, ça fait depuis des mois qu'il y a de moins en moins de contribution en news et le site plait aux administrateurs. Ils le font bénévolement et reconnaissont que linuxfr est un site fabuleux grace à eux. Toute requête est vaine et on ne peut en faire reproche.
> Ce qui elimine directos gstreamer vu qu'il ne sait pas lire les dvd encryptés
Il sait lire les dvd crypté (et pas encrypté).
> je n'ai toujours pas vu un truc pour le lier a dvdcss
Il utiliser un plugin (qui utiliser dvdread qui s'occupe de css)
> qu'il ne sait pas streamer
Il sait streamer.
> qu'il ne sait pas lire plein de format audio (mp3 pour le plus courrant)
Il lit plein de format audio et mp3 notament.
> comme clearstream arrete pas de faire des reproche sur KDE a cause de QT lie a trolltech
J'ai fait des reproches sur ça ? Je n'ai pas fait le moindre commentaire avec le mot "trolltech".
J'ai fait le constat que KDE était lié à Qt (comme Gnome est lié à Gtk) et que ce n'étant en rien un soucis pour eux mais qu'être lié à Gstreamer est un soucis pour eux. J'ai fait ce constat (en prenant Qt et d'autres librairies) pour "dénoncer" ce deux poids deux mesures.
Pour Gstreamer, il est très très modulaires et utilise les plugins. Très probablement tu n'as pas installé les plugins non libre.
Il y a :
gstreamer-plugin-base
gstreamer-plugin-good
gstreamer-plugin-ugly
gstreamer-plugin-bad
C'est aussi du pur pragmatisme que de vouloir corriger le logiciel libre là où il sucks.
> il ne peuvent pas prendre la responsabilité de trop se lier à un framework.
Mais il le font pour Qt, etc...
Tout le monde le fait et par pragmatisme.
> J'espère aussi que les frameworks multimédia gagnent en maturité et qu'on arrivera à en avoir 1 ou 2 activement soutenus qui sortiront du lot. Dans KDE5, qui sait ?
Si c'est ce type de problème, RedHat/Fedora a un petit truc sympa (c'est vieu, ça doit dater de Red Hat 6).
Si le serveur ne se lance pas, il reconfigure X11 en VGA (pas de driver spécifique) puis lance X11 à nouveau.
> et non pas a cause d'une liaison gnome/gstreamer, argument stupide
Qu'es-ce qui te garantit que Qt sera stable durant toute la vie de KDE 4 ?
Qu'es-ce qui te garantit que libjpeg, libxlst, libxml, libsvg, libpcre, libpng, libpgpgme, libnetsnmp, libdbus, libhal, libsmb, et encore une dixaine d'autres librairies non développées par KDE et utilisées par KDE resteront stables durant toute la vie de KDE ?
KDE a-t-il prévu des "phonons" pour toutes ces librairies ?
Non.
Alors pourquoi ce "traitement de faveur" pour Gstreamer ?
A part une raison stupide, je ne vois pas.
> Gstreamer est encore un projet jeune, et qui non seulement ne peut encore garantir de compatibilité binaire, mais meme pas de compatibilité source comme l'a montré le passage 0.8->0.10.
Premièrement, Gstreamer n'a pas cherché à garantir la stabilité de l'API entre la version 0.8 et 0.10. Donc la question de ne pas pouvoir ne se pose pas, car Gstreamer ne voulait pas. Comme KDE ne veut pas garantir la compatibilité entre KDE 3 et KDE 4. La version 0.9 (de développement) était dès l'origine incompatible avec la version 0.8 et c'était prévu avec sa création. La version 0.9 était dès l'origine installable à côté de la version 0.8 (pour conserver une API stable).
Linux est pire que Gstreamer, il n'y a ni ABI et API stable entre versions mineures (x.y.n et x.y.n+1).
Remarquons le culot dont à fait preuve KDE à propos de l'incompatibilité entre gstreamer 0.8 et 0.10 en disant que ça a casser les applis des utilisateurs après une mise à jours. N'importe qu'elle gestionnaire de paquet digne de ce nom aurait refusé de mettre à jour gstreamer 0.8 vers 0.10 si des programmes utilisent gstreamer 0.8 et ne sont pas disponibles en version gstreamer 0.10.
C'est le boulot des gestionnaires de paquet !
Remarquons le culot de KDE de dire que gstreamer 0.10 a introduit des bugs qui n'existaient pas dans gstreamer 0.8. Je suis sûr à 12 000 % que KDE 4 va ajouter des bugs qui n'étaient pas dans KDE 3 et qui ne vont pas être corrigés ni dans la semaine et ni dans le mois de la sortie de KDE 4.
Et quel culot de la part de KDE de critique la maintenance de Gstreamer alors que KDE n'est pas foutu de maintenir Arts qui fait le quart du huitième de ce que fait Gstreamer.
Quand on fait preuve d'un tel niveau de FUD, il y a quelque chose de stupide, de crétin, qui se cache.
> KDE aurait pris Xine par exemple (qui n'est peut-etre pas exempt du probleme de la compatibilité binaire), on aurait crié à la sission, à la fragmentation, et à la duplication inutile d'effort entre KDE et Gnome.
Ben avec Phonon, KDE "garantit" la sission des frameworks durant tout KDE 4. Inutile d'instrumenter Gnome pour le constater.
> Si le backend X a un bug, je ne vois pas en quoi c'est lié à Phonon
Je considérais le cas où Phonon a un bug avec un backend spécifique.
> ni en quoi ça constitue un échec pour lui.
OK, l'argumentaire était mal foutu.
> Au contraire, dans ce cas-là, l'intérêt saute aux yeux.
Il saute au yeux si on part du principe que le logiciel libre n'est pas foutu d'avoir un framework qui ne sucks pas et que Phonon roxe. J'ai déjà argumenté sur ce point.
Si le libre fait un framework qui roxe comme Xorg ou est l'intérêt d'avoir deux ou plus serveurs X11 différents et une couche au dessus pour basculer de l'un à l'autre s'il y en a un qui sucks ? Il y a un intérêt sur le papier mais la quantité de ressource pour fiabiliser tout ça est énorme, beaucoup plus énorme que de faibiliser seulement Xorg. Hors les ressources du libre sont assez limités.
Tu peux facilement balayer mon argument en disant que l'histoire montre que les frameworks multimédia libres sucks et que je suis un gros naïf.
Mais voilà, je ne veux pas croire que celà va perdurer, je ne veux pas que ça perdure.
> Si un backend est vraiment mauvais (i.e. pas d'amélioration au fil des versions), il sera peu utilisé et le backend sera abandonné. Où est le problème ?
Dans le contexte actuel où les frameworks sucks, t'as raison.
Mais pourquoi diable il faudrait se résoudre à croire que le logiciel libre ne peut que merder que les frameworks multimédia ?
> 1) Il y a la question de la stabilité de l'API. Même en contribuant beaucoup à un framework, les dev KDE ne seront jamais maîtres de l'API.
C'est vrai. Mais c'est vrai aussi pour plein de domaines et c'est aussi vrai pour Gnome et en fait vrai pour tout le monde.
La stabilité API, ça peut être fait très simplement et ce n'est pas la montage que sous-entend KDE. Par exemple il y a longtemp eu Gtk 1.x alors que Gtk 2.0 était sorti depuis longtemps. Il n'a pas été fait une encapsulation au dessus de gtk2 et gtk1. Conserver Gtk 1.x n'a pas été une montage de boulot (quoique le "split" n'a pas été simple au début). Tous les Gnome 2.x ont esound pour conserver la compatibilité. Ca ne représente pas beaucoup de boulot (voir zéro) et sûrement moins que de maintenir Phonon pour qu'il suive les modifications d'API de plusieurs backends. La nécessité de compatibilité n'entrave pas l'évolution de Gnome (ajout de Gstreamer durant la branche 2.x, et vas savoir si Xine ne va pas pointer le bout de son nez durant Gnome 3.x s'il roxe) alors que l'évolution de KDE sur plusieures années (la durée de vie de KDE 4) est contrainte au plus petit dénominateur commun des backends et ils se donnent beaucoup de boulot.
> Conséquence directe, quand l'API d'un framework change, ce n'est pas toutes les applis qui doivent s'adapter, mais seulement Phonon.
Oui. Mais il faut aussi se demander s'il n'est pas plus pertinant d'adapter les logiciels aux dernières évolutions. Dans le domaine du desktop où l'utilisateur veut du "dernier cri" et où les développeurs se font fort de répondre aux attentes des utilisateurs, ce n'est pas à sous-estimer. Surtout aussi que les développeurs du libre aiment utiliser le "dernier cri" et non "trainer" avec du "has been".
Certes, tout ceci est assez voire très subjectif. Mais tu crois que les utilisateurs de Linux dans leur ensemble seraient plus content aujourd'hui si depuis le début de Linux 2.6, Linux avait conservé une compatibilité "obsolue".
Oui la politique de Linux 2.6 parfois sucks (le driver bidule qui explose en vole lors du passage de Linux 2.6.n à 2.6.n+1 par exemple). Mais la politique de la stabilité absolue sucks, et gravement, dans des domaines aussi dynamiques que le desktop.
Si la politique de Phonon était l'évidence, alors la politique de Linux 2.6 serait évidente de stupidité.
La compatibilité "absolue" est importante pour des cas comme php. Pour php, des *milliers* de site en production et "sensibles", chaqu'un avec des milliers de lignes de code php spécifiques, en dépendent.
Pour un backend multimédia, c'est une poignée d'application pour un service qui n'est pas critique (mais important).
Pour te montrer que la stabilité de ABI n'est pas si importante que ça, et notament dans le logiciel libre, je te donne des exemples. Les binaires de FC5 ne marchent pas sur FC4 et inférieur. Pratiquement personne ne l'a remarqué !
Pour FC6, ça sera encore comme ça !
Il ne sagit pas de une ou deux applis, mais de toute les applis livrées par FC et FE.
Considères aussi Xorg. Xorg casse les binaires (côté driver) pour faire avancer les choses et 2 ou 3 semaines après tout est rentré dans l'ordre pour le bénéfice de tous. Ce n'est pas un point faible du libre/Xorg mais un point fort (malheureusement pas toujours compris).
Esound est un bonne exemple qui montre qu'il n'y a pas toujours de fortes exigences en compatibilité binaire dans le desktop. Bien que esound soit le "standard" supporté par Gnome pour la branche 2.x, presque aucune distribution ne le livre maintenant car presque aucune application ne l'utilise encore. Elles sont toutes passées à autre chose. Je crains que Phonon, à l'instar de Esound et aussi Arts, subisse le même sort.
> Mais tu trouvera toujours un utilisateur qui voudra celui que tu n'as pas choisi, pour une raison X ou Y, recevable ou non, mais dont il ne démordra pas.
C'est très juste. Mais je ne crois pas que le logiciel libre y gagne en considérant que c'est la règle.
Il faut respecter cette liberté, non considérer que c'est la règle.
> D'où la très grande utilité de Phonon, même pour l'utilisateur : si j'ai envie d'utiliser Xine, je le dis à Phonon, et je n'ai pas à le dire à chaque appli.
Ici tu te trompes. Pourquoi, pour l'utilisateur, demander à Phonon de changer de backend si le but de Phonon est d'avoir la même chose quelque soit le backend ?
Pour l'utilisateur ça a un sens si Phonon échoue dans ses objectifs (typiquement ne marche pas avec le backend X pour cause de bug mais marche avec le backend Y).
Et si ça change quelque chose, pourquoi Phonon encapsule des backends qui offrent de "piètres" prestations ?
Tu ne serais pas en train de faire la confusion avec des facilité du bureau qui sauvegarde des préférences utilisateurs du style "mon navigateur préféré", "mon client mail préféré", "mon lecteur dvd préféré" ? Ce dernier pouvant lancer un lecteur qui utilise Phonon ou Xine ou ...
Ceci dit, je me trompe peut-être. A mon sens, le point le plus faible de mon argumentaire, est que Phonon n'existe pas encore. Il n'a pas fait ses prèves en bien ni en mal. Donc, si vous êtes convaincu par Phonon, foncez et codez un Phonon qui roxe des ours. Je sais, vous n'avez pas besoin de mes encouragements et vous vous en foutez :-)
> Peut-être préfères-tu, comme dit plus bas, ce qui se passe en ce moment avec le dev d'amarok (ou de tout autre lecteur multimédia, juk par exemple) obligé de développer un connecteur pour xine, un autre pour gstreamer (qui d'ailleurs est plus ou moins laissé à l'abandon), le tout pour *simplement* lire des fichiers audio.
Non.
Ici tu démontres qu'avoir plusieurs backends sucks. Tu démontres aussi que maintenir une interface pour plusieurs backends sucks aussi.
> Il ne s'agit ni plus ni moins que de mutualiser les efforts
Dans l'optique de supporter plusieurs backends !
Mais tu viens de le démontrer, cette démarche sucks et depuis de nombreuses années.
> d'assurer un code qui fonctionne puisqu'il sera officiellement inclus dans kde.
Arts était "officiellement inclus dans kde". Tu connais l'histoire. Ceci dit, c'est mieux que de ne pas être inclus dans KDE.
Puis le problème avec Phonon est : que va supporter KDE ?
Phonon seulement ? => sans issue.
Phonon et Xine et NMM et Gstreamer et alsa ?
KDE avait déjà du mal à supporter Arts. Il faut aussi le reconnaitre qu'il reste beaucoup de boulot à Gnome et Gstreamer. Ceci montre que les ressources du logiciel libre sont insufisantes pour maintenir 50 backends (déjà que pour 3 ou 4 ça sucks).
> il me semble que kde pousse le modèle objet et l'encapsulation le plus loin possible et qu'ils raffolent de ce genre d'outils.
Je répète, si l'encapsulation apporte quelques choses, pourquoi pas.
Il y a un binding de Gstreamer en C++. C'est une encapsulation, ça apporte quelque chose. Les developpeurs C++ sont contents. Les développeurs C++, ce n'est pas 0,1 % des développeurs !
Si KDE veut étendre cette API ou une autre pour ajouter des fonctions qui simplifient la vie des développeurs. Go ! M'enfin Gstreamer ce n'est pas sorcier à utiliser dans un contexte simple.
Si KDE veut le faire pour autre chose que Gstreamer => Go !
Ce que fait KDE, c'est ajouter une API (pas en étendre une pour répondre à un besoin) pour faire ce que tous les backends savent déjà faire (c'est dans la définition de Phonon).
> il s'y trouve même un gnomiste pour défendre cette idée (phonon) et regretter que Gnome n'ait pas fait de même.
C'est très bien !
J'ai peut-être tord, tu as peut-être raison. Tout le monde peut se tromper mais tout le monde à le droit de défendre ses points de vu (c'est une remarque à ceux qui voudraient me "censurer").
Tu peux me trouver un KDEiste qui est contre Phonon ?
> Pour finir, nulle part il n'est, en effet, écrit que les dev seront, couteau sous la gorge, obligés d'utiliser phonon pour une appli externe à kde.
C'est le libre. C'est normal.
Pour une appli KDE :
1- Phonon pour les trucs simples.
2- Xine, GStreamer, NMM, etc pour les trucs un rien compliqués (dès que ce n'est pas dans le plus petit dénominateur commun des backens).
3- Xine, Gstreamer, NMM, etc pour les trucs compliqués.
4- Xine ou Gstreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
5- Autre chose de mieux que Phonon (le truc par défaut). La liste est longue, voire on ne peut faire plus long, de part la définition de Phonon.
=> Une API supplémentaire (et même pas une extension d'une existant) pour faire ce qu'on sait déjà faire.
=> Beaucoup de cas pour ne pas utiliser Phonon.
=> Donc les efforts seront dispersés (et non mutualisé).
Avec Gnome :
1 Gstreamer pour les trucs simples.
2 Gstreamer pour les trucs compliqués.
3 Xine ou GStreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
4 Autre chose de mieux que Gstreamer (le truc par défaut). La liste est limitée car Gnome a pris initialement le meilleur framework (du moins selon eux).
=> quelques cas pour ne pas utiliser Gstreamer.
=> Donc les efforts sont concentrés sur Gstreamer (et non dispersé). Ils sont concentrés sur ce qui fait vraiment le boulot, ce qui apporte de la valeur à l'utilisateur, et non sur un wrapper.
KDE ajoute une API et plus de raisons pour les développeurs de se disperser sur 50 backends. Avoir plein de backend sucks ! L'histoire le montre.
Et rien que pour faire des trucs simples, les développeurs doivent maintenir un truc donc le bon fonctionnement dépend de lui-même et de plusieurs backends.
> Ils ne restent donc que fidèles à leur façon de faire avec Phonon.
Non !
Pour les widgets, KDE n'encapsule QUE Qt. Pas Qt et Gtk et Xt etc... et pas en ne fournissant que le plus petit dénominateur commun d'un ensemble de "backends" graphiques.
Il n'y a qu'un "backend" graphique, c'est Qt. Il n'y a qu'un backend vfs, c'est kio, etc. Mais il y aura plusieurs backends multimédia, ce sont NMM, Xine, Gstreamer, etc...
Tu comprends la différence ?
Je n'ai rien contre que KDE encapsule QUE Xine ou autre.
Tu peux considérer que Phonon sera un succès. Si le logiciel libre n'arrive pas faire à un (voire deux) backend qui roxor des ours, il y aura encore 50 backends et il faudra vivre avec.
Si le logiciel libre sucks, Phonon va permettre que ça sucks un peu moins.
Moi, je ne veux pas que le logiciel libre sucks.
Je ne veux pas que le logiciel libre persiste dans une voix qui manifestement ne marche pas. Je n'aime pas ce qui "pousse" à persister dans cette voix qui sucks.
Le choix de KDE est peut-être judicieux. Mais il a des effets de bord non négligeables. Ils faut les reconnaitres et non avoir des oeillères devant les yeux et affirmer que l'encapsulation que fait Phonon est la même que les autres encapsulations faites dans KDE par exemple.
> Libre au dev d'amarok de continuer préférer (je n'en sais rien en fait) xine
Libre, libre, libre !
OK, je le sais, c'est du logiciel libre.
Libre aux développeurs de Gnome de faire comme KDE et pousser dans une voix qui sucks.
> Je retourne dans les préférences, je re-change, et hop, là, ça marche.
Le but d'un bureau n'est pas de donner un maximum de préférences pour que l'utilisateur (pardon, le technicien en informatique) trouve l'astuce qui fait marcher le bousin.
> Tu proposes quoi pour résoudre ce problème particulier ?
De corriger le bug là où il est !
Proposer du "ça ne marche pas mais tu peux faire pour que ça marche" n'est pas un objectif à suite. OK, parfois ça rend service. Mais pour une grande majorité d'utilisateur, la conclusion sera que Linux c'est compliqué, ça sucks, etc...
Pour les développeurs, c'est se compliquer la vie a offrir 50 moyens pour faire marcher le bousin. Cette énergie dépensée serait beaucoup plus utile à corriger les bugs au-lieu de trouver des moyens pour les contourner.
> quelles que soient les préférences de l'utilisateur final (toi qui préfère GST, un autre qui ne jure que par Xine, ma maman qui est sous Windows, mon papa qui est sous OSX, ...).
C'est vachement important pour 99,9 % des utilisateurs...
Pardon pour 0,1 % des utilisateurs.
L'utilisateur en a rien à foutre de savoir qu'il y a un backend, qu'il a le choix entre plusieurs backends etc...
De plus avec Phonon, quelque soit le backend, c'est la même chose. Donc en quoi ça concerne l'utilisateur ? A part l'emmerder pour rien ?
> comment dans ce cas gérer les ambitions multiplateformes du K.
Les frameworks sont multiplateformes. Effectivement, si KDE veut bichonner les utilisateurs de TO7, Gstreamer ou Xine ou n'importe quoi ne va pas les aider.
> ça va permettre à n'importe quel développeur d'applications KDE de bénéficier des fonctionnalités multimédia de base sans devoir apprendre d'autres API
Et le jour où il veut faire un peu plus compliqué que ce que permet l'API de Phonon ? Par exemple à la demande des utilisateurs ou simplement car il en a envis.
Il peut demander à Phonon d'étendre l'API. Mais Phonon va peut-être dire "non" car ils veulent conserver une API "serrée" ou car un backend supporté par Phonon ne permet pas la fonctionnalité.
Au final le développeur va surement apprendre une autre API, alors qu'il aurait pu se contenter d'en apprendre qu'une.
Puis mets toi à la place du développeur lorsqu'il envisage de faire une appli. Es-ce qu'en général il se dit "je vais prendre ce truc là car il permet le minimum au rique d'être bloqué et de passer à autre chose", ou "je vais prendre ce truc là car il permet le maximum et j'ai peu de chance d'être bloqué et il me donne plus de liberté".
Il faut aussi savoir évaluer la complexité. Quelque chose avec plein de fonctionnalité n'est pas forcément plus compliqué que quelque chose avec peu de fonctionnalité.
Par exemple php a plein de fonctionnalités. Si tu enlèves le support pour xml, les expressions rationnelles, les accès aux bases de données, es-ce que ça rend php plus simple dans le cadre d'un programme simple qui n'utilise pas xml, ni les expressions rationnelles, et n'accède pas à une base de donnée ?
Ben non.
Dans une bonne API, ce dont tu ne te sers pas, ne doit pas te géner.
Pour un développeur C, il n'est pas plus compliqué de faire du C avec un compilateur C++ même si ce dernier à plus de fonctionnalité.
Faire des trucs simple avec Gstreamer, c'est l'affaire de 10 ou 20 lignes. Un développeur qui ne sait pas gérer ça, n'est pas un développeur.
Beaucoup de développeurs vont se dire "je vais mettre 20 lignes au lieu de 10 afin de ne pas être bloqué par l'API minimaliste de Phonon".
[^] # Re: Mouaip
Posté par clearstream . En réponse à la dépêche L'alternative BSD. Évalué à 2.
J'ai bien compris. Je tenais seulement à dire que s'ils n'ont pas les mêmes objectifs, on ne peut pas en conclure qu'ils n'ont pas un soucis de la qualité aussi élevé.
[^] # Re: La licence.
Posté par clearstream . En réponse à la dépêche L'alternative BSD. Évalué à 2.
Je n'ai pas dit tout à fait ça. J'ai dit :
- "la licence BSD est incompatible avec du code GPL."
Si le projet est sous BSD, le code doit respecter la licence du projet. Si le code est sous GPL, ça coince.
Si le projet est sous GPL, le code doit respecter la licence du projet. Si le code est sous BSD ou GPL, c'est OK.
# HAL
Posté par clearstream . En réponse au journal kudev : projet de gestion aisée des règles udev.. Évalué à 2.
Du moins si l'objectif est de gérer les périphériques USB.
D'ailleurs Fedora va retirer kudzu pour tout faire avec HAL (pour FC6 ou FC7).
Et il manque un outil pour configurer les fichiers hdi !
Reconnaissons que la tâche est beaucoup plus compliqué mais l'outil est également beaucoup plus puissant.
Je ne vais pas ici te faire un topo sur HAL. Je te conseille vivement de te renseigner sur HAL.
Pour /etc/fstab, la décision a été prise de ne plus l'éditer pour les périphériques amovible. Sous gnome c'est gnome-volume-manager qui monte ou démonte les périphériques et on peut le faire à la main avec gnome-mount. Ce n'est pas une solution qu'il m'emballe, mais l'autre avait de sérieux problèmes techniques.
[^] # Re: Mouaip
Posté par clearstream . En réponse à la dépêche L'alternative BSD. Évalué à 3.
La qualité et la pertinance est là.
J'avais mal interprété la news, tu as brillament éclairi les choses.
> * La méthode principale de QA (quality assurance), en simplifiant à peine, est pour Debian le testage intensif à grande échelle et la correction systématique des RC bugs ; pour OpenBSD, ce serait plutôt re-audit permanent du source, son "nettoyage" progressif, et l'intégration régulière, dans ce code, de nouvelles méthodes de renforcement.
Je n'aime pas quand on dit que tel projet est plus centré sur la qualité qu'un autre (ce qui n'est pas ton propos il me semble).
Si on prend Ubuntu ou Fedora, la qualité n'est pas négligée. Simplement ces distributions ont aussi d'autres exigences (faire évoluer le logiciel libre, explorer de nouvelles voix, faire un bureau exitant, "rester dans la compétition"). En considérant les contraintes et les ressources disponibles, la qualité est formidable. Ce n'est qu'en parti dû aux distributions et le mérite en revient principalement aux développeurs des projets respectifs qu'on retrouvent dans les distributions.
La qualité ne se résume pas à : "j'intègre ça car c'est stable, je n'intègre pas ça car ce n'est pas stable". Ca c'est une politique pour délivrer quelque chose de stable. Les distributions "professionnelles" le font.
La qualité est un soucis permanent qu'on "s'inflige", qu'on soit en phase de développement ou sur un vieu logiciel dont la fiabilité est le critère numéro un.
Compte-tenu de la rapidité d'évolution de Linux, Linux serait un désastre s'il n'avait de hautes exigences qualités.
Sans pouvoir l'affirmer, je pense que Linux a autant le soucis de la qualité que les *BSD. Mais Linux est moins centré sur la stabilité.
Pour faire une analogie, les équipes qui construisent des F1 ont des critères de qualités extrèmement élevés. Mais comme elles ont la contrainte de devoir gagner des courses, ben la F1 a une durée de vie ridicule.
[^] # Re: Mouaip
Posté par clearstream . En réponse à la dépêche L'alternative BSD. Évalué à 3.
Heu, non, http://janitor.kernelnewbies.org/ n'a pas ce rôle. Mais c'est un excellent travail pour ceux qui veulent s'initier au développement de Linux (ça c'est le rôle de janitor).
> alors que c'est fait directement par les développeurs du noyau sur les Net/OpenBSD (je ne connais pas bien FreeBSD).
C'est aussi fait par les développeur Linux. Mais ils ne vons pas refuser un coup de main de janitor.
# Mouaip
Posté par clearstream . En réponse à la dépêche L'alternative BSD. Évalué à 1.
Pour ce qui est du noyau, demande l'avis de Reiser. Linux audite aussi le code, etc...
Il peut être très long (plusieurs mois, voire années) pour être intégré à Linux.
> La réutilisation du code est grandement facilitée
Sauf que la licence BSD est incompatible avec du code GPL. Heureusement beaucoup de driver sous Linux ont la double licence (BSD/GPL).
[^] # Re: Au secours
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 2.
http://linuxfr.org/comments/746145,1.html
Certe, je n'étais pas obligé et ton commentaire n'est pas "inspiré" uniquement par ce dernier thread.
[^] # Re: Du calme!
Posté par clearstream . En réponse au journal Xorg et les modules proprio.... Évalué à 7.
Sur une version oui. Sur une succession de version non.
Comment avoir des retours d'utilisateur s'il reste en version N-1 ?
Pour que le logiciel libre évolue vite, il faut des utilisateurs sur la dernière version. Pas sur une version qui a peu d'intérêt pour les développeurs.
> et encore xorg 7.1 est une sorte d'exception
Pas du tout. C'est récurrent comme problème.
> pour xorg 7.0 que je me souvienne j'ai pas eu de probleme
Il y en a eu.
> De plus les développeurs du drivers NVIDIA aident activement Xorg
Bof. En tout cas ils n'aident pour avoir des drivers libres.
> ils ont poussés à inclure dans Xorg une modification qui a rendu le driver NVIDIA incompatible avec Xorg 7.1!
C'est juste. La motivation première de Nvidia, n'est pas la "communauté" mais les distributions "professionnelles" qui sortent bien après les distributions les plus "hypes".
> En plus X11R7.1 est relativement récent, est-on vraiment à 6mois
Trois mois je crois. Largement assez pour porter les drivers. D'ailleurs tous les drivers libres était OK dès la sortie de Xorg 7.1.
Je crois que tu n'as pas lu ou pas assez attentivement l'article de lwn.
Jusqu'à maintenant, Fedora ne se souciait en aucun cas des drivers propriétaires. Il y a peu (avec la sortie de Xorg 7.1), Fedora a pris une décision en prenant en compte les drivers propriétaires. Fedora allait fournir Xorg 7.1 en mise à jours de FC5, mais c'est rétracté car des utilisateurs de drivers proprios ont gueulé.
C'est nouveau, et selon moi regrettable car on a privilégié les utilisateurs de drivers propriétaires sur les utilisateurs de drivers libres. On a retirer de la liberté au libre.
Par rapport à Fedora, il faut relativer. Cette décision ne dicte pas les décisions à venir.
Plusieures choses :
* pour les mises à jours de sécurité ou bug important, Fedora montera toujours en version. Donc si un trou de sécurité est trouvé dans Xorg 7.0, Fedora fournira Xorg 7.1 comme correctif. Pas de backport.
* Mike Harris, mainteneur de Xorg pour Fedora, voulait Xorg 7.1 dans FC5. Le remplaçant de Mike Harris (ce dernier est parti prendre des vacances prolongées, merci à lui pour son excellent travail) ne met pas Xorg 7.1 pour FC5 dans ses priorités (c'est 2 ou 3 jours de boulot) et préfère se concentrer sur FC6 (actuellement en développement). Si ça ne tenait qu'à lui, il ne le fairait pas (pour ce cas spécifique) et ça n'a rien à voir avec les drivers proprio.
* Lors de cette épisode, Rawhide avait Xorg 7.1 depuis longtemps, FC6 test2 était sorti avec Xorg 7.1. Donc Xorg 7.1 était assez intensivement testé même sans la disposition de Xorg 7.1 dans FC5.
* Cette décision de ne pas fournir temporairement Xorg 7.1, n'impacte en rien les développeurs. D'ailleurs la branche testing (celle utilisée pour tester les mises à jour) reste totalement ouverte à toute chose qui peuvent casser les drivers proprio. Si Mike Harris n'avait pas quitté Red Hat, c'est là que serait Xorg 7.1 pour FC5. Et si un trou de sécurité était trouvé dans Xorg, ce même Xorg 7.1 (avec la dernier version CVS qui a le correctif) se serait retrouvé dans les mises à jour.
Afin, il y a quelques travaux sur http://www.livna.org/ (qui fournit des paquets pour les drivers Nvidia proprio et autres) pour que lorsque le driver proprio est installé, une mise à jours de Xorg ne soit pas possible sans que le driver n'ait pas été mis à jours pour la nouvelle version du serveur. C'est très facile à faire.
Malheureusement tout le monde n'utilise pas livna mais récupère les drivers sur le site de Nvidia. Dommage que NVidia ne fournisse pas ses drivers au format rpm ou dpkg pour ne pas avoir ce problème (surtout que c'est fait pour ça).
Sinon les utilisateurs de drivers libres se sentirait un peu moins en otage de drivers proprio et pour FC5 serait déjà sous Xorg 7.1.
[^] # Re: Au secours
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -2.
Tu parles des librairies wrappées par Qt et tu n'es même pas allez vérifier. Pourtant avec un "rpm -q --requires" ou un ldd ça se fait vite. Une ligne de commande seulement.
Je ne voulais pas répondre à ton commentaire au début. T'as demandé une réponse, je l'ai fait et voilà.
Si tu voulais du "oui, oui, oui", t'as frappé à la mauvaise.
> gst devrait déjà faire ses preuves pour les besoins de base
C'est fait, c'est utilisé par Gnome depuis plus d'un an qui n'utilise que Gstreamer.
Notes que Phonon n'a toujours pas fait ses preuves...
> cf les commentaires plus haut
Apparament la personne a oublié d'ajouter des plugins. Si elle ne veut pas se renseigner avant d'utiliser quelque chose, Gstreamer n'y est pour rien. Les modules sont à un click de la page d'accueil du site de Gstreamer.
Tu crois que Gstreamer ne supporte pas mp3 car quelqu'un le dit ?
Mp3 est supporté par Gstreamer depuis la nuit des temps.
Tu crois que Gstreamer ne supporte pas le réseau car quelqu'un le dit ?
Gstreamer support tcp, udp, gnomevfs (il ne tient qu'à KDE de faire l'équivalent), et rtp*. Un exemple qu'il y a plus d'un an :
http://linuxfr.org/comments/581662.html#581662
Rhythmbox qui utilise gstreamer permet d'écouter la radio sur internet et rtp* pour les videos real.
Tu crois que Gstreamer ne supporte pas les DVD car quelqu'un le dit ?
Gstreamer supporte les dvds cryptés ou pas depuis longtemps. A vu de nez peut-être depuis au moins 2 ans.
T'es un peu naïf.
Sur ma bécane, j'ai 82 modules offrant 487 fonctionnalités. Il manque principalement le support pour dvb.
> L'avantage est _jutement_ de ne pas s'enchaîner à un élément extérieur non maîtrisé.
Le développeur est enchaîné à Phonon dont l'api ne doit pas bouger durant en gros 5 ans (la durée de vie de KDE 4) et Phonon est enchaîné aux frameworks.
> L'avantage est _jutement_ de ne pas s'enchaîner à un élément extérieur non maîtrisé.
Et Arts, qui le développait ? Ce n'était pas KDE par hazard ?
Ben oui. On a vu ce que ça a donné.
Ce n'est pas parce que KDE fait quelque chose que c'est forcément parfait ou mieux que les autres.
> L'API de phonon pourra être étendue au fil des avancées des backends
Des extensions seulement. Si une fonctionnalité casse la compatibilité, il faudra attendre KDE 5 (au moins 5 ans).
Et si personne veut étendre Phonon comme c'est arrivé avec Arts ?
Je répète, ce n'est pas parce que KDE gère le projet que tout est forcément rose.
> mais sera toujours sous contrôle.
Super.
Comme ce n'est fait que pour le framework multimédia, je peux en conclure que tout le reste n'est pas sous contrôle.
> Et non, ce n'est pas un travail surhumain de maintenir phonon.
Arts non plus ce n'était pas un travail surhumain.
[^] # Re: Au secours
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -6.
Vérifies toi même, les libs que j'ai sité ne sont pas "wrappées" par Qt (je n'ai pas sité Xlib). Qt wrappe presque rien (vérifies toi même).
> J'imagine même que la plupart des plugins de gestion des backends seront maintenus par un gars de l'équipe de dev du backend concerné.
Ben si les autres s'en chargent... C'est rien comme boulot. Ils doivent bosser sur leur frameword ET sur Phonon maintenant. Pour KDE c'est que du bonheur surtout que tu dois penser que les développeurs de framework n'ont que ça a foutre.
> - Le "plus petit dénominateur commun" de gst/xine/mplayer est quand même énorme : lire des vidéos, des sons, streaming, mixer, equalizer, effets vidéo, ... tout le nécessaire pour la quasi totalité des applications desktop (knotify, amarok, kaffeine, kmix, krec, ...),
Donc tous les développements actuels sur les frameworks sont inutiles puisqu'il y a déjà tout le nécessaire selon toi.
J'imagine que quand les autres fairont mieux, tu vas te persuader que c'est inutile car t'as déjà "tout le nécessaire pour la quasi totalité des applications desktop".
> Pour la MAO, il vaut mieux de toute façon passer par jack que gst/xine.
Jack ne fait pas la vidéo. Gstreamer oui. Quand avec Gstreamer et une bête caméra USB à 2 sous on pourra éditer ses propres films, ajouter des commentaires ou une musique de fond en deux cliques tu vas penser que c'est inutile pour l'utilisateur moyen. Au mieux KDE offrira ça par défaut dans KDE 5. Pas avant 5 ans...
> - Comme dit plus haut, c'est du "sucre" pour les développeurs
Il vont peut-être s'économiser 10 lignes de code pour rester enchaîné à Phonon. Au moins avec ce sucre ils ne risque pas grossir.
> à part des soucis en moins dans amarok quand gstreamer change d'API
Ce qui arrive tout les ans (13 mois entre 0.8 et 0.10) et le rythme va forcément décroitre. Si ton appli est simple (type une appli qui utilise Phonon), c'est l'affaire de 1 jour maximum pour passer de Gstreamer 0.8 à 0.10 et avoir plus de fonctionnalité. Avec Phonon pour avoir plus de fonctionnalité, il faut "seulement" que tu changes complètement d'API.
> Maintenant, clearstream, qu'est-ce qui te révolte tant ?
Ta naïveté.
[^] # Re: Proposez plus de dépêches
Posté par clearstream . En réponse à la dépêche Statistiques et évolutions pour le site. Évalué à 1.
> - acceptées (avec éventuellement des corrections) - 90% des cas
Parce que t'on profile est dans le politiquement correct de Linuxfr.
Linuxfr est souvant abhérant dans sa modération. Par exemple Red Hat qui achete à 50 million de $ Netscape Directory Serveur et annonce le mettre en libre prochainement, ben ça passe en seconde page (et même pas dans la catégorie Red Hat ; bonjour la reconnaissance). Faire une connerie, ça arrive à tout le monde. Mais les modérateurs dans leur "grande sagesse" n'ont pas voulu la corriger ! Par contre une beta de l'installeur Debian ou un contrat de 1 million pour Mandriva, ça passe en première page. On a atteind le sommet avec SuSE où Linuxfr trouvait toujours de nouveaux prétextes pour ne pas passer les news SuSE (on ne le fait pas à cause de Yast, c'est car on refuse les news de distributions payantes, etc). Pourtant SuSE était (et est toujours) un acteur majeur du libre et les utilisateurs de SuSE sont manifestement des utilisateurs de logiciel libre. Aujourd'hui linuxfr n'a toujours pas fait de section Fedora. Pratiquement tous les autres sites l'ont fait mais toujours pas Linuxfr. Pourquoi ? Parce qu'ils ne veulent pas. Bien sûr qu'ils vont trouver une raison à ça. Que les utilisateurs de Fedora disent utiliser Fedora et non Red Hat, ils s'en foutent.
C'est comme ça depuis longtemps et ça restera comme ça. Les modérateurs sont accèptés que s'ils sont politiquement correct selon l'interprétation de Linuxfr. Ceux qui n'ont pas l'esprit linuxfr sentent intuitivement qu'il leur est inutile de proposer une news. Donc ils confortent l'esprit linuxfr et l'aparente équité affiché via les stats de news refusées.
Pourquoi en discuter, ça fait la cinquantième fois que le sujet revient sur le tapis, ça fait la cinquantième fois que des contributeurs en news dirent qu'ils ne refairont pas de news, ça fait depuis des mois qu'il y a de moins en moins de contribution en news et le site plait aux administrateurs. Ils le font bénévolement et reconnaissont que linuxfr est un site fabuleux grace à eux. Toute requête est vaine et on ne peut en faire reproche.
[^] # Re: Au secours
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 5.
Il sait lire les dvd crypté (et pas encrypté).
> je n'ai toujours pas vu un truc pour le lier a dvdcss
Il utiliser un plugin (qui utiliser dvdread qui s'occupe de css)
> qu'il ne sait pas streamer
Il sait streamer.
> qu'il ne sait pas lire plein de format audio (mp3 pour le plus courrant)
Il lit plein de format audio et mp3 notament.
> comme clearstream arrete pas de faire des reproche sur KDE a cause de QT lie a trolltech
J'ai fait des reproches sur ça ? Je n'ai pas fait le moindre commentaire avec le mot "trolltech".
J'ai fait le constat que KDE était lié à Qt (comme Gnome est lié à Gtk) et que ce n'étant en rien un soucis pour eux mais qu'être lié à Gstreamer est un soucis pour eux. J'ai fait ce constat (en prenant Qt et d'autres librairies) pour "dénoncer" ce deux poids deux mesures.
Pour Gstreamer, il est très très modulaires et utilise les plugins. Très probablement tu n'as pas installé les plugins non libre.
Il y a :
gstreamer-plugin-base
gstreamer-plugin-good
gstreamer-plugin-ugly
gstreamer-plugin-bad
Voir ici :
http://gstreamer.freedesktop.org/src/
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 0.
C'est aussi du pur pragmatisme que de vouloir corriger le logiciel libre là où il sucks.
> il ne peuvent pas prendre la responsabilité de trop se lier à un framework.
Mais il le font pour Qt, etc...
Tout le monde le fait et par pragmatisme.
> J'espère aussi que les frameworks multimédia gagnent en maturité et qu'on arrivera à en avoir 1 ou 2 activement soutenus qui sortiront du lot. Dans KDE5, qui sait ?
Espérons que KDE5 sorte vite :-)
[^] # Re: Drivers proprios
Posté par clearstream . En réponse au journal Ubuntu : La MAJ de xserver-xorg fait planter le serveur X. Évalué à 3.
Si le serveur ne se lance pas, il reconfigure X11 en VGA (pas de driver spécifique) puis lance X11 à nouveau.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -1.
Tout a un rapport avec la choucroute.
> améliore une fonctionnalité (genre le 5.1 sur la lecture d'un son), elle peut être intégrée à Phonon
Yet another backend.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -3.
Gnome à le même cahier des charges.
> et non pas a cause d'une liaison gnome/gstreamer, argument stupide
Qu'es-ce qui te garantit que Qt sera stable durant toute la vie de KDE 4 ?
Qu'es-ce qui te garantit que libjpeg, libxlst, libxml, libsvg, libpcre, libpng, libpgpgme, libnetsnmp, libdbus, libhal, libsmb, et encore une dixaine d'autres librairies non développées par KDE et utilisées par KDE resteront stables durant toute la vie de KDE ?
KDE a-t-il prévu des "phonons" pour toutes ces librairies ?
Non.
Alors pourquoi ce "traitement de faveur" pour Gstreamer ?
A part une raison stupide, je ne vois pas.
> Gstreamer est encore un projet jeune, et qui non seulement ne peut encore garantir de compatibilité binaire, mais meme pas de compatibilité source comme l'a montré le passage 0.8->0.10.
Premièrement, Gstreamer n'a pas cherché à garantir la stabilité de l'API entre la version 0.8 et 0.10. Donc la question de ne pas pouvoir ne se pose pas, car Gstreamer ne voulait pas. Comme KDE ne veut pas garantir la compatibilité entre KDE 3 et KDE 4. La version 0.9 (de développement) était dès l'origine incompatible avec la version 0.8 et c'était prévu avec sa création. La version 0.9 était dès l'origine installable à côté de la version 0.8 (pour conserver une API stable).
Linux est pire que Gstreamer, il n'y a ni ABI et API stable entre versions mineures (x.y.n et x.y.n+1).
Remarquons le culot dont à fait preuve KDE à propos de l'incompatibilité entre gstreamer 0.8 et 0.10 en disant que ça a casser les applis des utilisateurs après une mise à jours. N'importe qu'elle gestionnaire de paquet digne de ce nom aurait refusé de mettre à jour gstreamer 0.8 vers 0.10 si des programmes utilisent gstreamer 0.8 et ne sont pas disponibles en version gstreamer 0.10.
C'est le boulot des gestionnaires de paquet !
Remarquons le culot de KDE de dire que gstreamer 0.10 a introduit des bugs qui n'existaient pas dans gstreamer 0.8. Je suis sûr à 12 000 % que KDE 4 va ajouter des bugs qui n'étaient pas dans KDE 3 et qui ne vont pas être corrigés ni dans la semaine et ni dans le mois de la sortie de KDE 4.
Et quel culot de la part de KDE de critique la maintenance de Gstreamer alors que KDE n'est pas foutu de maintenir Arts qui fait le quart du huitième de ce que fait Gstreamer.
Quand on fait preuve d'un tel niveau de FUD, il y a quelque chose de stupide, de crétin, qui se cache.
> KDE aurait pris Xine par exemple (qui n'est peut-etre pas exempt du probleme de la compatibilité binaire), on aurait crié à la sission, à la fragmentation, et à la duplication inutile d'effort entre KDE et Gnome.
Ben avec Phonon, KDE "garantit" la sission des frameworks durant tout KDE 4. Inutile d'instrumenter Gnome pour le constater.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
Je considérais le cas où Phonon a un bug avec un backend spécifique.
> ni en quoi ça constitue un échec pour lui.
OK, l'argumentaire était mal foutu.
> Au contraire, dans ce cas-là, l'intérêt saute aux yeux.
Il saute au yeux si on part du principe que le logiciel libre n'est pas foutu d'avoir un framework qui ne sucks pas et que Phonon roxe. J'ai déjà argumenté sur ce point.
Si le libre fait un framework qui roxe comme Xorg ou est l'intérêt d'avoir deux ou plus serveurs X11 différents et une couche au dessus pour basculer de l'un à l'autre s'il y en a un qui sucks ? Il y a un intérêt sur le papier mais la quantité de ressource pour fiabiliser tout ça est énorme, beaucoup plus énorme que de faibiliser seulement Xorg. Hors les ressources du libre sont assez limités.
Tu peux facilement balayer mon argument en disant que l'histoire montre que les frameworks multimédia libres sucks et que je suis un gros naïf.
Mais voilà, je ne veux pas croire que celà va perdurer, je ne veux pas que ça perdure.
> Si un backend est vraiment mauvais (i.e. pas d'amélioration au fil des versions), il sera peu utilisé et le backend sera abandonné. Où est le problème ?
Dans le contexte actuel où les frameworks sucks, t'as raison.
Mais pourquoi diable il faudrait se résoudre à croire que le logiciel libre ne peut que merder que les frameworks multimédia ?
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 2.
C'est vrai. Mais c'est vrai aussi pour plein de domaines et c'est aussi vrai pour Gnome et en fait vrai pour tout le monde.
La stabilité API, ça peut être fait très simplement et ce n'est pas la montage que sous-entend KDE. Par exemple il y a longtemp eu Gtk 1.x alors que Gtk 2.0 était sorti depuis longtemps. Il n'a pas été fait une encapsulation au dessus de gtk2 et gtk1. Conserver Gtk 1.x n'a pas été une montage de boulot (quoique le "split" n'a pas été simple au début). Tous les Gnome 2.x ont esound pour conserver la compatibilité. Ca ne représente pas beaucoup de boulot (voir zéro) et sûrement moins que de maintenir Phonon pour qu'il suive les modifications d'API de plusieurs backends. La nécessité de compatibilité n'entrave pas l'évolution de Gnome (ajout de Gstreamer durant la branche 2.x, et vas savoir si Xine ne va pas pointer le bout de son nez durant Gnome 3.x s'il roxe) alors que l'évolution de KDE sur plusieures années (la durée de vie de KDE 4) est contrainte au plus petit dénominateur commun des backends et ils se donnent beaucoup de boulot.
> Conséquence directe, quand l'API d'un framework change, ce n'est pas toutes les applis qui doivent s'adapter, mais seulement Phonon.
Oui. Mais il faut aussi se demander s'il n'est pas plus pertinant d'adapter les logiciels aux dernières évolutions. Dans le domaine du desktop où l'utilisateur veut du "dernier cri" et où les développeurs se font fort de répondre aux attentes des utilisateurs, ce n'est pas à sous-estimer. Surtout aussi que les développeurs du libre aiment utiliser le "dernier cri" et non "trainer" avec du "has been".
Certes, tout ceci est assez voire très subjectif. Mais tu crois que les utilisateurs de Linux dans leur ensemble seraient plus content aujourd'hui si depuis le début de Linux 2.6, Linux avait conservé une compatibilité "obsolue".
Oui la politique de Linux 2.6 parfois sucks (le driver bidule qui explose en vole lors du passage de Linux 2.6.n à 2.6.n+1 par exemple). Mais la politique de la stabilité absolue sucks, et gravement, dans des domaines aussi dynamiques que le desktop.
Si la politique de Phonon était l'évidence, alors la politique de Linux 2.6 serait évidente de stupidité.
La compatibilité "absolue" est importante pour des cas comme php. Pour php, des *milliers* de site en production et "sensibles", chaqu'un avec des milliers de lignes de code php spécifiques, en dépendent.
Pour un backend multimédia, c'est une poignée d'application pour un service qui n'est pas critique (mais important).
Pour te montrer que la stabilité de ABI n'est pas si importante que ça, et notament dans le logiciel libre, je te donne des exemples. Les binaires de FC5 ne marchent pas sur FC4 et inférieur. Pratiquement personne ne l'a remarqué !
Pour FC6, ça sera encore comme ça !
Il ne sagit pas de une ou deux applis, mais de toute les applis livrées par FC et FE.
Considères aussi Xorg. Xorg casse les binaires (côté driver) pour faire avancer les choses et 2 ou 3 semaines après tout est rentré dans l'ordre pour le bénéfice de tous. Ce n'est pas un point faible du libre/Xorg mais un point fort (malheureusement pas toujours compris).
Esound est un bonne exemple qui montre qu'il n'y a pas toujours de fortes exigences en compatibilité binaire dans le desktop. Bien que esound soit le "standard" supporté par Gnome pour la branche 2.x, presque aucune distribution ne le livre maintenant car presque aucune application ne l'utilise encore. Elles sont toutes passées à autre chose. Je crains que Phonon, à l'instar de Esound et aussi Arts, subisse le même sort.
> Mais tu trouvera toujours un utilisateur qui voudra celui que tu n'as pas choisi, pour une raison X ou Y, recevable ou non, mais dont il ne démordra pas.
C'est très juste. Mais je ne crois pas que le logiciel libre y gagne en considérant que c'est la règle.
Il faut respecter cette liberté, non considérer que c'est la règle.
> D'où la très grande utilité de Phonon, même pour l'utilisateur : si j'ai envie d'utiliser Xine, je le dis à Phonon, et je n'ai pas à le dire à chaque appli.
Ici tu te trompes. Pourquoi, pour l'utilisateur, demander à Phonon de changer de backend si le but de Phonon est d'avoir la même chose quelque soit le backend ?
Pour l'utilisateur ça a un sens si Phonon échoue dans ses objectifs (typiquement ne marche pas avec le backend X pour cause de bug mais marche avec le backend Y).
Et si ça change quelque chose, pourquoi Phonon encapsule des backends qui offrent de "piètres" prestations ?
Tu ne serais pas en train de faire la confusion avec des facilité du bureau qui sauvegarde des préférences utilisateurs du style "mon navigateur préféré", "mon client mail préféré", "mon lecteur dvd préféré" ? Ce dernier pouvant lancer un lecteur qui utilise Phonon ou Xine ou ...
Ceci dit, je me trompe peut-être. A mon sens, le point le plus faible de mon argumentaire, est que Phonon n'existe pas encore. Il n'a pas fait ses prèves en bien ni en mal. Donc, si vous êtes convaincu par Phonon, foncez et codez un Phonon qui roxe des ours. Je sais, vous n'avez pas besoin de mes encouragements et vous vous en foutez :-)
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
Non.
Ici tu démontres qu'avoir plusieurs backends sucks. Tu démontres aussi que maintenir une interface pour plusieurs backends sucks aussi.
> Il ne s'agit ni plus ni moins que de mutualiser les efforts
Dans l'optique de supporter plusieurs backends !
Mais tu viens de le démontrer, cette démarche sucks et depuis de nombreuses années.
> d'assurer un code qui fonctionne puisqu'il sera officiellement inclus dans kde.
Arts était "officiellement inclus dans kde". Tu connais l'histoire. Ceci dit, c'est mieux que de ne pas être inclus dans KDE.
Puis le problème avec Phonon est : que va supporter KDE ?
Phonon seulement ? => sans issue.
Phonon et Xine et NMM et Gstreamer et alsa ?
KDE avait déjà du mal à supporter Arts. Il faut aussi le reconnaitre qu'il reste beaucoup de boulot à Gnome et Gstreamer. Ceci montre que les ressources du logiciel libre sont insufisantes pour maintenir 50 backends (déjà que pour 3 ou 4 ça sucks).
> il me semble que kde pousse le modèle objet et l'encapsulation le plus loin possible et qu'ils raffolent de ce genre d'outils.
Je répète, si l'encapsulation apporte quelques choses, pourquoi pas.
Il y a un binding de Gstreamer en C++. C'est une encapsulation, ça apporte quelque chose. Les developpeurs C++ sont contents. Les développeurs C++, ce n'est pas 0,1 % des développeurs !
Si KDE veut étendre cette API ou une autre pour ajouter des fonctions qui simplifient la vie des développeurs. Go ! M'enfin Gstreamer ce n'est pas sorcier à utiliser dans un contexte simple.
Si KDE veut le faire pour autre chose que Gstreamer => Go !
Ce que fait KDE, c'est ajouter une API (pas en étendre une pour répondre à un besoin) pour faire ce que tous les backends savent déjà faire (c'est dans la définition de Phonon).
> il s'y trouve même un gnomiste pour défendre cette idée (phonon) et regretter que Gnome n'ait pas fait de même.
C'est très bien !
J'ai peut-être tord, tu as peut-être raison. Tout le monde peut se tromper mais tout le monde à le droit de défendre ses points de vu (c'est une remarque à ceux qui voudraient me "censurer").
Tu peux me trouver un KDEiste qui est contre Phonon ?
> Pour finir, nulle part il n'est, en effet, écrit que les dev seront, couteau sous la gorge, obligés d'utiliser phonon pour une appli externe à kde.
C'est le libre. C'est normal.
Pour une appli KDE :
1- Phonon pour les trucs simples.
2- Xine, GStreamer, NMM, etc pour les trucs un rien compliqués (dès que ce n'est pas dans le plus petit dénominateur commun des backens).
3- Xine, Gstreamer, NMM, etc pour les trucs compliqués.
4- Xine ou Gstreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
5- Autre chose de mieux que Phonon (le truc par défaut). La liste est longue, voire on ne peut faire plus long, de part la définition de Phonon.
=> Une API supplémentaire (et même pas une extension d'une existant) pour faire ce qu'on sait déjà faire.
=> Beaucoup de cas pour ne pas utiliser Phonon.
=> Donc les efforts seront dispersés (et non mutualisé).
Avec Gnome :
1 Gstreamer pour les trucs simples.
2 Gstreamer pour les trucs compliqués.
3 Xine ou GStreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
4 Autre chose de mieux que Gstreamer (le truc par défaut). La liste est limitée car Gnome a pris initialement le meilleur framework (du moins selon eux).
=> quelques cas pour ne pas utiliser Gstreamer.
=> Donc les efforts sont concentrés sur Gstreamer (et non dispersé). Ils sont concentrés sur ce qui fait vraiment le boulot, ce qui apporte de la valeur à l'utilisateur, et non sur un wrapper.
KDE ajoute une API et plus de raisons pour les développeurs de se disperser sur 50 backends. Avoir plein de backend sucks ! L'histoire le montre.
Et rien que pour faire des trucs simples, les développeurs doivent maintenir un truc donc le bon fonctionnement dépend de lui-même et de plusieurs backends.
> Ils ne restent donc que fidèles à leur façon de faire avec Phonon.
Non !
Pour les widgets, KDE n'encapsule QUE Qt. Pas Qt et Gtk et Xt etc... et pas en ne fournissant que le plus petit dénominateur commun d'un ensemble de "backends" graphiques.
Il n'y a qu'un "backend" graphique, c'est Qt. Il n'y a qu'un backend vfs, c'est kio, etc. Mais il y aura plusieurs backends multimédia, ce sont NMM, Xine, Gstreamer, etc...
Tu comprends la différence ?
Je n'ai rien contre que KDE encapsule QUE Xine ou autre.
Tu peux considérer que Phonon sera un succès. Si le logiciel libre n'arrive pas faire à un (voire deux) backend qui roxor des ours, il y aura encore 50 backends et il faudra vivre avec.
Si le logiciel libre sucks, Phonon va permettre que ça sucks un peu moins.
Moi, je ne veux pas que le logiciel libre sucks.
Je ne veux pas que le logiciel libre persiste dans une voix qui manifestement ne marche pas. Je n'aime pas ce qui "pousse" à persister dans cette voix qui sucks.
Le choix de KDE est peut-être judicieux. Mais il a des effets de bord non négligeables. Ils faut les reconnaitres et non avoir des oeillères devant les yeux et affirmer que l'encapsulation que fait Phonon est la même que les autres encapsulations faites dans KDE par exemple.
> Libre au dev d'amarok de continuer préférer (je n'en sais rien en fait) xine
Libre, libre, libre !
OK, je le sais, c'est du logiciel libre.
Libre aux développeurs de Gnome de faire comme KDE et pousser dans une voix qui sucks.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 2.
Le but d'un bureau n'est pas de donner un maximum de préférences pour que l'utilisateur (pardon, le technicien en informatique) trouve l'astuce qui fait marcher le bousin.
> Tu proposes quoi pour résoudre ce problème particulier ?
De corriger le bug là où il est !
Proposer du "ça ne marche pas mais tu peux faire pour que ça marche" n'est pas un objectif à suite. OK, parfois ça rend service. Mais pour une grande majorité d'utilisateur, la conclusion sera que Linux c'est compliqué, ça sucks, etc...
Pour les développeurs, c'est se compliquer la vie a offrir 50 moyens pour faire marcher le bousin. Cette énergie dépensée serait beaucoup plus utile à corriger les bugs au-lieu de trouver des moyens pour les contourner.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
Pour preuve, tu en parles alors qu'on parle d'informatique.
Que la force de la choucroute soit avec toi.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
Gstreamer = > multiplateforme (*nix / Windows / Mac OS)
Il y a peut-être d'autre framework aussi portable que Gstreamer, mais je ne les connais pas.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
C'est vachement important pour 99,9 % des utilisateurs...
Pardon pour 0,1 % des utilisateurs.
L'utilisateur en a rien à foutre de savoir qu'il y a un backend, qu'il a le choix entre plusieurs backends etc...
De plus avec Phonon, quelque soit le backend, c'est la même chose. Donc en quoi ça concerne l'utilisateur ? A part l'emmerder pour rien ?
> comment dans ce cas gérer les ambitions multiplateformes du K.
Les frameworks sont multiplateformes. Effectivement, si KDE veut bichonner les utilisateurs de TO7, Gstreamer ou Xine ou n'importe quoi ne va pas les aider.
> On a tous déjà démonté tes arguments
Ben l'histoire jugera.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -2.
Et le jour où il veut faire un peu plus compliqué que ce que permet l'API de Phonon ? Par exemple à la demande des utilisateurs ou simplement car il en a envis.
Il peut demander à Phonon d'étendre l'API. Mais Phonon va peut-être dire "non" car ils veulent conserver une API "serrée" ou car un backend supporté par Phonon ne permet pas la fonctionnalité.
Au final le développeur va surement apprendre une autre API, alors qu'il aurait pu se contenter d'en apprendre qu'une.
Puis mets toi à la place du développeur lorsqu'il envisage de faire une appli. Es-ce qu'en général il se dit "je vais prendre ce truc là car il permet le minimum au rique d'être bloqué et de passer à autre chose", ou "je vais prendre ce truc là car il permet le maximum et j'ai peu de chance d'être bloqué et il me donne plus de liberté".
Il faut aussi savoir évaluer la complexité. Quelque chose avec plein de fonctionnalité n'est pas forcément plus compliqué que quelque chose avec peu de fonctionnalité.
Par exemple php a plein de fonctionnalités. Si tu enlèves le support pour xml, les expressions rationnelles, les accès aux bases de données, es-ce que ça rend php plus simple dans le cadre d'un programme simple qui n'utilise pas xml, ni les expressions rationnelles, et n'accède pas à une base de donnée ?
Ben non.
Dans une bonne API, ce dont tu ne te sers pas, ne doit pas te géner.
Pour un développeur C, il n'est pas plus compliqué de faire du C avec un compilateur C++ même si ce dernier à plus de fonctionnalité.
Faire des trucs simple avec Gstreamer, c'est l'affaire de 10 ou 20 lignes. Un développeur qui ne sait pas gérer ça, n'est pas un développeur.
Beaucoup de développeurs vont se dire "je vais mettre 20 lignes au lieu de 10 afin de ne pas être bloqué par l'API minimaliste de Phonon".
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
Où ça ?
> Tu trouves toujours ça aberrant ?
Manifestement, tu n'as pas compris ce que j'ai dit. La réciproque est sûrement vrai.
J'arrête ici, et reprends une phrase de Laurent A. :