YBoy360 a écrit 673 commentaires

J'aimais bien Firefox et Thunderbird, mais je n'apprécie vraiment pas les dernières décision de la MoFo.

Ce que je n'apprécie pas concernant la MoFo :

• le quasi abandon de Thunderbird, malgré les moyen dont ils disposent, pour moi c'est un pièce crutiale du libre, il semble vivre sa vie comme un vilain petit canard au sein de la fondation ;
• Le rejet de toutes techno venant de Google (Dart VM, PNaCL, …), OK, c'est Google, mais moi j'aimais bien, et il eut fallu des avis constructifs sur le sujet ;
• Leur moteur était plus difficile à maintenir que Webkit (avis personnel), qui doit son origine à KTHML, le moteur de rendu HTML de KDE, qui était un moteur très compacte, adapté aux mobiles. Si Apple puis Google base leur navigateur dessus, ce n'est pas par hasard.

J'apprécie particulièrement Webkit, c'est un fait. En partie, car les développeurs sont les mêmes que pour KHTML. Ils essayent de rendre leur moteur maintenable, c'est encore un avis personnel, mais personne parle du code de FF vs le code de Webkit. Certes, ce n'est pas à la porté du premier venu, mais si toute l'industrie choisi ce moteur, c'est sans doute pour ce genre de raison.

Concernant les performances brutes, sous Linux, par rapport à FF, désolé, sur ma machine, la page suivante est catastrophique sur FF (d/l les 2 fichiers, puis ouvrir le fichier HTML, c'est un bête canvas, avec du picking) :

client-area-tests

P-e que ça fonctionne bien sur FF sous Windows, super …

Même si j'utilise et adore Kotlin (hors d'Android), Groovy a largement plus de légitimité pour avoir la primeur sur ces fonctionnalités.

Gradle est un très mauvais exemple de comment faire du Groovy, je pense que ça le dessert plus qu'autre chose. Mais bon, ça lui permet d'avoir une certaine présence.

C'était quelqu'un de vraiment accessible, on a beaucoup échangé lors de mon mentoring (je n'ai pas le temps matériel de contribuer à Mageia). Il était partout, je pense à lui, à son fils et à sa famille.

J'aimerai ne pas avoir lu cette triste nouvelle. J'enterre aussi mon père demain. Mon moral est dans mes chaussettes.

Ils ont encore de quoi tenir suffisamment longtemps pour se retourner. Je me méfie toujours de ceux qui annoncent la mort des grandes entreprises tôt comme ça. Intel serait déjà mort, Microsoft aussi, Apple aussi, AMD pareil, Facebook n'en parlons pas,…

C'est un peu différent dans le cas d'Intel pour 3 raisons :

• Faire un processeur est extrêmement capitalistique, contrairement à ce que fait MS ou Facebook, un nouveau processus de fabrication coûte des milliards pour la mise en oeuvre, ne pas être à niveau aujourd'hui c'est l'être encore moins demain ;

• Le conseil d'administration a nommé l'ancien DAF (Directeur Administratif et Financier) comme dirigeant. En général, ça fonctionne pas pour les boites hi-tech (loin de moi l'idée de dire qu'ils sont des incapables, mais je n'ai pas d'exemple de financier ayant réussi dans l'industrie) ;

• Le DAF en question a suggéré de fabriquer des puces par TSMC, ça c'est la preuve qu'ils sont vraiment dans une passe inquiétante car le jeu d'instruction Intel implique une surconsommation de l'ordre de 30 % par rapport au jeu d'instruction ARM (désolé, pas de liens, je parle bien du jeu d'instruction, pas de l'architecture, car l'unité de décodage pour passer du CISC au RISC consomme 30 % de transitor d'un core sur le die), à processus de fabrication équivalent, ils seront derrière ARM, il tenait avant grâce à leurs supers usines.

Enfin, concernant l'out-of-order, la prédiction de branchement, autres, ce n'est pas une spécificité d'Intel, ARM s'est mis à le faire il y a déjà un certain temps, chez Intel, les Atoms n'en dispose pas, le compilateur ne peut pas prévoir tout statiquement et les gains associés sont quand même important, alors je doute que ça disparaisse.

tes pupilles se protègent p-e plus en voyant un écran blanc qu'un écran tout bleu. Mais bon, le wifi c'est pas bon, la 5G, n'en parlons pas, et il parait que se droguer c'est mal.

C'est vrai que c'est moins flashy que l'écran bleu d'un PDP-1 OS.

Je connais bien Javadoc, et je sais bien qu'il s'agit de la documentation d'une API.. c'est même ce que je dis dans mon 1er message. Normalement si il s'agit d'une API, c'est vrai que le code est trivial par nature. De plus les IDE proposent d'afficher le Javadoc au survole de la méthode…

Asciidoctor permet déjà de mettre des extraits de code à partir d'un numéro de commit et un numéro de ligne. On pourrait appliquer ce principe pour commenter une API.

Avantages : i18n, documentation API composite, enrichie aux extraits de code des tests venant des sources pour montrer l'usage de l'API, documentation structurée.

Si on a pas besoin de tout ça, juste d'une documentation de l'API, c'est difficile de faire mieux que les Javadoc like, je te l'accorde.

Je suis bien au courant. Quasiment tous les projets java utilisent ce principe. Cela dit, avec asciidoctor par exemple, on devrait pouvoir externaliser cette documentation. Ça fait sens si on veut la traduire et même documenter à partir des tests, des exemples de code tiré du git, présent dans d'autres fichiers.

Je veux bien documenter une classe, au dessus du code de celle-ci, car ça ne gêne pas la lecture du code. Par contre documenter toutes les méthodes est une perte de temps, surtout lorsque ça paraît triviale. La doc inline qui explique un passage complexe est bien sûr primordial.

Trop commenter le code nuit à sa lisibilité. En plus le bleu sur nos écrans c'est mauvais pour les yeux.

C'est vraiment important de commenter 1 pauvre ligne de code aussi triviale ? Alors oui, javadoc et tout, mais avec d'autres IDE, on accède au code très rapidement et on préfère le lire directement plutôt que de se coltiner la doc de chaque méthode.

Puis ça oublie gentiment Axelor …

ils ont annoncé 2 ans pour mener la migration, tout en précisant que des machines Intel sortiraient. En tout cas, la présentation WWDC était vraiment impressionnante en ce qui concernait la migration ARM : il y a déjà Office et Adobe, le tout semblait fonctionner dans une machine au format Mac mini, y compris Premier en 4K, avec tout un tas de filtres.

Il ne faut pas oublier qu'Apple côtoie ARM depuis Newton, Arm Holdings (Advanced RISC Machines) est une joint venture entre Acorn et Apple. Si on regarde la progression des performances en l'espace de 10 ans des puces Apple sur leurs téléphones, on est dans un autre registre que les puces x86 (c'est vrai que les procédés de fabrication y sont en partie responsable).

Donc potentiellement, Apple peut avoir des performances par thread suffisantes pour leurs besoins rapidement, d'ici 2 ans.

Tout est dans le potentiel. Le turfu quoi, pas la situation actuelle.

La situation actuelle n'est pas non plus désespérante. En performance par Watt, si tu ne te limite pas aux benchmarks orienté FLOPS, t'obtiens quelque chose de déjà compétitif, avec une consommation moindre.

Or les performance per watt, c'est capital pour le potentiel de progression d'une plateforme. Faut pas oublier que tous les correctifs appliqués pour juguler les failles des procos Intel les ont aussi bien ralentis.

Mince, j'avais pas vu le lien précédent en français… Sorry pour les familles tour ça.

Il semblerait que oui :
https://github.com/groovy/groovy-android-gradle-plugin

Ce serait dommage si ce n'était pas possible, Gradle est utilisé pour le build des applications Android, alors pourquoi pas pour les applications directement..

Cela dit, je n'ai pas essayé. Mais la version OpenSource d'Intellij supporte Groovy, donc normalement pas de problème pour faire ça confortablement.

Édite : En fait non, c'est déprécié…

Il faut installer

# urpmi plasma-workspace-wayland

puis relancer KDE (5.18.3 sous Cauldron) en choisissant dans sddm "Plasma (Wayland)" et suivre les instructions du journal.

Résultat : ça doit dépendre lourdement de la carte graphique car ce n'est pas foufou sous KDE, j'utilise un contrôleur intégré Intel.

Kwin est en retard sur Wayland, il y a des bug graphiques lorsque l'on passe les fenêtres les unes sur les autres, style le z-index est au fraise. Il faudrait tester avec un autre gestionnaire de fenêtre purement Wayland (Sway ou Weston). Ou Gnome bien sûr.

oui, il faut attendre et ce sera sans doute en défaveur de l'Allemagne et la Suisse, donc je suis d'accord. L'épidémie sévit depuis plus longtemps en Corée…

Mais il y a 2 autres facteurs qu'il faudrait prendre en compte, en leur faveur :

• la Corée du Sud est quasiment une île … En Allemagne et encore plus en Suisse, il y a beaucoup de trafic transfrontalier ;
• l'épidémie se propage moins si peu de famille avec enfants. Il devrait y avoir une corrélation directe avec le nombre de famille avec enfants et la rapidité de propagation du virus. Je connais pas les chiffres, car la Lombardie est la région la plus touchée et sans doute avec peu de famille avec enfants proportionnellement au reste de l'Europe.. Par contre la Corée, à ma connaissance est encore moins bien lotie question natalité que l'Italie.

Je connais un peu les Coréens, ils sont plus proche de nous que nous ne le pensons. Certes, c'est un peuple coercitif, mais différent du Japon.

La Suisse et l'Allemagne s'en sortent encore mieux que la Corée du Sud pour le moment. Ils sont aussi en Europe (géographiquement au moins)…

En Corée, il y a une forme d'isolement des malades qu'il est difficile de faire accepter ici : Il y a des caméras thermiques qui les localisent et transmettent leur position aux autres. Ils sont évidement confinés chez eux. Si ça ce n'est pas de la distanciation sociale …

De plus, comme dit dans les précédents journaux, ils ont connu le H1N1, le SRAS, et p-e le virus est-il moins virulent en Corée (souche différente, température moins propice).

Là où tu marques un points, c'est qu'on a l'impression qu'en France on se repose sur des "experts" souvent âgés, et sur des compétences qui ne tiennent pas compte des avancés technologiques/scientifiques. Trop peu de grands dirigeants en France ont un baqkground "ingénieur" ou scientifique. On a l'art de faire de la politique pour faire de la politique.

En Allemagne et en Suisse, ce n'est pas le cas.

Surtout quand on lit mal son propre graphique et qu'on minimise à la main … J'aurais au moins dû mettre la variance.

Pour info, j'utilise maintenant l’algorithme conseillé venant du package minpack.lm, ça donne des résultats plus précis.

Autant pour l'Espagne la date semble ne pas trop bouger (entre le 28,5 et le 29,5) d'un jour sur l'autre, autant pour l'Italie, ça a glissé énormément … J'essaie de minimiser en moyennant les prédictions sur les derniers jours. ça permet de lisser des cas de saturation des hôpitaux et ça donne une date un peu plus stable (entre le 23 et le 24).

J'attends la semaine prochaine pour la France et les US.

j'ai ajouter sur github la variance des résultats. Et j'ai ajusté par rapport aux derniers relevés, je vais continuer à le faire en gardant un historique.

Tout va se jouer dans les prochains jours en Italie. J'espère que la situation ne va pas trop empirer.

Pour la France, il y a un grand plateau, ce qui est rassurant, et peut s'expliquer par le fait que le virus a été virulent d'abord dans le "Grand Est", puis est allé sur Paris, avec un certains décalage. Puis enfin, les mesures de confinement.

Bien sûr, ces courbes ne connaissent pas la géographie, ou les mesures politiques.

Elle pourrait cependant être intéressante si la progression du virus est de > à 2 pour 2.5 jours. Car, dans ce cas, l'effet du confinement est moins visible (grande partie de la population infectée, difficile à contrôler). Si une grande partie de la population est infectée, l'année prochaine, le virus devrait avoir beaucoup plus de mal pour se propager, et sa létalité serait moins forte.

Après, il y a la capacité et l'efficacité des hôpitaux qui croissent dans le temps, mais peuvent se trouver en sur-capacité.

Un dernier mot concernant les tests : ils ne détectent que les porteurs du virus, on ne détecte pas ceux qui ont eu le virus. Donc très difficile d'estimer la population totale par extrapolation à partir des tests.

merci pour ce lien, je vais essayer d'utiliser ces outils.

Je pense qu'il faut aussi mettre en avant la variance, et l'incertitude qu'elle projette dans le résultat final. sachant qu'aujourd'hui la variance est de 800, elle doublera pour le résultat final.

Merci, je l'adapterai sur git demain, en même temps que la mise à jour des résultats. Je vais essayer d'améliorer l'ajustement des paramètres pour des valeurs non entière, notamment sd.

Bonne soirée.

c'est presque facile de simuler le cas où il n'y a pas de mesures. Au moins, ça donne une indication du pire des cas. Ce qui est déjà pas mal.

Si on fini avec moins de 10 000 cas en Italie, alors que la propagation du virus double tous les 3 jours, ça permet d'ajuster la létalité du virus par rapport à ce qui nous est communiqué.

Pour info, on trouve comme paramètres pour la courbe théorique avec le second algorithme de convergence :

amplitude = 9571 (c'est le nombre de morts total)
jours = 31 (ce n'est pas demain, mais après demain)
largeur de la gaussienne = 8

Je vais mettre ça sur github au propre.

Version plus optimiste que la précédente et sans doute plus juste :

# d: dataset, m: mean, sd: width, a: aplitude

normApplitude <- function(d, m, sd) {
  d[length(d)] / pnorm(length(d):length(d), mean = m, sd = sd)
}

normVariance <- function(d, m, sd, a) {
  var(d - pnorm(1:length(d), mean = m, sd = sd) * a)
}

mTab = c(length(d):(length(d)+40))
sdTab = c(4:10)

print(mTab)
print(sdTab)
vOrig = Inf

aApprox = 0
mApprox = 0
sdApprox = 0

for (a in c(5000:20000)) {
  for (sd in sdTab) {
    for(m in mTab) {
      v = normVariance(italy, m, sd, a)
      if (v < vOrig) {
        sdApprox = sd
        mApprox = m
        aApprox = a
        vOrig = v
      }
    }
  }
}

Les résultats diffèrent un peu de ce que je trouve à la main … J'analyse et je fais un retours.

J'ai ajouter dans github le code de convergence. Il ne se limite qu'a calculer les parties entières des paramètres.

C'est crade, mais le voici :

# d: dataset, m: mean, sd: width, a: aplitude

normApplitude <- function(d, m, sd) {
  d[length(d)] / pnorm(length(d):length(d), mean = m, sd = sd)
}

normVariance <- function(d, m, sd, a) {
  var(d - pnorm(1:length(d), mean = m, sd = sd) * a)
}

mTab = c(length(d):(length(d)+40))
sdTab = c(4:10)

print(mTab)
print(sdTab)
vOrig = Inf

aApprox = 0
mApprox = 0
sdApprox = 0

for (sd in sdTab) {
  for(m in mTab) {
    a = normApplitude(italy, m, sd)
    v = normVariance(italy, m, sd, a)
    if (v < vOrig) {
      sdApprox = sd
      mApprox = m
      aApprox = a
      vOrig = v
    }
  }
}

il faut rentrer le tableau du nombre de morts "italy", puis sourcer le code.

Je connais pas bien RStudio, je l'utilise seulement depuis hier. Je relève le défi, je vais essayer de faire une fonction qui détermine les variables par dichotomie.

Par contre, pour la version manuelle, j'ai d'abord utilisé le fichier ODS pour avoir une idée de ce que je cherchais… ça ne va pas être si simple de ne pas partir de n'importe quoi.