🚲 Tanguy Ortolo a écrit 12091 commentaires

De là à y voir du racisme…

Ceci dit, c'est peut-être à l'origine d'un certain racisme historique envers les noirs non ?

Dans les boulangeries, le gâteau "tête de nègre" a changé de nom pour éviter les connotations

Comment s'appelle-t-il maintenant ? C'est le genre de renommage dont j'ai horreur, je trouve d'ailleurs dommage que le mot « nègre » lui-même se soit retrouvé associé aux idées d'esclavage…

Debian ou Ubuntu LTS. Surtout pas d'Ubuntu non LTS par exemple : je n'ai pas envie qu'ils soient embêtés, ou qu'ils ne m'embêtent, avec des mises à jour trop fréquentes.

Et pour répondre aux arguments selon lesquels ils pourraient vouloir des logiciels récents : c'est faux. Les gens restent sans problème pendant des années avec des logiciels complètement caduques qu'ils utilisent très fréquemment, par exemple Windows XP ou Internet Explorer 6.

sethostname(2), clock_settime(2), setenv("LANG", const char *value, 1)

Génial ! Et comment je sauvegarde ça ? Ou tu préfère que l'utilisateur rentre ces paramètres à chaque reboot ?

• Nome d'hôte : dépend des distributions en effet, donc à wrapper.
• Heure : horloge matérielle, commune à tous. Un script d'init est fourni pour sauvegarder tout seul l'heure à l'arrêt dans toutes les bonnes distributions.
• Ton fichier de session, .profile, .zshenv ou .xinitrc.

Ta variable TZ elle est toujours plus simple quand tu dois donner le mot de passe root à un utilisateur pour qu'il la change ?

Nawak. Une variable d'environnement, ça se change par le processus qui veut se la changer. Dans notre contexte, il faut un moyen de dire à gnome-session de se la changer, mais pas besoin de privilèges root.

Comme l'indiquent les sections de page de manuel, il s'agit d'appels systèmes, effectués via la libc qui les passe au noyau. Bref, ce sont des trucs pour coder en C.

Si tu veux travailler en shell : hostname(1), date(1) et export LANG=…

pour changer le nom d’hôte, la date, l'heure et la localisation du système

Lis le mail, il n'y avait aucun moyen standard

sethostname(2), clock_settime(2), setenv("LANG", const char *value, 1)

systemd c'est un init, pas un outil pour changer l'heure. Pour changer l'heure, il y a clock_settime(2). Et PolicyKit pour wrapper ça et machinchouettiser les privilèges.

Y a un développeur Java qui t'a fait du mal ?

Non, c'est Java lui-même qui m'a fait mal. J'ai été traumatisé par un DocumentBuilderFactory.getInstance().newDocumentBuilder().createDocument() : c'est un exemple typique d'abus de patrons de conception, avec ici un singleton de fabrique de fabrique de documents au sein même de la bibliothèque standard.

Quels logiciels demandent ça?

Tous les systèmes de prise de contrôle genre KVM IP.

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