Lecabanon.Org
Accueil > Liens Web > Actu > DLFP - Dépêches

DLFP - Dépêches

LinuxFr.org

http://linuxfr.org/

Articles

  • HappySchool, logiciel de gestion scolaire

    8 décembre, par Manunu, Ysabeau, Davy Defaud, yPhil, Pierre Jarillon, Xavier Teyssier

    HappySchool est une application Web de gestion à destination des écoles primaires et secondaires. Fruit d’une expérience de terrain, elle se veut simple d’utilisation et modulable afin de s’adapter aux particularités des établissements scolaires. Happy School est un logiciel libre, est similaire à RosarioSIS ou encore ZeusEdu. HappySchool s’appuie sur une série de projets libres dont les cadriciels Django et Vue.js.

    Sommaire

    Applications

    HappySchool est constitué de plusieurs applications indépendantes qui peuvent être activées et désactivées selon les besoins :

    • un annuaire des élèves et des enseignants qui permet de trouver une personne par nom ou classe et d’afficher des informations la concernant, de générer un trombinoscope par classe, ou encore d’avoir un rapide aperçu des données aux autres applications ;
    • un dossier des élèves qui permet d’assurer un suivi des élèves, notamment des informations personnelles et des sanctions — cette application permet également de gérer le suivi des sanctions et de leurs demandes, d’organiser des conseils disciplinaires et de vérifier la présence des élèves lors des retenues ;
    • un suivi des absences des élèves qui fonctionne sur tablette hors connexion — deux interfaces ont été développées, une pour les éducateurs et une pour les enseignants ;
    • une gestion des entrées et sorties de l’infirmerie avec une notification automatique par courriel aux différents responsables de l’école ;
    • une gestion des appels au travers de notifications, par exemple en notifiant un éducateur qu’un élève sera absent pour cause de maladie suite à l’appel d’un parent ;
    • un suivi des absences des professeurs pour la gestion administrative ;
    • un suivi des changements d’horaire des enseignants afin d’avoir une connaissance centralisée d’où se trouvent les élèves — l’application prévoit l’affichage des changements d’horaires sur grand écran.

    L’application avec l’annuaire des élèves et des enseignants est au cœur de Happyschool. C’est la seule partie obligatoire de l’application. Les autres sont modulables en fonction des besoins des utilisateurs.

    Une fiche d’élève avec son identité, les moyens de contact, les informations médicales et d’autres plus générales ou personnelles :
    Une fiche d’élève

    Le dossier des élèves, pour leur suivi :
    Dossier des élèves

    Le relevé des présences, ces dernières sont notées par demi‑journée :
    Prise des présences

    Gestion des données sensibles

    Afin d’avoir un meilleur contrôle de la gestion des données sensibles, il est possible de fonctionner avec deux instances indépendantes, une avec toutes les données sensibles et une autre avec un minimum d’informations confidentielles (nom des personnes, prénom, classe). La première instance pilote la seconde avec une API. En pratique, cela peut être un serveur sur le réseau local de l’école inaccessible depuis l’extérieur et un autre, dénudé, externalisé (VPS, serveur dédié, etc.).

    Historique

    Je travaille depuis cinq ans dans une école belge primaire et secondaire (6 à 12 ans et 12 à 18 ans, respectivement) de la Fédération Wallonie‐Bruxelles. À mon arrivée, l’école utilisait déjà des applications faites sur mesure à base de fichiers Excel, afin d’assurer des traces écrites, et une communication par courriels entre les différents responsables. Malgré les qualités de la solution, certains aspects restaient compliqués à gérer, en particulier l’utilisation mono‑utilisateur d’un fichier Excel. Après un certain temps, je me suis attelé à la tâche de réécrire ses applications en une application Web à l’aide de Django et Vue.js. Cela a permis d’introduire de nouvelles fonctionnalités, comme une gestion fine des permissions accordées aux utilisateurs mais aussi de faciliter la maintenance du logiciel. Dès le début, le but était de développer un logiciel libre utilisable et surtout adaptable aux particularités de différentes écoles. Pour le moment, il est tout de même assez spécifique au fonctionnement des deux écoles dans lesquelles je travaille. HappySchool est encore en développement, mais j’espère qu’il pourra déjà profiter à d’autres.

    En particulier, le logiciel est pour le moment pensé dans une optique d’importation des données des élèves et professeurs plutôt qu’un ajout manuel de celles‑ci. En effet, les écoles où je travaille (enseignement libre francophone) doivent utiliser un logiciel officiel où toutes les informations de l’école se trouvent. Il m’a donc semblé plus simple de créer des scripts de synchronisation et d’importation (fichier CSV). Mais j’espère pouvoir faire évoluer ce logiciel en fonction des besoins et demandes d’autres utilisateurs. Par exemple, il est possible de s’authentifier avec un compte Google, Microsoft ou avec son propre serveur LDAP en plus du système interne.

    Une autre limitation vient également de la définition d’une classe. En effet, celle‑ci doit pour le moment être définie par un chiffre (l’année) et une série de lettres. J’imagine qu’il peut être intéressant de lever cette contrainte pour d’autres systèmes scolaires.

    Si vous êtes intéressé, une instance de test est disponible à l’adresse suivante : https://test.happyschool.be. Vous pouvez vous y connecter avec le couple d’identifiant « directeur/happyschool ».

    Projets en cours

    Deux applications sont en cours de développement et de test, dont :

    • une application de retard qui permet de prévenir les éducateurs et/ou les parents par courriel, d’imprimer un ticket de retard et de créer automatiquement une sanction ou une alerte après un certain nombre de retards ;
    • un suivi individuel d’apprentissage (PIA, pour Projet Intégré d’Apprentisssage), par la mise en place d’une série d’aménagements et d’objectifs — il s’adresse particulièrement aux élèves en grande difficulté et/ou avec des troubles d’apprentissage (dyscalculie, etc.).

    Par la suite, il est également prévu de pouvoir introduire les horaires des élèves et enseignants à partir d’une exportation de programme comme EDT ou Untis.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  • Redox OS, le prochain système d’exploitation à conquérir le monde ?

    8 décembre, par tisaac, Xavier Teyssier, Davy Defaud, palm123, Pierre Jarillon

    Le 20 avril 2015, Jeremy Soller publiait la première version de Redox OS sur GitHub. Ce système d’exploitation est depuis lors en développement actif, avec des apports de plus de soixante‑dix développeurs. Après cinq ans de développement, on en est à la version 0.5.0.

    Voici un courte présentation de Redox OS, de son état d’avancement, et quelques réflexions sur la possibilité de succès de ce projet.

    Sommaire

    Le projet

    En bref

    En très court, c’est un système d’exploitation :

    1. écrit en RUST ;
    2. avec une architecture de type micronoyau ;
    3. qui s’inscrit dans la lignée des systèmes d’exploitation à la UNIX et qui assure une certaine compatibilité avec les normes POSIX ;
    4. qui passe de la logique « tout est fichier » à « tout est lien URL » ;
    5. publié sous licence de type MIT X11.

    L’ambition est de créer un système d’exploitation complet, totalement fonctionnel et axé sur la sécurité dans un esprit open source. L’un des objectifs est de pouvoir être une alternative réelle à GNU/Linux, ainsi que d’être suffisamment compatible pour pouvoir exécuter la plupart des programmes tournant sur GNU/Linux avec un minimum de modifications.

    On ne sera pas surpris que l’argument de la sécurité soit mis en avant pour justifier le choix de Rust.

    Les projets annexes

    Comme l’objectif de Redox OS est d’être un système d’exploitation complet, en plus du développement du noyau, il englobe une série de projets annexes, notamment :

    • TFS : un système de fichiers inspiré de ZFS ;
    • Ion : le shell de Redox ;
    • Orbital : le serveur d’affichage de Redox ;
    • OrbTK : une boîte à outils de widgets ;
    • pkgutils : la bibliothèque de gestion des paquets de Redox et son interface en ligne de commande ;
    • Sodium : un éditeur de type Vi ;
    • ralloc : un allocateur de mémoire ;
    • games-for-redox : une collection de mini‑jeux pour Redox (similaires aux jeux BSD).

    Ce qui occupe actuellement Jeremy Soller est pkgar. Pkgar est un format de fichier, une bibliothèque et un exécutable en ligne de commande pour créer et extraire des collections de fichiers sécurisés par chiffrement, principalement pour une utilisation dans la gestion des paquets sur Redox OS.

    Un projet vivant ?

    Le développement de Redox OS est actif. Depuis le début, une septantaine de personnes a contribué au code mais, assurément, Jeremy Soller reste très largement le contributeur principal.

    Si l’on regarde les publications des différentes versions, on observe des sorties assez régulières même si le rythme a peut‑être tendance à ralentir avec le temps. Voici une sélection de quelques publications du projet :

    • première publication d’image ISO : 0.0.3, le 1er décembre 2016 ;
    • rafraîchissement du visuel : 0.1.0, le 24 février 2017 ;
    • la publication des deux ans : 0.2.0, le 23 avril 2017 ;
    • le retour de Redox : 0.3.0, le 13 juillet 2017 ;
    • la dernière de la série 0.3.x : 0.3.5, le 21 mars 2018 ;
    • la série ignorée : il ne semble pas y avoir de réelle publication dans la série 0.4.x ;
    • la dernière en date : 0.5.0, le 24 mars 2019.

    La dernière publication remonte donc à plus d’un an mais cela n’empêche pas Jeremy Soller et quelques autres de régulièrement donner des nouvelles. On peut également suivre le projet sur Twitter, sur Discourse ou encore reddit.

    Mentionnons également que depuis 2018, Redox organise ses propres Summer of Code qui permettent à quelques étudiants de contribuer au développement du système d’exploitation dans le cadre de stages d’étudiant. La page News du site de Redox recueille d’ailleurs chaque année les comptes‑rendus hebdomadaires de l’avancement ce travail.

    Redox OS est donc bien un projet vivant et semble être le seul projet de système d’exploitation écrit en Rust réellement actif, à l’exception éventuelle de quelques projets à visée pédagogique.

    Un système d’exploitation qui fonctionne ?

    Clairement, la réponse est non si vous cherchez un système d’exploitation alternatif à GNU/Linux. Aujourd’hui, Redox OS n’est pas du tout à un stade où vous pouvez facilement l’installer sur votre PC. Il est assez simple de tester Redox OS, soit en mode « média autonome », soit à l’aide d’une machine virtuelle. Mais très vite, on est confronté au manque de pilotes basiques.

    Quand je l’ai testé sur un portable Dell Inspiron 17R N7110, cela fonctionnait plutôt correctement. Le clavier, le pavé tactile et l’écran fonctionnaient correctement. Malheureusement, impossible de me connecter à Internet, vu que les seuls contrôleurs Ethernet gérés pour le moment par Redox OS sont les RTL8168d et e1000d, qui ne sont, ni l’un ni l’autre, le matériel qui équipe mon Dell. Forcément, cela limite un peu les possibilités.

    Au stade actuel, il y a un micronoyau fonctionnel avec quelques éléments de base supplémentaires. Redox OS dispose d’un environnement graphique avec un gestionnaire de fenêtres et quelques applications basiques. Il est possible de naviguer sur le Web grâce à son navigateur intégré (Netsurf). Vous disposez également d’un éditeur de texte, d’un gestionnaire de fichiers, d’un terminal et d’une visionneuse de documents. Et c’est pratiquement tout. Dans cette liste, il manque encore les jeux ; mais contrairement à certains et à d’autres, je n’ai pas su les faire fonctionner.

    De son côté, le créateur de Redox OS a pu l’installer de manière permanente sur un System76 Galago Pro (galp3-c) en novembre de l’année dernière. Jeremy Soller semble assez satisfait de la manière dont le système fonctionne sur cet appareil.
    Pour vous faire une idée du fonctionnement de Redox OS, vous pouvez regarder cette courte vidéo, ou cette vidéo un peu plus longue (une trentaine de minutes) qui présente de manière un peu plus large les capacités et limites de Redox OS.

    À ce stade, le plus ennuyeux est peut‑être que malgré de nombreux efforts, Redox OS n’a pas encore atteint le stade où il peut se compiler à partir de lui‑même (self‑hosting). Pour l’utilisateur lambda tel que moi, cela ne signifie pas grand‑chose, mais pour pouvoir développer plus efficacement Redox OS, cela semble être une étape appréciable.

    Doit‑on s’inquiéter qu’après cinq ans, cette capacité de self‑hosting n’est pas encore atteinte ? Sans doute pas. Par exemple, cela a pris huit ans à Haiku pour atteindre ce stade de maturité.

    Pourquoi cela ne marchera pas

    Micronoyau vs noyau monolithique, débat éternel avec toujours le même vainqueur

    Dès le début de Linux, il y eut un débat sur la pertinence de l’architecture du noyau qui était monolithique. Ce débat ayant principalement lieu entre Andrew S. Tanenbaum et Linus Torvalds. D’un point de vue théorique, l’architecture avec un micronoyau offre une meilleure sécurité (et peut‑être une meilleure portabilité) au détriment de la performance. Au niveau de la performance, les plus optimistes avancent que la perte de rapidité du micronoyau par rapport au noyau monolithique peut être limitée à 6 %. Ce débat revient de temps à autre, mais force est de constater qu’aucun système d’exploitation basé sur un micronoyau n’a jamais percé. Pourquoi en serait‑il autrement aujourd’hui ?

    Une dynamique qui ne décolle pas

    Quand l’on regarde le développement de Linux, on se rend compte que bien que les premières années furent assez confidentielles aux yeux du grand public, il y a eu rapidement un grand nombre de personnes qui a travaillé sur ou autour de Linux.

    Un des éléments explicatifs est que Linux répondait à de réels besoins. Avant tout au niveau personnel, Linus avait un vrai problème avec un ordinateur puissant (pour l’époque) mais pas vraiment de système d’exploitation exploitant toute cette puissance. Au niveau collectif, il y avait sans doute une communauté qui cherchait à développer un système d’exploitation libre. Alors que Hurd ne progressait pas réellement et que BSD était empêtré dans des questions de licence, Linux apportait une bonne part de ce qui manquait à cette communauté. Ce n’était sans doute pas le but de Linus au départ mais son travail répondait à un besoin qui dépassait largement sa personne. Concernant Redox, on ne voit pas le réel problème individuel que l’on essaie de résoudre, pas plus que de besoin plus large qu’il permettrait de satisfaire.

    Argument délicat à utiliser dans le contexte du Libre, mais il y a une forme de balkanisation des développements de systèmes d’exploitation sur base de micronoyaux. Redox OS y contribue d’ailleurs, vu que ce projet a été lancé alors que d’autres systèmes d’exploitation avec une architecture de micronoyau existaient ou étaient en développement. Ceux qui sont intéressés par les systèmes d’exploitation construits avec un micronoyau visiteront avec intérêt microkernel.info. La diversité est évidemment une force et une richesse, mais elle est aussi une faiblesse quand les ressources sont limitées.

    Vu de loin, il n’est pas tellement évident qu’il existe une feuille de route claire pour le développement de Redox OS. Une feuille de route explicite n’est sans doute pas totalement nécessaire, mais cela peut aider à créer une dynamique et une communauté alignée sur des objectifs cohérents.

    Pourquoi cela pourrait marcher

    Rust, le langage à utiliser

    Le choix de Rust est sans doute très pertinent pour le développement d’un système d’exploitation. Ce n’est pas pour rien que même Apple et Microsoft se mettent à utiliser de plus en plus Rust. Sur la question de Rust comme langage pour écrire un système d’exploitation, je vous recommande les vidéos de Bryan Cantrill sur le sujet, qui sont plutôt intéressantes. Par exemple, « Is It Time to Rewrite the Operating System i  Rust? » ou « Rust and Other Interesting Things ». Pour un avis moins enthousiasmant sur Rust, il y a une autre vidéo, mais j’ai quelques doutes sur la qualité de la traduction proposée en sous‑titre.

    L’air du temps

    Même si l’architecture avec un micronoyau n’a pas percé sur les ordinateurs de bureau, il y a quand même des évolutions dans le monde de la programmation qui vont dans un sens similaire. Par exemple, le développement des architectures en micro‑service dans le monde du Web est, même si comparaison n’est pas raison, dans un même esprit que les micronoyaux. On pourrait penser que c’est le signe d’un changement de l’air du temps qui pourrait être plus favorable aux micronoyaux.

    De manière plus directement liée au monde des ordinateur de bureau, les flatpacks et autres concurrents avec le développement de bacs à sables visent, entre autres, à améliorer la sécurité en contrôlant de manière plus fine les accès des différents programmes aux différentes ressources de l’ordinateur. C’est justement une des forces des micronoyaux que de pouvoir offrir un contrôle fin de ce à quoi accède chaque logiciel. Pourquoi, pour des questions de sécurité, s’amuser à utiliser flatpack et consorts sur un noyau monolithique alors que, par conception, une architecture avec micronoyau est mieux à même d’atteindre cet objectif ?

    La théorie du ketchup

    Concernant la dynamique qui ne prendrait pas son envol, c’est sans doute à relativiser. De nombreux projets très valables sont développés par peu de personnes. Par ailleurs, n’est‑il pas normal que poser les bases d’un projet prenne du temps et que, aux yeux d’un néophyte, cela donne l’impression de ne pas beaucoup avancer ? Tout comme le ketchup met du temps avant de sortir de la bouteille et puis vient tout d’un coup, il est possible que Redox OS semble peu évoluer pendant une longue période et puis, une fois les fondations bien construites, puisse voir son développement largement accélérer à partir d’un moment. C’est visiblement aussi un peu l’espoir du développeur principal de Redox OS, qu’une fois que Redox OS sera self‑hosted, cela débloque les contributions possibles d’autres développeurs.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  • Pharo : quoi de neuf ?

    8 décembre, par tisaac, Davy Defaud, stepharo, bobble bubble, palm123, Benoît Sibaud, BAud, orfenor

    Au début de Pharo, il a eu droit à une série de dépêches sur LinuxFr.org. Mais depuis 2016 et la dépêche sur Pharo 5.0, il faut bien reconnaître qu’il n’y a pas vraiment eu de nouvelles concernant Pharo sur LinuxFr.org. Ayant acheté le numéro de novembre‐décembre de Programmez, j’y ai lu un dossier intéressant sur Smalltalk qui présente Pharo comme une implémentation moderne et libre de Smalltalk. Cela m’a motivé à me renseigner un peu sur Pharo et, finalement, je me suis dit que certains seraient peut‑être intéressés de voir ce qu’est devenu Pharo depuis la dernière dépêche de 2016.

    Sommaire

    Pharo, c’est quoi

    La pub

    Selon la page d’accueil de son site Internet (traduction par mes soins) :

    Pharo est un langage de programmation orientée objet pur et un environnement puissant, axé sur la simplicité et le retour d’information immédiat (pensez à un EDI et un système d’exploitation réunis en une même suite logicielle).

    Sur la même page, on vous promet :

    • un langage simple et puissant : pas de constructeurs, pas de déclaration de types, pas d’interfaces, pas de types primitifs ; pourtant, un langage puissant et élégant avec une syntaxe complète qui tient sur une carte postale ! Pharo, ce sont des objets et des messages ; et c’est tout ;
    • un environnement vivant et immersif : un retour d’information immédiat à tout moment de votre développement — développement, test, débogage — ; même dans les environnements de production, vous ne serez plus jamais bloqué dans la compilation et le déploiement des étapes !
    • une expérience de débogage étonnante : l’environnement Pharo comprend un débogueur comme vous n’en avez jamais vu auparavant. Il vous permet de parcourir le code, de relancer l’exécution des méthodes, de créer des méthodes à la volée, et bien plus encore !
    • Pharo est à vous : Pharo est le fruit d’une incroyable communauté, avec plus de cent contributeurs pour la dernière révision de la plate‑forme et des centaines de personnes qui contribuent constamment à des cadriciels et des bibliothèques ;
    • entièrement open source : la pile complète de Pharo est publiée sous licence MIT.

    Un peu d’histoire

    La généalogie de Pharo remonte à Smalltalk et particulièrement la version Smalltalk-72 qui a été créée par Alan Kay pour relever le défi de spécifier un langage de programmation puissant en moins d’une page. Les fondamentaux sont là, mais la maturité viendra vraiment avec la version Smalltalk-80.

    Ces développements se déroulent dans le cadre du Xerox PARC qui verra dans les années 70 passer une concentration hallucinante de génies de l’informatique qui poseront les bases de nombreux éléments de l’informatique moderne. Xerox s’est montré capable de monter un centre de recherche particulièrement fécond mais sera moins inspiré concernant la valorisation de ce travail.

    Nous éludons une partie de l’histoire pour nous retrouver en 1995 chez Apple où Alan Kay et Dan Ingalls (un autre ancien du PARC de Xerox) créent Squeak, qui est une nouvelle implémentation de Smalltalk hautement portable et dont la machine virtuelle est elle‑même écrite en Smalltalk. Le focus de Squeak est assez orienté sur les applications ludiques et multimédia.

    Squeak n’est pas la seule suite qui a été donnée à Smalltalk, on peut par exemple citer :

    Pharo, quant à lui, est un divergence de Squeak qui était justifiée de la manière suivante dans la dépêche annonçant le lancement de Pharo :

    Le projet Pharo est un projet de Smalltalk open source. L’objectif de Pharo est de pousser Squeak au niveau supérieur.
    Pharo est en effet un fork de Squeak. Les forks apparaissent pour résoudre des problèmes difficiles à résoudre dans le projet père. En effet, Squeak est otage de plusieurs sous‑communautés (très amicales au demeurant), ce qui ne conduit à aucune évolution utile pour ces sous‑communautés, et cela résulte finalement en une myriade de forks (Etoys, OpenCroquet, Sophie, Squeak, Qwaq…), chacun spécifique à une communauté/projet, mais insuffisamment généraliste pour une portée plus large.

    Dans un commentaire de l’annonce de la version 1.2, ceci était exprimé de la manière suivante :

    Pharo est un fork de Squeak, suite à une divergence d’intérêts entre des développeurs qui voulaient continuer à développer une plate‑forme multimédia un peu fourre‑tout (Squeak) et ceux qui voulaient que se développe un Smalltalk avec de meilleures pratiques logicielles (tests unitaires, découplage des modèles et de l’interface utilisateur, intégration continue des modifications…). Pharo vise une cible plus professionnelle avec notamment le développement Web avec Seaside.

    Pharo = Smalltalk ?

    Alors qu’au départ, Pharo a souvent été présenté comme une implémentation de Smalltalk, la réalité est un peu plus complexe que cela. Pharo est désormais plus présenté comme un langage (fortement) inspiré par Smalltalk comme l’exprimait Damien Cassou dans les commentaires de la dépêche annonçant Pharo 3.0 :

    Effectivement, on peut voir Pharo comme une implémentation du standard Smalltalk avec son environnement de développement et ses bibliothèques de code. Cependant, nous avons décidé d’arrêter de dire ça car le standard Smalltalk n’évolue plus alors qu’on améliore Pharo en permanence.
    Ça signifie qu’on s’autorise à ne pas être compatible avec le standard. Par exemple, Pharo possède la notion de trait (un mécanisme d’héritage multiple de méthodes) alors que le standard ne le prévoit pas. De même, dans la prochaine version de Pharo, on n’utilisera plus de chaînes de caractères pour déclarer les variables d’instances car on utilisera à la place les Slots (un mécanisme beaucoup plus poussé qui permet d’avoir différents types de variables d’instances avec des comportements différents). Là encore, on s’éloigne du standard Smalltalk. Enfin, le standard définit une API qu’on s’autorise à remplacer petit à petit par une autre plus moderne.
    Pour toutes ces raisons, on parle maintenant de « Smalltalk-inspired » et plus d’implémentation de Smalltalk.

    La syntaxe de Pharo

    La syntaxe de Pharo est très proche de celle de Smalltalk et continue à tenir sur une carte postale. Quand on dit que la syntaxe de Pharo tient sur une carte postale, il faut l’entendre comme le fait que l’on peut illustrer toutes les caractéristiques de cette syntaxe sur un code qui tient sur une carte postale.

    La syntaxe de Pharo sur une carte postale, par Xkriva11 — Own work, CC BY‑SA 4.0, https://commons.wikimedia.org/w/index.php?curid=69598356

    Pour avoir une explication un tout petit peu plus détaillée, on pourra se référer à cette Cheat Sheet qui tient sur deux pages.

    Une des caractéristiques les plus marquantes de Pharo est son caractère très pur de langage orienté objet. Pratiquement tout est objet. Entre autres, il y a très peu de mots réservés. Notamment, on retrouve très peu d’instructions de contrôle intégrées au langage telles que if … then … (else …). Ce genre de contrôle sera implémenté en utilisant des objets et en leur adressant des messages. Dans le cas d’un if … then …, on aura :

    Condition
      ifTrue: quelque chose
      ifFalse: autre chose

    Condition est un objet de type booléen à qui on envoie deux messages (ifTrue et ifFalse, avec à chaque fois un bloc comme argument).

    Projets utilisant Pharo

    Un langage avec des caractéristiques plaisantes, c’est sympa. Mais c’est encore plus intéressant quand l’on peut voir ce que cela donne dans des cas concrets. Ici, une sélection très loin d’être exhaustive de projets réalisés avec Pharo. Les plus curieux trouveront une liste plus longue sur le site de Pharo. Liste qui malheureusement n’est pas totalement à jour dans la mesure où elle renseigne aussi des projets qui ne semblent plus être actifs aujourd’hui.

    Dr. Geo

    Sans doute le projet le plus connu des moules de LinuxFr.org, vu que ce projet y a eu droit à une série de dépêches.

    Illustration Dr. Geo

    Dr. Geo est un logiciel de géométrie interactive euclidienne du plan, pour une utilisation à l’école secondaire et primaire. Il permet d’organiser des activités pédagogiques dans l’enseignement de la géométrie, voire d’autres domaines liés des mathématiques. Il propose également une approche de la géométrie dynamique par la programmation, soit par l’utilisation de script(s) intégré(s) à une figure, soit par une description purement programmatique d’une construction géométrique.

    Honey Ginger

    Honey Ginger est un simulateur hydrodynamique à particules lisses (smoothed‐particle hydrodynamics simulator) avec une visualisation et une interactivité riches. Je ne sais pas à quoi cela peut réellement servir et comment on peut l’intégrer à d’autres choses pour arriver à quelque chose d’utile, mais je trouve les effets dans la vidéo de démo assez amusants.

    Illustration de Honey Ginger

    Monde bancaire

    Je trouve intéressant d’observer que Pharo est aussi utilisé dans des mondes « sérieux » et pas seulement chez des geeks, des académiques ou des graphistes. Ainsi, Pharo a été utilisé dans des GAB déployés dans les rues de Moscou de 2008 à 2015. Cet usage ayant fini semble‐t‐il suite à la fermeture de la banque pour d’autres raisons (information que je n’ai pas vérifiée). On retrouve des vidéos de ces GAB par ici. Autre banque à avoir eu recours à Pharo : CSOB. CSOB est une des trois plus grandes banques en République tchèque et est une filiale à 100 % de la banque belge KBC. Sinon, en Argentine, des banques utilisent Pharo pour la gestion des stocks.

    Phratch

    Bien que je craigne que le projet soit abandonné depuis lors, j’ai envie de mentionner ce projet de réimplémentation de Scratch en Pharo. Premièrement, parce que je suis un peu inquiet de l’évolution de Scratch qui me semble avec la version 3 aller vers une dépendance à Internet, alors que les versions précédentes pouvaient fonctionner sur un ordinateur en totale autonomie. Deuxièmement, parce que c’est quelque peu particulier de voir un projet être implémenté en Pharo alors que le projet initial était écrit en Smalltalk (les versions suivantes sont passées en ActionScript puis en JavaScript). Comme un retour aux sources. Pour ceux qui aiment ce genre de programme et qui sont prêts à se passer dans le nom de la référence explicite à Scratch, il y a aussi NovaStelo qui revisite le genre.

    Quoi de neuf ?

    Iceberg

    Le gestionnaire de versions historique de Pharo était Monticello. Depuis Pharo 6.0, il a été remplacé par Iceberg qui fait le pont avec Git.

    L’esprit de Monticello était très similaire à Git en tant que système de gestion de versions distribué. Le système Monticello était taillé sur mesure pour les systèmes Smalltalk. Une bibliothèque cliente et un serveur ou forge Monticello sont nécessaires pour pouvoir l’utiliser.

    Les raisons qui ont poussé Pharo à aller au‑delà de Monticello pour favoriser une compatibilité avec Git sont :

    1. le recours à Git permet à la communauté Pharo d’employer des forges standard déjà maintenues permettant de ne pas devoir y consacrer des ressources qui peuvent être plus utilement employées ailleurs dans le cadre de Pharo ;
    2. Git est devenu de facto le standard comme gestionnaire de versions, imposer d’en utiliser un autre tel que Monticello crée une barrière à l’entrée supplémentaire dans la découverte de Pharo ; faire usage de Git permet ainsi de réduire le coût d’entrée pour un informaticien découvrant Pharo ;
    3. certaines forges telles que GitHub ou GitLab offrent une belle visibilité pour les projets qu’elles hébergent ; ainsi, l’intégration avec Git permet aussi aux développeurs en Pharo de bénéficier de cette visibilité.

    Iceberg permet naturellement les opérations classiques d’un dépôt Git (création, clonage, gestion des branches, commits, fusion de branches…). La particularité d’Iceberg c’est qu’il essaie d’articuler le monde des fichiers source (partie Git) avec la représentation objet omniprésente dans le monde Smalltalk. Par exemple, les algorithmes de diff ne mettent pas seulement en lumière une à une les lignes de codes impactées (approche Git) mais mettront en évidence les méthodes modifiées ainsi que leurs classes.

    bootstrapping

    Depuis Pharo 7.0, Pharo peut être « bootstrappé » à partir d’une version antérieure de Pharo. Dans ce contexte, « boostrapper » signifie compiler un langage en utilisant un compilateur écrit dans ce même langage. En d’autres mots, l’image d’une nouvelle version de Pharo est générée par une application Pharo qui s’exécute dans une version antérieure de Pharo.

    Au‑delà de l’élégance de la démarche de créer la version suivante à partir de la précédente, cela permet aussi de créer des noyaux de Pharo réduits. Cela peut être intéressant soit dans une perspective de sécurité (on réduit la surface d’attaque), soit dans une perspective d’informatique embarquée (on réduit l’usage de la mémoire pour Pharo). Il est ainsi possible d’obtenir à l’aide de ce bootstrap des noyaux de l’ordre de 200 Kio.

    Calypso

    Calypso est depuis Pharo 7.0 le nouveau navigateur système de Pharo (system browser). Il remplace Nautilus, apporte des améliorations pour le travail à distance et des capacités de navigation plus avancées.

    Gestion de différents états pour les traits

    Avec Pharo comme pour Smalltalk, l’héritage est simple. Une classe n’hérite que d’une seule autre. En revanche, pour quand même pouvoir gérer une forme d’héritage multiple, Pharo implémente la notion de traits. Cela permet de partager des comportements entre classes au‑delà de la hiérarchie des classes. Depuis Pharo 7.0, les stateful traits sont implémentés.

    64 bits

    Dans ses premières versions, Pharo était une version 32 bits. Depuis Pharo 6.0, une version 64 bits est disponible pour GNU/Linux et macOS. C’est également le cas pour Windows depuis Pharo 8.0.

    Et pour la suite ?

    La publication de Pharo 9.0 est prévue pour mars 2021. Dans les cartons, une série de nouvelles fonctionnalités :

    • nouvelle syntaxe de classe ;
    • commentaire en Microdown (une sorte de Markdown) ;
    • des nouveaux outils ;
    • nouveau cadriciel graphique (avec possibilités de rendu GTK) ;
    • nouveau mécanisme de complétion automatique ;
    • optimisation du compilateur ;
    • nouvelles machines virtuelles sur ARM 64 bits ;
    • nouveau FFI ;
    • ses tonnes de corrections et tests…

    Ressources

    Pharo n’est clairement pas un projet qui se cache ou qui est difficile d’accès sur Internet. Il y a pas mal de ressources qui permettent de le découvrir même pour de parfaits newbies. On retrouvera pas mal d’informations sur le site officiel de Pharo.

    MOOC

    Mettons en exergue la possibilité de suivre un MOOC sur www.fun-mooc.fr. C’est la première version du MOOC remis à jour, mais il se base sur le MOOC précédent qui a connu au minimum quatre sessions. Plutôt orienté pour des personnes ayant une expérience de la programmation, il devrait cependant être accessible à toute personne motivée. Pour contenter tout le monde, le MOOC est constitué de cinq parcours :

    • débutant complet ;
    • en quête de Web ;
    • rafraîchir votre vision OO ;
    • devenir un expert Pharo ;
    • en quête de magie noire.

    Ces profils sont complémentaires : pour devenir un expert en Pharo, il faut commencer par le profil débutant et compléter avec les autres parcours.

    Des livres

    Une série de livres sont disponibles sur Internet. Tous sont téléchargeables gratuitement. Une partie de ceux‑ci sont disponibles en version imprimée sur www.lulu.com. Je ne les ai pas toutes vérifiées mais il semble que tous les livres sont sous des licences CC. Parfois libre, parfois NC.

    Ce ne sont pas vraiment des livres, mais pour ceux qui veulent aller plus loin, il y a aussi une recension des articles académiques liés à Pharo.

    Mais aussi

    Sur la chaîne YouTube de Pharo, on retrouve une grande variété de vidéos, notamment des archives des Pharo Tech Talks qui sont organisées tous les mois. On retrouve aussi de nombreuses présentations réalisées sur Pharo ou certaines de ses applications. Si vous désirez discuter avec la communauté Pharo sur Discord, c’est par là. Si vous voulez obtenir des nouvelles régulières, ce blog est à conseiller.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  • Les journaux LinuxFr.org les mieux notés de novembre 2020

    7 décembre, par Florent Zara, Davy Defaud

    LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

    Bannière LinuxFr.org

    Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation a priori de lʼéquipe de modération. Ceux‑ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux du mois de novembre passé.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  • Le procès de Julian Assange, commencé le 7 septembre 2020 est toujours en cours

    5 décembre, par dzecniv, BAud, Pierre Jarillon, Davy Defaud, Yves Bourguignon, Ysabeau, Benoît Sibaud, ariasuni, Lawless

    Le lundi 7 septembre ont démarré les audiences en vue de l’extradition de Julian Assange vers les États‑Unis. Visé par dix‑huit charges, il risque cent soixante‑quinze années de prison.

    Il est jugé à Londres pour les États‑Unis. Il n’est ni accusé ni poursuivi en Grande‑Bretagne.

      Sommaire

      L’accusation

      La justice américaine souhaite juger l’ex‑rédacteur en chef de WikiLeaks pour son rôle dans la diffusion de plusieurs séries de documents classés secrets, dont ceux fournis en 2010 par Chelsea Manning, qui détaillaient les exactions de l’armée américaine en Irak et en Afghanistan.

      L’acte d’accusation revient longuement sur les liens entre WikiLeaks et le collectif de hackeurs LulzSec, auteur de plusieurs intrusions à partir l’année 2011. Julian Assange est accusé d’avoir joué un rôle actif dans la diffusion des documents récupérés par LulzSec lors de la récupération illicite des courriels de la société de renseignement privée Stratfor. Il aurait soutenu les hackeurs dans leur opération et leur aurait fourni un logiciel permettant d’effectuer des recherches au sein des courriels récupérés. Il les aurait également incités à mener d’autres opérations. [Mediapart]

      Ces éléments ne signifient pas que Julian Assange ait été directement impliqué dans l’intrusion chez Stratfor, comme le souligne le site Gizmodo qui pointe plusieurs incohérences dans le scénario déroulé par le ministère public. Mais ils restent pourtant inquiétants pour le fondateur de WikiLeaks. En janvier 2015, la justice avait déjà refusé d’accorder le bénéfice du premier amendement au journaliste Barrett Brown, poursuivi pour avoir contribué à la diffusion des courriels de Stratfor. Il avait été condamné à soixante‐trois mois de prison ainsi qu’à verser 900 000 dollars à la société. [Mediapart]

      Le procès actuel

      À la fin du mois de juin dernier, le ministère public américain a dévoilé un nouvel acte d’accusation, ne comportant pas de nouvelles charges, mais incluant de nouveaux éléments tendant à nier sa qualité de journaliste en l’accusant d’avoir favorisé des piratages de documents et sollicité des hackers. [Mediapart]

      L’audience se tient dans des conditions difficiles. Elle ne se déroule pas dans la prison de Belmarsh, trop petite, mais à la Cour criminelle d’Old Bailey1, en visio‐conférence, dont plusieurs organisations de journalistes, dont RSF, se plaignent de la « mauvaise qualité ».

      Le père de Julian Assange a interpellé notre garde des Sceaux, Éric Dupond‐Moretti, lui demandant d’agir pour que « l’État français prenne l’initiative de proposer à Julian Assange l’asile politique ». « Les conditions politiques et juridiques sont semble‑t‑il réunies pour qu’un tel statut puisse bénéficier au prisonnier politique le plus connu au monde actuellement », estiment les signataires. Pourquoi a‑t‑il écrit à lui et pas au président de la République ? Il se trouve que M. Dupond‑Moretti a rejoint l’équipe de défense d’Assange début 2020, et lors d’une conférence de presse organisée à Paris le 20 février, le futur ministre affirmait avoir réclamé un entretien avec Emmanuel Macron pour lui demander d’accueillir le fondateur de WikiLeaks. [Mediapart]

      Son état de santé inquiète

      Le lundi 1ᵉʳ juin, des médecins avaient interdit au fondateur de WikiLeaks d’assister à une audience par visioconférence en raison de « problèmes respiratoires ».

      Lors de l’audience du 14 août, la juge Barrister a fait état d’un rapport psychiatrique montrant une dégradation de la santé mentale de Julian Assange ces dernières semaines. Les avocats du fondateur de WikiLeaks dénoncent depuis de nombreux mois les conditions de détention de leur client. Placé à l’isolement, celui‑ci ne dispose de quasiment aucun document et n’a pas pu s’entretenir avec son équipe juridique depuis plusieurs mois. [Mediapart]

      Il est emprisonné de manière préventive. Est‑ce un prolongement de la détention pour l’affaiblir et l’amener à la mort ?

      Ses futures conditions de détention probables inquiètent aussi

      La dernière semaine des audiences a permis d’avoir un aperçu des futures conditions de détention possibles, d’après plusieurs spécialistes du système carcéral américain qui sont venus témoigner.

      Outre l’ameublement minimal, tout est fait pour que le prisonnier ne croise personne de la journée. Il a droit à deux heures de promenade chaque jour, mais tout seul. Il a le droit d’aller à la bibliothèque, mais quand il n’y a personne d’autre. Il a droit à deux fois quinze minutes d’appels téléphoniques par mois, et il doit prévenir les autorités deux semaines en avance, et ses conversations peuvent être évidemment écoutées. Pas de contact lors des visites. Bref, des conditions aux conséquences psychologiques souvent lourdes, d’autant plus qu’on s’inquiète déjà de la santé mentale actuelle de Julian Assange.

      Et, bien sûr, ces descriptions étaient contestées par l’accusation, se basant sur des rapports fédéraux pour décrire des « prisons modèles », et que rien n’indiquait que Julian Assange irait en isolement.

      Pourquoi défendre Assange ?

      Supposons un journaliste belge spécialisé dans les affaires chinoises et qui publierait des révélations embarrassantes pour la Chine, que celle‑ci estimerait mettre sa sécurité en danger. Ce journaliste, de passage dans un pays sensible aux pressions chinoises, serait interpellé par ledit pays, à la demande des autorités chinoises qui demanderaient son extradition…

      Supposons un journaliste belge spécialisé dans les affaires du Proche‑Orient, qui publierait des informations embarrassantes pour Israël, que Jérusalem estimerait compromettantes pour sa sécurité nationale… De passage dans un pays africain redevable à Israël, ce journaliste serait interpellé à la demande d’Israël qui requerrait son extradition…

      À moins que ce même journaliste belge (ou anglais, ou français ou africain ou indien), ne publie des informations extrêmement embarrassantes pour l’Arabie saoudite, qui saisirait l’occasion de son passage dans un autre état du Golfe ou en Égypte pour demander son arrestation et son extradition…

      Ou encore un journaliste américain qui publierait des informations très confidentielles sur des opérations secrètes criminelles de l’armée indienne et que New Delhi tente de faire arrêter et extrader lors d’un voyage, par exemple, en Thaïlande…

      Voilà ce qui pend au nez de tous les journalistes si Julian Assange — journaliste australien — arrêté en Grande‑Bretagne, est extradé de la Grande‑Bretagne vers les États‑Unis pour avoir — comme responsable de Wikileaks — publié des informations que les États‑Unis estiment dommageables pour leur sécurité. [La Libre]

      Allan Rusbridger, l’ex‑rédacteur en chef du Guardian, estime que les gouvernements du monde entier, y compris les États‑Unis, le Royaume‑Uni et l’Australie, « ont déjà la volonté d’interdire tout type de reportage sur la sécurité nationale », en supprimant l’argument de la défense de l’intérêt public et — ou en imposant leur propre définition de l’intérêt public — en rendant illégal, non seulement de publier des documents, mais même de les recevoir. [La Libre]

      Nous savons déjà comment les États‑Unis utilisent leur droit de façon extraterritoriale dans de nombreux dossiers — ils viennent même de sanctionner le procureur de la Cour pénale internationale qui enquête sur des crimes de guerre commis en Afghanistan, pas seulement par des terroristes islamistes, mais aussi par des troupes américaines… Cette offensive va s’étendre aux médias comme La Libre.

      Fin des auditions

      À présent, la phase d’audition des témoins est terminée. La défense dispose de quatre semaines pour transmettre à la juge ses conclusions générales. L’accusation disposera ensuite de deux semaines pour y répondre. La cour rendra son verdict le 4 janvier 2021 à 11 heures. [Mediapart]

      Sources :

      1. Les Pendus de Londres, une histoire sociale du crime et de la peine capitale par les petits papiers de la Cour criminelle d’Old Bailey. ↩

      Commentaires : voir le flux Atom ouvrir dans le navigateur

    0 | 5 | 10 | 15 | 20 | 25 | 30 | 35 | 40 | ... | 95

    Sites Web

    0 | 20

    SPIP | Plan du site | Suivre la vie du site RSS 2.0 |

    1 visiteurs en ce moment