Je ne dis pas que mplayer est un ange. Il y a quelques problèmes et il y avait de gros problèmes. Parmis les problèmes il y a/avait :
1- utilisation de code incompatible GPL.
2- interdiction de diffuser des binaires.
3- utilisation de brevets : mpeg, asf, mp3, etc... C'est libavcodec qui est principalement visé et non mplayer.
4- Réalisation de travaux dérivés sans respecter à la lettre la GPL. C-à-d sans faire un changelog précis des fichiers modifiés, pourquoi, la date, l'auteur, etc...
Le point 1 est corrigé. (voir les sources :-) ). D'ailleur la mailing Debian n'indique jamais l'utilisation de code non compatible GPL (sauf au début mais ils arrêtent vite). La mailing list parle de l'abus d'interdire la diffusion de binaire alors que des sources tiers sont sous GPL (voir point 2, c'est corrigé).
Le point 2 est corrigé (voir des liens dans ce thread). Néanmoins, la distribution sous forme de source pose moins de problème par rapport aux brevets (on ne distribue pas un lecteur mais des sources qui disent comment lire un flux mpeg, etc...). Par contre c'est un problème par rapport à un usage abusif de DMCA.
Le point 3 est effectivement problématique. Néanmoins, on peut construire mplayer sans support pour mpeg 4, asf, mp3, ac3 etc... se qui évite le problème (Mais on a un lecteur de mer..). L'autre méthode, plus brutale, est de virer les sources qui utilisent les brevets.Il faut noter que c'est un problème pour tous les programmes qui utilisent ces brevets (dont xine). Notons que debian fait dans le deux poids, deux mesures, puisqu'ils ne voient pas de problème avec les lectures de mp3. Or, la license mp3 est très claire. Il faut payer si tu récupères un lecteur mp3 d'une autre manière que part le net. Donc il faut virer les lecteurs mp3 des cd. La distribution de distribe debian sur cd n'est donc pas possible. M'enfin, j'ai lu des mails debian indiquant que les brevets ne peuvent pas être appliqués à un programme sous GPL et que donc on peut distribuer un lecteur mp3. Mais bizarrement pas un encodeur mp3 ( http://www.debian.org/devel/wnpp/unable-to-package(...) ).
Le point 4 n'est pas encore corrigé mais ne doit pas être dure à corriger. Une des possibilités est l'utilisation de libavcodec telquel, sans modification. Mais il y a des problèmes techniques actuellement (celà semble proche pour la version 3.1). Néanmoins, je trouve que les debian-intégristes poussent un peu. Il y a des tonnes de projets qui font çà. Suffit de prendre un noyau linux de n'importe quelle distribe pour ce rendre compte que ce n'est pratiquement jamais respecté et que tout le monde s'en fout complètement.
> Bon person je dois avouer que le comportement tres pueril des developpeurs de mplayer ne plaide pas pour eux
Ce n'est pas des développeurs mais un développeur (Gabucino). Et mplayer ce n'est pas un développeur.
> Au lieu de tenter de respecter la lettre et l'esprit de la licence qu'ils ont choisis EUX-MEMES pour leur logiciel
C'est le point 4 qui n'est pas respecté et c'est tout. Je pense que çà va être corrigé. La GPL ne parle jamais de brevets.
> ils preferent s'amuser a denigrer le travail des autres!
C'est vrai, c'est pas cool.
> Ensuite je trouve aberrant le fait qu'ils interdisent la distributions des bianires
Y a un point à préciser. Depuis que mplayer est 100% GPL (version 90pre1 je crois), ils ne l'interdisent plus. Enfin, il ne l'encourage pas sur leur site. mplayer estime que ce n'est pas leur boulot mais celui des distributeurs que de proposer des versions optimisées i686, athon, etc... Quoiqu'il en soit, ce débat est clos car on peut compiler avec toute les optimisations. Le choix se fait à l'exécution. Notons que çà fait depuis un moment que mplayer propose le download de rpm packagé par un tier, http://www.piorunek.pl/~dominik/linux/pkgs/mplayer/(...) , et que la mailing list de support est mplayer-users .
> Ils ont choisi une licence qui s'appelle GPL cela implique des droits mais, malheureusement pour eux, des devoirs en particulier celui de la respecter
Il respecte la GPL sauf pour le point 4. Ce point (qui n'est pas toujours respecté par d'autres projets) peut-être facilement corrigé.
> sinon ils en changent!
Seulement car il ne respecte (pas encore) le point 4. NON. Ce serait une grosse perte pour le Logiciel Libre. D'ailleur mplayer est le logiciel le plus populaire sur freshmeat.net .
Personnellement, mplayer, pour cause d'utilisation de brevets, n'a pas sa place dans debian ni dans une distribe free software comme RedHat, Mdk, etc... Idem pour les lecteurs mp3.
Même chose pour xine qui utilise les brevets mp3, mpeg, ac3, etc, etc... Et c'est là que debian pousse grave alors qu'ils appuient sur leur image de vrais et seul distribe Free Software puisque estampillé GNU. Parfois ils sont intransigeants sur les brevets, parfois ils estiment que les brevets ne s'applique pas pour du code GPL, parfois c'est parque les brevets ne sont pas reconnus dans tous les pays, parfois ils ferment simplement les yeux, etc... C'est à la tête du client, c'est fonction de la direction du vent, de l'âge du capitaine, etc... Remarques que un ou deux "pro-debian" ont eu l'intelligence de proposer de virer xine puisqu'il a les même problèmes que mplayer.
Je suis désolé mais si debian ne fait pas preuve de plus de rigueur, ils n'auront plus à donner des leçons.
> si je me rappelle bien la CS ne contient que des packages officiels sur les applis de haut nivo.
C'est vague.
> Les diffs se situent dans les patche kernels, de gcc et de la libc (protection de pile, tous les patches de protection reso, etc...) donc ca doit pas etre dur a retrouver
Çà reste des supositions même si je pense que tu as raison. Actuellement on ne sait pratiquement rien de la CS. Quelle version de noyau, les add-ons ? Quelle version d'apache/Gnome/KDE, etc...
Si on compare à une RH AS :
kernel 2.4.9
apache 1.3
Gnome 1.4
Je ne pense pas qu'il y a de mauvaises intentions derrière cette discrétion. Néanmoins, l'absence d'un minimum de transparence fait que je déconseillerai l'utilisation de ce produit. Je rassure tout le monde, çà ne va pas avoir un gros impact sur les ventes :-)
Alors que Mandrake fasse un tout petit, un tout petit effort et mettent les sources en ligne. Çà ne diminurait pas ses ventes. Le succès de la RH AS qui coûte plus cher, le prouve. Surtout que cette CS a été partiellement financée pour des abonnements au club.
> d un part je crois que les sources c est celle de la 9.0+toutes les updates si.
Mdk parle d'une distribe testé durant 12 mois. La 9.0 est sortie il y a moins de 6 mois.
> la GPL ne t obligie en rien a diffuser les sources a tout le monde si tu ne diffuses pas les binaires a tout le monde.
J'ai pas parlé de violation de GPL. Je préfère une distributeur qui fourni les sources à toute le monde que rien du tout.
Le projet kde (ou n'importe quel autre projet), peut avoir envis de voir ce qui a été fait dans la corporate server. Ben ils ne peuvent pas sauf s'il débourse 750 .
Afin, l'EULA de la Advanced Server de RedHat est la même que la classique RedHat Linux.
Si quelqu'un me demande ce qu'il y a comme distribe, je dit :
- Mdk
- Debian
- RH
- etc...
Si on me demande une distribe orienté serveur/entreprise avec un "gros" support je ne dirait pas Mandrake si les sources ne sont pas dispos. Si Mandrake s'éloigne de l'open source, ce n'est pas de ma faute.
> Le premier proto de Nautilus était en C++, utilisant gtkmm (ça remonte à 1999/2000). Quand Eazel l'a montré à quelques membres "clés" de Gnome (Miguel, Havoc...), ils leur ont demandé de le refaire en C
J'avoue ma grande surprise. J'ai jamais entendu parlé d'un nautilus en c++. Je peux pas être au courant de tout. Ce qui me surprend beaucoup, c'est que Eazel était une boîte commerciale. J'ai du mal à croire d'une société commerciale, dont le but premier est de faire du pognon pour vivre, est plié face à quelque avis défavorables à l'utilisation du C++.
D'autant plus bizarre que c'est www.gnome.org qui héberge gtkmm, gnomemm, glade-- etc...
> "avant vous payez les logiciels, maintenant avec les logiciels libres vous ne payez plus que nos services..."
Du moment qu'il y a de la concurrence, je ne vois pas de problème de payer un service.
> et la philosophie pas un mot !
Ben les boîtes commerciales informatique qui font de la philosophie, je m'en méfie. Prend MS, ils en font des tonnes de la "philosophie" :
- "grace à nos technos, l'espèce évolue vers le haut, et patati et patata..."
> "vous pouvez modifier le codes source - mais c réservé à une élite - ou le faire faire par des gens comptétants....."
C'est vrai. Prend 100 utilisateurs d'informatique. Au mieux il y en a 3 à 5 qui peuvent modifier un programme.
> les marketeux du Libre qui vont essayer de te vendre une philosophie à leur gout
Faut pas écoute les discours "philosophique" d'une boîte commerciale et se concentrer sur les faits, les licenses, etc...
Peut-être que faire du pognon est incompatible avec la philosophie du libre. Mais ce n'est pas la cas.
> la volonte d'un tk puissant comme base de gnome qui a entraine le split.
Ce que je veux dire, c'est que c'est pas Gnome qui a entrainé Gtk+, mais ce sont les développeurs d'applications. Une application comme gnucash ou evolution est beaucoup plus exigante envers le tk que le bureau Gnome. Les developpeurs d'appli Gnome ont des besoins, ces besoins sont remontés à Gnome (voir gtk) et le team Gnome fait les modifs nécessaires. D'ailleur beaucoup de développeurs d'appli qui utilisent Gnome, développent Gnome également. Par exemple, si tu prends gconf, c'est pas un délire des développeur de Gnome. C'est un outil/librairie qui répond aux besoins des développeurs d'applis.
> il faut pouvoir compiler fam
C'est juste. Je ne connais pas fam dans le detail. C'est pas un gros programme (140k). Il n'utilise peut-être pas beaucoup de fonctionnalités avancées du C++. Il est donc peut-être assez portable. Çà reste des supositions.
> hmmm tu t'avance trop, gcc ne marche pas partout,
Peut-être, mais là où il ne tourne pas il ne doit pas avoir de besoin de Gnome ou KDE. J'ai utilisé gcc sous HP-UX, OSF-1, DEC-UNIX 4, Solaris.
> De plus le but de kde, n'est pas d'imposer un version specifique de compilo pour compiler (ca serait du delire)
C'est pas forcément du délire. Par exemple et il y a d'autres projets qui font de même, mysql et php nécessite gcc.
> si tu veut comparer a qquechose d'equivalent a Gnome ne prend pas Qt
Le problème, est que pour développer une appli KDE il me faut Qt.
> actuellement il y a surtout des progs qui veulent cohoperer avec kde:
> xmms (le plugin en sortie art), gstreamer (le plugin arts), etc...
Pour utiliser art tu passes par un protocole... Tu ne réponds pas à la question.
> maintenant la majorite des petits prog sont en c++
La majorité j'en suis pas sure (peut-être dans les sociétés commerciale). Mais beaucoup, c'est claire.
> car pkoi s'imposer le c qd tu peut utiliser le c++
Si pour les objectifs de mon projet je peut utiliser du c++, je vais prendre c++. On peut maintenant développer des applis Gnome en C++. Par contre pour les objectifs de gnome les librairies de base, sujette à avoir un binding ne peuvent pas être écrite en c++.
> Pour les langages de script, kdevelop est le plus gros utilisateur de ceux-ci (pour la conf, etc...)
C'est des bindings KDE? Je ne crois pas.
Pour être claire. Que KDE utilise C++ et n'a pas ou peu de binding n'est pas un reproche. C'est du logiciel libre et chaqu'un fait ce qu'il veut. KDE fait le bonheur de beaucoup d'utilisateurs et développeurs et c'est sa principale qualité au-delà du choix du language.
Gnome permet d'écrite des applis en c++ via gtkmm/gnomemm. Je ne pense pas que ces solutions soit autant abouti que le couple Qt/Kde. Je comprends parfaitement, et il est logique, qu'un développeur C++ utilise Qt/Kde.
> Mandrake a tjs soutenu les deux desktops de maniere egale.
J'en doute beaucoup. Pour la news sur Gnome 2.2 j'ai cherché les contributions de Mandrake. J'ai trouvé un menbre pour la gnome fondation durant un an (2000) et aucune candidature les années suivantes, de la doc, support supermount et bugfix. Il doit certainement y avoir d'autres points. J'ai aussi lu que Mandrake avait un développeur dédié Gnome.
Ce n'est absolument pas un reproche. Si Mandrake bossent ailleur et que c'est du GPL/BSD, ils sont irréprochables.
> mouais, enfin le tout le monde etait assez limite a cette epoque. Je ne pense pas qu'ils auraient investi dans le dev de Gtk+ si gnome n'en avait pas besoin.
C'est quoi ton problème ?
L'extention ajouté par gtk+ est pourtant très "C++".
L'explication sur le + est donnée par le développeur de gimp/gtk et non par un développeur Gnome. Cette extention est définitivement un plus. Afin, les extensions gtk+ sont pour tout les programmes qui utilisent gtk+ et non pour Gnome. Le but de Gnome est de faire un bureau et offrir des fonctionnalités pour le développement d'appli (evolution, galeon, gnucash, xchat, gnomemeting, etc...). C'est principalement des extensions pour les developpeurs d'appli et non uniquement pour Gnome. D'ailleur, les widgets spécifiques gnome se trouve dans gnome-lib et non dans gtk+.
> dans ORBit (qui on peut l'avouer est la permier implementation d'ORB digne de se nom et fichtrement rapide)
Développé par RedHat dans le cadre du projet Gnome, et en C. Y a même un binding python :-)
> Ben je pense que la problematique du "power user" qui veut pouvoir customizer son envirronement sans necessairement etre admin est un vrai probleme.
Ben trouve moi un cas où tu as besoin de connaitre l'existence de gconf pour customizer ton environnement.
gconftools est pour fixer les valeurs par défauts aux nouveauxcomptes ou imposer des valeurs (par exemple pour un proxy). gconftools est donc pour les admins (d'ailleur il faut être root pour modifier des valeurs).
> lorsque je lance gnome
Damned, pour quelqu'un qui n'arrête pas de critiquer gnome. Mais je pense que tu veux dire "lorsque je lance des applis gnome".
> Et surtout que ca prouve le changement de mentalite des devs gnome
Oh lala. Gnome n'est pas contre le c++. Faut arrêter avec cette légende. Ils se sont imposer la contrainte de pouvoir faire des bindings ce qui n'est pas très compatible avec le C++. C'est tout.
> au debut pas moyen d'avoir ne serai-ce une dependance c++
fam n'ajoute aucune dépendance c++ pour quelqu'un qui veut développer sous Gnome. Sinon, prouve le.
Si apache était écrit en C++, tu n'ai pas obligé de faire un navigateur en C++. Faut pas mélange librairie et protocole. fam est utilisé via un protocole. XFree peut-être réécrit en C++ que Gnome s'en battrait l'oeil. La seul chose qui compte pour les objectifs de Gnome c'est que la partie cliente soit en C. Pour corba, au début, Gnome utilisait une implémentation C++. Ce n'était pas un problème car il y a une librairie cliente était en C et que corba est un protocole.
> selon leurs dires le langage c++ etait supra mal supporte sur la majorite des os
Gcc tourne partout. Moins bien sous windows mais la cible de Gnome n'est pas Windows. Enfin, pour compiler KDE sous HP-UX par exemple, il te faut gcc ou le compilateur HP est suffisant ?
Tu oublies systématiquement les contraintes de Gnome. Gnome utilise systématiquement la LGPL pour ces librairies. Le but est d'authoriser l'écriture d'appli proprio qui utilise ces librairies (on aime, on n'aime pas mais c'est un autre histoire). Dans la même veine il doit être possible d'utiliser les compilos proprio d'HP, Sun, SGI, IBM, etc... Et il faut le reconnaitre, le support du C++ est assez inégale entre compilos. D'ailleur je ne suis pas sure qu'il y ait un compilo qui support tout de la dernière norme ANSI.
Qt est sous GPL. Il ne permet pas l'écriture de programme proprio.
Enfin, j'aimerai que tu me trouves un programme "correcte" qui utilise un binding de Qt ou KDE. Pour te donner un exemple, tous les programmes de configuration redhat utilisent le binding python (redhat-config-packages, up2date-gnome, redhat-logviewer-0.8.3-2).
Arrêtes de dire que Gnome n'aime pas le C++. Ils ont des objectifs. Si les contraintes de ces objectifs te semble incompatible avec tes goûts de programme, alors passe ton chemin.
Juste pour dire aux jeunes qui n'ont pas encore vu ce merveilleux film, "les tontons flingueurs", il y a la célèbre réplique de Francis Blanche (alias Maître Folage) :
- "Touche pas au grisbi, salope !"
J'ai rien contre C++.
> je ne voit pas ce que ca change au probleme.
C'était un troll, private jock. Le projet Gnome pour ces librairies de base évite l'utilisateur de C++ car çà rend les bindings languages difficile.
Donc en général, il est considéré comme "mal" d'utiliser du c++ pour un librairie de base Gnome.
Dans le cas de fam, il n'y a aucun problème à l'utilisation de c++ puisque c'est un serveur. Pour faire une analogie, qu'Apache soit écrit en C ou C++ ne change rien pour les clients (le navigateur). C'est le protocol http qui compte.
Faut pas le prendre mal. Mandrake semble préférer KDE (mdk était au début une RedHat avec ajout de KDE, mdk fournit plusieurs développeurs pour KDE). Ce n'est en rien reprochable. Tout le monde à le droit d'avoir des préférences.
[^] # Re: mplayer vs Debian
Posté par matiasf . En réponse à la dépêche Sortie de mplayer 0.90 rc4. Évalué à 3.
?!
Je fais mes paquets binaires depuis un src.rpm sous un compte normal.
[^] # Re: mplayer vs Debian
Posté par matiasf . En réponse à la dépêche Sortie de mplayer 0.90 rc4. Évalué à 9.
1- utilisation de code incompatible GPL.
2- interdiction de diffuser des binaires.
3- utilisation de brevets : mpeg, asf, mp3, etc... C'est libavcodec qui est principalement visé et non mplayer.
4- Réalisation de travaux dérivés sans respecter à la lettre la GPL. C-à-d sans faire un changelog précis des fichiers modifiés, pourquoi, la date, l'auteur, etc...
Le point 1 est corrigé. (voir les sources :-) ). D'ailleur la mailing Debian n'indique jamais l'utilisation de code non compatible GPL (sauf au début mais ils arrêtent vite). La mailing list parle de l'abus d'interdire la diffusion de binaire alors que des sources tiers sont sous GPL (voir point 2, c'est corrigé).
Le point 2 est corrigé (voir des liens dans ce thread). Néanmoins, la distribution sous forme de source pose moins de problème par rapport aux brevets (on ne distribue pas un lecteur mais des sources qui disent comment lire un flux mpeg, etc...). Par contre c'est un problème par rapport à un usage abusif de DMCA.
Le point 3 est effectivement problématique. Néanmoins, on peut construire mplayer sans support pour mpeg 4, asf, mp3, ac3 etc... se qui évite le problème (Mais on a un lecteur de mer..). L'autre méthode, plus brutale, est de virer les sources qui utilisent les brevets.Il faut noter que c'est un problème pour tous les programmes qui utilisent ces brevets (dont xine). Notons que debian fait dans le deux poids, deux mesures, puisqu'ils ne voient pas de problème avec les lectures de mp3. Or, la license mp3 est très claire. Il faut payer si tu récupères un lecteur mp3 d'une autre manière que part le net. Donc il faut virer les lecteurs mp3 des cd. La distribution de distribe debian sur cd n'est donc pas possible. M'enfin, j'ai lu des mails debian indiquant que les brevets ne peuvent pas être appliqués à un programme sous GPL et que donc on peut distribuer un lecteur mp3. Mais bizarrement pas un encodeur mp3 ( http://www.debian.org/devel/wnpp/unable-to-package(...) ).
Le point 4 n'est pas encore corrigé mais ne doit pas être dure à corriger. Une des possibilités est l'utilisation de libavcodec telquel, sans modification. Mais il y a des problèmes techniques actuellement (celà semble proche pour la version 3.1). Néanmoins, je trouve que les debian-intégristes poussent un peu. Il y a des tonnes de projets qui font çà. Suffit de prendre un noyau linux de n'importe quelle distribe pour ce rendre compte que ce n'est pratiquement jamais respecté et que tout le monde s'en fout complètement.
> Bon person je dois avouer que le comportement tres pueril des developpeurs de mplayer ne plaide pas pour eux
Ce n'est pas des développeurs mais un développeur (Gabucino). Et mplayer ce n'est pas un développeur.
> Au lieu de tenter de respecter la lettre et l'esprit de la licence qu'ils ont choisis EUX-MEMES pour leur logiciel
C'est le point 4 qui n'est pas respecté et c'est tout. Je pense que çà va être corrigé. La GPL ne parle jamais de brevets.
> ils preferent s'amuser a denigrer le travail des autres!
C'est vrai, c'est pas cool.
> Ensuite je trouve aberrant le fait qu'ils interdisent la distributions des bianires
Y a un point à préciser. Depuis que mplayer est 100% GPL (version 90pre1 je crois), ils ne l'interdisent plus. Enfin, il ne l'encourage pas sur leur site. mplayer estime que ce n'est pas leur boulot mais celui des distributeurs que de proposer des versions optimisées i686, athon, etc... Quoiqu'il en soit, ce débat est clos car on peut compiler avec toute les optimisations. Le choix se fait à l'exécution. Notons que çà fait depuis un moment que mplayer propose le download de rpm packagé par un tier, http://www.piorunek.pl/~dominik/linux/pkgs/mplayer/(...) , et que la mailing list de support est mplayer-users .
> Ils ont choisi une licence qui s'appelle GPL cela implique des droits mais, malheureusement pour eux, des devoirs en particulier celui de la respecter
Il respecte la GPL sauf pour le point 4. Ce point (qui n'est pas toujours respecté par d'autres projets) peut-être facilement corrigé.
> sinon ils en changent!
Seulement car il ne respecte (pas encore) le point 4. NON. Ce serait une grosse perte pour le Logiciel Libre. D'ailleur mplayer est le logiciel le plus populaire sur freshmeat.net .
Personnellement, mplayer, pour cause d'utilisation de brevets, n'a pas sa place dans debian ni dans une distribe free software comme RedHat, Mdk, etc... Idem pour les lecteurs mp3.
Même chose pour xine qui utilise les brevets mp3, mpeg, ac3, etc, etc... Et c'est là que debian pousse grave alors qu'ils appuient sur leur image de vrais et seul distribe Free Software puisque estampillé GNU. Parfois ils sont intransigeants sur les brevets, parfois ils estiment que les brevets ne s'applique pas pour du code GPL, parfois c'est parque les brevets ne sont pas reconnus dans tous les pays, parfois ils ferment simplement les yeux, etc... C'est à la tête du client, c'est fonction de la direction du vent, de l'âge du capitaine, etc... Remarques que un ou deux "pro-debian" ont eu l'intelligence de proposer de virer xine puisqu'il a les même problèmes que mplayer.
Je suis désolé mais si debian ne fait pas preuve de plus de rigueur, ils n'auront plus à donner des leçons.
[^] # Re: Corporate Server 2.1
Posté par matiasf . En réponse à la dépêche Plein de nouvelles de Mandrake. Évalué à -1.
C'est vague.
> Les diffs se situent dans les patche kernels, de gcc et de la libc (protection de pile, tous les patches de protection reso, etc...) donc ca doit pas etre dur a retrouver
Çà reste des supositions même si je pense que tu as raison. Actuellement on ne sait pratiquement rien de la CS. Quelle version de noyau, les add-ons ? Quelle version d'apache/Gnome/KDE, etc...
Si on compare à une RH AS :
kernel 2.4.9
apache 1.3
Gnome 1.4
Je ne pense pas qu'il y a de mauvaises intentions derrière cette discrétion. Néanmoins, l'absence d'un minimum de transparence fait que je déconseillerai l'utilisation de ce produit. Je rassure tout le monde, çà ne va pas avoir un gros impact sur les ventes :-)
Alors que Mandrake fasse un tout petit, un tout petit effort et mettent les sources en ligne. Çà ne diminurait pas ses ventes. Le succès de la RH AS qui coûte plus cher, le prouve. Surtout que cette CS a été partiellement financée pour des abonnements au club.
[^] # Re: Corporate Server 2.1
Posté par matiasf . En réponse à la dépêche Plein de nouvelles de Mandrake. Évalué à -1.
Mdk parle d'une distribe testé durant 12 mois. La 9.0 est sortie il y a moins de 6 mois.
> la GPL ne t obligie en rien a diffuser les sources a tout le monde si tu ne diffuses pas les binaires a tout le monde.
J'ai pas parlé de violation de GPL. Je préfère une distributeur qui fourni les sources à toute le monde que rien du tout.
Le projet kde (ou n'importe quel autre projet), peut avoir envis de voir ce qui a été fait dans la corporate server. Ben ils ne peuvent pas sauf s'il débourse 750 .
[^] # Re: Corporate Server 2.1
Posté par matiasf . En réponse à la dépêche Plein de nouvelles de Mandrake. Évalué à -2.
Par exemple, RedHat qui fournit une distribe orienté serveur concurrente de la Corporate Server de Mandrake. Les sources sont disponibles :
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/2.1AS/en/os/i386/(...)
les erratas :
ftp://updates.redhat.com/enterprise/2.1AS/en/os/SRPMS/(...)
Afin, l'EULA de la Advanced Server de RedHat est la même que la classique RedHat Linux.
Si quelqu'un me demande ce qu'il y a comme distribe, je dit :
- Mdk
- Debian
- RH
- etc...
Si on me demande une distribe orienté serveur/entreprise avec un "gros" support je ne dirait pas Mandrake si les sources ne sont pas dispos. Si Mandrake s'éloigne de l'open source, ce n'est pas de ma faute.
[^] # Re: SUSE prêt pour le desktop
Posté par matiasf . En réponse à la dépêche SUSE prêt pour le desktop. Évalué à -3.
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par matiasf . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 1.
J'avoue ma grande surprise. J'ai jamais entendu parlé d'un nautilus en c++. Je peux pas être au courant de tout. Ce qui me surprend beaucoup, c'est que Eazel était une boîte commerciale. J'ai du mal à croire d'une société commerciale, dont le but premier est de faire du pognon pour vivre, est plié face à quelque avis défavorables à l'utilisation du C++.
D'autant plus bizarre que c'est www.gnome.org qui héberge gtkmm, gnomemm, glade-- etc...
[^] # Re: SUSE prêt pour le desktop
Posté par matiasf . En réponse à la dépêche SUSE prêt pour le desktop. Évalué à 4.
Du moment qu'il y a de la concurrence, je ne vois pas de problème de payer un service.
> et la philosophie pas un mot !
Ben les boîtes commerciales informatique qui font de la philosophie, je m'en méfie. Prend MS, ils en font des tonnes de la "philosophie" :
- "grace à nos technos, l'espèce évolue vers le haut, et patati et patata..."
> "vous pouvez modifier le codes source - mais c réservé à une élite - ou le faire faire par des gens comptétants....."
C'est vrai. Prend 100 utilisateurs d'informatique. Au mieux il y en a 3 à 5 qui peuvent modifier un programme.
> les marketeux du Libre qui vont essayer de te vendre une philosophie à leur gout
Faut pas écoute les discours "philosophique" d'une boîte commerciale et se concentrer sur les faits, les licenses, etc...
Peut-être que faire du pognon est incompatible avec la philosophie du libre. Mais ce n'est pas la cas.
[^] # Re: Trollesque ??
Posté par matiasf . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
Je ne comprend pas en quoi çà résoud le problème.
# Corporate Server 2.1
Posté par matiasf . En réponse à la dépêche Plein de nouvelles de Mandrake. Évalué à 1.
Par contre, quelqu'un peut me dire où sont les sources ?
[^] # Re: Trollesque ??
Posté par matiasf . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 0.
Ce que je veux dire, c'est que c'est pas Gnome qui a entrainé Gtk+, mais ce sont les développeurs d'applications. Une application comme gnucash ou evolution est beaucoup plus exigante envers le tk que le bureau Gnome. Les developpeurs d'appli Gnome ont des besoins, ces besoins sont remontés à Gnome (voir gtk) et le team Gnome fait les modifs nécessaires. D'ailleur beaucoup de développeurs d'appli qui utilisent Gnome, développent Gnome également. Par exemple, si tu prends gconf, c'est pas un délire des développeur de Gnome. C'est un outil/librairie qui répond aux besoins des développeurs d'applis.
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par matiasf . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 0.
C'est juste. Je ne connais pas fam dans le detail. C'est pas un gros programme (140k). Il n'utilise peut-être pas beaucoup de fonctionnalités avancées du C++. Il est donc peut-être assez portable. Çà reste des supositions.
> hmmm tu t'avance trop, gcc ne marche pas partout,
Peut-être, mais là où il ne tourne pas il ne doit pas avoir de besoin de Gnome ou KDE. J'ai utilisé gcc sous HP-UX, OSF-1, DEC-UNIX 4, Solaris.
> De plus le but de kde, n'est pas d'imposer un version specifique de compilo pour compiler (ca serait du delire)
C'est pas forcément du délire. Par exemple et il y a d'autres projets qui font de même, mysql et php nécessite gcc.
> si tu veut comparer a qquechose d'equivalent a Gnome ne prend pas Qt
Le problème, est que pour développer une appli KDE il me faut Qt.
> actuellement il y a surtout des progs qui veulent cohoperer avec kde:
> xmms (le plugin en sortie art), gstreamer (le plugin arts), etc...
Pour utiliser art tu passes par un protocole... Tu ne réponds pas à la question.
> maintenant la majorite des petits prog sont en c++
La majorité j'en suis pas sure (peut-être dans les sociétés commerciale). Mais beaucoup, c'est claire.
> car pkoi s'imposer le c qd tu peut utiliser le c++
Si pour les objectifs de mon projet je peut utiliser du c++, je vais prendre c++. On peut maintenant développer des applis Gnome en C++. Par contre pour les objectifs de gnome les librairies de base, sujette à avoir un binding ne peuvent pas être écrite en c++.
> Pour les langages de script, kdevelop est le plus gros utilisateur de ceux-ci (pour la conf, etc...)
C'est des bindings KDE? Je ne crois pas.
Pour être claire. Que KDE utilise C++ et n'a pas ou peu de binding n'est pas un reproche. C'est du logiciel libre et chaqu'un fait ce qu'il veut. KDE fait le bonheur de beaucoup d'utilisateurs et développeurs et c'est sa principale qualité au-delà du choix du language.
Gnome permet d'écrite des applis en c++ via gtkmm/gnomemm. Je ne pense pas que ces solutions soit autant abouti que le couple Qt/Kde. Je comprends parfaitement, et il est logique, qu'un développeur C++ utilise Qt/Kde.
[^] # Re: Mdk pro kde !
Posté par matiasf . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 3.
J'en doute beaucoup. Pour la news sur Gnome 2.2 j'ai cherché les contributions de Mandrake. J'ai trouvé un menbre pour la gnome fondation durant un an (2000) et aucune candidature les années suivantes, de la doc, support supermount et bugfix. Il doit certainement y avoir d'autres points. J'ai aussi lu que Mandrake avait un développeur dédié Gnome.
Ce n'est absolument pas un reproche. Si Mandrake bossent ailleur et que c'est du GPL/BSD, ils sont irréprochables.
[^] # Re: Trollesque ??
Posté par matiasf . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 2.
MDI c'est pas Gnome. OK, c'est une grande gueule.
[^] # Re: Trollesque ??
Posté par matiasf . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
C'est quoi ton problème ?
L'extention ajouté par gtk+ est pourtant très "C++".
L'explication sur le + est donnée par le développeur de gimp/gtk et non par un développeur Gnome. Cette extention est définitivement un plus. Afin, les extensions gtk+ sont pour tout les programmes qui utilisent gtk+ et non pour Gnome. Le but de Gnome est de faire un bureau et offrir des fonctionnalités pour le développement d'appli (evolution, galeon, gnucash, xchat, gnomemeting, etc...). C'est principalement des extensions pour les developpeurs d'appli et non uniquement pour Gnome. D'ailleur, les widgets spécifiques gnome se trouve dans gnome-lib et non dans gtk+.
> dans ORBit (qui on peut l'avouer est la permier implementation d'ORB digne de se nom et fichtrement rapide)
Développé par RedHat dans le cadre du projet Gnome, et en C. Y a même un binding python :-)
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par matiasf . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 0.
Ben trouve moi un cas où tu as besoin de connaitre l'existence de gconf pour customizer ton environnement.
gconftools est pour fixer les valeurs par défauts aux nouveauxcomptes ou imposer des valeurs (par exemple pour un proxy). gconftools est donc pour les admins (d'ailleur il faut être root pour modifier des valeurs).
> lorsque je lance gnome
Damned, pour quelqu'un qui n'arrête pas de critiquer gnome. Mais je pense que tu veux dire "lorsque je lance des applis gnome".
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par matiasf . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 0.
Oh lala. Gnome n'est pas contre le c++. Faut arrêter avec cette légende. Ils se sont imposer la contrainte de pouvoir faire des bindings ce qui n'est pas très compatible avec le C++. C'est tout.
> au debut pas moyen d'avoir ne serai-ce une dependance c++
fam n'ajoute aucune dépendance c++ pour quelqu'un qui veut développer sous Gnome. Sinon, prouve le.
Si apache était écrit en C++, tu n'ai pas obligé de faire un navigateur en C++. Faut pas mélange librairie et protocole. fam est utilisé via un protocole. XFree peut-être réécrit en C++ que Gnome s'en battrait l'oeil. La seul chose qui compte pour les objectifs de Gnome c'est que la partie cliente soit en C. Pour corba, au début, Gnome utilisait une implémentation C++. Ce n'était pas un problème car il y a une librairie cliente était en C et que corba est un protocole.
> selon leurs dires le langage c++ etait supra mal supporte sur la majorite des os
Gcc tourne partout. Moins bien sous windows mais la cible de Gnome n'est pas Windows. Enfin, pour compiler KDE sous HP-UX par exemple, il te faut gcc ou le compilateur HP est suffisant ?
Tu oublies systématiquement les contraintes de Gnome. Gnome utilise systématiquement la LGPL pour ces librairies. Le but est d'authoriser l'écriture d'appli proprio qui utilise ces librairies (on aime, on n'aime pas mais c'est un autre histoire). Dans la même veine il doit être possible d'utiliser les compilos proprio d'HP, Sun, SGI, IBM, etc... Et il faut le reconnaitre, le support du C++ est assez inégale entre compilos. D'ailleur je ne suis pas sure qu'il y ait un compilo qui support tout de la dernière norme ANSI.
Qt est sous GPL. Il ne permet pas l'écriture de programme proprio.
Enfin, j'aimerai que tu me trouves un programme "correcte" qui utilise un binding de Qt ou KDE. Pour te donner un exemple, tous les programmes de configuration redhat utilisent le binding python (redhat-config-packages, up2date-gnome, redhat-logviewer-0.8.3-2).
Arrêtes de dire que Gnome n'aime pas le C++. Ils ont des objectifs. Si les contraintes de ces objectifs te semble incompatible avec tes goûts de programme, alors passe ton chemin.
[^] # Re: Centralisation des guides d'interface GNOME et KDE
Posté par matiasf . En réponse à la dépêche Centralisation des guides d'interface GNOME et KDE. Évalué à 2.
[^] # Re: Alternatives
Posté par matiasf . En réponse à la dépêche Nouveau Gnucash. Évalué à 4.
- "Touche pas au grisbi, salope !"
[^] # Re: Alternatives
Posté par matiasf . En réponse à la dépêche Nouveau Gnucash. Évalué à 0.
[^] # Re: Gnome 2.2 est sorti
Posté par matiasf . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 1.
C'est pas directement lié à gnome 2.2.
[^] # Re: Pour Debian, oui oui...
Posté par matiasf . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 3.
Perrier, unbreakable bootle
et non orangina.
Aller ganin, retourne devant la télé.
[^] # Re: Pour Debian, oui oui...
Posté par matiasf . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à -1.
unbreakable distrib
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par matiasf . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 4.
> je ne voit pas ce que ca change au probleme.
C'était un troll, private jock. Le projet Gnome pour ces librairies de base évite l'utilisateur de C++ car çà rend les bindings languages difficile.
Donc en général, il est considéré comme "mal" d'utiliser du c++ pour un librairie de base Gnome.
Dans le cas de fam, il n'y a aucun problème à l'utilisation de c++ puisque c'est un serveur. Pour faire une analogie, qu'Apache soit écrit en C ou C++ ne change rien pour les clients (le navigateur). C'est le protocol http qui compte.
[^] # Re: Mdk pro kde !
Posté par matiasf . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.