arnaudus a écrit 5258 commentaires

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…

À mon avis, il faut voir les templates pour ce qu'ils sont : des outils au service des développeurs de bibliothèques. Si tu regardes le main, la syntaxe n'est pas trop affreuse.

Par contre, j'avoue que j'ai vraiment un doute sur cette tendance à remplacer le polymorphisme par la programmation générique. Bon, c'est toujours un peu compliqué de reprocher aux développeurs de chercher le gain de performance, mais le coût associé est, à mon avis, terrifiant. Pensez par exemple aux logiciels libres : de combien de contributeurs potentiels se prive-t-on avec un code truffé de variadic templates qui s'apparentent au brainfuck? Ça n'est même pas un problème de lisibilité, c'est avant tout un problème d'abstraction, de syntaxe obscure, et de normes tarabiscotées, qui transforment la méta-programmation en exercice complètement élitiste, réservé aux professionnels du domaine. C'est quasiment un autre langage, en fait.

C'est un peu tendancieux quand même, parce que la licence mentionne souvent des clauses supplémentaires (typiquement, no warranty) qui couvrent également l'utilisation.

Tu y vas fort quand même, une grosse partie de la publicité revient, au sens étymologique, à partager avec le public des informations sur le produit que tu veux vendre : si vous cherchez une voiture neuve, j'en vends pour 14999€, et regardez comme elle est belle. Dans l'absolu, je ne vois pas vraiment de mal à ça, impossible d'avoir une activité économique viable si tu n'as pas de moyen d'informer des clients potentiels de ton existence.

Après, tu as la partie qui consiste à présenter des truc sous leur meilleur jour, mais dans un certain sens, c'est pareil que de mettre du déodorant avant un rendez-vous galant. L'objectif n'est pas non plus forcément de pousser l'autre à un acte irrationnel. Là où le marketting est nuisible, c'est (i) quand il est agressif (on t'abreuve d'informations alors que tu n'en as pas demandé), (ii) quand il est mensonger (prix, qualités du bien, etc), ou (iii) quand il utiliser des techbiques de manipulation pour provoquer des achats compulsifs qui seront regrettés.

Dans les faits, c'est fou le nombre de gens qui ne comprennent pas comment fonctionne le système d'imposition, et qui sont prêts à tout un tas de comportements irrationnels pour éviter de «sauter une tranche». Y compris chez des cadres sup, ou tout un tas de gens qui ont le bagage culturel pour comprendre ce qu'est un taux d'imposition marginal. Mais non, tu as toujours dans ton entourage quelqu'un qui est fier de t'expliquer qu'il a dû faire quelques centaines d'euros de dons pour ne pas sauter une tranche (*).

On trouve un truc un peu similaire avec la déclaration frauduleuse de frais réels quand on est dans les taux d'imposition les plus bas. Là, c'est sûr qu'il y a un peu d'argent à la clé, mais très peu en comparaison des risques qu'on prend (bon, les risques sont tout relatifs, mais c'est plutôt la honte d'être affiché lors d'un contrôle fiscal qui me semble rédibitoire).

Pour revenir à la défiscalisation, je me demande si ça n'est pas le même biais cognitif que celui qui semble inciter certaines personnes à acheter des objets dont ils n'ont pas besoin parce qu'ils sont en promotion.

(*) le cas des seuils est un peu particulier, mais les seuils pour les allocations familiales ou autres prestations sont différents des seuils d'imposition (j'imagine que c'est volontaire, d'ailleurs, ces seuils sont tous différents les uns des autres ce qui, globalement, limite l'effet total). En tout cas, même si on est bien renseignés, les seuils s'appliquent sur les revenus de l'année N-1 ou N-2, avec des montants réévalués tous les ans, c'est bien difficile de prévoir en 2018 quel sera le seuil qui sera retenu en 2020…).