chimrod a écrit 1064 commentaires

Tu as raison, après relecture, il garde effectivement la tête froide et reste plutôt calme. Sur le moment j’en avait gardé eu une autre lecture…

Pour le second point, j’ai l’impression que Zenitram réagis plus facilement pour reclarifier ce qu’est le libre et ce qu’il n’est pas ; mais nous sommes d’accord, cette vision est partagée et il n’est pas le seul à la porter !

Tu as de manières de mourir dans le jeu :

• Ne pas réfléchir et foncer tête baissée. Dans ce cas, tu meurs alors qu’il te reste des potions de soins ou d’autres ressources qui auraient pu te sauver. C’est con mais à part prendre de la distance sur le jeu, il n’y a pas vraiment de solutions
• Mourir à petit feu, en perdant nos ressources les unes après les autres jusqu’à finir acculé dans un coin du donjon. Là il y a moyen de progresser :)

Les graines permettent de changer une situation critique en partie gagnante. Il faut juste penser à ouvrir son sac et regarder son inventaire :

• la houlevigne placée sur une passerelle est un combat en moins
• la roséclipse pour s’échapper d’une situation compliquée
• la moussepine permet de blesser qqn quand notre arme n’est pas au niveau
• Le pistigel sur un ennemi sensible au froid
• …

Tu as énormément de guide sur le subreddit plus des spoils ou techniques de jeu plus ou moins originales. Je n’ai plus de lien sous la main, mais tu trouves régulièrement des guides sur la manière de jouer tel ou tel personnage.

Mais dans tous les cas, il faut expérimenter ! Une mort qui nous a permit d’apprendre qqch sur le jeu est une mort utile !

Cela fait longtemps maintenant que je suis l’activité de Shattered Pixel Dungeon, et il s’agit d’un jeu dont je ne me lasse pas depuis maintenant quelques années. Il réussi à être addictif sans nous rendre dépendant, et être simple sans être répétitif.

À côté de cela, il faut aussi noter que le projet (et non plus le jeu lui-même) et une très bonne réussite. L’auteur a son caractère (voir son coup de gueule contre fdroid), mais a réussi à fédérer tout une communauté autour de son fork et de ses changements. Son système de donation pour accéder au jeu premium fonctionne bien (ça a juste comme effet de donner une bordure dorée aux écrans et de renommer ses perso)

Mais dois-je comprendre qu’il se fait de l’argent en ayant forké le code de qqn d’autre ? Et bien oui, et c’est ça le libre (coucou Zenitram !) Tout comme n’importe qui est libre de faire pareil avec son code (et il suffit de voir les annonces sur le sub-reddit pour s’en rendre compte). Evan a tout compris, et c’est une très bonne chose au final !

Bonjour,

Excuse moi de la réponse tardive. Le modèle avait déjà été choisi, et sauf incompatibilité dans le matériel je préfère rester sur ce qui a été demandé.

Par contre je garde le lien pour moi, cela pourra me servir prochainement !

Pour les pisteurs qui passent par des requêtes http j'utilise l'application blokada, qui fonctionne comme un bloqueur VPN. Cela permet de filtrer toutes les requêtes, même celles venant des applications.

Pour les appels ou autre, oui il y a cela. Par contre j'ai l'impression que ta demande concerne davantage LineageOS que l'appli bancaire c'est bien cela ? Tu envisages un remplacement de téléphone ? Si oui, je t'invite à lire la dépêche quel téléphone plus ou moins libre en 2021 qui t'ouvrira plein de pistes !

Que veux-tu dire par "sur cet environnement" ? Au moment du lancement de l'application le système nous demande si l'on autorise telle ou telle permission à l'application (comme sur d'autres systèmes je suppose ?)

Merci de me faire découvrir. Ça fait tellement longtemps que je suis attaché à Debian que je ne pense pas forcément à regarder ailleurs.

Après, je pense que le mieux pour se lancer est de faire ça sur son pc sans trop de risque plutôt que de se lancer dans cette opération sur un matériel nouveau avec des conditions qui ne sont pas des plus évidentes !

Mais je garde sous le coude (en ce moment je m'amuse assez les raspberry pi zero, l'envie me reviendra un moment de revenir sur les pc !)

J'ai également un PC sous lineageOS (sur lequel j'ai installé micro-g, ce qui peut faire une différence). Par fdroid, j'ai installé "Aurora store", qui permet ensuite d'installer des application du google store… dont l'application de la caisse d'épargne.

Je n'ai rien à signaler, ça fonctionne.

C'est le processeur de base que tu cite, je comptais lui prendre un processeur Ryzen 5 3500U (2.1 GHz / jusqu'à 3,7 GHz). Ça sera suffisant pour qu'il mette à jour son site d'armorial du poitou…

Merci du retour et d'avoir pris le temps de chercher

Oui j'ai donné le lien constructeur, mais je pense qu'à ce niveau il n'y aura pas de surprise sur les options disponibles (disque dur etc). Du moment que le wifi et fonctionne et que l’acceleration vidéo est disponible le reste sera secondaire.

Le problème que tu pointes sur le touchpad remonte à février et peut être contourné en recompilant le noyau (ça me changera de buildroot…). Je pense (espère) qu'il a du être intégré d'ici là sinon je me débrouillerai.

Ah ah merci du rappel :) Oui, il faut que je me replonge dedans tu as raison

Le con est vraiment con, il croit que c'est nous le con alors qu'en fait c'est lui…

(Note : je ne connais pas Rust, il est donc possible que ma syntaxe ne soit pas propre)

La syntaxe 'a permet de définir une contrainte dans la signature de la fonction. Ce qui est important ici n'est pas d'ajouter l'information sur la durée de vie : ce qui est important est que cette information de durée de vie soit la même sur l'ensemble des termes passés en arguments.

Tu pourrais avoir cette fonction qui prend en paramètre des arguments avec des durées de vie différents :

  fn longest<'a, b>(x: &'a str, y: &'b str) ->

Le problème qui se pose ici est de définir le résultat de la fonction. Garde à l'esprit qu'il faut que cela soit exprimable dans le langage. Comment représentes-tu prends la durée de vie la plus mauvaise des deux ? (C'est peut être possible, j'ignore a quel point le système de type de rust est avancé. Il faudrait pour cela que la durée de vie puisse être représenté par un type arbitraire).

On pourrait décider de prendre arbitrairement l'un ou l'autre :

  fn longest<'a, b>(x: &'a str, y: &'b str) -> &'b str

mais le compilateur risque de ne pas aimer et lever l'erreur en indiquant une incohérence dans le code.

Le plus simple est donc d'imposer cette contrainte : les deux types doivent avoir la même durée de vie, et c'est à l'appelant de s'assurer que cette contrainte est respectée.

Les deux process étaient relancés à partir du point de contrôle précédent tout simplement. Il faut garder à l'esprit que dans ce contexte, c'était la sureté de l'exécution qui était mise en avant, au détriment de la vitesse, et cela a à la fois des impacts sur le fil d'exécution du programme, mais sur le hardware mis en place autour.

De mémoire, il y avait peut-être un contrôleur d'exécution, qui s'assure que les deux programmes s'exécutent correctement, qui se trouvait dans une "chambre forte" protégée de tout environnement (radiation, ionisation etc). Au final cela revenait moins cher de mettre seulement ce dernier élément en confinement, et laisser les processeurs/microcontroleurs subir les attaques de l'environnement plutôt que créer une brique complète qui protège l'ensemble du système. (je ne sais plus trop si les programmes s'autocontrôlaient ou si cela était fait en extérieur — l'idée étant là, on peut imaginer les deux)

J'avais un jour assisté à une conférence sur ces questions de sureté de code. Dans un environnement "hostile" (je ne sais plus trop le contexte : nucléaire, ou ce genre de truc), une solution avait été de compiler le programme deux fois, avec deux compilateurs différents. Les deux programmes s'exécutaient en parallèle, et des points de contrôles avaient été mis en place dans lesquel chaque programme attendait que l'autre produise le même résultat avant d'embrayer sur la suite.

Comme le source était le même, il était attendu que le résultat soit identique, mais l'utilisation de deux compilateurs faisaient qu'un incident survenant sur l'exécution d'un programme n'avait pas le même impact sur l'autre, ce qui protégeait la solution.

Pareil, j'utilisais le thème sombre "par défaut" parce que le thème clair ne me correspondait pas. En voyant que le thème avait mis à jour dans la dépêche, je me suis empressé d'aller modifier ça dans l'appli, et c'est beaucoup mieux comme ça !

Merci !

J'ai redécouvert récemment GPG, également via la protection des mots de passes. Jusqu'alors, j'avais la vision de GPG un peu réductrice d'être associé aux courriels, avec des contraintes que j'imaginais un peu lourdes (le process de création d'une clef est "sérieux" quand on veut juste tester sans aller plus loin).

J'ai sauté le pas il y a un an, en m'achetant une clef GPG (une version "non sécurisée" qui n'est pas basée sur carte à puce). Cela me permet de versionner mes mots de passe sans risque dans git (et donc de sécuriser une perte), ou d'y avoir accès sans avoir à diffuser ma clef GPG (le token est suffisant).

Comble du bonheur, il est également possible d'utiliser la clef GPG pour ssh, ce qui évite d'avoir à multiplier les clefs autorisées !

Super merci du lien !

J'aime beaucoup ce genre de cheminement, qui part d'un problème complètement anodin, et fini vers une chaine d'erreur touchant plusieurs librairies…

Par contre, il faut savoir naviguer entre les différents projets pour identifier les anomalies, ce qui n'est pas simple du tout.

Bien essayé mais non :) Je suis à mi-chemin entre la version stable et la version testing (prochaine version stable) pour certains paquets.

Quand je regarde le patch et les changements apportés, j'ai l'impression qu'il ne gère pas toutes les branches et qu'il reste encore des appels au code de la GLib. Peut-être que je tombe dans l'un de ces cas là. (mais mes connaissances ne me permettent pas d'aller plus loin). Afin d'être sûr, j'ai installé hier le paquet "xfce4-terminal", qui se trouve en amont dans la liste des terminaux testés par la GLib, et c'est bien celui là qui s'est lancé quand j'ai voulu éditer mon fichier (je trouve ça un peu archaïque de coder en dur les applications dans une librairies, mais bon, c'est pas le sujet…)

Au moins j'ai l'explication désormais, même si le fonctionnement n'est pas normal, le fait de savoir d'où vient le problème est déjà quelque chose de rassurant (les bugs ça existe et c'est normal, ça m'inquiète davantage de ne pas comprendre pourquoi le système ne fonctionne pas comme attendu).

J'ai ouvert un rapport d'incident chez Debian, à suivre !

Bon, j'ai l'impression de voyager dans le temps…

J'ai trouvé un ticket qui correspond à mon problème mais qui aurait été clos en 2018 ! Il faut maintenant comprendre pourquoi j'ai encore le problème sur mon PC !

Bon, je pense avoir trouvé la source de mon problème : la Glib utilise une liste de terminaux dans une liste pré-définie en dur dans le code :

https://github.com/GNOME/glib/blob/master/gio/gdesktopappinfo.c#L2581

Par contre, je n'ai aucune idée de savoir comment contourner ce problème, ni même a qui le remonter !

Malheureusement, il n'est pas pris en compte quand je fais ça depuis mon navigateur de fichier, et c'est bien là mon malheur.

Je vais tester avec autre chose que pcmanfm-qt. Le problème vient peut-être de là…

J'utilise i3 comme WM, avec lxqt comme bureau (réduit presque au minimum). Mais plus je suis en train de chercher, plus j'ai l'impression que le problème vient du navigateur de fichier — où d'un composant dans la chaîne qui aurait stocké une liste de terminaux qques part, sauf que j'arrive pas à mettre la main dessus, et ça m'énerve ! :)

Bonjour,

Merci pour ton retour, je suis sous debian.

Le comportement avec xdg-open diffère :

• Quand je lance la commande depuis un terminal, ça me lance l'éditeur dans le terminal courant (quel que soit ledit terminal)
• Quand je lance la commande depuis un prompt au niveau du gestionnaire de fenêtre : ça m'ouvre l'éditeur dans le terminal par défaut

Par contre je ne sais pas ce que lance le gestionnaire de fichier au moment où je clique sur l'icone de mon fichier…

J'ai essayé de lire le code de xdg-open pour voir comment était traité le cas du Terminal=true mais n'ai pas réussi à trouver où cela était géré.

Je me souviens de ton journal ! À l'époque je ne connaissais pas Graphviz, j'ai vraiment pris en claque en voyant ce que l'on peut faire avec. Pas loin de 15ans après, ça fait toujours parti des outils que j'installe sur les PCs qui me passent sous la main.

Quand j'y repense, je crois que LinuxFr m'a vraiment accompagné dans mes explorations !