lasher a écrit 2753 commentaires

Comme le sais-tu ? Peut-être que l'auteur considère ça comme une remise en cause de sa morale parce qu'il se serait inspirer d'un autre livre (que ce soit vrai ou pas).

Je te propose de lire l'article qu'il a publié dans le NewYorker et te rendre compte par toi-même qu'à aucun moment P.Roth ne se sent atteint dans sa dignité. Il raconte simplement dans l'article comment il en est arrivé à écrire son bouquin.

Mais un jeu commercial et distribué yadda yadda, pas de problème ? Deux poids, deux mesures ?

Bon je ne comprends pas vraiment là. Chez tout plein de gens, il est naturel de fournir des versions static inline un peu de cette façon-là:

/* from some_util_file.h */
/* #includes omitted */

static inline void fatal(const char *msg) {
    perror(msg);
    exit(errno);
}   

/* ... */


static inline void * s_malloc(size_t sz) {
    void *p = malloc(sz);
    if (!p) fatal("Couldn't allocate memory");
    return p;
}

/* ... */

Bref, de proposer des versions « configurables » (car par ex là, ça va forcément toujours planter alors que parfois il existe des moyens de moyenner). Est-ce que ce ne serait tout simplement pas plus simple de toujours faire ainsi ? Comme ça au moins, on sait que quelqu'un, quelque part prend en charge ce genre de trucs, et le code du « vrai » programme n'a pas besoin d'être encombré de vérifications en tous genres…

Laisse Perl tranquille ! Il t'a rien fait ! :-(

Voilà, exactement. D'un côté on a Red Hat qui paie des gens (a priori pas mauvais techniquement) pour developper systemd, de l'autre on a un nombre indéterminé de gens (sans doute en majorité des admins plutôt que des devs), et c'est évident que maintenir l'init façon SysV ou BSD va se faire naturellement, en dehors de leurs heures de travail…

Tu rigoles j'espère ? La politique, ça commence au niveau zéro, celui de l'engagement militant. Si un truc ne te plaît pas, et que tu ne participes pas d'une manière ou d'une autre pour contribuer à ce qu'elle change, tu es aussi coupable qu'un admin qui (au hasard) ne saurait pas faire plus que scripter (parce que bon, le dév système et la prog en C, ça fait 10-20 ans qu'il en fait plus…).

Certes, mais dans ce cas précis, au moment de dire à Roth "il nous faut des sources secondaires", j'ai comme l'impression que son identité n’était plus en doute…

Oui. Plus exactement, c’étaient les spéculations de critiques littéraires. Maintenant comme le disait quelqu'un sur la page de commentaire de Wikipedia à ce sujet : "C'est un fait que des gens ont dit ceci. C'est aussi un fait qu'ils se sont trompés."

Plusieurs intervenants dans la discussion ont alors précisé que Wikipedia n'a pas l'obligation de dire "la vérité", mais bien de sourcer toutes leurs affirmations (j’exagère et je déforme sans doute). Ce que je trouve un peu grave, c'est que si une source qu'on ne peut taxer de "mineure" dit que quelque chose est fausse, ben…

Et oui, tu as raison, on peut toujours vouloir revenir sur ce qu'on a dit, etc. Sauf que dans ce cas précis, on a d'un coté "Machin pense que ce bouquin est inspire par …", et de l'autre l'auteur qui dit "Non, c'est pas inspire par … du tout."

Donc au final, il y aurait sans doute la place pour les deux informations (réception par la critique et réalité des faits), mais la remise en question de la crédibilité de l'auteur du bouquin dont l'article est question a fait monter le tout en épingle.

Pour répondre rapidement :

1. Roth est passée par un de ses collaborateurs pour faire l’édition de la page en question (apparemment, la page citait des critiques du NY times qui faisaient le rapprochement avec l'autre auteur).
2. Ca a été considéré comme du vandalisme, donc le texte original a été rétabli 2 fois je crois
3. Roth a ensuite écrit (on ne sait pas comment : lettre papier ? email ?) a Wikipedia pour qu'on modifie la page (et de ce que j'ai compris, il a demandé a ce qu'on retire la fausse information)
4. C'est la qu'on lui a explique qu'il fallait des sources secondaires (!)
5. Roth écrit dans un journal pour rajouter des sources secondaires…

Ensuite, on ne peut PAS exiger de tout le monde de connaitre par cœur la façon dont Wikipedia opéré, etc. Par là je veux dire qu'un mec de 70+ ans a autre chose à foutre que d'apprendre le protocole de communication avec les admins wikipedia, lorsqu'il a l'impression qu'on dit des choses fausses à son sujet.

Enfin, je ne vois pas pourquoi tu me donnes une définition du dictionnaire pour "allegedly" alors que j'avais déjà fait une traduction au tout début de mon journal…

Moi j'aurais plutôt dit que c'était une référence à « "Il" est revenu », l'adaptation de « Ça » de Stephen King.

Généralement il y a une notion de compensation dans ce cas-là.

Mac OS X permet de formater des volumes en UFS, je dirais depuis le premier jour (en tout cas dans 10.3 c'était déjà faisable).

J'oubliais : le « relativement vrai » s'applique au percevoir des « compagnons » vis à vis de l'autre personne dans le couple, bien entendu. :)

Bon, je vais tacher de trouver des copines "féministes" dans mon entourage et leur raconter/faire lire la blague. Bien que je pense avoir des opinions différentes des tiennes concernant les "limites" du sexisme, etc., je suis d'accord avec toi sur cette blague : il n'y a absolument rien de sexiste de mon point de vue dans cette blague.

Je n'ai pas lu les raisons qui pourraient faire croire ca cette dame que la blague est sexiste. Je suppose que ce sont les références au "silent treatment" et ce qu'une femme veut dire par "nothing's wrong". Bon d'une, je suis d'accord, c'est une généralisation sur le comportement féminin en couple. De deux, le phénomène s'est suffisamment produit dans mon entourage (et avec les copines que j'ai eues) pour que, sans aucune donnée statistiquement vérifiable, je puisse au moins considérer que ce comportement, s'il n'est pas forcement majoritaire, reste quand même SUPER courant. De trois, même si ce comportement est le produit d'une certaine forme de domination patriarcale instaurée par la société (ce dont je ne serais pas difficile à convaincre), ça ne change pas le fait que LA, MAINTENANT, ça reste relativement vrai. De quatre, ça ne veut pas dire que les hommes ne peuvent pas être comme ça non plus. :)

Il y a un DVD qui regroupe trois émissions du tribunal, dont celui de Le Pen. C'est d'ailleurs très intéressant à écouter. Il y dit des trucs qui font froid dans le dos. On y comprend aussi pourquoi Desproges dit "avec un 'H' comme dans HHHHalimi" (car mal prononcé par Le Pen pendant l’émission). Les émissions étaient aussi filmées (peut-être pas celles du début cependant). Du coup on peut aussi y voir la bouille des intervenants, notamment dans le cas Le Pen : un Luis Rego qui ricane en bon sale gosse décrivant la journée d'un fasciste, Le Pen mort de rire, et les rares prises de vue de Desproges, qui ne rit pas du tout. Tu peux trouver les vidéos sur YouTube.

Le coffret comprend aussi des interviews de Villers et Rego (entre autres). C'est la qu'il explique le vote dont j'ai parlé.

Pourtant, à l'occasion où il le dit (tribunal des flagrants délires), il fait pourtant de l'humour (et de très bonne qualité)… Il n'avait pas envie de rire en la presence du borgne, mais il faisait de l'humour quand meme ? Ou bien c'est toi qui veux qu'il l'ait dit dans ce sens là ?

1. Avant de faire cette émission, il y a eu de gros débats au sein de l’équipe du "tribunal" pour savoir s'il fallait inviter LePen. Desproges était contre.
2. Desproges, après avoir "perdu" le vote, a fait preuve de professionnalisme en faisant son boulot (et brillamment).
3. Quand Luis Rego prend la parole, tout le monde (y compris Le Pen) rit énormément. Pas Desproges. D'ailleurs, Desproges n'a quasiment pas souri pendant son propre réquisitoire.

Proposer en upstream sur un projet aussi gros que Mozilla, peut consommer énormément de temps, parce que le patch ne peut pas plaire, parce qu'on te demande de le refaire comme-ci, comme-ça.

… Ou parce que même une fois que tu t'es exécuté, on peut finir par te le refuser. J'ai des témoignages dans le cas précis de Mozilla où des patches pour XulRunner ont au départ été refusés pour des questions de forme (coding style, etc.), puis refusés tout court. De ce que j'ai compris, il s'agissait de patches qui n'avaient pas d'impact « négatif » (au sens de changement lourd dans le comportement de XulRunner). Du coup les personnes en question¹ (qui développent un produit construit par-dessus XulRunner) font leurs propres patches, et ne tentent plus de remonter quoi que ce soit.

[1] Je ne veux pas parler en leur nom, vu que je n'ai jamais travaillé avec eux, et donc qu'il me manque sans doute des détails…

OK, mais là on parle de programmation en C++ pas d'un sous-ensemble de C++. Ta proposition de ne pas utiliser les classes est une façon parmi d'autres de choisir une stratégie pour répondre aux questions que je pose.

Pas d'accord. Pour paraphraser S.Meyers (« Effective C++ »), le C++ est en réalité 4 langages en un :

1. Le langage C
2. Le langage « C avec classes » (et potentiellement en 2b. C avec classes + exceptions + RTTI)
3. C + STL (c'est très, TRÈS utilisé dans pas mal de machins pour simulations numériques soit dit en passant)
4. Le système de templates (en incluant les possibilité de méta-programmation) + C

Tu peux prendre indépendamment n'importe lequel de ces langages, ou bien en faire une combinaison. Pour donner un exemple à la con : j'utilise C++ pour l'écriture d'un runtime. Nous utilisons le système OO, les templates, et nous avons utilisé la STL principalement pendant la phase de prototypage (nous essayons de remplacer les conteneurs STL par des structures de données qui s'adaptent mieux au contexte — à l'exception de std::string, bien pratique). Nous n'utilisons pas les exceptions. Jamais. Nous ne pouvons pas nous permettre de payer pour exceptions et potentiellement la RTTI qui va avec.

Ta fonction écrit sur stdout ou dans un fichier si c'est une valeur complexe ou renvoie un code de retour. Tu récupères la valeur avec '>' ou avec les backquotes pour les valeur complexes.

Ah bah forcément, si tu limites les fonctions du shell à ce qui t'arrange … :-) Mais oui, je suis bien d'accord, le shell n'est que le « squelette » (en gros : structures de contrôle et notion de « statement »). Que le reste soit fait à base d'utilisation de bc, seq, etc. ne me choque pas du tout dans le cadre de Bash. Ce que je dis, c'est que la notion de « fonction » en Bash est en réalité une notion de « procédure » (i.e. qui ne renvoie aucun résultat). Et si tu veux pouvoir communiquer ce résultat à d'autres fonctions dans ton script Bash, ou tout bêtement à l'appelant, tu te retrouve obligé de passer par des variables globales prédéfinies et connues de l'utilisateur de la fonction. Si toutes tes fonctions Bash sont purement autonomes je suis d'accord ça suffit. Si tu cherches à aller plus loin (je ne dis pas que c'est souhaitable), la notion de fonction en Bash est très limitée.

Le shell ne sert pas à manipuler ces valeurs, il sert à coordonner le travail de plusieurs processus (en leur passant les valeurs).

Ben plein de gens ne sont pas d'accord avec toi, sinon la notation $(()) pour faire de l'arithmétique entière n'existerait pas, par exemple (et je m'en suis servi plusieurs fois pour automatiser des benchmarks dont les binaires prenaient en paramètres des valeurs numériques …). Ou les fonctions « builtin », etc.

Cela dit, c'est justement parce que programmer en C/C++/ADA/blah est trop chiant pour ce qui concerne la « coordination de processus », mais que (ba)sh est trop limité dans beaucoup de cas (le script de coordination commence à dépasser la trentaine de lignes ;-)) que des langages comme Perl émergé.

[à propos du passage de paramètre en C/C++] La différence avec ce que j'ai écrit est que tu as supprimé l'opération de recopie. Si tu passes un pointeur avec transfert de propriété et que tu veux continuer à travailler sur la valeur, il faut la recopier. Quelle que soit la façon dont tu résous le problème, tu n'as pas le droit de le passer sous silence.

Donc en gros, tu m'expliques que si je fais des choses plus compliquées que Bash, alors j'ai plus de questions à me poser quant à la façon de concevoir mes fonctions en C++. Je dis que si tu veux rester au « même niveau » de fonctionnalités que Bash pour les appels de fonction, un moyen simple est de faire faire du « tout référence constante » pour le passage de paramètre, et « tout référence » (non-const) pour écrire le résultat de la fonction (ça marche aussi en passant un std::ostream).

Pour la copie, etc., j'aimerais bien que tu me donnes un exemple simple de ce que tu veux dire en utilisant Bash et C++. Les copies profondes ou superficielles ne sont un problème que si tu manipules des objets complexes. Dans le cas des appels de fonction en C++, je ne vois pas le rapport. Ta fonction se fout de la sémantique de copie. Elle prend des paramètres en entrée, et renvoie éventuellement un résultat, point.

a l'epoque, c'etait pas à moi que ca arrivait, mais j'avais déja assez de jugeote pour comprendre en quoi c'etait horrible, et que j'etais assez "bizzare" pour que, s'il n'y avait pas eu encore pire, ca aurait pu être moi le souffre douleur. Je me suis alors demandé ce que j'aurais pu faire pour aider le gars… Pas trouvé de réponse => C'est con pour lui. Tant mieux que ca soit pas moi.

Bah moi j'ai fini par comprendre : un mec qui se retrouve « isolé » et se fait emmerder, ça m'arrivait d'aller l'aider. Je ne le faisais pas systématiquement, mais m'étant moi-même fait agresser quand j'étais plus jeune, j'ai passé une salle période au collège. Quand j'ai changé d'environnement (déménagement des parents et du coup changement de lycée), quelque part j'étais dans un lycée « pire » que le précédent, mais le changement de voisinage m'a permis de m'affirmer un peu mieux. Et je suis petit, pas baraqué.

Maintenant je ne le faisais pas si souvent que ça, mais si tout le monde aidait les plus faibles de temps en temps, y'aurait moins de « bullying » je pense …

Pour commencer tu n'as pas déclaré les prototypes de tes fonctions.

Tu n'es pas obligé de déclarer les prototypes. La norme autorise à ne pas le faire car une définition fait aussi office de déclaration.

Comment passer mes arguments à ma fonction? J'ai le choix entre: par valeur immédiate, par référence, par pointeur sans transfert de propriété, par pointeur avec transfert de propriété, par recopie (si mon objet définit un constructeur de recopie, et que celui-ci n'est pas cassé… ah mais au fait, c'est une copie superficielle, etc.) Et encore j'évite les hypothèses de type pointeur sur void avec information adjascente pour récupérer le type (c'est parfois une option sérieuse).

Non. Tu fais ce que tu veux en C++. Tu n'es même pas obligé de passer par le système orienté objet si tu n'aimes pas. Tu peux parfaitement faire du « C en C++ » avec juste l'avantage d'avoir un typage plus fort et oui, des références à la place des pointeurs quand ça a du sens.

Comment récupérer la valeur de ma fonction? Dans un argument que j'aurais moi-même passé en argument (par référence ou par pointeur?) ou bien dans une valeur de retour, ou bien je renvoie une référence ou un pointeur sur un espace de stockage privé?

Alors qu'en Bash, c'est tellement mieux : tu es obligé de déclarer une variable extérieure à ta fonction, qui vit dans un espace de nommage « global » et donc risque d'entrer en conflit avec d'autres variables (bref, c'est de ta faute si deux fonctions utilisent la/les même(s) nom(s) de variable(s) de retour).

Ensuite, tu utilises tout un vocabulaire compliqué (« espace de stockage privé » ? Vraiment ?). Il y a deux solutions globalement : soit tu renvoies une valeur avec ta fonction, soit tu écris dans une variable passée par référence (que ce soit une référence de type « pointeur » ou « référence C++ », ça reste du passage par référence). Ensuite, n'importe quel codeur C (même pas C++) sait que dès que le type devient un peu complexe, il est préférable (le plus souvent, il y a toujours des exceptions bien entendu) de passer un paramètre par référence (donc par pointeur en C, pointeur ou de préférence référence en C++). Bref, tu as en gros trois choix pour le retour :

type f(paramètres...);               // par valeur, pour les toutes petites structures ou les types primitifs
void f(paramètres..., type& retour); // pour tout le reste en gros
void f(paramètres..., type* retour); // à utiliser en dernier recours, si on a besoin de manipuler le pointeur lui-même

Tout ce qui est qualification de type const, volatile, etc., rentre dans la notion de « type » dans ce contexte.
Je suis le même raisonnement général pour le passage de paramètres pour une fonction en C ou C++.

Comment signaler les erreurs?

Tu fais comme en C : tu utilises un entier/un enum pour le retour de ta fonction. Tu n'es pas obligé de passer par les exceptions. Tu n'es jamais obligé d'utiliser l'intégralité d'un langage, et c'est encore plus vrai en C++ où Stroustrup, Meyers, Sutter & co ne cessent de répéter qu'en C++ on ne paie que pour ce qu'on utilise. Rien ne t'oblige à faire de la méta-programmation à base de templates ou même de faire des fonctions templates si tu n'en as pas besoin. Rien ne t'oblige à faire du « C avec classes » si tu ne le veux pas. Et si tu le veux, rien ne t'empêche de jeter l'encapsulation par la fenêtre si tu veux juste un POD : déclare simplement des structures comme en C (avec l'avantage de pouvoir quand même définir des fonctions membres si tu veux faire un peu d'objet).

Évidemment, C++ est bien plus complexe que Bash, je ne le nie pas. Mais quand on me dit qu'en Bash il est bien plus simple de déclarer des fonctions qu'en C++, je suis très moyennement d'accord. Je me dis même qu'il suffirait de se donner une règle très simple pour « émuler » en partie la façon dont les fonctions Bash fonctionnent : toujours passer ses paramètres par référence constantes (types primitifs inclus), et si la fonction renvoie quelque chose, toujours fournir une/des variables passées elles aussi par référence.

Tu m'aurais dit « en Python/en Ruby, il est bien plus facile de déclarer des fonctions qu'en C++ », j'aurais déjà été plus d'accord. Ce qui me gêne dans les fonctions Bash, c'est l'absence de portée lexicale pour les valeurs de retour.

À la différence de C++ où il faut commencer une psychothérapie à chaque fois qu'on veut définir une fonction

Je sais que l’exagération est voulue, mais définir une fonction en C++ n'est pas plus difficile que définir une fonction en… C. Donc si ton idée est de dire que définir une fonction dans un langage de script quelconque est plus simple que pour les langages compilés classiques bon ben, nous sommes bien d'accord. Et encore, c'est discutable.

/* En C/C++ */
int sqr(int x) { return x*x; }

ou

(* en OCaml *)
let sqr x = x * x

me semblent plus sympa que

# En Bash
sqr()
{    
    sqr_result=$(($1*$1))
}
#do something about sqr_result

Je vais tâcher de faire court, parce que non seulement les mouches doivent vraiment en avoir marre de nous subir, mais en plus il serait temps que je rattrape le temps perdu sur mon boulot. :P

Ma théorie, c'est que si le logiciel avait pris naissance en même temps que l'art, et qu'on avait sacralisé les programmeurs et la création de code comme on a sacralisé les artistes et la création artistique pendant des siècles, peut-être que les programmeurs ressentiraient aujourd'hui un attachement narcissique d'une même intensité vis-à-vis de leur code. Mais c'est juste une théorie. :-)

C'est là que je me répète un peu encore, mais le logiciel est intrinsèquement utilitaire, là où (selon moi), l'art est intrinsèquement inutile (oui, je sais, la notion « d'art appliqué » fait que ce n'est pas aussi manichéen). Du coup, j'en reviens à mes exemples (bancals, je suis d'accord) sur la capacité à quantifier des améliorations sur des softs. Il y en a quand même un bon paquet qu'on peut objectivement mesurer : temps de réaction, temps de traitement pour un certain type de donnée, complexité d'un algorithme, quantité de mémoire consommée en RAM ou sur le disque dur, etc.

Lorsqu'on expose quelqu'un à, disons, du Goya ou du Rembrandt, ou bien du Daft Punk ou du Bach, etc., la réaction ne peut être que subjective. Elle est bien entendu sujette au passé culturel du spectateur ou de l'auditeur (tout comme tout ce qui touche aux IHM, etc.). Il n'empêche que cette réaction sera bien personnelle (même si sans doute statistiquement prévisible pour des individus d'un groupe « culturel » donné). La notion d'amélioration d'une œuvre aussi du coup.

J'ai été du côté de ceux qui ont tenté d'écrire des nouvelles et autres romans. Bien entendu, il y a énormément de choses qui sont similaires entre concevoir un programme (architecture, modélisation, etc.) et un roman (plan détaillé). Mais la différence selon moi est bien plus qu'anecdotique. Le type d'effort que j'ai mis dans les quelques nouvelles que j'ai réussi à achever fait que le moindre changement de vocabulaire, de virgule, etc., dans une phrase peut changer dramatiquement l'impression que je veux laisser au lecteur. Je ne dis pas que changer ladite phrase, ou même la supprimer, rendrait forcément l'œuvre moins bonne. Mais il y a quelque chose de personnel dans l'écriture de fiction qui fait que du coup ça casse ma vision de l'histoire que j'essaie de raconter.

A contrario, lorsque j'écris un article de recherche, les contraintes d'espace (un article fait entre 6 et 15 pages en moyenne, simple ou double colonne, 10pt ou 11pt), couplées au fait que ce qui importe c'est le message et sa clarté (car on veut être informatif avant tout) font que je n'ai aucun problème à ce que quelqu'un d'autre reprenne l'article, le modifie, l'augmente, etc., tant que ce qui est raconté dans la version modifiée reste factuel. Je vais peut-être grincer des dents si je vois des fautes de style (du genre phrase alambiquée mais qui reste correcte), mais tant que ça reste compréhensible, je ne vais pas me plaindre.

Quand j'écris du code ou que j'en conçois, je dois aussi composer avec la personne qui co-écrit le code. Nous n'avons pas forcément la même vision de comment implémenter les choses. Mais ce qui importe est que nous nous accordions sur un vocabulaire qui nous permette de définir une API. Ensuite, chacun code son truc. Et s'il faut modifier l'API plus tard, on se concerte, et on la modifie. Mais tout ça n'est possible que parce que l'objectif « ultime » du logiciel est d'être utilisé, et facilement maintenable (dans le cas où l'on veut le faire évoluer pour rajouter des fonctionnalités par exemple, l'optimiser, ou tout simplement corriger des bugs).

(et zut, j'ai encore écrit un roman… Je vais vraiment essayer de faire plus court pour le reste)

Oui mais entre les gens qui considèrent de *-ND c'est libre, ceux qui considèrent que *-NC c'est libre, ceux qui considèrent que FaiF c'est libre, si tu présentes une œuvre comme "libre", puis qu'ils se rendent comptent que c'est du *-NC-ND, tu vas en décevoir plus d'un. Pour éviter toute confusion, s'appuyer sur la définition existante est la meilleure chose à faire, IMHO.

Je suis d'accord, ça fout le bordel. Mais c'est toujours comme ça quand il n'y a pas de consensus sur une définition. Sauf que ce que tu appelles « la définition existante » n'est pour le moment qu'une définition parmi d'autres, qui en plus me semble avoir été proposée par des gens qui cherchent à généraliser la notion d'œuvre (donc que cette œuvre soit de nature technique, artistique, ou autre…). C'est ambitieux, pas forcément débile, mais avant de chercher à parler « pour tout le monde », il faut peut-être essayer de convaincre « assez de monde ». :-)

Les mots n'ont un sens que si une grande partie de la population qui y sont exposés les adoptent.

Je suis d'accord. Mais bon, en attendant "free software", pour la grande majorité des gens, ça veut dire "logiciel gratuit"…

Alors ce qui, à mon avis, a fait la grande force du mouvement pour le logiciel libre était que justement RMS s'est cantonné à un domaine bien précis. Et il a obtenu l'aval de nombre d'informaticiens de tous types (chercheurs, salariés, utilisateurs, etc.). Bref, il a obtenu l'aval de gens qui produisent du logiciel. Quand on parle d'œuvres artistiques, je pense qu'il faut commencer petit de la même manière. Avec un peu de chance, on va voir émerger des ambitions communes pour des types d'œuvres différents, ce qui va permettre de simplifier ce qui au départ ne sera qu'un ensemble désorganisé de « licences » et autres définitions de « X libre » (avec X qui peut être « roman », « musique », « film », « photographie », etc.).

Comment expliques-tu que certains auteurs publient sous des licences différentes ? (Pas forcément libres, juste un peu plus permissives que les droit d'auteur qu'il critiquent.) Ces artistes sont intelligents, mais ne sont pas non plus des génies.

Pour reprendre les cas connus, genre Trent Reznor (avec Nine Inch Nails, et la BO de « The Social Network » par exemple), la première chose qu'ils font, c'est de permettre le partage et de vendre ce qu'ils produisent à un prix raisonnable. Il y a bien entendu aussi le cas de Reznor qui a dumpé sur le Net 450GB de rushs d'un de ses concerts, sans contrepartie (à ma connaissance; je ne sais pas s'il a indiqué l'équivalent d'un -NC). Mais il peut se permettre ceci en grande partie parce qu'il a connu un tel succès avant qu'il a déjà une base solide de fans.

Mon intuition est qu'on n'arrivera à trouver de consensus et de plus en plus de licences « libres » (du genre de celles que tu indiques, ainsi que de celles que tu estimes vraiment libres) que lorsque suffisamment de gros acteurs en auront marre de l'attitude « rapace » des maisons de disque, et iront de plus en plus court-circuiter les maisons de disque. Cela aura aussi pour effet (selon moi) d'affaiblir grandement les sociétés d'auteurs tels la SACEM, la RIAA, etc. Cela dit, marchera sans doute pour la musique, mais pas forcément pour les films. Tout simplement parce qu'un musicien pourra toujours se faire des sous en faisant des concerts, alors qu'un film, une fois tourné, c'est difficile de le revendre aux mêmes gens. ;-)

[…] aujourd'hui, qu'est-ce qui te dit que la culture ne fonctionne pas différemment ? Qu'est-ce qui te dit que d'avoir une culture qui va à cent à l'heure, avec une majorité d'œuvres éphémères, ne devrait pas être la norme de demain ?

Rien, bien entendu. Mais qu'est-ce qui te dit que ça va arriver ? Je pense qu'une partie de la culture va effectivement aller vers l'éphémère. Je pense aussi que nous allons de plus en plus développer des filtres et des « méthodologies » pour filtrer ce qu'on trouve sur le net, et qu'on finira par stabiliser ce genre de culture. Dans tous les cas, nous n'y sommes pas pour le moment, et je doute très fortement que la notion de « classique » va disparaitre de de sitôt.

Pas d'accord. Personne ne lit les EULA etc. justement parce que c'est un merdier incroyable.

Et pourtant les EULA existent. Ce n'est pas une raison. Ce n'est pas parce que 99% des gens font les cons qu'on doit les soutenir dans leur connerie.

Non, pas d'accord du tout. Je suis pour la « piraterie » ( ;-) ) parce que justement, les gros industriels profitent de leur poids et de leurs amitiés avec nos représentants pour imposer tout un tas de restrictions sur ce qu'un individu peut faire d'une œuvre (artistique ou autre). Pour moi l'EULA est l'archétype de la technocratie : seules les élites peuvent comprendre de quoi ça parle. De plus, j'aimerais que tu évites de traiter mon père de con. Ou ma mère. Ou ma sœur en fait. Bref, toute personne qui a autre chose à foutre que lire, en détails (car c'est là que le diable se cache) des documents légaux à chaque fois qu'ils essaient d'installer un soft. Oui, la GPL aussi est un document légal, etc. Voici la grosse différence : la GPL est (grosso modo) la même pour tous les utilisateurs finaux, et une fois que tu l'as lue une fois, il suffit de lire la première ligne qui dit « ceci est un soft GPL » pour savoir de quoi parle le texte qui suit, et décider de cliquer « OK » ou « annuler ». Avec les EULA, on force chaque utilisateur à lire individuellement chaque licence car chaque éditeur logiciel remplit un patron avec des subtilités.

Si les utilisateurs sont si cons, je suppose que tu lis absolument TOUS tes contrats. Je suppose aussi que tu sais quelles sont les conséquences de chacune des clauses de chacun des contrats que tu as lus. Et le tout, sans avocat. Car tu n'es pas con, toi.

À ce moment-là autant dire aussi que ça ne sert à rien d'avoir une culture libre, puisque la plupart des gens partagent et remixent la culture sans se soucier de savoir si elle est libre ou pas.

Bah pour moi c'est un peu l'objectif de la « limite à dix ans » : 10 ans après publication, on élève une œuvre artistique dans le domaine public et du coup il est naturel de l'étudier, la modifier ou la partager. :-)

En passant on se rend compte que la grande majorité des auteurs, même les plus petits, prennent la peine de rajouter ce logo, preuve qu'il sont capables de faire un minimum d'effort intellectuel pour spécifier leurs conditions quand ils ont envie.

Oui, parce que rajouter © Machin prend à peu près 2 secondes. C'est un garde-fou pour éviter des abus sur ce que tu produis. Si plus d'artistes étaient au courant des différentes licences CC au point que creative commons devienne quelque chose qui sorte du milieu des « spécialistes », alors je pense qu'on verrait fleurir bien plus de CC-BY-SA-NC ou autres. Et c'est ce que je disais avant : on ne se poserait plus trop la question de « libre » ou « paslibre » : on aurait une méthode facile et reconnue par tout le monde de comprendre ce qu'on a le droit de faire avec une œuvre. Le vocabulaire deviendrait « le vocabulaire CC ».

Pour un partisan d'une forme d'élitisme culturel, c'est un peu paradoxal. On peut perdre beaucoup si on se rabat sur du premier degré. M'enfin j'arrête là la drosophilie.

Je ne pense pas être partisan d'une quelconque élite culturelle. Je pense sincèrement que toute œuvre devrait être libérée le plus tôt possible, tout en laissant malgré tout la possibilité au créateur originel de tenter de faire du fric au passage. Et à ma connaissance, dans beaucoup de cas, le seul moyen est tout de même de verrouiller un peu plus pour une durée (très) limitée les droits de ces œuvres.

Sur ce, je demande officiellement pardon aux mouches.

Ah et tant que j'y suis, je regardais un peu plus loin, et je suis tombé sur ceci. Je cite :

Que signifie donc ‘almâ ? Un dictionnaire de l’hébreu biblique, paru récemment en Israël³, attribue à ce mot le sens de « femme jeune ». D’après ce lexique, le terme pourrait revêtir deuxacceptions. Dans un premier cas, plutôt rare, il s’appliquerait à une « fille célibataire », valeurqu’un seul exemple viendrait confirmer, celui de Gn 24,43. Plus fréquente, une seconde acception,celle de « femme jeune non vierge », serait reflétée par trois occurrences : Pr 30,19, qui décrit le« chemin de l’homme dans une ‘almâ », dans le mystère de l’union sexuelle; Ct 6,8 qui mentionneles « innombrables » ‘alāmôt du harem du roi Salomon et, en dernier lieu, Is 7,14.

Cette courte notice du Milon ha‘ivrit hammiqra’it reflète la doxa actuelle sur le sens du mothébreu : référant à une jeune femme, le nom ‘almâ ne saurait impliquer par lui-même l’idée de virginité.

… Bon ensuite, le monsieur explique que malgré tout, les linguistes ne sont pas d'accord sur la signification des mots hébreux qui ont ensuite été traduits en grec (et menés à parthenos si j'ai bien tout suivi — c'est là que j'avais fait une erreur dans le commentaire auquel tu répondais, ce n'est pas « parthenos » qui était en cause, mais le fait d'avoir traduit le mot hébreu vers parthenos).

Bon du coup je suis allé faire un coup de « traduction de parthenos grec ancien français » sur google.

Ce qui est rigolo, c'est qu'on tombe, bien sûr, sur le wiktionaire. On tombe aussi sur parthénogénèse, qui reprend le lien que tu cites, mais qui, lui, spécifie « vierge, jeune fille » comme traduction. Oui, je chipote. Oui, ils veulent très probablement signifier « vierge ET jeune fille ». N'empêche, le wiktionnaire n'est pas tout à fait cohérent avec lui-même. Du coup il va falloir que j'aille voir ailleurs pour me convaincre.

Marche pas avec mon KDE. Alors que la touche compose est activable sous KDE et Gnome/XFCE super facilement… Ou bien sous X11 avec la bonne option. En plus, comme on le disait plus haut, la plupart des caractères spéciaux sont placés logiquement : ® est obtenu en effectuant la séquence (« compose un cercle et un r »). Mettre un nombre en exposant ? ou .

Donc oui, il est assez simple de retrouver ses petits avec la touche compose. Et au final, je pense que je tape à peu près aussi vite en Français avec mon qwerty+compose qu'avec mon vieil azerty (car mes doigts ont moins de chemin à parcourir).