Je devrais tourner mon clavier 7 fois avant de cliquer envoyer. Donc je rajoute un truc que j'ai ommis : même à Apple, avec leur très restreinte gamme hardware, ont *déjà* (c'est rare mais c'est arrivé) eu de gros problème de compatibilité. Une certaine version d'OSX était totalement instable sur les PowerMac G5 1,8 ghz et ça a mis de très longs mois pour se corriger.
Bref, c'est un peu facile de sauter sur Ubuntu, c'est un truc qui arrive à tout le monde.
"Quelle sont les pistes possibles pour éviter des désastres pareils à votre avis ?"
Demander à Red Hat de devenir le Apple du monde linux et de lancer toute une gamme de hardware grand public et pro ?
A part Microsoft, personne ne peut se payer la quantité de tests requis pour faire le moins de conneries possible sur le grand éventail de matériel PC. Et encore, même avec ça, il leur arrive d'avoir des problèmes à patcher. C'est pour ça que tous les chantres du OSX sur PC générique sont de doux rêveurs.
Heu ouais mais le mode sans echec sous windows y'a une GUI et des outils genre msconfig, mmc, regedit etc pour reconfigurer ce qui ne va pas sans trop de problème.
Un acces root à la ligne de commande, ce n'est pas vraiment ce que cherchent les utilisateurs d'Ubuntu.
Ce genre de chose, c'est faisable pour la bouffe, c'est même recommandable parce que la bouffe de grande surface c'est à 70% de la merde et on trouve des bons trucs dans les marchés ou dans le monde de l'artisanal.. (ah, mon beau saucisson)
Bien bouffer, c'est avoir la santé, et la santé, c'est plus important que le reste.
C'est quand même vachement plus dur pour les vêtements et l'électronique. La vie est chère.
>> For me, the main problem is that there are ReactOS developers who
>> think that examining Windows assembly to write ReactOS code is a
>> proper way to do things.
> I think the problem is that the way you describe is totally legal in
> most countries.
> In fact, afaik it is only in the USA where you have this explicit
> distinction between clean("chinese wall") and "dirty" reverse engineering.
> Which reminds me of a similiar thread on lkml about which country's laws
> actually applies
A ta place, je chercherais pas à savoir quelles étapes il faut avant de construire tous les composants qui servent à l'électronique de tous les jours. Je vois écrit sur mon appareil photo payé 900 euros à l'époque : Made in China. (olympus E-300)
That was in the past. WINE is now staying clear of ReactOS, not even accepting patches ported from it. ReactOS's collaboration with the tinykrnl project has ruined its reputation.
A developer wrote: This patch bases on reactos [xxxxx].dll.
A. Juliard [Jun 06]: No ReactOS-derived code will be accepted in Wine at this point.
M. McCormack[Jun 06]: [...] This is not simply a problem of what is legal and not in different countries. We don't want to be associated project that is perceived to be pushing the edge of what's legally (or even socially) acceptable. Doing so would encourage FUD about Wine and that's a good way to lose developers and users. [...] Using test cases to determine the behaviour of Windows provides a way to verify both the code that's written today, and code that will be written a year later. It's not just legally better, it's easier to do, easier for others to understand, and gives us a way to verify our code.
Le problème de ce projet, c'est qu'il existera déjà un successeur à Vista le jour où ReactOS sera totalement utilisable, il sera déjà tellement dépassé technologiquement par linux et Vista+1 que personne n'en voudra.
En fait, j'ai mal lu. J'avais interprété dans le sens où ce serait considéré comme bien de cracher techniquement sur MS même en disant des mensonges.
Je suis tout à fait d'accord de critiquer les points sensibles du monde propriétaire (DRMs, NGSCB, TCPA, TPM, formats fermés et périssables..), je suis juste contre de le faire avec des faux arguments ("Windows ça plante tout le temps").
Des nouveaux changements au sein d'xorg laissent penser qu'on aura plus besoin de 915resolution :) Je sais, c'est hors sujet, mais comme tu en parles et que ça touche mon laptop aussi, je pense que c'est une bonne info. http://wiki.x.org/wiki/IntelGraphicsDriver
"Sur Linuxfr, on parlait plus souvent de Kheops / Slackware que de Ubuntu / Mandriva même si Mandrake commençait à être super bien interfacée et RedHat entrait au Nasdaq (discussions en pagailles)."
La vision "dualiste" du logiciel libre qui voudrait séparer la communauté des entreprises commerciales c'est n'importe quoi. Sans la contribution en code d'entreprises comme Red Hat ou IBM, vous seriez un peu dans la merde. C'est pas Patrick Volkerding qui embauche des mecs pour bosser sur GCC et le kernel.
"Concernant ton paragraphe sur ms, oui c'est sur qu'ils sont bien obligé de sortir des produits un peu meilleurs que les précédents (ou de le faire croire...) mais ton commentaire ne fait qu'illustrer le propos de celui auquel tu réponds. Derrière un faux pragmatisme se cache un glissement phylosophique certain. Tout comme Nicolas, je pense qu'il s'agit d'une conséquence de la "grand publication" de linux[fr.org]."
Il s'agît d'une conséquence de l'amélioration des produits chez Microsoft, point. J'ai eu du windows à la maison depuis win95 OSR2, les changements de stabilité entre la série 9x et NT est édifiante. Déjà à l'époque je rêvais d'un NT4 grand public, compatible avec plus de logiciels communs et de jeux.. Windows 2000 a réalisé mon fantasme de l'époque. Win2k permettait de faire tourner la plupart des applis que j'avais et avait une stabilité exemplaire.
Y'a rien de philosophique là dedans. Les Win9x sont des OS horribles avec un système de fichier horrible (FAT32, on te regrettera jamais.). Depuis cette série de windows n'existe plus et les OS grand public et pro ont la même architecture de base. (Windows XP home ne fournit pas d'outils graphique pour gérer les ACL par exemple mais c'est toujours accessible en command line ou avec des utilitaires hors microsoft.)
Certaines personnes vivent ici sur un nuage où tout ce qui est open source est *forcément* meilleur que tout ce qui se fait en propriétaire. Ben tiens.
"Kde à Kubuntu (mais peut-être pas le support de Canonical)."
Kubuntu c'est juste une "cerise sur le gateau". La machine marketing derrière Ubuntu elle pousse Gnome.
Les premières Kubuntu étaient horriblement instables et les packagers avaient fait du boulot de merde. En fait, c'est dire, utiliser KDE sur une fedora, malgré le manque de logiciels QT, devait être plus agréable qu'utiliser les premières Kubuntu. La dapper est un peu plus correcte mais ça reste de la mauvaise finition.
"Imaginons que KDE choisisse Xine (ce qui n'empêche pas chaque application d'utiliser NMM ou autre). Xine profite du support de KDE et Xine s'améliore".
C'est là que je ne te suivais pas, en fait. En tant qu'utilisateur, Xine me va très bien et je ne vois pas de raison d'améliorer ce qui me convient déjà. Du point de vue des développeurs KDE, ils veulent s'immuniser si un jour Xine ne trouvait plus de programmeurs pour maintenir le backend (ce qui est tout à fait possible, dans le fond..), en créant une architecture indépendante couvrant les besoins minimaux et permettant de se séparer en un rien de temps du backend abandonné.
Note que les mecs qui créent les API et l'abstraction de Phonon n'ont pas forcément les compétences requises pour développer à plein temps Xine lui même. Entre faire quelques abstractions et faire tout un framework multimédia, y'a un monde.
Devant une telle ignorance feinte de ta part alors que la page même de DBUS précise bien qu'il est plus complexe que DCOP, je me contenterais d'un :
Ta gueule.
"The additional complexity of D-Bus arises from its separation of object references vs. bus names vs. interfaces as distinct concepts, and its support for one-to-one connections in addition to connections over the bus. The libdbus reference implementation has a lot of API to support multiple bindings and main loops, and performs data validation and out-of-memory handling in order to support secure applications such as the systemwide bus."
Et un détail croustillant :
"D-Bus is probably somewhat slower than DCOP due to data validation and more "layers" in the reference implementation. A comparison hasn't been posted to the list though. "
Contre un couteau, je préconise quand même la fuite. Faut mesurer le danger, se battre à main nue c'est une chose, se battre contre un mec ayant un couteau, c'est autre chose.. les chances de survie ne sont pas les mêmes. Le mec qui te plantes le couteau dans le ventre est certainement plus décidé à te voir mourir que le mec qui se bats à main nue.
Si tu veux mettre des grandes gueules K.O, le mieux c'est de faire de la boxe anglaise et d'apprendre des techniques de combat militaire.
Quelqu'un d'autre a suggeré le Krav Maga, c'est une option viable aussi.
"Sinon, au niveau des appuis commerciaux de KDE, il ne faut pas oublier Mandriva et SUSE."
SuSE a viré une partie de son staff quand ils se sont fait chopper par Novell (les vrais décideurs sont du camp Ximian.) et Mandriva est une petite distribution qui n'a pas vraiment le moyen de réellement soutenir KDE. D'ailleurs, t'as cas comparer la contribution de Mandriva et celle de Red Hat sur des sujets importants comme le kernel, gcc etc, tu verras que Mandriva à part faire leur propre distrib ils font pas grand chose.
"
> Les mecs d'Eazel ont voulu programmer au départ le Nautilus en C++ mais chez gnome ça a hurlé alors ils l'ont codé en C.
Du style un couteau sous la gorge ?
Il y a des programmes en C# maintenant dans Gnome."
Les temps changent, et les mecs de Ximian pèsent un poids lourd sur les décisions prises par Gnome. Le fait qu'Eazel se soit fait critiquer pour avoir voulu faire le nautilus en C++ ne change pas.
"Le mode spatiale est toujours là et toujours par défaut.
Apparament tu n'utilises pas nautilus."
Je sais, et c'est le mode par défaut de Fedora, mais pas de toutes les distro, et quand je disais qu'ils en reviennent, c'est de l'avis d'une bonne partie des grandes têtes derrière Gnome. Lis un peu ce qu'ont à dire Nat Friedman ou Jeff Waugh sur le sujet.
"KDE ne fait rien pour que ça arrive. KDE attend que ça arrive.
Gnome et Gstreamer se bouge le cul pour que ça arrive."
KDE n'a pas les ressources requises pour participer au développement de ton beau gstreamer, tout ce qu'ils peuvent faire, c'est juste l'adopter, ce qui est une très mauvaise idée. KDE n'a que Trolltech comme boite commerciale qui soutient, et c'est surtout du côté de la lib QT. Gnome a Red Hat, Novell (qui a acquis Ximian), des aides pour les HIG de Sun et pas mal de bugfix, ils ont eu Eazel pour créer Nautilus, niveau marketing ils sont bien servis avec Ubuntu dernièrement..
C'est comme si tu comparais les ressources mises sur linux et celles mises sur les BSD. Alors ouais, KDE ne participe pas directement à la création de ton framework multimédia, et ?
"KDE différent de Gnome est aussi justifié par deux "catégories" de développeurs : les pro-object et les pas pro-objet."
Hein ? c'est avec quoi que tu te drogues ?
Les développeurs de Gnome sont certainement autant pro-objets que les développeurs de KDE. Ils ont recrée le C++ en C avec la glib/gtk..
C'est une guerre de religion C/C++ qui provient des temps sombres de g++ et du fanatisme du projet GNU..
"Il y a quelques temps, on nous rabachait que KDE avait au moins 3 ans d'avance sur Gnome, que C++ roxor et C puxor, etc..."
Faut voir aussi le fanboysme du projet GNU sur le C. Les mecs d'Eazel ont voulu programmer au départ le Nautilus en C++ mais chez gnome ça a hurlé alors ils l'ont codé en C. A propos de ce pauvre Nautilus, il a été mutilé par la mode spatiale puis ils sont revenus en arrière, avec une bonne partie de développeurs gnome de haut calibre qui disent que c'était un échec..
"Puis KDE jurait que jamais il n'utiliserait Dbus car c'est une émanation du maléfique Gnome, que ça pue et que Dcop a au moins 10 années lumières d'avance."
Du calme, car ici, c'est DBUS qui est arrivé comme un cheveux sur la soupe en copiant les principes de base de DCOP et en rajoutant de la complexité à la tâche. Hebergé par freedesktop, les mecs de KDE vous font une faveur en adoptant un projet censé favoriser l'intéropérabilité des deux desktop..
En attendant, j'attends de voir une utilisation plus poussée chez Gnome de leur corba avant qu'ils la ramènent, quand on voit où on en est avec les kparts sous KDE..
kparts et KDE = code reuse. Kontact, le concurrent KDE à Evolution, réutilise des kparts pour toutes ses fonctions, tandis qu'evolution n'est qu'une sale application monolithique à la maintenance affreuse.
"[...]
[Là je coupe ton baratin sur Phonon]
[...]"
Phonon a pour but d'unifier dans le desktop KDE toutes les petites tâches audio que peuvent avoir besoin la majorité des appli, dans une API stable et pas prise de tête. Phonon n'est pas un concurrent à une quelconque technologie gnome et je ne vois pas très bien ton problème, là. Les logiciels les plus compliqués continueront d'utiliser xine ou, au pire, gstreamer, les autres auront une API tranquille sur laquelle ils ne s'arracheront pas les cheveux pour la suivre. En quoi les développeurs de KDE gênent ton pauvre petit gstreamer d'amour ?
"Mais autant choisir tout de suite le meilleur et travailler avec ce dernier pour en tirer profis au-lieu de se limiter au plus petit dénominateur commun."
Le meilleur, actuellement, ça n'est certainement pas gstreamer, donc là, tu repasseras avec tes délires fanatiques.
"Il n'est pas demandé aux développeurs d'applications Gnome ou Gtk de se limiter à une partie de l'API de Cairo (par exemple via Gdk). Alors que du côté de KDE, il va être demandé de se limiter à Phonon (sinon Phonon perd de son intérêt)."
Absolument pas. Les applications avancées sont libres de faire ce qui est nécessaire, le gros du desktop lui utilisera en effet Phonon.
"* La portabilité. C'est à mourir de rire. C'est le boulot même des toolkits."
Phonon permets la portabilité sur les quelques plateformes où gstreamer ne tourne pas. Par sa nature à multiple backend, il ne sera pas très difficile de l'adapter à des systèmes exotiques.
"Le logiciel libre ne gagne rien avec ce type d'attitude (parier sur la division). Ni en image, ni en qualité logiciel."
Les premiers à avoir provoqué cette division, c'est les mecs de Gnome. Gnome 1.x n'était rien d'autre qu'une copie de KDE, avec une interface encore plus bourrée d'options. Ce n'est que tardivement qu'ils se sont cherchés une identité et ont dépassé le stade "Nous sommes KDE en C, et nous sommes pro-GNU".
Je trouve ça gonflé de venir parler de division ici en accusant les développeurs de KDE de pratiquer la "défiance" envers les dev gnome.
[^] # Re: Epi !
Posté par ragnar . En réponse au journal Le web 2.0 et les bookmark... Évalué à 2.
[^] # Re: Vitesse de réaction
Posté par ragnar . En réponse au journal Ubuntu : La MAJ de xserver-xorg fait planter le serveur X. Évalué à 3.
Bref, c'est un peu facile de sauter sur Ubuntu, c'est un truc qui arrive à tout le monde.
[^] # Re: Vitesse de réaction
Posté par ragnar . En réponse au journal Ubuntu : La MAJ de xserver-xorg fait planter le serveur X. Évalué à 3.
Demander à Red Hat de devenir le Apple du monde linux et de lancer toute une gamme de hardware grand public et pro ?
A part Microsoft, personne ne peut se payer la quantité de tests requis pour faire le moins de conneries possible sur le grand éventail de matériel PC. Et encore, même avec ça, il leur arrive d'avoir des problèmes à patcher. C'est pour ça que tous les chantres du OSX sur PC générique sont de doux rêveurs.
[^] # Re: Qui test les MAJ ?
Posté par ragnar . En réponse au journal Ubuntu : La MAJ de xserver-xorg fait planter le serveur X. Évalué à 3.
Un acces root à la ligne de commande, ce n'est pas vraiment ce que cherchent les utilisateurs d'Ubuntu.
[^] # Re: ?
Posté par ragnar . En réponse au journal Microsoft veut coopérer avec l'équipe Mozilla pour le dev de firefox. Évalué à 10.
Je ne suis pas du tout enchanté de voir que Firefox pourrait encore plus donner la priorité à cette plateforme en collaborant avec MS.
[^] # Re: Fier de ton ordinateur ?
Posté par ragnar . En réponse au journal Fiers de vos Ipod?. Évalué à 2.
Bien bouffer, c'est avoir la santé, et la santé, c'est plus important que le reste.
C'est quand même vachement plus dur pour les vêtements et l'électronique. La vie est chère.
[^] # Re: vista
Posté par ragnar . En réponse au journal Version RC3 de ReactOs 0.3.0 disponible. Évalué à 3.
http://www.winehq.org/pipermail/wine-devel/2006-June/048468.(...)
Lis bien à quoi il réponds.
>> For me, the main problem is that there are ReactOS developers who
>> think that examining Windows assembly to write ReactOS code is a
>> proper way to do things.
> I think the problem is that the way you describe is totally legal in
> most countries.
> In fact, afaik it is only in the USA where you have this explicit
> distinction between clean("chinese wall") and "dirty" reverse engineering.
> Which reminds me of a similiar thread on lkml about which country's laws
> actually applies
La date :
Fri Jun 9 20:03:06 CDT 2006
# Fier de ton ordinateur ?
Posté par ragnar . En réponse au journal Fiers de vos Ipod?. Évalué à 2.
Ca va être un peu dur le retour en arrière.
[^] # Re: vista
Posté par ragnar . En réponse au journal Version RC3 de ReactOs 0.3.0 disponible. Évalué à 3.
That was in the past. WINE is now staying clear of ReactOS, not even accepting patches ported from it. ReactOS's collaboration with the tinykrnl project has ruined its reputation.
From the wine mailing lists, taken from http://wiki.jswindle.com/index.php/Coding_Hints :
A developer wrote: This patch bases on reactos [xxxxx].dll.
A. Juliard [Jun 06]: No ReactOS-derived code will be accepted in Wine at this point.
M. McCormack[Jun 06]: [...] This is not simply a problem of what is legal and not in different countries. We don't want to be associated project that is perceived to be pushing the edge of what's legally (or even socially) acceptable. Doing so would encourage FUD about Wine and that's a good way to lose developers and users. [...] Using test cases to determine the behaviour of Windows provides a way to verify both the code that's written today, and code that will be written a year later. It's not just legally better, it's easier to do, easier for others to understand, and gives us a way to verify our code.
# Le problème.
Posté par ragnar . En réponse au journal Version RC3 de ReactOs 0.3.0 disponible. Évalué à 5.
[^] # Re: ...
Posté par ragnar . En réponse au journal DLFP is dying. Évalué à 2.
Je suis tout à fait d'accord de critiquer les points sensibles du monde propriétaire (DRMs, NGSCB, TCPA, TPM, formats fermés et périssables..), je suis juste contre de le faire avec des faux arguments ("Windows ça plante tout le temps").
[^] # Re: Les Gnomistes m'emmerdent
Posté par ragnar . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 2.
http://wiki.x.org/wiki/IntelGraphicsDriver
"
https://bugs.freedesktop.org/show_bug.cgi?id=643
For all those who don't know. There is a new 'modesetting' branch for native
modesetting without the Video BIOS."
[^] # Re: ...
Posté par ragnar . En réponse au journal DLFP is dying. Évalué à 4.
La vision "dualiste" du logiciel libre qui voudrait séparer la communauté des entreprises commerciales c'est n'importe quoi. Sans la contribution en code d'entreprises comme Red Hat ou IBM, vous seriez un peu dans la merde. C'est pas Patrick Volkerding qui embauche des mecs pour bosser sur GCC et le kernel.
[^] # Re: ...
Posté par ragnar . En réponse au journal DLFP is dying. Évalué à 5.
Il s'agît d'une conséquence de l'amélioration des produits chez Microsoft, point. J'ai eu du windows à la maison depuis win95 OSR2, les changements de stabilité entre la série 9x et NT est édifiante. Déjà à l'époque je rêvais d'un NT4 grand public, compatible avec plus de logiciels communs et de jeux.. Windows 2000 a réalisé mon fantasme de l'époque. Win2k permettait de faire tourner la plupart des applis que j'avais et avait une stabilité exemplaire.
Y'a rien de philosophique là dedans. Les Win9x sont des OS horribles avec un système de fichier horrible (FAT32, on te regrettera jamais.). Depuis cette série de windows n'existe plus et les OS grand public et pro ont la même architecture de base. (Windows XP home ne fournit pas d'outils graphique pour gérer les ACL par exemple mais c'est toujours accessible en command line ou avec des utilitaires hors microsoft.)
Certaines personnes vivent ici sur un nuage où tout ce qui est open source est *forcément* meilleur que tout ce qui se fait en propriétaire. Ben tiens.
[^] # Re: Phonon
Posté par ragnar . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 2.
Kubuntu c'est juste une "cerise sur le gateau". La machine marketing derrière Ubuntu elle pousse Gnome.
Les premières Kubuntu étaient horriblement instables et les packagers avaient fait du boulot de merde. En fait, c'est dire, utiliser KDE sur une fedora, malgré le manque de logiciels QT, devait être plus agréable qu'utiliser les premières Kubuntu. La dapper est un peu plus correcte mais ça reste de la mauvaise finition.
"Imaginons que KDE choisisse Xine (ce qui n'empêche pas chaque application d'utiliser NMM ou autre). Xine profite du support de KDE et Xine s'améliore".
C'est là que je ne te suivais pas, en fait. En tant qu'utilisateur, Xine me va très bien et je ne vois pas de raison d'améliorer ce qui me convient déjà. Du point de vue des développeurs KDE, ils veulent s'immuniser si un jour Xine ne trouvait plus de programmeurs pour maintenir le backend (ce qui est tout à fait possible, dans le fond..), en créant une architecture indépendante couvrant les besoins minimaux et permettant de se séparer en un rien de temps du backend abandonné.
Note que les mecs qui créent les API et l'abstraction de Phonon n'ont pas forcément les compétences requises pour développer à plein temps Xine lui même. Entre faire quelques abstractions et faire tout un framework multimédia, y'a un monde.
[^] # Re: Phonon
Posté par ragnar . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 9.
Ta gueule.
"The additional complexity of D-Bus arises from its separation of object references vs. bus names vs. interfaces as distinct concepts, and its support for one-to-one connections in addition to connections over the bus. The libdbus reference implementation has a lot of API to support multiple bindings and main loops, and performs data validation and out-of-memory handling in order to support secure applications such as the systemwide bus."
Et un détail croustillant :
"D-Bus is probably somewhat slower than DCOP due to data validation and more "layers" in the reference implementation. A comparison hasn't been posted to the list though. "
[^] # Re: Apprendre un art ou apprendre la guerre ?
Posté par ragnar . En réponse au journal Ju-jitsu ou karaté. Évalué à 1.
Contre un couteau, je préconise quand même la fuite. Faut mesurer le danger, se battre à main nue c'est une chose, se battre contre un mec ayant un couteau, c'est autre chose.. les chances de survie ne sont pas les mêmes. Le mec qui te plantes le couteau dans le ventre est certainement plus décidé à te voir mourir que le mec qui se bats à main nue.
# Apprendre un art ou apprendre la guerre ?
Posté par ragnar . En réponse au journal Ju-jitsu ou karaté. Évalué à 1.
Quelqu'un d'autre a suggeré le Krav Maga, c'est une option viable aussi.
[^] # Re: Phonon
Posté par ragnar . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 2.
SuSE a viré une partie de son staff quand ils se sont fait chopper par Novell (les vrais décideurs sont du camp Ximian.) et Mandriva est une petite distribution qui n'a pas vraiment le moyen de réellement soutenir KDE. D'ailleurs, t'as cas comparer la contribution de Mandriva et celle de Red Hat sur des sujets importants comme le kernel, gcc etc, tu verras que Mandriva à part faire leur propre distrib ils font pas grand chose.
[^] # Re: Phonon
Posté par ragnar . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 6.
> Les mecs d'Eazel ont voulu programmer au départ le Nautilus en C++ mais chez gnome ça a hurlé alors ils l'ont codé en C.
Du style un couteau sous la gorge ?
Il y a des programmes en C# maintenant dans Gnome."
Les temps changent, et les mecs de Ximian pèsent un poids lourd sur les décisions prises par Gnome. Le fait qu'Eazel se soit fait critiquer pour avoir voulu faire le nautilus en C++ ne change pas.
"Le mode spatiale est toujours là et toujours par défaut.
Apparament tu n'utilises pas nautilus."
Je sais, et c'est le mode par défaut de Fedora, mais pas de toutes les distro, et quand je disais qu'ils en reviennent, c'est de l'avis d'une bonne partie des grandes têtes derrière Gnome. Lis un peu ce qu'ont à dire Nat Friedman ou Jeff Waugh sur le sujet.
"KDE ne fait rien pour que ça arrive. KDE attend que ça arrive.
Gnome et Gstreamer se bouge le cul pour que ça arrive."
KDE n'a pas les ressources requises pour participer au développement de ton beau gstreamer, tout ce qu'ils peuvent faire, c'est juste l'adopter, ce qui est une très mauvaise idée. KDE n'a que Trolltech comme boite commerciale qui soutient, et c'est surtout du côté de la lib QT. Gnome a Red Hat, Novell (qui a acquis Ximian), des aides pour les HIG de Sun et pas mal de bugfix, ils ont eu Eazel pour créer Nautilus, niveau marketing ils sont bien servis avec Ubuntu dernièrement..
C'est comme si tu comparais les ressources mises sur linux et celles mises sur les BSD. Alors ouais, KDE ne participe pas directement à la création de ton framework multimédia, et ?
[^] # Re: KDE
Posté par ragnar . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 10.
Hein ? c'est avec quoi que tu te drogues ?
Les développeurs de Gnome sont certainement autant pro-objets que les développeurs de KDE. Ils ont recrée le C++ en C avec la glib/gtk..
C'est une guerre de religion C/C++ qui provient des temps sombres de g++ et du fanatisme du projet GNU..
[^] # Re: Phonon
Posté par ragnar . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 10.
Faut voir aussi le fanboysme du projet GNU sur le C. Les mecs d'Eazel ont voulu programmer au départ le Nautilus en C++ mais chez gnome ça a hurlé alors ils l'ont codé en C. A propos de ce pauvre Nautilus, il a été mutilé par la mode spatiale puis ils sont revenus en arrière, avec une bonne partie de développeurs gnome de haut calibre qui disent que c'était un échec..
"Puis KDE jurait que jamais il n'utiliserait Dbus car c'est une émanation du maléfique Gnome, que ça pue et que Dcop a au moins 10 années lumières d'avance."
Du calme, car ici, c'est DBUS qui est arrivé comme un cheveux sur la soupe en copiant les principes de base de DCOP et en rajoutant de la complexité à la tâche. Hebergé par freedesktop, les mecs de KDE vous font une faveur en adoptant un projet censé favoriser l'intéropérabilité des deux desktop..
En attendant, j'attends de voir une utilisation plus poussée chez Gnome de leur corba avant qu'ils la ramènent, quand on voit où on en est avec les kparts sous KDE..
kparts et KDE = code reuse. Kontact, le concurrent KDE à Evolution, réutilise des kparts pour toutes ses fonctions, tandis qu'evolution n'est qu'une sale application monolithique à la maintenance affreuse.
"[...]
[Là je coupe ton baratin sur Phonon]
[...]"
Phonon a pour but d'unifier dans le desktop KDE toutes les petites tâches audio que peuvent avoir besoin la majorité des appli, dans une API stable et pas prise de tête. Phonon n'est pas un concurrent à une quelconque technologie gnome et je ne vois pas très bien ton problème, là. Les logiciels les plus compliqués continueront d'utiliser xine ou, au pire, gstreamer, les autres auront une API tranquille sur laquelle ils ne s'arracheront pas les cheveux pour la suivre. En quoi les développeurs de KDE gênent ton pauvre petit gstreamer d'amour ?
"Mais autant choisir tout de suite le meilleur et travailler avec ce dernier pour en tirer profis au-lieu de se limiter au plus petit dénominateur commun."
Le meilleur, actuellement, ça n'est certainement pas gstreamer, donc là, tu repasseras avec tes délires fanatiques.
"Il n'est pas demandé aux développeurs d'applications Gnome ou Gtk de se limiter à une partie de l'API de Cairo (par exemple via Gdk). Alors que du côté de KDE, il va être demandé de se limiter à Phonon (sinon Phonon perd de son intérêt)."
Absolument pas. Les applications avancées sont libres de faire ce qui est nécessaire, le gros du desktop lui utilisera en effet Phonon.
"* La portabilité. C'est à mourir de rire. C'est le boulot même des toolkits."
Phonon permets la portabilité sur les quelques plateformes où gstreamer ne tourne pas. Par sa nature à multiple backend, il ne sera pas très difficile de l'adapter à des systèmes exotiques.
"Le logiciel libre ne gagne rien avec ce type d'attitude (parier sur la division). Ni en image, ni en qualité logiciel."
Les premiers à avoir provoqué cette division, c'est les mecs de Gnome. Gnome 1.x n'était rien d'autre qu'une copie de KDE, avec une interface encore plus bourrée d'options. Ce n'est que tardivement qu'ils se sont cherchés une identité et ont dépassé le stade "Nous sommes KDE en C, et nous sommes pro-GNU".
Je trouve ça gonflé de venir parler de division ici en accusant les développeurs de KDE de pratiquer la "défiance" envers les dev gnome.