Au tour de l’excellente application K9 (servant à la lecture de mails sur téléphone mobile) de se conformer avec les nouveaux réglages de Gmail, via l’authentification OAuth2.
Dans les réglages, il faut cocher l’authentification OAuth2 :
Ensuite, lors de la synchronisation des messages, une boîte de dialogue demande les paramètres (adresse et mot de passe) :
C’est simple.
Google a mis sa menace à exécution : « À partir du 30 mai, vous ne pourrez peut-être plus accéder aux applis qui utilisent une technologie de connexion moins sécurisée ». De fait, début juin 2022, impossible de recevoir ou d’envoyer des mails depuis thunderbird au moyen de compte Gmail :
Hélas, le support de Mozilla est pauvre en solution : https://support.mozilla.org/fr/kb/thunderbird-et-gmail et https://support.mozilla.org/fr/kb/conversion-automatique-comptes-google-mail-oauth20.
Voici comment faire, capture d’écran à l’appui.
Cas POP :
Cas SMTP :
Ce quatrième opus de la franchise « Men in Black » fut un échec cuisant. Dans ce billet, il ne sera toutefois question que de programmation informatique utilisée dans ce film.
En effet, au début du film, l’héroïne montre un de ses écrans. Elle recherche des extra-terrestres et a manifestement écrit un programme pour les débusquer :
On reconnaît évidemment du langage COBOL du fait des numéros de lignes et de la syntaxe truffée de SQL. D’ailleurs, il est très facile de retrouver le code source d’origine. Il s’agit d’un simple programme d’exemple présenté sur le site IBM.
À nouveau on ne peut que s’interroger sur ce décalage existant entre la programmation informatique présentée au cinéma et le monde réel de la programmation. Manifestement Hollywood vit dans un monde déconnecté.
Cette série en quatre épisodes est présentée dans un article du site Développez.
Un point intéressant dans le premier épisode, est la présentation d’un code source illustrant le travail de codage du principal informaticien :
On reconnaît évidemment du code en langage C++, qui contient même un lien vers le site MSDN. Ce code est facile à retrouver sur GitHub : il s’agit d’un extrait du fichier keylogger.cpp du projet FTPKeyLogger.
On peut noter 2 points concernant ce choix :
1/ Ce programme a été écrit bien après les événements du film (l’action du film se situant entre la fin des années 90 et au début des années 2000). Or, le lien MSDN du programme date de 2011 selon toute vraisemblance selon Internet Archive.
2/ Pour une fois, le code source présenté n’est pas trop éloigné du film qui le présente, mais quand même, présenter un outil qui automatise la saisie de tout ce qui est tapé au clavier et qui envoie ensuite le résultat sur un serveur FTP, c’est quand même limite. Même si après tout ce genre de programme est en accès libre.
Bien que Windows 10 soit une belle amélioration par rapport à ses prédécesseurs, et en attendant Windows 11, il reste pas mal de composants inutiles qui consomment des ressources. Tels les widgets et autres applications faciles à retirer. Il reste pourtant au cœur du système d’autres composants nuisibles. Par exemple le service « Expériences des utilisateurs connectés et télémétrie ». Ce service qui se permet de consommer 100% de CPU sur 1 thread pendant longtemps ne sert qu’aux besoins de Microsoft (sans qu’on sache très bien ce qui est envoyé d’ailleurs), pas à l’utilisateur. Du coup, il suffit de l’arrêter définitivement.
Il y a seulement 4 ans, le machine learning apparaissait encore comme une utopie pour les compétitions de programmation. Pour preuve, cette remarque d’un compétiteur sérieux (à 34’40 ») :
La phrase qui nous intéresse : « En pratique, sur un challenge comme ça, je n’ai jamais vu quelqu’un gagner grâce au machine learning ».
On peut noter que le niveau en compétition de programmation a bien progressé sur ce genre de compétition. Du fait de l’utilisation croissante d’algorithmes qui ont fait leur preuves (Minimax, algorithme génétique, recuit simulé, algorithme de recherche en faisceau, Monte Carlo Tree Search et ses nombreuses variantes, etc.) on assiste à des résultats remarquables.
Certains compétiteurs ont réussi à appliquer avec succès le machine learning dès 2019 sur certains problèmes issus de précédentes compétitions. Les résultats étaient variables et dans certains cas très remarquables, battant largement tous les algorithmes mis en œuvre jusqu’à présent.
Lors de la très sérieuse compétition de programmation organisée par CodinGame en ce mois de mai 2021, plusieurs candidats se sont essayés au machine learning. L’un de ces candidats a particulièrement frappé les esprits en réussissant à sortir une solution qui a littéralement écrasé tous les autres participants (près de 7000).
On remarque donc que le machine learning, s’il n’est toujours pas une solution magique instantanée, engrange toutefois toujours plus de succès. Inévitablement, on va assister à une accélération de son utilisation, tout comme on a vu se répandre l’usage de certains algorithmes performants il y a quelques années.
À plusieurs reprises il m’est arrivé d’atteindre des limites peu connues en utilisant le .NET framework.
Récemment encore, en travaillant sur un problème d’optimisation, j’avais mis en place un algorithme de type BFS afin de chercher la solution la plus efficace à un problème. Du fait de l’explosion combinatoire du problème, mon pauvre programme pourtant en mode 64 bits tombait sur une exception de type « mémoire insuffisante« . Le souci est qu’au moment de l’exception, mon programme consommait à peine 10 Go de mémoire et qu’il me restait 16 Go de libre sur ma machine de 32 Go. Rageant.
Comme je travaille de plus en plus avec le .NET core, aussi bien sous Windows que sous Linux, j’ai voulu tester mon programme en le basculant pour .NET core 5 et voir s’il y avait des différences en terme de performance et d’occupation mémoire. Je n’ai pas spécialement noté de différence sur ces 2 aspects là, mais j’ai découvert une différence majeure : plus d’exception. J’ai même pu laisser filer mon programme au-delà de la mémoire disponible (process testé à 44 Go avec 32 Go de RAM), Windows restant imperturbable.
En conclusion, tout nouveau développement en C# devrait cibler sans hésiter .NET Core au lieu de .NET framework, vu l’ensemble des avantages (notamment l’aspect multi-plateforme) et l’absence de perte.
Le terme que je veux mettre en avant est éphémère.
On ne s’en rend pas compte parce que l’informatique est ancrée dans le quotidien et que les améliorations et nouveautés s’enchaînent dans ce monde. Mais l’obsolescence est de plus en plus présente dans de nombreux domaines de l’informatique.
Quelques exemples pour étayer cette remarque.
Flash a disparu début 2021 après une longue période pendant laquelle ce composant était indispensable à nombre de sites internet et même des logiciels. Cette disparition entraîne de fait nombre de pages internet à ne plus fonctionner (sauf si évolution), nombre de logiciels à ne plus pouvoir fonctionner (sans alternative), et nombre de vidéos à ne plus pouvoir être lues.
Les langages de programmation évoluent de nos jour à un rythme inquiétant (et sans compter les nouveaux langages qui fleurissent chaque année). Ainsi, nombre de langages se sont lancés dans une course folle à enchaîner soit des nouveautés non négligeables sur un rythme semestriel, soit des nouveautés significatives sur un rythme triennal. En conséquence, relire un code source écrit il y a une dizaine d’année peut faire mal aux yeux. Également, le travail d’actualisation des connaissances pour les développeurs devient de plus en plus compliqué (sans compter les nouveaux frameworks qui apparaissent ou qui évoluent, ainsi que les nouveaux outils et les nouvelles pratiques). Et là encore, arriver à recompiler un ancien code source peut s’avérer difficile voire impossible de nos jours tant les évolutions sont rapides et brutales. On peut penser au langage python 2 qui n’a plus de support depuis 2020, certaines anciennes version de Swift.
On peut aussi penser aux célèbres applets java qui étaient tant présentes au début du web : elles vont être définitivement retirées de la version 17 de java (cf. https://openjdk.java.net/jeps/398).
Les logiciels suivent le même chemin : certains disparaissent (Outlook Express, Internet Explorer, etc.). On peut aussi évoquer une liste impressionnante de projets abandonnés par Google : https://killedbygoogle.com.
Toutes ces évolutions conduisent inévitablement à devoir migrer sans cesse les données, changer les logiciels et les habitudes. Et même parfois, ça conduit à des pertes de données/fonctionnalités définitives. Une forme d’obsolescence à marche forcée. Et pourtant cette tendance ne devrait pas s’inverser, bien au contraire.
Début 2016, l’hypothèse d’une neuvième planète avait fait grand bruit, notamment dans les médias. Cette planète serait à la fois très grande (5 à 10 fois la masse de la Terre) et très éloignée (quelques centaines d’unités astronomiques).
Cinq ans plus tard, non seulement sa découverte n’est toujours pas d’actualité, mais un nouveau papier publié sur arxiv (No Evidence for Orbital Clustering in the Extreme Trans-Neptunian Objects) fait vaciller les hypothèses de l’existence de cette supposée planète. Notamment l’étude pointe du doigt des biais de sélection.
Étonnamment, peu de médias ont relayé cette information. Hélas, beaucoup de médias s’attachent à favoriser les informations sensationnelles, bien plus génératrices de clics que de simples informations factuelles.
Scénario : nous sommes en 2020, et maven affiche quantité de warnings (suivis de quelques erreurs) du genre :
[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-compiler-plugin:2.4: Plugin org.apache.maven.plugins:maven-compiler-plugin:2.4 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-compiler-plugin:jar:2.4
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.5/maven-resources-plugin-2.5.pom
Nous sommes donc en 2020, et l’usage du https devient la norme partout. Dans ce cas, il y a essentiellement 2 solutions :
Fièrement propulsé par WordPress & Thème par Anders Norén