matiasf a écrit 1969 commentaires

Très bonne lettre.

Autorises-tu que je la copie (je ne crois pas faire mieux...) pour l'envoyer à un député. Evidament je conserve les xxxxxxxx (donc je ne te site pas) en indiquant que la lettre que j'ai copié correspond à mon point de vue.

Je pense y ajouter des liens plus spécifiquement orienté LL (Les attaques aux LL via la loi).

> Heureusement que Mandrake l'inclut dans ses distributions !

çà sent un peu le troll. Toute les distibes fournissent ogg. Surtout un grand merci a ceux qui développement ogg/vorbis.

> Ne jetons pas l'opprobe sur une personne qui était convaincue d'avoir fait son travail et qui en fait était prisonnière d'un système sans même le savoir.

C'est comme çà qu'il faut voir les choses maintenant. C'est à nous (en fait l'AFUL) de tirer les choses vers le haut.

Je pense qu'après cette expérience, RF pourrait faire une émission sur les droits d'auteur, brevet, CSPLA, logiciel Libre, Intéropérabilité, etc... . Je pense que "Rue des entrepreneurs" est parfait pour çà. Cette excellente émission orienté entreprise montrerait clairement les objectifs des majors et l'intérêt des grosses entreprises pour des lois plus dure sur les brevets logiciel et le droit d'auteur.

J'ai mis "C2 (?)". Je ne suis pas sûre que Win NT a passé une certification C2. Par contre, il a passé une certification orienté sécurité qui ne nécessite pas le réseau. C'était au début de Windows NT (en 95 !).

> le rendez-vous est bien tardif.

Je ne suis pas surpris. çà dépend du type de rencontre. Il faut remarquer que c'est un rendez-vous annoncé. Ils (l'AFUL et RF) vont probablement communiquer sur cette rencontre . A la sortie de la rencontre un simple "on a causé entre nous" n'est pas suffisant.
Il est fort probable que des décisions vont être prises (annonce d'un partenariat pour la mise en place d'une solution ogg, annonce que ogg ne correspond pas à leur problématique, etc...).
Il faut noter que RF et l'AFUL ont déjà été en contact avant de faire cette annonce. Qu'il y a un (certe vague) "30 % de complétude" sur le site de l'aful. Bref ils ont fait des échanges et des actions sont en cours (au moins du côté de l'AFUL qui a peut-être une expression de besoin).

> [... plein de critiques sur RF ...]

Je crois que c'est le moment de "calmer" le jeux. L'annonce "wma uniquement" justifiait de gros cous de gueule mais ici il y a une démarche de prise en compte des systèmes sans support de wma.

Donc : wait and see.

Je suis contre ce type de pratique.

Sinon un user-agent qui fouille bien partout c'est httrack (comprend javascript par exemple) :
http://www.httrack.com/(...)

Normalement il faut une license Windows ce qui est déjà chiant et cher.

Le gros du problème est DRM. Si l'Europe suit le DMCA américain, on va avoir avec DRM le même problème d'avec DECSS.

Le cryptage de DVD est un système de protection. Publier un système comme DECSS pour accéder au contenu c'est donner des informations pour accéder à ce contenu, donc donner des informations pour éviter la protection. Hors selon DMCA et CSPLA (notre version française à venir), donner de telles informations est illégale.

Il y aura le même problème avec mplayer tant que les sources sont dispos. Hors mplayer étant GPL les sources seront forcément dispos. Ce qui montre l'incompatibilité entre GPL et DMCA etc...

Dans la même lignée il y a eu un problème avec Linux et un changelog d'Alan Cox. Il y avais un trou de sécurité dans un noyau 2.4 qui permet de sauter certains protections du noyau. Alan Cox a refuser de fournir des informations sur ce bug pour les américains en prétextant (à juste titre) le DMCA. Et aussi car il va régulièrement au USA et qu'il ne voulait se retrouver en tôle ...
Ben dans peu de temps il n'aura pas besoin d'aller aux USA pour aller en tôle :-) .

> signifie simplement “qu’un système fonctionne bien dans un cadre normal d’utilisation et s’il n’est pas attaqué”

Marrant car je crois que Windows NT a eu une certification C2 (?). MS comme d'hab a bien communiqué sur ce point. Hors cette certification a été faite sans connection réseau !

L'histoire se répète.

Il parle de ce qu'ils connaissent...
çà montre aussi qu'ils ont une certaine indépendance.

C'est un détail par rapport à wma mais ...

Si l'AFUL pouvait faire passer le message que les trucs lourdigues utilisés par RF font "chié" l'internaut :
- popup
- pas d'url pour le flus audio
- javascrip/java
- flash
- etc...

De gros site on compris çà :
- yahoo
- google
- les très nombreux sites dédiés Linux :-)
- etc...

Ce qui intéresse les internautes c'est le service, le contenu et pas des tonnes de popup, flash etc...

RF peut mettre plein de pub sur le site pour le rentabilisé, c'est compréhensible. Mais qu'il évite l'utilisation des dernières technologies de la mort qui tue qui n'apportent rien.
A passage, leur site impose le download de flash et je ne suis pas convaincu que windows soit livré avec flash. Donc le problème du download de ogg est ... petit ...

S'il souligne sur leur site qu'il est prévu pour tout les OS et indépendant de tout programme/technologie propriétaire car soucieux de leur mission de service public et suivant les prérogatives [...] çà leur fera une très bonne pub et le % d'OS "alternatif" va fortement augmenter :-).

Très bonne nouvelle. Au minimum, et c'est positif, M. Eric Duval-Valachs sera informé des problèmes avec les brevets (CSPLA, etc...) de l'utilisation de WMA et des contraintes imposées par le chois de ce format.

L'impression donné par RF est de ne pas avoir concience de ces problèmes et d'avoir choisi WMA à la va-vite uniquement en écoutant les conseils de Microsoft ou d'autre partenaire pas très soucieux du LL et des contraintes des formats/protocol propriétaire.

Au final, il n'y aura peut-être pas ogg mais ce sera un choix mûrement réfléchi.

> Eric Duval-Valachs. Il m'a paru, bien qu'effaré par la violence de certains courriers et de certains messages

Ils n'étaient pas majoritaire et sont courant dans tout forum.
Enfin cette décision par RF a été très mal amenée surtout pour un service public payé par tout les contribuables. Les radios privées qui ne fournissent que WMA sont nombreuses et çà me dérange beaucoup, beaucoup moins. La démarche d'une radio privée étant principalement financière. Et malheureusement M. Eric Duval-Valachs n'amenait que des arguments financier et globalement sont explication était loin d'être convainquante (pour ne pas dire plus ;-o ).

> à rapprocher de l'affaire Radio-France

Le problème est qu'avec DRM et les futurs lois Européen/Française il sera illégale d'utiliser mplayer.

Donc ce n'est pas une "bonne" solution.

Parmis les bonnes solutions il y a :
- MS fourni les spec et RF n'utilise pas DRM. Donc WMA devient un "standard".
- RF utilise un standard ouvert.

La réponse de RF n'est pas totalement négative mais :
- elle oublie l'essentiel : ils ont une mission de service public
- reste attaché à wma : les problèmes de solution propriétaire et aidé MS dans ses abus ne les dérangent pas.

J'ai l'impression que l'on reste face à une personne qui n'a aucune préoccupation éthique. La communauté est un marché qui a une "demande" (comme dit dans la réponse).

Je suis mitigé sur cette réponse qui est très consensuelle mais surtout loin de toute préoccupation éthique alors que c'est un service public.

Ecouter avec Mplayer...

1 - je crois que pour être dans la légalité il faut une license Windows.
2 - a moyen terme (cf CSPLA) il sera illégale d'utilise mplayer pour lire un flux WMA (surtout avec DRM).

Donc l'usage de mplayer n'est pas une solution a moyen terme.

> il reste la solution de boycotter RF
Ben je vais forcément boycotter RF puisqu'il utilise WMA. A moins que je bascule sous Windows mais çà c'est hors de question.

Donc je boycotte malgrès moi RF.

Bonne idée.

Le financement par la "communauté libre" d'un serveur ogg avec configuration etc. Par contre, le coût de la bande passante doit rester pour RF. RF paye la bande passante des windowsiens...

Cette solution serait beaucoup moins cher pour les Linuxiens que de payer une License Windows.

Par contre une telle initiative ne peut venir que d'un organisme comme l'aful (en partenariat avec RF).

Ceci montrerai aussi le coût réel (avec configuration) de cette solution. De plus pour un service public il vont être un peu honteux de faire payer cette infrastructure et rien pour les windowsiens...

Si c'est pas une misère d'attendre plusieurs années pour çà...

Peut-être pensaient-ils que l'Internet était un phénomène éphémère...

> tu l'achètes dans un endroit où tu peux rendre en cas de pb (comme la FNAC) et tu regardes.

J'adore cette idée.
- j'achete un DVD.
- je tente de le visualiser sans decss.
- çà marche je suis content.
- çà ne marche pas. Je le ramene car il n'est pas inscrit que c'est un DVD cripté et que je n'ai pas le droit de le lire. çà fait chié la FNAC, elle remonte l'info aux majors, les majors ajoutent un étiquettage et les medias en parlent en étant surpris qu'il est interdit légalement de lire un dvd sous Linux (quand CSPLA etc... sera appliqué).

Je vous présente toutes mes excuses.

Je croyais, à tord, que gcc 3.3 serait incompatible 3.2 et après quelques fouilles pour confirmer j'ai rien trouvé pour appuyer mes dire (sauf un mail qui indiquait qui fallait utiliser --thread=posix pour libstdc++).

Désolé pour cette propagation d'une fausse information.

> Faut arreter l'evangelisation bete et mechante ...

Chaqu'un son expérience. Moi je préfère gcc etc... Evidament qu'il y a des problèmes comme dans tous les logiciels mais pour moi gcc est meilleur (même si les autres savent souvant mieux utiliser le cpu) :
- Meilleur message d'erreur
- des extensions utiles
- disponible partout (très important çà surtout quand on a la malchance comme moi de travailler sur des fichiers binaires qui doivent être utilisés sur plusieurs plateformes)
- gdb avec gcc est le meilleur debugger (d'ailleur HP utilise gdb maintenant) en ligne.
- ddd avec gdb/gcc est le meilleur debugger graphique (du moins sous Unix). Et là il n'y a pas photo ! Surtout qu'en on voit les trucs tordus, non ergonomique (et faut de l'ergonomie pour debugger car le mode texte comme dbx c'est lourd...) proposés par les Unix commerciaux.

Alors tu dis que gcc y fait pas ci, y fait pas çà. Je confirme gcc n'est pas parfait. Mais j'ai eu aussi des poblèmes avec le compilo HP :
- certains programmes qui utilisent select() compilés avec -O2 ne marchent pas et pas de problème avec gcc. Et d'autres comportements "woodo" avec X11 quand on utilise les optimisations.
- le préprocesseur n'aime pas les grosses macros (quand une macro utilise d'autres macros qui utilisent d'autres macros ...).

Pour Solaris j'ai moins de critique mais il sort parfois des "pointeurs incompatibles" lorsqu'on utilise les const (les doubles const) .
Par contre je n'ai eu pratiquement aucun problème avec le compilateur OSF-1. Les plus gros reproches sont :
- messages d'erreur pas très clair.
- contrôle du code source très léger (variable non initialisé etc...).

Afin les qualités de gmake et sa disponibilité partout est un vrai bonheur. Surtout que les programmes makes sont beaucoup moins compatibles entre eux que le language C/C++.

> As tu deja essayer de debugger du code Fortran...

Non

> De meme avec GNU, tu sais comment ca se passe la gestion des exceptions C++ avec des librairies partages

Non, je n'ai pas de problème. Mais chaqu'un son expérience.

> revenez sur terre les amis !

Ben j'y suis là ... Tu es d'où toi?

> GCC, c'est bien pour compiler des trucs simpes. Mais rien de plus.

Apparament t'es pas de la planète terre. Ou alors pour toi mozilla/Linux/OpenOffice sont des trucs "simple et rien de plus".

Pour info, il y a un nouvel installeur pour debian qui vient d'entrer en phase alpha pour i386. C'est le bon moment de faire des tests et remonter des rapports de bug. http://www.debianplanet.org/node.php?id=878 Comme n'interface n'est qu'en ligne de commande je ne sais pas si çà mérite un article sur Linuxfr. Je vais donné l'impression de faire un troll : Donnez un coup de main à debian-installer car debian sur ce point est nettement en retard sur les autres.

> sinon toutes les distributions basées sur GCC.3x qui étaient sur le point de sortir, RH8, MDK9 et Suze-pas-libre, auraient utilisé des GCC3.1 patchés Si tu sous-entends que gcc 3.2 est sorti pour faire "plaisir" aux distributeurs, je ne suis pas convaincu (mais je me trompe peut-être). En effet, j'était abonné à la mailing psyche (RH8.0). Au début gcc 3.1.1 devait être utilisé. gcc 3.2 est sorti et quelqu'un a demandé si ce compilateur pouvait être intégré. Les devs RedHat on estimé qu'il n'y avais pas de grosse différence entre la 3.2 et leur version actuelle de la 3.1.1 . RedHat a décidé de mettre la 3.2. Je n'ai pas eu l'impression que le passage en 3.2 était une demande de RedHat ou autre distributeur. De plus la prochaine gcc 3.3 sera imcompatible avec le 3.2. Ce n'est que repousser le problème de quelques mois...

> c'est quoi cette attitude maintenons-seulement-les-langages-populaires ? Je crois que tu m'as pas compris. Pour moi c'est principalement un problème de maintenance par l'équipe gcc et peut être un problème de qualité du patch (je ne le connais pas). Si le language est populaire l'équipe gcc, tous les contributeurs, peuvent accepter la contrainte de prendre en compte cette fonctionnalité lorsqu'ils font des modifications. Si ce n'est pas le cas, faut-il "ennuyer" tous les contributeurs pour une fonctionnalité peu utilisée ? Ou n'est-il pas mieux de laisser la maintenance du patch à ceux qui l'on réalisé. Sur l'aspect popularité c'est tout ce que je dis. Je souligne aussi : > que je ne connais pas tout les tenants et aboutissants du problème. Tu remarquera que Linus a les même problème de chois avec Linux. Certaines fonctionnalités ne sont pas acceptés car elles alourdissent le boulot des autres développeurs. D'autres fonctionnalités sont acceptés même si elles sont loin d'être parfaite car elles n'impactent pas les autres développeurs. D'autres patchs sont refusé car il n'apporte rien d'important. Les distributeurs ont leur lot de patch pour le kernel non accepté par Linus et faut-il conclure que Linus est lent ou autre ? Bref il y a plein de raison pour le(s) mainteneur(s) d'accepter ou refuser un patch. Dire que gcc n'est pas réactif uniquement parce qu'ils n'ont pas accepté un patch est un peu léger pour me convaincre.

> c'est quand même le langage par défaut sous Mac maintenant... Quoi ? l'Ojective C ou le "Ojective C avec C++" . > Mais bon, à l'extrème on ne touche plus à rien alors. OK. Mais non. Les devs Apple GnuStep peuvent modifier gcc (c'est évidant). Le problème est l'acception par gcc d'un patch. Je vois quoi sur ce "forum" : - une personne qui se plaint de la lenteur d'acceptation d'un patch. - pas d'explication. c-à-d les raisons du refus, ou l'absence de réponse, etc... Bref il fait une critique sur l'équipe gcc sans réel fondement (du moins sans explication suffisante) : gcc n'est pas réactif d'ailleur le patch [...] on attend depuis <B>LONGTEMPS</B>. Je voulais souligner qu'étant distant du problème je ne vois pas en quoi gcc est critiquable et implicitement rejeter cette critique qui est limite gratuite. Je crois que tout çà tu l'as compris... Mais je dis çà et je ne fais pas avancé le schmilblic (c'est quoi l'orthographe?).

Mon commentaire n'était pas une attaque de ton commentaire mais un complément. Ce que tu as dit est juste.

> Sinon, certaines choses comme les attributes "pure" ou autres de gcc permettent au compilateur de mieux optimiser, et là, via autoconf ...

Ce sont des "bidouilles" (je ne critique pas la qualité de ces outils qui sont dans la pratique indispensables pour un programme multi-plateforme) pour optimiser ou gérer les différences d'implémentation des compilateurs. Si le standard C était parfait (mais ce n'est pas impossible) et les optimisation automatique toujours bonnes (et là il faut réver fort), ces pratiques ne seraient pas nécessaire. Je le répète, dans la pratique elles sont indispensables.

> utiliser des extensions devient donc nécessaire pour écrire un noyau
> les optimisations qui normalement ne changent rien peuvent modifier le comportement du programme, d'où la nécessité de pouvoir les contrôller dans un noyau.

En effet le standard C ne propose pas grand chose pour la programmation bas niveau (spécification d'adresse des variables, etc...) et n'est pas adapté pour le developpement du noyau. Il n'y a que le mot clé "volatile" dans la norme qui peut interresser un développeur noyau et le mot clé "register" (inutile vu le niveau des compilateurs mais toujours là pour des raisons historiques) et "inline" (rend aussi le code plus propre en évitant des macros et ajoute le controle de paramètres) pour optimiser du code.

Tout ceci est parfaitement normal. Le language C doit être intépendant du hard et le noyau s'occupe du hard. Les missions du standard C sont différentes du noyau voir incompatibles. Il faut donc passer par des extensions.

Pour les extensions de gcc qui ne sont pas dans la norme. Je les adore alors que j'ai pas fait de développement bas niveau :-). J'ai bossé sur OSF-1, HP-UX, Solaris et j'ai toujours utilisé gcc/gdb/ddd en parallèle avec les outils standards car ils sont bien meilleurs.

Bref tout ce blabla pour dire que l'on est d'accord.

C'est marrant que quelqu'un est voté [-] à mon post précédent alors que j'ai répondu à une question.

Qui est ce mec, quels sont ces motivations?

Y en a des vraiment bizarre sur linuxfr...