arnaudus a écrit 5237 commentaires

De toutes manières, il est indéniable que ce texte ne nous concerne pas, et que les destinataires sont les gens de Framasoft. Il est possible qu'ils le trouvent ici, mais ça n'est pas la meilleure façon de procéder.

Ça, c'est sur la forme. Sur le fond, je ne suis même pas convaincu que ce texte ait du sens. Les paragraphes que j'ai l'impression de comprendre sont une sorte de bullshitage fumeux à base de mot-clés.

Pourquoi ne pas le transformer en crédit d'impôt ?

Au delà du bête argument budgétaire, mon interprétation du système c'est plutôt que de déclarer un don revient à choisir d'orienter une partie de son impôt vers une association (c'est une manière de participer à la politique de financement des associations).

Si tu dois payer 1000€ d'impôts et que tu as 10000€ de revenu, il te reste 9000€ pour vivre. Si tu fais un don de 300€, tu te retrouves avec 8900€ pour vivre, 800€ d'impôts qui vont à l'État , et tu "orientes" 200€ de tes impôts vers une association (c'est comme si tu payais tes 1000€ d'impôts mais que tu forçais l'État à en redonner 200 vers l'association de ton choix). De manière assez logique, il est impossible d'orienter une partie de ses impôts quand on n'en paye pas.

Finalement, le seul truc bizarre du système, c'est qu'on rembourse le particulier (ce qui donne l'impression d'un cadeau ou d'une défiscalisation), alors qu'il serait beaucoup plus logique que les dons soient non-déductibles mais que l'argent arrive dans les caisses de l'association. Ça reviendrait au même au niveau comptable, mais symboliquement, ça change tout.

Il faut garder à l'esprit qu'il n'est pas obligatoire de déclarer ses dons, ce qui revient à considérer que l'argent des impôts est aussi bien dépensé par l'État.

C’est mal connaître la philosophie de Google que de dire ça.

Je ne comprends pas. L'OP dit "YouTube […] ne plante quasiment jamais", et ta réponse cite "the marginal difference between 99.999% and 100% gets lost in the noise of other unavailability". Est-ce qu'un service disponible 99.999% du temps n'est pas plus ou moins exactement un service qui ne plante quasiment jamais?

J'aurais dû lire la FAQ avant de poser des questions :-) Si j'ai bien compris, j'ai confondu les instances fédérées (qui partagent les métadonnées sans partager les vidéos) et les instances miroir (qui partagent tout).

Ceci dit, la FAQ semble être sûre d'elle quand elle décrit la manière dont les vidéos potentiellement illicites ou hors-charte sont rapportées aux administrateurs de l'instance où la vidéo est hébergée (et pas aux administrateurs des instances fédérées), mais je serais plus dubitatif. Ça me semble un peu douteux qu'un visiteur puisse visionner une vidéo hors-charte à partir de mon instance, et que je puisse m'en laver les mains aussi facilement, en prétendant que ça n'est pas moi qui l'héberge. C'est à peu près la même situation qu'un moteur de recherche, il y a une forme de complicité à servir d'intermédiaire naïf pour trouver un fichier peu recommandable (qu'il s'agisse de contenu illégal, immoral, ou n'importe quoi).

Si j'ai bien compris, Peertube offre une solution technique pour l'hébergement et la diffusion de vidéos (ce qui n'est pas rien), mais dans quel état se trouve la partie "réseau social"? Si on prend une plateforme comme Youtube, son utilité en tant qu'hébergeur n'est pas réellement prépondérante. Un intérêt majeur de Youtube est d'offir un moteur de recherche dans sa base de données de vidéos, qui permet 1) de fournir des listes de vidéos pertinentes à la suite d'une requête, et 2) de fournir ces fameuses "suggestions", qui, si elles sont bien utilisées, peuvent être d'une intérêt majeur (zapper vers quelque chose de plus prometteur quand on s'ennuie, se voir proposer un point de vue alternatif…). Or, pour offrir un tel service avec PeerTube, il faudrait une grosse base de données partagée entre de nombreuses instances pour un moteur de recherche (l'alternative consisterait en la mise en place d'une grosse instance, mais évidemment la décentralisation en prend un coup). Comment ça peut fonctionner concrètement?

L'autre question de fond reste la responsabilité des hébergeurs sur les contenus diffusés, qui risque de limiter la coopération entre les instances. On peut imaginer des chaînes d'instances de confiance, mais existe-t-il par exemple la possibilité de communiquer des listes de vidéos à supprimer entre instances "partenaires"?

Le builder est un outil du développeurs, pas un système de packaging.

Si c'était vrai, tu te distribuerais pas le système de build avec tes sources (tu ne distribues pas les options de ton IDE, ni ton compilateur…). Le fait d'avoir une cible "install" montre bien que tu distribues un pseudo-paquet.

Sauf que ça reste quand même assez limité, étant donné l'obligation de dénonciation des crimes et délits à laquelle sont soumis tous les fonctionnaires (article 40 du code de procédure pénale). La dénonciation passe directement par le procureur, en théorie. En pratique, l'administration fait tout pour faire croire qu'il existe une voie hiérarchique à respecter, pour de bonnes et de mauvaises raisons.

Si meson ou CMake s'imposent tout doucement comme outils de développement pour les projets d'envergures

L'intention n'était évidemment pas d'empêcher les gens d'utiliser un système de build différent de GNU make et autotools. Je trouve juste que ces systèmes alternatifs auraient pu faire l'effort de fournir une interface à peu près normalisée afin qu'il soit trivial de passer de l'un à l'autre, voire de complètement abstraire la procédure de compilation derrière une interface unique.

Bref, pour l'utilisateur lambda, ce n'est pas franchement plus compliqué à mon sens.

Ce qui est compliqué, c'est d'avoir une procédure différente pour chaque machin que tu veux compiler, en fonction des préférences du développeur. Ton raisonnement pourrait être poussé à l'extrême; si le dev a mis au point son propre système de build et qu'il te faut taper "gogo-gadget o compilateur", tu vas trouver ça débile, même si c'est marqué dans le README.

Ça n'est pas non plus pour rien qu'il y a des standards de facto, et je trouve que la compilation se prêterait justement pas mal à avoir une procédure un peu normalisée (avec un certain nombre de cibles standard: clean, make, install, etc). J'imagine aussi que ça simplifierait pas mal la vie aux différentes distributions, et que ça réduirait la fragmentation.

Tu réalises que Ninja est un remplaçant à Make ?

Non, ça n'est pas un remplaçant, et c'est bien ça le problème. systemd est un remplaçant à sysVinit, mais ninja est une alternative à make. Tu es donc exactement dans la situation décrite par le xkcd ; tu crées un système alternatif avec l'espoir qu'il remplace à terme l'existant, mais tu crées juste une nouvelle syntaxe qui s'additionne aux systèmes de build alternatifs qui existent.

Si au lieu de remplacer une brique par une autre équivalente tu préfères rajouter un wrapper et une nouvelle dépendance, t'es pas sorti de l'auberge…

Une dépendance à GNU make sur une distribution linux? C'est le genre de dépendance qu'on peut certainement assumer, non? En plus, la dépendance peut très facilement sauter si ton système de configuration fait en sorte de tester la présence de make sur le système.

Je pense justement que le coût d'une dépendance à un logiciel qui est installé par défaut sur la quasi-totalité des distributions et un wrapper trivial est minime par rapport au coût d'être dans l'inconnu total quand tu télécharges un .tar.gz.

Je crois que je comprend un peu ce que veut dire l'OP. La réalité, c'est que la diversité dans les systèmes de build est incoutournable, et qu'il n'est pas réaliste de faire comme si elle n'existait pas. L'avantage avec les autotools, c'est que quand on téléchargeait un tar.gz, on savait qu'il fallait faire ./configure && make && sudo make install. Là, chaque système de build vient avec une syntaxe à lui. Bien sûr, la réponse évidente, c'est "il suffit de remplacer make par ninja, et truc par machin, et de rajouter l'option --bidule = target, rien de bien sorcier. Sauf que chaque système de build concurrent va venir avec sa syntaxe, et que connaitre les syntaxes des 12 systèmes de build courants, ça va être possible pour un admin sys, mais pas pour quelqu'un qui installe un truc hors paquet de sa distrib tous les six mois.

Moi je trouve que les trois étapes "configuration", "compilation", "installation" sont très claires, et qu'il existait déja une syntaxe (pas forcément très logique, pas forcément intuitive, mais elle avait le mérite d'exister). Pourquoi ne pas s'être débrouillé pour que tout système de build génère par défaut un exécutable "configure" dans le répertoire, un Makefile minimal de trois lignes qui appelle ninja ou n'importe quoi d'autre, avec une cible "install" qui installe le truc? C'est ça le problème, c'est l'apparition de nouvelles syntaxes pour faire la même chose qu'avant.

Wikipédia semble lister un grand nombre de langages compilés et reflexifs (Go, objective-C, etc). Je ne les pratique pas, donc je ne sais pas vraiment de quel type de reflexivité on parle, mais j'ai quand même l'intuition que la reflexivité ou la méta-programmation doit empêcher la plupart de l'élimitation de code mort ou de code non-utilisé.

J'imagine que comme toute grande entreprise, les compétences initiales sont noyées dans la lourdeur, la bureaucratie, les décisions de décideurs qui ont une formation top-moumoutte en prise de décisions décisionnelles… Parce que ça ne date pas de Gmail, la "mise à jour" de Google maps d'il y a quelques années ont transformé un site incoutournable en quelque chose de quasi inutilisable. À se demander si Google ne se reconvertit pas dans le minage de bitcoins…

Je ne suis pas sûr qu'il soit aussi simple de détecter les bouts de code qui ne seront jamais appelés (et quand tu compiles statiquement, est-ce que tu veux vraiment que le compilo choisisse ce qui est lié et ce qui ne l'est pas?). Mais de toutes manières, ça pose une énième fois la balance entre la liaison dynamique et la liaison statique, c'est toujours aussi compliqué.

Sur le fond, c'est dur de lui donner tort, sur la forme, il y a des trucs douteux. L'exemple des compilateurs, par exemple. Pourquoi compiler du C++ prend des plombes? En grande partie, parce que c'est une tâche hyper complexe, du fait de l'évolution du langage vers de plus en plus de trucs à faire au moment de la compilation (y compris l'optimisation). Pourquoi afficher des trucs prend des plombes? En partie, parce que le nombre de pixels n'a pas augmenté linéairement dans le temps, en partie aussi parce qu'on a amélioré les algorithmes d'affichage (sub-pixellisation, etc), en partie parce qu'on a complexifié les choses à afficher (transparence, coins arrondis…). Nier que les ordinateurs d'aujourd'hui font aussi des tâches beaucoup plus complexes, ça rend quand même l'argument moins pertinent.

Tout grossit aussi parce que les briques de base s'améliorent en terme de fonctionnalités. Ça me semble être une évolution difficile à enrayer pour les bibliothèques de base, par exemple : "et si vous faisiez ci, et si vous faisiez ça", avec l'argument de "mais votre concurrent X le fait!". Un exemple tout con, c'est par exemple d'avoir besoin de fonctions mathématiques pas complètement courantes (je ne sais pas, la fonction probit dans un programme en C, par exemple). Idéalement, il faudrait quoi? apt install lprobit-dev et #include "probit.h", chacun contenant quelques lignes de code? Ça ne marche pas comme ça. Il va falloir installer un gros paquet contenant des centaines ou des milliers de fonctions (boost?), puis appeler un gros .h qui va inclure d'autres .h qui vont inclure d'autres trucs, et voila, ça y est, on a bloaté son système et son logiciel. Honnêtement, j'ai du mal à imaginer de vraies alternatives.

Ça permet de pouvoir le poursuivre. D'une manière générale, c'est de toutes manières le seul but des licences, non? Je ne connais pas de licence qui empêche physiquement quelqu'un de faire ce qu'il veut avec le code.

Après, tu peux diffuser sous copyright strict ; le code ne peut être reproduit ou diffusé de quelque manière que ce soit. Ajouter des termes de licences non-libres mais garantissant la libre diffusion offre la possibilité de contrôler ce que les gens ont le droit de faire ou non avec le code. Je ne prétends pas que c'est bien ou que c'est mal (en l'occurrence je crois que ça n'a que peu d'intérêt dans le cas dont on discute).

Ceci dit, pour revenir à ta remarque de départ, il faut bien se rendre compte que dans la très grands majorité des cas, les licences, libres ou pas, sont principalement de l'esbrouffe. Quand tu développes un bout de code sur tes week-ends et que tu le diffuses sous GPL, tu espères que la GPL dissuade éventuellement les gens peu scrupuleux de s'approprier le code. Ça n'est qu'un espoir, parce que si quelqu'un le fait, alors il faudra faire valoir tes droits (avocats, expertises, procès…). Tout le monde sait qu'il n'est pas très rationnel d'investir des dizaines de milliers d'euros dans une procédure judiciaire complexe (et assez incertaine vu la jeunesse de la jurisprudence sur ce genre de sujets) pour faire valoir des droits symboliques. Si tu attaques une grosse entreprise et que par miracle tu gagnes au tribunal contre une armée d'avocats spécialisés, tu vas pouvoir prétendre au remboursement partiel de tes frais de justice, et éventuellement un dédommagement à la hauteur réelle du préjudice subi (c'est à dire, de rien du tout à pas grand chose). Au mieux du mieux, le tribunal t'offrira l'équivalent du prix du logiciel que l'entreprise t'a pompé, si tu l'avais développé pour eux. S'il s'agit d'un utilitaire un peu marginal, ça ne va pas aller chercher loin. Et tout ça, c'est si ton adversaire est une entreprise française. Si c'est un groupe d'adolescents Biélorusses, tu vas te marrer rien qu'à savoir quelle institution judiciaire est concernée…

Du coup, comme toute licence, oui, c'est principalement du flan. Ça te donne juste la possibilité éventuelle de faire valoir tes droits contre un méchant, et tu espères que ça va faire suffisamment peur au méchant pour être dissuasif.

Pour garantir l’intégrité d’un document on le signe numériquement. Ce n’est pas le rôle d’une licence.

Ça n'est pas du tout la question, je pense. L'objectif est de laisser tout le monde distribuer un bout de code en rendant la distribution d'une version modifiée illégale. La signature numérique peut permettre à un tiers de s'assurer que le document est exactement le document d'origine au bit près (si ce tiers s'en donne la peine). Tu peux distribuer du code GPL et signé (dans ce cas, les versions modifiées ne seront plus signées et tu pourras éventuellement prouver que tu n'as pas certifié les versions modifiées). Bref, la signature numérique ne répond pas du tout à la question «je souhaite distribuer un document de manière à ce que chacun puisse à son tour le distribuer librement, éventuellement en changeant de format ou en appliquant des modifications mineures qui ne remettent pas en cause les droits d'auteur sur le document, mais sans pouvoir en modifier de version modifiée».

À la limite, je trouve que ça pourrait justifier d'une licence de type "CC-ND": la seule raison légitime de diffuser un code modifié pourrait être de falsifier un document historique. Bon, je joue l'avocat du diable, parce que je ne suis pas convaincu moi-même, et qu'il me semblerait intéressant que des passionnés puissent faire tourner ce code éventuellement patché sur du vieux matos. Mais bon, sur le fond, dès qu'on touche à des documents historiques, la question du "verbatim" me semble défendable.

J'imagine que c'est surtout l'intérêt historique du truc qui est prépondérant dans ce cas. Une sorte d'archives pour les historiens. Après, libre ou pas, ça n'est peut-être pas si important.

J'imagine que ça peut éventuellement être important, par exemple si un suspect a été pris par une caméra de surveillance à une certaine distance. Il y a des cas où ça doit pouvoir faire la différence, même si la plupart du temps ça n'a aucune importance.

Oui, je suis sûr de mon coup. De nombreux musiciens ont mis leurs enregistrements sous licence libre (souvent CC-BY-SA ou équivalent), et de manière surprenante, les œuvres orchestrales aussi. Tu peux commencer par wiki commons, par exemple, il y en a des milliers, et c'est plutôt propre au niveau des licences. Il y en avait énormément sur Jamendo avant le drame de l'affaire StMaclou, j'imagine que tout est encore sous licence libre, et doit être téléchargeable quelque part.

Pour les musiques de jeu, il y a un catalogue plétorique. La plus grande partie du répertoire classique est disponible sous licence libre, et pour ce genre de jeu, c'est plus que suffisant pour trouver des heures de musique d'ambiance adaptées. La qualité de l'exécution et de la composition sont d'ailleurs extrêmement supérieures à ce qu'on peut trouver en musique de jeux libres, et je crois que je ne comprendrai jamais comment on peut livrer des jeux libres avec une musique insupportable, alors que la musique symphonique libre est tellement facile à récupérer! Et qu'on ne parle pas de la personnalisation des jeux, le catalogue est tellement vaste qu'on peut trouver n'importe quoi qui corresponde à n'importe quelle ambiance…

Il y a aussi une gradation entre les raisonnements fallacieux (sophisme != raisonnement fallacieux). Il y a aussi certains raisonnements qui sont logiquement faux mais socialement vrais. Par exemple, l'argument de la pente glissante est assez frappant, puisqu'en effet, c'est un raisonnement fallacieux, sauf que l'organisation de nos sociétés humaines fait qu'il est souvent valide, puisqu'on fonctionne beaucoup par des raisonnements relativistes (on perçoit l'évolution d'une situation par rapport à l'existant, par exemple).

je suis pas persuadé que le gain en performance soit considérable quand on utilise des templates.

J'imagine que ça dépend du code, comme tu ne passes pas par une vtable, ça te fait sauter les indirections.

Moi, c'est plus la béatification des calculs par le compilateur qui me fait douter. Attention, je ne prétends pas que ça n'est jamais utile, c'est juste qu'il y a tellement de manières plus ou moins élégantes de le faire, mais qui ont le mérite de ne pas brainfucker du code… Déja, tu peux très bien calculer tes trucs au runtime et stocker les résultats en mémoire si les calculs ne sont pas trop longs (de toutes manières, s'ils sont trop longs, ta compilation va durer quinze plombes, ça n'est pas intéressant non plus). Par ailleurs, si ce que tu veux c'est une grosse base de données sur des séries mathématiques (un million de décimales de pi, les nombres premiers entre 10 et 20 millions, etc), alors une solution équivalente serait de les calculer une fois et de les mettre dans un .h (éventuellement généré automatiquement lors de la compilation?). Si c'est quelque chose de plus spécifique à ton soft, c'est certainement tout à fait raisonnable de coller tes trucs dans un fichier ou une base de données et de lire dedans la première fois que tu en as besoin (typiquement, ouvertures aux échecs, etc). De toutes manières, il arrive forcément un moment où la recherche dans une bdd prendra plus de temps que de recalculer, donc c'est toujours un compromis.

Ça ne retire en rien des capacités impressionnantes des dernières évolutions du C++, mais c'est juste que j'ai du mal à trouver ça exceptionnellement intéressant.

Mouais…

static constexpr frozen::map<T, decltype(F{}(v)), sizeof...(Vs)> cached = {{Vs, F{}(Vs)}...};

Franchement, rien qu'à parser ça, c'est chaud. Il y a deux qualificateurs (static et constexpr), avec static qui est hautement polysémique en C++ et constexpr qui vient d'être introduit dans la norme. Ensuite, on a visiblement une map, à dimension ésotérique. Et ensuite, on a une syntaxe pour l'initialisation qui est hyper obscure. J'ai l'impression qu'avec un peu de doc, je pourrais m'en sortir avec une connaissance du C++ "normale". Par contre, il faut comprendre aussi ce que bien peut faire decltype(F{}(v)), sizeof...(Vs), et {{x}...}, et dans mon cerveau, c'est un gros "syntax error". Ça ne ressemble en fait même pas à un truc compilable, en fait. On est vraiment en présence d'un nouveau langage, mais ça ressemble autant que C++ que perl ressemble à java…