SChauveau a écrit 389 commentaires

Pourquoi quelqu'un mettrait il une clef USB dans une centrifugeuse? Suis je bête! C'est pour séparer les 0 et les 1 bien sûr.

Cool. Je ne suis pas vraiment surpris car il est difficile d'inventer des choses vraiment originales surtout quand le concept est très simple.

Je ne connais pas trop le monde du P2P mais il me semble qu'il devrait être possible de faire en sorte qu'il ne soit pas possible de prouver que l'utilisateur a téléchargé le fichier. Par exemple, considérons 10 des fichiers Ai dont certains sont interdits et d'autres sont autorisés. Pour faire simple, je considère qu'ils ont tous la même taille. L'astuce consisterai à distribuer des fichiers Bi obtenus soit aléatoirement soit en combinant plusieurs Bi et un Ai. Dans l'idéal on s'assurera aussi que chaque fichier Bi est utilisé pour créer au moins un Ai legal. Voici un exemple avec des nombres 32bit représentant les fichiers à distribuer.

#include <stdlib.h>
#include <stdio.h>

int main(void)
{
  unsigned A[4] = {
    0xDEAA32EE, 0xF9942233,  // valeurs interdites
    0x72DCAA3E, 0x2EFBDF29   // valeurs autorisées
  };
  printf("Valeurs à distribuer\n");
  for (int i=0;i<4;i++) {
    printf("A[%d] = %04X  (%s)\n", i, A[i], (i>=2)?"illegal":"legal") ;
  }
  printf("Valeurs effectivement distribuées en P2P\n");
  unsigned B[9] ;
  B[0]  = rand();
  B[1]  = rand();
  B[2]  = A[0] ^ B[1] ^ (~B[0]);
  B[3]  = rand();
  B[4]  = ~(A[3] ^ B[2] ^ B[3]);
  B[5]  = rand();
  B[6]  = A[2] ^ B[0] ^ B[5];
  B[7]  = rand();
  B[8] = A[1] ^ B[3] ^ B[6] ^ B[4] ;
  for (int i=0;i<9;i++) {
    printf("B[%d] = %04X\n", i, B[i]) ;
  }
  printf("Formules publiques (ou pas)\n");
#define compute(NAME, F) printf("%s = %s = (%04X)\n", NAME, #F, F)
  compute( "A[0]" , B[1] ^ (~B[0]) ^ B[2]);
  compute( "A[1]" , B[8] ^ B[3] ^ B[6] ^ B[4] ) ;
  compute( "A[2]" , B[0] ^ B[5] ^ B[6] ) ;  
  compute( "A[3]" , ~B[4] ^ B[2] ^ B[3] ) ;
  return 0;
}

-> résultat

Valeurs à distribuer
A[0] = DEAA32EE (legal)
A[1] = F9942233 (legal)
A[2] = 72DCAA3E (illegal)
A[3] = 2EFBDF29 (illegal)
Valeurs effectivement distribuées en P2P
B[0] = 6B8B4567
B[1] = 327B23C6
B[2] = 78A5ABB0
B[3] = 643C9869
B[4] = CD9D130F
B[5] = 66334873
B[6] = 7F64A72A
B[7] = 74B0DC51
B[8] = 2F510E7F
Formules publiques (ou pas)
A[0] = B[1] ^ (~B[0]) ^ B[2] = (DEAA32EE)
A[1] = B[8] ^ B[3] ^ B[6] ^ B[4] = (F9942233)
A[2] = B[0] ^ B[5] ^ B[6] = (72DCAA3E)
A[3] = ~B[4] ^ B[2] ^ B[3] = (2EFBDF29)


Avec un tel systême, il serait difficile de prouver qu'un utilisateur a télécharger un fichier illégal de façon intentionnelle puisque les fichiers Bi sont aussi utilisés pour recréer des fichiers légaux. A priori, il n'y a aucun moyen de différencier les fichiers B[i] générés aléatoirement de ceux calculés avec une formule utilisant un fichier illégal. Interdire le partage de fichiers à priori aléatoires me semble difficile à justifier surtout si ils ont un usage légitime.

Par curiosité, pourquoi 1% ? Cette valeur a t'elle quelque chose de spécial ? Est ce mieux que 3%, 0.4% ou 5.23647% ?

Cela se passait assez récemment dans un petit village du Pays de Gales.

Tout les matins à 7h, les 400 habitants perdait temporairement leur signal TV.

Au final, il s'est avéré que le problème venait d'un vieux poste que son propriétaire allumait probablement pour regarder les infos en prenant son petit déjeuner.

https://www.bbc.com/news/uk-wales-54239180

Ça va pas faire. Je suis emacsien depuis 20 ans :-)

Pour commencer, je ne suis pas du tout un expert en ergonomie donc mes idées sont à prendre avec des pincettes. Ma vision consisterai simplement en un bouton toggle 'Edition' dans le menu ou dans un coin de l'écran. Quand il est actif, l'interface serait exactement comme maintenant. Quand il est inactif, tout les éléments relatifs à l'édition sont cachés:
- bouton delele feed
- bouton select feed
- bouton edit feed
- grip handle
- les cadres sous des colonnes
- …

J'ai compris! Le 'Tour' ne marche correctement que dans le 1er Tab.

Le Grip Handle est expliqué dans le 'Tour' mais pour une raison que j'ignore, les premières fois que je l'ai utilisé, le 'Tour' a arrêté d'indiquer la position des éléments graphique après la 3ième ou 4ième étape. Le texte d'aide était simplement affiché dans le coin en haut à gauche. Maintenant cela marche.

Après quelques minutes d'utilisations, j'ai 2 petites remarques:

(1) Je n'aime pas trop avoir les boutons d'éditions constamment à portée de clic (en particulier les 'Delete'). Je trouve que cela "pollue" un peu l'UI. Avez vous considéré l'idée se séparer l'édition et l'utilisation?

(2) Un clic sur le titre d'un feed ouvre l'URL du site tel que spécifié par le rss. Malheureusement, avant le 1er chargement du feed, c'est l'URL du fichier RSS qui est téléchargé. Ce n'est clairement pas ce qui m'intéresse. Dans la configuration du feed, je propose d'ajouter un champ pour l'URL du site. Ce champ pourrait être automatiquement rempli lors du 1er chargement du rss.

J'ai finalement trouvé. Pour que le drag & drop fonctionne il faut utiliser la petite zone entre l'icone et le texte. Et le bouton "Select this feed" permet d'en sélectionner plusieurs pour un déplacement groupé.

Cela me semble intéressant mais est il possible de réorganiser les feeds? Le drag & drop ne semble pas fonctionner et je vois pas de boutons copier/coller.
Il y a bien le bouton "Select this feed" mais je n'arrive pas à lui trouver la moindre utilité?

Dans le tout dernier enregistrement daté de mars on entend "Ha Ha Hou C'est chaud!"

«Upon discovering this, Sergei immediately filed immigration papers with any country that would listen»

Pourquoi? La réponse appropriée consistait à éloigner le serveur de quelques mètres ou à insérer une plaque de métal pour blinder la RAM.

Dans le même genre que l'octal il y a les problèmes liés aux locales. C'est bien connu pour les dates (1/4/21 = 1er avril en FR = 4 janvier en US) mais aussi pour les formats de nombres (19.5 en US = 19,5 en FR).

(bash) export LC_ALL=C
(bash) printf "%f\n" "4.5"
4.5
(bash) export LC_ALL=fr_FR.utf8 
(bash) printf "%f\n" "4.5"
bash: printf: 4.5: invalid number
4,000000

Par décalage horaire, j'imagine qu'il faut comprendre la synchronisation des horloges (NTP). Une mauvaise synchro, peut causer des problème bizarre par exemple avec les systèmes de fichier en réseau. Par exemple, Make peut se mettre à ignorer certains fichiers récents car ils ont une date dans le futur.

Cela me rappelle un bug qui m'a pris la tête pendant au moins une semaine. Mon histoire n'est pas aussi intéressante car au final il ne s'agissait que d'un banal dépassement de tableau.
Je développais un compilateur et un jour je constate plusieurs plantages sur un serveur de tests. Des joli segfaults bien propres. J'essaye sur ma machine et surprise … cela fonctionne. Idem sur les autres serveurs à ma disposition. Le bug ne se produit que sur 1 seul serveur. C'est inhabituel car cet outil est sensé être parfaitement déterministe.

Pour ne rien arranger, le bug disparaît quand je recompile en mode debug et Valgrind ne me dit rien d'intéressant. Les serveurs sont identiques avec les même processeurs, les mêmes DRAMs, le même OS (debian) et les mêmes bibliothèques. Je m'assure que la randomization d'adresses est désactivée, que tout les fichiers concernés (data, libs, exécutable, …) ont les mêmes checksums, que les horloges sont bien synchronisées, que le kernel linux est identique, … etc etc etc
Tout est pareil mais ce fichu test continue à planter sur un unique serveur. C'est la 5ieme dimension ce truc. Est ce que le bug serait dans le hardware? C'est rare mais cela m'est déjà arrivé. Après plusieurs jours, je commence à sérieusement douter de mes capacités. Peut être ne saurais je jamais pourquoi notre compilateur plante sur zorglub-test mais pas sur paglop-test ou iznogoud-test?
WTF … wait a second … "zorglub-test" fait 12 caractères de long alors que les 2 autres en font respectivement 11 et 13. Cela ne peut pas être aussi simple:

# ./run-buggy-test
segfault
# export HOSTNAME=123456-test
# ./run-buggy-test
 => Success

Et si! Le système de logs du compilateur initialisait une chaîne de caractères contenant le HOSTNAME dans un tableau trop petit de 1 caractère. Classique! Moins de 12 caractères, pas de problèmes. Plus de 12 caractères, dépassement de tableau mais pas de crash. Exactement 12 caractères et le \0 de fin passe la variable immédiatement après le tableau de vrai (1) à faux (0) et beaucoup plus tard … BOOM.

Un lien Wikipedia vaut mieux qu'un long discours.

https://fr.wikipedia.org/wiki/Principe_de_Dilbert

et aussi

https://fr.wikipedia.org/wiki/Principe_de_Peter

De mémoire, il me semble que pour la COVID 19 la période du R0 est d'environ 10 jours. C'est parce que l'incubation est d'environ 1 semaine et que l'on est contagieux pendant 1 semaine. En moyenne, il y a donc 1.5 semaines (~10 jours) entre 2 générations de contaminés.

En pratique cela signifie que pour un R0 de 2 le nombre de contaminé devrait doubler en 10 jours.

Par exemple, dans les 2 semaines avant le pic de Novembre 2020, le R0 était d'environ 1.5 et le taux d'incidence a doublé en une quinzaine de jours (soit 1.5 générations): 1.5^1.5 = 1.84

PS: Cette période est différente pour chaque virus et j'imagine qu'elle change aussi en fonction des variants.

PPS: Les nombres ci-dessus sont probablement faux. Il y a sûrement des études précises sur le sujet mais j'ai la flemme de chercher. C'est peut être 8 ou 12 jours. En tout cas, ce n'est certainement pas quelques heures.

C'est probablement un peu simpliste mais il me semble que l'on peut modéliser le R0 comme le produit de plusieurs coefficient variant avec le temps. Par exemple,

R(t) = Rv(t) * Ce(t) * Cc(t) * Cd(t) * Ci(t)

avec

Rv(t) = Taux de reproduction de base pour les variants en circulation à l'instant t.

Ce(t) = Coefficient environnemental (climat, température, humidité, vent, …)

Cc(t) = Coefficient culturel (vacances, us et coutumes, …)

Cd(t) = Coefficient de distanciation sociale (confinement, masques, …)

Ci(t) = Coefficient d'immunité (naturelle ou vaccins)

La vaccination n'affecte que le coefficient d'immunité. Au vue des chiffres de la vaccination, Ci(t) doit actuellement être proche de 0.8 et il diminue d'environ 0.02 par semaine. Pendant les 2 semaines suivant le déconfinement, Ci(t) a donc du diminuer d'environ 0.04 (4%) alors que le Cd(t) augmentait sensiblement. Le temps était plutôt humide avant le 19 mai donc on peut aussi supposer que le Ce(t) a changé significativement avec le retour du soleil (en bien ou en mal?).

Il n'y a donc aucune incohérence dans le fait que R(t) remonte temporairement alors que le Ci(t) diminue.

En effet. D'ici quelques mois, quand le nombre de cas sera quasiment nul, le R0 perdra de sa pertinence.

Outre le R0, il y a un graphique qui, me semble t'il, illustre bien l'efficacité de la vaccination massive sur les + de 60 ans. https://covidtracker.fr/covidtracker-france/#heatMapIncidence

La page https://fr.wikipedia.org/wiki/Statistiques_sur_la_pand%C3%A9mie_de_Covid-19_en_France contient un graphique montrant l'évolution du taux de reproduction depuis le début de l'épidémie.

Il y a aussi https://www.gouvernement.fr/info-coronavirus/carte-et-donnees#situation_epidemiologique-taux_de_reproduction_effectif

Les données brutes sont disponible au format CSV dans https://www.data.gouv.fr/fr/datasets/indicateurs-de-suivi-de-lepidemie-de-covid-19/

Pour le R0, la dernière valeur officielle est vieille d'environ 2 semaines. C'est probablement parce que l'effet des contaminations ne se fait sentir qu'après plusieurs jours ou semaines (tests, appels aux urgences, hospitalisations, …).

Il y a effectivement eu une remontée de 0.77 à 0.88 après la fin du confinement mais s'était à prévoir. Il n'est pas totalement impossible que le R0 remonte temporairement jusqu'à 1.0 si les mesures de distanciation sociales se relâchent trop. Toutefois, avec le rythme actuel des vaccinations (environ 15% par mois), je parierai quand même sur une baisse sensible du R0 au cours de l'été (avec de légères fluctuations en fonction de la météo et d'autres facteurs plus ou moins identifiés).

Je ne suis pas inquiet pour l'exécution sur mes Rpis mais comme tu écrits «Tu ne pourras donc pas l'utiliser directement sur ta machine et devra passer par du matériel compatible», je proposais plutôt d'utiliser qemu pour lancer un exécutable ARM de façon transparente sur un PC x86/amd64

https://ownyourbits.com/2018/06/13/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt_misc/

Cela pourrait s'avérer utile. J'ai égaré mon Kobo dans un avion il y a quelques années et j'envisage d'en racheter un.

J'ai un Raspberry Pi mais je suppose qu'il devrait être possible de configurer un émulateur arm tel que qemu-system-arm pour utiliser ta lib de façon transparente.

Ou solution B, on engage un groupe de mercenaires pour qu'ils s'emparent des bureaux d'Adobe et dérobent les sources librmsdk genre «Piège de cristal».

Je suppose que tu parles de la pré-compilation du lisp en bytecode. Si c'est le cas, cela accélère le chargement des fichiers lisp mais pas leur utilisation proprement dite.

Toutefois, la (future?) version 28.1 permet la compilation du lisp en code natif. https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS

    * Installation Changes in Emacs 28.1

    ** Emacs now optionally supports native compilation of Lisp files.
    To enable this, configure Emacs with the '--with-native-compilation' option.
    This requires the libgccjit library to be installed and functional,
    and also requires GCC and Binutils to be available when Lisp code 
    is natively compiled.  See the Info node "(elisp) Native Compilation"
    for more details.

En théorie cela devrait permettre d'accélérer certaines opérations coûteuses. Je ne sais pas si cela aura un effet notable sur la colorisation syntaxique des gros fichiers (c'est pénible à utiliser sur un Raspberry Pi 4) car le problème vient en fait du «garbage collector» qui interrompt l'exécution. Emacs n'est malheureusement pas multi-threads.

Je ne vois pas trop comment un programme avec les droits utilisateurs pourrait se mettre à jour tout seul ou peut être en installant les fichiers dans le dossier ~/.mozilla

Est ce que par hasard tu n'utiliserais pas Ubuntu? J'ai installé Ubuntu sur un Raspberry Pi il y a quelques mois et j'ai eu des problèmes d'espace disques causés par des mises à jours non demandées du kernel. J'ai finalement découvert que le problème venait du paquet unattended-upgrades qui comme le nom l'indique effectue des mises à jours automatiquement.

https://guide.ubuntu-fr.org/server/automatic-updates.html

Par défaut cela ne concerne que les mises jour de sécurité mais j'imagine que cela peut arriver pour Firefox.