🚲 Tanguy Ortolo a écrit 12507 commentaires

Tu parles de PolicyKit n'est-ce pas ? Oui, c'est précisément fait pour ça. C'est systemd qui dépasse les bornes, ici.

On est passé d'une API dbus dans gnome-setting-daemon à une autre, documentée. Au contraire c'est plus facilement portable entre les DM et les systèmes de centraliser tout ca…

Holà, doucement, on parle de régler l'heure, là. Et encore, même pas, dans le problème d'origine il s'agissait de régler le fuseau horaire. Donc, histoire de savoir un peu le contexte :

• Changer de fuseau horaire ça se fait en fixant la variable d'environnement TZ des processus concernés. Aucun privilège nécessaire.
• Changer l'heure ça se fait avec l'appel système clock_settime(2), qui est décrit dans POSIX. Évidemment il faut être root pour faire ça, mais il y a déjà PolicyKit pour blurber le bouzin afin que l'utilisateur puisse cliquer pendant que l'administrateur s'arrache les cheveux parce qu'il n'y comprend plus rien.

Alors franchement, utiliser une abstraction et sortir systemd pour ces conneries, c'est vraiment se prendre la tête pour la beauté du geste, le genre d'attitude de programmation qui est vivement découragée, à moins de vouloir finir comme Java avec des horreurs comme DocumentBuilderFactory.getInstance().newDocumentBuilder().createDocument() pour créer un simple document XML (oui oui, il y a sûrement une raison à cette complexité, mais comme personne ne la comprend, ça ne sert à rien).

Dbus est linux specifique me semble t'il.

Négatif.

http://packages.debian.org/squeeze/dbus : regardez vers la fin de la page : « kfreebsd ».

Non, rc.conf c'était visiblement utilisé sur le système du Monsieur pour fixer la variable d'environnement TZ, héritée par le gestionnaire de connexion graphique, donc par GNOME, qui visiblement l'ignore royalement.

Bof bof, il n'y a pas que GNOME en même temps.

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. :-)