benoar a écrit 4229 commentaires

Exactement, un socat au bout d'un ssh ça peut être très pratique. Après, avoir d'office cette fonctionnalité dans OpenSSH est pratique quand socat n'est pas disponible sur la machine.

Perso, avec socat j'ai pu bidouiller des montages sftp root en se loggant en simple utilisateur mais en utilisant sudo.

En fait on utilise le module pour bind9 et non le service DNS intégré à samba.

Je n'ai pas de soucis particuliers avec l'association des ip avec les noms de machines, les postes s'intègrent bien dans le DNS (c'est d'ailleurs tout l'intérêt de ce module).

OK, donc ça c'est quand tu as une bonne gestion centralisée faite par un admin compétent. Malheureusement, ça n'est pas forcément disponible partout.

D'ailleurs, dans un contexte sans AD, tu peux configurer un serveur DHCP pour mettre à jour les IPs des machines dans bind automatiquement lorsqu'elle lui attribue une ip et ainsi avoir un lien constant et fiable entre le nom du poste et son IP. Ça reste plus contraignant qu'avec l'AD ou tout est automatique on est d'accord.

Tu parles du DDNS je suppose ; c'est effectivement une alternative faisable, et plus simple qu'un AD je trouve car c'est à peu près intérgré de base dans l'ISC DHCP je crois (genre une option à activer). Mais ça reste un truc central qu'il faut qu'un admin mette en place.

Maintenant vu la description que tu en fais je pense que tu parles de WINS qui est effectivement une grosse plaie pas fiable pour un sous.

Oui, c'est ça, WINS, merci. L'avantage de WINS sur un AD ou un DHCP+DNS administré, c'est que c'est décentralisé : pas besoin d'un admin pour gérer tout ça. Après, le protocole laisse quand même à désirer, et mDNS est beaucoup mieux fait tout en restant décentralisé.

Si tu restes sur un seul subnet ça fonctionne déjà pas très bien mais une fois que tu relies des sites distants par IPSEC c'est une vraie cata : même si tu configures les serveurs WINS dans DHCP et que tu les informes qu'ils doivent se mettre a jour mutuellement entre les subnets.

C'est l'avantage de mDNS (et DNS-SD) : localement ça marche sans rien faire, et il « suffit » d'un relai mDNS entre les deux pour étendre le service à des subnets différents. J'utilise ça à la maison sur un routeur vraiment cheap (avec OpenWrt), et ça marche du tonnerre (OK, ça n'est pas vraiment un déploiement immense…). C'est pas mal décentralisé, contrairement à un AD/DHCP, et ça marche sans administration (i.e. j'ai installé le truc sur la machine, sans configuration, et je n'y ai jamais touché ; il n'a aucun état à stocker, c'est juste un relai stateless de trames multicast).

C'est clair que sans liaison nom d'hôte / ip fonctionnel on ne risque pas de vouloir passer sur IPv6. Je comprends mieux maintenant où tu voulais en venir ^.

Oui, c'est quelque chose qui est poussé mais de manière assez indirecte à l'IETF : pour faciliter la transition, il faudrait que les softs soient bien codés et utilisent getaddrinfo() afin de s'abstraire de la notation des noms/adressent, et que le service de DNS marche bien partout (et à la maison, endroit où il n'y a pas d'admin local en général, il faut que ça marche tout seul). D'où mDNS pour palier ce second problème.

Ou alors, t'as un souci.

Oui j'ai un souci : une carte graphique sans accélération avancée. Je sais bien que tous les gnomistes vont me dire que je n'ai qu'a avoir une implémentation d'OpenGL complète et sans bug, mais malheureusement ça n'est pas toujours possible (ni parfois souhaitable).

Pour utiliser GNOME 3.12 sur ma machine principale, qui n'a pas de carte graphique dédiée mais uniquement l'IGP de mon i7, avec les drivers libres, c'est incroyablement fluide et réactif.

Oui bien sûr, c'est la config la plus « standard » qui existe aujourd'hui, et qui est très bien accélérée car les devs Intel font du boulot pas trop mauvais. Donc heureusement que ça marche bien (d'autant plus avec un i7…).

Pour l'utiliser également dans une VM VirtualBox, ça l'est tout autant. Pas rencontré de problèmes de ce côté là.

Ça m'intéresse de savoir les specs de ta CG virtuelle, et de savoir quelle accélération est implémentée par celle-ci. Ça ne m'étonnerait pas qu'il y ait la gestion de l'OpenGL intégré.

D'ailleurs, pour avoir récemment testé l'alpha de Fedora 21 avec GNOME 3.14, ainsi que le live CD de GNOME, tous deux dans une VM VirtualBox, j'ai remarqué que ces fameuses nouvelles animations n'étaient pas actives, et qu'on gardait le comportement précédent. À voir si ce n'est pas justement GNOME qui s'adapte en fonction du type de machine qui le fait tourner.

Oui, Gnome s'adapte, j'ai déjà vu qu'avec des vieilles bécanes (Intel intégrée, mais de 2006…), il passe en mode « classique » sans me demander mon avis. Mais malheureusement, même le mode le plus « basique » est encore beaucoup plus demandeurs en ressources qu'un XFCE (et de loin).

Autant le reste de ma critique était plutôt légère et pour troller, autant il y a un bout auquel je voudrais répondre sérieusement :

Sinon tous les jours des gens se pendent devant mon bureau car il n'y a pas de mDNS, ce qui ne cesse de m'étonner vu qu'ils n'ont toujours aucune idée de ce que c'est.

Je trouve que le manque de déploiement et de connaissance à propos de mDNS est un très gros handicap pour le réseau en général, et un des plus gros freins à IPv6 : les gens continuent, quand ils ont besoin d'accéder aux machines locales, à utiliser des IP(v4). Ou alors, quand ils ont Windows, le gestionnaire de nom de SMB (dont j'ai oublié le nom), qui a un fonctionnement encore pire que mDNS (d'ailleurs, tu ne t'en pleins pas ?). On aurait un mDNS qui marche partout et plus de vulgarisation de ce protocole, tout le monde pourrait utiliser des noms au lieu des adresses, et le monde irait mieux (ainsi qu'IPv6). C'est un problème que je trouve très sérieux. Et c'est pour ça entre autres que je continue à répondre à ce fil.

Je suppose que oui. Chez moi, c'est toujours un peu « exotique » car j'ai des écrans multiples, et même avec une « grosse » bécane ça rame à mort. D'où retour à Xfce.

En fait, la solution idéale, ça serait de corriger tous les drivers pour toutes les cartes pour que tout marche bien dans le meilleur des mondes, mais c'est juste impossible : il y a toujours des bugs ou des cas bizarres, et puis de toutes façons les implémentations « graphiques » sont refaites tous les quatre matins (cf Wayland ou les mille framework d'accélération de X11) et donc ne sont jamais exempts de problèmes. Du coup, pour moi, il faut toujours avoir la possibilité de faire marcher le bousin sans grosse accélération graphique. Sinon c'est juste trop la merde.

Les fournisseurs de contenus et vos fournisseurs d’accès à Internet se rapprochent de plus en plus les uns des autres pour élaborer de nouvelles alliances (complicités) pour optimiser leurs modèles économiques en essayant de différencier les contenus circulant via Internet pour élaborer des facturations à géométrie variable.

Franchement, c'est incompréhensible. Le reste va un peu mieux, mais cette phrase pour introduire le propos fait tâche.

Euh je n'ai rien contre la modernité ni contre IPv6.

Tu parlais de ton inquiétude vis à vis des services qui « multicastent à tout va » : le NDP d'IPv6 est assez bavard, à juste titre.

Avoir des services inutiles

Ah, ça y est, on sent le penchant despotique de l'admin qui sait mieux que tout le monde ce que les gens veulent.

qui causent sur tous les postes vers tous les autres et qui pourraient entrer en conflit avec les vrais services - au hasard - le DNS de l'active directory vu que nos domaines finissent avec le tld .local… non je vois pas du tout l’intérêt. Maintenant chacun fait bien ce qu'il veut.

Ah bah c'est dommage d'avoir choisi ce tld, qui est maintenant officiellement réservé pour mDNS. Je vois sur la page WP que ça a été recommandé à une époque par MS… beau cafouillage, comme d'hab pour eux. Mais tu peux configurer ton nsswitch pour qu'il interroge ton DNS avant de tester mDNS si tu veux.

Et ça ne m'empêche pas de trouver ça bien pour un réseau domestique.

Oui, mais pas que : ça permet d'être plus pratique aussi pour faire des choses que l'admin rechigne parfois à faire.

Je fais régulièrement le test qui tue pour savoir si Gnome redevient utilisable : le lancer dans une VM, qui n'a donc pas d'accélération graphique avancée, juste les trucs de bases (driver qxl de qemu). Et bien c'est inutilisable : ça rame à mort, pour rien.

Je sais bien que ça n'est pas dans la tendance, mais pour moi du coup c'est toujours niet si Gnome n'est pas capable d'utiliser une carte graphique basique pour afficher des trucs basiques. Le pire, c'est que c'est pareil pour le mode « classique » : ils ont enlevé tous les effets bling-bling et n'ont que la base, mais ça rame toujours car le moteur de rendu sous-jacent est le même. Pathétique.

Eh bien ça fait un petit moment que je n'ai pas utilisé l'installation standard pour être honnête mais je te crois.

Pour préciser, je parle d'une install « bureau » standard. Il ne doit pas y être pour une install avec aucune tâche dans tasksel (genre pour un serveur). Même si perso, c'est un des premiers trucs que j'installe sur un serveur, pour faciliter l'accès au serveur en question.

Debian serait donc une distribution moderne ! \o/.

Bien sûr !

PS: Va falloir que je me note ça dans un coin pour penser à le virer le jour où :)

Si tu n'aimes pas le multicast pour faire « pro », tu ne va pas beaucoup aimer les technologies « modernes » comme IPv6, par exemple…

Debian ne l'inclus pas dans l'installation minimale…

Bah, dans l'install « standard », il y est, en tous cas.

Toutes les distros modernent l'incluent par défaut, et configurent les machines avec le nom que tu leur donne lors de l'installation. Normalement, tu te connecte à « le_nom_de_ma_machine.local » (note le .local à la fin) et ça roule, pas la peine de faire plus.

C'est quoi ton débit nominal ? Combien de temps exactement tient-il ? Est-ce reproductible ? Est-ce que ça le fait en téléchargeant depuis un autre site ? Est-ce que les autres téléchargements sont impactés à côté ? Etc… Il y a plein d'autres questions à se poser avant de crier au loup.

Chez SFR, je dis pas, là je parlais chez FDN.

Après, si tu veux te défendre auprès de SFR, il va peut-être falloir une analyse un peu plus poussée que juste un screenshot…

Note que Youtube fait régulièrement tout pour qu'on ne puisse pas utiliser cette méthode : 70% du temps, je me tape des HTTP 403 (unauthorized) quand j'essaye de télécharger une vidéo (sans parler des changements d'API qui nécessitent de mettre à jour les downloaders). Du coup, je m'en passe, mais ça ne m'aide pas à garder de la sympathie pour cette plateforme.

J'ai constaté exactement le même comportement sur ma ligne. Des fois je lances de gros rsync (ça prend une journée ou deux), et plusieurs heures ou jours après la fin du rsync, ma connexion est lente et mon ping est terrible (ça se sent beaucoup sur les jeux en ligne). Quand je veux utiliser ma connexion pour autre chose, je met mon rsync en pause, et les pages Web mettent longtemps à s'afficher, mes pings sur les jeux en lignes sont meilleurs qu'avec le rsync, mais bien plus mauvais que ce que j'ai à la normale.

C'est super étrange comme comportement. Je n'avais jamais entendu parler de ça avant.

Par contre, quand tu dis que tu « coupes ton rsync », c'est qu'il était encore lancé… non ? Parce qu'à ce moment-là, tu vas mettre quelques temps (qui se compte en secondes normalement, mais peut-être plus) à retrouver un débit correct à cause du bufferbloat des fournisseurs de lignes ADSL qui ont des buffers gigantesques sur leurs BAS/DSLAM. Essaye de mesurer après une ou deux minutes, ça devrait revenir à la normale. Si ça met plus de temps que ça, là par contre il y a réellement un problème, et il faudrait contacter les adminsys, car ça n'est pas normal du tout. Ou en parler sur les listes.

Je ne sais pas d'où ça vient. Qualité de la ligne ? Limites physiques ? Bridage d'un acteur (pas FDN, j'imagine, mais plutôt nerim ou SFR?).

La qualité de la ligne, ça peut jouer sur la manière dont le buffer se vide (plus ou moins vite, la réactivité qui en pâtit avec les pertes de paquet), ce qui est dû à SFR ou Orange, sur le chemin entre chez toi et FDN, mais normalement Nérim ne bride rien.

Bref, encore une histoire de http://www.bufferbloat.net/, qu'il faut combattre !

Et de réseau.

Bah justement, un truc qui fait que m'auto-héberger c'est vachement différent d'avoir un dédié, c'est que le réseau est super bien pour communiquer avec ton serveur. Tu n'es pas limité en upload, la latence est minimale, choses qui font que c'est super sympa de bosser dessus. La disponibilité avec l'extérieure, elle est globalement bonne, je n'ai pas à m'en plaindre. Avoir une connexion locale avec ton serveur, ça change beaucoup de choses.

Ça n'a rien avoir avec « éviter de modifier du code », je n'aurais pas dis la même chose si tu avait parlé d'« éviter de modifier des interfaces ».

Heu… je n'ai jamais parlé d'éviter de modifier du code. Les interfaces dont j'ai parlé pour Debian n'ont peut-être pas beaucoup bougé, mais le code derrière, si, quand on en a senti le besoin (c'est à dire pas forcément partout).

Le bazard c'est ne pas hésiter à modifier le code si besoin, éviter de forger les choses dans le marbre. Tu confond les interfaces et le code. Et oui debian pourrait tout à fait modifier la façon de faire sans rompre la compatibilité, c'est une question de volonté plus qu'un quelconque choix plus ou moins technique.

Je pense qu'il y a une incompréhension : les choses « forgées » dans le marbre, il y en a partout dans les exemples que tu as cité (les codes du VT200, le principe de balise dans le HTML, les instructions x86 communes à tous les CPU Intel depuis les années 70), comme dans Debian. L'important est de savoir lesquelles, à quel endroit, etc. Debian a déjà modifié sa façon de faire sans rompre la compatibilité ; la preuve par exemple, le fichier indiquant le niveau de compatibilité n'a pas bougé, mais c'est justement pour pouvoir faire bouger tout le reste quand ce numéro change !

Je vois mal comment tu peut me faire un homme de paille aussi gros là-dessus.

"Éviter de toucher à du code", c'est se payer une dette technique.

Pas forcément, comme je disais avant à propos de « pas tous » les archaïsmes à garder. Ça dépend d'où tu as placé tes interfaces, de comment elles ont été définies, etc. On utilise tous des parties de codes qui n'ont pas bougé d'un iota depuis des lustres (les tty, le principe du tout fichier, le HTML, l'ISA x86, etc) qui sont pourtant des choses qui sont plutôt pas mal aujourd'hui. Et le fait que Debian soit toujours si « populaire » (d'une certaine manière) me fait dire que c'est une distribution qui a plutôt fait des bons choix. Le bazar, ça ne veut pas dire réiventer la roue tous les quatre matins, hein, ça n'empêche pas d'avoir un peu de stabilité sur certains points — et heureusement.

Moi je suis plutot pour avoir le minimum de rétro-compatibilité, quand c'est possible. Quand on change quelquechose, on garde eventuellement une rétro-compatibilité pendant 1 ou 2 releases, on convertit tout le plus rapidement possible, et on se débarrasse de la rétro-compatilité des que c'est fait. Ca permet de garder les choses simples.

Et bien sache que certains y voient exactement l'inverse ! Et trouvent que c'est changer les choses qui est compliqué. Quand tu gardes des interfaces sur le long terme, ça évite d'avoir à retravailler les softs tous les quatre matins.

C'est d'ailleurs la meme raison pour laquelle les dev du noyau linux aiment avoir tous les drivers inclus directement dans l'arbre des sources du noyau: en cas de changement dans l'api interne, on modifie directement tous les drivers qui utilisent cette api, et il n'y a pas besoin de garder une compatibilité avec l'ancienne api.

Oui, effectivement : le tout est de savoir où placer les limites de stabilité. Note que l'ABI des syscall de Linux (oui, même le format binaire !) est plutôt assez stable, c'est ce qui permet par exemple à Docker de bien marcher (ça tourne sur tous les noyaux supérieurs à 3.X (j'ai oublié le X) sans se poser de questions), car un kernel se doit d'être une interface stable avec les applications utilisateur. Par contre, pour les interfaces driver-kernel, on estime que la stabilité est moins importante, car le support du matériel n'est pas considéré bon quand il est effectué en dehors de la branche principale. Oui, ce sont des jugements de valeur, les devs kernel ont tranché, et globalement ça marche plutôt pas mal comme ça.

Pour le packaging, pareil, le projet Debian a choisi les frontières de stabilité : un paquet source doit être dans un format qui change peu souvent car les outils de gestion de ces paquets sont complexes, et que faire évoluer l'ensemble des paquets de l'archive Debian est une gageure. Pour le format binaire, c'est encore « pire » : il faut potentiellement que les paquets binaires soient installables par des versions diverses et variées de dpkg et apt. Par contre, la manière pour les développeurs de gérer leurs modifications est en changement constant. Forcément, ce côté n'est pas vu par les utilisateurs : eux ne voient que le côté plutôt fixe. Et — comble de l'ironie — on a parfois des devs qui se plaignent que ça change trop pour les différentes possibilités de gestion du packaging !

Perso, la complexité n'est pas mauvaise quand elle est « simplement » dû au manque de documentation sur certaines procédures : c'est un classique du libre, ça se « corrige ». Je trouve que techniquement, les contraintes de rétro-compatibilité sont plutôt très supportables. Mais c'est clair que oui, niveau documentation, il y aurait encore des efforts à faire, même si la doc officielle est un bon début, même si elle est certes longue : non, on ne peut pas se lancer en une heure à faire un package Debian, ça demande (malheureusement ou heureusement, si on s'oriente du point de vue qualité) un peu plus d'effort.

Va falloir que tu m'expliques ce qu'il y a de manichéen là-dedans.

Dire que soit on peut tout bloquer de manière incontournable, soit on laisse tomber complètement, ça n'est pas manichéen ?

Ce qu'on dit, c'est que si tu vois un site qui mets les photos des ex à poil, tu dois pouvoir faire fermer le site, et si le pays d'accueil n'est pas coopératif, au moins pouvoir le bloquer chez toi.

Qui pourra dire que ce sont des photos non volontairement mises en ligne ? On a des exceptions pour des cas très rares et évidents (la pornographie infantile), mais pour le reste, seule la Justice peut trancher. À chaque fois que tu mets le pouvoir de censure entre les mains d'intermédiaires sur des contenus sujets à interprétation, ça dérape. En plus, ça coûte horriblement cher ! Et si à la place de donner tout cet argent à des FAI, on le donnait à la justice et à la police ?

La victime continuera à être à la vue de tout le monde et tous les jours à poil sur internet, mais qu'elle se console: le juge a été plus dur avec le mec qui a pris les photos… enfin, si on le retrouve, parce qu'il est peut-être aussi à l'étranger, hein!

Ça arrive tous les jours avec d'autres décisions de justice, où le prévenu peut continuer à circuler librement ou à faire ce qu'il veut pour raisons X ou Y, et ça fait les titres des journaux à faits divers. Ça n'est pas à un intermédiaire technique de décider de ces raisons X ou Y.

Et ici, la solution que tu proposes, c'est quoi?

Donner les moyens à la justice et à la police de faire leur travail et de poursuivre les infractions. La même chose devrait être effectuée dans tous les pays du monde. C'est clair que ça n'arrivera pas en un jour…

Tu as le droit de posséder un couteau, tu n'as pas le droit de tuer, tu te sens contraint?

Pas du tout : tu me fais un gros homme de paille. Le couteau aurait un système de caméra et d'analyse en temps réel qui ferait qu'il m'empêche de faire ce que je veux, oui, ça m'embêterait. Mais bon, en parlant d'analogie débile…

L'enjeu dont on parle ici, c'est que la police et la Justice n'ont justement PAS TOUJOURS les moyens d'agir, en particulier si le site est hébergé à l'étranger dans un pays non coopératif par un hébergeur non coopératif.

Et donc pour ce cas minime, on devrait fliquer tout le monde ? Non merci.

Tu comptes attendre que le cas de figure se présente et expliquer à la victime qu'on ne peut rien faire par choix, c'est dommage pour elle, parce que ça arrive pas souvent vous savez? Bon, et bien le contenu va rester public. Bonne journée!

Chose qui arrive déjà (encore une fois) dans la vie réelle pour pleins de cas. Pourquoi traiter différemment le monde d'Internet ?

Je suis justement en train d'écrire depuis plusieurs mois une doc sur la création de paquetage pour Debian, basé sur les autotools. C'est clair que ça n'est pas simple. Je vois deux principales raisons à ça : l'historique de Debian, qui est quand même une des plus anciennes distros, et le fait que Debian avant tout une communauté de gens qui s'accordent selon des principes démocratiques avant d'être une solution technique.

Le premier point doit être la raison des fichiers un peu en vrac (car je ne connais pas leur histoire exacte) : c'est clair que ça n'est pas « propre » comme le voudraient certains esthètes, mais c'est de toute façon géré automatiquement aujourd'hui pour la plupart. Les fichiers essentiels à connaître son décrits ici : https://www.debian.org/doc/manuals/maint-guide/dreq.fr.html. D'ailleurs, c'est la doc officielle du mainteneur, et je la trouve plutôt bien faite, en plus d'être traduite en français : https://www.debian.org/doc/manuals/maint-guide/index.fr.html. Le wiki, c'est vraiment une source pas terrible selon moi (oui, je suis en train de tendre le bâton pour me faire battre).

Les fichiers requis ont (à peu près) tous une raison valable d'exister : le control c'est celui qui correspond le mieux à ce qui existe dans les autres distros pour « définir » le paquet ; le copyright est séparé car historiquement non-structuré, contrairement au control, même si ça n'est plus le cas aujourd'hui (mais pour cause de rétro-compatibilité, on peut faire soit l'un soit l'autre) ; le changelog c'est parce qu'historiquement, on n'avait pas de VCS, et puis il est utilisé par plein d'outils pour en extraire des informations (comme la version : ainsi, le fichier contrôle qui définit l'identité du paquet change peu) ; et le fichier rules est séparé du control car celui-ci n'est pas descriptif, mais est un ensemble de commandes. On pourrait essayer d'en réunir certains, mais je ne vois pas de raisons très convaincantes.

La rétro-compatibilité, c'est très important, même si c'est chiant : ce sont souvent les empaqueteurs « jeunes » qui vont râler sur tous ces archaïsmes qui viennent les embêter. Mais avec l'âge, on apprend que certains de ceux-ci (pas tous, hein), et le principe de rétro-compatibilité, sont vraiment très importants.

Ce qui est aussi très important dans Debian, c'est la conformance à ses standards sur la liberté du code : c'est une des raisons de la normalisation du noms des paquets sources, car ceux-ci peuvent aussi être retravaillés s'ils contiennent des morceaux qui ne respectent pas la charte (les sources sont appelées dfsg-free pour “Debian Free Software guidelines”-free). C'est un point très important également pour la distribution : Debian possède un réseau de distribution assez gigantesque et pourtant gratuit pour l'utilisateur, car les personnes (les ftpmaster) qui le font ont confiance dans la légalité de ce que fait le projet.

La deuxième raison est celle qui fait qu'il y a 40 manière de faire chaque chose dans Debian : beaucoup de monde a une idée différente de comment « bien » faire les choses, et du coup, soit on s'accorde sur une méthode commune (genre la gestion unifée des patchs dans le format 3.0, lancée par Raphaël Hertzog qui traîne ici), soit on trouve une manière de faire cohabiter « pacifiquement » les différentes méthodes (comme le fait que les mainteneurs ont des préférences de VCS différentes, même si j'ai l'impression que git domine ; bon, c'est justement un peu ce qu'a permis le passage au format 3.0). C'est plus compliqué quand les gens n'arrivent pas à s'accorder, mais on ne peut pas (ou rarement) avoir recours à des méthodes autoritaires pour décider d'une seule et unique manière de faire quand on est une communauté régie par une constitution. Ça ne va pas plaire aux « pragmatiques » du coin, mais moi je trouve ça très pragmatique au contraire.

C'est cette vision démocratique qui fait aussi que l'historique a l'air parfois un peu inconsistant : le projet évolue au fur et à mesure de sa vie, et les standards changent d'une époque à l'autre. Malgré tout ça, je trouve que le projet Debian se porte plutôt bien, et est reconnu pour la qualité des ses paquets, à défaut de sa célérité d'empaquetage. Je pense que c'est dû très largement à sa manière de voir le but du projet comme un objet social et politique plutôt que de se concentrer sur la partie technique (même si elle est pourtant très reconnue).

Les méthodes d'empaquetage pour d'autres projets ont beau être techniquement « supérieure », je ne suis pas sûr que ça tienne complètement sur le long terme sans objectif moins technique : j'ai souvenir que le standard il y a dix ans sous MacOS X c'était fink. Je suppose que ça a changé vu que je n'entends plus parler que de MacPorts les quelques fois où je rencontre ce genre de packaging (et à l'époque MacPorts n'était pas terrible). Un autre « mauvais » exemple est OpenWrt : je trouve le système de packaging vraiment génial, mais la communauté derrière est assez désordonnée et mal organisée, ce qui fait que le projet est toujours un peu vacillant (et pourtant j'adore ce qu'ils font). Bref, se concentrer sur la technique, c'est oublier un aspect très important du logiciel libre.

Tout d'abord, je trouve la réponse de Marotte à ton commentaire vraiment très bien, je ne vais faire que rajouter quelques remarques.

La question ici, c'est la capacité à bloquer systématiquement un contenu illégal. Cette capacité est sure ou ne l'est pas.

C'est assez horrible ce raisonnement manichéen, malheureusement j'ai l'impression de le retrouver chez beaucoup d'informaticiens. Nous, tout n'est pas tout blanc ou tout noir.

Si tu sauvegardes la possibilité pour toi de diffuser sans qu'on puisse t'en empêcher, alors cette possibilité est accessible pour toute personne qui souhaite diffuser du contenu illégal. Et tu le sais très bien!

Elle est disponible pour toute personne qui a tout de même un peu de volonté. On ne pourra jamais par aucun moyen technique empêcher quiconque de faire quelque-chose de « mal », ou alors seulement dans une société orwellienne complètement autoritaire (et encore, pas complètement ; c'est l'intrigue du bouquin justement). On essaye d'empêcher les meurtres en interdisant les armes de certaines catégories, mais quelqu'un avec un bon couteau pourra toujours y arriver. Pareil pour échapper à la Justice française : tu pourras toujours essayer (physiquement) d'aller à l'étranger, même si ça n'est pas forcément simple. Et bien mettre ton contenu à l'étranger, même si c'est plus simple que de le faire physiquement, ça ne reste pas à la portée de tous. Et si tu le fais, on pourrais arguer que c'est une circonstance aggravante pour ton cas (si on te poursuis en Justice). On compteras sur la coopération du pays en question, comme on le fait pour les autres délits. Parfois ça marche, parfois pas.

On sait déjà tous que compter sur la coopération des hébergeurs à l'étranger ouvre des failles béantes dans le processus. Soit tu décides qu'on laisse ainsi, soit on prend des mesures sur le territoire.

C'est pareil pour les banques : « tout le monde » peut aller mettre son argent dans un paradis fiscal. Mais en pratique, peu de monde le fait, et pour ceux pour qui c'est le cas, on essaye de trouver des solutions, sans aller jusqu'à la surveillance globale de tous ! (normalement…)

Est-ce qu'on veut pouvoir bloquer? La réponse est oui. Sinon, toutes les lois sur la diffamation, l'apologie du crime et autre ne servent plus à rien!

Je suis sûr que ces lois sont régulièrement violées IRL et que ça ne pose pas non plus un problème gigantesque. On donne des moyens à la police et à la Justice pour y remédier, on ne met pas une muselière à tout le monde.

C'est là le problème, tu ne peux pas vraiment avoir une sortie texte à la fois adaptée pour un être humain et pour un script, donc le 'tout est texte' te force en fait soit à faire des compromis douloureux soit à multiplier les outils..

Comme contre-exemple il y a git, dont la sortie « brute » (raw) est tout à fait lisible par un humain et est celle utilisée par l'outil. Dans la doc, la syntaxe est très bien définie, et surtout de manière stricte. On ne se rend même pas compte qu'en fait, git est un ensemble de script et d'exécutables écrits dans des langages différents (C, shell, perl) qui marchent bien ensemble parce que c'est écrit par des mecs qui savent bien coder.

On n'en sait pas énormément sur ce brevet en question, mais vu le domaine, ça serait vraisemblablement un brevet « logiciel ». Quid de la validité de ce genre de poursuite en France ? C'est la première fois que je vois un tel cas ici.

Je me suis dit ça aussi, et après quelques recherches c'est le Control droit qui avait été modifié sous Debian pour la carte française, si c'est bien ce dont tu parlais : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733757
Ça a été corrigé depuis.

Voir https://bugs.freedesktop.org/show_bug.cgi?id=15804 pour l'historique de pourquoi c'est arrivé là.