Le probleme c'est que lorsqu'on propose de changer un systeme qui fonctionne (certainement pas parfaitement, mais les choses tournent) il faut avoir faut au moins le minimum de boulot et etre capable de repondre aux principales objections. Si tu proposes de tout changer, que tu n'as aucune reponse credible a plein de questions et que tu te faches lorsqu'on te le fait remarquer, c'est pas tres credible.
Je ne sais pas ce que vous avez contre ça, ça ne me semble pourtant pas bien difficile
y’a qu’à faut qu’on!
Est ce qu'on prend en compte les filiales? Quid des entreprises aides par un fond d'investissement detenu en majorite par la boite d'origine. Et les brevets vendus a des groupes de PI qui s'en servent pour recuperer de l'argent?
Plus rigolo, qu'est ce qui se passe quand 2 boites qui investissent dans le logiciel libre se font un proces? Tu prends celle qui donne 'le plus' au logiciel libre? Et si une boite fait pression sur des clients et fournisseurs et signe des accords de license, c'est une attaque contre le LL? Et si la boite en face decide d'attaquer, c'est de la defense?
Et puis soyons serieux, la majorite des attaques en PI (que ce soit avec du brevet logiciel ou pas) ca ne va que tres rarement au proces. La petite boite ou la boite pas assez riche pour s'engager dans des annees de proces se fait imposer un accord dont on n'entendra jamais parler.
Meme si tu arrives a demeler tout ca, ca va tellement limiter les boites potentielles que tu te retrouves dans la situation actuelle. Il est presque certains que toutes les grosses boites citees en exemple ont a un moment ou un autre utiliser leurs brevets pour etouffer la concurrence, sans que ca depasse necessairement le stade des menaces et sans que personne n'en entende jamais parler.
Cite-moi une seule attaque de brevet de la part de Google envers une entreprise qui ne l'a pas attaquée en premier depuis la naissance de Google.
Motorola, ca te dis quelque chose?
Une question de date.
Voir au dessus la question de l'attaque preventive contre une boite qui menace les fournisseurs et clients.
Normalement, il y a des "commissions" pour débattre justement car le monde n'est pas tout blanc ou tout noir.
On parle pas de faire tout blanc ou noir, la situation actuelle est deja plus ou moins dans le gris. La question c'est de savoir si on deplace le curseur ou pas dans une certaine direction.
Parce que soit Chris Wilson accepte de merger des patchs de merde et on peut se poser des questions, soit tu es de mauvaise foi (en agglomérant le patch qui est le sujet du journal et des patchs de Canonical que tu considères cradingues mais que tu ne décris pas)
Bon, je sais pas si ta boite est en France, mais je dirais que c'est pas tres representatif de la majorite des profils sur le marche (en France) :)
Par curiosite, tu en as beaucoup de profils qui tiennent la route en entretien? J'ose esperer que vous recherchez des gens avec deja beaucoup d'experience et qu'ils sont tres bien payes (parce qu'un inge junior C++ avec les competences listees et des connaissances reseau & DB, qui accepte d'etre paye des clopinettes, ca doit pas courir les rues).
va jeter un oeil a ce que Hex-Rays peut faire a ce niveau
On a deja eu cette conversation il y a un moment. En plus d'etre completement ignorant sur le sujet, il n'a aucun desir de se renseigner. De toute facon, c'est pas libre donc c'est comme si ca n'existait pas. Repeter les memes betises a chaque fois ne semble pas etre specialement genant non plus.
Peut-etre qu'appliquer le comportement de Linus aurait plus de succes? Apres tout, de l'auteur des depeches sur le noyau on est en droit d'attendre un peu plus que ca. Lorsqu'il parle sur des sujets qu'il ne maitrise visiblement pas (reverse-engineering, programmation C, securite) ou trolle sur LWN, un bon petit torrent d'insultes lui fera voir la lumiere et puis je suis sur qu'il trouvera ca humoristique.
Je pense que j'ai mal formule, ils ne s'amusent pas a mettre un score pour une attaque a la bombe. C'est juste que c'est parmi les nombreuses choses qu'ils retiennent pour le poster sur Facebook et pas vraiment pour le deplorer.
Je parlais évidement des gens qui sont aujourd’hui actif dans le mouvement.
Sur le mur Facebook du principal mouvement antifa du coin:
- on se rejouit que des suprematistes se soit fait tabasser
- on s'amuse d'un incendie criminel contre les locaux d'un parti d'extreme droite
- on celebre la mort de militant nationalistes
- on note une attaque a la bombe dans les locaux d'une association fasciste
Le tout ponctue de "si vous avez des informations sur X, ne le dites pas la police… Dites le nous." qui laissent peu de place a l'imagination.
(je suppose qu'on trouve tres exactement la meme chose dans le camp d'en face, mais ca pue deja assez comme ca chez les antifa, j'ai vraiment pas envie d'aller verifier).
Dans ce que rapporte les medias, il faut bien distinguer 2 choses:
1- Le cas de Clement, victime d'une agression. L'enquete etant en cours, il est encore difficile de savoir avec assurance comment les evenements se sont echaines, mais meme si son groupe a commence la joute verbale, ca ne pourra jamais ni expliquer ni excuser ce qui s'est passe. Sur ce point la, les "c'est de sa faute" ou "il l'a bien cherche" sont effectivement indefendables.
2- Les groupes antifa et leur actions qui se prennent un gros coup de projecteur. Sur ce point la, c'est pas forcement tres reluisant, on en arrive a justifier les actions violentes par detestation de l'autre. Je porte pas particulierement les fachos dans mon coeur, mais de la a aller faire la castagne… Disons que ca necessite une certaine disposition d'esprit pour se sentir investi d'une mission pour aller casser la gueule au groupe d'en face - le degre zero de la reflexion politique.
Evidemment il y a tout interet a amalgamer les deux pour surtout ne pas avoir a expliquer les actions violentes des deux cotes.
Les projets ou tu peux faire ce que tu veux et ou tu es "proprietaire" de ton perimetre et peut completement ignorer les retours des autres developpeurs c'est pas non plus super courant dans le libre (avec des contre-exemples flagrants comme la glibc ou ffmpeg/libav). Dans tous les projets ou je participe, si je m'amusais a faire ca, je me ferais ejecter rapidement.
Le probleme en question est quand specifique a l'organisation de Debian ou chaque developpeur est tres independant. Ca marche bien tant que les personnes veulent bien travailler ensemble et sont pret a passer le relais quand leur temps libre devient limite. Dans le cas contraire, ca donne l'episode Python ou le comite technique a mis 2 ans et demi pour rendre un avis demandant gentillement au developpeur d'essayer de travailleur avec les autres.
formats des documents bureautiques de base, la messagerie instantanée, la visioconférence, les réseaux sociaux, les calendriers, etc.
Le jour ou le format de documents reconnu par l'etat c'est OOXML, que le codec video que tu doit prendre en charge c'est H264 et que la loi t'obliges a garder le support pour une periode de 10 a 15 ans pour tout appareil vendu dans le commerce sous peine d'amendes, tu rigoleras moins.
Et pourquoi s'arreter la, si tu veux vendre du materiel ou du services, tu te dois d'assurer l'interoperabilite. Tu fais plus tourner le logiciel d'il y a 4 ans quand la loi a ete ecrite? Dommage, mais tu peux pas vendre ou distribuer ton matos ou ton OS, ils sont pas aux normes.
Ca depend a qui tu les vends. Les organisations qui font ca de maniere ouverte bossent generalement avec les gouvernements, ca aide :)
Et puis on trouve plein de boites de secu qui ne vendent pas l'exploit en lui-meme mais le correctif, juste pour leur clients. On peut trouver ca pas gentil (suivant sa morale) mais ca va etre dur de prouver que c'est illegal.
Du coup pour les thèmes, je me demande si tu parle des thèmes de gnome ou de gtk.
Hi, I'm the guy that has spent the last two years breaking themes with every
release. This is 100% deliberate and I intend to continue this process for the
forseeable future. […]
[…]
(4) After those decisions were made, no time was spent on even thinking about
compatibility, because there were no people even bringing up the topic, let
alone willing to work on it.
Les (le ?) développeurs de gtk à voulu casser la compatibilité pour de raisons très précises notamment réduire la dette technique qui commençait à peser trop lourd pour le peu de ressources de se projet
Casser la compatibilite entre GTK2 et GTK3, ca se comprend parfaitement (en dehors meme du nombre de personnes disponibles pour bosser dessus). Par contre il faut voir qu'ils s'amusent aussi a casser la compatibilite entre versions mineures de GTK (genre les themes). Et c'est exactement la meme chose pour les extensions qui petent aleatoirement entre versions (meme si il y a un peu plus d'excuses dans ce cas la).
Apres on peut trouver qu'il y a plein d'explications techniques, mais le fait que sur tous ces sujets plusieurs des devs Gnome ont clairement dit qu'ils ne voulait pas de ces fonctionnalites laisse planner le doute sur leur volonte de chercher une solution qui ne casse pas la compatibilite.
Le moteur du jeu est maintenant sous licence libre. Les donnees n'ont pas change de licence et ne sont pas liberees (ni mises gratuitement a disposition).
ou écumer les sites de warez pour avoir les données graphiques et sonores ?
C'est drole de parler de ca dans un meme message qui reclame des donnees libres (surtout que c'est dispo a la vente tres tres facilement)
mais est-ce que ça n'implique pas des temps de chargement des pages plus longs pour cause de code javascript plus volumineux
Il y a plusieurs problemes en fait:
la taille du code et des donnees a telecharcher (ceux qui se plaignent au dessus de la taille des libs js vont pleurer avec des fichiers JS de 20Mo ou plus :P): on peut distribuer sous forme d'application et stocker tout ca en cache local sur les navigateurs recents (mais c'est souvent limite a 5Mo). C'est une problematique plus large en fait: comment distribuer des applications qui font plusieurs Go dans un environnement ou les utilisateurs sont habitues a un chargement quasi instantane. Il y a plein de developpements interessants dans ce domaine (streaming, application cache, etc.)
le temps de compilation du code et la memoire consommee (le code asm.js est compile AOT): Mozilla a prevu d'ecrire un parseur specifique et optimise pour asm.js, vu qu'apparemment les tests sur des fichiers de 50Mo voient la conso memoire titiller la barre des 1.5Go (ouch!). Et comme pour les donnees, on peut essayer de mettre en cache une partie du code compile.
P*** mais non ! On te montre un JS qui est garanti comme étant plus performant que la moyenne partout.
Oui, et comme on oublie de bien preciser que ca ne concerne pas 99% des cas d'utilisation du JS et que pour les 1% restant (les jeux et les applis qui ont besoin de perfs) ca risque de necessiter le support complet asm.js de toute facon, ca reste de la communication.
Ce que tu ne sembles pas comprendre c'est que gagner quelques % de perfs c'est pas forcement desirable si les contreparties sont trop importantes. En particulier:
base de code existante a convertir
sous-language optimise pour les compilateurs et pas du tout pour l'ecriture a la main
support pour le developpement (debugger natif->asm.js, ide, etc.) pour l'instant presque inexistant
Si on oublie de parler de tout ca, on pense que asm.js c'est la solution magique juste parce que c'est un peu plus rapide, alors que pour le moment c'est reserve uniquement a la compilation via un generateur de code (ou a du code qui doit etre tres optimise, mais qui ne concerne certainement pas la totalite d'une appli web).
Bref, ma critique initiale c'est pas que c'est inutile parce que c'est juste un peu plus rapide que du code JS, c'est que pour la cible (les jeux avec grosse demande de perf) etre juste un peu plus rapide que du code JS c'est deja redhibitoire. Par consequent pointer ca comme un gros avantage est mensonger puisque des applis qui ont besoin de grosses perfs seront de toute facon inutilisables sans un support natif.
C'est quoi que tu comprends pas ? Plus performant que du JS classique ou partout ?
Asm.js est performant, partout, tout le temps, qu'il vente, qu'il pleuve ou qu'il neige.
Mais on s'en fout, ca n'a jamais ete la question.
L'assembleur est performant, partout, tout le temps, qu'il vente, qu'il pleuve ou qu'il neige. Le C est performant, partout, tout le temps, qu'il vente, qu'il pleuve ou qu'il neige.
Voila, c'est a peu pret ce que tu racontes. Pas besoin de t'expliquer ce que je pense des gens qui affirment betement ce genre de chose je pense.
Le code asm.js est plus rapide que son équivalent sémantique utilisant l’entièreté du vocable JS. Inconditionnellement.
Qu'est-ce qui te choque tant la dedans ? C'est pourtant simple.
Dans la cas de figure qui nous preoccupe (moteur de jeu recent avec des grosses demandes en perf), ca nous fait une belle jambe que compiler vers asm.js / JIT permettent de grappiller quelques % par rapport a du javascript idiomatique / JIT lorsque l'abscence de support AOT te donne juste un slideshow.
Comme dit plus haut, la partie "c'est du javascript ca va tourner pareil sur les navigateurs qui n'ont pas de support asm.js", c'est de la comm' (en gros c'est vrai tant qu'il n'y a aucune application qui necessite les perfs fournies par le support asm.js)
C'est déjà fait dans Nightly et c'est un compilateur ou plutôt une nouvelle passe de compilation ajoutée à IonMonkey (initialement appelée OdinMonkey). L'intérêt d'être un sous-ensemble de JavaScript reste que le code asm.js tourne sans condition sur tous les navigateurs.
Cough cough…
Custom asm.js parser (bug 854061) (estimated time: 2 months): create a new parser (reusing the tokenizer) that only recognizes asm.js, falling back to the general purpose parser on any failure. This would avoid creating 1.5GB of ParseNodes for 50MB asm.js files and also making parsing a lot faster. https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey
Je ne sais pas ce que tu veux dire par «en mode interprété».
Les navigateurs qui n'implementent pas le support direct pour asm.js et donc ne font pas une passe de compilation AOT dessus doivent executer le code en mode interprete/JIT (pareil que du code qui ne passerait pas la validation pour les navigateurs avec le support d'ailleurs). Et c'est evidemment beaucoup beaucoup plus lent, sinon faire son propre parseur et compilateur AOT n'aurait aucun interet.
J'ai du mal à comprendre ce que tu cherches à critiquer ici
Le message auquel je reponds juste au dessus (dont l'auteur n'a pas du prendre le temps de lire l'intro de la spec), ainsi que la partie de ton journal qui dit "Le code asm.js utilise les mêmes APIs DOM que n'importe quel code JavaScript."
J'ai peut-etre compris la spec completement a l'envers, mais quand je lis les autres commentaires dans le journal j'ai l'impression que les gens mettent un peu tout et n'importe quoi dans l’appellation 'APIs DOM' (et melangent WebGL, JavaScript 'normal' et modules asm.js).
Qu'est ce que tu entends par "utilise les memes APIs"? Qu'un module asm.js peut utiliser une grande partie des APIs DOM (sans tourner en version interpretee)?
Non content d'introduire son propre langage intermédiaire, ce qui est inutile comme je viens de l'expliquer
Disons que pour faire quelque chose du niveau de asm.js, c'est en effet pas forcement interessant de specifier son propre format de bytecode. Cela-dit, Mozilla prevoit d'ecrire un parseur separe pour les modules asm.js, du coup on voit plus trop l'interet d'etre un sous-ensemble de javascript.
Finalement c'est plutot pour des raisons de strategie: etre pret rapidement en reutilisant l'infrastructure existante, communiquer sur le fait que ca marche partout en mode interprete (on rigole, parce que le moteur Unreal 3/4 qui tourne avec la version interpretee en haute resolution, j'attends quand meme de voir).
C'est tres probablement une strategie gagnante. Au niveau technique j'ai tendance a trouver ca un peu degeu, mais si ca permet une adoption par tous les navigateurs rapidement, ca se discute pas :)
Native Client introduit un langage intermédiaire séparé pour chaque architecture (le code machine)
C'est pour ca que Google bosse sur PNaCl depuis un moment (oui, c'est pas si facile que ca et c'est toujours pas pret - voir au dessus pour mon avis sur la meilleure strategie).
Native Client introduit aussi son propre ensemble d'APIs, Pepper, remplaçant les APIs DOM, ce qui sape l'influence des autres développeurs de navigateurs
Ce qui gene Mozilla c'est qu'ils n'ont aucun controle dessus, pas le fait que ca soit de nouvelles APIs. Si lorsque PNaCl est stabilise Google essaye de standardiser tout ca, Mozilla serait toujours aussi contre.
J'ajoute que cet article est vraiment mon opinion personnelle
Si j'ecris un journal pour parler des trucs biens que fait ma boite et critiquant la concurrence (developpement ferme, pas standard), ca sera peut-etre mon avis personnel mais ca fera la comm' de ma boite.
Ce que tu decris dans ton journal est tres interessant (j'ai pertinente), mais les parties non techniques s'averent etre exactement l'axe de comm' de Mozilla. Ca ne veut pas dire que tu repetes betement la comm' mais:
quand tu bosses dans une boite, c'est normal de discuter ou de se renseigner sur ce que font les collegues et d'etre enthousiasme par les trucs innovants sur lesquels ils bossent. Les-dis collegues ne vont pas evidemment pas dire que ce qu'ils font c'est tout pourri et que la concurrence fait mieux.
Mozilla et Eich critiquent tres fortement et depuis longtemps NaCl et sont categoriquement oppose au concept (surprise surprise).
Bref, ca a beau etre ton avis perso, c'est aussi dans la ligne de l'entreprise (et ne soyons pas naifs, en tant qu'employee de Mozilla si tu etais tres critique vis a vis de la strategie de ta boite, tu viendrais pas poster sur LinuxFR).
Desole si ca fait tres critique envers ta demarche, je pointe juste que certaines des critiques que tu fais n'ont rien d'objectif. J'ai d'ailleurs le meme avis sur les personnes qui par exemple sont toujours promptes a critique web/internet et deviennent mysterieusement silencieuses des que ca parle de sauvegarde de la vie privee et tracking des utilisateurs…
Donc continue a poster des journaux sur ce que fait Mozilla, je les lis avec plaisir :)
As-tu regarde la spec? La difference entre un module asm.js de quelques megas et un gros bloc de bytecode est pas tres grande, hein.
Et quand on parle de sous-ensemble de javascript, c'est un sous-ensemble tellement reduit et optimise pour etre compile (pas pour etre ecrit a la main) avec des ajouts a la lib juste pour optimiser certains cas super rare dans du code "normal" mais qui reviennent beaucoup dans du code optimisee par un compilateur.
En gros, c'est operations numeriques sur un bloc de memoire statique (et c'est tout). Va donc voir la sortie d'un bloc ASMJS par Emscripten et reviens nous expliquer la difference fondamentale avec du bytecode.
Par ailleurs, si on regarde les plans de Mozilla (AOT force, parseur separe pour le code asm.js), ca ressemble quand meme tres fortement a utiliser ce sous-ensemble du JS comme representation intermediaire plutot que de redefinir leur propre format de bytecode.
C'est pas une mauvaise idee et c'est une bonne alternative a NativeClient, mais il faudrait pas non plus prendre la comm' de Mozilla pour quelque chose d'objectif. Les petits arrangement avec la verite et la petite histoire du gentil Mozilla et les standards contre le mechant Google dans ce journal, c'est joli mais c'est quand meme du BS de premiere.
[^] # Re: Licence ? Devil's in the deails ?
Posté par Littleboy . En réponse au journal Effort d'ouverture de la part de Nvidia. Évalué à 1.
C'est quoi la difference avec Intel et AMD a ce niveau?
[^] # Re: Du beau...
Posté par Littleboy . En réponse au journal Benoît Hamon a encore frappé. Évalué à 0.
Le probleme c'est que lorsqu'on propose de changer un systeme qui fonctionne (certainement pas parfaitement, mais les choses tournent) il faut avoir faut au moins le minimum de boulot et etre capable de repondre aux principales objections. Si tu proposes de tout changer, que tu n'as aucune reponse credible a plein de questions et que tu te faches lorsqu'on te le fait remarquer, c'est pas tres credible.
[^] # Re: Respectons les valeurs fondamentales du Logiciel Libre
Posté par Littleboy . En réponse à la dépêche RFC: Révision de la politique de sponsoring des RMLL. Évalué à 3.
y’a qu’à faut qu’on!
Est ce qu'on prend en compte les filiales? Quid des entreprises aides par un fond d'investissement detenu en majorite par la boite d'origine. Et les brevets vendus a des groupes de PI qui s'en servent pour recuperer de l'argent?
Plus rigolo, qu'est ce qui se passe quand 2 boites qui investissent dans le logiciel libre se font un proces? Tu prends celle qui donne 'le plus' au logiciel libre? Et si une boite fait pression sur des clients et fournisseurs et signe des accords de license, c'est une attaque contre le LL? Et si la boite en face decide d'attaquer, c'est de la defense?
Et puis soyons serieux, la majorite des attaques en PI (que ce soit avec du brevet logiciel ou pas) ca ne va que tres rarement au proces. La petite boite ou la boite pas assez riche pour s'engager dans des annees de proces se fait imposer un accord dont on n'entendra jamais parler.
Meme si tu arrives a demeler tout ca, ca va tellement limiter les boites potentielles que tu te retrouves dans la situation actuelle. Il est presque certains que toutes les grosses boites citees en exemple ont a un moment ou un autre utiliser leurs brevets pour etouffer la concurrence, sans que ca depasse necessairement le stade des menaces et sans que personne n'en entende jamais parler.
Motorola, ca te dis quelque chose?
Voir au dessus la question de l'attaque preventive contre une boite qui menace les fournisseurs et clients.
On parle pas de faire tout blanc ou noir, la situation actuelle est deja plus ou moins dans le gris. La question c'est de savoir si on deplace le curseur ou pas dans une certaine direction.
[^] # Re: Un petit rappel
Posté par Littleboy . En réponse au journal Intel boycotte officiellement le serveur d'affichage Mir. Évalué à 2.
Tu parles du patch pour le pilote Intel?
Parce que soit Chris Wilson accepte de merger des patchs de merde et on peut se poser des questions, soit tu es de mauvaise foi (en agglomérant le patch qui est le sujet du journal et des patchs de Canonical que tu considères cradingues mais que tu ne décris pas)
[^] # Re: Mes questions
Posté par Littleboy . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 6.
Bon, je sais pas si ta boite est en France, mais je dirais que c'est pas tres representatif de la majorite des profils sur le marche (en France) :)
Par curiosite, tu en as beaucoup de profils qui tiennent la route en entretien? J'ose esperer que vous recherchez des gens avec deja beaucoup d'experience et qu'ils sont tres bien payes (parce qu'un inge junior C++ avec les competences listees et des connaissances reseau & DB, qui accepte d'etre paye des clopinettes, ca doit pas courir les rues).
[^] # Re: Et tu aurais voulu qu'ils fassent quoi d'autre ?
Posté par Littleboy . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 3.
On a deja eu cette conversation il y a un moment. En plus d'etre completement ignorant sur le sujet, il n'a aucun desir de se renseigner. De toute facon, c'est pas libre donc c'est comme si ca n'existait pas. Repeter les memes betises a chaque fois ne semble pas etre specialement genant non plus.
Peut-etre qu'appliquer le comportement de Linus aurait plus de succes? Apres tout, de l'auteur des depeches sur le noyau on est en droit d'attendre un peu plus que ca. Lorsqu'il parle sur des sujets qu'il ne maitrise visiblement pas (reverse-engineering, programmation C, securite) ou trolle sur LWN, un bon petit torrent d'insultes lui fera voir la lumiere et puis je suis sur qu'il trouvera ca humoristique.
[^] # Re: Encourageant !
Posté par Littleboy . En réponse à la dépêche Sous le capot de la beta LibreOffice 4.1. Évalué à 4.
Il manque quand meme une section 'douchebag' dans la news avec la traduction des commentaires de robweir sur LWN.net
[^] # Re: Mir, the Canonical CLA and skewing the playing field
Posté par Littleboy . En réponse à la dépêche MariaDB dénonce un jeu de licence par Oracle. Évalué à 4.
Ca embete les grosses boites proprio avec des brevets qui voudrait distribuer Mir.
C'est quand meme drole de trouver des libristes couiner la dessus.
[^] # Re: Il y a militant et militant...
Posté par Littleboy . En réponse au journal À propos de militantisme…. Évalué à 0.
Je pense que j'ai mal formule, ils ne s'amusent pas a mettre un score pour une attaque a la bombe. C'est juste que c'est parmi les nombreuses choses qu'ils retiennent pour le poster sur Facebook et pas vraiment pour le deplorer.
[^] # Re: Il y a militant et militant...
Posté par Littleboy . En réponse au journal À propos de militantisme…. Évalué à 3.
Sur le mur Facebook du principal mouvement antifa du coin:
- on se rejouit que des suprematistes se soit fait tabasser
- on s'amuse d'un incendie criminel contre les locaux d'un parti d'extreme droite
- on celebre la mort de militant nationalistes
- on note une attaque a la bombe dans les locaux d'une association fasciste
Le tout ponctue de "si vous avez des informations sur X, ne le dites pas la police… Dites le nous." qui laissent peu de place a l'imagination.
(je suppose qu'on trouve tres exactement la meme chose dans le camp d'en face, mais ca pue deja assez comme ca chez les antifa, j'ai vraiment pas envie d'aller verifier).
[^] # Re: Il y a militant et militant...
Posté par Littleboy . En réponse au journal À propos de militantisme…. Évalué à 10.
Dans ce que rapporte les medias, il faut bien distinguer 2 choses:
1- Le cas de Clement, victime d'une agression. L'enquete etant en cours, il est encore difficile de savoir avec assurance comment les evenements se sont echaines, mais meme si son groupe a commence la joute verbale, ca ne pourra jamais ni expliquer ni excuser ce qui s'est passe. Sur ce point la, les "c'est de sa faute" ou "il l'a bien cherche" sont effectivement indefendables.
2- Les groupes antifa et leur actions qui se prennent un gros coup de projecteur. Sur ce point la, c'est pas forcement tres reluisant, on en arrive a justifier les actions violentes par detestation de l'autre. Je porte pas particulierement les fachos dans mon coeur, mais de la a aller faire la castagne… Disons que ca necessite une certaine disposition d'esprit pour se sentir investi d'une mission pour aller casser la gueule au groupe d'en face - le degre zero de la reflexion politique.
Evidemment il y a tout interet a amalgamer les deux pour surtout ne pas avoir a expliquer les actions violentes des deux cotes.
[^] # Re: encore plus simple
Posté par Littleboy . En réponse à la dépêche Attention au dépôt debian-multimedia.org !. Évalué à 2.
Les projets ou tu peux faire ce que tu veux et ou tu es "proprietaire" de ton perimetre et peut completement ignorer les retours des autres developpeurs c'est pas non plus super courant dans le libre (avec des contre-exemples flagrants comme la glibc ou ffmpeg/libav). Dans tous les projets ou je participe, si je m'amusais a faire ca, je me ferais ejecter rapidement.
Le probleme en question est quand specifique a l'organisation de Debian ou chaque developpeur est tres independant. Ca marche bien tant que les personnes veulent bien travailler ensemble et sont pret a passer le relais quand leur temps libre devient limite. Dans le cas contraire, ca donne l'episode Python ou le comite technique a mis 2 ans et demi pour rendre un avis demandant gentillement au developpeur d'essayer de travailleur avec les autres.
[^] # Re: La guerre des écosystèmes continue
Posté par Littleboy . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à -1.
Le jour ou le format de documents reconnu par l'etat c'est OOXML, que le codec video que tu doit prendre en charge c'est H264 et que la loi t'obliges a garder le support pour une periode de 10 a 15 ans pour tout appareil vendu dans le commerce sous peine d'amendes, tu rigoleras moins.
Et pourquoi s'arreter la, si tu veux vendre du materiel ou du services, tu te dois d'assurer l'interoperabilite. Tu fais plus tourner le logiciel d'il y a 4 ans quand la loi a ete ecrite? Dommage, mais tu peux pas vendre ou distribuer ton matos ou ton OS, ils sont pas aux normes.
[^] # Re: Silent patching
Posté par Littleboy . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 1.
Ca depend a qui tu les vends. Les organisations qui font ca de maniere ouverte bossent generalement avec les gouvernements, ca aide :)
Et puis on trouve plein de boites de secu qui ne vendent pas l'exploit en lui-meme mais le correctif, juste pour leur clients. On peut trouver ca pas gentil (suivant sa morale) mais ca va etre dur de prouver que c'est illegal.
[^] # Re: MATE est-il devenu obsolète ?
Posté par Littleboy . En réponse à la dépêche Le bureau MATE fait un grand pas en avant, avec sa version 1.6. Évalué à 3.
Encore? C'est mon premier commentaire sur ce fil.
Hi, I'm the guy that has spent the last two years breaking themes with every
release. This is 100% deliberate and I intend to continue this process for the
forseeable future. […]
[…]
(4) After those decisions were made, no time was spent on even thinking about
compatibility, because there were no people even bringing up the topic, let
alone willing to work on it.
https://bugzilla.gnome.org/show_bug.cgi?id=687752
[^] # Re: MATE est-il devenu obsolète ?
Posté par Littleboy . En réponse à la dépêche Le bureau MATE fait un grand pas en avant, avec sa version 1.6. Évalué à 5.
Casser la compatibilite entre GTK2 et GTK3, ca se comprend parfaitement (en dehors meme du nombre de personnes disponibles pour bosser dessus). Par contre il faut voir qu'ils s'amusent aussi a casser la compatibilite entre versions mineures de GTK (genre les themes). Et c'est exactement la meme chose pour les extensions qui petent aleatoirement entre versions (meme si il y a un peu plus d'excuses dans ce cas la).
Apres on peut trouver qu'il y a plein d'explications techniques, mais le fait que sur tous ces sujets plusieurs des devs Gnome ont clairement dit qu'ils ne voulait pas de ces fonctionnalites laisse planner le doute sur leur volonte de chercher une solution qui ne casse pas la compatibilite.
[^] # Re: et concrètement ?
Posté par Littleboy . En réponse à la dépêche Les codes sources des jeux Jedi Outcast et Jedi Academy passent sous licence GNU GPLv2. Évalué à 7. Dernière modification le 09 avril 2013 à 17:02.
Le moteur du jeu est maintenant sous licence libre. Les donnees n'ont pas change de licence et ne sont pas liberees (ni mises gratuitement a disposition).
C'est drole de parler de ca dans un meme message qui reclame des donnees libres (surtout que c'est dispo a la vente tres tres facilement)
[^] # Re: Pas convaincu
Posté par Littleboy . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 6.
Il y a plusieurs problemes en fait:
la taille du code et des donnees a telecharcher (ceux qui se plaignent au dessus de la taille des libs js vont pleurer avec des fichiers JS de 20Mo ou plus :P): on peut distribuer sous forme d'application et stocker tout ca en cache local sur les navigateurs recents (mais c'est souvent limite a 5Mo). C'est une problematique plus large en fait: comment distribuer des applications qui font plusieurs Go dans un environnement ou les utilisateurs sont habitues a un chargement quasi instantane. Il y a plein de developpements interessants dans ce domaine (streaming, application cache, etc.)
le temps de compilation du code et la memoire consommee (le code asm.js est compile AOT): Mozilla a prevu d'ecrire un parseur specifique et optimise pour asm.js, vu qu'apparemment les tests sur des fichiers de 50Mo voient la conso memoire titiller la barre des 1.5Go (ouch!). Et comme pour les donnees, on peut essayer de mettre en cache une partie du code compile.
[^] # Re: Pas convaincu
Posté par Littleboy . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 3.
Oui, et comme on oublie de bien preciser que ca ne concerne pas 99% des cas d'utilisation du JS et que pour les 1% restant (les jeux et les applis qui ont besoin de perfs) ca risque de necessiter le support complet asm.js de toute facon, ca reste de la communication.
Ce que tu ne sembles pas comprendre c'est que gagner quelques % de perfs c'est pas forcement desirable si les contreparties sont trop importantes. En particulier:
Si on oublie de parler de tout ca, on pense que asm.js c'est la solution magique juste parce que c'est un peu plus rapide, alors que pour le moment c'est reserve uniquement a la compilation via un generateur de code (ou a du code qui doit etre tres optimise, mais qui ne concerne certainement pas la totalite d'une appli web).
Bref, ma critique initiale c'est pas que c'est inutile parce que c'est juste un peu plus rapide que du code JS, c'est que pour la cible (les jeux avec grosse demande de perf) etre juste un peu plus rapide que du code JS c'est deja redhibitoire. Par consequent pointer ca comme un gros avantage est mensonger puisque des applis qui ont besoin de grosses perfs seront de toute facon inutilisables sans un support natif.
Mais on s'en fout, ca n'a jamais ete la question.
L'assembleur est performant, partout, tout le temps, qu'il vente, qu'il pleuve ou qu'il neige.
Le C est performant, partout, tout le temps, qu'il vente, qu'il pleuve ou qu'il neige.
Voila, c'est a peu pret ce que tu racontes. Pas besoin de t'expliquer ce que je pense des gens qui affirment betement ce genre de chose je pense.
[^] # Re: Pas convaincu
Posté par Littleboy . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 5.
Dans la cas de figure qui nous preoccupe (moteur de jeu recent avec des grosses demandes en perf), ca nous fait une belle jambe que compiler vers asm.js / JIT permettent de grappiller quelques % par rapport a du javascript idiomatique / JIT lorsque l'abscence de support AOT te donne juste un slideshow.
Comme dit plus haut, la partie "c'est du javascript ca va tourner pareil sur les navigateurs qui n'ont pas de support asm.js", c'est de la comm' (en gros c'est vrai tant qu'il n'y a aucune application qui necessite les perfs fournies par le support asm.js)
[^] # Re: Pas convaincu
Posté par Littleboy . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 2.
Cough cough…
Custom asm.js parser (bug 854061) (estimated time: 2 months): create a new parser (reusing the tokenizer) that only recognizes asm.js, falling back to the general purpose parser on any failure. This would avoid creating 1.5GB of ParseNodes for 50MB asm.js files and also making parsing a lot faster.
https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey
Les navigateurs qui n'implementent pas le support direct pour asm.js et donc ne font pas une passe de compilation AOT dessus doivent executer le code en mode interprete/JIT (pareil que du code qui ne passerait pas la validation pour les navigateurs avec le support d'ailleurs). Et c'est evidemment beaucoup beaucoup plus lent, sinon faire son propre parseur et compilateur AOT n'aurait aucun interet.
[^] # Re: Pas convaincu
Posté par Littleboy . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 10. Dernière modification le 04 avril 2013 à 05:27.
Le message auquel je reponds juste au dessus (dont l'auteur n'a pas du prendre le temps de lire l'intro de la spec), ainsi que la partie de ton journal qui dit "Le code asm.js utilise les mêmes APIs DOM que n'importe quel code JavaScript."
J'ai peut-etre compris la spec completement a l'envers, mais quand je lis les autres commentaires dans le journal j'ai l'impression que les gens mettent un peu tout et n'importe quoi dans l’appellation 'APIs DOM' (et melangent WebGL, JavaScript 'normal' et modules asm.js).
Qu'est ce que tu entends par "utilise les memes APIs"? Qu'un module asm.js peut utiliser une grande partie des APIs DOM (sans tourner en version interpretee)?
Disons que pour faire quelque chose du niveau de asm.js, c'est en effet pas forcement interessant de specifier son propre format de bytecode. Cela-dit, Mozilla prevoit d'ecrire un parseur separe pour les modules asm.js, du coup on voit plus trop l'interet d'etre un sous-ensemble de javascript.
Finalement c'est plutot pour des raisons de strategie: etre pret rapidement en reutilisant l'infrastructure existante, communiquer sur le fait que ca marche partout en mode interprete (on rigole, parce que le moteur Unreal 3/4 qui tourne avec la version interpretee en haute resolution, j'attends quand meme de voir).
C'est tres probablement une strategie gagnante. Au niveau technique j'ai tendance a trouver ca un peu degeu, mais si ca permet une adoption par tous les navigateurs rapidement, ca se discute pas :)
C'est pour ca que Google bosse sur PNaCl depuis un moment (oui, c'est pas si facile que ca et c'est toujours pas pret - voir au dessus pour mon avis sur la meilleure strategie).
Ce qui gene Mozilla c'est qu'ils n'ont aucun controle dessus, pas le fait que ca soit de nouvelles APIs. Si lorsque PNaCl est stabilise Google essaye de standardiser tout ca, Mozilla serait toujours aussi contre.
Si j'ecris un journal pour parler des trucs biens que fait ma boite et critiquant la concurrence (developpement ferme, pas standard), ca sera peut-etre mon avis personnel mais ca fera la comm' de ma boite.
Ce que tu decris dans ton journal est tres interessant (j'ai pertinente), mais les parties non techniques s'averent etre exactement l'axe de comm' de Mozilla. Ca ne veut pas dire que tu repetes betement la comm' mais:
Bref, ca a beau etre ton avis perso, c'est aussi dans la ligne de l'entreprise (et ne soyons pas naifs, en tant qu'employee de Mozilla si tu etais tres critique vis a vis de la strategie de ta boite, tu viendrais pas poster sur LinuxFR).
Desole si ca fait tres critique envers ta demarche, je pointe juste que certaines des critiques que tu fais n'ont rien d'objectif. J'ai d'ailleurs le meme avis sur les personnes qui par exemple sont toujours promptes a critique web/internet et deviennent mysterieusement silencieuses des que ca parle de sauvegarde de la vie privee et tracking des utilisateurs…
Donc continue a poster des journaux sur ce que fait Mozilla, je les lis avec plaisir :)
[^] # Re: Pas convaincu
Posté par Littleboy . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 6.
As-tu regarde la spec? La difference entre un module asm.js de quelques megas et un gros bloc de bytecode est pas tres grande, hein.
Et quand on parle de sous-ensemble de javascript, c'est un sous-ensemble tellement reduit et optimise pour etre compile (pas pour etre ecrit a la main) avec des ajouts a la lib juste pour optimiser certains cas super rare dans du code "normal" mais qui reviennent beaucoup dans du code optimisee par un compilateur.
En gros, c'est operations numeriques sur un bloc de memoire statique (et c'est tout). Va donc voir la sortie d'un bloc ASMJS par Emscripten et reviens nous expliquer la difference fondamentale avec du bytecode.
Par ailleurs, si on regarde les plans de Mozilla (AOT force, parseur separe pour le code asm.js), ca ressemble quand meme tres fortement a utiliser ce sous-ensemble du JS comme representation intermediaire plutot que de redefinir leur propre format de bytecode.
C'est pas une mauvaise idee et c'est une bonne alternative a NativeClient, mais il faudrait pas non plus prendre la comm' de Mozilla pour quelque chose d'objectif. Les petits arrangement avec la verite et la petite histoire du gentil Mozilla et les standards contre le mechant Google dans ce journal, c'est joli mais c'est quand meme du BS de premiere.
[^] # Re: le git et le couvert
Posté par Littleboy . En réponse au journal Chiselapp ferme ses portes. Évalué à 2.
Ca n'a plus l'air d'etre le cas, donc il y aura peut-etre un package debian dans pas longtemps.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639311
[^] # Re: Plusieurs choses à prendre en compte.
Posté par Littleboy . En réponse au journal Attaque DDoS contre Spamhaus. Évalué à 2.
Au lieu de perdre du temps a discuter avec eux, utilise le temps gagne pour mettre a jour ton CV :)