Scintilla se situe au niveau de GtkTextView + GtkSourceView, mais il y a des différences dans les fonctionnalités fournies. Je pense que GtkTextView est meilleur pour l'internationalisation (bon support d'Unicode, texte de droite à gauche etc, grâce à Pango). Je pense que GtkSourceView a une meilleure recherche et remplacement (incluant la recherche par regex, c'était mon sujet de GSoC). Scintilla a le code folding, …
Pour écrire une appli en GTK, l'API de GtkSourceView sera plus familière au développeur pcq ce sont des classes GObject comme tous les widgets GTK. Scintilla a une API un peu étrange je trouve, mais c'est peut-être pcq je ne suis pas habitué. Je trouve la documentation de Scintilla assez horrible, en comparaison GtkSourceView est documenté avec gtk-doc ce qui permet de l'ouvrir avec Devhelp. Enfin bon, je suis évidemment biaisé.
Scintilla a des backends pour différents toolkits : GTK+, Qt, pour Windows, etc. Et GTK+ lui-même (ou plutôt GDK pour être plus précis) a lui aussi des backends pour différentes plateformes : Wayland, X11, Windows, Mac, etc. GtkSourceView utilise directement GTK+, donc il n'y a qu'une seule couche de backend.
Mais là où ça devient intéressant du côté de GtkSourceView est le framework dans Tepl, qui fournit des APIs de plus haut niveau (ça utilise par exemple GtkApplication, GtkApplicationWindow, GtkNotebook), ce que Scintilla ne sait pas faire. J'ai bon espoir qu'en 1000 lignes de code il soit possible d'écrire un éditeur de texte basique comme gedit (sans les plugins), tandis qu'avec Scintilla ça demande je pense beaucoup plus de boulot (comme c'est le cas actuellement si on utilise seulement GtkSourceView). Mais bon il y a encore du boulot dans Tepl, mais à ce stade-ci je pense que le reste qu'il y a à faire est entièrement faisable (1% inspiration, 99% transpiration, là je pense être à 50% de transpiration ;-).
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Comme ce commentaire et celui-ci dans le bugzilla l'indique, il n'est pas prévu de rendre gnome-shell sous Wayland crashproof, en tout cas pas à court terme. Matthias Clasen est un des managers de l'équipe desktop chez Red Hat, et gnome-shell/mutter est développé en très grande partie par Red Hat.
Mais à long terme, il y a peut-être de l'espoir, en lisant ce commentaire d'un des développeurs de gnome-shell/mutter.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
À la sortie de GNOME 3.0, il y a eu beaucoup d'utilisateurs de GNOME 2 qui n'étaient pas satisfait, le paradigme du bureau avait fort changé, il fallait changer ses habitudes (ou changer d'environnement de bureau), etc.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Pour apprendre GLib/GTK+, je te conseille de lire ce guide que j'ai écrit.
Pour apprendre à contribuer à un logiciel libre, ce vieux article d'un ancien développeur GNOME est intéressant. Sinon il suffit de lire le fichier README, HACKING (ou CONTRIBUTING), et ce genre d'autres fichiers TOUT_EN_MAJUSCULE.
Pour GtkSourceView et Tepl, ce sont des bibliothèques donc il n'y a pas de fonction main() comme point d'entrée, chaque fonction publique est un point d'entrée. Tout est bien documenté, donc en ouvrant la doc avec Devhelp, il ne devrait pas y avoir de soucis à apprendre l'API (une fois que tu connais suffisamment bien GLib et GTK+).
Mais développer une bibliothèque est plus difficile que développer une application, il faut faire attention à l'API. Et il faut que l'API convienne à un maximum d'applications. Il faut choisir une bonne balance entre la simplicité et la flexibilité. L'avantage avec Tepl c'est qu'on peut faire des expérimentations, casser l'API tous les 6 mois, si ce n'est pas parfait du premier coup ce n'est pas grave.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
J'ai un peu d'expérience avec WebKitGTK+ en étant mainteneur de Devhelp, mais je n'ai jamais essayé de créer un éditeur de texte avec WebKitGTK+. En lisant l'article de arstechnica, on se rend compte assez vite que ça devient au final du développement web, avec du HTML, CSS et JavaScript.
Je sais qu'Evolution est passé à WebKitGTK+ pour écrire des mails. Sans doute que ça convient pour ce cas d'utilisation. Mais gitg, qui utilisait WebKitGTK+, est (re?)passé à GtkSourceView (gitg est développé par les mêmes développeurs que gedit/GtkSourceView). Pour gitg, je me rappelle vaguement de la conversation sur IRC, ils disaient que WebKitGTK+ n'était pas vraiment approprié pour ce qu'ils voulaient faire, que l'API n'était pas très pratique, et qu'ils avaient un plus grand contrôle avec GtkTextView/GtkSourceView.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Pour Red Hat Enterprise Linux (RHEL), CentOS et autres dérivés, il y a énormément de documentation en ligne, disponible gratuitement : https://access.redhat.com/documentation/en/
-> puis clique sur "Red Hat Enterprise Linux", il y a alors plein de guides, en particulier "System Administrator's Guide".
Pour l'administration système, je te conseille d'apprendre un outil d'automatisation comme Ansible ou Puppet. J'ai écris ce journal récemment sur ce sujet.
Pour écrire des scripts, je te conseille d'apprendre Python, le code est plus propre qu'avec des scripts shell. De plus en plus d'administrateurs systèmes utilisent Python (au lieu de shell et Perl, principalement).
Bon apprentissage ! Il y a pas mal d'offres d'emploi comme administrateur système Linux.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Sous le capot, est-ce que cette nouvelle version de Firefox utilise davantage de composants écrit en Rust, provenant de Servo ? Autrement dit, est-ce que le projet Quantum avance comme prévu ?
Donc, normalement, ce sera pour bientôt \o/ Mais j'imagine qu'ils ne portent pas Firefox tout d'un coup aux composants de Servo, je suppose que chaque version se rapproche un peu plus du but final. Par exemple Electrolysis (E10S) n'est toujours pas complètement finalisé.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ?
Parce que si par exemple la synchro audio-vidéo est citée comme un plus alors que c'est une fonctionnalité assez basique de jack (même moi, c'est ce que j'utilise le plus; je suis un très faible utilisateur audio avec jack)… Ou alors cette comparaison vient de toi, et pas de ce développeur? :-)
Oui cette comparaison vient de moi, c'était une vraie question. Je ne connais vraiment pas bien Jack.
Le développeur de PipeWire je pense qu'il s'y connait vraiment bien, c'est Wim Taymans, le co-créateur de GStreamer. C'est lui qui a le plus de commits dans GStreamer (en tout cas dans le repo git principal).
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
At the same time we don’t want to make this another painful subsystem transition so PipeWire so we will need to ensure that PulseAudio applications can still be run without modification.
Merci. Je note quand même que ce souci d’éviter de trop grandes souffrances ne concerne que les développeurs d’applications utilisant PulseAudio. Développeurs d’applications Jack, vous allez en chier […]
Ce n'est pas pcq il n'est rien dit au sujet de Jack qu'il faut imaginer que les développeurs d'applications Jack vont en chier… Comme pour PulseAudio, il sera peut-être possible que Jack utilise en interne PipeWire.
PipeWire est un projet encore très jeune, en ce qui concerne les plans pour l'audio pro et Jack, les plans sont encore peut-être flous.
Aussi, Christian Schaller a l'air d'avoir écrit son blog post assez vite, en tout cas il ne s'est pas relu attentivement pcq il y a pas mal de phrases avec des petites erreurs (comme celle ci-dessus). Donc ça ne sert à rien d'essayer d'extrapoler sur des choses qui sont omises dans ce blog post.
Bref, je pense qu'on n'a pas assez d'informations sur PipeWire pour avoir un avis raisonné, en tout cas en ce qui concerne l'audio pro.
Pour ma part, après avoir lu les fichiers README et doc/design.txt (en plus des blog posts de Christian Schaller), PipeWire m'a l'air d'être un projet très prometteur.
Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ? Est-il possible de sandboxer des applications Jack et qu'elles puissent toujours communiquer entre-elles ? PipeWire règle en tout cas ces deux problèmes, avec une solution plus générale, c'est-à-dire qui convient pour n'importe quel flux multimédia (audio et/ou vidéo), pas seulement pour l'audio. Et puisque PipeWire se base en grosse partie sur GStreamer, il y a énormément de code existant qui peut être réutilisé. Je suis sûr que l'équivalent de PulseAudio réécrit dans PipeWire aura beaucoup moins de lignes de code. Réutiliser la même stack multimédia que fournit GStreamer, ça a tout à fait son sens, selon moi.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Je l’utilise pas. Je veux juste que les gens qui veulent utiliser mes logiciels puissent les utiliser.
Ça dépend du contexte dans lequel tu développes tes logiciels, mais tu pourrais peut-être adopter une approche comme font la plupart des modules GNOME:
- sortir une nouvelle version à intervalle régulière.
- ne pas hésiter à utiliser les dernières technologies et versions des bibliothèques, sans garder la compatibilité avec les anciennes versions (donc pas de #if/#else suivant la version d'une bibliothèque, par exemple).
- pour une certaine version d'une certaine distrib, prendre la dernière version du logiciel qui est compatible.
Donc ceux qui sont en Debian stable pourraient installer la version N-1 ou N-2 de tes logiciels. Tout comme Debian stable a actuellement GNOME 3.22 alors que GNOME 3.24 est déjà sorti en amont.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Red Hat Enterprise Linux (RHEL) 7.2 et 7.3 sont sur GNOME 3.14, et pour RHEL 7.4 ce sera GNOME 3.22. Ça tombe bien que Debian ait les mêmes versions, il y a des chances que ce soit plus stable (étant donné que Red Hat fait plus ou moins les 3/4 du boulot dans GNOME).
Aussi, GTK+ 3.22 est et sera la dernière version de GTK+ 3, c'est donc une version LTS.
Bon il faut que les mises à jour arrivent dans Debian, pour la version stable j'ai déjà vu pas mal de paquets GNOME qui n'étaient pas à jour (genre un certain module GNOME en était à la 3.14.4 et Debian stable était toujours à la 3.14.0).
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
J'ai découvert GNU Parallel il n'y a pas très longtemps et je suis aussi conquis.
L'exemple que tu donnes est peut-être un peu compliqué. Un exemple plus simple :
Au lieu de :
for i in *.c;do
ma_commande $idone
L'équivalent avec parallel :
ls *.c | parallel ma_commande
GNU Parallel peut remplacer certaines boucles, ou remplacer l'utilisation de xargs, avec l'avantage que les commandes s'exécutent en parallèle. Le nombre de commandes qui s'exécutent en parallèle dépend du nombre de cœurs du CPU ; dès qu'une commande a fini, la suivante s'exécute.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Je suis interpellé par ta productivité. Je traîne un peu sur les news relatives à gnome, etc, et je ne vois aucune commune mesure entre le rythme rapide avec lequel tu développes lollypop et eolie, et la lenteur avec laquelle le projet Gnome avance
Il y a pas mal de nouvelles applications GNOME écrites en C qui se sont développées rapidement : gnome-software, gnome-builder, gnome-photos, recipes et peut-être quelques autres.
Pour Epiphany, les développeurs s'occupent aussi de WebKitGTK+, donc bon… De manière générale les développeurs GNOME s'occupent aussi des librairies, pas seulement des applications.
Je suis un dev GNOME et je préfère le langage C pour plusieurs raisons:
- le compilateur vérifie plein de trucs à la compilation, tandis qu'en Python on découvre certains problèmes au runtime (par exemple une faute de frappe dans le nom d'une fonction).
- je peux écrire des librairies, documentées avec gtk-doc et les annotations GObject Introspection, comme ça la librairie est utilisable dans plein de langages (dont Python).
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
GNOME est composé de plein de modules. Certains modules sont développés que par une seule personne (plus plein de traducteurs). Il peut y avoir des très grosses différences d'activité d'un module à l'autre, et pourtant il est possible pour la plupart des modules de sortir une nouvelle version tous les 6 mois.
La méthodologie agile est applicable pour toute taille de projet, et pour toute taille de l'équipe et du temps passé sur le projet.
Pour pouvoir sortir une nouvelle version régulièrement, il faut « juste » garder en permanence la branche master dans un état releasable. C'est une bonne pratique en programmation agile. Ça permet de faire du CI/CD (continuous integration/continuous delivery). Et pour un logiciel libre c'est d'autant plus important s'il n'y a pas un grand bus factor, pcq si le développeur principal arrête de contribuer alors qu'il a laissé la branche master dans un état instable, bonne chance pour celui qui reprend le projet.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
C'est chouette d'avoir des nouvelles de GIMP et Pitivi, ces news ne passent pas sur le planet GNOME.
Dans le second lien pour GIMP, je suis content de lire (section "Relaxing The No-New-Features Policy") :
We decided that these features should be disabled in 2.10, but can be added later in the stable branch, if they reach the stable state. This way, we don’t block exciting new features arrival for years, while still being able to ship regular releases. This would make our blocker list much smaller, and we could work in smaller steps.
En effet je trouve ça important de pouvoir sortir des nouvelles versions régulièrement. Pour suivre une méthodologie agile. GNOME arrive bien à sortir une nouvelle version tous les 6 mois, et Firefox toutes les 6 semaines environ. Alors pourquoi pas GIMP ?
GIMP 2.8 est sorti en 2012 (voir l'historique des versions). J'ai l'impression que les développeurs se sont lancés dans un énorme chantier avec GEGL, tout en continuant de rajouter des fonctionnalités. Résultat, la branche master dans git n'est pas dans un état pour sortir une version stable. Est-ce qu'il n'y avait pas moyen de passer petit à petit à GEGL (ou autre chantier d'envergure) tout en gardant la branche master stable ? En ayant certains bouts de code qui utilisent toujours l'ancien système, mélangé avec des fonctionnalités qui utilisent GEGL (comme StranglerApplication expliqué par Martin Fowler).
Jehan, si tu lis ceci, qu'est-ce que tu en penses, toi qui contribue à GIMP ?
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Mais sans les outils la méthodologie serait beaucoup moins praticable.
Je pense qu'on peut dire qu'en général ceux qui font du DevOps sous Linux connaissent bien des outils comme Kickstart, Ansible, Puppet, Docker, etc. Apprendre ces technologies est en quelque sorte un premier pas vers le DevOps. Ça aide en tout cas à décrocher un emploi dans le DevOps, et à avoir des sujets de conversation en commun avec ceux qui font ce boulot :-)
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
Merci. À la base je ne suis pas du tout sysadmin, je suis développeur. Mais je gère un petit serveur web, git, et quelques autres petits trucs. Et je fais de temps en temps une installation d'un desktop pour un PC de labo (mais pas une salle informatique complète).
Avant ça j'étais étudiant, sans serveur, avec mon seul laptop à administrer, donc je n'avais jamais appris Kickstart, Ansible etc. Mais maintenant que je connais Ansible, je vais essayer d'automatiser les tâches de post-installation pour mon PC perso aussi.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Vala
Posté par Sébastien Wilmet (page perso) . En réponse au journal Peek, capture d'écran au plus simple. Évalué à 8.
Les avis sont partagés dans la communauté GNOME :
- Blog post d'Emmanuele Bassi, avis contre
- Blog post de Michael Catanzaro, avis pour (voir la conclusion)
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Scintilla
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 4.
Scintilla se situe au niveau de GtkTextView + GtkSourceView, mais il y a des différences dans les fonctionnalités fournies. Je pense que GtkTextView est meilleur pour l'internationalisation (bon support d'Unicode, texte de droite à gauche etc, grâce à Pango). Je pense que GtkSourceView a une meilleure recherche et remplacement (incluant la recherche par regex, c'était mon sujet de GSoC). Scintilla a le code folding, …
Pour écrire une appli en GTK, l'API de GtkSourceView sera plus familière au développeur pcq ce sont des classes GObject comme tous les widgets GTK. Scintilla a une API un peu étrange je trouve, mais c'est peut-être pcq je ne suis pas habitué. Je trouve la documentation de Scintilla assez horrible, en comparaison GtkSourceView est documenté avec gtk-doc ce qui permet de l'ouvrir avec Devhelp. Enfin bon, je suis évidemment biaisé.
Scintilla a des backends pour différents toolkits : GTK+, Qt, pour Windows, etc. Et GTK+ lui-même (ou plutôt GDK pour être plus précis) a lui aussi des backends pour différentes plateformes : Wayland, X11, Windows, Mac, etc. GtkSourceView utilise directement GTK+, donc il n'y a qu'une seule couche de backend.
Mais là où ça devient intéressant du côté de GtkSourceView est le framework dans Tepl, qui fournit des APIs de plus haut niveau (ça utilise par exemple GtkApplication, GtkApplicationWindow, GtkNotebook), ce que Scintilla ne sait pas faire. J'ai bon espoir qu'en 1000 lignes de code il soit possible d'écrire un éditeur de texte basique comme gedit (sans les plugins), tandis qu'avec Scintilla ça demande je pense beaucoup plus de boulot (comme c'est le cas actuellement si on utilise seulement GtkSourceView). Mais bon il y a encore du boulot dans Tepl, mais à ce stade-ci je pense que le reste qu'il y a à faire est entièrement faisable (1% inspiration, 99% transpiration, là je pense être à 50% de transpiration ;-).
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Est il prévu de rendre la session Wayland "crashproof"
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 3.
Comme ce commentaire et celui-ci dans le bugzilla l'indique, il n'est pas prévu de rendre gnome-shell sous Wayland crashproof, en tout cas pas à court terme. Matthias Clasen est un des managers de l'équipe desktop chez Red Hat, et gnome-shell/mutter est développé en très grande partie par Red Hat.
Mais à long terme, il y a peut-être de l'espoir, en lisant ce commentaire d'un des développeurs de gnome-shell/mutter.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 3.
À la sortie de GNOME 3.0, il y a eu beaucoup d'utilisateurs de GNOME 2 qui n'étaient pas satisfait, le paradigme du bureau avait fort changé, il fallait changer ses habitudes (ou changer d'environnement de bureau), etc.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Double participation
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 5.
Merci pour ta première participation :-)
Pour apprendre GLib/GTK+, je te conseille de lire ce guide que j'ai écrit.
Pour apprendre à contribuer à un logiciel libre, ce vieux article d'un ancien développeur GNOME est intéressant. Sinon il suffit de lire le fichier README, HACKING (ou CONTRIBUTING), et ce genre d'autres fichiers TOUT_EN_MAJUSCULE.
Pour GtkSourceView et Tepl, ce sont des bibliothèques donc il n'y a pas de fonction
main()comme point d'entrée, chaque fonction publique est un point d'entrée. Tout est bien documenté, donc en ouvrant la doc avec Devhelp, il ne devrait pas y avoir de soucis à apprendre l'API (une fois que tu connais suffisamment bien GLib et GTK+).Mais développer une bibliothèque est plus difficile que développer une application, il faut faire attention à l'API. Et il faut que l'API convienne à un maximum d'applications. Il faut choisir une bonne balance entre la simplicité et la flexibilité. L'avantage avec Tepl c'est qu'on peut faire des expérimentations, casser l'API tous les 6 mois, si ce n'est pas parfait du premier coup ce n'est pas grave.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: GtkSourceView vs WebKitGTK+ ?
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 9. Dernière modification le 21/09/17 à 12:57.
J'ai un peu d'expérience avec WebKitGTK+ en étant mainteneur de Devhelp, mais je n'ai jamais essayé de créer un éditeur de texte avec WebKitGTK+. En lisant l'article de arstechnica, on se rend compte assez vite que ça devient au final du développement web, avec du HTML, CSS et JavaScript.
Je sais qu'Evolution est passé à WebKitGTK+ pour écrire des mails. Sans doute que ça convient pour ce cas d'utilisation. Mais gitg, qui utilisait WebKitGTK+, est (re?)passé à GtkSourceView (gitg est développé par les mêmes développeurs que gedit/GtkSourceView). Pour gitg, je me rappelle vaguement de la conversation sur IRC, ils disaient que WebKitGTK+ n'était pas vraiment approprié pour ce qu'ils voulaient faire, que l'API n'était pas très pratique, et qu'ils avaient un plus grand contrôle avec GtkTextView/GtkSourceView.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: un gros morceau
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 2.
J'ai utilisé la commande
apt-cache rdepends <package_name>, pour GtkSourceView 3 et 2. Et récursivement pour les bindings.« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: un gros morceau
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 6.
Pour la complétion des fonctions de math, et peut-être aussi le undo/redo.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
# Quelques références en vrac
Posté par Sébastien Wilmet (page perso) . En réponse au message Se former à l'administration Linux : par où commencer ?. Évalué à 2.
Pour Red Hat Enterprise Linux (RHEL), CentOS et autres dérivés, il y a énormément de documentation en ligne, disponible gratuitement :
https://access.redhat.com/documentation/en/
-> puis clique sur "Red Hat Enterprise Linux", il y a alors plein de guides, en particulier "System Administrator's Guide".
Quelques bouquins :
Pour l'administration système, je te conseille d'apprendre un outil d'automatisation comme Ansible ou Puppet. J'ai écris ce journal récemment sur ce sujet.
Pour écrire des scripts, je te conseille d'apprendre Python, le code est plus propre qu'avec des scripts shell. De plus en plus d'administrateurs systèmes utilisent Python (au lieu de shell et Perl, principalement).
Bon apprentissage ! Il y a pas mal d'offres d'emploi comme administrateur système Linux.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Rust, Servo, projet Quantum
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Firefox 55 est prêt pour la rentrée 2017. Évalué à 2.
Cool, merci pour les infos.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
# Rust, Servo, projet Quantum
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Firefox 55 est prêt pour la rentrée 2017. Évalué à 7.
Sous le capot, est-ce que cette nouvelle version de Firefox utilise davantage de composants écrit en Rust, provenant de Servo ? Autrement dit, est-ce que le projet Quantum avance comme prévu ?
La Roadmap de Firefox indique, dans la catégorie Responsiveness:
Donc, normalement, ce sera pour bientôt \o/ Mais j'imagine qu'ils ne portent pas Firefox tout d'un coup aux composants de Servo, je suppose que chaque version se rapproche un peu plus du but final. Par exemple Electrolysis (E10S) n'est toujours pas complètement finalisé.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Bye
Posté par Sébastien Wilmet (page perso) . En réponse au journal Claude Rich bronsonisé. Évalué à 7.
Désolé.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Leave Jack alone!
Posté par Sébastien Wilmet (page perso) . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 2.
Oui cette comparaison vient de moi, c'était une vraie question. Je ne connais vraiment pas bien Jack.
Le développeur de PipeWire je pense qu'il s'y connait vraiment bien, c'est Wim Taymans, le co-créateur de GStreamer. C'est lui qui a le plus de commits dans GStreamer (en tout cas dans le repo git principal).
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Leave Jack alone!
Posté par Sébastien Wilmet (page perso) . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 4.
Ce n'est pas pcq il n'est rien dit au sujet de Jack qu'il faut imaginer que les développeurs d'applications Jack vont en chier… Comme pour PulseAudio, il sera peut-être possible que Jack utilise en interne PipeWire.
PipeWire est un projet encore très jeune, en ce qui concerne les plans pour l'audio pro et Jack, les plans sont encore peut-être flous.
Aussi, Christian Schaller a l'air d'avoir écrit son blog post assez vite, en tout cas il ne s'est pas relu attentivement pcq il y a pas mal de phrases avec des petites erreurs (comme celle ci-dessus). Donc ça ne sert à rien d'essayer d'extrapoler sur des choses qui sont omises dans ce blog post.
Bref, je pense qu'on n'a pas assez d'informations sur PipeWire pour avoir un avis raisonné, en tout cas en ce qui concerne l'audio pro.
Pour ma part, après avoir lu les fichiers README et doc/design.txt (en plus des blog posts de Christian Schaller), PipeWire m'a l'air d'être un projet très prometteur.
Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ? Est-il possible de sandboxer des applications Jack et qu'elles puissent toujours communiquer entre-elles ? PipeWire règle en tout cas ces deux problèmes, avec une solution plus générale, c'est-à-dire qui convient pour n'importe quel flux multimédia (audio et/ou vidéo), pas seulement pour l'audio. Et puisque PipeWire se base en grosse partie sur GStreamer, il y a énormément de code existant qui peut être réutilisé. Je suis sûr que l'équivalent de PulseAudio réécrit dans PipeWire aura beaucoup moins de lignes de code. Réutiliser la même stack multimédia que fournit GStreamer, ça a tout à fait son sens, selon moi.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Vivement la suivante
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 4.
Ça dépend du contexte dans lequel tu développes tes logiciels, mais tu pourrais peut-être adopter une approche comme font la plupart des modules GNOME:
- sortir une nouvelle version à intervalle régulière.
- ne pas hésiter à utiliser les dernières technologies et versions des bibliothèques, sans garder la compatibilité avec les anciennes versions (donc pas de
#if/#elsesuivant la version d'une bibliothèque, par exemple).- pour une certaine version d'une certaine distrib, prendre la dernière version du logiciel qui est compatible.
Donc ceux qui sont en Debian stable pourraient installer la version N-1 ou N-2 de tes logiciels. Tout comme Debian stable a actuellement GNOME 3.22 alors que GNOME 3.24 est déjà sorti en amont.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
# GNOME 3.14 et 3.22 dans RHEL aussi
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 9.
Red Hat Enterprise Linux (RHEL) 7.2 et 7.3 sont sur GNOME 3.14, et pour RHEL 7.4 ce sera GNOME 3.22. Ça tombe bien que Debian ait les mêmes versions, il y a des chances que ce soit plus stable (étant donné que Red Hat fait plus ou moins les 3/4 du boulot dans GNOME).
Aussi, GTK+ 3.22 est et sera la dernière version de GTK+ 3, c'est donc une version LTS.
Bon il faut que les mises à jour arrivent dans Debian, pour la version stable j'ai déjà vu pas mal de paquets GNOME qui n'étaient pas à jour (genre un certain module GNOME en était à la 3.14.4 et Debian stable était toujours à la 3.14.0).
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: euh...
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Sortie d'it-edit version 3.0. Évalué à 6.
Les noms des projets que je maintiens ont aussi été écorchés :
Ce n'est pas : gtk-sourceview3, Texilla et gspell-1.
C'est : GtkSourceView, LaTeXila et gspell.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: GNU parallel
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche Nouvelles versions logicielles du projet GNU avril et mai 2017. Évalué à 10.
J'ai découvert GNU Parallel il n'y a pas très longtemps et je suis aussi conquis.
L'exemple que tu donnes est peut-être un peu compliqué. Un exemple plus simple :
Au lieu de :
L'équivalent avec parallel :
GNU Parallel peut remplacer certaines boucles, ou remplacer l'utilisation de xargs, avec l'avantage que les commandes s'exécutent en parallèle. Le nombre de commandes qui s'exécutent en parallèle dépend du nombre de cœurs du CPU ; dès qu'une commande a fini, la suivante s'exécute.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Release rapide
Posté par Sébastien Wilmet (page perso) . En réponse au journal Eolie, le petit frère de Lollypop. Évalué à 4.
Il y a pas mal de nouvelles applications GNOME écrites en C qui se sont développées rapidement : gnome-software, gnome-builder, gnome-photos, recipes et peut-être quelques autres.
Pour Epiphany, les développeurs s'occupent aussi de WebKitGTK+, donc bon… De manière générale les développeurs GNOME s'occupent aussi des librairies, pas seulement des applications.
Je suis un dev GNOME et je préfère le langage C pour plusieurs raisons:
- le compilateur vérifie plein de trucs à la compilation, tandis qu'en Python on découvre certains problèmes au runtime (par exemple une faute de frappe dans le nom d'une fonction).
- je peux écrire des librairies, documentées avec gtk-doc et les annotations GObject Introspection, comme ça la librairie est utilisable dans plein de langages (dont Python).
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: GIMP
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche GNOME fête ses 20 ans !. Évalué à 3.
GNOME est composé de plein de modules. Certains modules sont développés que par une seule personne (plus plein de traducteurs). Il peut y avoir des très grosses différences d'activité d'un module à l'autre, et pourtant il est possible pour la plupart des modules de sortir une nouvelle version tous les 6 mois.
La méthodologie agile est applicable pour toute taille de projet, et pour toute taille de l'équipe et du temps passé sur le projet.
Pour pouvoir sortir une nouvelle version régulièrement, il faut « juste » garder en permanence la branche master dans un état releasable. C'est une bonne pratique en programmation agile. Ça permet de faire du CI/CD (continuous integration/continuous delivery). Et pour un logiciel libre c'est d'autant plus important s'il n'y a pas un grand bus factor, pcq si le développeur principal arrête de contribuer alors qu'il a laissé la branche master dans un état instable, bonne chance pour celui qui reprend le projet.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: GIMP
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche GNOME fête ses 20 ans !. Évalué à 3.
En effet, il faudrait que je (re)vienne plus souvent sur LinuxFr. Je n'avais pas vu tous ces articles sur GIMP.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
# GIMP
Posté par Sébastien Wilmet (page perso) . En réponse à la dépêche GNOME fête ses 20 ans !. Évalué à 2.
C'est chouette d'avoir des nouvelles de GIMP et Pitivi, ces news ne passent pas sur le planet GNOME.
Dans le second lien pour GIMP, je suis content de lire (section "Relaxing The No-New-Features Policy") :
En effet je trouve ça important de pouvoir sortir des nouvelles versions régulièrement. Pour suivre une méthodologie agile. GNOME arrive bien à sortir une nouvelle version tous les 6 mois, et Firefox toutes les 6 semaines environ. Alors pourquoi pas GIMP ?
GIMP 2.8 est sorti en 2012 (voir l'historique des versions). J'ai l'impression que les développeurs se sont lancés dans un énorme chantier avec GEGL, tout en continuant de rajouter des fonctionnalités. Résultat, la branche master dans git n'est pas dans un état pour sortir une version stable. Est-ce qu'il n'y avait pas moyen de passer petit à petit à GEGL (ou autre chantier d'envergure) tout en gardant la branche master stable ? En ayant certains bouts de code qui utilisent toujours l'ancien système, mélangé avec des fonctionnalités qui utilisent GEGL (comme StranglerApplication expliqué par Martin Fowler).
Jehan, si tu lis ceci, qu'est-ce que tu en penses, toi qui contribue à GIMP ?
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Devops
Posté par Sébastien Wilmet (page perso) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 2.
Mais sans les outils la méthodologie serait beaucoup moins praticable.
Je pense qu'on peut dire qu'en général ceux qui font du DevOps sous Linux connaissent bien des outils comme Kickstart, Ansible, Puppet, Docker, etc. Apprendre ces technologies est en quelque sorte un premier pas vers le DevOps. Ça aide en tout cas à décrocher un emploi dans le DevOps, et à avoir des sujets de conversation en commun avec ceux qui font ce boulot :-)
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Preseed
Posté par Sébastien Wilmet (page perso) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 1.
Merci, c'est bon à savoir.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)
[^] # Re: Devops
Posté par Sébastien Wilmet (page perso) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 3.
Merci. À la base je ne suis pas du tout sysadmin, je suis développeur. Mais je gère un petit serveur web, git, et quelques autres petits trucs. Et je fais de temps en temps une installation d'un desktop pour un PC de labo (mais pas une salle informatique complète).
Avant ça j'étais étudiant, sans serveur, avec mon seul laptop à administrer, donc je n'avais jamais appris Kickstart, Ansible etc. Mais maintenant que je connais Ansible, je vais essayer d'automatiser les tâches de post-installation pour mon PC perso aussi.
« Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)