🚲 Tanguy Ortolo a écrit 12252 commentaires

Je ne comprends pas davantage ta question. Ce que je dis, c'est que Java, c'est celui d'Oracle. Qu'il y a des alternatives partiellement compatibles, ce qui ne résout pas complètement les problèmes de Java.

Conclusion, hébergez vous-mêmes vos données. Comme ça, vous n'aurez pas toutes les étoiles, non, mais bien mieux : non applicable pour la plupart.

• Tells users about data demands : inutile l'utilisateur est mis au courant par la demande elle-même.
• Be transparent about government requests : non applicable pour les demandes du gouvernement américain (inutile d'y obéir), pour les demandes du gouvernement français idem que précédemment.
• Fights for user privacy in court : évidemment.
• Fights for privacy in Congress : inapplicable, nous sommes en France.

D'ailleurs, un hébergement chez soi est probablement plus protecteur en cas de demande du gouvernement ou de la police. Le serveur étant dans le domicile privé, on peut refuser d'obéir tant que la police ne vient pas perquisitionner avec une autorisation d'un juge.

Ben ça ne doit pas être la même chose qu'Oracle Java, parce que je ne connais pas un seul système de contrôle à distance (KVM IP…) qui fonctionne là-dessus, pour mentionner un exemple bien typique.

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.