dans tous les cas, tu dois te retourner uniquement vers ton vendeur ! Ils vont te dire d'aller voir l'éditeur, le fabricant ... NON ! Le seul contrat que tu as signé, c'est le contrat de vente ! Il n'engage que 2 parties : l'acheteur et le vendeur, personne d'autre !
Il y a l'activation de la license de windows qui se fait auprès de Microsoft et non du vendeur...
Le CLUF spécifie bien quelles sont les parties contractantes.
Pour le reste, la DGCCRF reconnaît volontier que c'estd e la vente liée, mais tollérée pour le moment. La question est donc plus "est-ce vraiment tollérable" que "est-ce de la vente liée".
La preuve la plus flagrande que c'est de la vente liée est que l'OS et le hardware sont dissociés au niveau contractuel.
Le hardware fait l'objet d'un contrat de vente entre le constructeur et l'acheteur.
L'OS fait l'objet d'un contrat de license entre l'éditeur et l'acheteur.
Deux régimes contractuels différents, deux intelocuteurs différents pour l'acheteur: pour le hardware, l'acheteur devra s'adresser au constructeur en cas de problèmes, pour le software, c'est à l'éditeur que l'acheteur devra s'adresser.
Pou repartir dans les analogies automobiles, c'est comme si on incluait un contrat d'assurance de 5 ans chez l'assureur n°1 du marché pour tout achat d'une voiture, même si l'acheteur avait un contrat chez un autre assureur correspondant plus à ses besoins.
Posté par ragoutoutou .
En réponse au sondage AJAX.
Évalué à -1.
si le navigateur supporte le javascript et le xmlhttpRequest, ça marche, maintenant, effectivement, si ces deux éléments ne sont pas présents, il y a problème.
Ajax à toutes les sauces n'est certainement pas une bonne idée, mais pour des applications intranet, ça a une bonne valeur ajoutée.
Maintenant, c'est aux développeurs de mettre aussi en place des mécanismes permettant d'afficher les infos sans passer par ajax pour les navigateurs ne supportant pas le xmlhttprequest, donc la majorité des navigateurs texte et pour malvoyants.
Posté par ragoutoutou .
En réponse au sondage AJAX.
Évalué à 2.
si le navigateur supporte le javascript et le xmlhttpRequest, ça marche, maintenant, effectivement, si ces deux éléments ne sont pas présents, il y a problème.
Ajax à toutes les sauces n'est certainement pas une bonne idée, mais pour des applications intranet, ça a une bonne valeur ajoutée.
Maintenant, c'est aux développeurs de mettre aussi en place des mécanismes permettant d'afficher les infos sans passer par ajax pour les navigateurs ne supportant pas le xmlhttprequest, donc la majorité des navigateurs texte et pour malvoyants.
Posté par ragoutoutou .
En réponse au sondage AJAX.
Évalué à 2.
ce que tu décris, à savoir ton exemple de séparation données/présentation, c'est du xml...
et ajax est justement fait pour manipuler du xml. Avec un navigateur supportant le xsl/xslt, il est totalement possible de garder cette séparation tout en faisant une interface dynamique basée sur des principes ajax.
Ajax est moins une question de présentation qu'une question de manipulation des données, celà permet de charger un modèle de données au fur et à mesure des besoins de l'utilisateur plutôt que de lui envoyer un dump complet en une fois avec des choses dont il n'aura pas forcément besoin. Avec un système ajax, on peut donc charger les informations de base d'un modèle et puis importer morceau par morceau des données supplémentaires en fonction des besoins.
Ajax, c'est juste une technique, le résultat dépend entièrement de ce que les développeurs en font.
Posté par ragoutoutou .
En réponse au sondage AJAX.
Évalué à 3.
Marrant, en lisant ce sondage, je me suis posé la question "mais c'est quoi ajax"... quelques docs plus loin, j'étais en mesure d'ajaxifier une de mes applications PHP développée au boulot...
Bon, ben Ajax, c'est pas du vaudou, c'est pas de la magie noire, c'est en fait simple, pour ne pas dire tout con, c'est très pratique quand on a des pages composées de zones générées dynamiquement depuis une db (en l'occurence, il s'agit ici d'un inventaire de suivi d'un parc de serveurs, avec des fiches de config hardware et software assez détaillées).
Pour des applications web, c'est tout de même une technique pour avoir un chargement plus intelligent des pages contenant des zones de contenus générés dynamiquement. Un bon remplacement des frames.
On ne peut pas parler de méthode anti démocratique.
Si, on peut en parler...
le prouver est une autre paire de manches, les instances régulatrices ayant décidé de ne rien voir et donc de ne pas agir, mais la manoeuvre reste douteuse si on s'en réfère uniquement aux textes de loi.
Et si on regarde comment les scéances à l'assemblée se sont déroulées, il y a tout de même un sérieux doute qui subsiste (un article voté et adopté qui se fait re-voter pour être rejeté le lendemain par la même instance, dans une procédure d'urgence, ça fait tache)
p.ex, si c'est pour les présidentielles, il faut bien se souvenir des jolis effets de la dispertion des votes de gauche... et vu la vivacité et la cohérence actuelle de la gauche, un deuxième tour Le Pen contre Sarkozy semble relativement probable, ce qui ne présage rien de bon si celà arrivait (imaginez un Sarkozy élu avec 80% des votes au second tour... et un partage 40-60 en faveur de Sarko?)
Pour ce qui est du déficit de démocratie, il a commencé dans les institution européennes.
Facile de blâmer l'Europe, mais dans le contexte du DADVSI, le plus gros problème vient bien du gouvernement Français et non de l'Europe.
Et le déficite démocratique Européen en lui même découle du comportement des différents états constituant l'Union Européenne.
L'Europe à un problème, mais la source de ce problème est bien chez ceux qui ont fait l'Europe. Pour corriger l'Europe, il faut aussi d'abord corriger les états membres.
Hum, tu peux critiquer urpmi, mais je peux dire a propos qu'il est au point...
Je n'ai pas critiqué Urpmi, je n'en ai pas parlé...
Dans le message précédent ta "réponse" (parcequ'en fait je ne vois pas trop le rapport entre ta réponse et mon message) je faisais allusion à la différence entre gestionnaire de paquets de haut niveau et de bas niveau et de la futilité de comparer rpm à apt, rpm étant comparable à dpkg et apt étant comparable à yum ou up2date. Rien de plus.
De toutes façons, le choix d'une distribution ne se limite pas à celui de son gestionnaire de paquets.
Parce que franchement la version 4 y a aucun support du modèle objet, une gestion des assignations par adresse minable, etc...
affirmation ayant à peu près le même degré d'objectivité que ton
la RHEL contient quasiment rien (pas de php/mysql par exemple), parce que tout le contenu est "supporté" par red hat...
... ce sera quoi la prochaîne fois? "RedHat utilise encore le kernel 2.2" ?
Faut-il vraiment en arriver à raconter des bétises sur les concurrents pour valoriser Mandriva? Perso, je pense pas.
de toutes façons, apt-get et rpm ne sont pas dans la même catégorie...
rpm et dpkg sont comparables car ce sont des packages manager de bas niveau gérant l'inventaire et les liens des packages.
apt, yum et up2date sont des gestionnaires de haut niveau reposant sur une couche dpkg ou rpm (dans le cas d'apt, il peut reposer sur l'un ou l'autres).
Comparer apt et rpm, c'est comme comparer les jantes d'une voiture face aux pneus...
Le problème est que, pour utiliser commercialement le procédé de compression mp3, breveté, il te faut obtenir une licence complémentaire auprès des détenteurs du brevet.
Pas en Europe, les brevets sur le logiciel ne sont pas passés, et la comission européenne est occupée à faire machine arrière par rapport à sa position pro-brevets.
Par contre, pour les étasuniens, c'est un autre problème, et grâce à la réforme des brevets inspirée par Microsoft qui consacre le premier à déposer et non le premier à inventer, on pourra peut-être même voir des techniques de l'OGG se faire breveter par des cabinets d'avocats...
Enfin, par distribution pro, je parle de distribution supportée par de gros partenaires, comme emc, HP, IBM, Oracle,... et ne pas commencer à avoir une demi douzaine de distributions pour des tâches spécifiques (c'est d'ailleurs en grande partie à cause d'un manque de support par les sociétés comme HP que SuSE s'est fait jeter au boulot)... donc pas grand intéret de la part de l'entreprise pour laquelle je bosse pour mandriva au niveau serveurs... maintenant, si c'était dans un contexte de serveurs web, dans le cadre d'un ISP, je dis pas, Mandriva aurait sans doutes un intéret.
la RHEL contient quasiment rien (pas de php/mysql par exemple)
Faux, RHEL 4 incorpore mysql 4 et PHP 4, de plus un cd supplémentaire (en beta pour le moment) rajoute PHP5 et mysql5.
C'est vrai que dans l'ensemble, RH est plutôt pauvre par rapport à des SuSE, Debian, Ubuntu, Mandriva, mais ce n'est pas non-plus le désert.
Mais généralement, tu prends du RedHat pour avoir un environnement certifié pour telle ou telle application pro(fessionelle/priétaire), voir même pour des questions de support hardware. Si par exemple, tu installes Oracle sur Mandriva ou Debian, tu as la certitude qu'au premier problème, Oracle va te laisser tomber avec un classique "désolé, vous avez installé notre logiciel sur un OS non supporté...", et ce genre de comportements n'est pas rare...
Effectivement, c'est bien là le point où on peut attaquer ubuntu: des promesses, des promesses...
Pour la première partie, Ubuntu n'a pas le pouvoir de garantir le fait que les développeurs Ubuntu (salariés ou bénévoles) contribuent aussi à Debian, à moins de les payer pour le faire...
Pour la seconde partie, qui fait justement aux développeurs salariés, aucune promesse n'est faite...
Ce que la communauté Debian aurait sans doutes voulu voir, c'est l'inverse: un engagement sur le temps consacré à Debian par le personnel salarié plein temps.
Nous sommes deux pour un parc d'une cinquantaine de serveurs RHEL 2.1,3 et 4, donc l'automatisation est un réel besoin, et nous sommes les clients finaux d'APT puisqu'il est utilisé dans notre gestion.
De toutes façons en véritable environnement professionnel de grande entreprise, il y a souvent de nombreux éléments software à installer (même si ils ne servent à rien, mais qu'il faut installer pour des raisons politiques ou de standardisation) qui eux-mêmes peuvent casser le support d'une manière ou d'une autre, qui peuvent provoquer d'éternelles parties de ping-pong entre fournisseurs dès que quelque-chose casse...
Tant qu'une solution apt-rpm fonctionne, nous utiliserons ce format, quand le risque de voir celà ne plus marcher se pointera à l'horizon, il sera temps de migrer vers un nouveau système, mais heureusement, pour le moment, le projet apt-rpm semble encore bien actif...
pour résumer clairement, il y a deux faces au problème:
- la relation entre le développeur et Debian
- la relation entre Canonical et Debian
Dans le premier cas, il ne faut pas se leurrer, d'autres sociétés que canonical sont susceptibles d'embaucher des développeurs Debian, les rendant moins, voir pas du tout disponibles pour Debian. C'est un problème à règler entre les développeurs et les gestionnaires de Debian.
Dans le second cas, c'est un problème d'accords entre Canonical et Debian: à quoi Canonical s'est-il engagé auprès de Debian?
Canonical monopolisant les développeurs Debian?
Oui, forcément, ils cherchent des spécialistes en Debian pour faire tourner Ubuntu...
Embaucher un développeur Debian est-il un mal?
Si Debian n'a pas fait signer de contrat de non-concurrence à ses développeurs, il faut accepter que ceux-ci aillent chez la 'concurrence' ... en plus entre un boulot bénévole et un boulot payé, pas mal de développeurs vont vite faire leur choix...
Debian en manque de bonnes volontés pour reprendre le flambeau?
Non.
Non, Canonical ne leur permet juste pas de le faire en terme de temps.
Jusqu'à preuve du contraire, ils le font sur leur temps libre, c'est comme ça que fonctionnent la plupart des développeurs du logiciel libre.
Canonical ne va tout de même pas payer ses développeurs pour maintenir les paquets Debian en plus de ceux pour Ubuntu.
Qui a parlé de mener les responsables Debian en bateau ? Tu inventes.
Ben à priori, si on s'en réfère à ta version des faits, le mainteneur de python mène les responsables debian en bateau: il dit "oui, je vais le faire, je garde la responsabilité" mais ne fait pas ce pour quoi il s'est engagé... donc oui, ça s'appelle mener le monde en bateau,...
N'importe qui pourra revenir quelques commentaires plus haut et voir un paragraphe qui explique justement le rapport de cause à effet entre l'action d'Ubuntu et les conséquences sur Debian.
Faudra que tu te re-cites, je n'ai vu de ta part autre-chose que "c'est la faute de Canonical, ils embauchent des développeurs Debian... " c'est donc plutôt toi qui semble choisir la non-argumentation.
Pizza Hut fait une distribution dérivée de Debian ? Pizza Hut a pour stratégie de recruter des développeurs Debian ? Pizza Hut recrute des développeurs Debian parce qu'ils maintiennent des paquets dans Debian ?
Canonical interdit-il à ses développeurs de participer à Debian? C'est plutôt ça, la question.
La deuxième question est Canonical oblige t'il ses développeurs à mener les responsables debian en bateau?
En dépit de toutes tes envolées, il n'y a rien dans ce que tu as raconté qui prouve en véritable rapport de cause à effet.
Un peu d'honnêteté intellectuelle ne ferait pas de mal...
Et pourtant... quand, en sociologie politique, on étudie la Nation et la République, on l'étudie de façon comparative avec ce qui existe aux échelles plus petites, notamment les communautés, les associations. Les réflexions sur les procédures et instances démocratiques à l'intérieur de ces petites structures reflètent souvent les problèmes d'ensemble au niveau des États, parce qu'ils relèvent de la même construction. Serais-tu en train d'insinuer que l'ensemble des sciences politiques est un non sens ?
Non, les sciences po, c'est très utile, et c'est très louable de faire une simulation politique à grande échelle, et de manière internationnale.
Maintenant, il faut bien se rendre compte que faire cette simulation dans le cadre d'un projet informatique est un choix, un choix à assumer, de même que les dysfonctionnements liés à l'élaboration du modèle politique.
De même, si la simulation politique prend plsu de poid dans le développement de Debian que l'aspect distribution en lui-même, il est normal de voir des informaticiens sans ambitions politiques tourner les talons et aller vouir ailleurs.
Et il aurait été embauché par Pizza Hut, on aurait blâmé Pizza Hut?
Le problème est-il le fait qu'il ait accepté un emploi ou qu'il n'ait pas tenu ses engagements envers Debian?
Tu t'obstines aux comparaisons avec les entreprises, ce qui est un non-sens.
Comparer Debian avec une république est certainement un plus grand nonsens...
Pour ce qui est des procédures, c'est beau d'en avoir, c'est très bien, mais celà ne doit pas devenir un frein à la survie d'un projet. Au lieu de blâmer Canonical de tous les maux de Debian, il serait plutôt temps de se sortir les doigts du cul et d'agir pour préserver le bon fonctionnement de Debian. Cannonical n'aide certainement pas, mais il n'est pas non-plus la source du problème, juste un amplificateur.
Le fait est que plus je te lis, plus je trouve la situation ridicule.
La responsabilité première n'est pas chez la boîte qui embauche une personne, mais bien chez la personne qui n'assure pas ses autres engagements. Ce n'est pas la responsabilité de Canonical si un bénévole de Debian ne tient pas ses engagements.
Ensuite, la responsabilité revient aux chefs de projet de déterminer si une personne remplit encore ses engagements, et le cas échéant prendre les mesures ad hoc pour assurer la pérennité du projet: p-ex, envoyer un mail donnant une deadline claire au delà de laquelle la personne sera déchargée de facto de sa responsabilité, celle-ci étant redistribuée vers des volontaires plus enthousiastes.
Mais bon, à priori, comme chez Debian, tout doit faire l'objet de procédures, il faut en conclure que les gens ont trop peur de donner le moindre pouvoir à qui que ce soit. L'art de faire très compliqué quand on peut faire simple?
Problème simple ? Problème tellement simple qu'il fait l'objet de controverse dans toute association, dans la société et qu'il n'a jamais été réglé en matière d'institutions républicaines ? Le problème de l'éviction de quelqu'un d'une responsabilité qu'il a acquise est loin d'être un problème simple.
C'est un problème simple: soit on garde le mainteneur, soit on lui retire sa responsabilité. Maintenant, la décision peut être plus ou moins difficile à prendre selon la qualité de l'organisation, la définition des responsabilités dans l'entreprise.
Enfin, il faudrait un peu revenir sur terre quand il s'agit de mesurer les responsabilités, l'interchangeabilité des personnes, quand il s'agit de garder un projet communautaire à flot.
Debian est un projet communautaire, pas une république.
Euh... Tu le fais exprès ? Canonical est une entreprise avec un modèle de décision centralisée. Rien à voir avec un projet libre avec une structure démocratique. Ça n'a simplement aucun sens de comparer les deux organisations comme tu le faisais plus haut.
Au niveau efficacité, ça mérite comparaison, surtout quand on voit debian buter sur des problèmes aussi simples que quelqu'un qui ne fait pas son boulot.
Qu'on ne donne pas les pleins pouvoirs à une personne dans une démocratie, c'est normal, toutefois, il est aussi normal de donner aux gens des pouvoirs à la mesure de leurs responsabilités, quitte à ce que celà fasse l'objet d'un vote en petit commité.
Le fait que le modèle démocratique Debian soit incapable de gérer un problème aussi simple est consternant.
Et le fait que ce soit vieux le rend bien, souhaitable, efficace ou normal ? C'est de ça qu'on discute.
Le fait que ce soit ancien et fréquent en fait que c'est une chose normale et que tout projet (même non informatique) devrait pouvoir surmonter. Dans un système basé sur le bénévolat, les développeurs n'appartiennent pas à un projet ou à un autre, ils participent selon leurs disponnibilités.
Il faudrais dans ce cas leur "reprendre de force" les paquets ?
C'est si difficile de décider que puisque la personne ne tient pas ses engagements, et que d'autres sont prèts à reprendre le flambeau, on accepte de prendre le paquet venant des personnes motivées (sous réserve que la qualité y soit)?
dans les années à venir.
Debian a t'il encore tant de temps à perdre? Combien de développeurs de paquets devront encore tourner le dos avant qu'une procédure simple, rapide et efficace soit mise en place pour gérer ce genre de problèmes?
Oui. D'ailleurs, une des principales raisons pour lesquelles la Chine connaît une meilleure réussite économique que l'Inde est qu'il s'agit d'un régime autoritaire. Est-ce que la Chine est pour autant un modèle ?
Ok, d'office, dès qu'il s'agit d'avoir un peu de gestion, un peu d'autorité, c'est la dictature?
Si le projet Debian tient des élections pour désigner qui dirige, c'est pour être dirigé, le fait de laisser partir des pans importants comme Python en couille est clairement un manque de respect pour les autres personnes bossant sur le projet, et particulièrement les personnes bossant sur des éléments dépendant de Python.
Le fait que Ubuntu semble aller plus vite avec des objectifs mieux définis peut représenter un fort attrait pour les développeurs qui, du coup, ont l'impression de mieux voir où ils vont.
Ensuite, le fait que des sociétés engagent des développeurs de logiciels libres et que ceux-ci laissent du coup tomber leur sprojets libres ne date pas d'hier. Un projet de qualité libre ou non, se doit de pouvoir surmonter les abandons/départs/décès pouvant survenir dans les rangs de ses participants.
mais rendons à Shuttleworth ce qui appartient à Shuttleworth
A vue de nez, en tout cas, il a l'air de mieux savoir faire tourner sa boutique que l'organisation de Debian en tout cas... Le développeur est peut être inexcusable dans le fait qu'il prétend garder le paquet sous son contrôle, mais si la situation est telle que tu la décris, ça reste l'organisation de Debian qui se montre incapable de gérer la situation.
Faut pas confondre démocratie avec laisser aller et anarchie, il y a une responsabilité des élus face au "peuple".
[^] # Re: Vente liée car deux contrats différents...
Posté par ragoutoutou . En réponse à la dépêche N'oubliez pas l'appel à témoin de l'UFC pour les ventes forcées de logiciels !. Évalué à 3.
Il y a l'activation de la license de windows qui se fait auprès de Microsoft et non du vendeur...
Le CLUF spécifie bien quelles sont les parties contractantes.
Pour le reste, la DGCCRF reconnaît volontier que c'estd e la vente liée, mais tollérée pour le moment. La question est donc plus "est-ce vraiment tollérable" que "est-ce de la vente liée".
# Vente liée car deux contrats différents...
Posté par ragoutoutou . En réponse à la dépêche N'oubliez pas l'appel à témoin de l'UFC pour les ventes forcées de logiciels !. Évalué à 7.
Le hardware fait l'objet d'un contrat de vente entre le constructeur et l'acheteur.
L'OS fait l'objet d'un contrat de license entre l'éditeur et l'acheteur.
Deux régimes contractuels différents, deux intelocuteurs différents pour l'acheteur: pour le hardware, l'acheteur devra s'adresser au constructeur en cas de problèmes, pour le software, c'est à l'éditeur que l'acheteur devra s'adresser.
Pou repartir dans les analogies automobiles, c'est comme si on incluait un contrat d'assurance de 5 ans chez l'assureur n°1 du marché pour tout achat d'une voiture, même si l'acheteur avait un contrat chez un autre assureur correspondant plus à ses besoins.
[^] # Re: Moi j'aime Ajax
Posté par ragoutoutou . En réponse au sondage AJAX. Évalué à -1.
Ajax à toutes les sauces n'est certainement pas une bonne idée, mais pour des applications intranet, ça a une bonne valeur ajoutée.
Maintenant, c'est aux développeurs de mettre aussi en place des mécanismes permettant d'afficher les infos sans passer par ajax pour les navigateurs ne supportant pas le xmlhttprequest, donc la majorité des navigateurs texte et pour malvoyants.
[^] # Re: Moi j'aime Ajax
Posté par ragoutoutou . En réponse au sondage AJAX. Évalué à 2.
Ajax à toutes les sauces n'est certainement pas une bonne idée, mais pour des applications intranet, ça a une bonne valeur ajoutée.
Maintenant, c'est aux développeurs de mettre aussi en place des mécanismes permettant d'afficher les infos sans passer par ajax pour les navigateurs ne supportant pas le xmlhttprequest, donc la majorité des navigateurs texte et pour malvoyants.
[^] # Re: Mon avis...
Posté par ragoutoutou . En réponse au sondage AJAX. Évalué à 2.
et ajax est justement fait pour manipuler du xml. Avec un navigateur supportant le xsl/xslt, il est totalement possible de garder cette séparation tout en faisant une interface dynamique basée sur des principes ajax.
Ajax est moins une question de présentation qu'une question de manipulation des données, celà permet de charger un modèle de données au fur et à mesure des besoins de l'utilisateur plutôt que de lui envoyer un dump complet en une fois avec des choses dont il n'aura pas forcément besoin. Avec un système ajax, on peut donc charger les informations de base d'un modèle et puis importer morceau par morceau des données supplémentaires en fonction des besoins.
Ajax, c'est juste une technique, le résultat dépend entièrement de ce que les développeurs en font.
# Ajax, gros buzz, mais pratique...
Posté par ragoutoutou . En réponse au sondage AJAX. Évalué à 3.
Bon, ben Ajax, c'est pas du vaudou, c'est pas de la magie noire, c'est en fait simple, pour ne pas dire tout con, c'est très pratique quand on a des pages composées de zones générées dynamiquement depuis une db (en l'occurence, il s'agit ici d'un inventaire de suivi d'un parc de serveurs, avec des fiches de config hardware et software assez détaillées).
Pour des applications web, c'est tout de même une technique pour avoir un chargement plus intelligent des pages contenant des zones de contenus générés dynamiquement. Un bon remplacement des frames.
[^] # Re: Merci Coluche
Posté par ragoutoutou . En réponse à la dépêche DADVSI : dernières nouvelles du passage en force. Évalué à 2.
le prouver est une autre paire de manches, les instances régulatrices ayant décidé de ne rien voir et donc de ne pas agir, mais la manoeuvre reste douteuse si on s'en réfère uniquement aux textes de loi.
Et si on regarde comment les scéances à l'assemblée se sont déroulées, il y a tout de même un sérieux doute qui subsiste (un article voté et adopté qui se fait re-voter pour être rejeté le lendemain par la même instance, dans une procédure d'urgence, ça fait tache)
[^] # Re: Merci Coluche
Posté par ragoutoutou . En réponse à la dépêche DADVSI : dernières nouvelles du passage en force. Évalué à 3.
Selon le contexte, il y en a même trop...
p.ex, si c'est pour les présidentielles, il faut bien se souvenir des jolis effets de la dispertion des votes de gauche... et vu la vivacité et la cohérence actuelle de la gauche, un deuxième tour Le Pen contre Sarkozy semble relativement probable, ce qui ne présage rien de bon si celà arrivait (imaginez un Sarkozy élu avec 80% des votes au second tour... et un partage 40-60 en faveur de Sarko?)
[^] # Re: augmenter les pouvoir du parlement européen
Posté par ragoutoutou . En réponse à la dépêche DADVSI : dernières nouvelles du passage en force. Évalué à 6.
Facile de blâmer l'Europe, mais dans le contexte du DADVSI, le plus gros problème vient bien du gouvernement Français et non de l'Europe.
Et le déficite démocratique Européen en lui même découle du comportement des différents états constituant l'Union Européenne.
L'Europe à un problème, mais la source de ce problème est bien chez ceux qui ont fait l'Europe. Pour corriger l'Europe, il faut aussi d'abord corriger les états membres.
[^] # Re: passage a ubuntu
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 3.
Je n'ai pas critiqué Urpmi, je n'en ai pas parlé...
Dans le message précédent ta "réponse" (parcequ'en fait je ne vois pas trop le rapport entre ta réponse et mon message) je faisais allusion à la différence entre gestionnaire de paquets de haut niveau et de bas niveau et de la futilité de comparer rpm à apt, rpm étant comparable à dpkg et apt étant comparable à yum ou up2date. Rien de plus.
De toutes façons, le choix d'une distribution ne se limite pas à celui de son gestionnaire de paquets.
affirmation ayant à peu près le même degré d'objectivité que ton ... ce sera quoi la prochaîne fois? "RedHat utilise encore le kernel 2.2" ?
Faut-il vraiment en arriver à raconter des bétises sur les concurrents pour valoriser Mandriva? Perso, je pense pas.
[^] # Re: passage a ubuntu
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 2.
rpm et dpkg sont comparables car ce sont des packages manager de bas niveau gérant l'inventaire et les liens des packages.
apt, yum et up2date sont des gestionnaires de haut niveau reposant sur une couche dpkg ou rpm (dans le cas d'apt, il peut reposer sur l'un ou l'autres).
Comparer apt et rpm, c'est comme comparer les jantes d'une voiture face aux pneus...
[^] # Re: c'est normal: le mp3 est payant!
Posté par ragoutoutou . En réponse à la dépêche Les labels indépendants ouvrent leur plateforme. Évalué à 5.
Par contre, pour les étasuniens, c'est un autre problème, et grâce à la réforme des brevets inspirée par Microsoft qui consacre le premier à déposer et non le premier à inventer, on pourra peut-être même voir des techniques de l'OGG se faire breveter par des cabinets d'avocats...
[^] # Re: Ubuntu sur un serveur
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 3.
[^] # Re: passage a ubuntu
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 2.
Faux, RHEL 4 incorpore mysql 4 et PHP 4, de plus un cd supplémentaire (en beta pour le moment) rajoute PHP5 et mysql5.
C'est vrai que dans l'ensemble, RH est plutôt pauvre par rapport à des SuSE, Debian, Ubuntu, Mandriva, mais ce n'est pas non-plus le désert.
Mais généralement, tu prends du RedHat pour avoir un environnement certifié pour telle ou telle application pro(fessionelle/priétaire), voir même pour des questions de support hardware. Si par exemple, tu installes Oracle sur Mandriva ou Debian, tu as la certitude qu'au premier problème, Oracle va te laisser tomber avec un classique "désolé, vous avez installé notre logiciel sur un OS non supporté...", et ce genre de comportements n'est pas rare...
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 0.
Pour la première partie, Ubuntu n'a pas le pouvoir de garantir le fait que les développeurs Ubuntu (salariés ou bénévoles) contribuent aussi à Debian, à moins de les payer pour le faire...
Pour la seconde partie, qui fait justement aux développeurs salariés, aucune promesse n'est faite...
Ce que la communauté Debian aurait sans doutes voulu voir, c'est l'inverse: un engagement sur le temps consacré à Debian par le personnel salarié plein temps.
[^] # Re: passage a ubuntu
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 1.
Nous sommes deux pour un parc d'une cinquantaine de serveurs RHEL 2.1,3 et 4, donc l'automatisation est un réel besoin, et nous sommes les clients finaux d'APT puisqu'il est utilisé dans notre gestion.
De toutes façons en véritable environnement professionnel de grande entreprise, il y a souvent de nombreux éléments software à installer (même si ils ne servent à rien, mais qu'il faut installer pour des raisons politiques ou de standardisation) qui eux-mêmes peuvent casser le support d'une manière ou d'une autre, qui peuvent provoquer d'éternelles parties de ping-pong entre fournisseurs dès que quelque-chose casse...
Tant qu'une solution apt-rpm fonctionne, nous utiliserons ce format, quand le risque de voir celà ne plus marcher se pointera à l'horizon, il sera temps de migrer vers un nouveau système, mais heureusement, pour le moment, le projet apt-rpm semble encore bien actif...
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 1.
pour résumer clairement, il y a deux faces au problème:
- la relation entre le développeur et Debian
- la relation entre Canonical et Debian
Dans le premier cas, il ne faut pas se leurrer, d'autres sociétés que canonical sont susceptibles d'embaucher des développeurs Debian, les rendant moins, voir pas du tout disponibles pour Debian. C'est un problème à règler entre les développeurs et les gestionnaires de Debian.
Dans le second cas, c'est un problème d'accords entre Canonical et Debian: à quoi Canonical s'est-il engagé auprès de Debian?
Canonical monopolisant les développeurs Debian?
Oui, forcément, ils cherchent des spécialistes en Debian pour faire tourner Ubuntu...
Embaucher un développeur Debian est-il un mal?
Si Debian n'a pas fait signer de contrat de non-concurrence à ses développeurs, il faut accepter que ceux-ci aillent chez la 'concurrence' ... en plus entre un boulot bénévole et un boulot payé, pas mal de développeurs vont vite faire leur choix...
Debian en manque de bonnes volontés pour reprendre le flambeau?
Non.
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 2.
Jusqu'à preuve du contraire, ils le font sur leur temps libre, c'est comme ça que fonctionnent la plupart des développeurs du logiciel libre.
Canonical ne va tout de même pas payer ses développeurs pour maintenir les paquets Debian en plus de ceux pour Ubuntu.
Ben à priori, si on s'en réfère à ta version des faits, le mainteneur de python mène les responsables debian en bateau: il dit "oui, je vais le faire, je garde la responsabilité" mais ne fait pas ce pour quoi il s'est engagé... donc oui, ça s'appelle mener le monde en bateau,...
Faudra que tu te re-cites, je n'ai vu de ta part autre-chose que "c'est la faute de Canonical, ils embauchent des développeurs Debian... " c'est donc plutôt toi qui semble choisir la non-argumentation.
et ceux qui vont chez canonical ? ;)
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 3.
Canonical interdit-il à ses développeurs de participer à Debian? C'est plutôt ça, la question.
La deuxième question est Canonical oblige t'il ses développeurs à mener les responsables debian en bateau?
En dépit de toutes tes envolées, il n'y a rien dans ce que tu as raconté qui prouve en véritable rapport de cause à effet.
Un peu d'honnêteté intellectuelle ne ferait pas de mal...
Non, les sciences po, c'est très utile, et c'est très louable de faire une simulation politique à grande échelle, et de manière internationnale.
Maintenant, il faut bien se rendre compte que faire cette simulation dans le cadre d'un projet informatique est un choix, un choix à assumer, de même que les dysfonctionnements liés à l'élaboration du modèle politique.
De même, si la simulation politique prend plsu de poid dans le développement de Debian que l'aspect distribution en lui-même, il est normal de voir des informaticiens sans ambitions politiques tourner les talons et aller vouir ailleurs.
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 2.
Le problème est-il le fait qu'il ait accepté un emploi ou qu'il n'ait pas tenu ses engagements envers Debian?
Comparer Debian avec une république est certainement un plus grand nonsens...
Pour ce qui est des procédures, c'est beau d'en avoir, c'est très bien, mais celà ne doit pas devenir un frein à la survie d'un projet. Au lieu de blâmer Canonical de tous les maux de Debian, il serait plutôt temps de se sortir les doigts du cul et d'agir pour préserver le bon fonctionnement de Debian. Cannonical n'aide certainement pas, mais il n'est pas non-plus la source du problème, juste un amplificateur.
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à -1.
La responsabilité première n'est pas chez la boîte qui embauche une personne, mais bien chez la personne qui n'assure pas ses autres engagements. Ce n'est pas la responsabilité de Canonical si un bénévole de Debian ne tient pas ses engagements.
Ensuite, la responsabilité revient aux chefs de projet de déterminer si une personne remplit encore ses engagements, et le cas échéant prendre les mesures ad hoc pour assurer la pérennité du projet: p-ex, envoyer un mail donnant une deadline claire au delà de laquelle la personne sera déchargée de facto de sa responsabilité, celle-ci étant redistribuée vers des volontaires plus enthousiastes.
Mais bon, à priori, comme chez Debian, tout doit faire l'objet de procédures, il faut en conclure que les gens ont trop peur de donner le moindre pouvoir à qui que ce soit. L'art de faire très compliqué quand on peut faire simple?
C'est un problème simple: soit on garde le mainteneur, soit on lui retire sa responsabilité. Maintenant, la décision peut être plus ou moins difficile à prendre selon la qualité de l'organisation, la définition des responsabilités dans l'entreprise.
Enfin, il faudrait un peu revenir sur terre quand il s'agit de mesurer les responsabilités, l'interchangeabilité des personnes, quand il s'agit de garder un projet communautaire à flot.
Debian est un projet communautaire, pas une république.
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 0.
Au niveau efficacité, ça mérite comparaison, surtout quand on voit debian buter sur des problèmes aussi simples que quelqu'un qui ne fait pas son boulot.
Qu'on ne donne pas les pleins pouvoirs à une personne dans une démocratie, c'est normal, toutefois, il est aussi normal de donner aux gens des pouvoirs à la mesure de leurs responsabilités, quitte à ce que celà fasse l'objet d'un vote en petit commité.
Le fait que le modèle démocratique Debian soit incapable de gérer un problème aussi simple est consternant.
Le fait que ce soit ancien et fréquent en fait que c'est une chose normale et que tout projet (même non informatique) devrait pouvoir surmonter. Dans un système basé sur le bénévolat, les développeurs n'appartiennent pas à un projet ou à un autre, ils participent selon leurs disponnibilités.
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 0.
C'est si difficile de décider que puisque la personne ne tient pas ses engagements, et que d'autres sont prèts à reprendre le flambeau, on accepte de prendre le paquet venant des personnes motivées (sous réserve que la qualité y soit)?
Debian a t'il encore tant de temps à perdre? Combien de développeurs de paquets devront encore tourner le dos avant qu'une procédure simple, rapide et efficace soit mise en place pour gérer ce genre de problèmes?
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 0.
Ok, d'office, dès qu'il s'agit d'avoir un peu de gestion, un peu d'autorité, c'est la dictature?
Si le projet Debian tient des élections pour désigner qui dirige, c'est pour être dirigé, le fait de laisser partir des pans importants comme Python en couille est clairement un manque de respect pour les autres personnes bossant sur le projet, et particulièrement les personnes bossant sur des éléments dépendant de Python.
Le fait que Ubuntu semble aller plus vite avec des objectifs mieux définis peut représenter un fort attrait pour les développeurs qui, du coup, ont l'impression de mieux voir où ils vont.
Ensuite, le fait que des sociétés engagent des développeurs de logiciels libres et que ceux-ci laissent du coup tomber leur sprojets libres ne date pas d'hier. Un projet de qualité libre ou non, se doit de pouvoir surmonter les abandons/départs/décès pouvant survenir dans les rangs de ses participants.
[^] # Re: Non Respect
Posté par ragoutoutou . En réponse à la dépêche Ubuntu : le canard pimpant est arrivé !. Évalué à 2.
A vue de nez, en tout cas, il a l'air de mieux savoir faire tourner sa boutique que l'organisation de Debian en tout cas... Le développeur est peut être inexcusable dans le fait qu'il prétend garder le paquet sous son contrôle, mais si la situation est telle que tu la décris, ça reste l'organisation de Debian qui se montre incapable de gérer la situation.
Faut pas confondre démocratie avec laisser aller et anarchie, il y a une responsabilité des élus face au "peuple".