La Bajon vs La censure Youtube.

L'explication de l'évolution historique du conflit en Crimée sans utiliser les mots interdits par Google est formidable. J'ai ri au mois 5 fois en 4 min.

Je suis totalement d'accord avec ce qu'écrit @OpenNews sur le sujet RGPD / Censure / Blocage, par contre quand je lis dans le titre :

Le hollandais volant - Tarés qui ne comprennent rien à Internet

Et dans le post :

À nouveau on va tenter de rééquilibrer les opinions moisies du hollandais

Est-ce vraiment si difficile que ça de ne pas insulter l'autre ? Timo maîtrise visiblement mal le sujet, ok... Timo ne perçoit pas le "jeu politique" et ne comprends pas forcément comment fonctionne tout l'échiquier politique et la propagande des intérêts privés derrière, mais est-ce que cela permet de dire de lui que c'est "un taré" ?

Traiter l'autre de fou, c'est tente de le décrédibiliser à vie et faire l'erreur de ne pas contre-argumenter sur les propos.

De ce que j'ai lu de lui, il est possible de le convaincre, il n'est ni fou, ni stupide et je pense que lui expliquer d'autres points de vue sera bien plus bénéfique qu'en faire un ennemi, parce que là, si ce n'est pas déjà mort, c'est qu'il a vraiment un très bon état d'esprit.

@Sebsauvage d'accord avec toi, c'est juste scandaleux ! Par contre je me permets une interprétation contradictoire/complémentaire à la tienne quant aux raisons qui pousseraient Google à agir de la sorte :

Google est juste un gros robot sans tête, complètement débile.

Google applique une politique bien précise : sa politique anti-vie-privée et pro-centralisation.

Je m'explique :

• Le protocol Matrix vise à l'interopérabilité, mais une telle chose n'est utile que lorsqu'on n'est pas en situation de monopole.

• Mastodonte est décentralisé, pas possible de négocier quoi que ce soit avec une direction unique comme c'est le cas avec Twitter.

• Google est assujetie au Patriot Act, si un web sécurisé, décentralisé et non censurable émerge, ça pourrait bien gêner l'empire le plus belliqueux de ces trois derniers siècles.

Google emploie parmi ceux qui seraient les plus brillants esprits au monde, ceux qui développent les meilleurs algoritmes et les plus grandes infrastructures, tout en touchant de manière tentaculaire à tous les secteurs d'activité, donc affirmer que Google ne serait qu'un "gros robot débile" ça me semble étonnant.

Je pense que nier que les principaux propriétaires d'une telle corporation aient un projet politique et demanderaient à leurs brillantissimes soldats d'agir en conséquence n'est pas réaliste. Je te renvoie à l'attitude de Microsoft pendant des décénnies et Google, enfin Alphabet maintenant, est une entreprise de la même espèce et aux mêmes méthodes.

Bref pour se protéger de ce genre de pratiques, mieux vaut délaisser les produits et services Google à commencer par Chrome.

Edit : correction des fautes. Damned (oO) ! Note pour moi-même, ne plus écrire mes posts depuis mon mobile dans le rer.

Je ne peux m'empêcher de m'inquiéter en lisant cela car il agit d'une censure, que sa motivation sous-jacente soit juste ou injuste n'est pas la question car toute censure reste injuste par essence.

Alors sans tomber sans le sophisme de la pente savonneuse, l'étape d'après ne serait-elle pas l'interdiction de nier l'existence de Dieu ? Tout du moins dans certains pays dans un premier temps... Puis interdire la critique de l'état, puis de ses dirigeants (coucou Winnie le chinois).

En fait je ne comprends pas que l'on puisse se réjouir de la censure, même de celle d'un adversaire, car c'est une épée à double tranchant qui peut aisément se retourner contre les peuples et historiquement elle l'a toujours fait.

L'existence de la Shoah ne s'ordonne pas elle se démontre. Cacher des éléments de preuve au grand public, aussi horribles qu'ils aient pu êtres, fût l'idée la plus stupide qui fût car elle a permis la venue de personnes maniaques mais méticuleuses comme Faurisson. Chaque vide dans le puzzle de l'histoire lui a permis de renforcer ses croyances et de construire un argumentaire démontable uniquement par des experts. #BienJouéLesGars

Il aurait été plus judicieux de créer une page Facebook qui débunke tous les arguments des négationnistes un à un et d'automatiquement relier cette page à tous les postes qui nient la Shoah. C'est en diffusant des connaissances que l'on tuera le négationnisme, la censure n'est quant à elle qu'une arme sur étagère que s'offre les dictatures Caputalistes (non il n'y a pas de faute, c'est un mot que j'ai inventé, il est bien hein) pour tuer dans l’œuf les futurs révoltes et insurrections.

Mais bon diviser pour mieux régner il paraît que ça marche.

Toutes celles et tous ceux qui ont vécu une relation toxique sauront de quoi je m'apprête à vous parler. Peut-être connaissez vous quelqu'un qui laisse toute place à ses émotions, qui ne met en avant que son ressenti et à côté duquel vous ne pouvez rien dire, vous n'osez plus parler de peur de vous faire sauter à la gorge. Chacun de vos mots peut devenir un prétexte, une arme utilisée par cet interlocuteur pour vous piéger et ensuite vous punir.

À ce stade, surtout lorsque c'est votre conjoint, vous préparez vos paroles dans votre tête avant de prononcer quoi que ce soit et pendant que vous vous exprimez, vous faites attention à ses expressions, à ses gestes, à la moindre de ses crispassions afin de vous dédire juste à temps et vous éviter la punition pour ne pas dire le cataclysme.

Cette torture je l'ai vécu trèèès longtemps, je l'aimais pourtant et de tout mon cœur mais j'étais piégée et j'avais peur de ses réactions en per-ma-nence, vraiment la crainte était omniprésente, toujours là et tout le temps. C'était une relation hautement toxique et même ses propres amis venaient me voir pour me dire que j'avais beaucoup changée, que je m'effaçais plus qu'avant, que je riais beaucoup moins et surtout que j'acceptais des choses "pas normales" selon eux (mais ils ne voulaient pas êtres pris pour cible, alors ils se limitaient à ça et ne lui disait rien).

Aujourd'hui dès années ont passé, nous nous sommes séparés et je me suis reconstruite, alors quand je vois les dérives du progressisme qui met en avant le ressenti des gens avant le signifiant des mots (cf. le couple master-slave), qui pousse à l'auto-censure parce que certaines choses seraient intrinsèquement "mauvaises" (comme si la morale était une valeur universelle et absolue) au point où des universités s'effondrent (cf. Evergreen) et bien je suis terrifiée par cette mouvance qui se généralise.

Et je pèse mes mots, car vivre ça au niveau du couple a été l'une des plus horribles expériences de toute ma vie, alors vivre ça au niveau de toute la société française je n'imagine même pas le cauchemar ! Parce qu'à l'époque, en dehors de mon couple, j'avais le travail où je pouvais souffler, même le RER était une phase de répit c'est vous dire ! Mais c'était tout.

En ce sens, maintenant que je suis bien plus forte et bien plus avertie, je compte me battre bec et ongle contre les problèmes tout droit venus des USA, engendrés à cause du passé tordu de cette nation et qui ne sont pas les nôtres, afin qu'ils ne s'importent pas dans notre pays. Il faut dire non au progressisme autoproclamé "inclusif", il ne l'est pas, c'est un buzzword, un mot de novlangue qui exclus ceux qui "pensent mal". C'est un obscurantisme qui ne dit pas son nom et il s’immisce facilement car il touche à nos émotions et non à notre raison. Pour lutter contre lui il faut lutter contre notre pire ennemi : nous-même.

L'anti-racisme fait la même chose (enfin un pan de la mouvance antiraciste), qui prône l'agression, la destruction de l'ennemi sans ouverture, sans dialogue ni pardon. Tout ce qui n'est pas antifa doit être détruit, tout ce qui n'est pas inclusif est méprisable, tout ce qui n'est pas comme nous est contre-nous. Je n'arrive même pas à comprendre comment des gens qui pensent lutter contre les extrêmes ne fassent pas le rapprochement entre leur mode de fonctionnement et celui de ce qui a été des milices, puis des partis politiques radicaux et qui nous ont conduit vers les deux grandes guerres. La démarche intellectuelle était la même : on ne peut pas discuter avec eux les XXX (remplacez par la motion la plus efficace, "raciste, extrémiste, masculiniste, fasciste, pianiste" ? Ah non pas encore pour celui-là).

Bref, le monsieur en vidéo explique bien le point de vue et cela m'a donné envie de poster tout ça car j'ai vu beaucoup de choses passer sur différentes rivers et sur les réseaux asociaux ces derniers temps et quasiment tout n'est qu’émotionnel et se contredit entre mise en œuvre et idéologie.

Je vais rentrer directement dans le vif du sujet en prenant argument par argument et en répondant à chaque fois. Puis j'apporterai les miens à la fin.

1) Les bus applicatifs permettraient de coder en évènementiel.

Oui mais ça ne veut pas dire que c'est la seule technologie permettant de le faire. Vous en connaissez sûrement une autre : les requêtes AJAX sur HTTP. Vous savez ce truc à la base de tous les internets "modernes" sorti en 1996.

Par essence une requête AJAX est asynchrone et c'est lorsque le serveur notifie le client qu'il a traité sa demande (ce qui est la définition même d'un évènement) qu'une fonction de call-back est invoquée.

2) Passer par un bus applicatif réduirait le couplage entre les services.

En général on me sort cet argument face à RESTful ce à quoi je réponds : le degré de couplage est le même.

Effectivement en RESTful ce qui compte c'est le chemin utilisé et un fichier JSON qui contient les données. Il ne s'agit pas là d'invoquer une méthode via RMI, ni d'employer la même technologie côté client et côté serveur, il s'agit d'envoyer un fichier texte contenant les bonnes informations sur une URL. Wouah mais quel couplage ! #Unbelievable

Nous sommes déjà au degré utile et essentiel de découplage. Commencer à vouloir s'abstraire de l'URL est un non-sens d'autant qu'elle se retrouvera quand même dans les messages des bus comme Kafka mais sous une autre forme : le type du message.

Je m'explique : pour qu'un message soit dépilé par le bon service, il faut qu'il soit typé (ie. je contiens tel contenu et j'incarne telle demande), or le typage d'une demande en RESTful c'est ni plus ni moins que l'URL. Avec les bus applicatifs comme Kafka, nous représentons ce typage sous la forme d'une entrée de type clef-valeur dans un header mais cela revient à la même chose que de contacter une URL. C'est juste moins facile à relire car les protocoles sont binaires et non textuels (cf. KafkaMessage) donc ça paraît "plus découplé" mais ça ne l'est ni plus ni moins.

3) Les bus applicatifs permettraient de gérer des queues de messages.

En réalité cet argument n'en est pas un. Nous avons ajouté de la puissance de calcul dans le bus dont le rôle sera d'encaisser les pics de charge ; or pourquoi ne pas affecter cette puissance de calcul (en générale inhumaine lorsque nous parlons d'un cluster Kafka) directement dans les µ-services ? (ndr. qui sont eux aussi un anti-pattern d'architecture)

Dit autrement, nous préférons affecter de la puissance de calcul à des unités de stockage de messages, rajoutant ainsi des latences et augmentant les coûts d'infrastructure plutôt qu'aux unités de traitement qui fournissent elles des calculs utiles.

Je suis favorable aux queues lorsqu'elles sont à l'intérieur d'une application, car elles aident à mettre en place des algorithmes de calculs mutli-threads et parallèles pour ainsi tirer parti de 100% des hardwares mutli-cpus / multi-cores.

Au niveau inter-applicatif c'est une très mauvaise idée car cela fait reposer nos SI sur l'élément le moins fiable du monde : le réseau.

4) Les bus applicatifs seraient plus sécurisés en forçant une rupture protocolaire.

L'argument du changement de protocole dépend de comment fonctionne le bus et de son implémentation. Par exemple les bus qui travaillent en SOAP sur HTTP fonctionnent sur HTTP... Comme nos requêtes REST en somme... #ChangementDeProtocoleSur20

Ensuite, la sécurité ce n'est pas qu'une simple histoire de protocole, c'est toute l'architecture qui doit être pensée pour être résistante aux attaques. Cet argument laisse accroire que la sécurité est une chose facile et que nous aurions magiquement augmenté le niveau juste par la présence d'un sacro-saint bus, ce qui est faux.

Enfin, en quoi un changement de protocole sécurise quoi que ce soit ? Si j'envoie un message via un bus, quoi qu'il arrive ce dernier sera traduit dans un format interprétable par l'application, si je peux effectuer une injection parce que l'application tolère les injections, je pourrai quand même attaquer le système.

Souvent, on me rétorque à cet argument que le bus peut faire des contrôles anti-injections par exemple, mais ce sont les mêmes personnes qui me disent de l'autre côté qu'un bon bus reste au niveau du réseau et qu'il doit être neutre au niveau application : décide-toi camarade.

Pour moi ce qui transporte un message ou une requête ne doit transporter que le message ou la requête et ne rien faire d'autre. Quand j'envoie ou que je reçois une lettre par la poste je ne veux pas que la poste ouvre ma lettre et en modifie le contenu "pour me protéger". #Censure Pour mes applications c'est pareil, je décide seule de ce qui est une attaque et de ce qui est une demande, pas le bus, donc pas de sécurité à son niveau. #SegragationOfConcerns

5) Le monitoring réseau est plus facile avec un bus.

Le bus est un endroit centralisé par lequel tout transite, donc enregistrer qui s'adresse à qui semble plus simple que faire la même chose dans un réseau maillé à la sauce internet où n'importe qui peut contacter n'importe qui d'autre.

Alors cela est vrai lorsque les bus ne sont faits que d'une seule instance... Or si une seule et unique machine peut encaisser toute la charge de vos messages, déjà je vous pose la question de l'intérêt d'avoir mis en place un bus pour un SI aussi peu complexe avec une volumétrie aussi faible mais admettons...

En général les bus applicatifs sont de très gros clusters avec des systèmes de réplication inter-instances... Les gens qui me parlent de monitoring vont me dire que "grâce au bus je sais qui envoie des messages au cluster de mon bus et qui reçoit des messages du cluster de mon bus". Ok... Mais que se passe-t-il à l'intérieur du cluster ? Quel trajet le message a-t-il effectué dans cette #BoiteNoire ?

En y regardant de plus prêt nous nous rendons compte qu'il existe une case à l'intérieur de laquelle nous n'analysons plus rien et nous décrétons que cette case n'est pas à superviser puisque c'est le bus lui-même ; ce qui revient à superviser un routeur.

Or ne regarder que ce qui est extérieur au bus se rapporte à monitorer la périphérie du SI, c'est-à-dire nos services et c'est déjà chose possible avec des logs produits par les services eux-mêmes + ELK pour un coût et une complexité d'infrastructure dix fois moindre.

Je sais que Kafka est plus intelligente et permet de se monitorer elle-même, mais cela ne répond pas à la question du nombre d'instances supplémentaires à gérer du fait de sa seule présence, ni même de l'expertise que cela requiert ou encore de la manière dont Kafka va contraindre la façon de coder les services.

6) Les bus me permettraient de changer un service sans impacter les autres.

L'idée sous-jacente est de dire que comme tout le monde parle au bus alors les services ne se connaissent pas entre-eux. Il devient donc possible de changer un service sans devoir patcher les autres.

En réalité ce coût de transformation est déporté non pas pendant la mise à jour du service mais au moment de la migration du bus A vers un autre bus B.

Sauf que l'économie de ces petits coûts traités au fil de l'eau se métamorphosera en supra-giga-facture lors de la big-bang transformation qui consistera à sortir totalement le SI du bus A. C'est évident, puisque tout le monde parlant au bus, aussitôt que l'on changera de bus, il faudra mettre à jour tout le monde avec la complexité et le risque que ce genre de "migration" impose. Vous le sentez l'anti-pattern du point de vue du CTO ou d'une DSI ?

Je préfère disposer d'une communication ad-hoc entre plusieurs services REST s'appuyant sur des Swagger faisant office de contrat d'interfaçage. Ainsi tant que tout le monde parle le bon JSON, ça marche point.

Pas de protocole particulier, pas de lib "kafka-client" à tirer dans mon application, pas de dépendances vers des tiers, juste des fichiers textes ayant une structure (CSV, JSON, XML, YAML, etc) et que j'envoie ou reçois sur le réseau ; avec des mises à jours petites, fréquentes et réalisées en continue pour faire virer notre paquebot de SI sereinement.

Je peux en plus choisir un format adapté qu'il soit plat (properties) ou arborescent (JSON) là ou Kafka m'impose du plat en clef-valeur. Cette contrainte rend juste votre vie difficile pour représenter une hiérarchie d'objets, heureusement ça n'arrive que tout le temps...

Il faut bien comprendre que lorsqu'un Swagger change pour ajouter un nouvel attribut par exemple, il faut alors changer tous les clients. Mais c'est également le cas avec des bus comme Kafka ! En effet, si un message nécessite une valeur supplémentaire, il faut que tous les clients émettant ce message intègrent cette nouvelle valeur. Mais alors où se trouve le découplage des bus par rapport à REST ? Où se trouvent el famoso "mise à jour sans impact" ? Réponse : nulle part, c'est un mythe.

Nous voici arrivés à la partie contre-arguments (qui va être courte car j'en ai marre d'écrire) :

Les bus sont des SPOF (Single Point Of Failure) mais pourquoi ?

Au niveau du réseau
Comme tout passe par le bus, alors si le bus tombe tout tombe. C'est la raison pour laquelle Kafka a émergé ; puisque si un nœud Kafka tombe, alors il en existe d'autres pour assurer le travail et l'engouement pour Kafka est à mon sens le témoin du fait que les bus mono-instances étaient encore plus des anti-patterns. Mais quid des difficultés d'administration de Kafka ?

Je rappelle qu'un service doit déclarer les adresses de tous les nœuds Kafka pour se connecter au cluster (au cas où le seul nœud déclaré aurait lâché). Je dois donc paramétrer mon application pour qu'elle ait une connaissance de l'infrastructure alors que celle-ci devrait être agnostique de cette infrastructure. Nous revenons en arrière de 20 ans (promis je ferai un poste expliquant en quoi Docker fait la même chose vis-à-vis du build lié à la sécurité).

Le nombre d'instances à administrer augmentent mais pas seulement... Le type d'instances aussi !
Et oui il faut administrer les instances du bus en plus des instances applicatives mais en plus il faut disposer d'admin-sys ayant des compétences sur les applications ET sur le bus !

Alors du point de vue du cabinet de conseil c'est merveilleux puisque je peux fourrer encore plus de prestas ! #Money Mais du point de vue du CTO ou de la DSI, c'est mon porte-feuille qui se fait mettre à mal.

Et là je ne parle pas que de compétences, arguons que chaque instance tourne sur du hardware en dernier recours et que ce hardware a un coût. Plus d'instances => Plus de hardware ou du hardware plus gros et donc plus cher ! C'est le second effet kiss-cool au porte-monnaie.

Mais il y en a un troisième !! Il faut que je recrute des développeurs qui maîtrisent le bus. Vous savez les développeurs Kafka par exemple... Sauf que compétences en plus => tarifs plus élevés. Et cela engendre des difficultés de recrutement d'une part et une sensibilité accrue au turner-over d'autre part surtout quand l'expert Kafka nous quitte...

Les schémas du SI intégrant un bus masquent l'horreur de la réalité.
Avant les bus applicatifs, les architectes fournissaient des schémas avec plein de boites et encore plus de flèches le tout partant dans tous les sens. C'était alors triviale de constater l'ampleur du grand merdier et donc de réclamer une simplification du SI aux architectes dont le travail était manifestement défaillant.

Avec un bus, nous nous retrouvons avec les boites applicatives en périphérie de ces schémas et une plus grosse au centre : celle du bus lui-même. Là le schéma est propre, harmonisé, au moyen une belle structure en étoile où chaque composant ne s'adresse qu'au bus... #PowerPointSur20

Soyons clairs, c'est le même bordel à l'intérieur de la grosse boi-boite qui représente le bus que ça ne l'était avant sans la présence du bus. Sauf que ce souk devient invisible quand on ne se rend pas sur le terrain, en observant les flux et le code... Mais ce que le CTO ne voit pas ne lui pose pas de problème n'est-ce pas ?

Illustration du problème AVANT

Illustration du problème APRES

Comment identifier l'endroit où la complexité est la plus dense ? Comment y affecter des personnes et mesurer sans effort l'ampleur des difficultés qu'elles vont affronter si tous ces schémas avec ces flèches dans tous les sens ont été effacés du regard ? Comment justifier les coûts budgétaires aussi élevés à chaque mise à jour alors que notre SI paraît si simple, si joli, si sophistiqué avec sa structure en étoile dans de beaux Power-Point animés ?

Si certains architectes aiment autant les bus, je pense que c'est parce qu'ils peuvent montrer à quel point ils brillent, leurs schémas devenant clairs, limpides, dignes des experts qu'ils sont au vu de leurs tarifs. Et toute la difficulté retombera alors sur le dos des développeurs, vous savez ces "tocards" payés à pas cher et importés de l'étranger... De parfaits coupables pour des experts influents et bien-pensants face à la certitude que les devs soient des incompétents.

Je résumerais ma position sur un principe : KISS (Keep It Simple, Stupid !). Cela vaut pour du code, cela vaut aussi pour le SI.

Je cite l'article :

Seulement voilà, les tweets mettant en cause l’agence n’ont pas été du goût de la Société générale. Au point que le directeur de l’agence finira par contacter la libraire pour convenir d'un rendez-vous qui se révélera infructueux. "Trois semaines après, dans son bureau, l’actuel directeur, lors d’un entretien agressif et ubuesque, nous expliquait que la banque nous mettait dehors, à cause de ces tweets. Pas de raisons bancaires", se souvient Julie Goislard.

Depuis, elle a reçu plusieurs lettres recommandées l’informant de la fermeture de ses comptes personnels et professionnels sous 60 jours. Le compte de son compagnon et associé a subi le même sort. "Drôle de cadeau de Noël", écrit-elle sur Facebook.

Contactée par Le Parisien, la Société générale se refuse à tout commentaire, invoquant "la confidentialité" et le "secret bancaire". Elle indique cependant que "la banque peut fermer un compte bancaire à tout moment en respectant un préavis de 60 jours" sans qu'il soit nécessaire de "motiver sa décision".

Une raison de plus pour rester anonyme sur internet et sinon la Société Générale connaît-elle l'effet #Streisand ?

Voici quatre propositions :

• Un système qui centralise toute l'information pose problème.
• Un système qui autorise la censure pose problème.
• Un système qui n'est pas régit par un contrôle démocratique pose problème.
• Un système qui récompense des actes malveillants pose problème.

Vous mélanger ces quatre éléments et vous obtenez le fait que 20 Minutes peut forcer Facebook à censurer un concurrent, sans motif, que cela va lui rapporter de l'argent [ndr. à 20 Minutes] et que le concurrent, ici Mr. Mondialisation, n'a aucun moyen de défense.

Pas mal le service chez 20 Minutes. GG les gars, l'étape d'après c'est la répression du parti unique chinois, vous pouvez être fiers d'améliorer la compétitivité française dans ce domaine #Bravo.

La censure avance en France. Sci-Hub est bloqué par les FAI français sous ordonnance du pouvoir.

Du coup à ajouter dans votre fichier /etc/hosts : 186.2.163.90 sci-hub.tw

Rappel des faits :

François Asselineau ayant dépassé les 500 signatures, TF1 était obligée de l'inviter sur son plateau télé, pendant 6 min, au moment du prime de 20h, la semaine du 10 mars 2017. Lors de cet évènement, le journaliste taxe François Asselineau de complotiste, et lui explique que c'est étrange d'entendre François Asselineau dire que Jean Monet était un agent de la CIA ayant aidé à la mise en place de l'Union Européenne pour les intérêts Américains.

À cet instant, François Asselineau rigole et sort le numéro 675, datant de mars 2003, du magazine Historia où l'on apprend à l'intérieur du numéro de ce magazine que suite à la déclassification des documents confidentiels de la CIA, Jean Monet était effectivement un agent de la CIA œuvrant diplomatiquement et politiquement pour le compte des États-Unis d'Amérique en vue de construire une organisation politique appelée "Union Européenne" ; laissant le champs libre aux États-Unis d'Amérique d'étendre leur pouvoir en s'assurant que l'Union Européenne soit un système bloquant pour les états membres.

Qu'à fait le magazine Historia ?
Il vient non seulement de supprimer son numéro d'internet mais est en train de rééditer ce numéro afin de réécrire l'histoire.

Je rappelle que lors de ce prime, François Asselineau a également mentionner BFM TV qui fournissait la même information. BFM va-t-elle elle aussi réécrire l'histoire.

François Asselineau c'est actuellement le combat de Bernie Sanders face à la mafia Clinton. C'est l'argent de presque 19000 adhérents (18 mars 2017) face à l'argent des plus grandes fortunes du pays.

Je tiens à rappeler une chose :

BERNIE SANDERS A PERDU FACE AU POUVOIR DE L'ARGENT !!! ET COMME UNE MERDE ! PUTAIIIIIIIN !!!!!!

Trop peu de gens ce sont battus, trop peu de gens on diffuser l'information, trop peu de gens ont essayer pour lui permettre de changer les choses. Je supplie chaque personne qui me lit d'agir, c'est URGENT MERDE ! Cette fois-ci nous avons une chance de s'affranchir de l'oligarchie présente, aux prochaines élections, les choses seront complètement verrouillées.

Chlouchloutte, Lenny, Roudoudoutte, Doudou, Animal, MoniK, Camory à qui je fais souvent référence mais également aux autres qui me lisent un peu moins souvent mais dont je sais que les articles leurs parviennent quand même : Mon Poulet, Manu, Calvin, Shteuf, Yeam Anan et bien-sûr mon unique adoré Beuheu. S'ils vous plaît aidez-moi à combattre la censure qui démarre.

Quant à Historia je rappelle cette idée qui va leur coller à la peau :

We are Anonymous
We are legion
We never forgive
We never forget