swilmet a écrit 647 commentaires

Oui, il y a tout à fait moyen de faire du semi-orienté objets en C « normal », et du vrai orienté objets avec un object system comme GObject.

En C pur, une classe est une structure. Pour créer un objet (l'instance d'une classe), on alloue dynamiquement la structure. La variable self est un simple pointer, qu'on passe en premier argument à chaque fonction. Pour faire du polymorphisme, on peut créer sois-même une vtable, c'est-à-dire une structure contenant des pointeurs de fonctions.

Avec un object system, on peut faire plus de choses facilement, comme avoir des interfaces, des classes abstraites, l'héritage, etc. Mais en C ça demande un peu de « code de remplissage » (boilerplate), puisque la syntaxe du C n'est pas prévue pour ça.

… Et pas de top posting, SVP !

Sur le site web de LibreOffice, deux versions sont proposées : LibreOffice Fresh (dernière version stable) et LibreOffice Still (avant-dernière version stable). La Still est censée être plus stable, puisqu'il y a eu plus de corrections de bugs.

Pour une utilisation professionnelle, c'est à mon avis une meilleure idée de prendre LibreOffice Still.

Ceux qui utilisent Ardour ont généralement aussi acheté du matériel audio qui coute beaucoup plus cher. Payer 1$ par mois doit être à la portée de ces gens-là ;-)

Dans le live

Non tu dois lancer ces commandes en démarrant sur le Linux installé, pour que ton utilisateur existe. Ou bien, depuis le live, tu dois connaitre le user ID (un numéro) utilisé dans ton installation, ce qui est plus compliqué.

Oui pour le partitionnement c'est mieux d'avoir une partition /home séparée. Chez moi, je fais toujours :

• /dev/sda1 monté sur / (la racine), entre 20 et 30 GB
• /dev/sda2, la swap (un peu plus grand que la taille de la RAM suffit, pour pouvoir hiberner par exemple)
• /dev/sda3 monté sur /home, prenant le reste du disque dur

Pour un dual boot il faut créer des partitions étendues (des partitions pouvant contenir d'autres partitions).

$ ls -lad .mozilla/
ou (si on oublie que le paramètre -d existe, comme moi) :
$ ls -la | grep mozilla

$ man chmod
$ man chown

Par exemple :
$ chown user:user .mozilla/
(remplace « user » par le nom de ton utilisateur)
(tu dois sans doute faire tourner la commande chown avec sudo)

Pour changer l'utilisateur et le groupe de tous les fichiers se trouvant dans .mozilla, récursivement :
$ chown -R user:user .mozilla/
(c'est mieux de faire un backup avant, au cas où certains fichiers doivent avec un autre utilisateur ou groupe)

Un bon livre sur Unix, pour apprendre les bases d'un système Unix comme GNU/Linux.

Tu n'as peut-être plus les bonnes permissions sur le dossier ~/.mozilla.
Si tu ouvres un terminal, que donne la sortie de :
$ ls -la

(Regardes juste pour le dossier .mozilla).

Lien wikipédia sur les permissions UNIX.

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.