Autre polémique récurrente : se plaindre que passer d'une version majeure de GTK+ à la suivante est difficile pour les développeurs, et qu'en Qt tout est bien mieux. Certains projets en GTK+ ont été réécrits en Qt, avec les développeurs donnant des conférences à gauche et à droite en prônant haut et fort Qt.
Mais apparemment, le passage à Qt 5 est tout aussi galère.
C'est marrant, quand GNOME retire une fonctionnalité il y a une horde de trolleurs qui rouspètent. Je remarque qu'ici kdenlive a aussi retiré des fonctionnalités, apparemment.
Et si retirer des fonctionnalités était en fait quelque chose qui peut arriver à toute application non-triviale ayant un long historique de développement ?
Je parlais bien de GNOME/Wayland, pas de Wayland en général.
Comme expliqué dans ce commentaire, c'est possible de changer l'architecture de gnome-shell/mutter pour régler ce problème, mais ça demanderait énormément d'efforts.
Je veux pas faire le rabat-joie, mais quand gnome-shell plante sous Wayland, toutes les applications plantent avec (si un contenu n'était pas sauvegardé, les données sont perdues) :
Alors qu'avec X11, gnome-shell est redémarré automatiquement par la session (gnome-shell n'est qu'un client parmi d'autres du serveur X). Sous X11, c'est quand le serveur X plante que toutes les applications plantent avec. Mais le serveur X plante beaucoup plus rarement, c'est un code beaucoup plus ancien et éprouvé.
Quelques raisons qui ne me laissent pas en confiance sous Wayland : une grosse partie du code de gnome-shell est écrit en JavaScript. C'est une architecture monolithique (beaucoup moins modulaire que Xfce, par exemple). Et il y a un an ou deux d'ici, j'avais assez souvent des crash de gnome-shell (sous X11), et je pense qu'on pouvait voir sur le Retrace Server que ça arrivait à pas mal de monde.
Ces dernières années les développeurs de gnome-shell ont fait pas mal d'efforts pour stabiliser le code, mais des plantages, il y en aura encore. Et quand ça arrivera à quelqu'un, il perdra ses dernières modifications.
En Belgique, les dons peuvent se déclarer comme « revenus divers », taxés à 33%.
Mais il y aura (ou il y a déjà, je ne sais pas) d'autres possibilités, moins taxées, voir cet article par exemple : un taux entre 10 et 20%, pour un montant maximal entre 6.000 et 10.000 euros (lorsque l'article a été publié, le taux et le montant maximal exact était toujours en cours de discussion). Typiquement pour des revenus issus de Airbnb, Uber, etc.
Donc j'imagine que ça s'applique aussi pour les revenus liés à une campagne de financement sur internet, sur Liberapay ou autre.
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 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.
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).
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.
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.
[^] # Re: Image d'accueil
Posté par swilmet . En réponse au journal Faire un peu d'argent avec le logiciel Libre, l'après Wallabag.... Évalué à 2.
gUI en a déjà parlé plus haut.
[^] # Re: kdenlive
Posté par swilmet . En réponse au journal Des conséquences d'un plâtre. Évalué à 0.
Autre polémique récurrente : se plaindre que passer d'une version majeure de GTK+ à la suivante est difficile pour les développeurs, et qu'en Qt tout est bien mieux. Certains projets en GTK+ ont été réécrits en Qt, avec les développeurs donnant des conférences à gauche et à droite en prônant haut et fort Qt.
Mais apparemment, le passage à Qt 5 est tout aussi galère.
# kdenlive
Posté par swilmet . En réponse au journal Des conséquences d'un plâtre. Évalué à 0.
C'est marrant, quand GNOME retire une fonctionnalité il y a une horde de trolleurs qui rouspètent. Je remarque qu'ici kdenlive a aussi retiré des fonctionnalités, apparemment.
Et si retirer des fonctionnalités était en fait quelque chose qui peut arriver à toute application non-triviale ayant un long historique de développement ?
[^] # Re: Petit retour d'expérience
Posté par swilmet . En réponse à la dépêche Fedora 25 est disponible !. Évalué à 1.
Je parlais bien de GNOME/Wayland, pas de Wayland en général.
Comme expliqué dans ce commentaire, c'est possible de changer l'architecture de gnome-shell/mutter pour régler ce problème, mais ça demanderait énormément d'efforts.
[^] # Re: Redshift !
Posté par swilmet . En réponse à la dépêche Fedora 25 est disponible !. Évalué à 1.
En tout cas pour l'input, il y a libinput. Il y a peut-être d'autres exemples.
[^] # Re: Petit retour d'expérience
Posté par swilmet . En réponse à la dépêche Fedora 25 est disponible !. Évalué à 3.
Je veux pas faire le rabat-joie, mais quand gnome-shell plante sous Wayland, toutes les applications plantent avec (si un contenu n'était pas sauvegardé, les données sont perdues) :
https://fedoraproject.org/wiki/Wayland_features#Restarting_gnome-shell
Alors qu'avec X11, gnome-shell est redémarré automatiquement par la session (gnome-shell n'est qu'un client parmi d'autres du serveur X). Sous X11, c'est quand le serveur X plante que toutes les applications plantent avec. Mais le serveur X plante beaucoup plus rarement, c'est un code beaucoup plus ancien et éprouvé.
Quelques raisons qui ne me laissent pas en confiance sous Wayland : une grosse partie du code de gnome-shell est écrit en JavaScript. C'est une architecture monolithique (beaucoup moins modulaire que Xfce, par exemple). Et il y a un an ou deux d'ici, j'avais assez souvent des crash de gnome-shell (sous X11), et je pense qu'on pouvait voir sur le Retrace Server que ça arrivait à pas mal de monde.
Ces dernières années les développeurs de gnome-shell ont fait pas mal d'efforts pour stabiliser le code, mais des plantages, il y en aura encore. Et quand ça arrivera à quelqu'un, il perdra ses dernières modifications.
[^] # Re: Redshift !
Posté par swilmet . En réponse à la dépêche Fedora 25 est disponible !. Évalué à 1.
Rien n'empêche d'écrire une bibliothèque pour avoir du code en commun.
[^] # Re: Déclarer les dons
Posté par swilmet . En réponse à la dépêche Liberapay, plate‐forme libre de dons récurrents . Évalué à 3.
Un meilleur article, toujours pour la Belgique :
http://www.decroo.belgium.be/fr/chambre-economie-collaborative
# Déclarer les dons
Posté par swilmet . En réponse à la dépêche Liberapay, plate‐forme libre de dons récurrents . Évalué à 3.
En Belgique, les dons peuvent se déclarer comme « revenus divers », taxés à 33%.
Mais il y aura (ou il y a déjà, je ne sais pas) d'autres possibilités, moins taxées, voir cet article par exemple : un taux entre 10 et 20%, pour un montant maximal entre 6.000 et 10.000 euros (lorsque l'article a été publié, le taux et le montant maximal exact était toujours en cours de discussion). Typiquement pour des revenus issus de Airbnb, Uber, etc.
Donc j'imagine que ça s'applique aussi pour les revenus liés à une campagne de financement sur internet, sur Liberapay ou autre.
[^] # Re: Temps de lancement
Posté par swilmet . En réponse au journal Mozilla: l'enjeu de 2017 est-il au niveau du navigateur web ?. Évalué à 2.
J'ai trouvé ça :
https://wiki.archlinux.org/index.php/Preload
# Temps de lancement
Posté par swilmet . En réponse au journal Mozilla: l'enjeu de 2017 est-il au niveau du navigateur web ?. Évalué à 1.
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é.
[^] # Re: Remplacer gecko par webkit?
Posté par swilmet . En réponse au journal Mozilla: l'enjeu de 2017 est-il au niveau du navigateur web ?. Évalué à 6.
Mozilla développe déjà un remplaçant, Servo, écrit en Rust.
[^] # Re: Chocking
Posté par swilmet . En réponse au journal Campagne de financement pour PulseAudio. Évalué à 2.
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).
[^] # Re: Ubuntu a bon dos
Posté par swilmet . En réponse au journal Campagne de financement pour PulseAudio. Évalué à 3.
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.
[^] # Re: Chocking
Posté par swilmet . En réponse au journal Campagne de financement pour PulseAudio. Évalué à 6.
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.
[^] # Re: Chocking
Posté par swilmet . En réponse au journal Campagne de financement pour PulseAudio. Évalué à 8.
Red Hat fait effectivement énormément de choses pour le desktop. (Bien plus que Canonical).
Deux exemples récents :
libinput, voir cet article :
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.
[^] # Re: Proposer des noms
Posté par swilmet . En réponse à la dépêche Sortie d’Ubuntu 16.10 Yakkety Yak. Évalué à 0.
Zapus la fin.
(De l'alphabet bien entendu).
[^] # Re: Signification de Yakkety Yak
Posté par swilmet . En réponse à la dépêche Sortie d’Ubuntu 16.10 Yakkety Yak. Évalué à 1.
Résultats plus pertinents dans un moteur de recherche ?
[^] # Re: Intégration app store
Posté par swilmet . En réponse à la dépêche Sortie d’Ubuntu 16.10 Yakkety Yak. Évalué à 2.
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).
[^] # Re: Moins de lynchage - plus de pédagogie
Posté par swilmet . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à -1.
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+.
[^] # (Trop) longues dépêches
Posté par swilmet . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à 7.
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.
[^] # Re: Moins de lynchage - plus de pédagogie
Posté par swilmet . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à -4.
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).
[^] # Re: Vivement 'dredi
Posté par swilmet . En réponse au journal Vidéos de la systemd.conf. Évalué à 5.
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.
[^] # Re: Nixos...
Posté par swilmet . En réponse au journal Vidéos de la systemd.conf. Évalué à 3.
Ton fichier de config tu peux le mettre dans Git. Pour un re-déployement c'est plus facile.
[^] # Re: GTK+4
Posté par swilmet . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 3.
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.