anonyme512 a écrit 498 commentaires

Clair ! Si encore c'était un pack avec StarOffice (et pas OpenOffice), à défaut d'être entièrment libre, il utilise des formats ouverts. Mais là, c'est une invitation à l'inertie...

Ceci dit, cette news, je lui donne un potentiel troll de 1428 MJ.h^-1 environ.

c'est pas lié à l'applet java son problème ?

voila ce qui arrive quand on utilise quelque chose (plus ou moins ) proprietaire et que Microsoft est contre. On n'a pas de solution.

aucun rapport
essaye d'utiliser du PNG, et tu vas rigoler, précisément parce que MS est très mollement pour, et que le support PNG dans IE5.x est entre inexistant et grossièrement incomplet (256 couleurs, pas de canal alpha, etc.).

le problème il est très directement issu de la situation de monopole de Microsoft. Si ils décident de pas implémenter une techno ou de l'implémenter à leur sauce, le standard étant ouvert ou pas, on l'a dans l'os.

pour le reste, c'est clair qu'il y a des web agencies qui abusent, mais, d'après moi, le problème c'est plutot l'ahuri de marketeux qui veut son application comme-ci comme-ça, et que techniquement c'est pas possible en HTML/DHTML/ECMAScript/etc., et que donc les téchos sont forcés de se tourner vers Java, ou, encore pire, vers ActiveX (ça se voit pas trop sur l'internet, mais dans les extranets ou intranets, c'est hélas monnaire courante). il est à noter que, les 9/10 du temps, on aurait pu rendre exactement le même service avec une combinaison HTM/DHTML/ECMAScript/etc. bien sentie, mais bon le marketeux, il veut qu'il y aie un bouton rouge là et pas bleu qui s'allume en même temps que le click sur le bidule qui tourne à gauche, tout en modifiant le menu grisé en haut. Et comme le marketeux c'est lui qui a le pognon, et qu'en conséquence il veut se sentir puissant et indispensable au projet, ben t'es bien obligé de l'écouter, que tu sois ergonome, ingénieur, codeur ou graphiste (bref un mec qui fait réellement le boulot au final..). (okok, ça sent le <ma_vie></ma_vie>)

hmouais. c'est surtout que les applets sont écrites pour la jvm de Microsoft, qui a été modifiée par rapport à celle de Sun, comme chacun sait, ce qui a fait d'ailleurs l'objet d'un procès gagné par Sun.
de plus, cette jvm de microsoft se basait sur java 1, donc c'est complètement dépassé d'un point de vue de l'interface notamment, sauf à utiliser les extensions Microsoft, ce que la plupart des gens ne se privent d'ailleurs pas de faire, d'où ces ennuis.
bien sur, si le plugin java2 était installé par défaut à la place de cette chose, il y aurait déjà moins d'ennuis, mais, chez MS, la tendance est plutot "no-java-at-all-bicoze-dotNet-il-est-better", alors...

Ca dépend ce que tu programmes et comment tu le programmes.
Si c'est pour programmer ton appli, la différence sera à mon avis négligeable.
Par contre, si tu veux programmer LE serveur web qui ne pense pas mais bosse le plus vite possible, c'est clair que le plus près tu es du système et mieux ça vaut. Mais pour vraiment optimiser, faut meme te mettre dans le kernel-space. Ca vous rappelle quelque chose ?
Par contre, si il s'agit de faire autre chose que d'aller bêtement chercher un fichier sur le disque et de le retourner (ce qui reste un besoin, typiquement pour les images), tout programmer près du système est contre productif et n'apporte pas grande chose dans 90% des cas, voire c'est dangeureux (penser à la sécu..). L'idéal étant d'avoir un système mixte où les pages HTML sont générées par un serveur d'application (écrit en Java, Python, ou autre), et un serveur web plus simple en frontal qui rebalance directement les images. Ca aussi ça existe.
Quand à la jvm, il y a un bon paquet de fonctionnalités qui sont appelées directement dans le système (les threads susnommés par exemple), donc je me demande d'où tu tires tes 10 100 1000.. la jvm n'émule pas une NES, une PlayStation ou que sais-je, c'est beaucoup plus limité et beaucoup plus bas niveau.
Ceci dit, entre du code exécuté par exemple en CGI ou directement dans Apache (via un module), il y a déjà une bonne différence. Par contre entre du CGI et un programme tournant en java, les facteurs ne sont clairement pas ceux que tu évoques (ce doit etre au plus un facteur 2-3), sauf à écrire ton CGI en C, de manière méga optimisée et avec du code assembleur dedans éventuellement, mais ça te prendra pas le meme temps, aura pas la meme stabilité, etc. Quand à programmer un module Apache, ça te prendra également beaucoup de temps et de soucis de stabilité.
En résumé, compare des pommes avec des pommes et des oranges avec des oranges, et tu verras que, pour les besoins coté serveur qu'il remplit, java n'est pas considérablement plus lent que les autres options.

Et puis ne pas oublier http://gcc.gnu.org/java/(...) qui permet de pondre du code machine natif....

je me demande d'où sort ce mythe que java ça rame... du passé surement, de l'époque de Java 1, avec ses threads émulés, et autres awt pitoyables.
coté client, c'est certain que même Java 2 (1.2 ou ultérieur) rame, vu que meme swing n'est pas accéléré convenablement niveau affichage. Mais java coté client, c'est quasi complètement mort depuis longtemps, à l'exception d'un ou deux types d'applets relativement largement utilisées (genre applets de chat, etc.), qui sont d'ailleurs souvent pas écrites en swing mais en awt, pour cause de Microsoft :-((
par contre coté serveur, avec la jvm serveur, les native threads (et pas les green threads), et en optimisant correctement le garbage collector, question perfs et stabilité, ça n'a pratiquement rien à envier à des applis natives. Le surcout de la jvm est loin d'etre énorme, et java reste quand même un langage compilé, et non interprété.
de plus il y a aussi gjc pour les plus téméraires...

bon voilà, j'ai marché dans le troll

Lequel screensaver ne bloque surement pas à cause des capacités réseau de X, et ne sert qu'a continuer de faire chauffer ton CPU et bouffer inutilement du jus à ton moniteur qui ne demande qu'a se mettre en veille.

si il a une carte ATI, qu'il aille se renseigner sur GATOS(.sf.net), il y a des gros bugs dans les implémentations DRI/DRM notament sur l'accès DMA. Ce pourrait bien être ça.
Sur certaines Matrox aussi je crois qu'il peut y avoir des ennuis du meme genre.
Sinon si il est en AGP 4X, qu'il essaye de redescendre en 2X, il y a des bugs avec certaines cartes mères, qui sont contournés par les drivers sous Windows, mais bien évidemment pas sous Linux. Un upgrade de BIOS aide parfois à résoudre le problème aussi.

Dans tous les cas, la solution de base à tenter lorsqu'on a le serveur X qui bloque, c'est de virer le "Load dri" du XF86Config. Si ça résoud le problème, alors faut s'intéresser aux drivers DRI/DRM provenant direct du CVS ou bien à des projets tels que GATOS qui fournissent des drivers bien déplombés.
Sinon, mettre à jour vers la dernière version de XFree aide parfois aussi, mais en général ce n'est pas suffisant, il faut encore aller piocher ailleurs (dans les projets susnommés), notamment si on a une ATI AIW ou avec TVOUT.

Bref, en résumé, il y a des milliers de raisons, certaines matérielles, d'autres provenant souvent de la mauvaise intégration de XFree réalisée par certaines distro, qui peuvent expliquer pourquoi le screensaver se fige, et XFree n'est qu'un des coupables possibles...

tu sais quand on va sur kernel.org c pas hyper top mieux non plus, mais l'arbo "Documentation" du noyau, ça, c'est quelque chose ! et chaque gros ensemble du kernel est lui même très bien documenté, la plupart étant gérés comme des projets indépendants avec leurs propres pages, ML, documentation, etc.
Pour XFree, seul le DRI bénéficie de ce traitement....

Ben.. perso j'ai essayé de m'intéresser au problème. A mon avis, un des problèmes majeurs de XFree c'est l'énorme difficulté de "pénétration" du projet.
Pour le Kernel, il est à la fois plus modulaire et plus documenté.
Pour XFree, il faut pratiquement s'intéresser à la totalité pour arriver à bouger un truc dans un coin, et surtout rien n'est correctement documenté. On manque totalement de points d'entrée dans le projet... Chaque extension est (partiellement) documentée indépendament des autres.
Quand aux docs des drivers, ça se limite vraiment au strict nécessaire, et ça frise parfois de la publicité mensongère:
http://www.xfree.org/4.2.1/r1282.html#2(...)
"including hardware accelerated 2D drawing" heu oui, sauf que toutes les extensions 2D ne sont pas complètement accélérées (aux dernières nouvelles, le DMA ne marchait toujours pas pour XVideo, le développeur ayant abandonné le dev en cours de route). Quand au reste de la doc de ce driver elle est.. comment dire... le moindre des modules du noyau linux est mieux documenté que ça, largement mieux (voir nottament http://www.xfree.org/4.2.1/r1283.html#3(...)). Et tout l'ennui c'est que la réponse habituelle (t'as qu'à faire mieux toi meme), ne marche pas, car c'est vraiment très compliqué, ça prend beaucoup de temps de rentrer dedans.

Quand à la Mach64, le machin avait l'air tellement velu que le sieur LT (un finlandais), est venu leur donner un coup de main (notamment sur l'utilisation du DMA, de ce qu'ils avaient droit de faire coté DRM ou pas, comment le faire, etc.). Et pourtant, la Mach64, c'est loin d'être la carte graphique la plus complexe (vu son age entre autres). Ceci dit, je crois pas que ce sera présent dans XFree 4.3.0, aux dernières nouvelles ils n'avaient pas encore tout à fait fini, donc ptet ben qu'oui ptet ben qu'non (mais mes nouvelles datent du début du mois).

Pour finir pour Render, ça a fini par etre le cas, mais il me semble que dans XFree 4.0.x il n'y avait pas d'implémentation par défaut, c'est venu en 4.1.0. Mais là encore je me trompe peut etre.

Pour le reste, je suis d'accord avec toi, mais là on a un problème d'oeuf et de poule: y'aura pas plus de programmeurs tant que ce sera pas mieux documenté, et y'a pas assez de programmeurs pour mieux documenter...
J'espère qu'une distro va en avoir assez pour affecter des gens sur la chose, ce sont les seuls qui peuvent nous sortir du cercle vicieux, mais ça va leur couter cher, et le démarrage risque d'etre long.

Un truc qui manque aussi à mon sens: Que chaque nouvelle extension ait une implémentation par défaut, débrayable par une implémentation optimisée par le driver spécifique quand celui ci est disponible.
L'écriture des drivers est de plus en plus complexe et donc prend de plus en plus de temps (il n'y a toujours pas de support correct pour l'ATI Mach64, qui est antidéluvienne, et la Rage128 a du support 16 et 24 mais pas 32bits, et l'accès DMA est catastrophique - peut etre une limitation hardware qui m'a échappé, mais c'est curieux - , quand aux Radeon, elles sont très diversement supportées. Et je cite ATI parce qu'ils fournissent quasi systématiquement leurs specs 2D et 3D). En conséquence, certains matériels restent de manière totalement absurde de coté pour certaines fonctionnalités (typiquement XVideo, XRender), alors qu'une implémentation par défaut le leur donnerait au prix certes de performances médiocres.
Dans la même lignée, rapprocher DRI/DRM, XFree, FB, etc. ce serait une très bonne chose, car j'ai l'impression que c'est l'une des raisons pour lesquelles les pilotes XFree sont si longs à écrire.

Il faudra que tu m'expliques le liens subtil que tu fais entre l'acte de voler et de copier.

à vrai dire, c'est pour cela que la notion de droit d'auteur a été inventée, de manière à faire d'une oeuvre un bien au même titre qu'un piano.
maintenant, quand on voit comment la plupart des maisons de disques traitent leurs artistes, je me demande qui, du "pirate" ou de la maison de disque, s'assoit le plus sur les droit d'auteurs.
par ailleurs, je pense qu'il ne faut pas non plus critiquer le "kapitalisme" des dérives actuelles. une boite c'est là pour faire du pognon et c'est normal. maintenant elle ne peut vendre qu'au prix où le marché accepte d'acheter. le marché actuel n'accepte plus d'acheter à de tels prix (faut pas déconner, il y a un tel écart entre les couts de reproduction des oeuvres et leur prix résiduel de vente - une fois les auteurs payés quoi, que personne n'a envie de payer ça, et c'est une conséquence de la révolution numérique). donc en conséquence, et c'est là que c'est révoltant: au lieu de faire voter des lois pour maintenir leur activité, ils devraient se soumettre à la loi du marché.

pour moi c'est un troll velu dans le sens où elle fait toute une montagne de ces petites choses. toutes les distros ont leurs petites choses.

l'autre jour je tombe sur un sale bug dans le serveur X de la RH (un problème avec l'utilisation de Xvideo sur certaines cartes). Paf, je soumets un bug. La réponse en retour est: on traite pas ce genre de bug, démerdez vous à obtenir un patch auprès de XFree, et on veut bien l'appliquer pour la prochaine version de RedHat. Résultat, je déconseille à quiconque d'utiliser la RH 7.3 avec une carte ATI non Radeon (encore qu'il y a d'autres emmerdes avec les Radeon), et quand à la RH 8.0, dessus ça ne va pas planter (enfin, ça va moins planter, car ils ont désactivé le DMA, n'ayant pas envie de mettre plus que ça les mains dans le cambouis), mais le out-scaling hardware ne marchera pas non plus, et les perfs vont pas etre terribles. Sur la Mandrake, il y a pas de tels problèmes (sur les versions que j'ai testées).
Seulement la mémère d'OSNews, ça, sur RH elle l'a pas vu, car il faut faire un peu plus de tests pour le voir. Idem pour les quelques bugs de Bluecurve et de KDE-Redhat. Et en fait c'est ça que je lui reproche: ses reproches envers Mandrake sont justifiés, mais il y en a au moins autant à dire envers RH (par ex.). RH aussi se cherche d'ailleurs, mais pour eux c'est moins grave, car ils font du pognon.
Partant de là, pour être équitable, elle aurait dû faire la même part à ces petits problèmes dans les deux revues (voire 3, elle a fait une revue de la SuSE, qui doit avoir les meme emmerdes). Etant donné qu'elle ne l'a pas fait, j'en déduit qu'elle avait envie de se taper un bon gros troll velu envers Mandrake.

Ce qui n'excuse en rien le fait que Mandrake devrait mieux finir et tester leurs distro (notament apprendre à connaitre un peu mieux le mot "intégration"), et se décider un peu mieux sur ce qu'ils voudront faire quand ils seront plus grands.... Mais globalement ça rejoint le problème général de "Linux on the desktop", avec un XFree qui est inchiable (erreurs de design - chaque extension devrait avoir une implémentation par défaut , implémentation laborieuse - drivers buggués incomplets ou non fonctionnels, et le pire: projet hermétique - impossible de "rentrer" dedans), une guéguerre KDE GNOME qui n'en finit plus (encore que l'émulation ça a parfois du bon) avec en toile de fond un problème de licence ([L]GPL), une gestion relativement compliquée de la configuration notamment matérielle, etc.
Les mecs d'Apple, qui ont fait un UNIX ready-for-the-dektop, ils sont pas fous: ya pas de serveur X, ils ont leur propre interface accessible en ObjectiveC et en C, et ils ont éliminé les problèmes matériel en contrôlant le matériel (c'est ça le principal d'ailleurs).

A vrai dire il y a:

CPhone, le plus abouti, qui marche plus ou moins:
http://cphone.sourceforge.net/(...)

et Kmeeting, qui ne fait rien du tout:
http://www.sf.net/projects/kmeeting/(...)

heu minute, je suis pas du tout mandrakiste moi, mais complètement agnostique question distro.

je pointais juste le fait que cette nana avait pondu un gros troll velu.

perso le seul point que je trouve pertinent dans sa revue n'a aucun rapport avec ce qu'elle teste, et ce sont précisément ces interrogations sur le positionnement de Mandrake. c'est vrai que je vois pas bien où ils veulent en venir, mais je crois que eux non plus... rappelez vous cette interview de.. je sais plus Gael Duval je crois, qui disait qu'il verrait bien la création d'une "fondation Mandrake", à la Debian, pendant que MandrakeSoft commercialiserait le produit. de telles hésitations pour une société commerciale c'est assez incroyable.

pour le reste je ne fais pas confiance à cette nana. j'ai installé des Mandrake, (et meme RH et Debian) sur un certain nombre de machines, sans jamais avoir d'ennuis, parfois en simple, parfois en double boot. A l'inverse, j'ai eu les pires emmerdes avec le KDE de RH, et je ne suis pas le seul à en avoir eu, alors que pour elle tout marche bien. je trouve aussi que sur la Mandrake 9.0 drakconf a été énormément amélioré par rapport à avant, et que par rapport au système de config de RH il est bien en avance (je sais pas par rapport à YAST, quand à la Debian, sur ce point, oublions ;-)). Evidemment, il y a encore des progrès à faire, mais je doute que quiconque chez Mandrake en doute, tout comme chez Debian (d'ailleurs le sous projet Debian-Desktop est là pour ça), et même chez RH (qui doit beaucoup progresser dans sa relation avec KDE).

arrête ! l'article sur debianplanet avait peut etre une ou deux lacunes, mais dans l'ensemble ce qu'il dit est vrai, et d'ailleurs il ne s'agit en réalité que de mettre de la colle sur des trucs déjà largement existants, et d'adpoter une attitude consistant à préselectionner un comportement par défaut systématiquement, et qui ne soit pas complètement aberrant.

en revanche, l'article d'OSNews, c'est un gros troll de compèt' et tout le monde est d'accord là dessus. la nana elle a une config' complètement zarb, hyper anormale, et évidemment, elle a des problèmes. encuite, elle érige tout un tas de problèmes secondaires au rang d'énorme bug principal énorme de la vie. de plus, ça fait déjà plusieurs reviews qu'elle divague de la sorte. si elle avait fait une review de Debian récemment, on aurait bien rigolé...

elle peut pas être plus longue à accoucher que la woody, va ;-)

à quand le trolloscope automatique dans templeet ? là, tu as un bon score en effet.

tiens JJB, j'ai trouvé un nouveau sujet de troll: à quand une Debian (stable) enfin compilée avec gcc 3.x ? Pour le code C++ ce serait quand même vachement mieux... et donc pour Qt/KDE, le pied ;-)

mais bon moi je dis ça...

ben oui, justement, pour l'utilisateur de base, ou le mec qui a pas forcément le temps, c'est trop dur. dommage que tu ne le comprennes pas, perso je l'expérimente presque tous les jours. autrement dit: moi, je m'en sors, avec mes méthodes à moi, et puis parce que je suis informaticien et que j'utilise linux depuis un bout de temps. Mets un mec tout juste sorti de Windows devant, et tu vas voir... Evidemment, je prends un extrême, parce que c'est pas forcément non plus le but de la Debian, mais...
c'est ce que je disais avant: c'est bien d'avoir le choix, à condition d'avoir aussi celui de la simplicité.

MAI SAI TRO DUUUUUUUUUR !!!!!! lol kissss mdrrrrrr ptdr
là c'est bon, tu te discrédites tout seul, rien à toucher, ça résume bien ta pensée.

quel dommage qu'il y ait pas les votes, mais bon:
[+++++++++++++++++]

c'est très exactement ce qui manquait à la Debian.

Il y a eu quelques revues de cette distro qui ont été mal perçues, car la plupart des fans croyaient y voir simplement une attaque de l'installateur Debian (qui n'est pas top, mais un installateur ne fait pas une distro).

En revanche, ça sert à rien d'ergoter sur la puissance d'apt-get, la Debian est une plaie à configurer, ce qui rend également pénible les mises à jour. La configuration de XFree en est un bon exemple (cool, j'ai fait apt-get install xfree et ça me descend et m'installe tout.. mais heu, j'ai un clavier pc104 103 105 ? ma carte graphique c'est une 3D Prophet, c'est quel driver ? etc.). Le merdier (ya pas d'autre nom désolé) des 20 000 version de kernel-image un autre bon exemple (alors, vous voulez du 2.4 ou du 2.2 ? avec ou sans alsa ? pour quelle architecture ma bonne dame ?). Quand au support matériel pfuuu !!! Ce qui me permet de m'en sortir d'habitude sans trop me faire de noeuds au cerveau, c'est... kudzu et sndconfig (suivi d'un update-modules). no comment.
Ce genre de choix c'est bien (même très bien) pour un utilisateur averti. Pour un utilisateur de base, ou un utilisateur qui n'a pas trop le temps, c'est un handicap. Donc longue vie à ce sous-projet qui apportera le seul choix qui manque à la Debian pour être parfaite: le choix de la simplicité !

Tout à fait d'accord.

En fait, tout ça me rappelle un peu ce qui s'est passé au moment ou Netscape a ouvert son code source:
Les développeurs, la communauté, etc. se sont rendus compte que c'était .. disons.. de la merde. Donc ils se soont dit qu'ils allaient repartir du début.
Et là nouveau problème, ils se sont aperçus qu'il leur manquait un paquet d'outils pour refaire convenablement un tel développement.
Le projet Mozilla a donc accouché de Bugzilla (entre autres). Mais en contrepartie, il en a salement pris dans la vue en terme de délais: pendant que les développeurs font ce genre de développements "annexes", ils ne font pas le développement central.
Le cas de Linux est donc assez épineux de ce point de vue, car on est dans une phase assez critique où le support matériel est plus que jamais important. Doit-on perdre du temps sur Subversion, de manière à avoir un logiciel de gestion des sources qui soit libre, au détriment de l'implémentation plus que nécessaire de certains modules (ou du moins une augmentation considérable des délais) ?
Les délais c'est important, car c'est aujourd'hui que Linux doit convaincre. Demain, avec Palladium & Co., il sera trop tard.
L'attitude de Stallman, c'est exactement la même depuis le début: il s'en fiche des délais, pourvu d'être conforme à son idéologie tout le temps. Parfois c'est bien, mais force est de constater que le système GNU n'est pas tout à fait une réalité (même si le Hurd, doucement..), et que le "projet" de la FSF a quand même été vachement aidé par Linus et ses potes, ainsi que par des boites commerciales sans rapport avec la FSF (distros, trolltech, IBM, Sun, etc.)
Bref, en conclusion, c'est quand même un beau sujet à troll, vu que les deux (RMS et LT) ont raison à leur façon...

on peut faire de la manif bien intelligente. Ceux qui ont suivi les SansNous se souviennent peut etre. Evidemment, faut éviter les banderolles avec des couleurs CGT/PCF/FO et les merguez grillées, mais monter un stand sauvage devant, voire deux stands: un GNU/Linux, et un plus anti-brevets, type eurorights...

Ca, je demande à voir.
Je me disais que KDE était lent jusque là et que c'était dommage.
Et puis, RH s'est décidé à fournir des packages officiels et corrects et testés un minimum pour KDE 3.0.4 pour ma RH 7.3, de manière totalement inattendue (c'est la première fois qu'ils le font, d'habitude soit yen a pas d'officiels, soit ils marchent pas).
Donc, je télécharge, je fais un rpm -Fvh et miracle ça passe !
Après une relance de X, je teste et re-surprise: qu'est ce que c'est rapide !!! Certes l'ouverture de session est toujours un petit peu longue, mais après, c rapide et hyper stable.
Ma conclusion: tout dépend de comment le bazar a été compilé.

en fait, il n'y a pas que le Sagem qui soit multiplaque, BeWan et Netgear ont aussi des modmes ou routeurs ADSL multiplaques, dans toutes les gammes de prix, et souvent compatibles Linux en plus.
de plus, je sais pas chez ECI, mais les modems Alcatel (Speed Touch Home/Pro), sont également multiplaque, moyennant une mise à jour du firmware (qui revient à deux cliquouilles dans une interface web).
dernière remarque: qqun a-t-il testé les fameux modems Sagem ? si c'est de la même qualité que leurs téléphones portables (batterie qui dure moins de 8h en veille au bout de 9 mois-un an d'utilisation, plus divers autres problèmes - il parait que ça s'arrangeait sur les derniers modèles), ça promet...

heu, c'est aussi en gros ce que je dis, mais je ne suis pas très clair et surtout pas assez exhaustif.

on a d'un coté le parquet (censé agir dans l'intérêt du peuple français), et de l'autre la cour (censé agir dans l'intérêt de la justice et en regard de la loi), et enfin les parties civiles (Tati et Kitetoa).

en première instance, la cour a condamné Kitetoa à une amende de principe, en grosse partie parce que la loi étant ce qu'elle est, le juge ne pouvait pas vraiment faire autrement. Il s'agit d'un jugement assez normal, car au regard de la loi, il y avait bien eu infraction, enfin du moins dans l'interprétation qu'en a fait le juge. Là c'est assez compliqué de savoir pourquoi il a rendu un jugement dans ce sens, mais je ne serais pas surpris de découvrir que c'était plus ou moins intentionnel afin de provoquer un appel du jugement, le juges sont coutumiers du fait quand une loi a une zone de flou. Le (relativement) faible montant de l'amende milite en ce sens, mais bon, je suis pas dans la tête du juge.

A la suite de quoi, le parquet, pour éviter que ce genre de débordements ne continuent, a fait appel, de manière d'une part d'annuler la condamnation, et d'autre part d'obtenir un arrêt de la cour d'appel, afin de changer la loi via la jurisprudence. en fait, il ne s'agit pas exactement de changer la loi, mais plutôt d'en préciser son interprétation.

Bon, maintenant, je ne suis pas avocat, j'ai juste fréquenté ce milieu à une époque. C'est assez intéressant, d'autant que les avocats français sont fondamentalement différents des américains. Si le sieur Soufron (c bien ça ?) passe dans le coin, ce serait sympa qu'il en dise un peu plus.