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.
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.
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.
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.
[^] # Re: Redshift !
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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.
# Flatpak, Snappy, AppImage
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 3. Dernière modification le 08 octobre 2016 à 20:47.
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.
[^] # Re: Wayland et copier-coller à la souris
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 2.
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.
[^] # Re: Un avis
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 2.
Mais les développeurs GNOME risquent de ne plus maintenir File Roller.
[^] # Re: Un avis
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 2.
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: