GuiGui's Show

Je me note ces infos qui proviennent du Canard du 06/04 (on en trouve aussi trace sur des forums Internet comme http://forum.acuhello.org/viewtopic.php?f=3&t=171) :
    * Un décret de 2014 interdit la publicité dans les logiciels d'aide à la prescription médicale. Donc, au moment de la prescription, c'est obligation de disparition des pubs ;

    * Mais rien n'empêche d'intégrer de la pub à tous les autres moments. Et comme la fonction d'aide à la prescription est intégrée dans des logiciels plus gros qui font aussi agenda, gestion des dossiers des patients,... bah c'est plutôt aisé à faire ;

    * Les deux poids lourds du secteur, Hellodoc (USA) et CLM (France) sont gavés de pubs pour des produits pharmas... Bulletin d'informations quotidiennes, pubs dès que l'ordinateur se met en veille,... ;

    * Pourtant, ces logiciels sont payants : 64€/mois pour CLM, 10€/mois de plus pour virer la pub. Quel intérêt d'avoir encore de la pub à part la recherche du profit ?!

    * Hellodoc propose même une ristourne sur cet abonnement mensuel aux doc' qui acceptent de transférer des données de patients afin de constituer des panels. Hellodoc & co vendent des études à l'industrie pharma en se basant sur des données médicales concédées par des médecins qui utilisent leur logiciel. Joli. IMS Health, l'éditeur d'Hellodoc assure que les données sont anonymisées. L-O-L.

« Selon le principe posé par l’article L.113-1 du Code de la propriété intellectuelle (CPI), “La qualité d’auteur appartient, sauf preuve contraire, à celui ou à ceux sous le nom de qui l’œuvre est divulguée.”

Le titulaire des droits d’auteur sur un logiciel peut être une personne physique, le développeur du programme ou une personne morale, l’entreprise au sein de laquelle le logiciel a été développé. Plus précisément, une entreprise peut être considérée comme titulaire des droits d’auteur sur un logiciel dans trois cas de figure :

1 - le logiciel est qualifié d’œuvre collective : dans cette hypothèse, la contribution de chacune des personnes ayant participé au développement du logiciel se fond dans un ensemble ne permettant pas de distinguer le travail de chacun. Ce logiciel peut être la propriété de l’entreprise qui est à l’initiative du développement, l’édite et sous le nom de laquelle il est distribué. L’entreprise sera donc investie des droits d’auteur ;

2 - le logiciel est développé par un salarié de l’entreprise : l’article L.113-9 du CPI dispose que “les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l’exercice de leurs fonctions ou d’après les instructions de leurs employeurs sont dévolus à l’employeur qui est seul habilité à les exercer”, sauf dispositions statutaires ou stipulations contraires (prévues dans le contrat de travail). Toutefois, cette disposition ne concerne pas tous les salariés et exclut les tiers à l’entreprise, même intervenant pour son compte, tels que les stagiaires, intérimaires, consultants détachés par un prestataire informatique, consultants indépendants, etc. ;

3 - le logiciel est cédé dans le cadre d’un accord de cession de droits d’auteur : dans cette hypothèse le logiciel a été développé par une ou plusieurs personnes qui cèdent les droits patrimoniaux à l’entreprise. Pour être valable, la cession doit remplir les conditions de fond et de forme spécifiques, prévues par la loi [3].

[...]

La décision Sociétés Orqual c/ Tridim et autres de la Cour de cassation

[...]

Dans un arrêt du 15 janvier 2015, la Cour de cassation a cassé l’arrêt d’appel, sur le fondement de l’article L.113-1 du CPI, rejetant l’analyse selon laquelle le développement des logiciels étant le fruit du travail des deux associés, la société Tridim en détenait les droits d’auteur. En effet, selon les juges, “une personne morale ne peut avoir la qualité d’auteur” et ce notamment au motif qu’en l’espèce les contributions des auteurs au développement des logiciels étaient de natures différentes (d’une part, développement de code pour l’informaticien, d’autre part, apport d’éléments “métier” pour le professeur en médecine) et ne se fondaient pas dans un ensemble permettant de qualifier ces œuvres de “collectives”.

Par ailleurs, bien que ceci n’ait pas été précisé par la Cour, il convient de souligner que la société Tridim ne pouvait ni se réclamer titulaire des droits d’auteur au motif que les logiciels avaient été développés par des salariés, puisque ce sont les deux gérants qui avaient élaboré ces logiciels, ni se prévaloir d’aucun accord de cession de droits sur les logiciels. »

Vous vous souvenez de la directive de la FCC (régulateur USA des télécoms) qui demandaient à ce que les AP WiFi ne puissent plus utiliser des paramètres (fréquence, canaux, puissance d'émission) non approuvés ? C'est ici http://shaarli.guiguishow.info/?c6_2Ug

Les WiFistes criaient alors au loup : il était évident que les constructeurs de tels équipements n'allaient pas prendre de risques ni se prendre la tête et allaient tout simplement interdire l'installation d'un firmware alternatif genre OpenWRT. Crainte fondée. D-Link est le premier constructeur à l'anoncer mais semble ouvrir la porte à un firmware libre modifié verrouillé qui respecte les nouvelles règles de la FCC. http://www.numerama.com/tech/156369-tp-link-va-bloquer-firmwares-open-source-routeurs-vendus-aux-etats-unis.html

Vous vous disiez que c'bon, c'est chez les ricains, c'est looooooin, les constructeurs sortiront une version EU débridée. Déjà, ce raisonnement était absurde (l'uniformisation mondiale c'est mieux pour les profits). Mais voilà qu'arrive la directive européenne 2014/53/UE. Elle laisse une porte ouverte... à savoir si cette porte sera transposé dans le droit nationale qui fera foi.

« La transposition de la directive 2014/53/UE touche à sa fin et le gouvernement doit notamment prendre par ordonnance les mesures concernant l'évaluation de la conformité des logiciels, en application de l'article 3.3 (i) de la directive : [...] Cet article implique que les fabricants d'appareils vérifient tous les logiciels pouvant être installés sur l'appareil et leur conformité aux réglementations radio applicables, comme par exemple la fréquence et la puissance du signal.

[...]

Cette mesure présente un certain nombre de dangers :
    [...] Si les fabricants doivent évaluer la conformité aux réglementations de tous les logiciels installés sur les équipements qu'ils produisent, ils seront immanquablement conduits à installer sur ces derniers des dispositifs de contrôle au travers de logiciels non libres et non amovibles. Il deviendra extrêmement difficile pour les utilisateurs et entreprises d'utiliser des logiciels alternatifs — autres que les logiciels natifs — sur les appareils achetés (routeurs, téléphones mobiles, cartes WIFI ou ordinateurs, et tous les appareils connectés). [...]

     Toute entrave à cette liberté de choix mettra en péril la sécurité des appareils qui ne pourront être ni maîtrisés, ni contrôlés par leurs utilisateurs. Et ce, alors que les logiciels libres offrent généralement un niveau de sécurité supérieur, notamment parce que les failles et erreurs techniques sont plus facilement détectées et réparées via des processus collaboratifs et transparents. [...]

    En France et en Europe, de nombreux acteurs (notamment associatifs) développent des réseaux Internet sans-fil, contribuant ainsi à réduire la fracture numérique et à encourager l'appropriation citoyenne des réseaux et services Internet. Or, pour ce faire, ils ont besoin d'installer sur les équipements radios qui composent leur infrastructure des logiciels libres ad hoc, développés spécialement pour répondre à leurs besoins. [...]

Pour ces raisons, dans le cadre de la transposition de la directive radio, nous appelons le Gouvernement et l'ARCEP à inscrire dans le droit français le considérant 19 de la directive. Ce dernier constitue en effet un garde-fou fondamental, puisqu'il garantit que « l'établissement de la conformité de la combinaison d'un équipement radioélectrique avec un logiciel ne [serve] pas de prétexte pour empêcher l'utilisation de cet équipement avec d'autres logiciels réalisés par des tiers indépendants. (...)  ». Ce considérant est absolument nécessaire pour garantir l'ouverture des équipements radio et permettre l'innovation dans le domaine des télécommunications sans-fil. »

« Il est tout d’abord prévu que les bureaux de vote ne puissent plus fermer avant 19 heures (contre 18 heures aujourd’hui), y compris à la campagne. En ville, il sera toujours possible d’exercer son devoir de citoyen jusqu’à 20 heures. Cette réforme, introduite contre l’avis du gouvernement et du Sénat, ne sera applicable que pour les élections présidentielles. Pour les législatives, par exemple, il y aura toujours une amplitude de deux heures (18h/20h) entre la fermeture des premiers et derniers bureaux de vote.


[...] le fait de communiquer (sur Internet, à la télévision...) tout « résultat d'élection, partiel ou définitif », avant la fermeture du dernier bureau de vote du territoire métropolitain sera passible d’une amende de 75 000 euros – contre 3 750 euros aujourd’hui.

[ NDLR : haha lol... une amplitude d'une heure au lieu de deux... L-O-L. Ça va tout changer ! Mais on ne touche pas aux instituts de sondage qui permettent aux politocards de préparer leurs discours avant que le résultat tombe... Deux heures pour influencer des pauvres âmes dans le sens du vote mais bien sûr... Et les frontalier-e-s peuvent toujours capter les résultats via des émissions de TV/radio frontalières. Bref, des inégalités de partout... ]


[...] Il faudra toujours recueillir 500 soutiens d’élus (maires, députés, sénateurs, conseillers régionaux et départementaux, eurodéputés français...) pour se présenter officiellement, mais les formulaires ne pourront plus être transmis par les équipes de campagne. Les auteurs des présentations devront eux-mêmes faire suivre leur parrainage au Conseil constitutionnel, qui préparera pour l’occasion un formulaire type.

[ NDLR : ouuuuuch donc il faudra que l'élu signataire soit vraiment motivé. On est clairement dans une démarche proactive "je veux vraiment soutenir ce candidat". C'est peut-être là que l'on voit le mieux la démarche d'éviction des petit-e-s candidat-e-s dénoncée par l'opposition...


La véritable nouveauté réside dans le fait que dorénavant, le Conseil constitutionnel rendra public « au moins deux fois par semaine, le nom et la qualité des citoyens qui ont valablement présenté des candidats à l’élection présidentielle ».  [...] »

[ NDLR : c'est une bonne chose pour le citoyen mais ça permettra aussi de sanctionner les élus qui ont présenté de nouveaux/nouvelles candidat-e-s d'aucun parti en jouant sur des leviers comme les subventions, les aides pour des projets municipaux,... Le système précédent était le tirage au sort de 500 élus parmi ceux et celles ayant présenté un même candidat. Donc, la probabilité d'apparaître au JO n'est pas nulle et elle se réduit d'autant que le candidat est populaire. Donc l'étouffement des petits candidats, ça ne date pas d'hier. ] »


Ces lois modifient également le temps de parole. Avant, durant les 4 semaines qui précèdent l'élection, il devait y avoir une égalité du temps de parole dans les médias (et une équité de temps d'antenne qui inclue les reportages et autres sur un-e candidat-e, ses soutient, ses sujets,...). Voir http://www.lemonde.fr/les-decodeurs/article/2016/04/01/temps-de-parole-vers-une-presidentielle-plus-inegalitaire_4894005_4355770.html pour une très bonne explication des différents temps du matraquage médiatique qui précèdent une élection présidentielle.

Désormais, cette égalité sera assurée uniquement durant les 2 dernières semaines (la campagne officielle). Du dépôt de la candidature jusqu'à ces 2 dernières semaines, on sera sur un régime de l'équité du temps de parole : le CSA devra s'assurer que chaque candidat a le droit à la parole en tenant compte de sa représentativité et de son animation du débat public...

Je ne sais pas vraiment quoi en penser : cela fait bien longtemps qu'il n'y avait plus égalité à cause des nouveaux moyens de diffusion pas pris en compte par le CSA comme Internet ou... la presse écrite (sisi, elle est exclue du comptage). On notera que cela est obligatoire uniquement sur la TV hertzienne car le nombre de fréquences est limité. Sur les autres supports, avoir une chaîne de TV entière à la gloire d'un-e candidat-e ne pose pas de problème puisqu'il peut y avoir une infinité de chaînes de TV et que les citoyen-ne-s n'ont aucune obligation de les regarder.

Lors du "débat" entre les deux tours, cette contrainte d'égalité m'a toujours semblé être un frein au "débat" genre le-a présentateur-trice arrête un candidat-e dans son speech derrière l'excuse bien pratique du temps de parole.

Ensuite, vu la qualité des débats durant ces 4 semaines, on s'en passera, hein : être président-e c'est avoir une vision de l'avenir et la défendre, pas commenter l'actualité, ni envoyer des tacles aux autres candidat-e-s ni promettre le plein emploi et toutes ces conneries. Bref, venir me dire que ces 2 nouvelles lois nuisent à la qualité du débat politique voire l'empêche, juste L-O-L puisqu'il n'y a pas de débat politique ni d'échange d'idées. De plus, pourquoi diable ce débat devrait-il avoir lieu uniquement à 1 mois d'une élection présidentielle ? Les citoyen-ne-s devraient s'intéresser au quotidien à la vie politique.

Enfin, la véritable question à se poser me semble être : si un candidat-e (un parti en vrai) est élu uniquement grâce au matraquage médiatique qui précède l'élection, est-ce qu'on n'a pas là un problème beaucoup plus sérieux ? Il n'y a que si l'on répond non que la question égalité/équité du temps de parole devient importante.


Une autre mesure prévue par ces lois : les comptes de campagne comptabilisent les entrées/sorties à but électorialiste sur les 6 derniers mois au lieu d'un an. L'objectif affiché est de réduire les fraudes car les mandataires auraient du mal à estimer si une dépense est électorialiste 1 an avant une élection... Perso, je constate donc que les 16 millions d'euros max (plafond des comptes de campagne à l'heure actuelle) englobent désormais uniquement 6 mois, ce qui augmente la force de frappe médiatique des partis puisque les 6 mois qui précèdent sont donc libres de toute déclaration. ;)

« Je n’entends parler que d’emploi. C’est devenu l’étalon or, la justification absolue, le fourre tout. Pas une émission, pas un discours politique sans que cela ne dirige les débats. On se moque de l’intérêt des choses, on ne compte que les emplois. Et en plus on compte mal, souvent on ment.

[...]

On a besoin d’argent pour vivre, soit. On a besoin de faire des choses pour s’épanouir, je le pense. Mais quel rapport avec l’emploi? Pourquoi est-il si profondément ancré en nous que c’est une valeur? J’ai bien une idée mais là on va tomber dans le subjectif et je voudrais être consensuel aujourd’hui 😉

Restons en donc aux faits. Qui pourrait dire qu’un employé de nos armuriers qui travaille pour un gras salaire sur les mines anti-personnelles ou les armes biologiques est plus utile à la société que Mr René, chômeur senior sans espoir de retour à l’emploi et qui passe son temps a donner du soutien scolaire à nos enfants.

[...]

Quand je regarde mes amis ingénieurs, l’immense majorité travaille, comme moi il y a peu, pour des grosses boites et mettent leur « génie » au service d’empires économiques sans avoir la moindre maîtrise de ce qu’ils font et pourquoi ils le font. Quand tu penses que des ingénieurs travaillent à l’obsolescence programmée, et on nous dira qu’il n’y a pas de sot métier.

[...]

J’ai pensé à 10 000 trucs pour mettre mes modestes connaissances au service de la commune, de l’école, du collège, des vieux, et le constat est simple: à chaque fois que je pensais à quelque chose d’utile à la société, c’était impossible de pouvoir en vivre. Et tous les trucs qui me semblaient avoir une chance de marcher étaient au mieux inutiles, plus souvent nuisibles, donc hors de question.

[...]

Tant qu’on nous éduquera dans l’espoir d’avoir « une belle situation » (entendez « grassement payée », pas « noble métier »), ça ne risque pas de bouger.

[...]

J’ai travaillé 17 ans dans l’automatisation de tri postal. De merveilleuses machines qui mettent tellement de postiers au chomage. J’ai toujours eu l’utopie de la machine qui libère l’homme, mais le temps a passé et j’ai bien du me rendre compte que tout mon travail ne participait qu’au bénéfice exclusif de mes patrons, et au mien bien sûr. J’ai vraiment cru que ça changerait, que la révolution numérique mettrait un peu de temps à être comprise mais après toutes ces années pas l’ombre d’un début de prise en compte de cette nouvelle réalité: l’emploi disparaît.

[...]

Au prétexte de booster la Sainte Croissance qui seule saura apporter le bonheur aux petites gens, nous avons appris à être rentables. Méritants dit-on dans le jargon politique, ultime hypocrisie. Tout ça pour qu’au final des jeunes rêvent de devenir footballeur ou rock star de la télé réalité, tu parles d’un mérite.

Il faut se libérer de l’emploi, je ne sais pas si c’est par le Revenu de Base, le Salaire à vie, ou d’autres propositions mais il existe des pistes de réflexion dont on n’entend jamais parler chez Pujadas. On continue de gaspiller des milliards à subventionner des pans entiers de l’économie dont l’activité est in fine nuisible à la société, tout cela soit-disant pour l’emploi. »

W00t. Donc la latence d'une appli peut dépendre du buffer de réception TCP (si trop gros par rapport au volume moyen de données reçues, la structure contient uniquement les métasdonnées et que dalle de données donc le noyau tente de merger les paquets comme un ramasse-miettes et donc la latence explose...) et du nombre de sockets ouvertes sur un même port (adresses IP différentes) puisque la liste des sockets TCP ouvertes sur un système est stockée dans une table de hachage qu'il faut consulter à chaque SYN avant de répondre SYN ACK ou RST. Sauf que la fonction de hachage utilisée prend en compte uniquement le port... Donc, un grand nombre de sockets sur un même port massacre les performances puisque la table de hachage se retrouve avec la même complexité qu'une liste chaînée... Voici un très bon exemple qui pourrait être utilisé dans un cours d'informatique sur la complexité algorithmique à la place des exemples vaseux ou en tout cas très vaporeux.


« A customer reported an unusual problem with our CloudFlare CDN: our servers were responding to some HTTP requests slowly. Extremely slowly. 30 seconds slowly. This happened very rarely and wasn't easily reproducible. To make things worse all our usual monitoring hadn't caught the problem.

We ran thousands of HTTP queries against one server over a couple of hours. Almost all the requests finished in milliseconds, but, as you can clearly see, 5 requests out of thousands took as long as 1000ms to finish. When debugging network problems the delays of 1s, 30s are very characteristic. They may indicate packet loss since the SYN packets are usually retransmitted at times 1s, 3s, 7s, 15, 31s.

[...]

The first "ping" went from an external test machine to the router and showed a flat latency of about 20ms

[...]

The second "ping" session was launched from our external test machine against one of our Linux servers behind the router [...] The "ping" output shows the max RTT being 1.8s. The gigantic latency spikes are also clearly visible on the graph.

The first experiment showed that the network between the external testing server and a router is not malfunctioning. But the second test, against a server just behind this router, revealed awful spikes. This indicates the problem is somewhere between the router and the server inside our datacenter.

[...]

As you see from this tcpdump output, one particular ICMP packet was indeed received from the network at time 0, but for some reason the operating system waited 1.3s before answering it. On Linux network packets are handled promptly when the interrupt occurs; this delayed ICMP response indicates some serious kernel trouble.

[...]

To understand what's going on we had to look at the internals of operating system packet processing. Nowadays there are a plethora of debugging tools for Linux and, for no particular reason, we chose System Tap (stap). With a help of a flame graph we identified a function of interest: net_rx_action [...] The net_rx_action function is responsible for handling packets in Soft IRQ mode.

[...]

During a 30s run, we hit the net_rx_action function 3.6 million times. Out of these runs most finished in under 1ms, but there were some outliers. Most importantly one run took an astonishing 23ms.

Having a 23ms stall in low level packet handling is disastrous. It's totally possible to run out of buffer space and start dropping packets if a couple of such events get accumulated. No wonder the ICMP packets weren't handled in time!

[...]

We repeated the procedure a couple more times. That is:

    We made a flame graph source.
    By trial and error figured out which descendant of net_rx_action caused the latency spike source.

This procedure was pretty effective, and after a couple of runs we identified the culprit: the tcp_collapse function. [...] ver 300 seconds there were just about 1,500 executions of the tcp_collapse function. Out of these executions half finished in under 3ms, but the max time was 21ms.

[...]

The tcp_collapse function is interesting. It turns out to be deeply intermixed with how the BSD sockets API works.

The naive answer would go something along the lines of: the TCP receive buffer setting indicates the maximum number of bytes a read() syscall could retrieve without blocking.

While this is the intention, this is not exactly how it works. In fact, the receive buffer size value on a socket is a hint to the operating system of how much total memory it could use to handle the received data. Most importantly, this includes not only the payload bytes that could be delivered to the application, but also the metadata around it.

Under normal circumstances, a TCP socket structure contains a doubly-linked list of packets—the sk_buff structures. Each packet contains not only the data, but also the sk_buff metadata (sk_buff is said to take 240 bytes). The metadata size does count against the receive buffer size counter. In a pessimistic case—when the packets are very short—it is possible the receive buffer memory is almost entirely used by the metadata.

Using a large chunk of receive buffer space for the metadata is not really what the programmer wants. To counter that, when the socket is under memory pressure complex logic is run with the intention of freeing some space. One of the operations is tcp_collapse and it will merge adjacent TCP packets into one larger sk_buff. This behavior is pretty much a garbage collection (GC)—and as everyone knows, when the garbage collection kicks in, the latency must spike.

[...]

There are two ways to control the TCP socket receive buffer on Linux:

    You can set setsockopt(SO_RCVBUF) explicitly.
    Or you can leave it to the operating system and allow it to auto-tune it, using the tcp_rmem sysctl as a hint.

[...]

This setting tells Linux to autotune socket receive buffers, and allocate between 4KiB and 32MiB, with a default start buffer of 5MiB.

Since the receive buffer sizes are fairly large, garbage collection could take a long time. To test this we reduced the max rmem size to 2MiB and repeated the latency measurements: [...] Now, these numbers are so much better. With the changed settings the tcp_collapse never took more than 3ms! [...] With the rmem changes the max latency of observed net_rx_action times dropped from 23ms to just 3ms.

[...]

Setting the rmem sysctl to only 2MiB is not recommended as it could affect the performance of high throughput, high latency connections. On the other hand reducing rmem definitely helps to alleviate the observed latency issue. We settled with 4MiB max rmem value which offers a compromise of reasonable GC times and shouldn't affect the throughput on the TCP layer. »


Et la suite en https://blog.cloudflare.com/revenge-listening-sockets/ :
« After adjusting the previously discussed rmem sysctl we continued monitoring our systems' latency. Among other things we measured ping times to our edge servers. While the worst case improved and we didn't see 1000ms+ pings anymore, the line still wasn't flat. [...] As you can see most pings finished below 1ms. But out of 21,600 measurements about 20 had high latency of up to 100ms. Not ideal, is it?

[...]

The latency occurred within our datacenter and the packets weren't lost. This suggested a kernel issue again. Linux responds to ICMP pings from its soft interrupt handling code. A delay in handling ping indicates a delay in Soft IRQ handling which is really bad and can affect all packets delivered to a machine. Using the system tap script we were able to measure the time distribution of the main soft IRQ function net_rx_action [...] While most of the calls to net_rx_action were handled in under 81us (average), the slow outliers were really bad. Three calls took a whopping 32ms!

[...]

With some back and forth with flame graphs and the histogram-kernel.stp script we went deeper to look for the culprit. We found that tcp_v4_rcv had a similarly poor latency distribution. More specifically the problem lies between lines 1637 and 1642 in the tcp_v4_rcv function in the tcp_ipv4.c file [...] The numbers shown above indicate that the function usually terminated quickly, in under 2us, but sometimes it hit a slow path and took 1-2ms to finish.

The __inet_lookup_skb is inlined which makes it tricky to accurately measure. Fortunately the function is simple - all it does is to call __inet_lookup_established and __inet_lookup_listener. It's the latter function that was causing the trouble

Let's discuss how __inet_lookup works. This function tries to find an appropriate connection sock struct structure for a packet. This is done in the __inet_lookup_established call. If that fails, the __inet_lookup will attempt to find a bound socket in listening state that could potentially handle the packet. For example, if the packet is SYN and the listening socket exists we should respond with SYN+ACK. If there is no bound listening socket we should send an RST instead. The __inet_lookup_listener function finds the bound socket in the LHTABLE hash table. It does so by using the destination port as a hash and picks an appropriate bucket in the hash table. Then it iterates over it linearly to find the matching listening socket.

To understand the problem we traced the slow packets, with another crafted system tap script. It hooks onto __inet_lookup_listener and prints out the details of only the slow packets [...] With this data we went deeper and matched these log lines to specific packets captured with tcpdump. I'll spare you the details, but these are inbound SYN and RST packets which destination port modulo 32 is equal to 21.

[...]

As mentioned above, Linux maintains a listening hash table containing the listening TCP sockets - the LHTABLE. It has a fixed size of 32 buckets

To recap:

    All the SYN and RST packets trigger a lookup in LHTABLE. Since the connection entry doesn't exist the __inet_lookup_established call fails and __inet_lookup_listener will be called.
    LHTABLE is small - it has only 32 buckets.
    LHTABLE is hashed by destination port only.

[...]

At CloudFlare we are using a custom DNS server called rrdns. Among many other requirements, the server is designed to withstand DDoS attacks. [...]  In fact, our DNS architecture is designed to spread the load among 16k IP addresses.

When an IP address is under attack, and the server is not keeping up with incoming packets, the kernel receive queue on a UDP socket will overflow. We monitor that by looking at the netstat counters [...] It was more than the DNS server could handle, the receive queues built up and eventually overflowed. Fortunately, because we are binding to specific IP addresses, overflowing some UDP receive queues won't affect any other IP addresses.

[...]

But what does that have to do with the LHTABLE? Well, in our setup we bound to specific IP addresses for both UDP and TCP. While having 16k listening sockets in UDP is okay, it turns out it is not fine for TCP.

[...]

Due to our DNS setup we had 16k TCP sockets bound to different IP addresses on port 53. Since the port number is fixed, all these sockets ended in exactly one LHTABLE bucket. This particular bucket was number 21 (53 % 32 = 21). When an RST or SYN packet hit it, the __inet_lookup_listener call had to traverse all 16k socket entries. This wasn't fast, in fact it took 2ms to finish.

To solve the problem we deployed two changes:

    For TCP connections our DNS server now binds to ANY_IP address (aka: 0.0.0.0:53, *:53). We call this "bind to star". While binding to specific IP addresses is still necessary for UDP, there is little benefit in doing that for the TCP traffic. For TCP we can bind to star safely, without compromising our DDoS defenses.

    We increased the LHTABLE size in our kernels. We are not the first to do that: Bill Sommerfeld from Google suggested that back in 2011.

With these changes deployed the ping times within our datacenter are finally flat, as they should always have been »

« Petit à petit, tout se met en place et l’étau se resserre lentement mais sûrement, pour que l’argent liquide disparaisse des mains des citoyens, et que, progressivement, les États renforcent leur contrôle des populations sous leur coupe.

[...]

Le cash disparu, tout n’étant plus qu’électronique, on sait qui fait quoi et pour combien. On peut même facilement museler des opposants en les effaçant des transactions, puisqu’après tout, l’impossibilité d’accès à un compte en banque signe rapidement la misère pour le citoyen concerné.

[ NDLR : oui enfin ni ma banque ni Visa ni Mastercard n'ont le détails précis des biens achetés dans une grande surface... donc on se calme sur le « on sait qui fait quoi ». ]

[...]

Bien évidemment, la lutte contre le cash représente avant tout la lutte contre la fraude fiscale et sociale. Oh, pas celle avec les valises remplies de billets que certains politiciens s’échangent discrètement, mais plutôt l’économie souterraine, i.e. le travail au noir.

[ NDLR : pensons plus loin : le cash est une limite à la transparence. Je peux rémunérer qui je veux en échange de n'importe quoi (bien ou service) sans formalité et sans qu'aucun lien n'apparaisse entre nous. Pratique pour ne pas entrer dans le cercle sociale de quelqu'un. ]

[...]

Apparaît un bonus évident : lorsque tout est électronique, tout est en banque, et moyennant un taux négatif sur ces comptes, on oblige les gens à consommer. Pratique, lorsqu’on cherche absolument à noyer les dettes et les erreurs du passé dans une inflation soutenue.

[...]

Sur le plan moral tout d’abord, elle instille l’idée perverse qu’on peut, sans dommage sur l’individu, rendre instantanément tout le monde directement dépendant de l’État, de la naissance à la mort. Distribuez ce revenu pendant quelques années et au bout d’un peu plus d’une génération, plus personne ne se souviendra qu’avant son arrivée, des millions de gens se passaient de son existence et savaient vivre sans lui, sans l’État, exactement de la même façon que tout le monde est maintenant persuadé de l’absolue nécessité de la guerre permanente contre les drogues ou de l’interdiction du port d’arme, même si drogues et armes furent bien plus librement disponibles dans l’Histoire sans qu’il fut question de sociétés barbares ou médiévales (on parle d’il y a moins d’un siècle).

[...]

Sur le plan économique ensuite, ce revenu deviendra en pratique un plancher pour à peu près tout, créant de l’inflation de façon immédiate ou quasiment ; de la même façon que les APL (aides publiques au logement) ont tiré les loyers vers le haut pour quasiment l’intégralité de leurs montants, le revenu universel en fera de même pour à peu près tout ; tout étant renchéri, le gain pour ceux qui n’auront que ce revenu sera à peu près nul.

[...]

Dans cette optique, si on élimine toutes les aides diverses et variées et qu’on les remplace par une seule distribution simple et universelle, on comprend qu’on gagnera au moins sur les frais engendrés par la complexité précédente. [...] Cette même réalité nous rappelle en effet assez douloureusement que toutes les inventions du même acabit, toutes les aides censées réformer de fond en comble des systèmes de redistributions ont systématiquement fini par s’ajouter à l’édifice socio-légal déjà existant.

[...]

À moins bien sûr que toute cette manœuvre n’ait qu’un seul but : celui de pousser à la consommation et donc, de créer de l’inflation, Graal vital pour nos keynésiens en charge de saboter bibliquement l’économie mondiale.  »

Avis intéressant.

De très bons rappels sur les avantages du cash sur la monnaie électronique.

Sur le revenu de base, je partage la dépendance à l'État et comme d'hab, je me demande si l'on ne peut pas faire un revenu de base parfaitement local, à la manière des SEL, de la solidarité de groupes (qui auront le défaut d'être des moteurs d'exclusion sociale :( ). Je partage le fait que l'inflation est inévitable rendant les produits de consommation de base inaccessibles aux seuls bénéficiaires du revenu de base (il faudra donc trouver un job alimentaire et bis repetita). Le revenu de base ne peut pas fonctionner dans l'économie de croissance actuelle.

Via Le Hollandais Volant (http://lehollandaisvolant.net/?mode=links )

« J’ai écrit ce précédent billet alors que je travaillais dur sur un projet. J’étais employé. C’était intéressant et bien payé. Mais inutile pour le commun.

Depuis j’ai connu pour la première fois de ma vie le chômage après 20 ans d’emploi ininterrompu. Je ne suis plus employé, et heureusement, je travaille tout le temps

[...]

Le samedi je me lève aussi parce qu’on a école le samedi matin dans mon village et que je vais donner des cours bénévoles d’informatique et de culture numérique car les services publics ne le feront pas.

[...]

Les nuits ne sont pas non plus de tout repos. Nous sommes famille d’accueil, crois moi Monsieur le réformateur, il parait que je suis « inactif », mais la grasse matinée ce sera pour une autre vie.

Mes journées sont bien pleines. J’aide des associations, j’essaye d’apprendre aux gens comment collaborer via internet, je leur fais des sites web, je dépanne les PC vérolés, je développe un outil de gestion de documents en ligne pour l’école, j’ai monté un site pour l’organisation de l’aide aux réfugiés dans le Morbihan, j’aide qui je peux. Un chouette boulot. Un vrai travail. Pas un emploi.

Tout cela est bien modeste, mais toutes ces petites choses me semblent utiles au commun, au développement de notre commune.

Il va falloir que j’arrête tout ça. Et c’est dommage parce que ce travail me plait vraiment. Si j’avais par exemple un salaire à vie ou un revenu de base je pourrais certainement m’y épanouir. En fait je travaille pour un peu tout le monde, mais surtout des gens qui ne pourraient pas se payer mes services, alors qu’au final, c’est l’intérêt de tous.

J’ai essayé d’imaginer des façons d’exercer ce type d’activité tout en pouvant en vivre dans le système actuel. Je n’ai pas trouvé. Je pense notamment à l’éducation populaire au numérique qui me semble un chantier astronomique et essentiel, c’est évidemment sans espoir. On va vers une fermeture de notre bureau de Poste, l’école est menacé de perdre une classe, partout les budgets sont restreints, il parait qu’il faut être « réaliste », alors mes lubies d’émancipation citoyenne, ce n’est pas exactement une priorité.

Je vais penser à mon intérêt privé, mais je ne ferai pas semblant de croire que l’amélioration de ma condition bénéficiera au final à la collectivité.

Du point de vue des gens « modernes » comme Monsieur Macron, je suis actuellement un poids, je ne produis pas, je suis une charge qui vit au crochet d’un système trop généreux. C’est bizarre, il me semble pourtant n’avoir jamais autant servi notre Société. Mais notre Société n’aura à nouveau d’estime pour moi que si je reprends un emploi de col blanc pour mon profit et celui du grand capital :) »

Quelques petits rappels concernant les Commissions parlementaires.

« En début de législature, puis chaque année au début de la session ordinaire, l’Assemblée nomme, sur la base de la représentation proportionnelle des groupes politiques et sur proposition des présidents de ces groupes, les membres des commissions permanentes.

[...]

Les commissions permanentes sont généralement soumises à une très forte contrainte, celle du temps. [...] Mais ce principe est très difficile à respecter, surtout depuis que l’institution de la session ordinaire unique (en 1995) a concentré la séance publique sur trois jours (mardi, mercredi et jeudi). Le mercredi matin est réservé aux travaux des commissions. La quasi-totalité des réunions de commission se déroulent le mardi après-midi et le mercredi.

[...]

C’est afin d’alléger cette contrainte que la révision constitutionnelle du 23 juillet 2008 a introduit l’exigence d’un délai de six semaines entre le dépôt d’un texte et son examen en première lecture devant la première assemblée saisie [...] Ces délais ne s’appliquent cependant ni en cas d’engagement par le Gouvernement de la procédure accélérée, ni aux projets de loi de finances et de financement de la sécurité sociale, ni aux projets relatifs aux états de crise.

[...]

La révision constitutionnelle du 23 juillet 2008 a modifié l’article 42 de la Constitution, de telle sorte que, depuis le 1er mars 2009, la discussion des projets et propositions de loi porte, en séance, sur le texte adopté par la commission saisie au fond [...] Ce n’est qu’à défaut de l’établissement d’un texte par la commission, soit qu’elle ait voté le rejet du texte, soit qu’elle n’ait pas pu achever l’examen du texte dans les temps, que le texte discuté en séance publique est celui dont l’assemblée a été initialement saisie.

[...]

En conséquence, il faut, si l’on souhaite combattre la position retenue par la commission saisie au fond, présenter en séance un amendement en sens contraire.

Une dérogation à cette nouvelle règle d’examen a toutefois été prévue au deuxième alinéa de l’article 42 de la Constitution, en faveur des projets de révision constitutionnelle, des projets de loi de finances et des projets de loi de financement de la sécurité sociale, dont la discussion en séance porte, en première lecture devant la première assemblée saisie, sur le texte présenté par le Gouvernement, puis, pour les autres lectures, sur le texte transmis par l’autre assemblée. »

« This tool maintains the ROA table of the BIRD Internet Routing Daemon (http://bird.network.cz). It automatically adds and deletes ROA information using the RTRlib (http://rpki.realmv6.org/).

This tool brings RPKI functionality to BIRD but does not require any changes to the BIRD code base. The program runs in parallel to the BIRD daemon and communicates with the daemon via the BIRD control socket. »