moi1392 a écrit 728 commentaires

Je ne sais pas vraiment quel est son status officiel.
Je cherchais les symboles de debogage associés à gcc avec un simple "apt search xx | grep dbg" et impossible de les trouver, au cours de mes recherches j'ai fini par tomber sur ce repo.
Les paquets de symboles que je cherchait y sont présent, ainsi que plein d'autres, et à jour avec debian sid, donc je suppose qu'ils sont activement maintenus.

Ce que moi j'ai compris de ce journal, c'est qu'il se plaint qu'un changement aussi important, certes annoncé il y a un an lors de la publication de Debian 12, ne soit pas rendu plus manifeste quand sa connaissance est indispensable.

À chaque reconstruction d'initramfs (à chaque mise à jour du kernel, d'initrd, de grub et de certains outils), tu as un gros tas de lignes t'indiquant que certains firmwares sont possiblement manquants, dont les firmware de gpu amd en question.
Une recherche très rapide t'indique le problème et comment le résoudre.

Je ne m'avance pas trop la dessus car je n'en suis plus sûr à 100%, mais il me semble qu'au chargement du module kernel, tu as aussi ce genre de message, donc tu l'as dans ta console au démarrage, qui certe défile relativement vite, mais tu peux aussi le retrouver dans les logs, par exemple avec journalctl ou dmesg.

Je suis d'accord qu'il faut faire un peu attention pour voir ce genre de choses, mais quand on installe debian ET que quelque chose liée à un pilote de matériel ne marche pas, prendre le temps d'au moins lire les logs du kernel au démarrage pour voir s'il n'y a pas un message d'erreur au chargement du module, c'est quand même un minimum.

Il y a un nouveau split de package récemment qui m'a surpris, c'est celui pour les paquets avec les symboles de debogage.
Je comprends l'idée de le sortir du repo principal car très peu de gens les installent, par contre je n'ai pas réussi à lui trouver de mirroir j'ai donc du me mettre sur l'url de base http://debug.mirrors.debian.org

De plus, et je n'ai pas trouvé de raison argumentée à cela (je n'ai pas beaucoup cherché non plus…), la nomenclature des noms de paquets a aussi changé, au lieu d'être nom-du-paquet-dbg, c'est maintenant nom-du-paquet-dbgsym

Voila le lien sur une doc officielle (pas très exhaustive je trouve) si quelqu'un en as besoin : https://wiki.debian.org/DebugPackage

Je ne sais pas trop quoi penser de l'article, je suis d'accord avec tous les exemples, mais il me titille quand même.

Déjà pour l'histoire des macros, évidemment, ce sont de très mauvaises macro à éviter absolument, mais ça n'a rien à voir avec le sujet de free, mais dans d'autres contextes (et l'exemple de la macro max le montre bien), ce genre de macro est à proscrire.

Ensuite le tests avant le free, perso je me suis reconnu dans le cas "débutant", je me souviens encore dans mes jeunes années de dev quand j'ai appris que free (pour rêtre honnete, dans mon cas c'était delete du c++) vérifiait si le pointeur n'était pas null et j'ai arreté de faire la vériication à chaque fois.
Mais dans la pratique, il arrive souvent que dans les phases de nettoyage on ne fasse pas qu'un free, exemple :

if ( ptr != NULL ) {
    do_something(ptr);
    free(ptr);
}

Alors oui, le free peut-être sorti du bloc if, mais en terme de lisibilité, je trouve ça vraiment mieux de l'y laisser.

Et pour ce que tu appelles la programmation défensive (bizarre comme terme, ça existe la programmation offensive où on cherchce volontairement à se mettre dans des situations compliquées ???) c'est pareil : dans la pratique, mettre le pointeur à NULL c'est un flag qui permet de connaitre un état local pour le gérer correctement quand je ré-entre dans ce code, je le fait très régulièrement et je trouve que c'est une pratique très saine, simple d'utilisation et très utile.

Pour en revenir à l'article, j'ai l'impression que l'auteur prend des cas d'utilisation pourris pour appuyer ses arguments. Je peux faire à peu près pareil avec beaucoup de pratiques de code, de fonctions ou d'objet des librairies standard. Oui, quand on s'en sert mal, ç'est pas bien. (variante du : "c'est pas gentil d'être méchant")
Des questions intéressantes, pour toute critique sur des pratiques de code, seraient plutôt :
- est ce qu'il est trop facile de mal s'en servir même pour quelqu'un de pas complètement débutant ?
- quels sont les cas utiles, intéressants, et est-ce qu'il sont assez importants pour accepter qu'il y ait des limitations, revers à l'utilisation.
- est ce qu'il n'est pas plus intéressant de comprendre dans quel contexte cela est utile, pour savoir dans lesquels on peut s'en passer ? (typiquement l'idée du livre sur "design patterns" pour des cas un peu plus complexes et précis)

Je n'ai pas testé cela, et je viens de voir qu'elle était disponible en live usb, je le tenterai ce week end pour voir et je repasse poster mes résultat ici au passage.
Merci pour la suggestion.

Il m'est arrivé d'utiliser epoll et d'être un peu frustré par ses limitation (surtout le fait que certains événements kernel ne sont pas accessibles via des file descriptors), je suis alors allé voir le lien wikipedia d'io_uring, et j'ai l'impression qu'il a été implémenté pour réglé un problème de performances, et pas de fonctionnalités.

Ce qui m'intéresserait, ça serait de pouvoir gérer les signaux via epoll (ou io_uring) comme un fd normal.
Il y a eu, il fut un temps, le projet signalfd, mais je n'ai pas l'impression qu'il ait abouti.
Quelqu'un a des news sur ces sujets ?

Tu peux essayer KDE Connect qui permet à la base d'échanger entre un ordiphone et un PC, mais qui fonctionne également très bien entre 2 PC (je m'en sers souvent quand je bosse sur portable et fixe pour échanger le presse papier)

Effectivement, on peut discuter du rapport entre réseau aérien et réseau ferré.
La question qui se pose alors, et à laquelle je n'ai pas la réponse est : Si on mets tout le volume (quand c'est possible) d'un des deux réseau sur l'autre, quel est le bilan
global ?

Un second point non négligeable, est que des gares, on peut en faire tous les 5/10 km. Pour un réseau dense, l'avion c'est un peu moins adaptable.
On en revient donc au point 1, à partir du moment ou le réseau ferré existe déjà pour le réseau dense (et encore, une gare tous les 50/100 km, on peut arguer que c'est du réseau "dense" comparé à de l'aviation), ça n'ajoute que la ligne de chemin de fer longue distance.

Même si l'avion est un facteur d’émission de gaz à effet de serre important par rapport à d'autres moyens de transport, il a un avantage, il n'a besoin que de peu d'infrastructure (pas de route, ou de voies ferrées) au sol. Il y a le besoin d'aéroports, d'une surface au sol négligeable.

Je ne réponds que sur ce point car je suis largement incompétent sur les autres.
Mais pour y aller à l'aéroport, il les faut ce routes. Et AUCUNE route ne disparait jamais parce qu'elle est remplacée par un transit aérien.
Il me semble donc que ça n'est en aucun cas un facteur à mettre dans les avantages ou le bilan, en terme pollution carbone, de l'aviation.

Tu peux tenter un dépôt de plainte pour refus de dépôt de plainte, mais c'est pas sûr qu'il soit accepté. (apparement c'est assez fréquent, alors ils ne se déplacent plus)

Tu peux aussi tester la clé usb sur une autre machine, sans faire l'installation bien sur, mais juste pour t'assurer qu'elle est correctement construite et qu'un PC arrive à démarrer dessus.
ça éliminera cette potentielle erreur.

Hello, ton outil à l'air sympa, je n'ai pas encore pris le temps de le regarder de plus près, il y a tout de meme 2 choses qui m'intéresseraient comme features :

• Les blacklist : avec des classes d'ip : au bout d'un mometn, j'aimerais bannir des classes d'ip entières, quand 5, 10 voir 15 ips de la meme classe se font bannir et qu'il s'agit d'ip d'un pays obscur de l'autre bout du monde, je pense que j'ai assez donné et que je peux me permettre de tout bannir, et définitivement. C'est à dire inscrire ces classes d'ip en ban définitif sans possibilité d'unban à mon d'une intervention manuelle de ma part.

• Les whitelist : il m'arrive de me tromper dans mes tentatives de login, quand je suis dans mon reseau local, je n'ai pas forcément envie d'etre aussi strict, une règle un peu plus souple en terme de retry et de temps de ban pourrait etre mise en place.
  Cet intéret est limité et case gueule et je ne pense pas m'en servir personnellement, mais il y a un autre intéret aux whitelists que je décrit dans le point suivant.

• Intéret combiné des whitelist avec les blacklist :
  Je me suis écrit (en c++) un petit bout de code qui merge des ip en classe d'ip que je lance régulièrment sur le résultat de fail2ban-cli status [sshd ou autre], l'intéret d'avoir des whilelist dedans est aussi d'éviter de bannir automatiquement toute une classe d'ip qui contiendrait l'ip de mon boulot et/ou d'endroit dont je sais me connecter régulièrement.
  Mon code est un peu tordu, certainememt buggué et évidement mal testé et documenté, mais j'arrive à m'en servir pour moi, si ça t'intéresse et qu'il te donne des idées, je peux te le filer. (licence balec, c'est du code écrit à la méthode rache (c))

Techniquement, même 9 femmes pour un bébé, si on suppose que tout le processus est "naturel" (pas de fécondation in vitro ni de clonage à partir d'une cellule souche), il faut qu'au moins un homme soit impliqué à un moment pour que cela marche, sinon 9, 12 ou 46 mois n'y changent rien à l'affaire.

Sa réponse est donc erronée.

D'ailleurs il réponds quoi pour savoir combien de temps il faut à une femme (assistée par un homme ou plus, soyons fous) pour faire 2 bébés ? Où à 3 femmes pour faire 5 bébés ?

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 ?