benoar a écrit 4239 commentaires

même si les specs ne sont pas toujours à jour par rapport à la dernière version existante

Bah voilà, t'as sorti un des nombreux problèmes des formats "proprios" (pour moi flash est proprio) car ils dévoilent ce qu'ils veulent, et gardent secret certaines parties intéressantes. Comme ça, ton appli libre aura beau essayer de suivre tous les changements, elle sera toujours en retard et tout le monde continuera à dire "les applis libres qui font du flash ça pue".

Alors voilà, j'aimerais qu'on m'explique :

- d'un côté, on oblige les fabriquants de DRM à divulguer le fonctionnement de leur protections à des fins d'interopérabilité : je suis complètement d'accord avec ceci, bien que ce soit complètement con pour eux : divulguer le secret d'un DRM enlève ton son intérêt ("protéger" un fichier par une méthode secrète et divulguer ce secret...)

- d'un autre côté, si on parle, diffuse, fabrique, utilise un logiciel chargé de pouvoir lire ces fichiers DRMisés (en utilisant, par exemple, les informations divulguées par l'obligation sus-citée), on risque des peines d'amendes et de prison pouvant parfois être très élevées.

Quelqu'un voit-il une quelconque logique à cette nouvelle loi ?

PS: remplacer DRM par MTP pour ceux qui sont tatillons

Oui c'est vrai qu'aujourd'hui de plus en plus de développeurs sont conscient de l'importance de l'interopérabilité, que c'est vraiment utile pour avoir des bases solides sur lesquelles se baser, de pas avoir à tout refaire pour X constructeurs différents. Mais ça c'est le point de vue d'un développeur.

Du point de vue du marketteux, le retard de l'interopérabilité des solutions ça veur dire un avantage économique pendant quelques temps (ou alors un cassage de gueule complet, aussi), et donc plein de brouzouffes en plus ! Bref, tu t'es créé ton petit monopole pendant quelques temps. Et après de toutes façons si tu gagne, tout le monde te suivra donc t'auras l'avantage technologique, et si tu perd tu te barre discrètement dans un coin paumé pour que personne te retrouve (mais bien sûr tu laisses les employés dans la merde). Croire que toutes les entreprises "capitalistes" d'aujourd'hui veulent respecter les règles du marché "libre et équitable" c'est oublier qu'elles font aujourd'hui tout pour avoir une position dominante dans leur domaine (quitte à créer son propre domaine, c'est le principe de la différenciation, une des premières chose que j'ai apprise en économie).

Bref, je suis complètement d'accord avec toi sur le fait que ta méthode serait la bonne, que ce serait bien pour tout le monde, je trouve tes remarques très justes. Mais c'est oublier la réalité économique d'aujourd'hui et les buts recherchés par les boites : c'est pas de rendre tout le monde heureux, mais de faire un max de thunes.

Désolé pour le ton pessimiste, mais je suis comme ça en ce moment...

C'est bien de faire un beta histoire de débugger toutes ces fonctionnalités, mais moi je trouve qu'en général vim est très très peu buggé...
Je trouve ça exceptionnel : c'est peut-être le logiciel que j'utilise le plus, je ne me souviens pas avoir vu de bug dedans, et encore jamais aucun plantage en plus de 6 ans d'utilisation.
Ayant du mal à me mettre à Latex, qui m'avait pourtant bien servi pour un rapport (fait dans vim, bien sûr), j'ai eu du mal à m'adapter aux plantages réguliers de OOo. C'est vrai quoi, j'ai jamais eu le réflexe de sauvegarder mes documents textes toutes les 30s pour éviter le crash pendant mon utilisation de ce merveilleux outils : Vim, mon amour !...

Essaye de regarder ce qu'il s'est passé dans le monde de la 3D, et tu comprendra que c'est pas vraiment le genre de philosophie à laquelle adhèrent les boites proprios en général.
Au début on fait chacun ses APIs de son côté, incompatibles (à l'époque pour la 3D il y avait Glide (3DFX), ??? (PowerVR), OpenGL, Direct3D, etc...) et c'est celui qui a le meilleur marketing qui gagne. Après, les concurrents se rangent du côté du gagnant pour pas mourrir.
Bref, je sens que ça va pas être si rose que ce que tu propose...

alors autant avoir un DRM qu'on puisse utiliser avec Linux et des logiciels libres.

Putain, mais le but d'un DRM c'est de limiter tes libertés ! Tu vois pas le problème avec "logiciel libre" ?
Oui la GPL limite tes libertés car tu peux pas enculer le développeur en en faisant un logiciel proprio, mais cette limitation n'est pas technique, c'est juste une limitation légale. Comme avec la musique actuellement, il y a des lois sur le droit d'auteur pour limiter tes libertés de l'utiliser (pas la vendre à qqn si t'as pas les droits dessus, par exemple), on a pas besoin d'avoir des DRMs qui te prennent pour un gamin en te disant "bah puisque tu peux pas respecter une loi, je vais te foutre des claques avec mon bon gros DRM".

Dans ce cas on parle généralement de la taille des registres généraux, qui est de 32bits dans les "processeurs 32bits" actuels. Mais il y a aussi la taille des opcodes (32bits meme sur les 64bits RISC... je parle pas du CISC qui a des tailles variables), la tailles des registres de l'unité vectorielle (128bits pour le SSE ou l'Altivec), etc... Alors un "processeur 32bits" c'est pas très précis, même si ça correspond en général à la taille des GPR.

Déjà, rien qu'en recroisant avec le numéro de carte bleue qui a payé le CD/DVD ça doit être possible. Enfin ça doit pas être légal, cf la CNIL et tout ça. Mais vu comme cette institution est respectée en ce moment, j'ai bien peur que ça arrive quand même un jour...
Bref, payons nos CDs en liquide ! (et les CDs sans DRM bien sûr, les autres pas la peine de les payer)

Cette technique peut marcher s'il n'existe pas de moyen de détection du watermarking et de suppression de cette marque. Sommes-nous sûr sur ce point ?

Un moyen auquel je viens de penser, serait de comparer bit à bit 2 fichiers décryptés obtenus par 2 personnes différentes. Ça se trouve, c'est déjà utilisé dans les DRM actuels fermés (je parle des DRMs sur la musique en ligne, comme indiqué plus haut, je vois pas comment on pourrait faire ça avec un CD puisqu'on ne sait pas (à priori) qui a acheté le CD).

En même temps, c'est un système de DRM, donc, si il ne fonctionnait pas correctement, (en pistant l'utilisateur du contenu), il ne servirait pas à grand chose...

Bah pourtant c'est ce qui se passe actuellement, vu que toutes les protections ont été crackée à ma connaissance. L'important, c'est pas qu'il soit compètement efficace, c'est qu'il soit assez chiant pour emmerder l'utilisateur honnête... à mon avis.

Merci de l'avoir dit, c'est tout à fait ce que j'allais répondre. Je rajouterais que l'idée du watermarking, c'est une hypothèse de ma part.
J'ai pensé à ça car l'idée de Sun actuellement ne sert pas à grand chose en tant que tel (libérer un DRM et donner tous ses secrets ...) et que je me suis dis qu'il doit y avoir qqch d'autre derrière.

Alors je viens de lire rapidement le code des différentes parties du truc, et globalement, je vois rien de très compliqué, ni de code proprio, rien de bizarre.
En fait, ce DRM utilise même des outils tout a fait classiques : curl, SSL, etc... En bref, chaque contenu DRMisé est crypté, et lorsqu'on a besoin de lire le contenu, il va chercher la clé sur un serveur de clé, qui lui donne (ou non ...) et décrypte le contenu. Mais rien sur le nombre de lectures, le nombre de copies, rien même pour empêcher VLC de dumper le flux dans un fichier ! (apparemment, hein, je n'ai fait qu'une lecture rapide)

Et c'est là que je me suis dit qu'il y avait qqch de bizarre. Et je me suis dit qu'en fait, effectivement, les gens de chez Sun doivent très bien savoir qu'on ne PEUT PAS empêcher qqn de copier un contenu numérique une fois décrypté. L'astuce se trouve autre part que dans la technique. J'ai remarqué ça en voyant qu'une importance certaine était accordée au serveur de licence. Alors voilà ce que j'ai pensé (attention, énorme extrapolation de ce que j'ai lu) :

J'ai remarqué qu'une clé privée pour l'utilisateur était utilisée pour négocier ces transactions. En fait, je pense que le cryptage comme on le pense en ce moment pour les DRM, c'est à dire que le contenu est codé avec la clé privée de Sony/Microsoft/etc ... et décodé avec leur clé publique, n'est pas utilisé ici. C'est plutôt l'inverse : chaque utilisateur envoie sa clé publique au serveur, qui va coder le contenu avec et l'envoyer à l'utilisateur (qui le décodera avec sa clé privée). A priori, cela ne change pas grand chose, on a le contenu et la clé (que ce soit dans le cas de la clé publique des Majors, ou de sa clé privée), on le décode. On a notre morceau décrypté, super.

Mais c'est sur autre chose que vont jouer les majors (ou tout autre fournisseur de contenu DRMisé, car je pense que ça va très vite s'étendre) à mon avis : le serveur de clé justement. Comme on lui donne sa clé publique pour qu'il nous crypte le contenu, il nous identifie. Il peut donc choisir de nous refuser sur certains critères (qui seront bien cachés par les majors) comme le fait qu'on soupçonne qqn de faire circuler les fichiers en clair sur le P2P, ou autre. Vous allez me dire : mais comment savoir quel utilisateur (donc avec quelle clé) a "piraté" le contenu en le débarrassant de ses DRMs ? Je pense par exemple au water-marking. Et comme cela, on se retrouve à se voir refuser l'accès à tout contenu DRMisé. "Ho, pas grave, je vais recréer un compte" -> là je pense que justement, ça sera assez contrôlé, et on pourra également détecter les "récidivistes" ; "Ho, pas grave, je vais aller me fournir sur le P2P" -> oui mais pour fournir le P2P, il faut donc que certaines personnes "sacrifient" leur clé afin de décoder du contenu. Vous allez me dire, mais si tout le monde fait comme ça, les majors ne pourront plus suivre, elles abandonneront leur système. Mais c'est sans compter sur l'égoïsme humain, qui fera qu'au final personne ne voudra se "sacrifier", ou alors ce sera toujours les même; bref, comme toujours dans la vie réelle...

Enfin voilà la petite réflexion qui m'est venue à l'esprit; je vais m'arrêter là pour l'instant pour éviter le post de 3km. Attention tout de même, ce que je viens de dire est à prendre avec des pincettes, je pense que je suis parti très loin de ce qu'est le code à la base, cela provient donc au final majoritairement de mon imagination. J'espère que ce n'est pas vraiment ça. Non, vraiment, il ne faut pas que ce soit ça...

Par contre je viens de trouver les sources de DReaM (le nom de ce DRM) qui sont sous licence "libre" (CDDL).
Et un truc intéressant : il y a déjà un patch pour VLC, sous GPL, ici : https://dream.dev.java.net/source/browse/dream/DReaM/DReaMCA(...)
A étudier donc pour savoir ce qu'il s'y cache.

Portage des jeux simples quand on auras une machine/pc cell dispo facilement

J'avais entendu, au moment ou le premier Cell était sorti (sur un blade IBM il me semble) qu'ils ne comptaient pas vraiment le commercialiser, à part peut-être dans qq serveurs très spécialisés (en + de la PS3 bien sûr). C'est le problème avec le Cell, c'est un très mauvais proc généraliste (core in-order, spu difficilement programmable que pour des applis de traitement massif de données, etc...). Donc la machine estampillé "Cell" chez monsieur tout le monde, j'en doute (peut-être dans une prochaine évolution de ce proc, mais alors on peut encore attendre...)

A tous ceux qui pensent que c'est cool pour linux, je pense que les jeux qui seront développés seront :

- spécifiques au processeur Cell, donc rien à voir avec nos x86, et donc pas la peine d'espérer un portage
- propres aux API de la PS3, donc pour l'histoire de la revalorisation d'OpenGL, j'en suis pas si sûr (même si la carte est une NVidia, rien n'empêche que ce soit un driver avec une API spécifique)
- bourrés de DRMs, et de formats proprios à la con (c'est Sony, hein, le Microsoft des consoles)

Bref, à part utiliser un système "gratuit" pour diminuer les coûts de développement, je vois pas trop en quoi ça peut valoriser linux. Ha si, pour l'image de "marque" de linux pour ceux qui n'ont rien compris aux problèmes que je viens de citer.

Les protocoles ouverts et extensibles c'est bien, mangez-en!

PS: Attention, chez moi, la lecture du film en flash a pris 100% de RAM

Bizarre, chez moi (linux ppc) la non lecture du flash m'a pris 0% de CPU.

Dans les liens sur la page vers les remarques des utilisateurs, il parait que certaines versions de la protection Starforce endommagent effectivement le lecteur CD/DVD. Après, que ce soit vraiment le cas, ou alors encore un autre bug de Windows avec ce système, je sais pas trop...

Bah tu sais aujourd'hui c'est une mode dans le libre : on brevète les trucs quand c'est pour du libre, mais quand c'est les enculés-d'en-face-qui-font-du-proprio c'est inadmissible. On utilise des drivers proprios qui déchirent niveau rapidité sous linux, mais sinon le proprio sous windows ça pue. Et les DRM Open Source de Sun c'est coool, alors que ceux de Sony/VU/... c'est nul ça restreint la liberté des gens. Etc...

Non la décision récente n'a rien dit de tel, elle a juste "cassé un premier jugement, en considérant en gros que tous les éléments n'ont pas été pris en compte lors du jugement en question.

Oui c'est vrai, j'avais pourtant lu les commentaires suite à cette décision, qui précisaient bien ce point. Méa culpa.

C'est bien ce qui est dit pourtant:
On ne peut interdire la publication du code source et de la documentation technique d'un logiciel indépendant intéropérant pour des usages licites avec une mesure de protection d'une oeuvre.

Ce que je voulais dire, c'est que la lib permettant le cassage de la mesure de protection peut être utilisée de manière licite ou non. L'usage de mencoder est donc dans ce cas utilisé à des fins illicites. Mais pourtant, aucune partie du code de mencoder ne contourne une protection technique, puisque c'est la lib DeCSS qui s'en charge. Pourtant, c'est la même lib qui permet un usage licite de la lecture d'un DVD lorsqu'elle est utilisée dans mplayer !

Merci pour ces informations.

Mais je remarque qu'il y a toujours cette différence entre logiciel à usage licite ou non :

On ne peut interdire la publication du code source et de la documentation technique d'un logiciel indépendant intéropérant pour des usages licites avec une mesure de protection d'une oeuvre.

Prenons DeCSS, sous sa forme de bibliothèque (libdecss). Je l'utilise avec mplayer : ok, c'est pour regarder mon DVD crypté avec CSS. Je l'utilise avec mencoder : bah ça dépend, si c'est pour de la copie privée, ok (ha non, merde, la décision récente d'un juge contre la copie privée sur les DVDs me contredit) mais si c'est pour le distribuer ou le revendre, c'est pas ok. Bref, ça dépend de l'utilisation de la lib, pas de son "caractère licite", ce qui ne veut rien dire.

Bref, ils ont toujours rien compris, ou alors ils le savent très bien mais ils s'en foutent.

Gni ? De quoi tu parles ?
Effectivement, si tu veux des paquets pas "classiques" ou que tu n'as pas tous les CDs de la Mandriva (je ne sais pas combien en contient la Discovery/LX), il te faudra une connexion à internet.
Mais pour installer OpenOffice.org, les CDs de base doivent te suffire ! Je ne suis pas sûr que tu aies bien lu la doc, c'est expliqué en détail ici : http://lea-linux.org/cached/index/Fiches:Administration-fich(...)

Concernant l'histoire du travail collaboratif, qui serait exclu du champs d'application des peines induites par cette loi, je pensais que ça venait peut-être de l'annonce récente de l'intégration du P2P dans Vista pour mieux "travailler ensemble en entreprise". Je viens de retrouver ça :

The Windows Collaboration module uses peer-to-peer technology to let Vista users work together in a shared workspace

ici : http://news.yahoo.com/news?tmpl=story&u=/ttpcworld/20060(...)

De la part d'un amendement Vivendi Universal, ça ne m'étonne pas trop que Microsoft se soit invité au débat pour mettre sa petite exception à lui.

Tu n'as pas du bien chercher sur Léa-linux ... Sous linux on ne va pas télécharger des programmes sur des sites pour les installer, on utilise un gestionnaire de paquet. Va voir http://lea-linux.org/cached/index/Intro-faqdeb.html# en bas de la page.
Une petite recherche sur ces forums ou sur google t'aurais surement donné le même résultat.

les flux RTP transitent généralement en Pear to Pear

Pour améliorer le transit des flux, mangez des poires ?

C'est assez symptomatique de la part des extrémistes que d'aller enculer les mouches sur des trucs pareils.

C'est vrai qu'on ne voit jamais de débat d'extrémiste qui encules des mouches sur linuxfr...