🚲 Tanguy Ortolo a écrit 12224 commentaires

Non, parce que btrfs c'est sous GPLv2, ce qui est déjà plus sûr. Mais effectivement, le fait que ce soit fait par Oracle n'est pas du tout rassurant.

(normal c'est Apache, un bon repaire de fanas de Java, ça)

Pour plein de raisons.

• C'est propriétaire donc ça n'a pas sa place dans un système libre. Ça a été partiellement libéré par Sun, mais Java fait évidemment machine arrière.
• Plus grave encore, il est tout simplement interdit de redistribuer le Java d'Oracle. C'était autorisé par une licence spéciale, qui a été retirée l'an dernier.
• C'est lourd et contraignant en terme d'installation, probablement parce que ça a été conçu sans penser à l'intégration, en tout cas comparé à des systèmes concurrents comme Python.
• C'est fait par Oracle qui sont des connards prêts à coller un procès à n'importe qui dès qu'ils trouvent une piste pour le faire : « Là, eux là-bas, Google, ils utilisent le mot “Java”, pas bien ! »

Bref, pour toutes ces raisons, mais à mon avis surtout pour les trois premières, ce n'est pas demain la veille du jour où le solveur de dépendances de Debian sera codé en Java par exemple. D'une façon générale, beaucoup de gens, lorsqu'ils tombent sur un logiciel en Java, ont le réflexe de chercher une alternative en autre chose que Java.

Qui du coup n'ont aucune chance d'être utilisés dans pas mal de cas où ils pourraient être utiles. Java est une maladie du logiciel libre.

Sauf qu'il est en Java.

je ne vois pas d'opposition, mais au contraire complémentarité.

C'est d'autant plus complémentaire que les systèmes d'empaquetage peuvent être adaptés pour empaqueter très rapidement des logiciels ou modules disponibles par un tel système de paquet interne. Pour Debian, c'est le cas au moins pour les extensions Mozilla et les logiciels ou bibliothèques en Python, en Perl et en Ruby par exemple.

retroshare n'est pas un paquet simple, il y a déjà 3 paquets à créer

Ça pourrait être le cas, mais non, contrairement à des logiciels qui ont une seule source à séparer en morceaux après l'avoir compilée, celui-ci est bien séparé en trois sources distinctes. De ce point de vue-là, ce sont trois paquets simple.

c'en est une autre de contacter toutes les distributions pour le faire inclure en suivant les procédures

D'où l'intérêt de Debian : il suffit de faire le travail une seule fois, et le paquet devient automatiquement disponible pour les utilisateurs de Debian, d'Ubuntu et de Mint, trois des onze distributions du top de Distrowatch (et pour onze architectures matérielles d'un coup).

Dans ce cas, pourquoi ont-ils préparé eux-même des paquets Debian ?

ou de je ne sais quelle pseudo allégeance avec "la distrib-la-plus-répandue-du-monde-si-on-compte-tout-les-forks"

Ça du sens, cette comptabilisation des dérivées. Parce que, maintenir Retroshare dans Debian, ça l'apporterait automatiquement aux utilisateurs de toutes les dérivées. Du point de vue des paquets disponibles, les dérivées sont évidemment à considérer.

Non. Ça c'est typiquement le genre de logiciel que j'essaie s'il est déjà disponible. Si j'y avais un réel intérêt, oui, je m'occuperais de le maintenir dans Debian.

Exact, sauf qu'ils ont préparé des paquets Debian. Le gros du boulot est fait, s'arrêter là c'est idiot. Ou alors c'est qu'ils ne veulent pas s'engager à maintenir ces paquets à long terme, ce qui est tout aussi inquiétant.

Autant que je sois précis tant qu'à faire. Quand on a un logiciel, et qu'on veut le fournir aux utilisateurs de Debian et dérivés, la bonne façon de faire, surtout si des utilisateurs le demandent ce qui est le cas ici, c'est : empaqueter, puis faire intégrer le paquet dans Debian.

Faire son propre paquet, voire faire son propre dépôt, c'est bon pour commencer, ou s'il y a une vraie raison qui s'oppose à l'entrée du paquet dans Debian (genre : des bouts non libres). À terme, c'est une très mauvaise solution, qui ne convient pas pour les utilisateurs d'une autre architecture que celle du développeur par exemple.

Retroshare s'installe très facilement sur ubuntu, debian, freebsd et windows

Sur PC 32 bits uniquement. Et personne ne connaissant pas Retroshare ne le trouvera directement en cherchant dans les paquets disponibles.

ils fournissent même des .deb

Pour i386 uniquement !

Des tas de logiciel libre de qualité ne sont pas dans Debian, faut arrêter les conneries. Et l'inverse est vrai, il y a dans debian des tas de softs de merde ou non à jour.

Exact. La question ici c'est : puisqu'ils ont fait un paquet Debian, et qu'en plus des gens demandent Retroshare dans Debian, pourquoi ne l'ont-il pas proposé ?

C'est du logiciel libre, si des gens veulent sous retroshare sous debian, all is open.

Exact. Et visiblement les gens de Retroshare ne s'en préoccupent pas.

Donc c'est la première réponse, ce qui est inquiétant parce qu'ils ont peu de chance de percer chez les linuxiens en ignorant la distribution la plus importante en nombre d'utilisateurs directs ou dérivés.

Ça témoigne en tout cas d'un problème. En effet, pourquoi ce paquet n'est-il pas dans Debian, s'il est déjà préparé ? Plusieurs réponses possibles :

• ils ne connaissent pas Debian, ou s'en moquent ;
• Leur paquet est sale, ils le savent et ne le proposent donc pas pour intégration ;
• leur paquet est sale, ils ne le savaient pas, l'ont proposé à l'intégration et ont été refusés.

Dans tous les cas, c'est mauvais signe. Bon, ceci étant, il y a une demande d'empaquetage de Retroshare. Une demande, mais pas de proposition pour le moment…

Documentée, oui : http://www.debian.org/doc/manuals/developers-reference/

Accessible publiquement, ça dépend de ce que tu entends pas là. Si tu te demandes si les listes et les salons de discussion sont ouverts à tous, oui. Si n'importe qui peut avoir un accès root sur les serveurs, certainement pas. :-)

Parce que ce logiciel n'est pas correctement diffusé ? Exemple au hasard : pas dispo pour Debian. Cette distribution, est loin d'être une distribution mineure ; avec ses dérivées comme Ubuntu ou Mint, elle serait même largement la plus répandue, probablement utilisée par une majorité absolue de linuxiens. Alors un logiciel sans paquet Debian, voilà, ça n'inspire pas confiance.

Qui te dit qu'on sera en surpopulation si Orange sature sont /32? On n'apprend vraiment jamais du passé!

Si, on apprend, et on dimensionne des systèmes qui ne peuvent physiquement pas être saturés. IPv6 en est un exemple : l'espace d'adressage est assez grand pour associer des millions d'adresses par centimètre carré de surface terrestre.

ZFS est un autre exemple : remplir l'espace maximal de stockage autorisé nécessiterait une énergie supérieure à celle nécessaire pour faire bouillir les océans de la Terre.

J'ai entendu parler d'une solution qui permettait d'avoir le même contenu sur une mailing-list, un forum, et un serveur de news

Pour ce qui est d'intégrer des ML et un serveur de nouvelles, c'est assez facile, à faire soi-même ou en utilisant les services de Gmane par exemple. Pour ce qui est d'un forum Web, ce qu'il faut c'est une interface Web pour les nouvelles. Google Groups fait ça, mais ça ne doit pas être le seul.

Ah, et pour les ML plutôt que des forums Web, je peux préciser. Des ML utilisent un système standard, le courrier électronique, et sont donc plus faciles à intégrer n'importe où. Gmane est un exemple d'une telle intégration, qui fournit une interface de nouvelles en lecture-écriture pour des ML. Google Groups est un autre exemple, qui fournit une interface Web pour des groupes de nouvelles. Gmane + Google Groups, ça existe peut-être…

Aucune idée, j'ai toujours vu Kerberos comme une grosse usine à gaz. Mais tout est centralisé dans un LDAP, si c'est utilisable avec Kerberos tant mieux, sinon tant pis.

Un parti politique a des besoins spécifiques, mais je peux, à titre de comparaison, te donner l'exemple de Debian, en ce qui concerne les discussions et la prise de décision. Pour le millier des développeurs Debian dans le monde, nous avons :

• Des listes de discussion par courrier électronique. C'est le moyen principal pour les discussions pérennes ; il y a des listes générales par sujet (debian-users@, debian-devel@, debian-users-fr@, debian-devel-announces@…) et des listes par projet ou groupe de travail (debian-l10n-fr@, debian-science@…). Ces listes sont ouvertes à tous, même au non-développeurs Debian, et accessibles par ailleurs sous la forme de forums de nouvelles par Gmane.

• Des salons IRC. C'est le moyen principal pour les discussions instantanées à court terme (« Quelqu'un saurait quel les l'outil pour pré-byt-compiler les modules Python d'un paquet déjà ? »). Il y a beaucoup moins de salons que de listes, mais ça suit un peu la même organisation, il y a des salons généraux (#debian, #debian-devel, #debian-fr…) et des salons spécialisés (#debian-python…).

• Une plate-forme de vote. Les élections et les propositions de modification de textes (typiquement, de la constitution Debian) sont élaborées et discutées en liste publique, puis proposées au vote, et ce sont les développeurs Debian qui votent.

Outre ces moyens de communication et de décision, il y a un tas d'outils de travail, mais c'est à mon avis un autre sujet. Pour ce qui est de l'infrastructure, tout ce qui nécessite une identification est basé sur LDAP en effet, et c'est d'ailleurs l'usage le plus complet de LDAP que j'ai jamais vu : on y stocke non seulement les noms et mots de passe des gens, mais également leurs clefs publiques SSH et PGP, ainsi que les caractéristiques de chaque machine du projet Debian. Il me semble d'ailleurs que ce LDAP est utilisé pour construire la zone DNS debian.org avec les noms des machines et des services, mais là ça devient vraiment hors sujet. :-)

Si vous voulez mon avis :

• forum et listes de discussion : c'est redondant, il faut en éliminer un (je préférerais voir rester les ML, plus standard) ;
• gestion de bogues, pads : à conserver pour des usages spécifiques ;
• serveur de discussion audio : à éliminer, c'est un des moyens les plus inefficaces qui soient ça, à remplacer par des salons écrits IRC ou XMPP ;
• plate-forme de vote : à conserver pour les décisions ;
• wiki : à conserver pour la documentation ;
• Twitter et compagnie : à conserver pour leur usage spécialisé, mais surtout pas pour les discussions internes ;
• blog : à conserver, et monter un Planet avc une vraie adresse (http://planet.partipirate.org/) pour les blogs des sympathisants.

/64 plutôt. L'auto-configuration fonctionne à partir d'un préfixe de 64 bits. Maintenant, c'est bon pour les machines qui servent de routeur à tout un réseau, pas aux postes terminaux !

/96, c'est vraiment radin, ça…