freem a écrit 5019 commentaires

Non parce que hein, les divers outils vus dans cette dépêche sont tous basés sur une techno hyper lourde: le HTML5.

On peut éventuellement améliorer la situation du point de vue du respect de la vie privée en patchant des logiciels fondés sur cette techno, certes, et c'est mieux que rien, mais sauver la planète?
J'en doute. Fort. Très fort. À mes yeux, le web est le principal moteur qui implique de devoir balancer du matos encore fonctionnel mais "trop vieux".

Ton […]Python[…] d'il y a 20 ans fonctionne encore

J'aimerai en être si sûr :]

Parce qu'en terme de distros magiques, j'en connais une autre qui s'en revendique: sourcemage (bon, c'est surtout pour la blague, hein, j'ai jamais utilisé après tout).

À suivre les liens, on trouve des sources, tu pourras juger et chercher ce qui te plaît, ce à quoi que tu veux faire jouer a ces enfants. Pourquoi pas, jouer avec eux?

• https://forum.freegamedev.net
• http://www.lebottindesjeuxlinux.tuxfamily.org/fr/home/
• https://libregamewiki.org/Main_Page (pointé par le 1er)

Tu peux aussi éventuellement chercher dans ton navigateur de paquet préféré, aptitude via les catégories ou, soyons fous, les debtags (si tu trouves un soft qui tiens la route je suis preneur).
D'autres on peut-être d'autres outils.

Un merci aussi à Linuxfr.org grâce a qui j'ai pu exposer mon problème et trouver une solution

yw. Désolé, pas pu m'empêcher.

une ceinture de chasteté […] qu'on pouvait bloquer […] sans moyen […] de déverrouillage

Ben oui, justement, une ceinture de chasteté quoi :)

Pas faux. J'avais mal interprété tes propos, désolé.

Tout à fait, ma réponse était d'ailleurs garantie 100% sans ironie :)

En vrai, ma réponse marche. Dans certains contextes. Pas dans les bons. De la même manière que la réponse à laquelle je répondais…

Je réagis seulement à la remarque sur Hugo : certes c'est un logiciel complexe (comme beaucoup de générateurs de site statique, il réimplémente pas mal de fonctionnalités de make), mais il sert seulement à générer du contenu statique, contenu qui peut être aussi simple que l'on veut.

Et si le contenu est simple, pourquoi utiliser hugo? S'il est possible de faire des sites simples facilement, de compiler aisément un layout et une liste, par exemple, de documents markdown en un site simple et propre, pourquoi un truc aussi complexe que hugo?

Notes bien, je ne tape pas en soit sur hugo, c'est juste probablement le générateur statique le plus utilisé en ce moment… il ne sert que d'exemple pour illustrer ce que, oui, je qualifie de complexité.

Bon, sur le layout, il semble qu'il va me falloir revoir mon jugement, cela dis.

Si tu regarde ça par exemple : Full-Bleed Layout Using CSS Grid

Merci! Encore que, en suivant le lapin, j'ai commencé la lecture du PDF en lien, et, bon, 352 pages à lire… je sais pas si je dois vraiment te remercier… XD

Je suis d'accord avec le postulat de base, mais je trouve l'article un peu… limite (alors qu'il semble que la personne derrière sache un minimum de quoi elle parle).

Et ceci d’autant plus qu’il n’existe derrière ces navigateurs que deux moteurs de rendu, le cœur du navigateur, la partie qui interprète le langage HTML et le CSS et dessine la page. Chrome, Edge et Safari utilisent le même moteur de rendu, WebKit (ou l’une de ses variantes).

D'une part, safari et chrome n'utilisent pas le même moteur de rendu (oui, c'est un fork, mais je doute fort qu'il reste beaucoup en commun depuis le temps), et d'autre part, il y a au moins un autre moteur de rendu qui est maintenu, bien que pas au niveau des autres, clairement.
Ce qui fait donc (en moteurs de rendu non morts):

• gecko
• blink
• webkit
• netsurf

L'auteur recommande d'ailleurs dillo… dont la dernière "news" date de… 2015, 2 commits en 2018, 2 en 2017, pour moins de 20 lignes changées depuis: dillo est moribond (et il était loin d'être fini la dernière fois que je l'ai essayé. Idem pour netsurf, certes, mais au moins il reste de la lumière.).

Autre navigateur « alternatif », le Tor Browser. C’est un Firefox modifié

Moué…. mais qui est basé sur FF, donc loin de ne pas être complexe. Très loin, même.

Accessoirement, la seule complexité qui est abordée par l'article, c'est celle dont "on se fiche pas mal": les pubs, le tracking…
Rien n'est réellement mentionné au sujet de la complexité des technologies sous-jacentes, c'est à dire HTML/CSS, avec lesquels créer un simple layout de type header, menu latéral, footer, relève de la gageure, la ou c'était censé être simple. Du coup, tout le monde utilise des logiciels complexes (regardez la taille du code d'hugo…) pour le moindre truc.

Non, gemini ne permettra pas de bloquer le tracking, il n'y a pas besoin de cookies pour ça. Le format n'inclue rien d'exécutable? Certes, mais il permets de télécharger n'importe quel type de fichier en plus du format à la con, et donc d'en faire le rendu. Oui, on pourrais utiliser un navigateur gemini pour faire le rendu de code HTML5.

sauf à utiliser seulement git… mais auquel cas ils ont autant le contrôle de leur informatique qu’avec github (il reste un problème de surveillance, mais une forge libre (pour son proprio) qui n’est pas github a autant de pouvoir de surveillance que microsoft avec github… c’est juste qu’il s’agit d’une entité plus petite et donc moins puissante).

La solution, du coup, c'est fossil, non?

Franchement, même l’AGPL ne garantit rien. Au moins avec la GPL,

Ben, si la pré-condition légale est respectée, l'AGPL est «mieux» que la GPL, justement, puisque plus contraignante.
Mais bon, oui, il y a ce gros pré-requis que les gens respectent la loi…

PS : c’est quoi le problème de l’extrêmisme ? :o tu es sûr que tu ne confonds pas avec l’agressivité ou le manque de pédagogie ?

Pas faux :)

Non, mais, pour tuer facilement, pas besoin de cgroups, just kill -9 $(pidof foobar) fait le job. Le problème, c'est de tuer quand tu as une perte d'une des conditions importantes pour le fonctionnement. Genre, la perte de connection au serveur graphique (via protocole X11 ou wayland, peu importe) devrais être simple à détecter, et quand c'est le cas, il faut tuer les applications graphiques, idéalement sans le -9, parce que peut-être qu'on peut sauvegarder l'état avant de redémarrer.

Bon, je sais, je rêve. Et c'est hors sujet, on parle d'un DE la, après tout, l'utilisateur à accès au clavier et à la souris, pas besoin de chien de garde, il peut faire le job.

C'est forcément l'init qui récupère ça.

Certes. Mais du coup, je me demande justement si c'est pertinent.

Ça veut dire quoi maintenir une interaction possible ? Ton programme ne veux plus réagir, on ne peut pas l'y contraindre. A lui d'avoir différentes interfaces si nécessaire (graphique, dbus, une socket unix ou tcp, un pipe nommé,…).

Je voulais dire, que si le programme ne peut plus interagir, autant le tuer, et c'est pas le job de PID1 d'être capable de vérifier ça.

Tu demande comment faire pour qu'une application buguée réagisse bien ? Remonter un bug ou un patch.

Ok. Donc, les watchdog, ça sert à rien, revenons à sysVinit (parce que oui, l'intérêt majeur de systemd (et d'autres) est bien de proposer un mécanisme de watchdog logiciel). Quand ça crash, on fait un déplacement (allez, 300 bornes, c'est rien…) et on fait un rapport de bug ou on patche, en espérant qu'il n'y ait plus de freeze.
En fait, même les containers, ça sert à rien: s'il y a une faille, on fait un rapport de bugs et/ou corriger le problème.
Perso, ma solution dans ces cas la, c'est d'essayer de revenir a du moins accéléré, moins performant, plus cher (en temps immédiat de dev) mais plus simple, plus maintenable et plus fiable (en gros, du KISS, qui a un réel coût).

Balancer un signal. Si le processus a prévu un handler c'est cool sinon ça te permettra de le tuer.

C'est ce que je craignais… perso, j'aimerai un système qui fasse que l'application crash (parce que du coup on peut relancer) quand son «descripteur de fichier graphique» n'est plus fonctionnel.
J'ai vécu le cas, sur le bureau, c'est pas trop grave (avez-vous pensé a rebooter?), et sur de l'embarqué, à plus de 50km du bureau, accès via réseau téléphonique radio seulement, déjà nettement plus chiant (l'utilisateur ne peux pas rebooter). En vrai, la solution, ça a été de revenir aux bases: ce bon vieux framebuffer pour le graphisme, avec rendu logiciel (jusque 10ms par trame, sur un CPU type intel), et libinput pour le tactile. Et pour le texte, ben, la fonte au format PSF (v1 ou v2): ça va qu'on reste dans les zones latines quoi…
C'est une solution de merde, clairement, mais pas trop eu le choix (compte tenu des impératifs de temps, le client était vraiment pas content d'avoir des trucs qui bugguent tout le temps, et le patron était pas fan non plus: il fallait du simple, qui juste marche).

À mon sens, le choix des développeurs de Wayland qu’il en fasse le moins possible et de déléguer presque tout aux clients est de très loin leur choix le moins judicieux.

Le fait qu'ils ne s'occupent pas des décorations de fenêtre ne me choque pas, en soit.
Du peu que je connais, rien ne semble empêcher l'implémentation du paradigme:

Wayland-serverd
 |-- window-manager
 |-- some-client
 `-- window-decorator

Par flemme, tout le monde construit la logique de la gestion des fenêtre dans le serveur graphique, mais je ne vois rien qui empêche de split la chose. En fait, ça serait probablement, la meilleure chose à faire: moins de code dans l'une des parties les plus critiques, qui pourrais (devrais?) ne faire que gérer le respawn de certains services critiques (s'ils existent: le wm, un VNC en entreprise par exemple, un presse-papier, etc) et leur donner les informations dont elles ont besoin (principalement la position et les dimensions des fenêtres, en fait, probablement aussi le temps sans que la fenêtre ait été actualisée, le focus, et 2-3 bricoles?).

Le «seul problème» ici, bien sûr, c'est qu'il est nécessaire de construire un protocole entre wayland-serverd et window-manager, ainsi, forcément, qu'entre le wm et le wd.
Avoir ces protocoles séparés ne me choque pas plus que ça, puisque ça permets notamment que, le jour ou wayland sera moisi parce qu'on aura de nouveaux usages, on pourra peut-être ne changer que le coeur, le reste fonctionnerait potentiellement encore, chose qui ne semble pas vraie sous X11.

Le fait est par contre que les bibliothèques (gtk et qt) ont choisi d'embarquer la décoration côté client: c'est plus simple pour aller vite, je dirais.

Le menu par défaut (nommé garçon) ne démarre plus les applications comme étant des processus fils du tableau de bord. Ainsi un crash de l’application n’entraîne plus avec lui la disparition du tableau de bord.

Donc, si je comprend bien, le tableau de bord plantait quand un processus fils crashait, et la réponse à été de détacher les processus fils?

Pourquoi pas, en soit, parce que je pense qu'en effet, ce n'est pas le rôle du tableau de bord de gérer les applications. Par contre, j'ai déjà eu le cas (à plusieurs reprises, même, et 99% du temps avec des navigateurs web, 1 fois avec claws) d'applications qui n'ont plus de fenêtre, ce qui est très bien pour un certain nombre d'applications (daemons) mais très chiant pour des applications graphiques, comme une application ncurses qui ne se fermerait pas quand stdout est fermé…

Bref, je présume que du coup la gestion du processus remonte jusqu'à PID1? Ou y-a-t-il un processus avant qui récupère la parenté, et éventuellement maintiens (je ne sais pas si c'est possible) la garantie qu'il est possible d'interagir avec la-dite application?

Honnêtement, je ne sais pas ce qu'il est possible de faire dans ce domaine, mais je me pose de plus en plus la question de la fiabilité des applications interactives: comment réagir en cas de problème (race condition, "perte" d'affichage graphique, etc)? Quelles solutions techniques théoriques et pratiques y a-t-il actuellement?

Le but n'est pas de jeter la pierre à xfce pour ce choix, loin de la, juste de profiter de l'occase pour savoir comment ce genre de situations (rares, certes) sont gérées.

GitlabCE et Gitea sont des alternatives libres intéressantes

Et rien ne prouve ni ne force que l'instance que tu utilises soit libre: c'est pas des licences AGPL (MIT et CC-BY-SA, à vue de nez).
Triste, pour un extrémiste comme toi de ne pas avoir remarqué ce point.

Sérieusement, si avoir un nouvel identifiant suffit à te freiner alors tes ambitions doivent être très faibles…

Mes ambitions sont très bien ou elles sont, vois-tu. En fait, je pense que les DVCS c'est cool: je peux faire un code libre, le diffuser, et fork qui veut. Si ça veut poser une question, ça passe par le mail (oups, j'en ai un gafam…), si ça veut contribuer, idem.
Même que j'hésite à utiliser fossil, pour avoir un truc plus sexy.

Point de nouveaux identifiants, point d'usine à gaz web, c'est assez confortable, et mes ambitions apprécient ce petit monde cozy.

Par contre, je comprend que ça ne soit pas le cas de tout le monde. Certains veulent coder en communauté sans être emmerdés par les insistances à utiliser GH, et je les comprend.

Pour rappel, les gestionnaires de mots de passe, ça fonctionne très bien, même ceux intégrés aux navigateurs web, et les sessions longues durées aussi.

Alors… en fait, je t'expliques: moi, je refuses catégoriquement de laisser un outil aussi complexe et bordélique qu'un navigateur web stocker des mots de passe. Idéalement, j'aimerai même ne pas avoir a passer par ces trucs pour quoique ce soit de sécurisé, tellement il me semble stupide de faire confiance a ces usines à gaz.
Sur ce point, je fait ce qu'on appelle un compromis, tu devrais essayer.

Ensuite, les gestionnaires de mots de passe… oui, faudrait que je fasse. Je me dis ça depuis des années, mais bon, j'ai plusieurs machines, et oui, j'ai la flemme de me trimballer une clé chiffrée sur moi qu'il me faille 1) avoir compatible windows (parce que je sais jamais quand je vais devoir intervenir sur un windows) 2) déchiffrer 3) espérer la compat des outils locaux… juste pour accéder à une forge, dont les informations sont toutes accessibles publiquement, de toute façon (parce que c'est le but. Oui, même le mail l'est, régulièrement).
L'alternative, c'est synchroniser ses machines en permanence… ouai, en fait non, merci.

Il y a une vie possible en dehors des GAFAM et elle est pleine de bonnes choses, essayez à l'occasion, vous risquez d'être surpris :o)

Par exemple avoir mon propre VPS chez ovh pour héberger mes gadgets? Ouai, c'est déjà le cas, merci.

PS: tu devrais essayer d'être moins extrême, c'est plein de bonne choses, tu risques d'être surpris :o)

Le commentaire sur lequel tu pointes ne sembles pas parler de debian?

Sinon, moi, je trouve ça plutôt logique, d'essayer de faire un logiciel qui tourne sur des distros qui ne sont pas en rolling release, ça ne me choque pas.
Je connais des logiciels qui vont bien plus loin, les versions doivent compiler et fonctionner sur Ubuntu Xenial, la version de systemd? 229. Vs 241 pour Debian buster.

Je suis déjà plus choqué par le fait que cet ensemble critique n'utilise pas semver pour essayer de facilement indiquer si une nouvelle version casse des comportements ou non, en fait. Surtout vue la vitesse ou ils vont (tu l'as dis toi-même, debian 10 à 6 versions de retard)…

Du coup ma question est : qui utilise encore un écran de veille de son plein gré actuellement ?

Ceux qui ont encore des écrans cathodiques? XD

Plus sérieusement, je suis assez d'accord sur l'inutilité d'un "screensaver" de nos jours: mieux vaut éteindre l'écran, cesser d'émettre de la lumière inutile: c'est plus économe en énergie et j'imagine allonge la durée de vie de l'écran. Peut-être que ce n'était pas vrai il y a quelques décennies, peut-être qu'un cathodique consomme tellement au démarrage que l'éteindre peut ne pas être pertinent… mais les LCD, ça m'étonnerais grandement.

Pour en revenir sur le support de systemd… bah, franchement, de ce qui est expliqué dans le billet, je suis d'accord que ça semble merdique le mécanisme en place (risque de verrou permanent), mais, vraiment?
Pourquoi systemd essaie-t-il de gérer les fonctionnalités de mise en veille de l'écran?

Ça ne devrais pas être le boulot réservé des serveurs X11 ou wayland, selon ce qui est installé? Ou d'un autre daemon éventuellement pour les gens qui font du rendu direct (framebuffer, par exemple. Ne riez pas, c'est bien plus pratique que ça en a l'air)… ah tiens, c'est p'tet ça la raison du mécanisme de systemd: mettre en veille les machines qui ont un écran en TTY (vraie question, je précise) ou en rendu direct?

L'alternative, c'est quoi? Bitbucket? C'était bien avant, mais avec toutes leurs refontes d'UI, c'est devenu pire, et pas qu'un peu, que github. Ça reste pas libre.
Gitlab? Tant que c'est pas hébergé chez toi, pas libre.
Sourceforge? On connaît, je pense.

Ahhh sinon, y'a bien ça: savannah. Comment dire… même dans les années 2000, une interface de ce niveau était difficilement acceptable. La dernière solution, l'auto-hébergement, mais on t'a répondu pourquoi on peut ne pas vouloir (nouveaux identifiants).

Bon, après, il y a peut-être une autre solution: auto-hébergement, avec une forge qui supporterait l'authentification via les SSO des… GAFAM. Doit être chiant à mettre en place ça, par contre.
Tu as une piste? J'ai bien quelques projets persos à héberger, qui sont sur mon stagit perso, mais je doute qu'il y ait un jour une contribution, ce sont des gadget après tout.
Si tu as une solution avec une authentification centralisée pour laquelle j'ai pas besoin de galérer des heures pour la mettre (et la maintenir) en place, pour laquelle je n'ai pas à charger trop ma pauvre VM cloud dont les 20Gig de disque sont déjà bien remplis, je me pencherai dessus.

Oups, j'ai marché dedans.

Désolé pour ça, mais oui, j'aurai du mentionner que la famine est liée à la suppression des cookies :)

Je n'ai pas dis que uzbl est propre. D'ailleurs, me semble qu'il est mort (tu le dis toi-même, 2014).
Tu sais, uzbl, c'était juste un example. C'est un truc qu'on m'a appris quand j'étais en 2nde: quand on argumente, idéalement, il faut un example (c'est à dire un point pratique, pas nécessairement exhaustif) pour appuyer la théorie, l'idée. Je sais que je ne suis pas bon pour ce genre de choses, mais je pensais que ce genre de choses étaient connues de tous. Désolé.

Des exemples de navigateurs dans ce style, il y en a d'autres, juste, moi, j'ai arrêté de chercher un navigateur web correct, j'ai abandonné l'idée. Alors je n'imprime pas leurs noms quand je les vois passer (je pourrais toujours demander sur divers #irc, cela dis).

Je l'ai aussi pris comme example sur le côté «fonctionnel» si tu me permets ce terme. C'est à dire un logiciel minimum, qui sera bien plus simple a patcher/forker/utiliser comme example qu'une ancienne suite logicielle qui s'est faite élaguer quelques fonctionnalités (et s'est vu en greffer d'autres) au fil des années.

Des example «comme uzbl» (sur l'idée d'un navigateur minimaliste) il y en a plusieurs. Aucun n'est basé sur le moteur de FF, par contre, la plupart, c'est sur webkit, parfois le port Qt, plus souvent le port Gtk. De temps en temps un navigateur qui vise plus gros se base sur chromium, mais eux visent plus gros. Même ceux-la, il y en a beaucoup plus que des forks de FF, cela dis.

Ton argument était le contraire exact…

Non. Le fait que j'espère qu'ils ont amélioré ne veux pas dire que le code n'est pas sale. Je connais un certain nombre de bases de code très laides, qui ont été un peu nettoyées mais l'histoire pèse toujours et le code est toujours dégueu. Juste moins pire.
Ce que tu viens de citer, en gros, si je me reformule (désolé si ça n'était pas clair), c'est: "j'espère qu'avec servo ils ont nettoyé au passage".

J'ai la version 3.17.3 de claws, empaquetée par Debian Buster ici. Ok, je n'ai qu'un seul compte mail et "quelques" flux rss, mais je ne constate pas de freeze systématiques de l'UI quand je fait la relève.

Les freeze que j'ai expérimentés, c'est surtout avec une connexion de merde, sur un réseau dégueulasse, et je ne serais pas surpris que ça ait été causé par le routeur qui embarquait un cache DNS qui cassait toutes les 5 minutes, sans parler de la connection à la fiabilité douteuse (routeur ethernet <=> gprs) qui rendait impossible de conserver une connection ssh plus de 5 minutes, 10 pour les chanceux.
Vu l'âge du bestiau (claws/sylpheed), je ne serai pas surpris que l'usage sur des réseaux stables mais lent ne soit pas trop problématique (héritage) mais qu'un réseau non stable (avec fortes pertes de paquets je suppose?) puisse poser des problèmes?