> mplayer n'est pas GPL. Ils n'en ont rien à branler des problèmes de licences et ne font rien pour les régler.
Je te trouve bien insultant pour des gens qui font du GPL.
Peux-tu trouver un source dans la dernière version de mplayer qui ne respecte pas la license GPL et qui est développé par le team mplayer ?
> Bon sang il faut le dire comment ?
Avec des arguments. Surtout si c'est pour insulter des gens qui font avancer le Logiciel Libre.
> > Faut pas "allumer" mplayer pour sa license.
> Si.
Non. mplayer fait du GPL. Ils sont obligés d'utiliser du code non GPL pour les codecs. Mplayer ne fait pas des codecs ! Ce n'est pas de leur faute si certains codecs ne sont pas compatibles avec la GPL. Afin, l'utilisation de mpeg 4 impose de payer un license. C'est toujours pas de leur faute.
Je trouve stupide de taper sur un projet qui fait du GPL. D'ailleur en fouillant les sources j'ai rien vu qui ne soit pas GPL ou LGPL. Ce problème est donc a confirmer. Le site web étant aussi très claire :
http://www.mplayerhq.hu/homepage/design5/info.html :
> License
> MPlayer can be distributed under the GPL v2 license.
Enfin, il utilise des librairie GPL qui les imposes donc d'être GPL.
Alors allez taper sur les développeurs de codec et laissé tranquille mplayer sur ce point.
> Donc MPlayer c'est beau c'est bien, mais si la GPL ne leur plait pas ils n'ont qu'a mettre MPlayer sour la W4r3z Public License, et tout le monde sera content.
Tu n'aime pas la GPL ?
> Ce que je ne concois pas, c'est qu'ils essaient de le faire rentrer dans la debian alors que leur projet ne respecte pas le contrat Debian.
Y quand même quelque chose de très louche. Quand tu dis "ils essaient", c'est qui "ils". Tu es sure que ce sont des développeurs de mplayer ?
Mplayer n'a jamais insister pour fournir les binaires car il y a perte d'optimisation dans ce cas forte probabilité de plantage pour les version entérieur à 90pre9 je crois. C'est pas très "convivial" pour une distribution binaire.
Lorsque je lis debien/README.debian du tar de mplayer j'ai :
> Most options are autodetected or configured during compilation thus
> users are supposed to build this package themselves.
Encore quelque chose qui indique qu'il ne font pas le forcing pour une distribution binaire de mplayer.
Faut pas "allumer" mplayer pour sa license. Ce qui est développé par l'équipe Mplayer est GPL. Par contre il utilise des librairies ou fichier qui ne sont pas GPL.
Et encore, çà commence a être de l'histoire ancienne :
http://mplayerhq.hu/DOCS/users_against_developers.html
- "MPlayer previously contained source from the OpenDivX project, which disallows binary redistribution. This code has been removed in version 0.90-pre1 and the remaining file divx_vbr.c that is derived from OpenDivX sources has been put under the GPL by its authors as of version 0.90pre9. You are now welcome to create binary packages as you see fit."
Enfin, il y a maintenant la détection du cpu à l'exécution :
- "Another impediment to binary redistribution were compiletime optimizations for CPU architecture. MPlayer now supports runtime CPU detection (specify the --enable-runtime-cpudetection option when configuring). It is disabled by default because it implies a small speed sacrifice, but it is now possible to create binaries that run on different members of the Intel CPU family."
> qu'est ce qu'ils sont <censure>!!!!
Je vais rappeler 2/3 évidences :
- C'est leur projet
- C'est gratuit et développé sur leur temps libre
- Si çà ne marche pas avec une version binaire, tu peux recompiler (par exemple en prenant les sources du paquet) et faire un rapport de bug si çà ne marche toujours pas.
Enfin, si quelqu'un fourni des binaires (une distribution par exemple) il peut faire le support de la version binaire fournie, voir remonter des rapports de bug s'ils sont confirmés en compilant sur la bécane.
A chaque version de mplayer il y a une annonce. C'est trop à mon avis. C'est actuellement des RC. Il pourrait au minimum y avoir un appel pour des tests/rapports de bugs.
On est d'accord. Je rapelais les objectifs étaient différents. Or deux projets complémentaires n'ont pas forcément des objectifs très différents. l'exemple le plus "classique", c'est GNOME et KDE. Ils sont complémentaires (l'un est C centrique l'autre C++) alors qu'ils ont des objectifs très proches.
> peut-être pour empêcher de relancer la discussion sur la complémentarité des deux organisations ?
Ces deux projets ont des objectifs différents :
DLC : promotion
freedesktop : Définition de standard pour les bureaux et assurer l'intéropérabilité entre les différents bureau.
2 -
> qui développe et adapte GNU/Linux pour le bureau.
DLC est plus là pour la promotion voir la coopération des projets que le développement.
3 -
> Son but est de bien cibler les attentes et besoins des utilisateurs en la matière.
Non. Son but est de montrer que les desktop sous linux répondent aux besoin des utilisateurs. Voir de mettre en oeuvre des moyens pour réponde aux besoins des utilisateurs.
4 -
> Ce n'est pas le premier effort de Debian pour s'adapter aux utilisateurs de bureau GNU/Linux.
Le fait de suivre DLC, ce n'est pas faire un effort pour "s'adapter aux utilisateurs de bureau GNU/Linux.".
> Le sous-projet Debian Desktop en est l'exemple.
Çà, oui, c'est un effort pour "s'adapter aux utilisateurs de bureau GNU/Linux.".
> Mais des fonctionalités comme pouvoir monter un ftp distant en système de fichier local sont assez alléchante!
C'est le boulot de programme/librairie en user mode. Comme le fait mc ou gnome-vfs. Quoiqu'il en soit, je ne vois pas pourquoi Linux ne pourrait pas faire çà.
Pourquoi vouloir "bruler" ce qu'on aime tant ? Hurd n'a rien prouvé en terme davantage. Théoriquement, c'est une jolie pièce de software. Mais les avantages concrets n'existent pas. Ah si, les drivers tourne en user mode. La belle affaire. çà tourne en user mode mais çà peut freezer ta bécane.
De tout manière, c'est souvent comme çà en free sofrware. Dès qu'un truc a beaucoup de succès, çà fait moins rebelle et on cherche autre chose.
La corporate server est sur le même marché que la RH SA. Par contre elle est nettement moins cher. Pas de chance car RH va peut-être lancer un RH SA moins cher : http://news.com.com/2100-1001-978248.html(...) :
"Red Hat's plan to release a new, lower-priced version of Advanced Server will come to fruition by the end of March, said Erik Troan, Red Hat's director of product marketing, in an interview. The new products, which Red Hat said in December likely would cost between $600 and $800, will have a smaller profit margin but will let Red Hat expand to run on almost three times the number of servers, Thompson said. "
Sur le marché des concurrents d'Unix et MS, basé sur GNU/Linux, ils sont concurrents. Si l'un perd des part sur ce marché, l'autre gagne. Mais en même temps c'est des concurrents qui s'entraide. Le travail de RedHat profit à Mandrake et vice versa.
Franchement, c'est un système non maintenu. Si je fais "Get summary reports" j'obtient 206 bugs ! Tous produits Mdk confondus !
De plus, comment je fais pour rechercher les bugs de la dernière beta ?
Ils devraient prendre exemple sur RedHat : http://bugzilla.redhat.com/(...)
Pour chercher les bugs de la dernière beta, c'est facile : Product "RedHat public beta", Version "phoebe". Et j'obtiens 424 bugs. Soit deux fois plus que touts les produits Mandrake ! Enfin, pour ceux qui çà interressent, il y a plein de bugs "confidentiel". En fait, tout les bugs assignés ont un rapport de bug pour RedHat qui est inaccéssible pour les autres. Exemple : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=53866(...)
Recherché 82777 dans la page :
You are not authorized to access bug #82777.
Petit paquet, gros paquet, là est la question .
Bof...
Les gros paquets ? ni pour ni contre bien au contraire.
C'est pas la taille qui compte mais les dépendances.
Comme dit quelqu'un dont j'ai oublié le nom ce qui compte c'est de faire "the right thing". Faire ce qui convient. gnome-lib peut-être utilisé sans gnome-core alors pourquoi regrouper les deux ? glib peut-être utilisé sans gtk+ et est même de plus en plus utilisé pour des programmes sans interface graphique. Alors pourquoi imposer l'installation de Gtk+ pour n'utiliser que la partie glib. libxml (anciennement gnome-xml) est maintenant aussi utilisé par docbook-dtds. Pourquoi pour utiliser docbook, je devrais installer gnome ? libxml est aussi utilisé par kdebase. Tu serais heureux d'installer Gnome pour utiliser KDE ? De même, pango ne nécessite que glib. Peut-être qu'un jour KDE va utiliser pango. Si un jour tu as besoin pour x raisons d'installer deux fois la même librairie (par exemple pango 1.0 et pango 1.1) t'es pas obligé de mettre en doublon tout un tas de truc qui ne sert à rien.
Le fait de bien découpé un projet en librairies indépendantes facilite la réutilisation par d'autre projets et structure le projet. Si la librairie est réutilisée, elle ne devient pas une librairie spécifique Gnome par exemple, mais un librairie spécialisée dans son domaine où Gnome pioche dedans comme d'autres projets. Ainsi apprendre l'utilisation de libxml, glib ou pango n'est pas seulement un plus pour développer des applis Gnome, mais pour tout type d'applis qui ont besoin de ces fonctionnalités. La réutilisation par d'autres projets de ta librairie l'améliore car tu as le feedback de plein de développeurs.
KDE en regroupant tout, limite la réutilisation par d'autres projets. Ils créent des dépendances qui n'existe pas et donne une impression de "c'est tout ou rien".
> petits paquets:
> - une gestion lourde des dependances
C'est un faux problème. Les dépendances sont fixées une fois et c'est tout. Ce qui pose problème c'est lors des changements de librairie (style gtk qui forme un tout puis est splité en glib, gdk, gtk).
> - un travail plus lourd pour les empaqueteur du fait de la gestion des dependances entre plein de paquets
partiellement faux. Par exemple rpm c'est déterminer les dépendances entre librairies automatiquement.
> - un processus de recherche des bugs plus complexes
C'est clairement faux. Si tu as un programme qui ne marque plus suite à la mise à jour de plusieurs librairies, tu peux restaurer les anciennes librairies une par une pour trouver la fautive.
> oui mais j'ai le paquet X en v3.1 et Y en 0.4 avec Z en 0.2, est-ce que j'upgrage X pour faire marcher lambda ?
C'est le coût de la souplesse. Si j'installe gnucash 1.8 et qui me faut passer de libgal 0.18 à 0.19, je suis bien content de ne pas être obligé de mettre 10 autres librairies à jours qui peuvent compremettre le bon fonctionnement des programmes déjà installés.
> - une mise a jour beaucoup plus complexe, toujours a cause des dependances.
Y a des programmes pour çà.
> gros paquets:
> - une gestion de dependance hyper simple
Si tu gère plus les dépendances, c'est que les développeurs gère les dépendances... Car je crois pas qu'un développeur KDE qui bosse sur une partie spécifique peut être toujours synchrone avec le reste du projet. Déjà que pour des projets pas très gros il est fréquent de créer des branches spécifiques, je pense qu'il en est de même pour KDE.
iso9660 n'est pas un système de fichier qui permet l'écriture. Sinon le programme mkisofs n'est d'aucune utilité. On peut seulement créer un système de fichier iso9660 avec les données. Mais on ne peut pas le modifier (je crois par contre, que l'on peut ajouter des donnés à la fin du système de fichier).
Moi je disais que KDE serais pardant s'il était viré de RedHat. C'est tout.
> pour faire ce qu'ils ont fait ils ont fait ca comme des porcs
Y a comme un goût. C'est,... Ah oui. Un troll.
> un petit peu plus que 0 personnes sur le projet kde non?
Ben si ils sont 0 personne, ils ne peuvent pas nuire à kde. De toute manière, dès qu'ils bossent sur KDE on assiste à un lynchage public. Franchement, je comprends que maintenant ils aient encore moins envie d'intervenir.
Faux quand même noter que RedHat a au moins autant (surement plus) modifié Gnome pour leur besoin que Kde. C'est évidant puisqu'ils ont plusieurs développeur dédié Gnome. Cette initiative est dix fois plus respectée (et je ne dis pas apprécié!) chez les utilisateurs de Gnome que Kde. Franchement, certains utilisateurs de Kde donne une mauvaise image du projet KDE. Le projet KDE ne mérite pas çà.
C'est comme pour l'annonce de Open-HCI. Globalement, les utilisateurs de GNOME trouvent çà bien mais certains, CERTAINS, utilisateurs de KDE ne veulent pas de coopération.
Gnome : http://www.gnomedesktop.org/article.php?sid=908&mode=thread(...)
KDE : http://dot.kde.org/1044312611/(...)
Cet esprit est malsain. Heureusement ce n'est qu'une minorité.
> Et pour exemple kde n'est pas dans de base installe
Çà c'est un problème avec ton admin. Demande lui d'installer KDE ou de changer de distribution. Il existe des tonnes de distributions basées sur RedHat, toute aussi gratuite et qui prévilégie KDE.
C'est pas de la faute à RedHat si votre admin choisi RedHat et n'installe pas KDE.
Faudrait voir à arrêter ce bordel autour de RedHat.
Existe-il des plaintes d'utilisateurs de Gnome qui gueulent car KDE est prévilégié dans Suse, Xandros, Lycoris, etc... Non.
> veulent-ils le rendre complètement monolithique ou conserver la possibilité du choix?
Ils veulent laisser le chois.
De http://www.gnome.org/start/2.2/notes/rnwm.html(...) :
> At the same time, all interaction between the window manager and the desktop is done via documented standards (see the section called Standards Compliance), so you can substitute the window manager of your choice from a long list of available options: Sawfish, fvwm2, icewm, Waimea, Openbox, are just some of them.
Je suis pas un spécialiste compta.
Gnucash depuis peu de temps peu utiliser PostgreSQL pour le stockage des données. Çà permet aussi d'avoir un solution multi-utilisateur. J'ai testé dans la version 1.7 mais c'est pas encore au point.
Je pense qu'il est trop tôt pour remplacer ciel par gnucash. Enfin, Ciel doit aussi faire des trucs comme les fiches de paie etc... qui sont très spécifique par pay et surement pas implémenté dans gnucash.
Les 712 bugs inclus les problèmes de développeurs comme "mauvaise détection de gcc", "definition de bidule dans titi.h alors quelle devrait être dans toto.h", etc...
D'où tu sorts ce chiffre de 8000 ?
D'où tu sorts le chiffre de 4000 pour KDE ?
Des chiffres comme çà ne veulent rien dire. Ils dépendent principalement de :
- la maintenance de la base de bug (recherche de doublon, confirmation des bugs etc...).
- l'utilisation de la base de bug
- bug spécifique à un plate-forme
Il est claire qu'un bugzilla peu utilisé est beaucoup plus flateur...
> plutot que de me precipiter sur une version bugguèe.
Tellement buggué que RedHat et Mandrake (et surement d'autre) vont se précipité de mettre Gnome 2.2 dans leur prochaine distribe. Une opération suicide ?
La variable d'environnement doit être défini avant de lancer gnome-session. Donc par gdm ou un équivalent. Donc lorsque tu te logue regarde s'il n'y a pas une option pour changer de locale.
Si tu lances depuis une console suffit de faire un :
$ export LANG=fr_FR
ou
$ export LANG=fr_FR.UTF-8
Sur RH (et donc surement Mdk) il y a le fichier /etc/sysconfig/i18n qui défini la langue par défaut lorsqu'on se logue.
> Par contre, pas moyen de trouver le packages de localisation en français de gnome 2.2.
Gnome ne marche pas comme KDE. Chaque projet a sa traduction. Lorsque tu récupères gnome-lib par exemple tu as les traductions de gnome-lib.
[^] # Re: mplayer vs Debian
Posté par notrya2 . En réponse à la dépêche Sortie de mplayer 0.90 rc4. Évalué à 2.
[^] # Re: mplayer vs Debian
Posté par notrya2 . En réponse à la dépêche Sortie de mplayer 0.90 rc4. Évalué à 4.
[^] # Re: mplayer vs Debian
Posté par notrya2 . En réponse à la dépêche Sortie de mplayer 0.90 rc4. Évalué à 6.
[^] # Re: mplayer vs Debian
Posté par notrya2 . En réponse à la dépêche Sortie de mplayer 0.90 rc4. Évalué à 3.
[^] # Re: mplayer vs Debian
Posté par notrya2 . En réponse à la dépêche Sortie de mplayer 0.90 rc4. Évalué à 7.
[^] # Re: mplayer vs Debian
Posté par notrya2 . En réponse à la dépêche Sortie de mplayer 0.90 rc4. Évalué à 2.
# Peut-être un peu trop ?
Posté par notrya2 . En réponse à la dépêche Sortie de mplayer 0.90 rc4. Évalué à 6.
Mais bon, mplayer : "çà arrache grave".
[^] # Re: Deja vu!
Posté par notrya2 . En réponse à la dépêche Debian co-fondateur du Desktop Linux Consortium. Évalué à 0.
[^] # Re: Deja vu!
Posté par notrya2 . En réponse à la dépêche Debian co-fondateur du Desktop Linux Consortium. Évalué à 1.
Avant, il n'y en avait pas.
> peut-être pour empêcher de relancer la discussion sur la complémentarité des deux organisations ?
Ces deux projets ont des objectifs différents :
DLC : promotion
freedesktop : Définition de standard pour les bureaux et assurer l'intéropérabilité entre les différents bureau.
# Limite.
Posté par notrya2 . En réponse à la dépêche Debian co-fondateur du Desktop Linux Consortium. Évalué à 10.
1 - c'est du déjà dit http://linuxfr.org/2003/02/05/11267.html(...)
2 -
> qui développe et adapte GNU/Linux pour le bureau.
DLC est plus là pour la promotion voir la coopération des projets que le développement.
3 -
> Son but est de bien cibler les attentes et besoins des utilisateurs en la matière.
Non. Son but est de montrer que les desktop sous linux répondent aux besoin des utilisateurs. Voir de mettre en oeuvre des moyens pour réponde aux besoins des utilisateurs.
4 -
> Ce n'est pas le premier effort de Debian pour s'adapter aux utilisateurs de bureau GNU/Linux.
Le fait de suivre DLC, ce n'est pas faire un effort pour "s'adapter aux utilisateurs de bureau GNU/Linux.".
> Le sous-projet Debian Desktop en est l'exemple.
Çà, oui, c'est un effort pour "s'adapter aux utilisateurs de bureau GNU/Linux.".
[^] # Re: Linux,
Posté par notrya2 . En réponse à la dépêche Linux, "successeur logique de AIX", selon IBM. Évalué à 2.
C'est le boulot de programme/librairie en user mode. Comme le fait mc ou gnome-vfs. Quoiqu'il en soit, je ne vois pas pourquoi Linux ne pourrait pas faire çà.
[^] # Re: Linux, HURD
Posté par notrya2 . En réponse à la dépêche Linux, "successeur logique de AIX", selon IBM. Évalué à 3.
De tout manière, c'est souvent comme çà en free sofrware. Dès qu'un truc a beaucoup de succès, çà fait moins rebelle et on cherche autre chose.
[^] # Re: Pas de chance.
Posté par notrya2 . En réponse à la dépêche Plein de nouvelles de Mandrake. Évalué à 1.
http://news.com.com/2100-1001-983546.html(...)
Les articles disent a peu près la même chose.
# Pas de chance.
Posté par notrya2 . En réponse à la dépêche Plein de nouvelles de Mandrake. Évalué à 2.
http://news.com.com/2100-1001-978248.html(...) :
"Red Hat's plan to release a new, lower-priced version of Advanced Server will come to fruition by the end of March, said Erik Troan, Red Hat's director of product marketing, in an interview. The new products, which Red Hat said in December likely would cost between $600 and $800, will have a smaller profit margin but will let Red Hat expand to run on almost three times the number of servers, Thompson said. "
[^] # Re: Plein de nouvelles de Mandrake
Posté par notrya2 . En réponse à la dépêche Plein de nouvelles de Mandrake. Évalué à 4.
[^] # Re: Plein de nouvelles de Mandrake
Posté par notrya2 . En réponse à la dépêche Plein de nouvelles de Mandrake. Évalué à 9.
https://qa.mandrakesoft.com/(...)
Franchement, c'est un système non maintenu. Si je fais "Get summary reports" j'obtient 206 bugs ! Tous produits Mdk confondus !
De plus, comment je fais pour rechercher les bugs de la dernière beta ?
Ils devraient prendre exemple sur RedHat :
http://bugzilla.redhat.com/(...)
Pour chercher les bugs de la dernière beta, c'est facile : Product "RedHat public beta", Version "phoebe". Et j'obtiens 424 bugs. Soit deux fois plus que touts les produits Mandrake ! Enfin, pour ceux qui çà interressent, il y a plein de bugs "confidentiel". En fait, tout les bugs assignés ont un rapport de bug pour RedHat qui est inaccéssible pour les autres. Exemple :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=53866(...)
Recherché 82777 dans la page :
You are not authorized to access bug #82777.
Alors, un petit effort M. Mandrake. Copiez le système de RedHat. D'ailleur des sources sont dispos (license MPL) en page principal ou directement ici :
http://bugzilla.redhat.com/download/rh-bugzilla-pg-LATEST.tar.gz(...)
[^] # Re: Gnome 2.2 est sorti
Posté par notrya2 . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 6.
Bof...
Les gros paquets ? ni pour ni contre bien au contraire.
C'est pas la taille qui compte mais les dépendances.
Comme dit quelqu'un dont j'ai oublié le nom ce qui compte c'est de faire "the right thing". Faire ce qui convient. gnome-lib peut-être utilisé sans gnome-core alors pourquoi regrouper les deux ? glib peut-être utilisé sans gtk+ et est même de plus en plus utilisé pour des programmes sans interface graphique. Alors pourquoi imposer l'installation de Gtk+ pour n'utiliser que la partie glib. libxml (anciennement gnome-xml) est maintenant aussi utilisé par docbook-dtds. Pourquoi pour utiliser docbook, je devrais installer gnome ? libxml est aussi utilisé par kdebase. Tu serais heureux d'installer Gnome pour utiliser KDE ? De même, pango ne nécessite que glib. Peut-être qu'un jour KDE va utiliser pango. Si un jour tu as besoin pour x raisons d'installer deux fois la même librairie (par exemple pango 1.0 et pango 1.1) t'es pas obligé de mettre en doublon tout un tas de truc qui ne sert à rien.
Le fait de bien découpé un projet en librairies indépendantes facilite la réutilisation par d'autre projets et structure le projet. Si la librairie est réutilisée, elle ne devient pas une librairie spécifique Gnome par exemple, mais un librairie spécialisée dans son domaine où Gnome pioche dedans comme d'autres projets. Ainsi apprendre l'utilisation de libxml, glib ou pango n'est pas seulement un plus pour développer des applis Gnome, mais pour tout type d'applis qui ont besoin de ces fonctionnalités. La réutilisation par d'autres projets de ta librairie l'améliore car tu as le feedback de plein de développeurs.
KDE en regroupant tout, limite la réutilisation par d'autres projets. Ils créent des dépendances qui n'existe pas et donne une impression de "c'est tout ou rien".
> petits paquets:
> - une gestion lourde des dependances
C'est un faux problème. Les dépendances sont fixées une fois et c'est tout. Ce qui pose problème c'est lors des changements de librairie (style gtk qui forme un tout puis est splité en glib, gdk, gtk).
> - un travail plus lourd pour les empaqueteur du fait de la gestion des dependances entre plein de paquets
partiellement faux. Par exemple rpm c'est déterminer les dépendances entre librairies automatiquement.
> - un processus de recherche des bugs plus complexes
C'est clairement faux. Si tu as un programme qui ne marque plus suite à la mise à jour de plusieurs librairies, tu peux restaurer les anciennes librairies une par une pour trouver la fautive.
> oui mais j'ai le paquet X en v3.1 et Y en 0.4 avec Z en 0.2, est-ce que j'upgrage X pour faire marcher lambda ?
C'est le coût de la souplesse. Si j'installe gnucash 1.8 et qui me faut passer de libgal 0.18 à 0.19, je suis bien content de ne pas être obligé de mettre 10 autres librairies à jours qui peuvent compremettre le bon fonctionnement des programmes déjà installés.
> - une mise a jour beaucoup plus complexe, toujours a cause des dependances.
Y a des programmes pour çà.
> gros paquets:
> - une gestion de dependance hyper simple
Si tu gère plus les dépendances, c'est que les développeurs gère les dépendances... Car je crois pas qu'un développeur KDE qui bosse sur une partie spécifique peut être toujours synchrone avec le reste du projet. Déjà que pour des projets pas très gros il est fréquent de créer des branches spécifiques, je pense qu'il en est de même pour KDE.
[^] # Re: Test de la Knoppix 3.1
Posté par notrya2 . En réponse à la dépêche Test de la Knoppix 3.1. Évalué à 4.
[^] # Re: Test de la Knoppix 3.1
Posté par notrya2 . En réponse à la dépêche Test de la Knoppix 3.1. Évalué à 1.
> pour faire ce qu'ils ont fait ils ont fait ca comme des porcs
Y a comme un goût. C'est,... Ah oui. Un troll.
> un petit peu plus que 0 personnes sur le projet kde non?
Ben si ils sont 0 personne, ils ne peuvent pas nuire à kde. De toute manière, dès qu'ils bossent sur KDE on assiste à un lynchage public. Franchement, je comprends que maintenant ils aient encore moins envie d'intervenir.
Faux quand même noter que RedHat a au moins autant (surement plus) modifié Gnome pour leur besoin que Kde. C'est évidant puisqu'ils ont plusieurs développeur dédié Gnome. Cette initiative est dix fois plus respectée (et je ne dis pas apprécié!) chez les utilisateurs de Gnome que Kde. Franchement, certains utilisateurs de Kde donne une mauvaise image du projet KDE. Le projet KDE ne mérite pas çà.
C'est comme pour l'annonce de Open-HCI. Globalement, les utilisateurs de GNOME trouvent çà bien mais certains, CERTAINS, utilisateurs de KDE ne veulent pas de coopération.
Gnome : http://www.gnomedesktop.org/article.php?sid=908&mode=thread(...)
KDE : http://dot.kde.org/1044312611/(...)
Cet esprit est malsain. Heureusement ce n'est qu'une minorité.
> Et pour exemple kde n'est pas dans de base installe
Çà c'est un problème avec ton admin. Demande lui d'installer KDE ou de changer de distribution. Il existe des tonnes de distributions basées sur RedHat, toute aussi gratuite et qui prévilégie KDE.
C'est pas de la faute à RedHat si votre admin choisi RedHat et n'installe pas KDE.
Faudrait voir à arrêter ce bordel autour de RedHat.
Existe-il des plaintes d'utilisateurs de Gnome qui gueulent car KDE est prévilégié dans Suse, Xandros, Lycoris, etc... Non.
Inspires toi de çà :
http://dot.kde.org/1044312611/1044364582/1044368376/(...)
[^] # Re: Metacity officiellement le WM de gnome
Posté par notrya2 . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 4.
Ils veulent laisser le chois.
De http://www.gnome.org/start/2.2/notes/rnwm.html(...) :
> At the same time, all interaction between the window manager and the desktop is done via documented standards (see the section called Standards Compliance), so you can substitute the window manager of your choice from a long list of available options: Sawfish, fvwm2, icewm, Waimea, Openbox, are just some of them.
[^] # Re: Compta d'entreprise ?
Posté par notrya2 . En réponse à la dépêche Nouveau Gnucash. Évalué à 5.
Gnucash depuis peu de temps peu utiliser PostgreSQL pour le stockage des données. Çà permet aussi d'avoir un solution multi-utilisateur. J'ai testé dans la version 1.7 mais c'est pas encore au point.
Je pense qu'il est trop tôt pour remplacer ciel par gnucash. Enfin, Ciel doit aussi faire des trucs comme les fiches de paie etc... qui sont très spécifique par pay et surement pas implémenté dans gnucash.
[^] # Re: Gnome 2.2 est sorti
Posté par notrya2 . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 5.
[^] # Re: Gnome 2.2 est sorti
Posté par notrya2 . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 5.
> plus de 8000 bugs connus
Selon çà :
http://bugzilla.gnome.org/gnome-21-report.html(...)
C'est 712 dont 70 ont déjà un patch.
D'où tu sorts ce chiffre de 8000 ?
D'où tu sorts le chiffre de 4000 pour KDE ?
Des chiffres comme çà ne veulent rien dire. Ils dépendent principalement de :
- la maintenance de la base de bug (recherche de doublon, confirmation des bugs etc...).
- l'utilisation de la base de bug
- bug spécifique à un plate-forme
Il est claire qu'un bugzilla peu utilisé est beaucoup plus flateur...
Sinon pour les bugs les plus embêtants, c'est ici :
http://www.gnome.org/start/2.2/notes/rnknownissues.html(...)
> plutot que de me precipiter sur une version bugguèe.
Tellement buggué que RedHat et Mandrake (et surement d'autre) vont se précipité de mettre Gnome 2.2 dans leur prochaine distribe. Une opération suicide ?
[^] # Re: en français ?
Posté par notrya2 . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 6.
Si tu lances depuis une console suffit de faire un :
$ export LANG=fr_FR
ou
$ export LANG=fr_FR.UTF-8
Sur RH (et donc surement Mdk) il y a le fichier /etc/sysconfig/i18n qui défini la langue par défaut lorsqu'on se logue.
[^] # Re: en français ?
Posté par notrya2 . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 6.
Gnome ne marche pas comme KDE. Chaque projet a sa traduction. Lorsque tu récupères gnome-lib par exemple tu as les traductions de gnome-lib.