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.
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).
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.
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).
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.
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 ?
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 :-)
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.
À la place d'Ansible, un autre outil du même genre très utilisé est Puppet.
Ansible peut faire aussi de l'orchestration dans un data center, par exemple pour faire une migration impliquant plusieurs serveurs (exécuter les tâches de manière coordonnée, dans le bon ordre).
Ansible permet d'automatiser des tâches d'administration système. Ce qui inclut pouvoir exécuter une même commande sur plusieurs machines en même temps.
Je compte peut-être écrire bientôt un journal sur Kickstart et Ansible, j'ai appris ces deux technologies récemment et ça change vraiment la vie (par rapport à faire des installations et configurations manuellement).
Ben c'est un acronyme (GNU Network Object Model Environment si je ne m'abuse)
Ça fait longtemps que l'acronyme ne colle plus avec ce que fait le projet GNOME.
GNOME est parfois écrit Gnome, par exemple dans ce vieux livre: GTK+/Gnome Application Development (écrit par Havoc Pennington, un des premiers développeurs GNOME).
Miguel de Icaza (un des deux créateurs de Gnome) écrit aussi Gnome « Gnome ». Par exemple dans cet article (mais il faut dire que Miguel de Icaza ne contribue plus à GNOME, il s'est tourné vers C#/Mono).
Je suis actuellement sous Xfce depuis peu pcq gnome-shell était trop instable (freezes), et un des trucs que je regrette de GNOME est gnome-control-center. Je trouve que le control center de GNOME est vraiment bien comparé à l'équivalent pour Xfce.
Je n'ai pas non plus d'ordinateur avec un écran tactile, mais je sais que Red Hat a fourni beaucoup d'efforts ces dernières années pour supporter le touch. Dans GTK+, dans gnome-shell, dans libinput, le kernel etc.
This is another item we have put significant effort into. Over the last few years we made sure that we went from almost no touch support in the desktop to now supporting touch throughout the stack.
Je sais aussi que Red Hat travaille de temps en temps pour le support des tablettes. Certains développeurs GNOME arrivent à installer GNOME sur des tablettes, d'ailleurs, et ça marche plus ou moins (même si c'est loin d'être parfait).
Si ça tombe le projet de convergence qu'avait Canonical avec Unity 8, ce même projet est faisable avec GNOME 3. Il faut bien avouer que l'interface de GNOME 3 pourrait convenir sur une tablette, et pourquoi pas sur un smartphone ou une télé également.
Dans le marché du cloud sous Linux, il y a déjà deux gros acteurs : Red Hat et SUSE. Il faudra voir, mais mon avis personnel est que Canonical ne saura pas faire le poids face à ces gros concurrents, en tout cas pas sur le long terme. Mais bon, je peux me tromper.
Pour l'IoT tout peut encore être joué, je dirais.
J'avais discuté un peu il y a quelques années avec un employé Canonical, il avait dit que si Ubuntu phone ne fonctionnait pas, ce serait fini pour Canonical. Le changement de focus vers le cloud et l'IoT n'est peut-être qu'une mesure pour retarder la faillite de Canonical, mais en réalité ils n'ont peut-être pas beaucoup d'espoir que ça marche.
Seul le temps nous dira ce qu'il en est… Peut-être que dans 10 ans Canonical n'existera plus. C'est en tout cas une des possibilités.
Pour un historique détaillé de la relation entre Canonical et GNOME, aux débuts de GNOME 3 et Unity (en 2011), lire cette série d'articles de Jeff Waugh.
Bref, si Canonical était déjà critiqué en 2008 pour son manque de collaboration upstream, ça ne s'était pas amélioré en 2011. C'est vrai que Canonical est une petite entreprise par rapport à Red Hat ou Novell/SUSE, donc ils ne savent pas contribuer autant, mais ils avaient les moyens de contribuer plus upstream au lieu de tout développer dans leur coin (avec un CLA qui plus est).
S'ils prennent tous les composants upstream sans modification, c'est juste du travail de packaging, et Debian l'a déjà fait, donc ça ne devrait pas être trop de boulot. Mais il y a le liveCD/USB à adapter, avec l'installeur. Ça ça demandera sûrement plus de boulot.
Reste à voir s'ils veulent modifier gnome-shell avec des extensions comme le fait la session GNOME Classic. Je sais que SUSE par exemple a modifié GNOME Classic pour n'avoir qu'une seule barre en bas.
Et quid de leur partenariat avec Amazon? Vont-ils implémenter la même chose dans la recherche de gnome-shell? (je suppose que ça rapporte à Canonical du financement).
[^] # Re: Vivement la suivante
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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.
# GNOME 3.14 et 3.22 dans RHEL aussi
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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).
[^] # Re: euh...
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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.
[^] # Re: GNU parallel
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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.
[^] # Re: Release rapide
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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).
[^] # Re: GIMP
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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.
[^] # Re: GIMP
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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.
# GIMP
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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 ?
[^] # Re: Devops
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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 :-)
[^] # Re: Preseed
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 1.
Merci, c'est bon à savoir.
[^] # Re: Devops
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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.
# Mauvais lien vers le whitepaper
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 1.
J'ai été trop vite et je me suis trompé de lien pour le whitepaper, je ne savais pas qu'il y avait en fait plusieurs whitepapers.
Celui dont je voulais parler était Ansible in depth.
# Quelques infos en plus
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 5.
Le journal étant déjà assez long, je n'ai pas expliqué tout ce que je voulais initialement.
[^] # Re: Ansible
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Présentation du multiplexer de sessions ssh cssh_tmux. Évalué à 2.
Voilà j'ai écrit ce journal :
Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux
[^] # Re: Ansible
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Présentation du multiplexer de sessions ssh cssh_tmux. Évalué à 3.
Ansible permet d'automatiser des tâches d'administration système. Ce qui inclut pouvoir exécuter une même commande sur plusieurs machines en même temps.
Je compte peut-être écrire bientôt un journal sur Kickstart et Ansible, j'ai appris ces deux technologies récemment et ça change vraiment la vie (par rapport à faire des installations et configurations manuellement).
# Ansible
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Présentation du multiplexer de sessions ssh cssh_tmux. Évalué à 3.
Ou utiliser Ansible ou un autre outil du même genre.
[^] # Re: GNOME en minuscule
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au sondage Quel est votre environnement de bureau préféré ?. Évalué à 2.
Ça fait longtemps que l'acronyme ne colle plus avec ce que fait le projet GNOME.
GNOME est parfois écrit Gnome, par exemple dans ce vieux livre: GTK+/Gnome Application Development (écrit par Havoc Pennington, un des premiers développeurs GNOME).
Miguel de Icaza (un des deux créateurs de Gnome) écrit aussi Gnome « Gnome ». Par exemple dans cet article (mais il faut dire que Miguel de Icaza ne contribue plus à GNOME, il s'est tourné vers C#/Mono).
[^] # Re: Unity is the best
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au sondage Quel est votre environnement de bureau préféré ?. Évalué à 2.
Une usine à gaz ? GNOME a souvent été critiqué pour avoir retiré des fonctionnalités.
Pour le moment dans le sondage, c'est GNOME 3 qui est en tête, donc ça veut dire que ça convient quand même à pas mal de personnes.
[^] # Re: XFCE
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au sondage Quel est votre environnement de bureau préféré ?. Évalué à 3.
Je suis actuellement sous Xfce depuis peu pcq gnome-shell était trop instable (freezes), et un des trucs que je regrette de GNOME est gnome-control-center. Je trouve que le control center de GNOME est vraiment bien comparé à l'équivalent pour Xfce.
[^] # Re: Révolution digitale
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal GNOME 3.24. Évalué à 1.
Je n'ai pas non plus d'ordinateur avec un écran tactile, mais je sais que Red Hat a fourni beaucoup d'efforts ces dernières années pour supporter le touch. Dans GTK+, dans gnome-shell, dans libinput, le kernel etc.
Voir cet article de Christian Schaller :
Je sais aussi que Red Hat travaille de temps en temps pour le support des tablettes. Certains développeurs GNOME arrivent à installer GNOME sur des tablettes, d'ailleurs, et ça marche plus ou moins (même si c'est loin d'être parfait).
Si ça tombe le projet de convergence qu'avait Canonical avec Unity 8, ce même projet est faisable avec GNOME 3. Il faut bien avouer que l'interface de GNOME 3 pourrait convenir sur une tablette, et pourquoi pas sur un smartphone ou une télé également.
[^] # Re: Test de Recipe (et de flatpak)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal GNOME 3.24. Évalué à 2.
Oui ton retour d'expérience serait utile pour les développeurs.
Tous les bugs/demandes de fonctionnalités sont là :
https://bugzilla.gnome.org/page.cgi?id=browse.html&product=recipes
Les plans de développement sont là :
https://wiki.gnome.org/Apps/Recipes/Development
[^] # Re: Audit externe et nouveaux investisseurs
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Vers une réduction des effectifs chez Canonical ?. Évalué à 1.
Dans le marché du cloud sous Linux, il y a déjà deux gros acteurs : Red Hat et SUSE. Il faudra voir, mais mon avis personnel est que Canonical ne saura pas faire le poids face à ces gros concurrents, en tout cas pas sur le long terme. Mais bon, je peux me tromper.
Pour l'IoT tout peut encore être joué, je dirais.
J'avais discuté un peu il y a quelques années avec un employé Canonical, il avait dit que si Ubuntu phone ne fonctionnait pas, ce serait fini pour Canonical. Le changement de focus vers le cloud et l'IoT n'est peut-être qu'une mesure pour retarder la faillite de Canonical, mais en réalité ils n'ont peut-être pas beaucoup d'espoir que ça marche.
Seul le temps nous dira ce qu'il en est… Peut-être que dans 10 ans Canonical n'existera plus. C'est en tout cas une des possibilités.
[^] # Re: Video App ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal GNOME 3.24. Évalué à 10.
Blender, GIMP et Inkscape :
https://blogs.gnome.org/bastian/2017/04/08/insights-into-the-gnome-3-24-release-video/
[^] # Re: Bon choix
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 3.
Pour un historique détaillé de la relation entre Canonical et GNOME, aux débuts de GNOME 3 et Unity (en 2011), lire cette série d'articles de Jeff Waugh.
Bref, si Canonical était déjà critiqué en 2008 pour son manque de collaboration upstream, ça ne s'était pas amélioré en 2011. C'est vrai que Canonical est une petite entreprise par rapport à Red Hat ou Novell/SUSE, donc ils ne savent pas contribuer autant, mais ils avaient les moyens de contribuer plus upstream au lieu de tout développer dans leur coin (avec un CLA qui plus est).
[^] # Re: Un an après Mozilla
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 1.
S'ils prennent tous les composants upstream sans modification, c'est juste du travail de packaging, et Debian l'a déjà fait, donc ça ne devrait pas être trop de boulot. Mais il y a le liveCD/USB à adapter, avec l'installeur. Ça ça demandera sûrement plus de boulot.
Reste à voir s'ils veulent modifier gnome-shell avec des extensions comme le fait la session GNOME Classic. Je sais que SUSE par exemple a modifié GNOME Classic pour n'avoir qu'une seule barre en bas.
Et quid de leur partenariat avec Amazon? Vont-ils implémenter la même chose dans la recherche de gnome-shell? (je suppose que ça rapporte à Canonical du financement).