freem a écrit 4934 commentaires

Je suppose que le point est que ça ne génèrera pas un makefile qui gère les libs aussi souplement qu'un makefile à la main qui utilisera probablement pkg-config.
Je ne fait que supposer, ici.

Ma foi, je ne savais pas que c'était un format interprétable directement par make que ça crachais, je ne connaissais la fonctionnalité que grâce à la doc de ninja, je n'ai jamais eu la curiosité d'ouvrir ces fichiers. Merci de l'info.

Lors de mises à jour, je suis régulièrement consulté pour savoir si je préfère ma version de /etc/vim/vimrc, avec un outil permettant de voir le diff. Donc je suppose qu'en effet, il aurait été possible de demander.

J'imagine que le /etc/apt/sources.list est exclut d'une manière ou d'une autre? Possiblement historique?
Après tout, il est aussi généré par le système, et je n'ai jamais eu cet outil de diff dessus (et pourtant, j'ai une vieille habitude de le modifier, même si je sais que je devrais utiliser /etc/apt/sources.list.d/… j'essaie, mais les habitudes sont dures, et le changement pas si pertinent).

ici

supprimé, parce que je disais la même qu'un autre.

Ce paquet est, en effet, très bien intégré… pour les installations 32 bits, parce que les gens de valve ne sont apparemment pas capables de compiler leurs trucs pour du 64 bits, en 2024. Pardon, 2022 ou 2023, parce que Debian, c'est vieux.

Non, j'ai juste mal lu, désolé.

J'ai mal lu ce passage:

Pour un usage général, le plus simple est d’utiliser l’un des éditeurs de texte fournis avec macOS. Si vous souhaitez utiliser un éditeur de texte graphique, servez-vous de TextEdit (dans le Launchpad). Sinon, utilisez l’un des éditeurs en ligne de commande inclus avec macOS

Pour ceux qui, comme moi, se demandaient ce que pouvait bien vouloir radio-france à la Forme de Backus-Naur qui est probablement plus connue du public de linuxfr :D

Et alors? Je peux aussi installer vim, emacs et nano sur windows, ce n'est pas pour autant qu'ils sont installés par défaut..

Et surtout, ça n'a, mais alors, rien à voir avec 1984, univers dans lequel l'art n'est pas banni (mais instrumentalisé, si ma mémoire est bonne, après la scène de départ ou le héros dirige sa colère contre le Parti et non contre l'ennemi désigné, il y a une scène ou le mode de vie des gens pas rebelles est décrit, et la musique y est clairement mentionnée).
Ça serait bien plus proche de Farenheit 451…

Mais quel idiot, j'ai oublié cette option! Bien vu! Un DVCS peut prendre plusieurs sources, pas forcément fixes, en plus, en fonction.

Note préliminaire: j'enchéris sur sobriquet et suis d'accord.

C'est moi, ou les tech ne sont pas considérés comme informaticiens ici?

Non, parce que bon, je pense qu'il y a plus de tech que d'admins et de dev, hein, et les techs n'ont pas du tout de raison majeure d'utiliser vim/emacs. En fait, c'est pire, ils doivent souvent faire avec juste notepad de windows…

Je pense qu'environ 1% des informaticiens sont des devs ou admins, et dans ceux-la, oui, ok, peut-être que 50% ont un intérêt à utiliser vim/emacs. Les autres n'y ont même pas accès! Pour rappel, windows est toujours un environnement informatique majeur, c'est pas parce qu'il y a moins de PC vendus qu'il y a moins de windows utilisés.

D'ailleurs, macOS, ça embarque vim ou emacs? M'étonnerais, et pourtant c'est un UNIX.

On pourrait aussi déduire les vieux barbus qui ont dû à une époque de leur carrière apprendre à maîtriser vi, mais qui sont bien contents de recourir à d'autres outils aujourd'hui.

Pour ma part, je ne suis pas (encore) un vieux (et je me tond, donc pas barbu), mais j'ai appris a utiliser vim volontairement il y a ~15 ans. Scintilla existait déjà (la base de notepad++ et de code::blocks, entres autres).
J'y vois plusieurs intérêt, mais ce n'est pas le sujet.

J'ai aussi vu des jeunes sortis de l'école s'intéresser a vim en voyant ma façon de bosser (en tant que dev C++ sous debian), mais quand ils sont passés à vim, ils sont aussi et surtout passés à i3, et je pense que c'est parce que je ne connais aucun IDE potable hors DE monolithique (KDE, Gnome, etc) et que i3+rxvt+vim, justement, permets d'avoir un système léger et pourtant bien intégré (les terminaux, ça marche vachement bien avec un bon gestionnaire de fenêtres après tout).

Perso, je pense qu'il est important de laisser chacun choisir sa façon de bosser tant que ça impacte pas l'équipe.

Le reste, sérieux, on s'en fout. Imposer un style de code, par exemple, c'est utile, parce que si fait correctement, on peut utiliser le VCS pour gérer automatiquement la transition de styles, et donc tout le monde peut bosser avec ce qu'il préfère (ok, il y a un impact quand on utilise des outils non-locaux… mais pourquoi faire ça dans un cadre quotidien?).

Et franchement, ce délire d'unification est typique des usines. Sur un chantier, personne ne va dire a un plaquiste de plaquer autrement ou avec d'autres outils, par exemple, j'ai d'ailleurs souvenir que les gens ne prêtent pas leurs outils parce qu'ils les modifient (les manches) pour leurs mains. Hors, vim, justement, est conçu pour… être plus efficace au niveau des frappes. Je suppose, de certaines personnes, au moins.
Ça marche pour moi, je n'ai plus de douleurs à la main droite (non, c'est pas la b… d'ailleurs, je suis pas sourd, mais bien les voyages souris<->clavier) mais ça ne marchera pas pour tous les métiers ou personnes. C'est normal. Les gens ont des usages, cultures et physionomies différentes.

Tellement bien fait.

Les recruteurs et leurs annonces factices ont fait tellement de mal, c'est une bonne chose qu'ils se prennent in DDOS dans la tronche, et pour le coup, c'est bien la première fois que je vois un truc positif de l'IA (j'entend, le buzzword, hein)!

En plus, c'est marrant… pourquoi les recruteurs ne veulent pas recruter d'IA, alors que les patrons ne cessent, justement, de déléguer de plus en plus de tâches aux IAs?

Donc oui, clairement les arroseurs arrosés.

c'est moi, ou ça casse juste l'argument de Raoul Hecky au sujet de pas utiliser de script à la mimine? :)

C'est assez long et complexe à faire

Je trouve la commande sshfs particulièrement simple, moi… plus rapide qu'apprendre à utiliser un nouveau logiciel, en tout cas.
Dans le cas de vi, ok, c'est relativement pertinent, parce que cet outil fait partie d'un standard. Ce n'est pas le cas de beaucoup d'éditeurs de texte, par contre.

Il y a toujours la possibilité de copier mais c'est long et tu multiplie les risques d'erreurs.

Le risque d'erreur bien moche me semble bien plus élevé quand on bosse en direct sur la prod, hein… si l'utilisateur n'est pas habitué aux terminaux, alors il est peu probable qu'il ait configuré ses outils pour avoir un distinguo visuel, et donc, la confusion de machine deviens nettement plus facile, surtout si les machines font partie d'un parc ou les noms sont cryptiques.

Dans le cas des gestionnaires de configuration basés sur un agent (cfengine3, notamment, les autres me souviens plus) c'est effectivement long et complexe a mettre en place, mais dans le cas de drist ou rexify (il y en a d'autres, plus connu, mais… voir parenthèse précédente) par contre, ça n'implique pas d'installer quoique ce soit sur le système distant (enfin, si, ssh, ainsi que rsync pour drist apparemment, ou perl pour rexify) ça n'est pas vrai, et le fait d'utiliser des scripts automatiques permets de pouvoir reproduire la procédure sans risque d'erreur, justement. Donc, 1) on tests sur un serveur de test 2) une fois validé que ça marche comme on veut, on lance le même sur un serveur de prod. C'est nettement moins casse-gueule, à mon avis, que modifier une configuration manuellement sur le serveur de test, puis de prod. Je ne parle même pas du cas ou on "oublie" de tester, hein… (mais je tape pas, j'ai fait. Problème de mauvaise éducation, j'ai longtemps ignoré l'existence de rex&drist après tout)

Sur une machine différente, si je n'ai plus ma conf, alors à la fois le username et le hostname seront blancs, de mémoire (ça change selon la distro, certes, mais au moins dans le cas de Debian, je suis certain que la couleur est dégagée pour le compte root "parce que root a pas besoin d'être distrait par la couleur" ou un true de ce style…). Même si pas blancs, la probabilité que le hostname soit de couleur et longueur différentes de mon habitude est plutôt élevée.

Donc, j'aurai bel et bien un moyen de me rappeler de faire attention: ni mon login ni mon hostname n'aurons la couleur habituelle qui me dit que je suis en sécurité.

Bien sûr, balader son .profile et ses copains sur une clé USB n'est pas interdit non plus, c'est pas gros et c'est pratique, ça évite de devoir se re-taper tous les alias pour la couleur, par exemple.

D'ailleurs la légèreté à la quelle on associe emacs aujourd'hui n'est pas fait exprès.

Après tout, EMACS est un acronyme signifiant: «Eight Megabytes And Constantly Swapping», non?

Je plaisante, mais ce "gentil" (pas trop) surnom montre justement qu'emacs n'était pas léger, à l'époque.

Perso, si l'excuse est l'usage de serveurs/conteneurs/whatever, je dirais qu'il est probablement plus efficace d'installer sshfs, de monter le système distant, et de modifier tranquillement depuis son environnement habituel. Ou utiliser drist/cfengine3/chef/puppet/whatever, aussi.

Selon le rapport d'activité de la DGFiP, le nombre d'agents était de 92 166 en 2022. En nette baisse par rapport aux 124 617 agents en 2009

Sauf que l'outil développé par l'IA a besoin d'être vérifié: hé non, ce n'est pas magique.
Hors, il y a moins de monde.

Les applications de l'IA au monde sociétal sont un truc super expérimental, et ne pas avoir les moyens humains de contrebalancer l'expérimentation me semble en effet super emmerdant. La tech peut être utilisée pour le bien commun, mais je n'ai pas confiance en nos dirigeants pour avoir le type de sagesse nécessaire pour ça, alors que s'il s'agit d'automatiser du racket qui fait rentrer du fric… oui, recourir à la force pour extorquer de l'argent a ceux qui ne peuvent pas facilement se défendre, pour moi, s'apparente a du racket, et le gouvernement dispose de la force.

Je pense personnellement que le plus gros problème de sudo est le fait qu'il s'agisse d'un binaire SUID

(Citation de l'article lié)

Bon, ok, mais dans ce cas, il faudrait "juste" attaquer le problème à la racine, et s'occuper de PAM, par exemple en portant BSDauth qui n'est aujourd'hui utilisé que par OpenBSD? Qui dit "porter" dit "récupérer l'historique des bugfix" au passage, plutôt que de NiH encore un truc qui sera affecté par des failles de sécurités… parce que l'historique du PID1 systemd est pas super reluisant de ce point de vue, il me semble. Je ne connais pas celui de PAM, mais ce que je sais, c'est qu'une tentative d'installer openldap sur ma machine pour l'expérimentation rendait mon shell inutilisable, dmesg indiquant des segfaults…

Je précise que je n'ai jamais utilisé openBSD (et donc bsdauth), mais à vue de nez ça passe aussi par une archi client-serveur, probablement en exploitant la capacité d'AF_UNIX de pouvoir transférer des descripteurs de fichier.
Plan9 à priori a un équivalent, encore plus poussé mais j'ignore entièrement comment ça marche: majordomo je crois?
J'ai essayé de trouver plus d'infos techniques sur le sujet, sans succès :/ (parce que l'idée me plaît beaucoup, à moi. Enfin, pas trop étudié le défunt p9, parce que de toute façon ils doivent avoir recours a des spécificités du kernel ou des patchs de libc.)

OOOOh !!! C'est vrai que c'est LE truc qu'il fallait pour sécuriser son système. Mettre du rouge …

Ca doit être un équivalent des terminaux dont le thème graphique change selon qu'ils soient sous sudo ou non (je crois me souvenir avoir vu ça dans gnome? Il y a longtemps…).

Perso, au boulot, je modifie simplement mon prompt pour que 1) mon username apparaisse en rouge quand je suis UID=0, et 2) mon hostname change de couleur selon la "zone de criticité": bleu pour ma machine, rouge pour la prod, jaune pour mes VMs, etc.

Bref, changer le fond de la couleur du terminal, je parie qu'on peut déjà le faire avec du bash ou zsh…

Les artworks (je préfère ce terme, parce que pour moi il n'y a pas que les artworks qui font partie des assets: il suffit de voir ce que peut faire openmw avec le contenu du jeu d'origine) peuvent être refaits, il y a plusieurs cas de jeux basés sur gzdoom qui pratiquent ça.

mais je le trouve pas très beau face à un Half Life sorti un an plus tôt

Pas surprenant, et je dirais que descent n'a jamais été magnifique point de vue esthétique. Par contre, c'est le seul shooter que j'ai connu dans lequel on pilote un vaisseau spatial dans un labyrinthe. Oui, ça le rend très niche, je pense.

Je me demande si un jeu des développeurs se mettront à utiliser une forme de licence à la mongo pour dire « on exploite X années, puis on refile tout ». Particulièrement intéressant pour les jeux consoles qui meurent avec cette dernière.

J'ai déjà vu le cas, je crois, mais je suis incapable de citer un cas tout de suite, désolé. Ca me reviendra peut-être plus tard, ou je pourrais demander sur IRC, mais… de toute façon c'est plutôt rare, je n'ai vu ça qu'avec de petits projets, et descent me semble pas trop correspondre a ce type de description.

Pour des opérations normales, ça passerais. Par contre, si tu veux lancer des milliers de services (genre, des VPS comme le faisait Pantheon, un des sponsors de systemd à l'époque), ça peut rajouter de la charge inutilement (ne serait que pour faire une boucle sur tout les FD avec select par exemple, même si je suppose que le kernel a peut être des optims à ce niveau).

Certes.

Petit détail ceci dit: select(2) est obsolète, il vaut mieux utiliser poll(2) pour du portable, et pour du non portable, faut voir avec l'OS.

Notamment:

WARNING: select() can monitor only file descriptors numbers that are less than FD_SETSIZE (1024)—an unreasonably low limit for many modern applications—and this limitation will not change. All modern applications should instead use poll(2) or epoll(7), which do not suffer this limitation.

Accessoirement, le truc vraiment bien avec poll(2) c'est qu'il n'y a pas besoin de recréer le tableau a chaque itération, c'est bien pratique. Et puis, pas besoin de macros pour s'en servir, l'interface juste "coule de source".
C'était le moment culturel :)

Dans le cas de systemd, compte tenu de leurs positions, j'ose espérer qu'ils utilisent epoll(2) et non select/poll, justement, parce qu'en terme de perfs c'est mieux, qu'ils disent.
En vrai, je ne suis pas sûr qu'une boucle sur quelques milliers de pollfd soit lente, d'autant plus que si c'set bien fait, il sera rarement utile d'itérer sur la totalité, sauf en cas de gros traffic ou si ceux qui ont un événement sont à la fin. Ok, ça fait un très, très gros "sauf".
Je pense qu'en effet sur un cas de serveur avec plusieurs milliers de daemons/services, systemd sera l'un des meilleurs en terme de performance, ne serait-ce que parce que pas besoin d'allouer 4Kio de RAM pour chaque process comme le ferait par exemple runit (dans le cas d'un linkage statique, hein, ou avec muslC. Parce que link dynamique avec glibc6, c'est direct 750Kio de bouffés par process, non je ne sais pas pourquoi).

Parce que ces autres "calendriers" (conventions, en vrai) utilisent leur propre systèmes de numération, c'est à dire tes RH mettent 01/01/20xx pour le 1er mai quand tu poses un congé?
Quelle boîte étrange.

la persistance de la lactase à l'âge adulte

C'est ça, merci.

En tout cas, l'exemple de la lactase est une exception, parce que l'adaptation humaine récente est assez ennuyeuse,

Question probablement bête, mais la médecine et la plus grande adaptation de la société aux individus nés mal adaptés est peut-être une des causes?
Pas assez de danger, combiné à des compensations techniques, ça pourrais réduire l'efficacité des mécanismes de sélection? Oui, je sais, c'est un terrain glissant niveau éthique.

L'immunité c'est naze, quand c'est trop efficace ça te rend malade aussi (1).

Seuls les non allergiques peuvent l'ignorer, je crois :D

Merci pour les explications.

Déjà pour l'histoire des macros, évidemment, ce sont de très mauvaises macro à éviter absolument

Comme la plupart des macros, en fait.
Dès lors que le bloc "macroifié" n'utilise pas les éléments de syntaxe du pré-processeur (concaténation, stringification, __DATE__, __LINE__, __FILE__,…) alors il vaut souvent mieux utiliser des fonctions, quitte a les mettre dans le header avec un inline bien senti.
Plus facile a aligner, pas besoin de s'emm… avec les continuations de ligne (parce que #define ne travaille que sur une ligne, donc il faut \\ le retour chariot OU faire un one-liner. Dans les deux cas, la lisibilité en prend un coup), se base sur le compilateur qui est plus intelligent que le pré-processeur (type-safety, notamment), isolation des variables (une macro ne limite pas la portée, une fonction si) qui implique qu'on risque moins de "shadow" autre chose par accident parce qu'on a oublié d'utiliser le workaround do { ... } while (false) (ou qu'on a malencontreusement ajouté un ; à la fin, même si ça, au moins, ne générera pas de bugs a ma connaissance)…

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 ???)

Je confirme que ça existe, j'en ai entendu parler à plus d'un endroit. Le concept m'a toujours semblé un peu flou, ceci dit.
Parce que bon, moi aussi, je teste le retour d'erreur de la plupart de mes fonctions… (pas toutes, j'ai souvent la flemme avec printf(), par exemple) et je n'ai pas l'impression d'être spécialement défensif: c'est surtout histoire d'avoir des logs utilisables quand ça va bugguer (parce que ça finit toujours par bugguer), plutôt que de devoir galérer a trouver une repro au pifomètre… puis un log bien fait, c'est quand même plus simple à lire qu'un coredump…

Je suis aussi d'accord sur la remise à zéro du pointeur. C'est un truc qu'il m'arrive de faire, notamment quand j'ai affaire a des conteneurs "fait main": je préfère une RàZ inutile plutôt que passer des heures a trouver d'où viens un bug, tout ça pour m'apercevoir que le pointeur est libéré 2 fois, utilisé alors qu'il devrait être invalide, ou ce genre de joyeusetés… C'est particulièrement pertinent en C, d'ailleurs, qui n'offre aucun moyen de gérer ce genre de besoins basiques automatiquement. Un jour, peut-être, il sera possible d'écrire du C sans se farcir ces infâmes piles de labels pour la gestion d'échec. Mais d'ici la, je continuerai a considérer le C comme un artefact du passé.
Je préfère perdre quelques cycles à xor un emplacement mémoire, que des heures a débuguer un truc dont la reproduction est aléatoire (autant j'aime les grosses segfault qui tâchent, facile a choper, vous savez, celles qu'on reproduit trivialement… autant les autres types de corruption mémoire j'aime pas!).

wget et curl sont des outils souvent utilisés pour dialoguer avec un serveur. Oui, ça inclue autant télécharger qu'uploader. Les deux font grosso modo la même chose, mais différemment, avec diverses options.
Perso, j'utilise wget dans mes scripts juste parce que ça augmente les chances que ça marche avec busybox (qui peut inclure un module wget, mais pas curl), je ne connais pas plus que ça la différence.

Il doit bien y avoir des réimplémentations en rust (au hasard) ainsi que d'autres outils, mais je les connais pas.

Il (elle ?)

Dans le doute: «Ça».

Sinon, compte tenu du fait qu'une IA générative n'est rien de plus qu'un générateur de texte qui marche correctement, il ne faut pas en attendre la moindre cohérence technico-scientifique, ça ne sert qu'a générer du texte, point barre.