benoar a écrit 4229 commentaires

C'est pas légal (pb de licence), mais au moins on a les sources et donc ça marche également sur autre chose que du x86 : compiler FFmpeg avec la lib VC-1, ici : http://multimedia.cx/eggs/?p=129

Après je pense que tu dois avoir un totem-ffmpeg quelque part, ou un truc dans le genre.

Testé avec mplayer sur ppc, mais ça marche à peu près bien.

J'ai jamais vraiment eu confiance en les drivers de chez NVidia. J'ai eu plein de plantages inexpliqués qui disparaissaient après passage aux drivers nv (libres). Mais j'avoue que c'était il y a qq temps (genre 2 ans), et il parait que ça s'est amélioré depuis.

En tous cas, si tu dis que ça arrivait aussi avant l'install des drivers NVidia, ça vient peut-être d'autre part. D'un coté il me semble que les drivers proprios sont intégrés dans la mandriva (dans le pack payant), donc peut-être que tu les utilise depuis le début sans le savoir ...

Sinon pour savoir les dernières choses qui se sont passées avant le crash, faut aller voir dans les logs. genre :
tail /var/log/messages
ou
tail /var/log/syslog

Mais avec ce genre de crash brutal, je sais pas si ce sera très utile.
Mais comme tu me dis que ça arrive même sans la cooker, je pense aussi à un problème matériel .... !?

Pour ton pb de réseau, t'utilises un modem usb ou ethernet ? Ton indication sur la manière de le récupérer semble indiquer le 2e choix, mais dans ce cas si ça déconnecte, c'est la faute à ton modem...

1° l' écran se fige et je n' ais plus le contrôle du clavier et de la souris, je suis obligé de rebooter par une extinction de l' ordi à la hussarde.(Se produit sous konqueror plus particulièrement).

Ca ressemble bien a un crash de X ... par hasard, t'as une NVidia et les drivers proprios ?

Oui pour la version de Turbolinux, ils ont peut-être vu ça avec MS et payé une licence, mais je connais personne qui l'utilise (j'en avais jamais entendu parler avant). Moi je parle de la version de FFmpeg qui a été trouvée par reverse-engeneering (source : wikipédia) et qui est celle sur laquelle se base la majorité des players aujourd'hui (et dont au moins on a les sources, sinon pour mon ppc avec celle de Turbolinux, a mon avis, je peux me brosser). D'ailleurs ça montre bien qu'entre un module proprio et une version libre, le choix est vite fait.

Pour la doc de WMV9, je suis pas sûr que ce soit si simple que de payer la doc une fois et d'implémenter après comme on veut. Il doit bien y avoir des licences à payer par player/encodeur distribué ... ? Ce qui est incompatible avec le libre pour moi.

Je sais bien que les specs ISO des fois faut bien les payer pour les avoir (ou un autre consortium connu, je ne sais plus, enfin en général c'est pas trop cher) mais après on l'implémente comme on veut. Bon, après vient le problème des brevets, et ça il y en a aussi bien sur MPEG4 que sur WMV9, donc sur ce point là c'est la même galère sur les 2. C'est pour ça qu'il faut les combattre avant qu'ils n'arrivent en europe (pas la peine de re-troller sur ce point, je connais ton avis sur la chose depuis les débats de l'année dernière, c'était juste une remarque sur les coûts qu'engendrent l'implémentation d'un codec vidéo).

Oui je sais qu'on peut lire les WMA sous linux, merci, je le fait souvent (quand on m'en passe). Mais comme je précise plus haut, cela a été obtenu par reverse-engeneering, et non grâce à une doc qu'aurait pu donner microsoft.

Comme tu l'as deviné, j'ai un Mac, mais je n'ai pas (plus) MacOSX. Et la solution que tu donnes dans ton lien est proprio. Si j'ai choisi linux, c'est pas pour faire hype ou pour bidouiller (enfin si, bidouiller un peu), c'est pour être libre. Donc les solutions proprios ça ne me va pas.

A propos de documentation des codecs, c'est marrant comme windows ne file pas de doc pour le WMV9, alors que c'est juste un dérivé du MPEG4... qui est une norme ISO. D'un autre côté, j'en ai tellement marre de me battre que récemment j'ai compilé le patch de la lib VC1 (l'implémentation de WMV9 dont on a les sources) pour mplayer. Ca marche, mais c'est pas optimisé du tout, et c'est en totale contradication avec la licence de cette lib, et avec la licence de mplayer. Bref, je suis dans l'illégalité...

Ma remarque sur le .doc, c'était pour faire remarquer l'étrange différence de traitement que l'on fait à microsoft : les AAC avec fairplay c'est assez chiant à lire car c'est pas très commun (enfin, j'en ai pas croisé des masses), alors que les .wma ou les .doc sont lisibles partout sous linux car il y a une pression énorme des utilisateurs pour pouvoir lire ces formats. Pourtant c'est exactement pareil, c'est des formats proprios. Et encore, comme je disais plus haut, le AAC est une norme ISO (elle fait partie de MPEG4), c'est juste le DRM "fairplay" qui n'est pas documenté.

Oui effectivement, tu as raison. Mais je ne parlais pas de la qualité de l'outil, mais bien de ce que les utilisateurs en font, et comment ils l'utilisent : ils le font mal et trouvent ça normal de rebooter...

Pour une station de travail en entreprise, bien entretenue, bien mise à jour, je veux bien avouer que j'exagère.

Mais pour le PC de monsieur tout le monde, avec un bordel monstre de logiciels/spyware/virus/antivirus, les reboot sont beaucoup plus fréquents. Et en plus les gens trouvent ça normal.

Je suis d'accord avec le problème des licences, mais bizarrement tout cela vient à mon avis des DRMs qu'ils utilisent dedans, PAS du format de codage audio. Car quand on regarde les specs de ces formats, c'est l'inverse de ce que tu expliques (Windows bien / Apple pas bien) qui arrive : les specs du AAC sont des normes ISO, alors que celles du WMA ont été obtenues par reverse-engineering et sont tout ce qu'il y a de plus proprio/cachées !!

Il faudrait que je recherche un peu plus la raison des licences car je ne suis pas tout à fait sûr que cela provienne du problème de DRM, mais cela commence à montrer pour quoi de toutes façons ces deux formats puent pour quelqu'un qui (comme moi) veut rester vraiment libre. D'ailleurs, pourquoi les implémentations libres ne payent-elles pas de licences ? (oui, ça doit venir du fait que tant que personne ne se fait de pépettes dessus, ils laissent passer)

Et justement, c'est mon problème : je veux être vraiment libre. D'ailleurs, j'ai préféré, comme Arlette, ne pas choisir au 2è tour...

Franchement, rebooter, c'est chiant.

D'un côté les windowsiens y sont tellement habitués pour des raisons plus ou moins obscures (plantage, reboot après un changement de paramètres dans le panneau de config, après une install d'appli, quand l'ordi rame trop, etc ...) que ça ne changera pas grand chose pour eux, je pense. En plus je suis sûr qu'ils trouveront ça très ingénieux, ou utile, enfin qu'ils verront un coté positif que nous, libristes, on n'aurait jamais osé imaginer.

Ce n'est pas parce qu'un logiciel existe sur une certaine plate-forme que le codec existe aussi !!
Sous linux x86 tu utilise les codecs win32 qui proviennent des versions windows de ces codecs : c'est proprio, c'est uniquement un binaire pour x86, même pas fait pour linux à la base. C'est crade à souhait. Mais ça marche à peu près, donc tout le monde est content. Et tout le monde a oublié pourquoi certains font toujours chier pour ça : on veut que linux soit libre, pas qu'il soit techniquement meilleur/+ facile/etc...
Enfin j'ai l'impression que presque plus personne ne cherche ça, même ici. C'était mieux à vent, quand on était entre intégristes...

Juste une petite question pour toi (elle peut paraître bête, mais je ne veux pas du tout te prendre pour un débile, c'est pour ma petite enquête sur comment les gens + "normaux" voient l'informatique) : tu sais ce qu'est une architecture ? un format de fichier ? un codec ?

Et pourquoi personne ne parle de Microsoft : il fait exactement pareil ! Le format WMA (proprio) n'est lisible que sur du matos compatible Microsoft. Mais bien sûr, comme quasiment tous les constructeurs (ça doit même être tous) sont compatibles WMA, personne n'en parle.

Bah oui c'est vrai quoi, pourquoi tout le monde fait chier avec les .doc, c'est bien lisible partout avec Microsoft Office, non ? Ha bon, ya des gens qui n'ont pas Windows ?? (tip: imaginez un monde sans OOo pour les lire pour que ce soit réaliste comme remarque...)

Je viens de trouver une solution, qui n'est peut-être pas très élégante mais qui marche (chez moi...). Je me suis intéressé au problème car j'avais déjà voulu faire ça, et la solution "à larrache" que j'avais trouvé, c'était de bourriner sur Ctrl+c...
Donc voici ce que j'ai trouvé :


while true
do
nslookup www.toto.com &
wait $!
done


En bref, ça lance le processus en arrière plan, mais ça l'attend tout de suite. L'astuce c'est que wait est une commande intégrée au shell, donc quand elle reçoit un SIGINT, c'est bien le shell qui s'interrompt.
Seul petit "bug", c'est que la commande est généralement exécutée une dernière fois après l'avoir killée (comme on kill le wait, on revient au shell avant que notre commande ait pu (éventuellement) se terminer).

Ce qu'il veut dire c'est qu'il doit te manquer certains paquets de KDE, dont celui qui contient startkde. Je ne sais pas non plus dans lequel il se trouve (j'ai pas de mandriva).
Es-tu sûr d'avoir installé tous les paquets nécessaires ? Normalement, ce problème ne se pose pas, grâce aux dépendences, si tu as installé les bons paquets KDE de base : il doit y en avoir un qui s'appelle kde-desktop ou un truc dans le genre, qui installe tous les autres.

J'ai peut-être un indice : la signification exacte de \w doit dépendre de la locale en cours. Je sais pas comment la changer ni vérifier ça, mais généralement les changements de locales influes sur ce genre de chose (bon c'est vrai qu'en UTF8 en ne pense plus aux locales, mais il doit bien y avoir un fr-utf8 (non ?) qui change ça)

Je recopie un bout de l'article 7 qui parle de ça :

Les licences de développement des mesures techniques de protection sont accordées aux fabricants de systèmes techniques ou aux exploitants de services qui veulent mettre en ½uvre l'interopérabilité, dans des conditions équitables et non discriminatoires, lorsque ces fabricants ou exploitants s'engagent à respecter, dans leur domaine d'activité, les conditions garantissant la sécurité de fonctionnement des mesures techniques de protection qu'ils utilisent.

Pourquoi les éditeurs/développeurs de logiciels libres ne seraient pas considérés comme des fabricants de systèmes techniques comme les autres ?
Et tu parle de NDA, mais est-ce que cela correspond à une condition équitable et non discriminatoires ?

Je vois bien ce que tu veux dire, c'est écrit comme ça dans les textes mais dans la réalité ça ne sera pas appliqué pour les développeur du libre, mais ce serait bien qu'on essaye de faire jouer la justice pour déterminer qui a raison (et oui, encore une fois, on ne s'en sort pas sans passer par la case tribunal...)

C'est vrai que la condition de garantie de la sécurité de fonctionnement des mesures techniques c'est aussi super ambigu en fonction de comment on implémente notre prog : si je code une bibliothèque libre pour décoder un DRM, peut-on m'accuser de ne pas garantir l'efficacité des DRM sachant que celui qui utilise ma lib peut aussi bien faire un simple affichage du film qu'une recopie...

Bref c'est clair que ce texte est super mal tourné, mais j'essaye de trouver un fond plutôt "bon" à ce bout de texte, même si l'intention originale ne devait pas être si louable, comme tu l'expliques.

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.