`smk`, un make sans Makefile

Sommaire Au début était la flemme… D'accord, mais on fait comment? Et à l'usage, ça ressemblerait à quoi smk? Première invocation Deuxième invocation C'est maintenant le tour de passe-passe? Il ne te reste plus qu'a l'essayer Quelques caractéristiques fun Y-a-quoi dans la boite? Et pour faire le ménage? Après la frappe chirurgicale, le build chirurgical Prends toutes les options, c'est le même prix Un peu d'histoire Le plan de développement à court terme Et toi dans tout ça? En savoir plus Au début était la flemme… Ça fait bien longtemps que je me dit que quand j'écris un Makefile, je travaille trop. Si on considère cet exemple : main.o : main.c hello.h gcc -o main.o -c main.c Le kernel sait parfaitement que ma commande gcc -o main.o -c main.c lit main.c, et écrit main.o. Et donc que si main.c change, je dois recompiler, et si main.o n'est pas là, idem. Et pareil pour les dépendances entre commandes. Mieux encore, le kernel sait que gcc a également lu tout un tas d'autre .h ou .c, il connait donc mieux les 'prerequisite' de main.o que moi. Alors, pourquoi devrais-je écrire tout ça dans le Makefile? Évidemment, il existe des solutions qui insèrent automatiquement dans le Makefile les dépendances aux "includes", ou des systèmes qui surveillent les mise à jour du file system pour déclencher ou préparer des lancements de build. Mais je n'ai pas vu de système simple et universel, qui ne demande rien à l'utilisateur si ce n'est les commandes à exécuter (ce qui est un peu le minimum, sauf à ce que l'outil fasse dans la médiumnité pour deviner ce que veut l'utilisateur). Note au passage : si j'ai raté un projet existant de ce type, merci d'avance pour vos références! C'est là que né l'idée séminale du projet smk : et si on essayait de faire un make un peu intelligent (sans mépris pour son fantastique ancêtre), à qui on ne donnerait que des commandes type gcc -o main.o -c main.c, et qui se débrouillerait pour comprendre par lui même les entrées, les sorties et les dépendances? Smk, c'est "Simple Make", j'ai pas été cherché loin. Mais c'est tellement ça. D'accord, mais on fait comment? Sur Linux, le kernel offre depuis belle lurette une interface pour tracer tout un tas de chose: ptrace. (Je développe sous Linux, alors je ne parle que pour Linux, mais il y aurait des équivalents laissant espérer un portage pas trop galère sur pas mal d'autres OS). Et même plus simple que ptrace, et suffisant pour ce qu'il est convenu d'appeler un POC, il y a l'outil strace. strace est surtout utilisé à des fins d'analyse ou de debug, mais après tout, pourquoi ne pas le sortir un peu de ses rails? Alors l'idée, c'est juste de demander à strace de lancer les commandes du smkfile en espionnant les opérations sur les fichiers, et d'analyser ensuite le log pour déduire des opérations de "read" les fichiers sources, et des opérations de "write" les fichiers cibles. Sur le papier, ça à l'air simple, hein? Mais l'expérience t'apprend que quand ça à l'air simple, ça veut juste dire que c'est le début. (Houla, je suis en forme! Note la bien celle là, on dirait du Sénèque à sa sortie de l'Epitech) Et à l'usage, ça ressemblerait à quoi smk? Je vais me servir d'un petit exemple tiré du tuto, un classique Makefile avec trois compilation : all : hello hello.o : hello.c gcc -o hello.o -c hello.c main.o : main.c hello.h gcc -o main.o -c main.c hello : hello.o main.o gcc -o hello hello.o main.o Note que smk ingère ce fichier tel quel (smk sait lire des Makefile simple). Mais, me diras-tu, si il faut écrire ça pour l'utiliser, je ne vois pas bien l'intérêt, autant utiliser make. En effet! La promesse de smk, c'est de réduire le Makefile au strict minimum, et voici donc le smkfile correspondant: gcc -o hello.o -c hello.c gcc -o main.o -c main.c gcc -o hello hello.o main.o Au niveau ménage, je dirai qu'on est pas mal : on ne peut pas retirer grand chose de plus sans taper dans l'indispensable! Appelons ce smkfile mybuild.txt et allons-y. Première invocation > smk mybuild.txt gcc -o hello.o -c hello.c gcc -o main.o -c main.c gcc -o hello hello.o main.o Jusque là tout va bien. Deuxième invocation > smk Nothing to run OK, c'est bien ce que ferait make. Note que je ne précise plus le nom du smkfile. smk garde la trace de ce qui a été exécuté dans ses runfiles (fichiers .smk.* dans le répertoire courant). Si il n'y a eu qu'un seul run dans ce répertoire, pas d'ambiguïté, donc pas besoin de préciser. C'est maintenant le tour de passe-passe? > touch hello.c > smk gcc -o hello.o -c hello.c gcc -o hello hello.o main.o Ah ouais, c'est bien comme make, alors qu'on a pas décrit la moindre "target" ou la moindre "recipe". Mais attends, je ne comprends pas : un tuto? des exemples? Tu veux dire que ça tourne déjà?? Je te l'avais dit que tu ne regretterais pas d'être resté! Il ne te reste plus qu'a l'essayer Inutile de te dire que je n'en suis pas à packager ou à dockeriser smk, va falloir faire à ça l'ancienne. Heureusement, ça reste simple. Il faut juste un gcc Ada:apt install gnat (ou ce qui va bien sur ta distro), ou bien télécharge GNAT ici (il s'installera alors sous /opt). Puis : git clone https://github.com/LionelDraghi/smk.git cd smk gprbuild -P smk.gpr Et ensuite, direction le tuto! Quelques caractéristiques fun Y-a-quoi dans la boite? Maintenant que ça a tourné, tu aimerais peut-être savoir ce que smk a compris et stocké de la situation, en terme de commandes, sources et cibles. Note au passage que ce sont les seuls concepts: il n'y a pas besoin de 'recipes' pour faire le lien entre les sources et les cibles, la commande est le lien. Il y a une option pour ça: > smk -rl (read previous runs) 2018-12-10 22:15:39.30 [hello] gcc -o hello hello.o main.o Sources (2) : - 2018-12-10 22:15:39.00:/home/lionel/Proj/smk/tests/hello.c/hello.o - 2018-12-10 22:15:39.00:/home/lionel/Proj/smk/tests/hello.c/main.o Targets (1) : - 2018-12-10 22:15:39.00:/home/lionel/Proj/smk/tests/hello.c/hello 2018-12-10 22:15:39.08 [hello.o] gcc -o hello.o -c hello.c Sources (1) : - 2018-12-10 22:15:38.00:/home/lionel/Proj/smk/tests/hello.c/hello.c Targets (1) : - 2018-12-10 22:15:39.00:/home/lionel/Proj/smk/tests/hello.c/hello.o 2018-12-10 22:15:39.19 [main.o] gcc -o main.o -c main.c Sources (2) : - 2018-11-14 23:14:17.00:/home/lionel/Proj/smk/tests/hello.c/hello.h - 2018-12-07 00:41:31.00:/home/lionel/Proj/smk/tests/hello.c/main.c Targets (1) : - 2018-12-10 22:15:39.00:/home/lionel/Proj/smk/tests/hello.c/main.o Elle donne pour chaque commande, l'heure d’exécution, et la liste des sources et des cibles avec la date de modification de chaque fichier. Et pour faire le ménage? Comme smk connait toutes les cibles, fini les multiples rm -rf dans les sections clean des Makefile, smk s'en charge: > smk --clean Deleting /home/lionel/Proj/smk/tests/hello.c/hello Deleting /home/lionel/Proj/smk/tests/hello.c/hello.o Deleting /home/lionel/Proj/smk/tests/hello.c/main.o Après la frappe chirurgicale, le build chirurgical Toujours parce que smk connait toutes les cibles, un build particulier sera aussi simple que > smk hello.o ("sera", parce que ça, je ne l'ai pas encore implémenté. Mais tu l'auras pour Noël, promis!) Et ça pourra être n'importe lequel des fichiers cibles (liste que l'on obtient par > smk -lt (--list-targets)). Pratique, non? Prends toutes les options, c'est le même prix Bien sûr, smk s'efforce de rendre les fonctions essentielles de make, avec si possible le même nom d'option (inspirés soit de make, soit de mk):-k (keep-going), -n (dry-run), -e (explain), etc. Un peu d'histoire L'idée est resté en sommeil pendant pendant longtemps, parce que l'aspect trifouillage des appels au kernel ne me tentait pas trop, j'imaginais ça très compliqué. Mais en fait, dès les premières recherches, je suis tombé sur l'outil idéal même si fait pour des fonctions plus classiques de debug et de d'espionnage, strace. C'est ainsi qu'est né en moins de deux semaines la première version utilisable de ce POC (la v0.0.2). Finalement, j'ai galéré là ou je ne pensais pas (problème de précision de la date de modification de fichier dans mon environnement de dev. GNAT), et au contraire, j'ai été assez vite là ou j'anticipais une galère (interprétation de la sortie de strace pour classifier un accès fichier en 'read' ou en 'write'). L'aventure à commencé il y a tout juste un mois, mais j'ai déjà eu quelques retours qui me font penser que l'idée ira au-delà de ce "POC". Et toi, t'en dit quoi? Le plan de développement à court terme Mon intention est d'aller vers la prise en compte de besoins un peu plus complexes. Ce que j'ai aujourd'hui dans le radar: la prise en compte d'objectifs différents, voir même antagonistes dans le même fichier: actuellement, si tu veux un build prod et un build debug, il faut faire deux smkfile. Et on a pas toujours envie de multiplier les fichiers, alors je suis parti pour implémenter un mécanisme de "sections", avec une syntaxe à la make: section1 : commande 1 commande 2 section2 : commande 1 commande 2 etc. Que l'on pourra invoquer avec un: > smk section2: la "récursion": si on veut que le build de prod et le build de debug exécutent la même suite de tests, alors il serait bon que l'on puisse dans un smkfile en invoquer un autre. Ce sera alors fait en appelant smk autrefichier.txt, et non par une syntaxe d'include particulière, car je veux que le format du smkfile reste simple. Et quoi de plus simple que juste ce que l'on aurait tapé sur la ligne de commande? les cibles sans cibles, comme rm main.o. Clairement pour moi, la cible n'est pas le fichier, c'est l'effacement. A discuter. Mais bien sûr si je publie ceci, c'est pour avoir des réactions, des idées, des envies, et surtout des utilisateurs (voire même des contributeurs!). Et vos retours peuvent grandement changer mes plans. Alors, en ce qui concerne le plan de dev, demain est un autre jour. Et toi dans tout ça? Cette v0.1.0 me semble d'ores et déjà utilisable, et je suis curieux d'avoir des retours sur le concept. Et de savoir ce que serait ton "dream-product". Juste une précision, afin de cadrer le débat : smk n'a pas vocation à faire tout ce que fait make ou un système de build sophistiqué. Mais en revanche je pense qu'il y a un créneau d'application assez large, tout en respectant son ADN : universel et très simple. Merci d'y penser avant de me sortir tous les truc magiques que tu fait avec des Makefiles imbitables! :-) En savoir plus Sur le site de smk, tu trouveras diverses choses utiles, comme (en vrac) les tests, des indications sur le format du fichier texte en entrée (baptisé logiquement smkfile), la compatibilité de ce format avec celui des Makefile, une petite comparaison smk/make, des discussions sur le design, etc. C'est un POC, mais ce n'est pas une raison pour ne pas faire les choses biens! Les sources sont disponibles sur https://github.com/LionelDraghi/smk/, que tu peux utiliser pour remonter tes idées, bugs, remarques… Last but not least, smk est sous Apache 2.0. Télécharger ce contenu au format Epub Commentaires : voir le flux atom ouvrir dans le navigateur

group_work LinuxFRJournaux Il y a 6 jours - 23:27

acme-dns-tiny v2.1 has been released ☺

This release does a jump from RFC draft 9 implementation to ACME RFC draft 16. Full details available on the tag v2.1. PS: that's not related to the recent dnspython 1.16 release 😉

group_work acme-dns-tiny Il y a 7 jours - 22:15

dnspython 1.16.0 has been announced

Bob Halley has announced a new release of dnspython, a python library to do DNS stuff. As you may have seen, acme-dns-python heavily relies on dnspython to do its job and so we'll need to check if the script is still compatible with this new release. Please note that we should not have many troubles with the next 2.x release of dnspython as, acme-dns-python is already thought to be used only with Python 3.

group_work acme-dns-tiny Il y a 7 jours - 19:56

Systèmes d'exploitation pour téléphones. Partie 1 : Premières initiatives ☎😍

Voici la première dépêche d'une série sur les systèmes d'exploitation (plus ou moins) libres pour téléphones. Dans les années 90, nos téléphones n'étaient pas libres. Mais, au début des années 2000, des libristes s'organisent et une multitude d'initiatives apparaissent. Remémorons-nous ces bons vieux projets des débuts. C'était aussi la mode des GIF animés 🐧 Qui pourrait se passer de son téléphone ? Celui-ci devient de plus en plus puissant, remplaçant souvent l’ordinateur. Ainsi, 17 % des français possédaient un smartphone en 2011 et 73 % en 2017. [réf] Mais avons-nous le contrôle sur notre téléphone ? Acheter un ordinateur avec un OS libre est plutôt facile. Et pour libérer nos téléphones ? [NdM] : cette dépêche est publiée sous licence CC BY-SA 3.0 lien n°1 : Quel système d'exploitation pour nos téléphones ? - FramaGit lien n°2 : Quel système d’exploitation pour nos téléphones ? - GitHub lien n°3 : QT dévoile Qtopia Phone Edition - programmez.com - 2003 lien n°4 : Qtopia GreenPhone : prix et disponibilité - generation-nt.com - 2006 lien n°5 : Opie 1.0 dans les bacs - LinuxFr - 2003 lien n°6 : État de l'art des anciens projets libres mobiles - postmarketOS - 2018 lien n°7 : GPE 2.7 pour PDA sous Linux et Tablette Wifi Nokia 770 - LinuxFr - 2016 lien n°8 : Sortie de la version «Doppio» de LuneOS - LinuxFr - 2018 Sommaire Introduction Qtopia Phone Edition OPIE GPE Phone Edition DeforaOS OpenWifiPhone La famille OpenMoko Hackable:1 SHR QtMoko Symbian De Palm OS à LuneOS 🌜🌠 Conclusion Appel à participation Introduction Initialement, nous avions prévu une seule dépêche. Mais, au fur et à mesure de sa rédaction (2000 révisions en deux ans), cette longue dépêche était devenue trop volumineuse pour être digérée en une seule fois. Alors, nous l'avons découpé en petites bouchées : Les premières initiatives ☎😍     ← Vous êtes ici La lignée de Maemo à Nemo 🔒 Le libre sur la planète Android 🤖💚 La saga Firefox OS 🦊🚀 Ubuntu pour unifier ordinateur et téléphone 🖥️📲 Les récents projets qui risquent de chambouler le monde 🌍 Une synthèse des commentaires de toutes ces dépêches 🤷 Mais si ton estomac est coriace, nous avons aussi tout regroupé dans un article disponible sur deux dépôts Git : Framagit et GitHub. Une fois publiée, une dépêche sur LinuxFr.org est rarement modifiée. Alors, aide nous dans la rédaction des dépêches à venir. 📳💟 Sinon, ce n'est pas trop tard, tu peux toujours proposer tes idées d'amélioration sur les dépôts Git avec ta poule ricouestte. 🐔 Qtopia Phone Edition 1991, deux norvégiens commencent à coder une bibliothèque graphique en C++ batisée quelques années plus tard Qt qui signifie Q toolkit (la boite à outils Q) et se prononce cute (mignon) ; 1995, Trolltech publie Qt-0.90 avec, pour la première fois, son code source et prend en charge X11 et Windows ; 1997, Matthias Ettrich démarre l'ambitieux environnement de bureau KDE en choisissant Qt, apportant à cette bibliothèque une immense publicité (pourtant Qt n'était pas libre à cette époque) ; 2000, Trolltech publie Qt-2.2 et lance le projet Qt/Embedded ; 2003, Trolltech lance Qtopia Phone Edition, un système d’exploitation complet (sous Linux) incluant l'environnement graphique et ses applications ; 2006, Trolltech décompose Qt/Embedded en QWS et Qtopia Core qui équipent, à l’époque, un million d’appareils (une dizaine de modèles de téléphones et une trentaine d’autres types d’appareils) ; 2007, Trolltech commercialise le Greenphone (en), un téléphone sous Linux pour faire la promotion de Qtopia (les derniers logiciels prorio deviennent libres à partir de Qtopia-4.3) ; 2008, suite au rachat par Nokia (100 millions €), Trolltech devient sa filiale Qt Software, et le projet Qtopia est renommé en Qt Extended ; 2009, abandonné par Nokia, le projet Qt Extended est repris par la communauté sous le nom de Qt Extended Improved (QtEI). Qtopia (Trolltech) | Symbian^1 ▼ Symbian^2 ◀──▶ Qt Symbian^3 Extended (Nokia) (Nokia) | ▼ QtEI (Communauté) Pour l’anecdote, après avoir dissout la société norvégienne Trolltech Qt Software (2010), Nokia revend Qt à Digia (2012). Cette dernière recrée à nouveau la société, mais en Finlande (2014), puis l'introduit en bourse sous le nom de Qt Group (2016). Vidéo : 41 secondes pour se faire une idée du Qtopia Greenphone (2007) OPIE 2002, OPIE (Open Palmtop Integrated Environment) naît de la bifurcation (fork) de Qtopia ; 2013, le projet n’a presque plus d’activité ; 2014, le dernier développeur, Paul Eggleton (bluelightning) réalise les derniers des 12 000 commits en 12 ans ; 2015, le code source est migré sur GitHub pour la prospérité. Qtopia ─▶ OPIE (Trolltech) (Communauté) | ▼ Qt Extended ─▶ QtEI (Nokia) (Communauté) OPIE n’est pas un système d’exploitation, mais, tout comme G(PE)2, il est un environnement graphique complétée par 80 applications. OPIE est basée sur Qt, au contraire de G(PE)2 qui est basé sur GTK+. OPIE a souvent été utilisé sur un système d’exploitation libre comme Familiar Linux (2001-2007), OpenZaurus (2002-2006) et Ångström (2007-2018). Ce sont des systèmes d’exploitation conçus à l'origine pour PDA et ordinateur de poche mais peuvent aussi équiper des téléphones. Vidéo : OPIE avec Ångström sur un Sciphone G2 en 2011 (3 minutes) GPE Phone Edition En 2001, Nils Faerber annonce le projet GPE (sigle récursif pour GPE Palmtop Environment) pour offrir une interface graphique et des applications aux PDA de l’époque. GPE utilise GTK+ et fournit toutes les applications de bases qui sont écrites essentiellement en C ; En 2006, l'équipe GPE crée le projet GPE Phone Edition aka G(PE)² pour les téléphones ; En 2008, l'initiative G(PE)2 est abandonnée après 1500 commits en deux années ; En 2013, le projet GPE devient inactif après 9000 commits et 11 années d’activité. G(PE)2 est un environnement graphique (applications), le concurrent communautaire de OPIE. Tous deux nécessitent un système d’exploitation comme Familiar Linux (2001-2007), OpenZaurus (2002-2006) et Ångström (2007-2018). GPE fonctionnait avec ces systèmes d’exploitation sur PDA et ordinateur de poche. G(PE)2 était adapté aux téléphones, et utilisait probablement la distribution GNU/Linux Ångström. Vidéo : Démarrage d'une distribution GNU/Linux avec GPE-2.7 sur un iPAQ avec Windows Mobile 5, probablement en utilisant HaRET (1 minute et demi, 2007) DeforaOS En 2004, Pierre Pronchery (khorben), en stage d'école d'ingénieur, commence à travailler sur le projet DeforaOS. Pierre explique que le but est de proposer un environnement natif basé sur Debian et GTK+, pour différents matériels capables de démarrer un système alternatif. Le développement continue mais au ralenti car : Pas de financement durable ; Plus de matériel de référence pour la téléphonie libre ; Peu d’engouement pour GTK+ par rapport à Qt ; Outils disponibles sous Linux décevant comparativement à ceux sur NetBSD. Pierre est toujours prêt à travailler avec une équipe pour proposer une alternative à Android et iOS. Mais cela implique un budget à 7 chiffres… Vidéo : Conférence de DeforaOS : un voyage dans le développement d'un OS (1 heure) par Pierre Pronchery (enregistrée par l'association MiNET en 2018) OpenWifiPhone En 2005, Miko et Oliver créent le projet OpenWifiPhone pour développer sur leur temps libre un téléphone 100 % logiciel libre. Le protocole GSM n’étant pas encore pris en charge par le noyau Linux, ils utilisent un SoC ARM spécialisé VoIP Wi-Fi fourni par un fondeur qui espérait que ce type de téléphones puissent remplacer les DECT. C’était aussi le début des réseaux Wi-Fi communautaires (Réseau citoyen, France Wireless…). Le logiciel grenoblois Linphone avec Speex permettait déjà des appels téléphoniques SIP. Des opérateurs commençaient aussi à installer des bornes Wi-Fi (hotspot), un bouillonnement… Mais en 2008, les deux amis ont dû déménager dans des villes différentes, puis baisse de motivation et, en plus, les téléphones Wi-Fi ne percent pas. La famille OpenMoko 2006 Des Taïwanais créent la société Openmoko (Open Mobile Kommunikations) pour vendre des téléphones dont les utilisateurs peuvent bidouiller le système d’exploitation ; Openmoko crée le site communautaire openmoko.org ; Openmoko publie FreeSmartphone.Org (FSO), un intergiciel (middleware) pour faciliter la communication entre processus (détails en anglais) ; 2007, dark_moule nous prévient de la vente des 1000 prototypes Neo 1973 (300$ et 450$) ; 2008, dark_moule nous annonce son successeur, le Neo FreeRunner, disponible à 330 € chez Bearstech ; 2008 swap38 crée le site francophone openmoko-fr.org ; Publication de SHR, distribution GNU/Linux basée sur FSO et compatible avec les téléphones GTA ; Publication d’une autre distribution FDOM (Fat and Dirty OpenMoko) ; 2009 L'agence spatiale allemande envoie dans l'espace un Neo FreeRunner pour étudier le comportement en conditions extrêmes d'un appareil grand public, notamment de son accéléromètre (le Neo FreeRunner est choisi car il est libre et ne cache pas son fonctionnement interne permettant d'apporter la preuve scientifique) ; Openmoko arrête le développement de ses téléphones pour cause de financement insuffisant ; Harald Welte avec la communauté maintiennent le code source et le site openmoko.org ; publication de la distribution Hackable:1 pour téléphones ; 2010, publication de QtMoko avec le portage de l’environnement Qtopia sur OpenMoko ; 2012, création de OpenPhoenux (OPEN PHOnE liNUX) pour fédérer les communautés, les logiciels et fabrication de matériels libres (open-hardware) et devient tinkerphones en 2016 ; 2017 Adrien Dorsaz fait le bilan OpenMoko et des téléphones associés ; Michael Lauer (Mickey), un des développeurs de cette aventure, publie une rétrospective du projet OpenMoko 10 ans après sa naissance (en). OpenMoko (Openmoko Communauté) _________|_________ | | | | | | FDMO | | ... | | | | Hackable:1 | SHR QtMoko Hackable:1 En 2009, Pierre Pronchery (khorben) intègre la société Bearstech, puis crée avec d'autres la distribution Hackable:1 pour fournir une Debian avec GNOME Mobile. En 2010, une dizaine de personnes travaillent sur Hackable:1. En 2012, le projet est progressivement abandonné. Vidéo : 5 secondes de Hackable:1 (2009) SHR La distribution GNU/Linux SHR, qui signifiait à l'origine Stable Hybrid Release réutilise le travail d'Openmoko. Initialement créée en 2007 pour combiner GTK+ et le nouveau intergiciel (middleware) freesmartphone.org (FSO) créé par Openmoko, SHR a beaucoup évolué et les applications graphiques se basent de préférence sur les Enlightenment Foundation Libraries (EFL), mais peuvent aussi utiliser GTK+ ou Qt. Pour uniformiser la communication entre les applications, la communication entre les différentes couches du système utilise l’interface D-Bus. La construction de l’image (ROM) utilise OpenEmbedded et le gestionnaire de paquets opkg. SHR se veut flexible, et il peut être installé entre autres sur les téléphones Openmoko Neo Freerunner, Goldelico OpenPhoenux (GTA04) et Nokia N900. Très appréciée, la distribution était en 2010 la plus utilisée pour les téléphones Openmoko. En 2010, le projet Yocto apparaît et SHR s'adapte pour en profiter : les couches shr-core et meta-smartphone apparaissent, et le rythme de sortie se cale sur celui de Yocto. Depuis 2013, SHR est globalement inactif. Cependant la couche meta-smartphone, réutilisée par LuneOS, est toujours maintenue. En 2017, la branche « shr » du dépôt meta-smartphone est finalement supprimée. En 2018, la branche master du dépôt meta-smartphone est toujours très active, notamment grâce aux distributions LuneOS et AsteroidOS qui y contribuent. Vidéo : Démarrage de SHR sur GTA04 en 17 secondes, une prouesse ! (2012) QtMoko En 2009, Nokia, alors dirigé par un ancien de chez Microsoft, abandonne le projet Qt Extended, anciennement Qtopia (code source). Immédiatement, la communauté s'organise et créé la bifurcation (fork) Qt Extended Improved (QtEI). Dans la continuité du dépôt Git de QtEI commence le projet QtMoko pour unifier le meilleur des projets communautaires QtEI et OpenMoko, notamment sur le portage vers Debian. Une première version est même publiée la même année. Qtopia ───▶ OPIE (Trolltech) (Communauté) | | OpenMoko | (Communauté) ▼ | Qt Extended | (Nokia) | | ▼ QtEI ─▶ QtMoko (Communauté) Bien que OPIE et QtMoko soient issus du même ancêtre Qtopia, les deux projets ne sont pas compatibles, et donc les applications OPIE ne peuvent être réutilisées sous QtMoko. Chacun développe dans son coin ! L'environnement graphique Qtopia étant sous licence GPL, toutes les applications fournies doivent également être sous la même licence. Cette limitation a pour origine le modèle économique de Trolltech qui vendait une licence commerciale (non-libre). Aucune entité n'étant propriétaire de l'ensemble du code source, ce n'est plus possible de s'arranger afin de fournir une application non-libre ou avec une licence incompatible avec la GPL. Ce qui peut être vu comme un avantage pour les libristes et ceux qui sont soucieux de leur vie privée, mais aussi comme un inconvénient pour ceux qui souhaitent inciter les entreprises/développeurs à proposer leurs applications non-libres ou avec d'autres licences libres. Lire le troll quand Nokia a passé une partie de Qt sous licence LGPL en 2009. Cependant en 2014, Radek Polak, le dernier développeur, se décourage à cause, entre autres, de la consommation élevée de la batterie quand le téléphone est en veille. Néanmoins, neuf mois plus tard, c'est la renaissance du projet. Nikolaus Schaller, fervent défenseur du libre et fondateur de Golden Delicious crée la bifurcation (fork) QtMoko2. Cela tombe bien, sa société conçoit des téléphones libres comme le GTA04 et le neo900. ^_^ Vidéo : Démo QtMoko sur GTA02 (3 minutes, 2011) Symbian Voici l’histoire de l’ouverture-fermeture du code source de Symbian OS entre 2008 et 2011 : Avant 2005 : Symbian est né d'un partenariat entre la société Psion, éditeur du logiciel Epoc 32, et les sociétés Nokia, Ericsson, Motorola et Matsushita. Selon Wikipedia il dispose de nombreuses API spécifiques pour la communication mobile voix et données, et utilise des protocoles standard de communication réseau : IPv4/IPv6, WAP, MMS, Bluetooth, GPRS/UMTS, Java, SyncML, … En 2005, Nokia travaille sur Maemo, un nouveau système d’exploitation pour ses ordiphones (tablettes, smartphones, …), mais celui-ci n’est pas encore suffisamment mature, alors Nokia continue de commercialiser ses produits phares (flagship) avec Symbian (jusqu’en 2010) ; En 2006 : toujours selon Wikipedia : plus de 100 millions de téléphones et de smartphones (comme les excellents Nokia E71 et E72) ont été vendus. L'Europe est, à cette époque, la figure de proue du domaine. Nov. 2007, Google crée l'Open Handset Alliance (OHA) réunissant 34 partenaires pour promouvoir Android (84 entreprises en 2018) ; Jan. 2008, Nokia s’inquiète du modèle économique open source de Android et rachète Trolltech pour 100 millions face à Google qui annonce le Android Developer Challenge pour distribuer 10 millions aux développeurs des meilleures applications Android ; Juin 2008, Nokia, toujours inquiet, rachète Symbian afin d’ouvrir le code source et de créer la Symbian Foundation (en) à l’instar de l’OHA ; En 2009, le noyau de Symbian^1 est libéré, puis Symbian^2 contient davantage de code libre ; Fév. 2010, tout le code source de Symbian^3 est sous licence EPL comme pressenti par Raphaël SurcouF ; Deux semaines plus tard, Nokia présente au MWC un installateur d’applications Qt pour téléphones Symbian comme le Nokia N97, le Nokia 5800 et le Nokia E72 très apprécié par zarbatrip ; Oct. 2010, le Nokia N8 est le dernier smartphone phare (flagship) sous Symbian ; Fév. 2011, le nouveau PDG de Nokia (ancien Microsoft) choisit Windows Phone pour le haut de gamme, dissout la Symbian Foundation et ferme le code source de Symbian. Qtopia (Trolltech) | Symbian^1 ▼ Symbian^2 ◀──▶ Qt Symbian^3 Extended (Nokia) (Nokia) | ▼ QtEI (Communauté) Le SDK était complexe à mettre en œuvre et il fonctionnait uniquement sous Windows avec des outils assez mal empaquetés (packagés). Les applications étaient codées en C++ avec Qt, mais aussi, dans une moindre mesure, en Java (J2ME) et en Python. Des morceaux de Symbian sont réutilisés dans d’autres projets comme Qt Extended et Maemo. Un peu de ce code source originel subsiste dans l’ADN des descendants (MeeGo, Mer, Sailfish, Nemo) qui sont également en C++ et Qt. Vidéos de 2010 pour se faire une idée de la progression entre Symbian^1 (Nokia C3) et Symbian^3 (Nokia N8) : https://youtu.be/UJNYqnnWPvw (7 minutes) https://youtu.be/GDnvqp_MYH8 (6 minutes) https://youtu.be/Rub7BDoduKw (5 minutes) https://youtu.be/GmKFzaDfhTo (6 minutes et demi) De Palm OS à LuneOS 🌜🌠 1996, sortie de Palm OS avec les PalmPilot 1000 et 5000 (en) ; 2002, la société PalmSource est créé pour développer/commercialiser Palm OS et devient indépendante de Palm l’année suivante ; 2004, malgré les améliorations apportées, PalmSource n’arrive toujours pas à commercialiser Palm OS et décide de développer un successeur basé sur Linux ; 2006, Palm arrive à récupérer les droits sur Palm OS et PalmSource annonce l'arrivée prochaine du successeur ; 2007, PalmSource publie ACCESS Linux Platform, une distribution GNU/Linux (GTK+, GStreamer, BlueZ, matchbox, cramfs…) pour succéder à Palm OS mais les deux téléphones qui devaient être commercialisés sont annulés ; 2008, Palm travaille sur Nova basé sur Linux pour succéder à Palm OS ; 2009, Palm commercialise le smartphone Palm Pre équipé de Nova renommé en webOS, premier successeur de Palm OS à équiper un produit grand public ; 2010, HP rachète Palm pour 1 milliard dans l’objectif d’équiper ses appareils avec webOS (même pour ses imprimantes) ; 2011, HP abandonne finalement l’idée de commercialiser ses produits avec webOS, puis décide de collaborer avec la communauté libre ; 2012, HP publie Open webOS avec 450 000 lignes de code sous licence Apache 2.0 ce qui permet à la communauté webOS-ports de poursuivre le développement ; 2013, LG rachète à HP les droits sur webOS pour équiper ses téléviseurs connectés ; 2014, la communauté webOS-ports publie LuneOS issue de Open webOS avec une base Android ; 2018, LG crée webOS OSE (Open Source Edition) et propose une collaboration à double sens avec LuneOS. Palm OS (Palm) | Palm OS (PalmSource) ___|___ | | webOS ALP (Palm) (PalmSource) | webOS (HP) \ | \ | Open webOS webOS (HP + Communauté) (LG) \ \ | \ \ |webOS OSE ◀─▶ LuneOS | (LG) (Communauté) | | | | | | ··· ··· ··· LuneOS n'est pas un ancien projet, il est plutôt récent. Mais il est présenté dans cette première partie pour ses racines qui remontent aux années 90. Son nom provient de l’interface graphique Luna, héritage d'un long processus de maturité et souvent copié. Pour pouvoir fonctionner sur du matériel récent, LuneOS réutilise les couches basses du projet LineageOS, dont les pilotes (driver) d’Android. C'est le projet Halium qui fédère ces couches basses avec les différents systèmes d'exploitation. À part certains blobs issus des pilotes Android, tout le reste est sous licence Apache 2, MIT, GPL et LGPL. Ainsi nous profitons de l'ergonomie intuitive issue de webOS sur des mobiles récents.   \o/   Une petite dizaine d'appareils sont déjà pris en charge officiellement dont les Nexus 4 et 5, les Xiaomi Mi A1, Redmi 5, Note 4x et aussi les Raspberry Pi 2 et 3. L'équipe webos-port privilégie les téléphones avec un bon rapport qualité/prix, une forte communauté et un bootloader déverrouillable. Historiquement, c'était les Nexus, mais depuis que Google a monté en gamme avec les Pixel, l'équipe webos-port s'est rabattue sur les téléphones Xiaomi. LuneOS, tout comme pour SHR, utilise OpenEmbedded pour la construction de ses paquets. De plus, comme SHR était déjà installable sur les téléphones HP Palm Pre, Pre Plus et Pre2, LuneOS réutilise également une partie du projet. Tout comme pour les projets Mer, Sailfish OS et Nemo mobile, les applications natives de LuneOS utilisent généralement la bibliothèque graphique Qt qui profitent de l'accélération matérielle avec QtWayland. D'ailleurs, l'équipe webos-ports collabore avec le projet Mer, car certaines briques de Mer sont réutilisées dans LuneOS, comme la gestion de la téléphonie. En mars 2018, à la surprise générale, LG publie [1] ,[2] webOS OSE (Open Soure Edition) afin d'inciter d'autres constructeurs à utiliser ce système d'exploitation dans leurs produits. Cette ouverture permet à webOS OSE de bénéficier des innovations apportées par la communauté webos-port, mais aussi de partager les améliorations et corrections de webOS OSE vers LuneOS. En juin 2018, des représentants de LG et de webos-port se rencontrent à Paris pour mieux collaborer et choisissent le Xiaomi Mi A1 (en) comme base commune (et non pas un des téléphones LG). LG compte beaucoup sur son système d'exploitation et met à jour sa feuille de route (roadmap) régulièrement (en). Le 28 novembre 2018, la publication de la version majeure LuneOS Doppio améliore le Bluetooth (passage de BlueZ4 à BlueZ5 et mutualise davantage son code source avec le projet Halium (en). L’équipe webos-port est constituée d’une vingtaine de personnes et a besoin d’aide : coder/tester les applications natives ; remplacer les composants de Open webOS par ceux de webOS OSE ; réparer l’image VirtualBox qui ne fonctionne plus avec les versions récentes de Mesa ; migrer vers Yocto Sumo/Thud ; améliorer les messages, la caméra ; prendre en charge à nouveau le GSM du Touchpad 4G (seul le WiFi fonctionne) ; corriger la régression sur Node-SQLite3 ; corriger les régressions du clavier virtuel ; corriger les régressions sur certains appareils et en prendre d'autres en charge. Ainsi, LuneOS, s'améliore progressivement et un jour une nuit, des téléphones seront peut-être vendus avec LuneOS préinstallé… lors de la pleine lune… Pour en savoir plus, Christophe Chapuis nous présente régulièrement le projet LuneOS dont il est contributeur : webOS se relance en LuneOS (2014) Quelques nouvelles de LuneOS (2017) LuneOS « Doppio » est sortie (2018) Vidéo : Démo de 5 minutes de l'application LuneTube version 0.2.0 (2016). Aujourd'hui (2018), cette application en JavaScript a beaucoup mûri et en est à la version 0.5.3. Conclusion Ceci n’est pas le chapitre conclusion. 😮 Ah, mais elle est où la conclusion ? 🤔 Ben… dans les commentaires ! 😜 Et oui, chacun à son avis : les échecs, les spéculations, les succès, le positif… Restons bienveillants dans nos réactions : même si nos arguments sont différents, nous sommes tous globalement d’accord pour avoir davantage de contrôle sur nos téléphones, pas besoin d’utiliser des mots agressifs. 😘 😍 Un rappel des projets que nous venons d’aborder par ordre de date de première publication du code source : 2000, Qtopia, bibliothèque graphique Qt pour l’embarqué ; 2001, GPE, environnement GNOME allégé avec ses applications ; 2002, OPIE, bifurcation de Qtopia par la communauté avec des applications ; 2003, Qtopia Phone Edition, distribution GNU/Linux pour téléphone ; 2004, DeforaOS, distribution GNU/Linux pour appareils mobiles ; 2005, OpenWifiPhone, distribution GNU/Linux pour téléphones Wi-Fi ; 2006, GPE Phone Edition, adaptation de GPE pour téléphones ; 2007, ACCESS Linux Plateform, distribution pour succéder à Palm OS (1996) ; 2007, OpenMoko, distribution GNU/Linux pour téléphones ; 2008, SHR, distribution GNU/Linux pour téléphones ; 2008, Symbian^1, le système d’exploitation le plus utilisé par les téléphones de l’époque ; 2009, Hackable:1, distribution GNU/Linux pour téléphones ; 2010, QtMoko, fusion de OpenMoko avec l’environnement Qtopia ; 2012, Open webOS, libération de webOS (un autre successeur de Palm OS) ; 2014, LuneOS, fusion de Open webOS avec une base Android ; 2014, QtMoko2, renaissance du projet QtMoko par la société allemande Golden Delicious (en) ; 2018, LG publie webOS OSE et des mutualisations possibles avec LuneOS. Parmi ces projets libres, quatre sont toujours actifs : DeforaOS, QtMoko2, LuneOS et webOS OSE. Afin de se concentrer sur les téléphones et leurs environnements applicatifs, nous n’avons pas abordé les distributions GNU/Linux comme Familiar Linux (2001-2007), OpenZaurus (2002-2006), Ångström (2007-2018) et Poky (en). Ni les systèmes de construction d’image (ROM) comme OpenEmbedded (en) et Yocto (en). Ni les serveurs graphiques comme PicoGUI (en) et TinyX-KDrive (en). Et nous n’avons pas non plus abordé les suites applicatives comme Pimlico (en). Le projet OsmocomBB (2010) est postérieur à la période du début des années 2000, et cette première dépêche est déjà assez longue. Nous en parlerons dans la partie 6. Appel à participation Tu as aimé cette épopée entre logiciels libres et téléphones, cette tumultueuse aventure agrémentée de liens vers des articles LinuxFr.org, témoignages à jamais gravés dans le marbre, reflets de nos enthousiasmes, nos déceptions et nos espérances. Pour nous aider à continuer : Indique nous dans les commentaires tes idées pour aider ces projets, du moins ceux qui te tiennent à ♥ ; Si tu souhaites améliorer les articles Wikipédia, sache que cette dépêche a été spécialement publiée sous licence CC BY-SA 3.0 car Wikipédia hésite à passer à la 4.0 depuis deux ans ; D’autres dépêches de cette série d’articles sont peut-être encore en cours de rédaction, tu peux nous rejoindre dans l’espace de rédaction ; Une autre ambitieuse dépêche se prépare également : Quel téléphone mobile en 2019 ? Note que pour limiter le pourriel (spam), tu dois te créer un compte pour accéder à l’espace de rédaction. Tu peux aussi jeter un œil sur comment participer à LinuxFr. Une dernière vidéo pour patienter d'ici la prochaine dépêche : Les OS mobiles alternatifs par Lionel Duboeuf en mai 2018 (1 heure). Le support de présentation est disponible sous licence libre aux formats ODF et PDF. Télécharger ce contenu au format Epub Commentaires : voir le flux atom ouvrir dans le navigateur

group_work LinuxFRNews 8 Décembre

Sortie de Prosody 0.11

Ceci est la traduction de l’article Prosody 0.11.0 released, et est également disponible sur JabberFR ainsi que sur le blog de Prosody. Nous somme ravis d’annoncer la sortie longuement attendue du serveur XMPP Prosody 0.11.0 ! Ceci est la première version de la série 0.11, qui sera maintenant considérée comme la série stable. Cette version, avec plus de 2000 commits, n’aurait pas pu se faire sans l'aide de nombreux contributeurs, testeurs, et autres membres de la communauté. Merci ! lien n°1 : Prosody 0.11.0 released lien n°2 : Sortie de Prosody 0.11 lien n°3 : Notes de version lien n°4 : Setting up a modern XMPP server lien n°5 : Page de téléchargement lien n°6 : Discussion channels Sommaire Points importants Fonctionnalités principales Amélioration des salons Amélioration de la configuration Archivage des messages Réservation du pseudo Protocole PubSub PEP Nouveau format de vCard Optimisations de l’autonomie des portables Changements internes APIs asynchrones Automatisation des tests Support natif d’epoll Mise à jour depuis une version précédente Mise à jour de MySQL Lua 5.2 Tutoriels Téléchargement Points importants Si vous êtes impatients d'utiliser 0.11.0, c'est certainement dû au travail important qui a été fait dans cette version sur deux composants : MUC (Multi-User Conference) et PubSub. Ces deux composants implémentent les XEPs les plus complexes que XMPP fournit actuellement. Même si les versions précédentes fournissaient déjà MUC et PubSub, ceux-ci sont tous les deux des protocoles complexes ; ainsi, après une première implémentation, il nous semblait important de les revisiter pour mieux couvrir les fonctionnalités décrites dans les XEPs, mais aussi pour améliorer la structure du code et permettre la montée en charge. Cette version comprend beaucoup d'autres changements, corrections de bugs, amélioration de performances, etc. Les principaux changements sont détaillés ci-dessous. Fonctionnalités principales Amélioration des salons Un des plus gros changements dans cette version est le fait que MUC (Multi-User Conference) ait été presque entièrement réécrit. Ce projet ambitieux a été démarré plusieurs années plus tôt par daurnimator, qui a développé la majorité de ce nouveau code. Même si la plupart des changements restent internes au composant, cela nous a permis d'ajouter de nouvelles fonctionnalités plus facilement, mais aussi de permettre la montée en charge des services de MUC (cette nouvelle version de MUC est utilisée par Jitsi Meet ainsi que d’autres services hébergeant des centaines de milliers de groupes). Les améliorations sont trop nombreuses pour être toutes citées, cependant quelques points sont mis en avant ici. Amélioration de la configuration Le formulaire de configuration a été réorganisé et propose maintenant un agencement et des options plus claires. Nous avons hâte d'intégrer des traductions dans une version future ! Archivage des messages Nous avons ajouté le support pour l'archivage et la récupération des messages envoyés à un salon, en utilisant le protocole de la XEP-0313 (MAM, Message Archive Management). Cela permet à un client d'afficher des messages qui ont été envoyés lorsqu'il était hors-ligne. Réservation du pseudo Pour éviter toute confusion, Prosody peut désormais forcer la réservation de pseudo dans un salon, pour empêcher quelqu’un de se faire passer pour un autre, qui ne serait pas au même moment présent dans le salon. Par défaut, seuls les propriétaires et administrateurs d’un salon peuvent réaliser cette action — en rendant un utilisateur membre du salon —, mais il est aussi possible de le configurer pour autoriser les utilisateurs à enregistrer leur propre pseudo et à devenir membre par la même occasion. Protocole PubSub Notre implémentation de PubSub a beaucoup été améliorée pour cette version. Link Mauve a travaillé sur la persistance des nodes et des items, ce qui veut dire que les données peuvent être stockées sur le disque plutôt qu’en mémoire et ne seront donc plus perdues lorsque le serveur est relancé. Nous avons également implémenté la configuration des nodes et la gestion des affiliations, nécessaires à un contrôle d’accès avancé. Et finalement, nous avons ajouté le fameux publish-options qui permet aux clients de publier des items en spécifiant leurs droits d’accès de façon sécurisée. PEP Notre ancien code pour PEP était une implémentation minimale, séparée du code de PubSub, qui implémentait tout ce dont les clients avaient besoin en 2009. De plus en plus de fonctionnalités de PubSub ont été demandées au fil des années pour PEP, qui devenait de plus en plus utilisé. Il devenait évident que PEP devait fournir toutes les fonctionnalités de PubSub et aurait dû utiliser le même code. Florian Zeitz a démarré ce projet en créant un nouveau module mod_pep_plus. Ce module est maintenant l'implémentation par défaut et est utilisé à la place du module mod_pep d’origine. Ceci nous permet de prendre en charge OMEMO pour les gens n’étant pas dans votre liste de contacts. Ça permet aussi aux clients d’utiliser PEP pour stocker les marque-pages et autres données. Nouveau format de vCard Cette version implémente la nouvelle version de la spécification vCard (vCard4), décrite dans la XEP-0292, et supporte de nombreux nouveaux champs. Votre vCard est aussi stockée dans PEP, ce qui autorise un contrôle d'accès avancé (par exemple vous pouvez choisir que votre vCard soit publique, ou disponible uniquement pour vos contacts). Peu de clients, voire même aucun, ne supporte vCard4, mais l’ancien protocole vcard-temp est toujours supporté en utilisant mod_vcard_legacy, qui traduit vers le nouveau format de manière transparente, jusqu’à ce que les clients se mettent à jour. Optimisations de l’autonomie des portables Cette version vient avec quelques modules communautaires visant à améliorer l’autonomie des clients mobiles. Un traffic constant peut empêcher un téléphone de passer en mode d’économie d’énergie, par exemple avec les changements de statut des contacts, ou beaucoup de messages des salons. Mais ces informations ne sont généralement pas importantes, surtout quand le téléphone est en veille ou que l’application est en arrière-plan. Les clients qui prennent en charge la XEP-0352, tel que Conversations, peuvent informer le serveur quand leur application est mise en arrière-plan, et Prosody va réagir en optimisant le traffic sur la connexion. Ceci est implémenté dans mod_csi_simple. Changements internes APIs asynchrones Nous avons consacré beaucoup d'efforts à ajouter des tests et à rendre notre API asynchrone interne plus robuste. Cette API sera utilisée pour améliorer les performance des plus gros services. Avec ces changements, l’authentification ou les plugins de stockage asynchrones sont maintenant supportés de façon expérimentale. Prosody ne supportera pas cette API officiellement pour cette version car il reste beaucoup de changements prévus. Automatisation des tests Une des plus grosses améliorations récentes au projet a été le nombre croissant de tests automatisés. Les versions précédentes ont été presque entièrement testées à la main, à cause du peu de tests automatiques disponibles, mais nous avons désormais une large batterie de tests qui tourne après chaque changement. Plus de détails dans un futur article ! Support natif d’epoll Ce nouveau backend réseau expérimental fournit une alternative à libevent. Parmi ses avantages, il est plus petit et plus simple, mais disponible uniquement sous Linux. Mise à jour depuis une version précédente Si vous mettez à jour depuis une version précédente, nous vous recommandons très fortement de lire les notes de version. Quelques changements importants sont listés ici. Mise à jour de MySQL Les utilisateurs de MySQL doivent mettre à jour leur schéma avant que Prosody 0.11 puisse fonctionner. Ceci afin de corriger quelques bugs qui empêchent le bon fonctionnement des nouvelles fonctionnalités de PEP. Après la mise à jour, exécutez : prosodyctl mod_storage_sql upgrade Lua 5.2 Prosody dépend de Lua 5.1 depuis le tout début. Comme nous l’avons annoncé lorsque Prosody 0.10 est sorti, nous sommes en train de le mettre à jour vers des versions de Lua plus récentes. La version de Lua recommandée pour Prosody 0.11 est Lua 5.2, mais Lua 5.1 est toujours compatible pour les plates-formes qui en ont besoin. Cependant, les versions 0.11.x sont les dernières versions à être compatibles avec Lua 5.1 (et par extension, LuaJIT). Tutoriels Si vous prévoyez d’installer Prosody pour la première fois, le Homebrew Server Club a publié un excellent tutoriel sur comment configurer un serveur XMPP moderne sur Debian, en utilisant Prosody 0.11. Téléchargement Comme d’habitude, vous pouvez trouver les instructions de téléchargement pour de nombreuses plates-formes sur notre page de téléchargement. Si vous avez des questions, commentaires ou problèmes quelconques avec cette version, dites-le nous ! Télécharger ce contenu au format Epub Commentaires : voir le flux atom ouvrir dans le navigateur

group_work LinuxFRNews 22 Novembre