moi1392 a écrit 740 commentaires

je suis aussi tombé sur cette page quand j'ai cherché :)
Mais je pense qu'ils se sont inspirés de l'original qui est un peu plus ancien.

Indice : ça vient d'une bd

Et il parait que ça se marie super bien avec la confiture d'épluchure de saucisson ! Mais d'après certains, c'est salé.

PS: J'ai pas trouvé la ref en ligne pour mettre un lien, un pot gratuit à qui retrouvera l'origine.

En effet j'ai allègrement zappé la phase d'optimistion du compilateur et du linker ;)

Ça doit être parce que je debug… sur des builds compilés en debug et qu'il m'est arrivé de voir de genre de dépassement et de constater l'écrasement des variables adjacentes ;)

juste 2 remarques

(*(c(void)))[10] : tableau de 10 pointeurs de fonction 'c' sans paramètre, retournants un entier.

Si je ne dit pas de bêtises, en C, les paramètres des fonctions n'ont pas besoin d'être déclarés dans les pointeurs sur les fonctions.
D'ailleurs, à l'inverse du C++, les paramètres de fonctions ne sont pas manglés avec le nom de la fonction dans la table des symboles (c'est ce qui permet la surcharge de fonctions en C++ et pas en C)

*d[2] = {&a} : tableau d (2 éléments) de pointeurs int initialisés avec l'adresse a qui est indéfinie à ce stade.

elle est indéfinie mais représente la première variable locale si on est dans le corps d'une fonction. Du coup indirectement on peut modifier la valeur du pointeur "b" qui est déclaré constant par exemple comme cela :

*(d[0] + 1) = &a

et hop, b pointe maintenant sur a lui aussi ;)
à priori ça marche aussi si on est pas dans une fonction, c'est juste pas une adresse de la pile mais dans la zone des variables globales du binaire. (.bss s'il me reste des souvenirs en état, mais là vraiment faut aller vérifier, c'est plus de mon âge ces conneries)
Et dans ce dernier cas, le linker devrait pouvoir la déterminer et la fixer sans avoir besoin de code dynamique si on compile un exécutable et pas une librairie.

Si le PC chauffe sous kde, il y a de fortes chances que ça soit kwin dont le contexte 3D est rendu de façon logicielle.
peut-être un problème de pilote/config de ta carte graphique.

En lisant le titre de la dépêche, j'ai compris que l'idée était de faire un outils qui gomme les différences d'API entre les environnements de bureau.
Mais après lecture il me semble que c'est plutôt un outil qui facilite et uniformise l'utilisation d'API, quelles soient spécifiques ou non.

Est ce que ça serait dans les plan de gommer ces différences quand il y en a, par exemple, si une commande particulière est disponible via une API sous gnome et une différente sous kde, proposer une commande lidecli unique qui fait le bon appel selon l'environnement en cours d'utilisation ?
Je n'ai pas l'impression que ça soit l'objectif de l'outil. Mais c'est quelque chose qui pourrait se greffer par dessus.

Ce mot-clef bien connu a deux effets : il suggère au compilateur de procéder à l’expansion du corps de la fonction

Il me semble avoir lu à plusieurs reprise qu'il y a bien longtemps que le mot clé inline n'était plus utilisé par le compilateur pour décider quelle fonction inliner.

alors je suis allé voir la doc pour sourcer la bêtise que je m'apprétais à écrire dans ce message et….. c'est pas clair.

si je m'en tiens à la doc de gcc sur le mot clé inline il semble qu'il est bien utilisé pour définir quelle fonction inliner.

Par contre, quand je vais voir les options de la ligne de commande de gcc il explicite bien à chaque fois que c'est sur la base d'heuristiques du compilateur que sont choisies quelles fonctions inliner.

On peut arguer qu'un mot clé dans le code est une heuristique, mais si ça n'était que cela, je pense qu'il aurait suffit d'écrire ça dans la doc des options.

quelqu'un aurait une référence sur ce que fait exactement gcc sans aller lire le code ?

ça me fait penser à cette histoire, mise en ligne justement cette semaine :
https://unodieuxconnard.com/2023/05/26/jamais-sans-ma-vodka/

Oui, les humains aussi font parfois de la merde incompréhensible…

*** Breaking News (du futur) ***
Les IA savent maintenant identifier et reconnaitre le sarcasme.

Pour ne pas la chiffrer il faut avoir bien ignoré ton logiciel qui t'a dit que ce serait bien que tu mette une passphrase. Je comprends que dans certains cas, on puisse trouver contraignant de chiffrer sa clef (avoir un agent ssh lancé avec ta session demande un peu de configuration)

D'accord, on ne parlait pas de la même chose alors.
Mais du coup en quoi est-ce différent (dans le sens plus sécurisé) que de mettre un mot de passe très long (genre une clé rsa en base64) avec un gestionnaire de mots de passes ?

Sans mettre en cause la probité de tes collègues

ça après techniquement c'est plus mon problème…

C'est les mêmes qui ont l'accès root aussi sur les serveurs en question ?

Non, mon utilisation était de me connecter de temps en temps CHEZ MOI depuis mon boulot pour des raisons persos. Genre récupérer des vidéos à partager avec les collègues (il n'était pas rare que le temps de la pause de midi on se fasse un épisode ou deux d'une série quelconque en mangeant au bureau)
Utilisation complètement illégitime, j'en conviens :⁾

Ton ordiphone peu utiliser une clef,

Quand tu le prévois à l'avance oui. C'était pas mon cas.

surtout si tu as des besoins irrésistibles de te connecter n'importe où.

Alors oui, si on supprime le besoin de se connecter, tu peux même virer le serveur ssh c'est encore plus sécure, et ce, sans l'avis d'un expert :p

Faut faire attention avec ce genre de sentiment. Personnellement je ne m'autorise pas ce genre d'hypothèse sans qu'un gars un minimum plus sérieux que moi en sécurité le confirme.

JE suis d'accord sur le fond, et j'ai bien précisé qu'à ma connaissance il n'y a pas de moyen de faire la différence depuis une tentative de connexion à distance. Mais je me comporte comme si les login étaient connus, tout en ne les dévoilant pas.
C'est toujours ça de pris comme disait l'autre.

Je ne comprends pas. Comment pourrait-il accéder à ta clef ?

Alors on ne parle peut-être pas de la même chose quand on parle de clé. Moi je parle d'une paire de clés publique/privé générée sans mot de passe.
Et pour ce qui est de mes collegues, je pouvais leur filer un shell sur ma machine de travail sous mon login sans soucis.
En sachant que ça n'est pas "ma" machine, mais celle de mon employeur que j'utilisais quotidiennement, j'aurais pu faire mon puriste, mais je n'y voyais pas d'inconvénients vu que je m'en servait quasi exclusivement pour bosser et qu'il n'y avait rien de perso dessus. Du coup j'allais au plus pratique quand c'était arrangeant pour bosser.
De toute façon les sysadmin avaient les mots de pass root sur toutes les machines, donc là encore ils auraient pu accéder à ma clé privée très simplement.

Interdire l'accès SSH à root et plutôt gênant pour les scripts de maintenance qui doivent être exécutés à distance. C'est suffisamment sécurisé si l'accès root ne peut se faire qu'avec une paire de clés

Et pourquoi ne pas créer un utilisateur spécifique, mettre tes scripts sur la machine client et mettre soit
1) tes scripts en suid root
2) voir si tu peux t'en sortir avec les droits de fichiers/capabilities du noyau ?

Jamais rencontré de cas de besoin de mot de passe.

j'ai eu besoin d'acceder à ma machine (je ne sais plus pour quelle raison) de l'extérieur une fois, j'ai installé une appli ssh sur mon ordiphone et me suis connecté en ssh.
Sans mot de passe j'aurais été coincé.

L'usage de clef n'est pas simplement immensément plus sécurisé que n'importe quel mot de passe dit fort, il est aussi infiniment plus pratique à l'usage.

Je ne suis pas d'accord là dessus.
Dans mon ancien boulot, je me connectais de temps en temps chez moi par ssh, et je n'ai pas envie qu'une personne qui utilise "ma" machine, car oui, il m'arrivait de laisser ma machine à un collegue sans être derrière lui, puisse se loguer sans soucis chez moi.
Et ceci est valable du coup pour nimporte qui qui aurait eu acces à cette machine, de façon légitime ou pas.

Au final la bonne solution est un compromis.
Chez moi je n'ai qu'un utilisateur auquel je peux me connecter par ssh avec mot de passe. Il est assez fort pour tenir une attaque brute force, si tant est que l'on connaisse le login, du coup indirectement ça "augmente" le force du mot de passe car il me semble qu'openssh ne donne pas de réponse différente pour mot de passe ou login incorrect (corrigez moi si je me trompe) et je n'ai pas vu de side attack qui puisse aider là dessus (genre temps de réponse, etc…)
je couple à un fail2ban "renforcé" (banni plusieurs jours au bout de 2 erreurs) et j'ai une blacklist (longue comme un bras de la voie lactée…) dans laquelle je mets régulièrement le log des ip de fail2ban.
Dans le temps il me semble que j'avais aussi trouvé le moyen de dire à ssh (ou à pam ?) d'ajouter un lag de 1 seconde entre chaque tentative d'authentification (ce qui démoli d'office le brute force, sans être gênant à l'utilisation, 1 seconde c'est rien quand je me trompe), mais je n'arrive plus à mettre la main dessus.

Approximativement 57,5%

Pour moi c'est en fait un sondage qu'il ne pouvait pas perdre

Moi je vois surtout ça comme un moyen de séléction simple et efficace pour la prochaine tournée de licenciement…
En effet, il gagne à tous les coup !

Un point important signalé sur le bug tracker debian :

BTW, all those who added symbolic links to make FF 108 work
should remove them before upgrading the firefox package, otherwise
there is a risk to have the same kind of issue.

Pour ceux qui ont mis en place ce workaround, n'oubliez pas de virer vos liens symboliques lorsque firefox sera mis à jour.

J'ai déjà eu le souci de vouloir installer un paquet au moment où ses dépendances étaient cassé dans sid.

De mon expérience, si vraiment tu ne veux pas attendre, ce qui marche le mieux c'est d'aller chercher une version plus ancienne dans les archives debian (les .deb) de de l'installer à la main.
Il faut 2 ou 3 passages de téléchargement manuel par les archices pour aller chercher toutes les dépendances qui ne sont cassées, et se taper quelques coups de dpkg pour voir ce qu'il manque, et le reste viens depuis l'archive par apt.

Vous êtes violent dans votre IUT… bon après j'ai une policy par défaut en drop sur les paquets tcp de connexion en entrée, c'est pour ça que je ne me gêne pas trop là dessus ;)
Mais oui c'est un coup à le faire par réflexe un jour ou sur une machine où je serai moins safe, je vais m'efforcer de changer cette habitude, merci :)

mais xhost + est une très mauvaise idée

Oui c'est vrai. Je ne sais pas pourquoi mais quand je tente un xhost +localhot ça ne marche pas comme je m'y attends.
Dans le temps j'étais un peu plus bourrin et je copiais le cookie d'authentification (.Xauthority) depuis le home de l'user connecté vers l'autre. Je ne suis pas certain que ça soit une meilleur pratique et j'ai arreté.
Je vais rententer ça en m'appliquant un peu plus.

Sinon ssh -X te fait passer en indirect rendering pour OpenGL et tu te retrouves avec de l'OpenGL 1.1 (ça à peut-être changé depuis), en plus certaines applis alakon (firefox pour ne pas le nommer) trouv(ai)ent le moyen de foutre la merde et de se lancer localement avec l'utilisateur local, au final ça ne m'a jamais vraiment convenu sauf pour des trucs simples.

PS: Pour firefox j'avais essayer un ssh -X à travers internet depuis un ami vers chez moi pour essayer de me connecter à un site avec mon ip de chez moi et pas celle de chez lui.
Je hais les application qui essayent de faire des trucs "intelligent" en ne se comportant pas comme leur environement leur indique…

je me doutais bien que c'était la solution, mais je ne voulais pas le faire sans savoir pourquoi.
En regardant de plus près, le fichier /dev/dri/renderD128 utilise des attributs de filesystem étendu et l'user logué est ajouté en rw sur ce fichier. Je n'ai pas creusé pour savoir qui fait ça, je suppose que c'est dans la stack Xorg/dri quelque part.

De plus, la doc officielle debian indique bien que ce groupe sert à l'accès au périphérique de rendu.

Donc voila, j'ai ajouté mes utilisateurs dans le groupe et le problème est réglé ;)

C'est marrant parce que de ce que tu décris de l'image, je ressens le contraire de ce que tu dis.
Tout d'abord, je précise que je n'ai pas vu l'image, et je ne suis pas du tout au courant de la réalité de la vie en Cote d'Ivoire dans sa globalité.
Mais :

Pourquoi montrer un des quartiers les plus pauvres de Dakar, sans montrer les plus modernes et urbains ?

Par ce qu'il y avait de la place que pour une image ? Parce que c'est une image pour illustrer un problème, donc on montre le problème ?
Je fais la différence entre une image d'illustration, et une image de justification. En effet, dans ce contexte une image ne peut pas justifier un problème général, mais elle peut l'illustrer. donc si problème il y a bien (et ça, je n'en sais rien), l'image joue parfaitement son rôle.

Aucune information sur les quartiers riches et touristiques, comme la petite côte ou la pointe d'Amaldie.
Pas une seule ligne sur les richesses naturelles et minières du Sénégal, que nous exploitons pourtant.

Tout pays a des endroits et des richesses, si tu veux illustrer quelquechose de négatif et que tu montres des trucs positifs, c'est tes images qui sont déplacées et qui trompent.

Je trouve la présentation partielle et malsaine, comme une justification de la colonisation entre les lignes.

Du coup (je déteste cette expression et je l'utilise beaucoup trop…) je ne vois pas comment tu arrives à cette conclusion. Si comme tu l'as fait remarqué, il aurait été plus honnete de montrer les quartiers riches et les richesses du pays, tu aurais plutôt fait l'apologie de la colonisation et du pillage des richesses avec toutes les choses "bien" qu'elles ont apporté. En sous entendant au passage que les quartiers riches de Dakar sont quelque chose de "bien", donc que le projet de colonisation, sans parler de sa réalisation, était une bonne idée au final.
Alors qu'en illustrant les endroits les moins agréables, tu montres justement qu'un pays qui pourtant possède des richesses a une population qui vit dans une grande pauvreté et précarité. Du coup à bat les colonisateurs et les pilleurs !
Au final, et sans l'avoir vu mais seulement avec ta description, l'image illustre plutôt bien ce que tu dénonces, de mon point de vue biaisé à moi.

Je pense que OpenGL fonctionne parce qu'il obtient l'accès au GPU via X/GLX alors que Vulkan requiert l'accès direct.

Je pense que c'est ça aussi.

Il faut que ton user2 soit dans le groupe render.

Tu as vu cette info quelque part ou tu réponds avec les infos de mon message ? Si tu as lu jusqu'au bout, ni user1, ni user2 sont dans le groupe render et je n'ai aucune idée de comment l'user logué dans la session graphique arrive à ouvrir ce fichier.
Il faudrait en effet que je creuse de ce coté là mais j'espérais qu'il y aurait un moyen "officiel" (à la xhost par exemple) que quelqu'un connaitrait ici.

tu peux faire le test toi même avec glxgears pur OpenGL et vkcube pour Vulkan.
vkcube est compilé avec X sous debian.

bien joué :)
T'as fait comment pour libpng ? je l'ai fixé chez moi si tu as besoin.

quand j'essaie de le lancer sur un système 64-bit, le terminal m'informe gentiment que mon fichier n'existe pas

ça c'est une erreur classique pas classique du tout, c'est généralement quand tu fais l'édition de lien dans un environnement chelou, et que la lib ld.so référencée par ton executable n'est pas trouvée ou n'est pas de la bonne plateforme (32 vs 64 bits).

tu peux essayer de l'ouvrir (l'executable, pour toi le fichier "wesnoth") avec un éditeur de texte (évite les trucs graphique, less est très bien pour ça) et pas loin du début tu vas voir le chemin en dur vers la lib "ld.so.quelquechose" (par exemple /lib64/ld-linux-x86-64.so.2 pour les binaires de ma distribution)
vérifie que le chemin existe et qu'il pointe bien vers un loader 64 bits (c'est souvent un lien symbolique)
s'il n'existe pas, facile, tu crées un lien symbolique vers le bon fichier, s'il existe et pointe vers du 32 bits… hheeuu… bonne chance. Je te déconseille fortement de le remplacer, tu auras juste TOUS tes binaires 32bits qui ne démarrerons plus, y compris les outils standards (ls, cp, …) ton système deviendra juste complètement inutilisable.

je m'auto-auto répond (pour une auto-auto-satisfaction récursive !)
c'est un

#include <algoritm>

qui manque dans src/campaign_server/campaign_server.cpp