Richard Van Den Boom a écrit 388 commentaires

Le noyau Linux sait pertinemment l'importance de conserver des interfaces stables sur la durée, pour ne pas casser la compatibilité avec les applis.
Gnome, comme KDE, aura besoin à un moment ou à un autre de mettre à jour tout son fonctionnement fondamental ne serait-ce que pour garder le même niveau de fonctionnalités.
Et ce n'est pas qu'une question de cosmétiques, c'est une question d'intégration. Les fonctionnalités apportées par le cadre de KDE4 seront accessibles à toutes les applications, ce qui veut dire que je pourrai utiliser une recherche utilisant Strigi à partir de KOffice ou d'Amarok, pour utiliser des les méta-données du fichier aussi bien que son nom. Je pourrai faire des recherches sur des accès SSH ou SMB sans montage à partir de n'importe quelle applis, pas seulement le gestionnaire de fichiers. Le carnet d'adresses sera accessibles de toutes les applis, etc.
Si Gnome veut pouvoir fournir un degré d'intégration proche, il devra à terme suivre le chemin de la refonte fondamentale.

C'était pas le cas quand la décision de créer Phonon a été prise, c'est ça qui est important.
Et comme je l'ai dit, tout le monde n'utilise pas Gstreamer, j'utilise xine personnellement, et beaucoup de monde utilise Mplayer ou VLC qui ne l'utilisent pas non plus.
Pour finir, le plugin xine pour Phonon a été crée en une semaine par un gars tout seul, alors que celui pour Gstreamer semble encore douteux. A croire que créer des applis qui utilisent Gstreamer n'est pas encore aussi simple que pour xine, soit parce que l'API est changeante, soit parce qu'elle est beaucoup plus complexe.
Il n'est donc pas du tout étonnant que les devs de KDE se soient orientés vers une couche d'abstraction de ce type, plutôt que de parier il y a un an sur Gstreamer partout.
Il est tout à fait possible qu'à terme, Gstreamer soit LA solution, mais au moment où les décisions ont été prises pour l'infrastructure de KDE4 et même maintenant, ce n'est pas un environnement qui s'impose de façon évidente par rapport aux autres.

La qualité de l'échantillon **et** les méthodes d'analyses. Les instituts de sondage appliquent des corrections aux résultats en fonction de paramètres psychologiques évalués dans la durée.
Les deux, échantillon et méthodes, sont totalement absents de ces sondages internet, ce qui les rend totalement inutiles.

Je ne vois pas pourquoi le message parent est en négatif, il montre une incompréhension mais n'est pas inutilement péjoratif comme ceux de ploum concernant l'UI de KDE. Enfin bref...

Pour te répondre, oui Phonon est une couche d'abstraction au dessus des framework multimedia. Sous Linux, il permet d'utiliser xine, Gstreamer ou prochainement NMM, voir jack comme serveur multimedia, ce qui permet donc à chacun de choisir celui qui lui convient. Et permet une portabilité plus aisée sur les autres plateformes car la "seule chose à faire" est d'écrire l'interface entre Phonon et le framework usuel de la plateforme. Pour l'appli, c'est en gros transparent (je dis en gros car je suppose que selon la plateforme, il y aura des fonctionnalités plus ou moins bien supportées qui doivent être désactivées quand elles ne sont pas dispos).

Et cela dit aussi, bon anniversaire à Gnome.
Je n'aime pas, je n'utilise pas, mais c'est du logiciel libre, nom d'un caniche!
Ca a droit à mon respect!

Il ne t'es pas venu à l'esprit que le passage à QT4 demandait de toute façon une réécriture des applis et que tant qu'à faire, il pouvait être intéressant de remettre tout à plat pour simplifier les choses?
En l'occurence, un truc comme Phonon rend la création d'applis multimédia plus simple. Et il en est ainsi pour toute l'infrastructure qui est mise en place pour KDE4. Quitte à porter les applis vers de nouvelles API, autant que celles-ci soient le plus définitive possible. Par ailleurs, le projet KDE est ainsi fait que les applis faites pour KDE 3.0 sont censées continuer à tourner sous KDE 3.5.7. Il en sera de même pour KDE 4.X, il falait donc que toute l'infra soit là, car après elle ne changera pas jusqu'à KDE5.
Parfois ce genre de remise à plat peut être très bénéfique sur le moyen et long terme. Ce qui est fait actuellement sur KDE 4.0 est très prometteur.

Si un jour GEGLE (si c'est bien comme cela que cela s'écrit) remplace GTK avec toutes les améliorations qu'il est censé apporter, alors Gnome devra en passer par là aussi. La seule raison qui permet à Gnome d'évoluer de façon incrémentielle, c'est surtout que sa librairie fondamentale n'évolue pas de façon radicale.

Tout le monde n'utilise pas Gstreamer pour le moment et cela n'est pas portable sous Win ou MacOS. L'un des avantages de QT4 est qu'il existe en GPL sous Win et que donc, il va être possible de porter les librairies et les applis KDE sous cette plateforme, comme sur Mac.
Phonon permet alors aux applis multimédia KDE de fonctionner de façon transparente sur ces plateformes, car il sert de couche d'abstraction entre elles et le framework multimédia de la plateforme (comme on l'a dit au dessus, DirectX sous Win et Quicktime sous Mac). On pourra donc avoir Amarok sous Win, sous Mac ou sous Nunux avec Gstreamer ou xine, selon ce que tu préfères.
Et sans que cela demande quoi que ce soit aux développeurs de l'appli.
Si ça c'est pas top moumoutte.......

Bon ceci étant dit, je vois pas trop l'intérêt de ramener tout cela sur une news Gnome.

Je ne saurais pas dire, ne connaissant pas Pinnacle Studio.
En général, là ou les softs de montage pros se distingue, c'est plus sur les résolutions supportées, sur les garanties de sortie de couleur, sur les possibilités de masques et globalement sur la vitesse et la capacité à gérer de gros projets avec beaucoup, beaucoup de pistes et de rushs.
La différence ne saute pas aux yeux à première vue, mais apparait vite dès que tu montes des films de plusieurs dizaines de minutes avec des centaines de plans.
Je n'ai pas assez utilisé MainActor pour savoir de quel côté il se trouve.

A mon avis, tout n'est pas libérable, à commencer par les codec d'exports qui sont le gagne-pain de MainConcept.
Mais ceux-ci pourraient surement être remplacés par les codec FFMPEG (plus exactement libavcodec/libavformat) qui généralement font plutôt du bon boulot.
Il me semble que dans ses dernières versions, MainActor utilisait Qt, cela permettrait probablement une récupération de tout le code de l'interface assez aisée.
Reste à savoir ce qui est récupérable du framework multimédia utilisé.

Montage linéaire, c'est un montage vidéo en temps réel, donc avec des flux capturé par des caméras que tu montes à la volée. C'est la TV, quoi.
Montage non linéaire, c'est celui que tu fais en ayant des rush, des images, des sons et que tu montes tout cela sur des pistes pour exporter le tout en fichier vidéo.

Concernant la libération du code de MainActor, cela pourrait être une bonne chose. Pour le moment, le seul soft de montage avec les mêmes fonctionnalités (voir meilleures) est Cinerella, mais son interface est vraiment trop mal foutue pour un travail pro. Les autres soft sont assez loin, que ce soit Kino, KDEenlive ou autres. Jahshaka n'est pas du tout dans le même créneau, c'est un logiciel de compositing qui est très prometteur mais trop instable pour le moment.
PErso, un MainActor GPL me plairait bien. Ca ferait une base de travail complète pour des devs afin d'ajouter des fonctionnalités intéressantes. Je serais prêt à donner des sous pour cela.
Et l'intérêt de payer pour celui là plutôt que pour les autres, c'est que cela permettrait d'avoir de facto un soft fini et utilisable et de voir du coup rapidement une communauté de devs se former autour pour l'améliorer, comme cela a fait pour Blender, qui est maintenant loin devant toute alternative libre.

Je ne sais plus, c'était en 2005, la distribe stable de l'époque. Crois-moi ou non, c'est pourtant bien ce qui s'est passé. Le passionné de Debian qui était dans ma boite à l'époque, et qui maintient un des miroirs, avait été un peu vert.
Pour ce qui est de changer de distribution, tant que le principe général de la distribution ne te convient pas, il vaut mieux en changer.
Maintenant, je suis d'accord avec toi : la Slack a quelques soucis de temps en temps, comme toutes les autres, mais je n'en changerai maintenant pour rien au monde.

Ubuntu sort sans KDE. Ca n'a pas l'air de gêner grand monde. Il n'y a pas (plus) Gnome dans la Slack. Bon. Quel est le rapport avec la gestion des packages?

Secondement, certes tu peux compiler des sources sur les autres plateformes mais du coup, tu te retrouves avec certains logiciels gérés par le logiciel de packages, d'autres non, des fichiers de configurations non standards (la plupart des distributions ont des fichiers de conf spécifiques qui ne sont pas pris en compte par les sources), etc.
En général, tu te retrouve assez vite avec un système un peu bordelique, ce qui explique que la plupart des gens attendent des archives correctement packagées pour leur distribution.
Avec la Slack, tu n'as pas ce souci, car de toute façon, Volkerding conserve les méthodes de configuration par défaut des sources, donc les docs des différents projets sont directement applicables, pas besoin de savoir "comment ça se configure sous Debian ou sous Red Hat". En fait, il n'y a strictement rien à faire pour créer un package Slack tout à fait raisonnable que de lancer la compilation des sources, faire une installation avec DESTDIR ou PREFIX, puis lancer le script 'makepkg'.

Enfin, car tu n'a pas l'air de le comprendre, il n'y a pas de gestion automatisée des dépendances sous Slack. Donc, quand tu mets un package à jour, il ne va pas t'en installer d'autres. Et quand tu mets à jour ta Slack, tu peux parfaitement éviter de d'installer un package et si par malchance ton package est remplacé, un simple "updatepkg" avec ton ancien package te ramène à la version que tu apprécies.

En bref, tu contrôles tout, sous la Slack. Evidemment, ça implique des difficultés que tu n'as pas sous les autres distributions, mais aussi une souplesse que tu n'as pas ailleurs non plus. On aime ou on aime pas.

Bon, les autres ont déjà répondu mais j'ai tout de même envie d'insister :

Non, la Slack ne va rien m'obliger du tout. C'est d'ailleurs la caractéristique principale des systèmes ne gérant pas automatiquement les dépendances, s'pas?
Si je me suis mis une version d'un projet, genre PHP, compilée de mes blanches mimines avec mes modifs à moi, et que je mets à jour Apache, cela ne va pas forcer la mise à jour de PHP. Et balancer la nouvelle version de la Slack dessus, en prenant bien soin de ne pas toucher à PHP, va marcher également.
J'ai gardé un version de Glut pendant 3 ou 4 versions de la Slack comme cela, sans jamais la refaire.
Essaye ça avec une Debian, une Red Hat ou une Suse, tu ne pourras que passer par un --nodeps et une fois que tu as commencé à installer des packages de cette manière, la gestion des dépendances devient un peu une farce.

Bon, d'accord, mon exemple était pas terrible.
Ce que je voulais illustrer, c'est que je peux sans souci avoir un transcode 1.1CVS sur une Slack 10.0. Et que mon transcode 1.1CVS compilé sous la Slack 10.0 marchera toujours quand je passerai sous Slack 12.0.
La gestion automatisée des dépendances ne te permet tout simplement pas cette souplesse.

Ben non. Une fois, j'avais tenté d'installer une Debian light, avec uniquement KDE. Et là, pour imprimer, je décide d'installer CUPS. Du coup, apt-get me descend tout Gnome, parce que le petit gaillard qui avait compilé CUPS avait mis comme dépendance gimp-print ou un truc dans le genre. Ce n'est qu'un des nombreux exemples de ce qui m'a toujours gavé avec les gestions de dépendances.

L'intérêt de la Slack, c'est que justement tu n'installes pas tous les softs à la main. Tu as une distribution assez complète et surtout avec la base fondamentale qui te permet de construire ce qui peut te manquer sans souci. En gros, Volkerding t'installe toutes les dépendances les plus courantes, et après tu te débrouilles. Et moi, honnêtement, je ne veux rien d'autre, je trouve toujours que les autres distribes se mettent en travers de ma route.

J'ajouterai à ce que disent les autres que quand tu compiles tes sources, tu n'as pas toujours à mettre à jour les librairies fondamentales.
Il me semble que les systèmes de gestion de dépendance mettent à jour des librairies en fonction de ce qui était présent à la compilation des packages. Il faut donc avoir en général au moins la version de chaque librairie utilisée à la compilation ou plus récente (corrigez-moi si je me trompe). De plus, un système de gestion de packages va t'installer des trucs dont tu pourrais te passer, sous prétexte que le logiciel que tu désires a été compilé avec.
Or, beaucoup de nouvelles versions de projets ne demandent pas spécialement les versions les plus récentes des librairies sous-jacentes. Du coup, tu n'es pas systématiquement obligé de les mettre à jour.
Un exemple : tu installes transcode et tu as une vieille version de libdvdread. Si le transcode a été compilé avec la dernière version de libdvdread, le système de gestion de packages va la mettre à jour, quitte à casser la compatibilité avec d'autres logiciels utilisant cette librairie et déjà installés. Alors que tu peux compiler ton transcode avec ta vieille libdvdread sans souci.
Maintenant, comme disent les autres, il y a des versions minimum à respecter, c'est dans les README et INSTALL. Il est aussi pas toujours inutile de mettre à jour les librairies, évidemment.

Il n'y a donc pas de solutions magiques. Il faut un peu mettre la main à la pâte. Mais avec la Slack, comme toutes les librairies fondamentales sont disponibles, il est rare d'avoir à installer plus de 1 ou 2 dépendances pour n'importe quel projet.

Allez, on décortique, tu sembles avoir besoin de réviser ton anglais, où alors tu as l'analyse sélective :

"GNOME is and always has been a moving target" : non, ce n'est pas une question d'innovation, c'est une question de changements trop réguliers qui empêchent de mettre en place un processus industriel de compilation. C'est ça que cela veut dire. En gros, à chaque nouvelle release, il fallait vérifier tout le processus de compilation et la liste des librairies nécessaires.

"even the "stable" releases usually aren't quite ready yet" : Tiens, tu l'as pas mal évacuée, celle-là. En gros, il y a des problèmes de finition.

"that really does demand a team to keep up on all the changes" : Est-ce si différent de ce que j'ai dit? Est-ce si compliqué de comprendre que l'idée est que Gnome est difficile à maintenir pour une personne seule, alors que KDE l'est moins? Et que c'est cela qui a motivé la décision de Volkerding?

"many of which are not always well documented" : pas facile de maintenir dans ces conditions, hein?

Quant à ton mail plus haut, "configure" ne va pas te chercher les librairies manquantes, il te dit juste lesquelles manquent. Et visiblement, d'après d'autres fils, Gargnome ne marche pas si bien que cela, et résoudre les dépendances dans le bon ordre a l'air d'être assez infernal.
Et quand bien même il fonctionne bien maintenant, cela n'était visiblement pas le cas il y a deux ans. D'autre part, il n'est pas certain que Gargnome puisse te permettre de créer aisément des packages Slack, et si tu dois te le repersonnaliser à chaque nouvelle release de Gnome, cela ne te te facilite pas tellement la tâche et reste un travail important.

Enfin, je ne critique pas Gnome, mais t'as l'air trop bouché à l'émeri pour le comprendre.

Non. Un débutant peut s'en sortir en suivant les indications données.
Un truc de geek, pour moi, est un truc que seuls les geek veulent mais aussi peuvent utiliser.

Je n'ai pas reformaté ma partition système depuis 4 ans : elle a reçu la 9.1, la 10 la 11 et maintenant la 12, avec pas mal de passages par la current, sans aucun souci. Aucun comportement bizarre, quelques trucs qui se mettent à foirer après une upgrade malheureuse, mais le retour arrière est du gâteau, une mise à jour à chaque fois propre et sans bavure.
Et régulièrement, je mets mes propres noyaux Linux compilés à partir des sources officielles, ce qui fait que je suis en 2.6 depuis quasiment le début.

Dans le genre troll tu ne portes pas trop mal.
Bon, explication de mon exemple :

Maintenir KDE, ça demande :

- de télécharger les archives KDE, qui sont bien packagées, sur UN site : 2mn devant ton ordi, mettons 1h de téléchargement.
- d'écrire un script pour chaque archive d'une vingtaine de de ligne qui crée le package Slackware. Comme KDE est bien foutu, le script est le même pour toutes les archives, seul le nom de l'archive et les quelques options de configure sont à donner. Plus un script qui lance tous les autres. En tout, une heure, et tu n'as pas à le refaire pour chaque version intermédiaire car il marche tout le temps. Les miens fonctionnent sans souci depuis KDE 3.0. Je regarde juste de de temps en temps les options des "configure" pour voir s'il n'y a rien à ajouter de judicieux.
- Je lance, le script et le lendemain, mon KDE est mis à jour.

Et en l'occurrence, c'est exactement la procédure suivie par Volkering aussi.
Lui a l'air de dire que faire la même chose avec Gnome n'est pas si simple, qu'il y a plein de packages et de dépendances à aller chercher à plein d'endroits différents, qu'il faut passer beaucoup de temps à vérifier les différentes versions des dépendances pour savoir qu'est ce qui marche avec quoi, qu'on tombe souvent dans des soucis de compilation, en bref qu'il faut fournir un gros boulot de consolidation que les devs de KDE font eux-mêmes.
Si tu ne vois pas la différence, c'est que tu ne t'es jamais donné la peine de faire ce travail toi-même. Et donc que tu parles sans connaitre.

Pour le reste, oui, c'est le choix de Volkerding de faire sa distribution tout seul (avec de l'aide de contributeurs, ces derniers temps), c'est son choix de virer Gnome quelle que soit la raison, et c'est son choix de fournir des scripts et des docs en mode texte.
Ce n'est pas non plus parce que c'est son choix qu'il n'a pas de bonnes raisons derrière.
En tout cas, je ne vois pas quelles sont tes bonnes raisons à toi de faire ton offusqué et de donner des leçons. Si ça ne te plait pas, utilise ta Ubuntu ou ta Mandriva, c'est toujours mieux que Windows.
Si c'est maintenant parce que tu n'aimes pas qu'on dise de mal de ton Gnome chéri, ça ne vaut pas le coup de monter sur tes grands chevaux : nombre de "Slackeux" utilisaient Gnome avant que Pat le retire et ont été ennuyés de ce retrait. Nul ne reproche quoi que ce soit à Gnome en tant qu'environnement, mais si Volkerding dit que c'est difficile à maintenir pour une personne seule, je prends sa parole avant celle de n'importe qui dans le monde Linux. Et certainement avant la tienne.

Je suis assez d'accord avec Nicolas au dessus : une Slack, c'est un système parfaitement utilisable, c'est pas juste un truc de geek.
Certes, il y a quelques manips à faire qui ne sont pas forcément simples pour un total débutant, mais elles sont pour la plupart documentées dans les fichiers en texte fournis sur les CD et elles donnent au gens la bonne habitude de lire des docs et d'apprendre à utiliser un système.
Mais au final, tu obtiens un KDE avec Koffice, le navigateur que tu préfères entre Konqueror et Firefox, un outil de gestion de mail, un truc pour lire tes MP3 (Amarok), un pour tes DVD et tes vidéos (Xine), de quoi chatter sur le web, enfin bref, la plupart des trucs qu'on peut faire avec Linux.
Très sincèrement, la Slack est la seule distribution que je n'ai pas réussi à foutre en l'air en deux semaines. Sur toutes les autres distributions que j'ai testées, les updates automatiques, les mises à jour de librairies quand je veux installer un nouveau soft et les conflits avec ce que j'ai compilé de mes blanches mains ont toujours fini par donner un système instable, avec des trucs qui foirent sans réelle logique.
Non, l'intérêt de la Slackware, c'est pas qu'elle est bien pour apprendre, c'est la maîtrise : on maitrise ce que l'on fait sur une Slack (on a pas le choix, diront des esprits chagrins), ce n'est vrai sur pratiquement aucune autre distribution.

Bon, maintenant, qu'elle ne soit pas adaptée à des utilisateurs non informaticiens et peu désireux d'apprendre, je ne le conteste pas. Il ne faut pas avoir peur de lire un fichier texte, d'éditer en ligne de commande avec vi ou de lancer des commandes dans une console.

Ensuite, ajouter ce qui manque ne me demande que de récupérer une vingtaine d'archives.
Personnellement, en plus du système de base, j'installe OpenOffice (je prends les RPMs et je les convertis en archives Slack avec rpm2tgz), puis je compile une vingtaine de projets pour avoir le reste (genre libdvdcss, codeine, transcode, wine).
C'est un tout petit peu plus long que d'installer des archives binaires, mais en même temps, je les fais évoluer comme je veux, sans être obligés de mettre à jour plein d'archives pour des questions de dépendances à la compilation. Et sincèrement, avec des Slackbuilds bien faits, compléter l'installation de base avec ses archives à soi, c'est un script à faire tourner pendant une nuit qui compile les sources, installe les binaires avec redirection, crée l'archive Slackware et la met à jour. Vraiment rien de compliqué et on apprend plein de trucs à le faire.

Compiler KDE, une fois que tu as ton Slackbuild, c'est télécharger 15 archives, toutes au même endroit, et lancer ton Slackbuild. Je fais cela en une nuit à chaque sortie de KDE et je n'ai **jamais** de problèmes.
Qu'en est-il de Gnome?

Peut-être faudrait-il surtout se plaindre au projet Gnome de la complexité de maintenir leur projet, plutôt qu'en vouloir à Pat.

Parce que tu penses que ce sont les développeurs qui font les parts de marché? Analyse subtile.
Met derrière Gimp une Fondation avec les mêmes finances que la Fondation Mozilla (qui a tout de même eu les sous pour payer des pubs, je le rappelle) et on en reparle.

A aucun moment, je n'ai remis en question le travail des développeurs de Firefox, juste relativisé l'aspect extraordinaire de leur travail, qui ne me semble pas spécialement plus remarquable que nombre de projets open source.

Bon, et puis bref, ça n'a pas grande importance, tout ça....

Hé hé hé tu as raison, ce mot m'est venu à cause de l'anglais.
Ceci étant dit, tu as en partie tort, car "achèvement" en tant que "haut-fait" est bien un des sens français, même si ce sens est plutôt vieilli.
Sur ce lien, par exemple :

http://atilf.atilf.fr/dendien/scripts/fast.exe?mot=ach%E8vem(...)

"Néol. d'aut., vieilli. Résultat de l'action, entreprises menées à leur terme, hauts faits :

10. Va, Michel, Prince des armées célestes, et toi, immédiatement après lui en achèvemens militaires, Gabriel : conduisez au combat ceux-ci, mes invincibles enfans...
F.-R. DE CHATEAUBRIAND, Paradis perdu, trad. de John Milton, t. 2, 1836, p. 9.
Rem. Dans ce passage, achèvement correspond dans le texte orig. de Milton à prouess qui signifie « valeur, vaillance »; il s'agit d'entreprises, d'actions menées à leur terme, mais aussi d'actions d'éclat, de prouesses. Peut-être s'agit-il d'éviter prouesses, devenu fam. en fr. usuel; le modèle a pu être le lat. res gestae."