rewind a écrit 3425 commentaires

Son analyse est plutôt bonnes quand il dit qu'on n'a fait que reculer et que les rares pas en avant ont été suivis par de nombreux pas en arrière. Maintenant, je trouve ses propositions un peu molles. Molles pas dans le sens où elles ne vont pas assez loin (quoique pour certaines, c'est le cas) mais molles parce qu'elles partent dans tous les sens et qu'elles n'ont aucune cohérence (voir les digressions sur les logiciels ou les architectes au détour des propositions). Il n'y a pas de vision globale et de direction majeure.

Ma petite analyse des points :
1. Un changement de mot ne va rien changer, c'est à peu près le même débat que DRM vs MTP. Ceci dit, je n'aime pas le terme "propriété intellectuelle" (sauf dans le sens où je suis propriétaire de mon cerveau).
2. Vaste débat que celui de juger la création comme ça a été dit dans d'autres commentaires. Est-ce qu'un recueil de poésie est plus ou moins créatif que la dernière bouse sorti de la Star Ac ? Je n'en suis pas si sûr. Avec sa définition, le logiciel se trouverait certainement exclus du champ du droit d'auteur. Le concept de création est très bien comme il est actuellement, je ne pense pas que ce soit le problème.
3. Voici la seule proposition qui soit à peu près sensée. Dans l'esprit du moins. Parce qu'après, les détails techniques sont confus. Je note aussi qu'il fait une analogie qu'on ne fait pas souvent, celui de la perception d'une rémunération comme un salaire et pas comme un capital. Parce que c'est souvent l'argument massue des gens qui trouvent normal que le fils de continue à percevoir le fruit du travail de ses aïeux : "c'est comme n'importe quel héritage". Et bien non ! On ne transmet pas son salaire à ces enfants mais juste son capital. Les artistes n'ont pas de salaires mais perçoivent ce qu'on appelle communément leur "droit d'auteur" (terme fort erroné en fait).
4. Détail jargonno-juridique inutile.
5. Il ne faut pas interdire de signer des traités comme ça, c'est idiot. Il faut tout simplement convaincre la majorité pour que des traités comme ça n'existe plus.
6. Mesure dangereuse ! Actuellement, on a des droits dès qu'on crée, même si c'est le journal intime de la petite soeur qu'elle cache sous son lit. Passer par un dépôt serait suicidaire. Parce que gérer un organisme de dépôt de ce genre va coûter et donc le dépôt risque de ne pas être gratuit. La justification d'une telle mesure est, à mon avis, totalement hors de propos. Les oeuvres orphelines sont vraiment excessivement rares. Et imposer une telle mesure pour des exceptions, ce n'est pas vraiment une bonne idée. De plus, ce concept de "tant que les ayants droits ne se manifestent pas", c'est un peu ambigu. Ils peuvent ne pas se manifester sciemment et ensuite, si ça marche, demander leur du. Ça crée une insécurité juridique nuisible. Ça rappelle les brevets et leurs abus.
7. Le domaine public existe déjà partout dans le monde. Pas besoin de le reconnaître plus qu'il ne l'est.
8. Le droit de citation existe (c'est une exception au droit d'auteur mais c'est reconnu). Le droit de copie privée est sur le même plan. En revanche, la deuxième partie est plus intéressante : taxe sur copie privée si ce droit est réellement applicable, oui.
9. Encore des exceptions. Ça ressemble à un mauvais patch.
10. L'État n'a pas à faire des choix de ce genre. L'intérêt majeur d'une oeuvre apparaît souvent bien après l'extinction des droits d'auteur. De plus, ça ouvre la porte à toutes sortes d'abus comme l'achat de droit d'un artiste proche du pouvoir.

Après avoir critiqué, je vais apporter ma petite pierre. Autant le copyright anglo-saxon est trop centré sur l'oeuvre et oublie complètement l'auteur (à part pour dire que c'est lui l'auteur), autant le droit d'auteur à la française est trop centré sur l'auteur : pourquoi les droits patrimoniaux s'éteignent-ils à une date fixé après la mort de l'auteur et pas après la publication de l'oeuvre ? Le droit d'auteur français a fait une très bonne séparation entre droits moraux (inaliénables et perpétuels) et les droits patrimoniaux (qu'on peut vendre et qui servent à vendre). Les droits patrimoniaux devraient être attachés à l'oeuvre puisqu'il concerne son exploitation commerciale. Comme c'est le cas pour les brevets. Il y a aussi la question des droits voisins, qu'est-ce qu'on en fait ?

Bref, je ne suis pas du tout convaincu par les mesures molles qui sont présentées. La propriété intellectuelle a besoin d'une contre-proposition, certes, mais qui doit être plus ambitieuse que ces mesures.

On aura beau troll^Wdire mais debian-legal a quand même une utilité avec tous ces acharnés qui lisent et relisent les licences dans tous les sens pour s'assurer que ça respecte les DFSG. Et moi, tant que Debian ne m'aura pas dit que les CC, saibien, j'éviterai d'utiliser les CC (enfin, les versions "libres", pas les version avec des NC ou des ND que je n'utiliserai jamais).

Ceci dit, il me semble qu'ils ont tout fait pour que les versions 3.0 (oui parce qu'il faut faire attention au numéro de version en plus des BY, SA, NC, ND), Debian a collaboré avec CC pour que ça rentre dans les DFSG. Donc, j'attends.

Dans la réforme de 1990, on peut même écrire "weekend".

Voir : http://www.orthographe-recommandee.info/comment.htm

Toute spirale n'est pas forcément un logo Debian

je vais répondre aux deux commentaires ci-dessus d'un seul coup.

Tout d'abord, comme dit PLuG, je suis dans un cas totalement similaire, sauf que s/SOAP/XML-RPC/ mais après, c'est la même chose.

Moi je ne suis pas un expert SQL, je veux juste faire des trucs ultra-simple, comme le permet JDBC. Après, je fais ma sauce du côté du Java. Et j'aimerais que mon code marche bien avec toutes les DB imaginables, en particuleir PostgreSQL. Alors ça revient un peu à dire qu'il faut se contenter du plus grand commun dénominateur entre toutes les bases (donc prendre les fonctionnalités de MySQL) mais bon, je ne veux pas utiliser JDBC qui permet d'abstraire la DB et ensuite faire du code SQL spécifique à une DB.

Ensuite, je suis d'accord, c'est pas forcément un problème au niveau PostgreSQL (et même je pense que le problème ne vient pas de là), mais il n'empêche que de nos jours, on utilise rarement une DB directement mais à partir d'API dans ce genre (il y a aussi PDO pour PHP, DBI pour Perl, etc) et qu'il faut également soigner l'implémentation de ces API, ça compte aussi dans l'adoption (c'était l'objet de mon premier post).

En toute honnêteté, j'aime bien PostgreSQL par rapport à MySQL, même si je ne l'ai jamais utilisé vraiment. Mais le fait que ça soit plus proche des standards, juste ça, ça me va. Parce qu'en MySQL, on ne sait jamais si on fait du vrai SQL ou du MySQLisme (pareil que les bashisme vis-à-vis du sh POSIX). Le support des transactions, le support de l'Unicode, le support des clefs étrangères, tout ça, c'est très bien et ça renforce mon opinion par rapport à PostgreSQL.

Seulement voilà, si on veut l'utiliser avec le driver JDBC [1], ben il manque des choses dont j'aimerais bien me servir. Et on voit sur la TODO liste [2] qu'il manque des trucs comme Statement.getGeneratedKeys qui est fort pratique. Ça donne l'impression que ce n'est pas encore tout à fait abouti. C'est dommage parce que je troquerais bien mon MySQL contre un PostgreSQL. J'ai lu les différents fils de discussion concernant cette fonctionnalité et je ne comprend pas bien les problèmes, pour moi il faut que cette fonction retourne la ou les clefs qui ont été générées par un INSERT, pas plus ni moins. Il n'y a peut-être pas le support dans PostgreSQL pour le faire mais ça serait vraiment une superbe fonctionnalité à ajouter.

[1] http://jdbc.postgresql.org/
[2] http://jdbc.postgresql.org/todo.html

> Les personnes visent de l'oeil droit ou gauche sans trop de rapport avec leur côté droitier ou gaucher (il me semble, mais je peux me tromper).

L'oeil directeur, c'est pas un choix, c'est physiologique. Pour le déterminer, c'est très facile, tu vises un truc au loin avec ton doigt les deux yeux ouverts et ensuite, tu fermes successivement les deux yeux, et normalement, y'a un des deux qui correspond au point visé et l'autre est en décalage.

Moi je suis droitier et mon oeil directeur est le gauche. Le jour où je l'ai découvert, je suis devenu bien meilleur à la fête foraine.

J'ai regardé vite fait dans les bug KDE et GNOME et j'ai vu :
http://bugzilla.gnome.org/show_bug.cgi?id=474419 pour Banshee
http://bugzilla.gnome.org/show_bug.cgi?id=494007 pour Empathy
http://bugzilla.gnome.org/show_bug.cgi?id=166643 pour GIMP

et rien sur KDE.

Est-on vraiment sûr que cette norme n'est pas utilisé par KDE et GNOME ? Surtout que c'est un gars de KDE qui l'a écrite apparemment alors ça m'étonne quand même...

Y'en a plusieurs que j'aime beaucoup, et elles sont mieux que libre, elles sont domaine publique. Tout d'abord le chant des oiseaux dans la forêt, puis le bruissement de l'eau sur les cailloux, puis le flonflon des vagues sur la plage... tout ceci est très agréable en charmante compagnie. Mais surtout, il y en a une que j'adore vraiment parfois : le silence !

pourquoi ne pas faire de bug report sur au moins les gros projets ou faire des liens vers les bug report existant visant à l'utilisation de XDG_CONFIG_HOME ? ça permettrait de pousser à l'adoption de ce standard et à terme de ne plus utiliser libetc (oui désolé, je veux la mort de ton projet :P)

Merci pour cette démonstration.

Je trouve la solution un peu bancale quand même, c'est du détournement de balises. Et à vrai dire, je préfèrerais nettement que les navigateurs implémentent la toute petite norme XInclude, ce serait nettement plus clair et plus simple.

Pour la compatibilité, la page wikipedia [1] dit qu'il y a compatibilité avec les outils ext3 si et seulement si ext4 n'utilise pas les extents, qui est maintenant une option activé par défaut.

Et dans l'autre sens, une partition ext3 pourra être vue comme une partition ext4.

Donc patrick_g ne dit pas n'importe quoi et la compatibilité dans les deux sens est bien une préoccupation des développeurs.

[1] http://en.wikipedia.org/wiki/Ext4

> Les autres vont se contenter de faire du HTML 5, plus digeste (et mieux validé qu'avant).

C'est ça que je ne comprends pas. Avoir voulu oublier la syntaxe SGML est probablement une très bonne décision. Et si j'ai bien compris, maintenant, il y a des règles de parsing défini dans la norme. Mais pourquoi ne pas avoir dit alors : le parsing se fera selon la norme XML ?

Non, là on a un truc bâtard entre la soupe de balise et le XML, genre "vous pouvez faire de la soupe de balise mais il faut quand même certaines règles", et pourquoi pas les règles XML ? elles sont si contraignantes que ça ? moi je ne crois pas, elles sont surtout très logique ! Allez dire à des gens : "bon des fois vous pouvez fermer vos balises mais c'est pas obligé et des fois vous devez le faire absolument sinon, ça foire", ils vont vous prendre pour un fou. Alors que dans le cas de XML : fermez vos balise, point, pas de discussion.

Enfin voilà, il faut m'expliquer l'intérêt d'une soupe de balise "mieux validée" mais pas XML.

1) je ne dis pas que la balise h est la panacée mais pour des gens qui ne veulent pas mettre des styles différents, c'est quand même utile et ça n'empêche pas d'utiliser h* pour des cas plus complexes.

2) ce n'était pas dt et dl mais dt et dd. dl garde son sens (= Definition List). Mais dt et dd prennent des sens différents : respectivement Definition Term et Definition Description pour dl et Speaker et Quote pour dialog [1]. D'où la schizophrénie.

3) je ne critique pas les balises sémantiques, loin de là, je critique le trop de balises sémantiques. ma question est : va-t-on créer une balise sémantique pour chaque truc que l'on veut ajouter ? si oui, ça va donner DocBook, si non on peut très bien essayer de trouver des balises suffisamment généraliste pour faire plusieurs choses mais suffisamment précises pour ne pas couvrir la moitié du monde.

Et puis juste comme ça en passant, les "applications web", si ça ressemble à ce qu'on a en ce moment en pire, je préfère encore ma vraie application.

4) merci du tuyau, je vais essayer dès ce soir

[1] http://www.w3.org/TR/html5/#the-dialog

J'avais juste oublié une petite chose que j'aurais aimé voir aussi en HTML5 : c'est l'inclusion de document externe.

Parce que, quand on fait un petit site statique et qu'on veut mettre un menu, il faut recopier ce menu partout, au risque de devoir tout recommencer si on changer le menu. Une simple balise include permettrait de résoudre ce problème et d'éviter de devoir utiliser un PHP pour pouvoir faire des choses proprement et simplement.

En XHTML, je pense qu'on pourrait utiliser XInclude [1] qui est justement fait pour ça (ça marche pour tous les documents XML). Mais je n'ai jamais vérifié si c'était implémenté par les navigateurs, je vérifierai à l'occasion mais j'ai vraiment des doutes.

Donc pas d'inclusion encore pour cette fois.

[1] http://www.w3.org/TR/xinclude/

J'étais très enthousiaste la première fois où j'ai vu XHTML2, je me disais qu'enfin, on avait pris la bonne direction, en abandonnant plein de boulets de HTML : obligation de la syntaxe XML, uniquement des balises sémantiques, etc. Bref, ce qu'aurait du être HTML dès le départ. Et XHTML1 représentait une très bonne transition entre les deux, à mon sens, en conservant encore pour quelques temps des balises qui n'avait plus lieu d'exister.

Et là, patatras, HTML5 arrive et remet tout ça en cause. Alors oui, on "peut" faire du XML avec HTML5, mais il ne faut pas rêver, les concepteurs ne vont pas s'amuser à aller vérifier la validité XML de leurs pages s'ils n'y sont pas obligés. Les trucs que je trouvais sympa dans XHTML2 et qui ont disparu dans HTML5 :
- la balise h qui permettait de ne pas spécifier de nombre après et qui, en combinaison avec la balise section donnait des trucs vraiment bien structuré [1]
- la balise l qui permettait de spécifier une ligne sémantique [2]

Mais surtout, parmi les horreurs de HTML5, j'ai vu :
- le détournement du sens de dt et dl où le d pourra signifier definition (comme en (X)HTML) mais aussi maintenant dialog, des éléments schizophrène donc. Ça va être simple d'apprendre le HTML5 : ça veut dire quoi dt ? ben le d veut dire : ça Dépend...
- la redéfinition de balises anciennes qui aurait dû disparaître, ce qui ne va pas améliorer ni leur abandon, ni leur compréhension : b, i, small
- la floppée de nouvelles balises inutile dans 99% des cas (aussi appelé Docbookisation de HTML) : progress, meter, etc.
- la disparition de la balise acronym : c'est peut-être anecdotique mais bon, moi je l'aimais bien et je l'utilisais. DokuWiki aussi génère automatiquement des balises acronym aussi pour un certain nombre d'acronymes qu'il connaît (genre SQL, IRC, etc). C'est une balise sémantique que je regretterai.
- la disparition de l'attribut style qui était fort pratique pour un style ponctuel mais souvent mal utilisé, je le reconnais.
- la disparition de l'attribut align dans la balise table : faudra m'expliquer comment, en CSS, je centre un tableau sans mettre de balise div autour et sans centrer tout mon texte. Idem pour l'attribut valign.
- le meilleur pour la fin : le retour de la balise font où on nous dit qu'on n'a pas le droit de l'utiliser, sauf si on est un éditeur WYSIWYG (un peu dans le genre du CPE, c'est publié mais vous ne devez pas l'utiliser). vu le nombre de personne qui utilise des Frontpage ou même des Word pour générer du HTML, on n'est pas près de voir disparaître ce truc infâme. On nous dit que les outils ne savent pas faire autrement ; et bien qu'ils apprennent à faire autrement mais qu'on ne nous ressortent pas ce cadavre qui était en voie d'extinction !

Bref, je suis vraiment très très très très sceptique et les avancées de HTML5 (je les ai pas commentées, d'autres l'ont fait avant) comme canvas ou nav ou header/footer ou audio/video ou même les nouveaux type d'input ne feront pas oublier toutes les horreurs/erreurs présentes et qui ne favoriseront pas les bonnes pratiques du web, à mon avis.

[1] http://www.w3.org/TR/xhtml2/mod-structural.html#edef_structu(...)
[2] http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.7.

... ce n'est pas une personne, aussi talentueuse soit-elle. C'est avant tout une architecture UNIX qui a prouvé son excellence, augmenté de quelques mécanismes pour permettre d'isoler un peu plus les processus, et surtout une bonne configuration concocté par un administrateur digne de ce nom.

C'est marrant, j'aurais dit l'inverse : par défaut, il vaut mieux savoir désallouer ce que tu as alloué et en cas de besoin (l'allocation et la désallocation se font à des moments et des endroits bien distincts), on peut avoir recours à un GC.

C'est quoi cette mode de mettre des GC partout ? Un GC n'est pas la réponse à tout, loin de là...

t'as raison, maintenant, la politique, ça se fait à Disneyland, avec des top models, c'est beaucoup mieux...

Je ne parlerais pas de statistiques dans ce cas présent... tout au mieux d'échantillons. La statistique, c'est quand même autre chose, ça suppose de déterminer les erreurs que l'on peut faire, sur l'échantillon (est-il bien représentatif ? de quelle population est-il représentatif ? quelle est l'intervalle de confiance sur les résultats obtenus ? etc.). Ici, on a des données qui valent ce qu'elles valent, qui nourrissent certainement bien les trolls mais pas les gens qui font des statistiques. Même les sondages d'opinion sont mieux fait que ça.

Ça n'enlève rien à l'initiative du site qui est une très bonne idée à mon sens.

> Tant que la programmation par sémaphore et par "shared memory" sera utilisée les programmes ne seront pas capables de bénéficier de toute la puissance des nouveaux processeurs.

Je ne suis pas du tout d'accord. On peut très bien utiliser des sémaphores et de la mémoire partagées et faire des programmes très performants sur les nouveaux processeurs. Ou alors, je dois m'être trompé depuis plus de 2 ans que j'en fais.

Avoir un langage dédié doit aider (je ne connais pas Erlang) et à l'inverse, avoir des libs de base (la libc pour ne pas la citer) qui ne sont même pas réentrante, ça n'aide pas vraiment. Mais c'est possible quand même.

Il faut se rendre à l'évidence qu'Erlang n'atteindra jamais le niveau d'utilisation (en nombre) de C ou C++ ou Java. Alors autant évangéliser sur les bonnes méthodes à utiliser dans ces langages. Des initiatives comme Intel TBB ou QtConcurrent permettent d'abaisser le niveau de la barrière à l'entrée et c'est dans cette direction qu'il faut aller à mon avis.

c'était mieux à vent ?

Ou peut-être que tu ne comprends pas le mot "alternatives" qui signifie "autre que GNOME" donc pas de troll

Je pense sincèrement que tu devrais postuler à Gartner, tu pourrais pondre des trucs comme ça tous les jours et en plus tu serais payé pour le faire...

Je préfère nettement la vision de Gof, ça me rappelle le livre de Jean-Michel Cornu et le chapitre sur la Coopération-Réciprocité-Pardon.

http://www.cornu.eu.org/texts/cooperation
http://fr.wikipedia.org/wiki/Coop%C3%A9ration-r%C3%A9ciproci(...)