Sébastien Wilmet a écrit 714 commentaires

Comme tu n'as pas le bug sous Fedora, c'est sans doute un problème chez Debian. Est-ce que Debian a la dernière version upstream des modules GNOME ? Regarde par exemple GTK+, Nautilus et gnome-shell. Tu peux voir les dernières versions upstream sur git.gnome.org (regardes les tags).

Oui Wayland n'est pas encore tout à fait stable. Sur Fedora 22 l'écran de login (GDM) tourne sous Wayland, mais pas encore la session (par défaut).

Je ne connais pas bien l'état de GNOME dans Debian, mais sous Fedora il est possible de choisir le type de session dans GDM : GNOME, GNOME Classic et GNOME sous Wayland. La dépendance à Wayland vient peut-être de là, si c'est comme ça chez Debian aussi.

Le rapport de bug est pour Wayland. C'est plus probable que tu utilises X11.

Sinon, tu peux tester un live-usb d'une autre distrib proposant GNOME 3.16, pour voir si le problème est lié à la config/packaging dans Debian ou bien si c'est un problème upstream. Fedora Workstation 22 propose GNOME 3.16 par exemple.

Beaucoup de développeurs sous Linux utilisent un Lenovo ThinkPad (j'ai remarqué ça en allant à des conférences comme le FOSDEM ou le GUADEC (conférence GNOME)). Ce sont des bons ordis, bien supportés sous Linux.

Pour ma part je préfère ceux avec une carte graphique Intel, au moins je suis sûr qu'elle fonctionne vraiment bien sous Linux, pcq Intel contribue énormément au noyau Linux (avec Red Hat, ils sont dans le top 3 des entreprises qui contribuent le plus à Linux, et ce depuis de nombreuses années).

Chez moi les trois étapes sont les mêmes. Je ne savais pas que le dual-boot était possible, donc j'ai écrasé Windows (en 2005, avec une Mandrake). Et depuis, je suis resté sous Linux exclusivement (à part une FreeBSD à un moment).

Avoir un dual-boot, c'est tricher ;)

Le passage de Mozilla à Firefox, ça a été de supprimer plein de fonctionnalités, et de les transformer sous forme de plugins pour certaines. Par contre du refactoring de code, ça ne change rien à l'aspect extérieur du logiciel, ça améliore juste le design interne.

Il peut y avoir aussi des problèmes avec les rolling releases.

Je réinstalle aussi toujours à partir d'un live USB. Je me suis fais un petit script de post-installation, plus 2 ou 3 étapes manuelles qui ne prennent pas beaucoup de temps. Au moins ça marche à chaque fois, et je suis sûr que mon système est « propre ». Quand j'installe un paquet, je le rajoute dans ma liste de paquets à installer dans le script. Avant de réinstaller, je nettoie ma liste de paquets en enlevant ce que je n'ai plus besoin.

Sur ma machine perso j'utilise Fedora 22 depuis la beta, et j'ai eu très peu de problèmes.

À mon boulot j'utilise Fedora sans problème aussi.

Fedora est assez prompt à faire les mises à jour, par exemple les versions 3.16.x de GNOME. Ubuntu ne met pas toujours à jour les versions des modules de GNOME. Certains modules restent en 3.14.0 alors que les développeurs ont sorti les versions 3.14.1 et 3.14.2 qui corrigent des bugs important (j'ai vu ça dans Debian aussi). Aussi, Ubuntu mélange les versions des modules de GNOME : certains modules sont en 3.14, d'autres sont en 3.12, d'autres sont encore plus ancien… ce qui engendre pas mal d'autres bugs. Et aussi, depuis plusieurs années, Ubuntu ne prend pas la dernière version de GNOME, mais la précédente.

Ce qui aide aussi dans Fedora est que bon nombre de packageurs sont aussi les développeurs/mainteneurs en amont. Donc ils savent comment bien intégrer leurs logiciels dans la distrib.

L'accélération du touchpad fonctionne très bien chez moi, avec libinput. Je n'ai rien du faire de spécial.

Abonne-toi au flux RSS de LWN, les annonces de RC y sont toujours, et il y a plein d'autres articles intéressants.

Utilise libpeas pour les plugins, c'est ce qui est utilisé dans gedit et d'autres applications de GNOME (libpeas provient du code de gedit à la base).

Mais, avoir un système de plugin rajoute beaucoup d'emmerdes pour le développement d'une application. Il faut que l'application définisse une API que les plugins pourront utiliser. Et, si possible, cette API ne doit pas être cassée à chaque version… Comme pour le développement d'une librairie, en gros. Avec l'age, n'importe quel code a besoin d'être restructuré un jour ou l'autre, et maintenir la compatibilité des plugins est parfois difficile et demande en tout cas plus de boulot.

De plus les plugins rajoutent de l'incertitude dans la stabilité de l'application. Toi, étant développeur de l'éditeur de texte, tu veux être certain que l'application soit stable, qu'il n'y ait pas de bugs. Avec des plugins, il peut y avoir plein de bugs imprévus. Les plugins sont généralement moins bien écrit et contiennent plus de bugs que le cœur de l'application (pcq développé par des gens moins expérimenté). Un cassage de l'API ne fait qu’aggraver les choses. Et les bugs ne sont pas forcément isolé à la fonctionnalité qu'un plugin fourni, un plugin peut faire apparaitre des bugs dans d'autres fonctionnalités. Et quand un utilisateur a plein de bugs et qu'il n'en connait pas vraiment la cause, il se dit que l'application est pourrie et va voir ailleurs.

Donc… je ne recommande pas vraiment les systèmes de plugins. En tout cas certainement pas pour une jeune application dont l'architecture du code doit encore évoluer.

Ceci dit, pour en revenir à libpeas, ça utilise sous le capot dlopen(), pour charger des shared libraries au runtime. Un plugin est donc une sorte de librairie.

Quelques précisions.

Le mode setting, c'est le réglage de l'écran dans un certain mode (résolution, nombre de couleurs, fréquence de rafraichissement). Avec un mode setting atomique, les paramètres sont tous changés en même temps, ce qui devrait régler le problème des bugs graphiques quand on passe d'un mode à l'autre (quand on démarre ou éteint l'ordinateur, quand on lance une application graphique en plein écran, etc).

Bref, c'est assez génial cet Atomic Mode Setting !

Cool, un autre éditeur de texte basé sur GtkSourceView.

Sache qu'il y a le projet libgedit (dont je suis l'initiateur), qui vise à rendre le code de gedit réutilisable pour d'autres éditeurs de texte, en bougeant les fonctionnalités dans GtkSourceView notamment.

Pcq, tu as sans doute pu le remarquer, écrire un éditeur de texte from scratch avec GtkSourceView demande quand même pas mal de boulot, pour avoir une éditeur de texte convenable. gedit fait 40k lignes de code plus ou moins (sans les plugins), donc il reste encore du refactoring à faire ;-)

Les Autotools ne sont pas obsolètes… Ça a l'avantage d'être un standard, tant pour les packageurs que pour les utilisateurs qui veulent compiler les sources (le fameux ./configure, make, make install). Si chaque projet utilise un build system différent, ce serait un vrai casse-tête. CMake (je ne connais pas Scons) ne suit même pas les GNU Coding Standards, il n'y a par exemple pas de make uninstall de base (ou alors ça a changé depuis la dernière fois que je l'ai utilisé).

J'ai écris sur ce sujet un peu plus longuement sur mon blog, où je suis passé de CMake aux Autotools pour LaTeXila.

Le fichier /etc/centos-release contient le numéro de version 7.1.1503.
Autre référence, l'article CentOS sur Wikipédia utilise comme numérotation 7.1-1503.

C'est beaucoup plus simple de se référer à la version équivalente chez RHEL, c'est-à-dire « 7.1 ». Je ne vois pas pourquoi les mails d'annonce n'utilisent pas cette numérotation.

En tout cas c'est tout à fait valide de dire « CentOS 7.1 » (version raccourcie). Le fichier /etc/centos-release peut très bien servir de référence, tout autant que les mails d'annonce.

La mise à jour s'est très bien passée pour moi, avec un simple yum update. Mais je n'avais « que » entre 400 et 500 paquets à mettre à jour (je n'ai pas installé beaucoup de paquets en plus sur cette machine, c'est presque comme l'installation de base, en workstation).

Dans le premier, ils ont annoncé qu'ils allaient mettre en Open Source une fois un montant atteint.

Ben voilà, il me semblait bien.

Si je me rappelle bien le concept du Humble Indie Bundle, ils ouvrent le code source et rendent les jeux gratuits une fois qu'une certaine somme est atteinte. Tant que cette somme n'est pas atteinte, ce sont des logiciels propriétaires, juste ?

Étant donné que les Humble Indie Bundles ont beaucoup de succès, je suppose que certains jeux ont été libéré, non ?

La dernière fois que j'ai cherché à télécharger un de ces jeux, c'était vraiment la galère et j'ai finalement pas trouvé… Ils ne sont pas disponible de base ni dans Fedora ni dans Debian à ce que je sache.

Y a-t-il une page quelque part avec les jeux qui ont été libéré ? Mais peut-être que je suis complètement à côté de la plaque.

Ou comment réinventer la roue… Toutes les applications GNOME sont déjà passées à GTK+ 3 depuis belle lurette. Étant donné que Mate est un clone de GNOME 2, les développeurs de Mate devront faire exactement le même travail pour porter les applications à GTK+ 3…

Ce serait plus malin pour Mate de continuer à maintenir metacity, gnome-panel, gnome-applets et quelques autres modules qui vont avec. Bref, juste le desktop, pas les applications ni les librairies.

Dans LaTeXila il y a un menu Math avec les commandes principales, plus de nombreux symboles dans le panneau latéral. La complétion peut aider aussi un peu.

Pour ma part, j'ai appris grâce au livre LaTeX par la pratique de Christian Rolland, mais je pense qu'il n'est plus en vente (à part d'occasion).

Mais il y a de nombreux autres livres sur LaTeX, par exemple celui de la collection Framabook (sous licence libre): Tout ce que vous avez toujours voulu savoir sur LaTeX sans jamais oser le demander, de Vincent Lozano.

Un éditeur LaTeX avec interface graphique a quand même des avantages :

• la structure du document dans le panneau latéral pour pouvoir naviguer rapidement dans le document, et avoir une vue d'ensemble ;
• ne pas à connaitre des centaines de noms pour les symboles mathématiques et autres ;
• une bonne auto-complétion (si ce n'est pas disponible dans Vim).

Non, Fedora prend toujours la dernière version de GNOME, il n'y a pas de retard.

Pour le matériel, il n'y a pas plus de détails.

Et puis entre-temps on a inventé… l'écriture ! Dingue ça.

Autre livre très intéressant :

Concepts, Techniques, and Models of Computer Programming

Avec un seul langage (Oz), le livre couvre tous les principaux paradigmes/modèles : declarative/functional programming, declarative concurrency, message-passing concurrency, explicit state (programmation impérative), object-oriented, shared-state concurrency, relational programming, GUI programming, distributed programming, constraint programming, et autres buzzword.

Voir aussi cette page de Peter Norvig (qui travaille chez Google, et a co-écrit Le livre sur l'intelligence artificielle) :

Teach Yourself Programming in Ten Years

Même si le langage Oz n'est pas très connu, le livre est surtout un outil pédagogique. Une fois qu'on a appris pas mal de paradigmes différents, on peut choisir un language plus répandu qui est spécialisé dans le paradigme qui convient pour un certain projet. Mais cela dit, c'est un avantage d'avoir un seul langage qui supporte plusieurs paradigmes, comme ça pour des projets un peu plus gros, on peut mélanger plusieurs paradigmes tout en gardant la même syntaxe. En gros on choisit le paradigme le plus approprié suivant le besoin.