Sébastien Wilmet a écrit 713 commentaires

J'ai trouvé ça :
https://wiki.archlinux.org/index.php/Preload

Pour moi le plus gros défaut de Firefox est le temps de lancement.

J'ai bien envie d'essayer de lancer firefox en background quand ma session desktop démarre. Comme ça ouvrir une nouvelle fenêtre Firefox sera quasi instantané.

Si webkit est aujourd'hui plus stable, plus performant et plus frituré que gecko, pourquoi ne pas l'adopter?

Mozilla développe déjà un remplaçant, Servo, écrit en Rust.

Si tu ne sais pas comment fournir plus d'informations, le mieux est de rapporter un bug dans le bug tracker de sa distrib, en demandant comment fournir plus d'informations. Celui qui a créé le paquet de PulseAudio s'y connait surement mieux que toi et pourra te demander l'output de certaines commandes, ou de tester certaines choses. Dans beaucoup de cas, un rapport de bug n'est initialement pas rapporté pour le bon module, le bug se trouve en fait ailleurs.

De manière générale, c'est mieux de rapporter un bug chez sa distrib plutôt que directement en amont, pcq le bug peut venir d'une mauvaise intégration dans la distrib, ou d'un patch. Aussi, le packageur peut déjà faire un premier diagnostic, comme ça quand un bug est rapporté en amont, il y a déjà plus d'informations utiles (et rapporté au bon endroit).

Ou alors inscrit-toi à une mailing list où tu sais qu'il y a des gens qui s'y connaissent bien en PulseAudio. Râler sur LinuxFr ne fera pas avancer les choses (sauf dans certains cas où quelqu'un s'y connait vraiment bien dans un domaine).

Peut-être que PulseAudio a été intégré trop tôt dans les distributions (en tout cas par défaut). Fedora est réputée pour être bleeding-edge, donc c'est le genre de bugs auxquels on peut s'attendre quand un nouveau logiciel assez complexe est intégré dans la distrib. Fedora est généralement une des premières distrib à intégrer ce genre de nouveautés, justement pour tester les choses « en grandeur nature ». Les développeurs s'attendent à recevoir des rapports de bugs s'il y a des problèmes, sinon si chez eux tout fonctionne bien, ces problèmes ne seront jamais corrigés.

Je serais intéressé de savoir si PulseAudio avait aussi pas mal de problèmes avec la première version de Red Hat Enterprise Linux/CentOS qui utilisait PulseAudio par défaut. Ou SUSE.

Peux-tu expliquer en détail pourquoi ? Est-ce que tu t'y connais suffisamment techniquement pour avoir de bons arguments ?

Chez moi PulseAudio fonctionne très bien, je n'ai rien à lui reprocher.

Red Hat fait effectivement énormément de choses pour le desktop. (Bien plus que Canonical).

Deux exemples récents :

• libinput, voir cet article :

  I would also like to point out that the vast majority of commits were done by Red Hat employees […]

• Un meilleur support des systèmes dual-GPU, voir cet article.

Mais Red Hat ne fait pas tout le boulot, d'autres entreprises et des particuliers contribuent aussi à un meilleur desktop sous Linux.

Zapus la fin.

(De l'alphabet bien entendu).

Résultats plus pertinents dans un moteur de recherche ?

En installant gnome-software et en utilisant gnome-shell (le desktop GNOME). Je ne sais pas si dans Unity il y a cette fonctionnalité. Mais les dernières versions d'Ubuntu utilisent gnome-software aussi (sous un autre nom).

Repenser le système des votes pertinent/inutile.

Pour le contenu principal (en-dehors des commentaires), c'est utile de savoir combien de gens ont apprécié le contenu. Pour les commentaires, ça peut aussi être utile, mais ça l'est moins que pour le contenu principal. Connaitre en détail combien de fois on s'est fait moinssé, non merci. Certains sites n'ont absolument aucune note sur les commentaires, et ça se passe plutôt bien. Mais ça peut être utile, quand on est pressé, de ne lire que les commentaires les mieux notés. Pareil pour le contenu principal, ne lire que les contenus les mieux notés. Peut-être qu'il ne devrait y avoir qu'un +1, comme sur Google+.

Je prend un exemple que je connais bien, GNOME. Les dernières dépêches sur GNOME sont, je trouve, très longues. Et ce n'est pas très utile parce que GNOME, en amont, publie des notes de version détaillées, et traduites en français !

Donc, au lieu d'écrire des dépêches de plus en plus longues, une dépêche peut très bien être assez courte, avec un résumé et un lien vers les notes de version officielles. Ça ne sert à rien de se fatiguer à réinventer la roue.

Par contre, ce qui est plus utile, c'est de publier plus régulièrement des dépêches ou journaux quand un truc important se produit dans un des projets, même s'il n'y a pas de nouvelle version. GNOME sort une version tous les 6 mois, mais il peut y avoir des choses intéressantes à raconter à un autre moment.

Pareil pour Fedora.

Less is more. Quantité/qualité. Quantité : nombre de contenus, mais aussi longueur des contenus. Un contenu de qualité peut être assez court.

Totalement d'accord, voir en détail, pour chaque commentaire, le nombre de fois qu'il a été moinssé, c'est inhumain.

Il y a plusieurs années, j'écrivais régulièrement du contenu et des commentaires. Puis quand est apparu les notes détaillées des commentaires, j'ai trouvé ça horrible, et j'ai préféré ne plus venir sur LinuxFr (de toute façon le contenu est moins bien que sur LWN, par exemple).

Les user/group IDs dynamique, ça permet d'installer/lancer un service, et s'assurer que quand ce service est stoppé/désinstallé, le système soit redevenu comme avant, à part éventuellement les data et les logs.

Si pour lancer un service, ce service a besoin de créer un utilisateur ou un groupe, quand le service est stoppé il faut que l'utilisateur/groupe soit retiré. Pour avoir un système sans état (stateless). Les UID/GID fixes font partie de l'état.

Donc en gros l'idée c'est d'installer son OS, que l'image de cet OS soit read-only, qu'il y ait toujours moyen de revenir à cet état (factory reset), et que pour lancer des services, ces services créent (temporairement) l'état qu'ils ont besoin. Quand un "service portable" est stoppé/désinstallé, systemd s'assurera de faire un revert de tout l'état qu'a modifié ce service (en gardant les données à ne pas supprimer, bien entendu).

Et un "service portable" sera portable du fait que ça fonctionnera sur n'importe quelle distribution Linux (avec une version suffisamment récente du noyau et de systemd). C'est un container, mais mieux intégré au système (moins isolé). C'est une solution plus sécurisée, pour remplacer les super privileged containers.

Ton fichier de config tu peux le mettre dans Git. Pour un re-déployement c'est plus facile.

Sur l'annonce officielle, il est écrit qu'une nouvelle version majeure de GTK+ aura lieu tous les 2-3 ans.

Si la période est plus longue, ça risque d'être plus difficile de porter du code à la nouvelle version. Si la période est plus courte, les mainteneurs de GTK+ ont plus de versions à maintenir. Donc 2-3 ans est un certain compromis. 2 ans est déjà appliqué dans d'autres projets : Debian (plus ou moins), Ubuntu LTS, …

De manière générale, quand quelque chose est pénible/difficile (ici porter son code à une nouvelle version de GTK+), il vaut mieux le faire plus souvent. Voir cet article de Martin Fowler.

Ton application utilise Qt, mais le runtime Flatpak pour Qt/KDE est toujours en développement. Flatpak a pour l'instant un meilleur support pour GTK+/GNOME (puisque Flatpak est principalement développé par des développeurs GNOME).

Donc, pour l'instant je conseillerais AppImage pour une application Qt (même si j'ai jamais essayé moi-même, il parait que ça fonctionne bien).

AppImage s'occupe uniquement de l'empaquetage/installation. Flatpak et Snappy vont plus loin pour isoler les applications dans une sandbox.

Entre Flapak et Snappy, j'ai tendance à préférer Flatpak. Lire cet article par exemple.

Effectivement :
https://fedoraproject.org/wiki/Wayland_features#BLOCKER:_primary_selection

Le copier/coller en sélectionnant du texte puis en le collant en faisant un click milieu s'appelle Primary selection.

Mais les développeurs GNOME risquent de ne plus maintenir File Roller.

Nautilus utilise la bibliothèque gnome-autoar pour compresser/décompresser les archives. Peut-être que File Roller utilise la même bibliothèque, je ne sais pas.

Pour la raison d'avoir intégré ça à Nautilus, voir le post de Carlos Soriano:

You may be aware that we have been using File Roller since forever to handle compressed files. However, this makes integration with Nautilus none. It misses the progress report integration, undo, redo, and possibility to close the application while the operation continues.

C'est wayland quoi…

Wayland (le protocole) n'y est pour rien. C'est l'architecture de mutter/gnome-shell qui est en faute ici. Lit ce commentaire :

https://bugzilla.redhat.com/show_bug.cgi?id=1367666#c4

Plusieurs applications peuvent utiliser le même runtime, le runtime est partagé. Si une application a besoin d'une bibliothèque qui n'est pas présente dans le runtime, cette bibliothèque doit être "bundlée" avec l'application.

Il peut y avoir plusieurs runtime bien entendu : il y a le runtime freedesktop.org, un runtime GNOME, un runtime pour Qt/KDE est en développement, et certaines entreprises ont leur propre runtime. Et il y a généralement plusieurs versions pour un certain runtime : GNOME 3.20, GNOME 3.22, etc.

L'énorme avantage, pour un développeur d'application, c'est que le développement et les tests sont faits avec un runtime précis (et une version précise). Par exemple le runtime GNOME 3.22. Quand GNOME 3.24 sortira, l'application pourra toujours utiliser le runtime GNOME 3.22, donc il y a beaucoup plus de garanties que l'application fonctionnera toujours bien (càd les utilisateurs utilisent la même chose que ce que les développeurs ont utilisé).

Certes, ça utilisera plus de RAM puisque toutes les applications n'utiliseront pas la même version du runtime. Mais de la RAM, les ordinateurs récents en ont assez, et avoir des applications moins buggées (et qui demande moins de travail pour les développeurs) semble être plus important.

Je suis tout à fait d'accord, Mate a forké l'ensemble de GNOME 2, alors qu'il aurait suffit de continuer de maintenir metacity, gnome-panel, gnome-applets et quelques autres modules.

Au début de GNOME 3, il y avait le mode fallback qui utilisait toujours metacity et gnome-panel. Puis ces modules sont devenus obsolètes, avec la session GNOME Classic comme remplacement. GNOME Classic est un ensemble d'extensions de gnome-shell, et qui sont bien maintenues (à la sortie d'une nouvelle version de GNOME, GNOME Classic fonctionne directement). Pour lancer GNOME Classic, il suffit de choisir cette session dans gdm (sur Fedora, GNOME Classic est déjà installé; sur RHEL/CentOS 7, GNOME Classic est la session par défaut).

Pour metacity, gnome-panel etc, au moment où ça a été rendu obsolète, il y a eu une annonce comme quoi d'autres développeurs pouvaient reprendre le flambeau. Ce qui a donné GNOME Flashback (je ne sais pas vraiment ce qu'il en est à l'heure actuelle, je ne sais pas si c'est bien maintenu).

Ceci dit, puisque Mate a forké l'ensemble de GNOME 2, toutes les applications de Mate ont toujours une barre de menu et barre d'outils, à la place d'une headerbar pour la plupart des applications de GNOME 3 maintenant. Par exemple pour totem je trouve la headerbar et le menu hamburger pas mal, mais je préférais la barre de menu et barre d'outils pour gedit.

Dans le cas de gedit, il y a pas mal d'efforts ces dernières années pour rendre le code davantage réutilisable (i.e. avoir du code en commun dans une bibliothèque), avec comme but de pouvoir créer un éditeur de texte aussi bien que gedit, mais beaucoup plus facilement qu'actuellement (au lieu de forker ~60k lignes de code, ne forker par exemple que ~5k lignes). (oui je suis à l'origine de cette initiative).

Donc, il y a d'autres solutions.

En fait tout le monde à le droit de ne pas donner (encore heureux je dirais)

Sauf que si personne ne paye pour ce genre de logiciels libres (qui sont quand même assez appréciés et utilisés), ces logiciels libres ne seront plus développés, et un logiciel propriétaire prendra le dessus à la place.

Par exemple pas mal de monde a l'air d'apprécier Sublime Text (et de payer pour), mais les gens devraient se souvenir que c'est un logiciel propriétaire, et qu'il y a des éditeurs de texte libres qui acceptent les donations.

Le marché du desktop vise principalement le grand public (les entreprises aussi, pour ça il y a Red Hat et SUSE par exemple qui ont aussi des offres pour le desktop). Ce que je veux dire par là est que la plupart des applications desktop, ou le desktop lui-même, sont destinés au grand public, pour un usage personnel. Donc si très peu d'utilisateurs payent pour ces logiciels libres, le logiciel propriétaire prendra le dessus (ou plutôt, le logiciel libre ne prendra pas les devants).

La GPL est plutôt faite pour les logiciels, pas les manuels.

Voir la FAQ sur gnu.org:
https://www.gnu.org/licenses/gpl-faq.html#WhyNotGPLForManuals

Ceci dit, je trouve l'initiative une excellente chose !