Posté par freem .
En réponse à la dépêche FreeBSD 11.1.
Évalué à 4.
Dernière modification le 01 août 2017 à 10:41.
J'ai vu plusieurs points intéressants pour les dev:
Notre bmake à nous intègre la version 20170510, en coopération avec NetBSD.
bmake, c'est une alternative à gnu make? Quels sont ses points d'intérêts techniques (donc, hors licence)?
Venu de NetBSD, getaddrinfo(1) a débarqué.
Euh... vous utilisiez quoi ces 16 dernières années, du coup? Je me souviens vaguement d'une autre fonction pour faire le même genre de trucs, sauf que de mémoire (impossible de me rappeler le nom, c'est pas possible ça!) IPv6 n'était pas supporté et elle apportait des problèmes de sécurité...
Et pour le "ces 16 dernières années", je me base sur le fait que "Conforming To POSIX.1-2001" signifie pour moi que le standard en question date de 2001. Je me trompe peut-être cela dit.
Dans l’idée de promouvoir lldb, the debugger, les débogueurs gdb et kgdb sont dépréciés.
Déprécier gdb, pourquoi pas. Faut dire que je ne suis pas fan de readline qui a des comportements aléatoires sur mes machines (genre "la commande grep est inconnue" dans bash, ou équivalent sous gdb, parce que cette stupide lib de readline semble ajouter des caractères invisibles suite à une typo que je corrige, mais seulement de façon aléatoire! grrr) et donc de tout logiciel qui se base dessus.
Par contre, je suis intrigué pour kgdb: je ne m'en suis certes jamais servi, n'ayant jamais eu l'occasion de hacker du kernel, mais j'aurai tendance à penser que débug un kernel nécessite des outils spécifiques, alors que je soupçonne lldb d'être généraliste, à l'instar de gdb.
Pour finir sur gdb/lldb... quid des frontends? La dernière fois que j'ai cherché (il y a moins d'un an) je n'ai trouvé aucun frontend correct. Ce n'est pas comme s'il en existait beaucoup pour gdb, mais j'arrive au moins à des résultats décents avec cgdb.
J'avais vu que lldb avait une interface ncurses intégrée, mais j'ai été totalement incapable de m'en servir, et pas foutu de trouver la moindre doc à ce sujet non plus!
Enfin, de toute façon, le fait de passer à clang/llvm rends la l'obsolescence de gdb inévitable: je ne compte plus les emmerdes que j'ai eues à débug du binaire clang avec gdb, alors j'imagine que la réciproque doit être vraie également.
Mis à part ces points de dev, j'ai vu plusieurs fois l'idée d'une collaboration avec NetBSD?
Je sais bien que le monde du libre est... libre, mais j'avais toujours imaginé les *BSD assez compartimenté, donc ça m'a surpris.
Il y a un objectif à plus moyen terme derrière, ou c'est juste accidentel?
Je sais que la philosophie de Net et Free BSD est très différente, mais peut-être que plus d'outils pourraient être partagés, ça serait pas mal.
# code
Posté par freem . En réponse à la dépêche FreeBSD 11.1. Évalué à 4. Dernière modification le 01 août 2017 à 10:41.
J'ai vu plusieurs points intéressants pour les dev:
bmake, c'est une alternative à gnu make? Quels sont ses points d'intérêts techniques (donc, hors licence)?
Euh... vous utilisiez quoi ces 16 dernières années, du coup? Je me souviens vaguement d'une autre fonction pour faire le même genre de trucs, sauf que de mémoire (impossible de me rappeler le nom, c'est pas possible ça!) IPv6 n'était pas supporté et elle apportait des problèmes de sécurité...
Et pour le "ces 16 dernières années", je me base sur le fait que "Conforming To POSIX.1-2001" signifie pour moi que le standard en question date de 2001. Je me trompe peut-être cela dit.
Déprécier gdb, pourquoi pas. Faut dire que je ne suis pas fan de readline qui a des comportements aléatoires sur mes machines (genre "la commande grep est inconnue" dans bash, ou équivalent sous gdb, parce que cette stupide lib de readline semble ajouter des caractères invisibles suite à une typo que je corrige, mais seulement de façon aléatoire! grrr) et donc de tout logiciel qui se base dessus.
Par contre, je suis intrigué pour kgdb: je ne m'en suis certes jamais servi, n'ayant jamais eu l'occasion de hacker du kernel, mais j'aurai tendance à penser que débug un kernel nécessite des outils spécifiques, alors que je soupçonne lldb d'être généraliste, à l'instar de gdb.
Pour finir sur gdb/lldb... quid des frontends? La dernière fois que j'ai cherché (il y a moins d'un an) je n'ai trouvé aucun frontend correct. Ce n'est pas comme s'il en existait beaucoup pour gdb, mais j'arrive au moins à des résultats décents avec cgdb.
J'avais vu que lldb avait une interface ncurses intégrée, mais j'ai été totalement incapable de m'en servir, et pas foutu de trouver la moindre doc à ce sujet non plus!
Enfin, de toute façon, le fait de passer à clang/llvm rends la l'obsolescence de gdb inévitable: je ne compte plus les emmerdes que j'ai eues à débug du binaire clang avec gdb, alors j'imagine que la réciproque doit être vraie également.
Mis à part ces points de dev, j'ai vu plusieurs fois l'idée d'une collaboration avec NetBSD?
Je sais bien que le monde du libre est... libre, mais j'avais toujours imaginé les *BSD assez compartimenté, donc ça m'a surpris.
Il y a un objectif à plus moyen terme derrière, ou c'est juste accidentel?
Je sais que la philosophie de Net et Free BSD est très différente, mais peut-être que plus d'outils pourraient être partagés, ça serait pas mal.
PS: pardon pour le pavé