genesis83 a écrit 78 commentaires

incompréhensible aussi : quel est l'objet ? pourquoi faire un journal ?

>Et ca perso, j'ai jamais vu avec dpkg alors que rpm ...

Alors que rpm quoi ? Tu as eu un problème avec une rpm tu en déduis une généralité comme quoi le système rpm ne serait pas fiable...

Et du côté de Debian ça n'a pas l'air irréprochable non plus, Mepis y consacre une entrée wiki : http://www.mepis.org/docs/en/index.php/Repairing_apt-get_dat(...)

>Donc en fait, ce que tu dis, c'est pas la fautes aux outils, ce sont les packageurs Redhat/Suse qui sont des blaireaux ?

Pourquoi tout de suite blaireaux... Il peut y avoir un choix de dépendance discutable ou erroné sur un paquet.

A t'écouter les paquets Debian seraient tous nickels et avec des choix de dépendance parfaits. On sait très bien que ce n'est pas le cas, l'énorme bourde sur openssl étant là pour le rappeler...

Allez un dernier Google Fight apt vs yum :)

http://www.googlefight.com/index.php?lang=fr_FR&word1=yu(...)

Déja tu passe de rpm à zypper/yum. Je connais mal zypper, donc je ne vais pas rentrer dans le débat, par contre yum et urpmi fonctionnent très bien.
L'exemple que tu donnes sur yum montre bien qu'il gère bien les dépendances. Peut-être sont-elles inappropriées mais dans ce cas apt ne fera pas mieux, nul besoin d'avoir un sourire en coin...

Quant à Google Fight, on lui fait dire ce qu'on veut...

http://www.googlefight.com/index.php?lang=fr_FR&word1=rp(...)

"Gestion des paquets à des années lumières du bordel rpm: Au boulot, j'ai des utilisateurs sous Fedora/OpenSuse, même avec les dépots officiels, ils arrivent à foutre en vrac leurs distribs..."

A foutre en vrac c'est à dire ?
Tu peux mettre HS une Debian en quelques secondes également en forçant la désinstallation de paquets vitaux. J'ai déja eu des problèmes d'installation de paquets sous Debian aussi, rien n'est parfait.

Tu peux jeter un coup d'oeil aux forums d'aide des distros basée sur rpm, tu trouveras très peu de problèmes qui y sont liés.

C'est comme pour EADS ou récemment U2, les Pays-Bas ont l'air d'être très attractifs pour les sièges sociaux. Par contre l'activité réelle n'y est pas forcément très développée.

"Pourquoi ne pas avoir créer la société dans un pays capitaliste, comme l'Irlande, la RFA ou la Hollande ?"

Y'a des Microsoft, Apple ou Google là-bas ? Première nouvelle...

Je pense qu'au niveau européen la France ne doit pas être si mal placée que ça...

Mais est-ce que ça affecte un UTILISATEUR réel de Fedora ? La question est là.
Il y a déja plus de bogues que de bras alors chercher à corriger ceux qui touchent la distribution silencieusement... d'autant plus qu'il y a des chances qu'ils soient corrigés upstream avant qu'un utilisateur ne soit affecté.

Sauf que la méthode utilisée est assez détestable et irrespectueuse ...

Qu'il cherche à faire corriger le bogue par "ceux qui savent" est une chose, qu'il détourne les outils d'une autre distribution à profit d'Ubuntu en est une autre.
Le bugzilla de Fedora est là pour rapporter et traiter les bogues rencontrés par les utilisateurs de Fedora.

Ca dépend où tu mets le curseur c'est vrai, mais voir les choses dériver vers un SE libre au service d'applications propriétaires...
On pourrait très bien en arriver à se dire : au point où j'en suis, autant aller jusqu'au bout des choses.

Justement jusqu'à présent le compromis adopté par beaucoup c'est l'utilisation du non libre uniquement lorsqu'il est indispensable. Ici on franchit quand même la ligne.

Tu as openmotif et truecrypt par exemple. Même si en général on essaie d'éviter de les packager si c'est possible, il suffit de faire un tour dans les dépôts non-free ou non officiels genre plf pour en trouver un nombre non négligeable.

Tout a fait. On peut aussi citer pulseaudio (quoiqu'on en pense par ailleurs) : développement assuré principalement par Redhat mais exécuté de façon à être multi-plateforme et neutre.

Ton exemple est ridicule. Le RAD n'est pas un centre d'intérêt spécifique.

Je ne savais pas que les utilisateurs d'Ubuntu avaient des besoins spécifiques qu'on ne retrouvait pas chez les utilisateurs d'autres distributions...

Super l'évolution, l'upstream neutre est mort. Je ne parle même pas de la duplication du travail...

Non la critique est bien sur la réalisation, rien d'autre. On réalise désormais une application ubuntu.
Si tu souhaites pouvoir l'utiliser hors d'ubuntu, tu dois patcher/forker.

DistUtilsExtra.auto.setup(name='quickly',
version="'%s'" % VERSION,
description='build new Ubuntu apps quickly',
long_description='Quickly enables for prospective programmer a way to easily build new ' \
'apps for Ubuntu based on templates and other systems for helping them ' \
'write their code in a guided manner. This also includes packaging and ' \
'deploying code.',
url='https://launchpad.net/quickly',
license="GPL v3",
author='Quickly Developer Team',
author_email='quickly@lists.launchpad.net',
cmdclass={'install': InstallAndUpdateDataDirectory}
)

Jusqu'à être Canonical/Ubuntu only. Le côté upstream devient accessoire, on a la bonté d'uploader un tarball de sources... navrant.

Jusqu'à quand les utilisateurs vont accepter d'utiliser un système d'exploitation qui n'est au final qu'un vaste support publicitaire au profit de la boîte qui l'a créé ? Qui plus est où va être la limite, notamment vis-à-vis de la protection des données personnelles ?

C'est le département marketing de Canonical qui essaie de faire passer un message comme quoi Canonical n'est qu'un simple contributeur à Ubuntu (voir le journal posté il y a peu du responsable serveur chez Canonical).
C'est honteusement hypocrite à commencer parcequ'Ubuntu est une marque déposée par Canonical et lui sert de support, mais certains semblent tomber dans le panneau.

Tout à fait d'accord, j'aillais pondre le même genre de billet.

« Canonical n'est pas le propriétaire d'Ubuntu » précise Nicolas Barcet.
Ubuntu and Canonical are registered trademarks of Canonical Ltd.

A un moment donné il faut arrêter l'hypocrisie...

En même temps si tu regardes la liste des 200 patchs, la majorité n'est pas spécifique à une architecture moins courante, arm c'est 6 patchs simplement.

Tu pars du principe que les développeurs Debian sont forcément plus compétents que les développeurs upstream, et que quand il y a désaccord ce sont ces derniers qui sont forcément dans leur tord...

Et j'ai l'impression que seule Debian a un problème avec glibc.

200 patchs c'est énorme ?

Combien y en a t-il pour leurs noyaux par exemple ? Plus de 300 pour la branche stable/testing et déja plus de 100 pour la branche instable.

Combien de ces patchs sont debian-only ? Un exemple sur lequel je suis tombé en jetant un coup d'oeil sur logram : les packagers Debian de phonon le patche pour créer un "magic header" phonon sorti de nul part et qui n'existe absolument pas upstream. Le résultat c'est que logram ne compile pas sur autre chose que Debian et dérivées à moins de patcher...

Qui est totalitaire ? J'ai un peu l'impression que si tu ne suis pas les désideratas et les points de vue des développeurs Debian, on te met cette étiquette.

Tu peux préciser ce que tu entends par "n'était pas en faveur de Canonical" ?