Jean-Philippe Garcia Ballester a écrit 1104 commentaires

Comme le dit flan, l'égalité des droits entre êtres humains c'est autant une valeur morale que la nécessaire liberté d'un logiciel (et l'éventuelle différence d'importance entres les deux valeurs est aussi une valeur morale).

l'idéologie, c'est mal, ça empêche de réfléchir

Sans valeurs morales (ce que tu appelles idéologie), tu utilises quoi comme critère pour légiférer ?

Je cite Thomas "logiciel non-libre est rarement acceptable"
Je cite Zenitram "FFmpeg est libre"
Qui mélange logiciel et format? dois je mettre en gras souligné le mot que Thomas a utilisé (et qui n'est pas "format")?

C'est toi qui n'a pas compris ce qu'il veut dire. Dans le paragraphe dont est tiré la phrase que tu cites, il ne parle pas du tout d'h264. Au début, il reste d'abord dans le sujet en disant en substance que les fonctionnalités ne sont pas les seules critères dans le choix d'un codec (et là il parle bien de h264), puis étend son idée au logiciel (et cette fois il ne parle plus d'h264).

Ces trois critères : la soumission d’un algorithme à brevet, la liberté d’une implémentation logicielle de cet algorithme ou le prix de distribution de cette implémentation sont trois exemples de critère qui peuvent être préféré à une supériorité technique.

Tiens, la liberté de modifier disparait du libre… CC-ND devient libre. Enfin, chez Thomas.

Il dit bien que ces critères sont des exemples et ne dit pas qu'ils sont suffisants. Aucun rapport avec la définition du libre donc.

Je ne comprends pas ton commentaire, il propose juste d'utiliser un antispam en complément des outils cités dans la dépêche. Je ne vois pas où il dit avoir une solution parfaite.

Si par là tu veux dire que neCua6nahS s'est trompé alors tu as tort…

je me suis souvenu que tu m'avais déjà parlé d'inotify et que tes commentaires proposait même d'utiliser systemd pour automatiser le lancement de services suite aux changements de fichier

Sauf erreur, je crois que tu fais référence à mon commentaire dans le journal inotify. Ca me fait un peu rire, parce que à la base je l'avais surtout écrit pour troller les anti-systemd :)

Une vieille installation manuelle de phpBB qui trainait, complètement troué. Quelqu'un en profité pour lancer un script qui envoyait des tas de paquets UDP sur une IP donnée, un DDOS sauf erreur.

Je pense que Menton faisait référence à la ville, donc son exemple est pertinent.

C'est aussi que tu ne fais pas de distinction entre une surveillance généralisée par un gouvernement et une surveillance au cas par cas sur décision de justice.

Tout pareil. Tes journaux sont très intéressants, surtout continue !

?

Rien ne t'empêche d'écrire une bibliothèque avec juste les fonctions utilisées par systemd et de patcher systemd pour se lier à ta bibliothèque.

Je rajoute aussi que systemd n'est pas un système d'init. C'est un ensemble de logiciels bas niveau (tout comme kde est un ensemble de logiciels graphiques). Du coup, oui, il est moins complexe à comprendre que ce qu'il remplace.

Dit moi, tu comprends mieux comment fonctionne un système d'init (si on peut encore appeller cela comme ça) aujourd'hui (systemd upstart), ou avant, à l'époque de SysvInit/runit/etc.. ? Moi c'était avant.

Si tu parles du fonctionnement interne du système d'init (le code), alors ça ne change rien, je ne le connais pas plus maintenant qu'avant.

Si tu parles de comment utiliser le système d'init, alors je trouve ça plus facile maintenant. Un tas de scripts d'init étaient imbitables, différent d'une distribution à une autre, non-documentés…

C'est vachement plus facile pour moi aujourd'hui d'écrire un script d'init que ça ne l'était avant, et je peux le faire avec plus de fonctionalités.

Moi je me souviens très bien de l'arrivée de pulseaudio, qui a foutu en l'air plein de truc qui marchaient; perso j'étais sous arts (artsd) à l'époque, j'avais tout qui marchait, (dont l'usage à travers de réseau), et lorsque pulseaudio a été imposé par la distrib, ça a tout cassé.

Sauf erreur de ma part, aRts a cessé d'être développé en 2004 (due to a variety of fundamental development and technical issues, cf wikipedia), et pulseaudio a été installé par défaut sur Ubuntu (une des premières distribs à l'avoir installé par défaut) à partir de 2008.

Et puis faire marcher l'ensemble des applis Linux à l'époque de aRts, il fallait quand même drôlement s'accrocher, avec des couches de compatibilité dans tous les sens, parce qu'entre oss, alsa, aRts, et esd, c'était pas folichon.

Et pulseaudio fait bien plus que ce que faisait aRts (une gestion simple du multi carte-son, ce qui est loin d'être un cas particulier aujourd'hui).

A titre personnel je ne suis pas nostalgique de l'avant PA en tout cas …

Je me rappelle encore de l'époque où il fallait écrire un fichier de config pour dmix à la main… Et même avec ça on avait pas le quart des fonctionnalités de PA.

C'est de plus en plus difficile de savoir ce que fait sa machine, mais c'est aussi de plus en plus facile de l'utiliser.

C'est une supposition, mais je pense que PA utilise seulement l'API bas-niveau de Alsa pour pouvoir faire ce qu'il veut faire.

Non, c'est incron et inotify-cxx. inotify tout court, c'est une API du noyau (des appels systèmes) qui n'est pas développée par la personne qui tient le site dont il est question.

Merci pour le commentaire (ce n'est pas le seul dans le genre) très révélateur de la manière de (non) penser des anti-systemd.

Les généralisations outrancières, c'est le mal.

Bonsoir,

c'est une affaire de goûts, mais la syntaxe de systemd me semble au contraire plus explicite (dans la configuration incron, les champs de sont pas explicites, il faut connaître la syntaxe du fichier pour le comprendre).

Elle n'est en tous cas pas plus obscure que celle d'incron (puisque les deux sont très bien documentées).

De plus systemd permet un peu plus de choses (démarrage conditionnel, dépendances, cgroups, etc).

Je croyais que c'était Tor Tue.

À noter aussi que les unités systemd de type path utilisent inotify. On peut donc utiliser systemd en lieu et place d'incron. Pour l'exemple donné ici, demander à lancer automatiquement la commande postalias lorsque /etc/aliases est modifié (totalement non testé mais c'est l'idée) :

le fichier /etc/systemd/system/aliases.path

[Path]
PathModified=/etc/aliases
[Install]
WantedBy=multi-user.target

le fichier /etc/systemd/systemd/aliases.service

[Service]
ExecStart=/usr/sbin/postalias

Il est aussi possible d'utiliser ces fonctionnalités sans accès root en mettant les unités dans le dossier $XDG_CONFIG_HOME/systemd/user/*.

Des infos plus récentes que le bugzilla de firefox peuvent être trouvées ici : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#239

Tout à fait, c'est beaucoup mieux, merci !

Sauf erreur de ma part, si on ne l'utilise ni ne la transforme, on ne peut l'utiliser que pour chauffer, n'est-ce pas ?

Sauf erreur de ma part, si on l'utilise pour chauffer, on l'utilise. /o\

Je voulais bien sûr dire, si on en la stocke ni ne l'utilise :)

Donc à part la cuisson des aliments qui ne représente pas une consommation d'énergie très élevée, l'énergie propre dont tu parles sert à se chauffer lorsqu'il fait chaud ?

On pourrait chauffer avec l'énergie solaire même lorsqu'il fait froid.

Tu peux en dire plus ? Des exemples ou des sources ?