beagf a écrit 763 commentaires

L'objectif est de prouver que tu n'as pas modifier un document entre «t» et «t+1», c'est tout. C'est un peu un principe d'enveloppe scellée, tu peux prouver que tu possedais un document à un instant dans le passé.

On peu faire un système de vente en aveugle comme ça :
- chaque personne intéressée écris un document avec son offre et publie le md5 ;
- quand tout le monde à publié son md5 on publie les documents.

Comme ça personne ne peut modifier son offre après l'avoir déposée, et personne ne connait l'offre des autres avant de poster la sienne. Et tout ça sans tier de confiance.

En effet, il n'y a pas le même niveau d'abstraction par rapport au formes de GC les plus communes.

Mais, tous les GC ne sont pas globaux, il y a beaucoup de cas où le GC ne gère qu'une partie de la mémoire, et dans ces cas là, l'utilisation ressemble énormément au smart pointers.

Un premier exemple : j'ai bossé avec un DSL où la majorité des types sont atomiques et les objets sont par défaut non-managés et utilisés par référence. Lorsque tu n'as plus besoin d'un objet tu fais un "delete(monobjet)" dessus et la référence deviens un atome représentant un pointeur invalide.
Ce DSL possède en plus un GC utilisé principalement pour les objets qui ont une longue durée de vie où qui passent d'un thread à l'autre. Dans ce cas, tu fais un appel "gc.manage(monobjet)" et tu n'as plus besoin de t'occuper du "delete(monobjet)".
On a bien un GC, de type mark-and-sweep dans ce cas là, qui s'utilise comme un smart pointer et c'est relativement courant comme système.

Deuxième exemple : Le Boehm-GC est un GC pour le C de type mark-and-sweep lui aussi et qui lui aussi ne va manager que la mémoire que tu lui demandes de manager.
Le cas d'utilisation typique c'est, si tu dois allouer de grosses quantités de mémoire qui ne peuvent contenir de références et dont la durée de vie correspond à celle du programme. C'est loin d'être un cas rare : une base de donnée en lecture seule, ou un modèle pour du calcul numérique. Dans ce cas, tu ne manage pas cette mémoire car sa durée de vie est bien connue et tu ne veux pas que le GC perde du temps à scanner cette mémoire à la recherche de référence qui n'y seront pas.

Il n'y a que dans les langages qui intègrent complètement le GC et où tous les objets sont managés que le GC est vraiment plus abstrait que le smart_pointer. En quantité de code qui tourne, ça représente largement la majorité rien qu'avec Java et la majorité des langages de script. Par contre en nombre d'implémentation de GC, je ne suis pas sur que ce soit le cas le plus courant.

Au final un long thread juste à cause d'une correction d'une petite erreur...

Mais, ce n'est pas grave, tu as raison et j'ai tord (et je m'en contretape).

sauf que mon objectif n'est pas d'avoir raison mais que l'on ce comprenne.

Je donne au verbe "alloué" le sens de "réservation de mémoire". De la mémoire qui peut être sur le tas, dans la pile, ou même dans un registre. Quand tu déclare une variable ou un objet, tu as une allocation, de même si tu fais un appel à malloc ou a new.

Mais dans tous les cas, l'allocation n'est pas ici l'élément pertinent. Ce qui est pertinent c'est que tu as au départ un pointeur, et que tu enveloppe ce pointeur dans une classe *_ptr pour ne pas avoir à te soucier de le libérer manuellement.
Dans ce cas, ta classe *_ptr réalise exactement la même chose qu'un GC, détecter quand le pointeur n'est plus utilisé et le signaler au gestionnaire de mémoire.

Quand tu crées un *_ptr, tu ne fais que signaler que l'objet doit être manager.
Dans un langage à GC, quand un objet est créé, il est de même signalé au GC.
-> La seule différence est que dans le cas d'un langage à GC c'est fais implicitement car tous les objets sont managés.

Quand il n'y a plus de références, le destructeur du *_ptr va appeler un éventuel finaliseur puis signaler au gestionnaire mémoire que le pointeur peut-être libéré.
Dans un langage à GC, quand il n'y a plus de références, le GC va appeler un éventuel finaliseur puis signaler au gestionnaire de mémoire que le pointeur peut-être libéré.
-> Aucune différences à part le fait que certains GC ne supportent pas les finaliseurs.

Donc, je ne comprend pas ou tu vois une différence entre les *_ptr et un GC. Les *_ptr sont des GC qui ne managent qu'une partie des objets et qui imposent la présence de finaliseurs. Leur définition fais que tous les algorithmes de GC ne peuvent être utilisés simplement, mais ça reste un GC.

• Un GC, maintenant, sait gérer tout seul les cycles ; à contrario des pointeurs à comptage de référence, avec lesquels il faut s'aider de weak_ptr ou assimilé

Un GC par comptage de référence de base non plus ne sait pas gérer les cycle, et c'est aussi le cas d'autres algorithmes. On pourrait très bien ajouter cette fonctionnalité aux smart-pointers, mais vu leur cadre d'utilisation ce ne serait pas très utile.

• Un GC ne finalise (comprendre: "détruit") pas l'objet pointé à contrario de tous les smart-pointers du C++.

Les smart pointer non-plus ne finalisent pas les objets, ils font comme le GC : quand un objet n'est plus référencé, ils le signalent au gestionnaire de mémoire qui va s'occuper de la libération.

• Tous les smart pointers ne sont pas à comptage de référence. La veille définition, c'est qu'un pointeur non brut/nu est smart/intelligent. Ainsi std::auto_ptr est un smart-pointer, tout comme boost::scoped_ptr, ou std::unique_ptr. [J'ai un peu de mal à voir pourquoi ces pinaillages autour des compteurs du coup]

Tous les GC ne sont pas non-plus à comptage de référence, on ne parlait du compteur que pour illustrer le fait qu'il y a bien une enveloppe créé autour du pointeur.

• Les *_ptr<> de boost (et de C++11) peuvent encapsuler autre chose que de la mémoire, et ça c'est classe: nous avons ainsi des scoped_guard. Un GC ? Même pas en rêve. Il ne connait que la mémoire.

La majorité des GC te permet de le faire. Quasiment tous les GC permettent de spécifier un "destructeur" pour les objets : une fonction à appeler sur l'objet avant de le libérer quand il n'est plus référencé.
Donc, la classe *_ptr correspond à l'enveloppe du GC, le pointeur stocké dedans correspond à l'objet managé, et le destructeur à le même rôle dans les deux cas.

• Après je me souviens de discussions sur fclc++ ou clc++m où un avantage était prêté aux GC : le MT car ils n'utilisaient pas de compteurs atomiques.

C'est juste que tels qu'ils sont définis, l'implémentation des *_ptr rend difficile l'utilisation d'algorithme de GC autres que les algorithme on-time de type comptage de références.
Le problème est que vu que tous les objets ne sont pas managé et les références ne peuvent être trouvées par exploration des objets, on ne peut pas vraiment faire autrement que d'intercepter la création et libération des références.

Sauf que...

1) Le compteur de référence est stocké dans la coquille par une indirection, en gros tu as un pointeur vers le compteur. Ça simplifie pas mal de choses, mais au final il y a bien toujours une coquille... Et la différence entre allouer un compteur ou un pointeur...

2) On s'en contretape de ce qui est alloué au final: la seule chose qui compte dans la discussion en cours c'est qu'il y a bien un coquille de construite autour de ton pointeur, ce qui implique que le smart pointer ce comporte exactement de la même manière qu'un GC.

3) On s'en contretape même qu'il y ait une allocation ou pas, ce qui est important c'est que tu viens une fois de plus de donner des arguments qui prouvent que tu avais tord.

J'hésite entre deux opinions :
- soit tu ne comprends vraiment pas et dans ce cas je te conseil de relire le thread depuis ton post qui à déclencher ma première réponses ;
- soit tu as compris que tu avais tord mais tu ne veux pas l'admettre, et dans ce cas la ça explique pourquoi tu continues de parler de truc qui n'ont rien à voir à ma remarque initiale.

Si on regarde l'innovation côté Steve Jobs, il y a quand même NeXTStep qui était particulièrement innovant, et qui est maintenant à la base de MacOS.

Dans une interview, à la remarque "la machine NeXT va sortir avec 6 mois de retard", Steve Jobs à repondu "Qu'est-ce que 6 mois de retard quand on à dix ans d'avance". La réponse est à la foi jolie et pas vraiment fausse.

Reste à espérer que Apple n'ait pas dix ans d'avance en ce qui concerne l'enfermement de l'utilisateur...

Sauf que le pointeur qui est gérer par cette allocation n'est pas sur la pile lui. (sinon il n'y aurait pas besoin d'un smart-pointer)

Donc pour recentrer la discution sur le point de départ une fois de plus : ma remarques de départ indiquait juste qu'un smart pointer et un GC interviennent de la même façon au moment ou l'objet deviens managé.

Que les données servant à ce que la mémoire soit manager soit sur la pile, dans le tas, ou sur mars, ne change rien au fait qu'ils ont le même comportement, contrairement à ce que disait LupusMic.

Je pense que la confusion viens justement de ce problème de mémoire et d'allocation. Il faut bien séparer deux chose ici : la mémoire pointée et la coquille. Les deux doivent être alloué pour que tout ce passe bien.
Dans le cas du smart pointer, la mémoire pointé est alloué par l'utilisateur, et la coquille implicitement par la classe smart pointer.
Dans le cas du GC, c'est la même chose : le compilateur alloue la mémoire pour l'objet demandé par l'utilisateur et ensuite informe le GC de cette zone de mémoire pour qu'il mette en place sa coquille autour.

Dans le cas du smart pointer, le compilateur est en général suffisament intelligent pour supprimer l'indirection de pointeur et juste alloué un compteur sur la pile ou le tas suivant le type de smart pointer.

Dans le cas du GC, vu que les chose sont plus complexe, on prévoit le coup avant et on bouge les infos du GC directement dans l'objet. Mais, ce n'est pas le GC qui va alloué la mémoire pointée.

Si on veut simplifier, dans les deux cas l'utilisateur fait l'appel à malloc (pour ces données) et demande au GC de ce charger de l'appel à free.

Tu relis mon commentaire puis le tiens et tu verras que tu viens de confirmer ce que j'ai dis...

La classe boost::shared_pointer c'est quoi ? Une coquille autour de ton pointeur... Et cette coquille est faite justement pour pouvoir enregistrer les nouvelles références et leur disparitions afin de libérer la ressource quand elle n'est plus utilisée.

Et avec ce modèle, on n'est pas obligé d'allouer le compteur dans le constructeur par défaut, parce que cela ne sert a rien.

Il y a deux cas possibles :
- soit tu permet de changer la valeur du pointeur encapsulé, et dans ce cas il vaux mieux que ton compteur soit alloué des le début sinon tu vas avoir du mal à le rajouter plus tard ;
- soit tu ne permet pas de changer la valeur du pointeur et dans ce cas tu retombes à nouveau dans le même cas qu'un GC : lui non plus ne met rien autour des "atom" car il n'y a pas de libération à gérer.

Donc, on en reviens toujours au fait qu'un smart pointeur fait la même chose qu'un GC.

Tu fais exprès de ne pas comprendre ?

Un smart pointer est un objet qui encapsule un pointeur, il y a donc bien une allocation de l'objet qui encapsule. Tu peux mettre ce que tu veux comme pointeur dedans, qu'il soit valide ou invalide ne change rien au fais qu'il y a bien allocation d'une coquille pour stocker le pointeur et son compteur de références.

Et pour revenir à ta remarque de départ c'est exactement ce que fais un GC : une nouvelle ressource est allouée et signalée au GC, lequel va placer la ressource dans une enveloppe avec les infos dont il a besoin pour pouvoir libérer la ressource quand ce sera nécessaire.

La seule différence est que souvent le GC va gérer tous les objets qui peuvent être alloués donc plutôt que d'avoir une enveloppe explicite, elle est implicite, c'est-à-dire que les objets intègrent eux-même les informations du GC afin d'éviter l'indirection et la surcharge en mémoire.
Et dans le cas des smart-pointers c'est la même chose car avec une bonne libc++ et un bon compilateur l'enveloppe en question est réduite à un compteur de référence avec un binding implicite au pointeur.

Donc, pour reprendre ton commentaire initial :
>Un GC gère l'allocation et la désallocation coordonnée d'objets.
>Un RIAA ne gère que la libération d'une ressource.
Soit tu ne considère pas que l'allocation de la coquille fais partie de l'allocation de l'objet, et donc ta première phrase est fausse ; soit tu considère qu'elle en fais partie, et dans ce cas c'est la deuxième qui est fausse.

Un GC et un smart pointer font la même chose : enregistrer l'existence d'une ressource et la libérer quand elle n'est plus nécessaire.

Si, il va allouer quelque chose : un objet (au sens général du terme) qui est managé et qui gère les accès à ton int.

Il faut bien comprendre qu'un smart pointer est une enveloppe autour d'un pointer, et que ce qui est gérer automatiquement c'est cette enveloppe. Elle à pour but de détecter à quel moment son contenu n'est plus utiliser et d'effectuer une action sur le contenu à ce moment là.
C'est exactement le même principe qu'un GC. Si tu veux te convaincre qu'il va bien y avoir une allocation, il suffit de ce demander ou va être stocker le compteur de référence.

Et le rapport avec la choucroute, ce n'est pas un problème du GC mais du destructeur qui n'est pas approprié à la gestion automatique de la mémoire ?

Sans compter que les exemples que tu donnes ne sont en rien spécifique à Windows mais sont présent quels que soit l'OS. Un socket, tant qu'il n'a pas été fermé, il reste ouvert... C'est même pour cela que sur les systèmes à GC, il y a une méthode pour les fermer explicitement à un instant donné sans attendre que le destructeur soit appelé par le GC.

Dans beaucoup de cas, le GC fera très bien sont boulot sur ces cas là aussi, il n'y a que lorsque tu dois ouvrir beaucoup de ressources et que le nombre de ressource pouvant être ouvertes à un instant donné est limité que cela pose problème.

Non, un GC gère la libération lui aussi. Il doit détecter quand un objet n'est plus utilisé et le libérer. (éventuellement avec un décalage) Par contre, pour faire cela il a souvent besoin de la coopération du code responsable de l'allocation (et des copies, ...) tout comme un smart pointer.
Le constructeur du smart pointer peut très bien être vu comme l'allocation de la ressource, c'est un moyen de signaler qu'un pointeur doit être gérer et un moyen d'être tenu au courant des nouvelle références sur ce pointeur.

Il est tout à fait possible même si c'est stupide d'implémenter les smart pointer avec n'importe quel algo de GC.

Le truc c'est qu'il faut comparer ce qui est comparable. Si tu remplaces un GC complet par des smart pointers tu vas clairement perdre en performances.

Les smart pointers ne sont absolument pas fait pour gérer tous les pointeurs d'un programme à la manière d'un langage à GC. Ils servent à gérer les quelques pointeurs au sein de l'application ou c'est pratique. Plus la proportion de pointeurs que tu veux gérer de cette manière est grande, moins les perfs seront compétitives.

Le C++ est un langage fait pour la gestion manuelle de la mémoire avec des outils pour qu'elle soit automatique de temps en temps, et dans ce cas les smart pointeurs sont beaucoup plus efficace car cela donne un outils simple et efficace beaucoup moins lourd qu'un GC complet.
Si tu utilise de manière systématique les smart pointers, le problème est plus que le langage choisit n'est pas le bon.

Pour ce qui est de la latence, les algos incrémentaux sont intéressant, mais ils viennent avec un prix : ils sont très complexes à mettre en œuvre, ils demandent beaucoup de coordination avec le runtime, et beaucoup de tuning de paramètres pour être vraiment efficaces. Un petit changement anodin peu faire tout écrouler.

Pour la défragmentation dans linux, je ne suis jamais aller voir ce qui ce faisait exactement, mais on est dans le cas d'une tâche bien définie ou typiquement la fréquence d'utilisation des objets est très grande et ou la collection est peu fréquente. Si tu as besoin de quelques huges pages, ton algo ne va tourner que le temps d'avoir ces pages et jamais faire de cycle complet.
Dans un cas comme celui là, tu peux généralement choisir des algos à priori complexes mais qui en fait deviennent très simple car il n'y a qu'un seul type d'objets avec un comportement extrêmement simple.

Reprend mon premier commentaire et tu y verras :
>Le comptage de référence est loin d'être mauvais et est même parfais dans certains cas. C'est juste qu'il n'est adapté que à certains cas d'utilisation et pas au cas général.
Je précise bien "pas au cas général". Par contre, dans le cas d'utilisation courant des smart pointers, c'est parfait.

Je répondais surtout à la critique contre le comptage des référence qui serait "le degré zéro" des GCs avec des performances pourries.
Ce n'est pas le cas, et il y a de nombreuses situations ou un simple comptage de référence est beaucoup plus efficace, simple à implémenter et souvent moins buggué que n'importe quel autre type de GC.

Pour continuer sur les différents GCs :

Pour ce qui est des opérations à chaque affectations, n'importe quel compilateur pas trop con va te permettre d'en supprimer une grande partie, et au final il n'en reste pas forcément tant que cela. Et tu as l'avantage que tu n'as jamais besoin de stopper tous tes threads afin de faire tourner ton GC une fois de temps en temps.

Que ton GC soit générationel ou pas ne change rien, l'aspect générationel ne va te permettre que de réduire la liste des objets à parcourir lors d'un cycle de GC, mais tu devra quand même tout stopper pour le faire. Si ton GC est capable de ne pas stopper le monde pendant qu'il tourne, alors il va nécessiter lui aussi des opérations pendant les affectations.

Ce qui rend le comptage de référence peu intéressant dans le cas général c'est que pour ne pas avoir trop d'opérations à faire à chaque affectation et à chaque fin de bloc, il est nécessaire de complexifier le compilateur et de le rendre plus intelligent sur ces éléments. Pour peu que tu ne sois pas dans un cas ou les cycles peuvent être évités ou détecter simplement, il faut aussi les prendre en compte.
Au final, le risque est d'avoir une implémentation aussi complexe qu'un autre GC mais en plus très liées au cœur du compilateur ce qui la rend encore plus complexe. Alors qu'un GC de type mark-and-sweep sera indépendant et donc plus simple à debugger.

Si tu peut te permettre des petites pause de temps en temps, il n'y a pas de problèmes avec d'autres formes de GC. Ce n'est pas pour rien qu'il y a autant de recherche sur les différentes manières de réduire le temps de pause à chaque déclenchement.

J'ai bossé sur DSL ou le comptage de références était vraiment l'algo optimal. Les structures de données disponibles rendaient les cycles très simple à détecter, les manipulations sur les objets ce prêtaient bien au comptage, par contre les contraintes de timing ne permettaient pas de stopper tous les threads de manière aléatoire. Le mec qui à essayer de remplacer mon GC par un truc plus évolué n'a jamais réussi à tenir les contraintes.

En conclusion :

Il ne faut pas utiliser bêtement le comptage de référence mais il faut pas cracher dessus non-plus. Il est adapté à certains cas, et c'est notamment souvent le cas quand on utilise les smart pointers.

Sauf que les processeurs modernes sont tous pipeliné, donc entre le moment ou la valeur est lue et le moment ou elle est écrite il se passe plusieurs cycles même si elle est indiquée s'exécuter en un seul cycle.
Donc même avec deux cœur sur un seul processeur, tu peux avoir des problèmes

thread 1       | thread 2
lecture val    | ...
incrementation | lecture val
ecriture val   | incrementation
...            | ecriture val

Ton opération n'est pas atomique si tu ne met pas le préfixe lock qui va blocker toutes les lectures de la valeur sur tous les processeurs.

Oui, mais non :-)

Tout d'abords cet article s'applique au code kernel ou tu dispose de primitive de synchro bas niveau. Pour du code portable, dans le cas de l'attente active dont il parle par exemple, un accès volatile est plus portable.

Ensuite, même si tu dispose de ces primitives, il y a pas mal de cas ou il est préférable d'utiliser volatile. Toutes les primitives en question vont placer une "full memory barier" ce qui oblige le compilateur à bloquer toutes les optimisation en avant et en après. Une variable volatile ne bloque les optimisations que pour cette variable, ce qui peut-etre très utile dans le cas ou tu n'as pas besoin d'un lock.

Par exemple, dans le cas d'une table de hashage (presque) lock-less, un thread qui écris une valeur doit mettre à jour deux case mémoires. Un thread qui veux lire cette valeur, doit faire une attente active sur la deuxième au cas ou le premier thread ai été interrompu entre les deux écritures. Un accès volatile est beaucoup moins couteux que la solution proposée.

Non, mais c'est lié. Une variable volatile permet de s'assurer que le compilateur ne va pas garder la variable dans un registre mais la relire à chaque accès. Par contre pour un accès donné, il faut quand même passer par un registre à un moment donné.

Par exemple, si x est une variable volatile et que tu as le code :

x = x + 1;
x = x + 1;

Le compilateur va charger x dans un registre, l'incrémenter et le sauvegarder en mémoire, puis recommencer. Si la variable n'est pas volatile, il va la charger une seule fois, l'incrémenter deux fois (une fois en fait, mais de deux...) puis la sauvegarder.

Donc si un autre thread modifie la variable entre la sauvegarde et le deuxième chargement, il n'y a pas de problème, par contre si le thread est interrompu pendant l'incrémentation cela merde quand même. Il faut une opération atomique pour éviter le problème.

Pas de bol, ça reste généralement plus efficace que beaucoup d'autres méthodes.

Avec un GC stop-the-world du style mark-and-sweep, tu dois stopper tous les threads à chaque fois que le collecteur ce met en route, au final c'est pas forcément mieux. De plus, la grosse majorité des objets ne changent pas de threads, donc avec un refcount, tu ne passe au opération atomiques que pour une partie des objets. Avec un stop-the-world, tu stop toujours tout le monde.

Avec un GC on-the-flow ou incrémental tu te tapes aussi des opérations atomiques et pour certains elles sont même plus lourdes que pour le refcount.

Bref, le refcount reste un bon algol de GC qu'il faut toujours considérer avant de s'engager dans des choses plus compliquées, même dans le cas du multi-threading.

Va falloir que tu revois tes standards. Le comptage de référence est loin d'être mauvais et est même parfais dans certains cas. C'est juste qu'il n'est adapté que à certains cas d'utilisation et pas au cas général.

Il a deux inconvénients :
- de base il ne gère pas les boucles de dépendances, mais il y a moyens de contourner ce problème, et dans certains cas on peut même garantir que cela ne ce produira pas ;
- il y peu déclencher des libérations en chaine qui font qu'une simple libération peut au final prendre beaucoup de temps.

Le deuxième inconvénient qui est généralement le plus sérieux, ne correspond au final qu'au cas standard ou la mémoire est libérée explicitement. De plus la grande majorité des algorithmes de GC fonctionne en "stop the world" et on donc exactement le même problème avec en plus le fait que la pause peut ce produire n'importe quand.

Les quelques algos qui contournent ce problème sont très complexes et donc quand on peut s'en passer et les remplacer par un comptage de référence qui s'implémente très simplement, pourquoi ce privé ?

Le comptage de référence, s'il est bien fait c'est-à-dire si le comptage est automatique et que les cycle sont gérés en cas de besoin, permet bien souvent d'avoir un GC beaucoup plus simple et tout aussi efficace, et surtout beaucoup moins buggé.

Je ne sais pas pour vous, mais personnellement, je préfère de très loin un système qui marche bien tout seul qu'un système ou je suis obligé de lire des tonnes de docs.

J'ai rien contre lire de la doc mais j'en lis déjà suffisamment pour mon boulot, donc si je peut ne pas avoir à en lire pour que mon poste de travail marche, c'est beaucoup mieux.

MacVim est tout récent, mais il est moins bien que gvim ou vim dans un bon terminal. À une époque, j'utilisais SubEthaEdit et TextMate, tout les deux propriétaires.

MacVim n'est pas tout récent, le projet à commencé en juillet 2004, et les première version réellement utilisable datent d'un an plus tard.

Mais surtout, qu'est-ce que tu trouve de plus utilisable dans un gvim ou un vim dans un terminal ? MacVim ne change que la partie graphique de vim et à part quelques racourçis supplémentaire qui se suppriment éventuellement avec 2 lignes dans ton vimrc, tu obtiens exactement la même chose que gvim sous linux.

Sauf que aucun des trois que tu cites ne remplace OmniGraffle Pro.

Ce n'est pas une critique et je ne vais pas faire la liste des trucs qu'il à en plus ; ni celles de ce qui lui manquent par rapport à ce que tu proposes, mais globalement :

yEd et Dia sont des logiciel destiné à faire des diagrammes et même s'il y a quelques possibilité de plus, c'est particulièrement inutilisable des que tu sort de ce cadre d'utilisation.
Inkscape c'est l'inverse, c'est prévu pour faire du dessein vectoriel et tous les trucs sympa qui facilitent la vie quand on fait des diagrammes ne sont pas disponibles.

OmniGraffle est vraiment sur un créneau intermédiaire entre les deux et qui — pour mon utilisation en tout cas — permettent de faire des choses très rapidement avec un rendu visuel superbe.
Et sur ce créneau je ne connais aucun logiciel libre qui puisse le remplacer.

Tu crées un compte juste pour l'occasion et pourtant tu dois surement fréquenter un minimum LinuxFR pour connaître ce journal ? Qui donc ce cache sous ce compte ? Qui donc n'assume pas ?
Quel est l'objectif de ce journal à part un pseudo apitoiement sur eux-même des défenseurs de Lisaac qui n'ont pas changés depuis ce journal ?

Tu aurais du relire un peu plus attentivement le journal que tu pointes et tu aurais vu ce message que j'avais écris à l'époque et qui hélas est toujours d'actualité http://linuxfr.org/nodes/55397/comments/1087066 .

Personnellement je viens de perdre du temps à le relire et je n'en reviens pas de la patience que j'ai eu tout comme d'autres.

Donc, je vais peut-être me faire moinser mais j'assume : pour moi, Lisaac est associé à gros tas de merde à ne surtout jamais approcher à nouveau. Vu que la communauté autour ne semble pas vouloir évoluer vers un peu plus d'ouverture d'esprit je ne vois pas pourquoi je continuerais de faire des efforts.
Moi aussi je peut jouer à qui est le plus con et je suis très fort à ceux jeux là et si Lisaac meurt réellement ne comptez pas sur moi pour verser une larme.

Ton lien ne change rien mais il représente bien le fond du problème. Comme tout le monde je pense, j'ai parfaitement compris ce que tu penses quand tu utilises le mot libre pour de la musique.

Le problème est qu'actuellement il n'y a absolument aucun consensus sur ce qu'est une œuvre libre et il n'y aucune raison de penser que tu as plus raison qu'un autre, ou de penser que la définition que tu pointes est la bonne.

Pour le logiciel, le mot libre est maintenant compris par tout le monde comme désignant les 4 libertés de Stallman et quand quelqu'un l'utilise différemment c'est généralement de la mauvaise foi. Mais si Stallman avais ajouté à sa liste un truc du style du copyleft qui impose de redistribuer selon les même conditions, tu peux être sûr que tous les BSDistes ne ce seraient pas rangés derrière sa définition.

Tant qu'il n'y aura pas une définition qui fait consensus, il n'est pas possible d'utiliser le terme libre sans préciser un minimum, et surtout, on ne peut pas ce permettre de critiquer comme tu le fais les choix des autres.
Jamendo indique clairement que pour eux le terme libre désigne globalement ce qui est permis par les CC, donc tu ne peux pas critiquer le fait qu'ils soient cohérents avec eux-même.

Il y a du bon et du moins bon dans ton journal, de bonnes idées et des mauvaises. Je suis d'accord avec une partie de ce que tu dis mais il y a quand même une énorme erreur dans ce que tu dis qu'un grand nombre de « libristes » font :

Le mot « libre » n'appartient pas au monde du logiciel libre et tu ne peux pas imposer ta définition ou celle de Stallman ou celle des BSDistes au reste du monde. La seule chose que tu puisses faire est de demander un minimum de cohérence dans le cadre du logiciel du style demander que l'on ne parle pas de logiciel libre pour un logiciel dont on ne dispose pas du code, en argumentant sur le fait que le terme à été introduit dans ce contexte avec une idée bien précise et qu'elle est largement acceptée.

Pour de la musique, des photos, du PQ ou des tomates... tu ne peux certainement pas imposer ta définition du mots libre. (qui ne correspond pas à celle du dictionnaire)
Ma voisine à beau être libre et le revendiquer, je suis à peu près sûr qu'elle ne veux pas être redistribuée ou modifiée par n'importe qui.