Il y a l'influence des outils (les fameuses IDE qui font tout un tas de trucs y compris afficher la liste des 170 fichiers dans une encadré en faisant croire que ce sont juste des fonctions –non, pas faux quand t'as une fonction par fichier etc.)
Vu le projet, je doute qu'il soit fait avec un IDE par contre, ou alors y'a des IDEs qui supportent autotools?
L'avantage d'une fonction par fichier, c'est le temps de compilation. Et un éditeur de code qui comprenne le langage peut largement permettre aux gens de naviguer entre les fichiers (le mien est pas config pour ça, mais rien ne l'empêcherait je pense)
Le C++ peut faire les deux, en fait (bas niveau, haut niveau). Après, gcc eux-mêmes utilisaient un garbage collector avant (j'avais vu un article sur lwn.net, qui expliquait qu'ils allaient intégrer du C++ pour réduire ça et donc améliorer les perfs, secoués par le succès alors montant de clang), et pourtant, c'est (c'était?) du C, donc bon…
On peut utiliser le C++ sans la STL, et dans ce cas on doit faire la gestion de la mémoire à la main (encore que, dans ce cas, on code soit-même ses wrappers…).
Parfois même, pas le choix, par exemple si on veut utiliser mmap (qui renvoie -1 et pas 0 en cas d'échec «On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set to indicate the cause of the error.») ou, plus parlant compte tenu du journal: dans le cas d'openGL ou dans de vulkan (ça retourne des handles, donc std::unique_ptr peut pas gérer sans intermédiaire).
Mais bon, je suis d'accord que:
Et même dans des langages bas niveau tel que le C, ou haut niveau tel que le C++ ou le Go, ces choses sont masquées.
Est juste une affirmation fausse: en C, si, il y a une gestion de la mémoire: malloc/calloc/realloc/free, c'est plus simple à utiliser que maintenir soit-même le tas et la pile du programme.
Toujours à ma connaissance en C, il n'y a pas besoin d'empiler manuellement avant d'appeler une fonction, ni de faire l'inverse en en sortant.
Ce qu'il manque au C (selon moi) pour alléger considérablement la charge des développeurs, c'est un mécanisme à la defer (go, je crois?).
Toujours en parlant de jeu vidéo, l'auteur devrais s'amuser un peu avec le langage de script de mindustry, la, il verrait ce qu'est une absence de gestion de la mémoire.
Et toujours à ma connaissance, en C++ les automatismes de gestion de la mémoire, ça se limite à la STL (mais je doute que Rust n'ait pas une lib pour tableaux dynamiques, listes chaînées, dictionnaires, … hein) ainsi qu'à la RAII (idem, je doute que Rust ne permette pas ce genre de choses, d'une façon ou d'une autre).
Comme je l'ai dit plus haut, la STL elle-même n'est pas parfaite, mais c'est bien assez bon dans 99% des cas.
Je me demande a quoi sert cette phrase en fait. Pourquoi dénigrer les autres langages (surtout en intro, ça ne donne pas envie)? Rust n'a-t-il donc pas assez de qualités?
En meme temps le projet est de 2011, avec plusieurs presentations depuis, selon wiki la derniere est de 2016.
Perso, je suis surtout curieux de la taille de la machine en photo, je n ai pas vu l'info. Je me demande aussi quelles sont les capacites des mains, cet aspect n'est pas du tout mis en avant par le peu que j'ai lu.
Le reste, la vision, la voix synthetique, etc, c'est cool aussi mais c'est juste du cpu et des libs au final. Je me permets meme de douter de l'ouverture des licences des-dites libs, sans la moindre preuve, je precise. Sinon, ca ne serai pas un doute.
Utilises clang-format pour générer un code formatté correctement à partir du code a ajouter, fais un diff, et si il y a des différences, tu envoies une erreur. Ensuite, tu places tout ça dans un pre-commit hook ainsi qu'un pre-merge (je suis plus sûr pour le 2nd, mais bref, le hook qui vérifie les patches avant de fusionner, parce que le pre-commit hook est malheureusement uniquement en local et n'est pas cloné à ma connaissance).
Je n'ai jamais utilisé cette technique avec clang-format, qui est sur ma TODO-list depuis perpette, mais j'ai fait exactement ça avec astyle, que j'utilise depuis avant la naissance de clang-format.
Genial! Ca juste marche, merci. Je n ai pas pu tester encore la version iw, parce que par habitude, j ai installe wireless-tools…
bon ca marche parce que j ai une ip et acces au portail mitm, reste a demander la "cle" mais ca devrai le faire.
Contrairement a tes proches, la poste ou la sncf donnent du service a tout le monde (moyennant finances pour la sncf et le courrier pas electronique de la poste). Je doute que ca soit comparable.
Tout à fait.
En fait, tu remarqueras que je ne participle plus vraiment (je serais curieux de voir un histo de mes connexions récentes, pas sûr que ça soit techniquement possible ceci dit).
C'est à peine si je viens voir de temps en temps, en fait. Et je constate que le plus souvent, je me contente maintenant de survoler les titres des liens quand je m'ennuies, et éventuellement aller voir ce qu'ils s'en dit histoire de sourire. Les journaux, je les ignore de plus en plus.
Vu que j'ai pas grand chose à faire au taf en ce moment, je me suis loggué hier, mais je constate que je visite plus facilement (mais ne me suis pas loggué la bas depuis des mois, littéralement, possiblement des années je sais pas) developpez.com (qui pourtant a des contenus "journalistique" de qualité plus que douteuse, mais bon, ça occupe 2minutes).
Je ne vais pas continuer le hors sujet, ça n'a que peu (aucun en fait) d'intérêt.
Bref $WEBSITE_NAME, c'est un peu ce que les utilisateurs en font.
En nombre de journal aujourd'hui sur la page principal, ça reste quand même logiciel/matériel libre qui sont en plus grand nombre
Je serais curieux de voir une liste des titres sur 12 mois, pour le coup. Pour les sujets, ça demande d'ouvrir la chose, donc plus d'efforts, pour peu d'intérêt au final (c'est vraiment une curiosité).
Mais si on devait faire un journal à chaque promesse ou annonce d'un gars médiatisé, LinuxFr.org perdrait tout son intérêt encombré par le bruit.
hum…
Cet argument ne me frappe pas, je sais pas pourquoi…
Ah. Si. Je sais.
Parce que j'ai l'impression que la plupart des discussions causent de politique, bien souvent même pas liée au logiciel libre.
Je suppose que je me trompe, et je finirai donc dans les limbes du -10… ou pas, a chaque fois qu'on dis ça, on se trompe. Advienne que pourra, je m'en tape.
les frameworks "modernes" sont toujours d'immondes bouzes qui nécessitent 2 Go d'installation avant de pouvoir écrire un "Hello, World" en noir sur fond blanc.
C'est parce que tu prends la mauvaise fonte, avec du Comic sans MS, je suis sûr que ça serait moins compliqué, probablement pour ça que c'était tant utilisé quand les DVDs existaient pas encore.
Une application C++, une image debian dumpée sur des Beaglebone black. Code tout pété, pas portable (mais fait par des étudiants, donc c'est pas choquant pour moi).
Besoin de porter vers x86 + dalle graphique + dalle tactile (avant c'était RS232 vers un clavier/écran tout pourrave et tout buggué).
1ère interface graphique: ÉtronJS. Échec, trop de problèmes de stabilité, difficultés de MàJ, et les devs assassinaient leur pauvre OS qui n'avait rien demandé à coup de "wget npm | sudo bash -" ou trucs dans ce genre.
2nd interface graphique, SDL2 en xorg-less (parce qu'un certain nombre de problèmes difficiles à résoudre venaient de xorg). Échec, la gestion de l'entrée était bancale. Tentative de lecture du code (par moi, 1ère fois que j'interviens dans cette partie, du coup): nope, le code des framebuffer est… bon, disons, pas fou, et surtout, considéré expérimental.
Du coup, 3ème, faite par moi, dans l'urgence. J'ai malgré tout pris le temps de voir comment étaient foutues les (rares) libs qui prétendaient faire ce que j'avais besoin, systématiquement overkill, complexité de mise en oeuvre. Au final, ça a été faire une lib basique de widgets moi-même, en me basant sur /usr/include/linux/fb.h et une lib, qui est libinput-dev.
Si jamais il devait arriver que cette lib ne soit pas adaptée, un portage vers autre chose serait trivial.
Autre exemple, sur le même projet (l'appli graphique n'étant qu'un seul élément): le code historique implémentait, de mémoire, les websockets à la main, ou je ne sais trop comment, peut-être des fichiers dupliqués à la sauvage, je ne sais vraiment plus.
Mon choix a été d'évaluer plus d'une dizaine de libs et de lire la RFC, au cas où. Il s'avère que la plupart des libs qui font du websockets en C ou C++ ont une assez gueule, mais la RFC est trop complexe pour moi (enfin, j'y arriverai, mais perte de temps considérable). Malgré ça, j'ai trouvé une lib(pub parce qu'elle le vaut bien) qui tenait la route, mais ce n'était vraiment pas la 1ère que j'ai évaluée. J'ai également eu le plaisir de leur remonter un problème (de doc, rien de méchant) qui a été très vite corrigé. Si un jour il y avait eu un bug critique dans le code, j'aurait été probablement capable d'intervenir, de ce que j'ai lu du code (propre, documenté, par de techniques à la conW mode, du simple, de l'efficace).
Pour moi, la gestion de ses dépendances, c'est ça: un travail qui certes prend un peu de temps, mais permets de réduire les risques: de faire un mauvais choix, déjà, et si ton choix est pas optimal, soit de pouvoir corriger le problème toi-même, soit de pouvoir aisément changer pour une autre lib.
Ce n'est pas prendre l'outil parfait, vu que ça existe pas, mais de prendre un truc qui ne te fout pas dans la merde si t'as besoin de changer ou d'intervernir dessus.
Alors, non, je ne lis pas chaque foutu commit, ça serait horrible, surtout depuis que les gens s'amusent à coller les commits de CI dans l'historique du projet, mais oui, je lis quelques fichiers source "au hasard", je regarde la fréquence de commits, je lis la doc, je regarde la licence aussi.
Pour ce qui est projets à framework… bah, désolé pour ceux qui bossent avec, hein. Ce que j'ai vu, c'est que quand on se base sur un framework, il est compliqué d'en sortir le jour ou ça colle plus aux besoins. C'est sûr, il fait tout, c'est propre (vu de l'extérieur, et encore, même pas toujours) c'est rassurant, mais j'ai déjà vu des boîtes réimplémenter from scratch leur outil qu'ils avaient codé depuis plus de 10 ans parce qu'ils avaient utilisé, justement, un framework qui s'était avéré pas si adapté que ça, finalement.
Pour moi, utiliser un framework, c'est mettre tout ses oeufs dans le même panier: c'est rapide à faire, mais le jour ou le panier est percé, on perd tout.
Je comprend bien que l'auteur du journal va loin, à dire d'inspecter chaque commit, mais a bien y réfléchir, de ce que j'ai vu dans des boulots, remplacer le temps perdu à contourner l'API du framework et dans des réunions stériles pourrait très bien abattre une bonne partie du boulot en question.
Boulot qui peut être dégrossi, mutualisé, par ailleurs, par exemple en essayant d'utiliser au maximum des outils fournis par, au hasard, debian, ou toute autre distribution logicielle qui ne fait pas de rolling release. Évidemment, ça implique d'avoir confiance upstream, mais bon, on le fait déjà quand on utilise une lib de toute façon, parce que c'est pas lire un historique de commit qui va renseigner sur ce que fait vraiment le code.
Note: de manière très amusante, alors que je suis un grand utilisateur de C++, j'ai constaté qu'après revue de code, la plupart du temps, j'opte pour des bibliothèques C, dont l'interface publique tend à être plus propre, plus simple et mieux documentée. Je crois bien qu'a part GLM, je n'ai pas été impressionné par une seule lib C++ ces dernières années, en fait.
Ceci dit, il est vrai que les autotools, c'est pas ça et ça ressemble beaucoup à de la magie noire.
Bien pour ça que j'ai vu pas mal de projets C ou C++ migrer vers cmake d'abord, et maintenant aussi vers meson (parfois même de cmake vers meson), au point que même certains IDE, il me semblent, n'ont plus leur propre système de build (ce qui se faisait beaucoup à une époque, systématiquement je dirais même?) mais se basent sur cmake/meson/whatever, pas sûr du tout, mais je ne serais pas surpris même que certains déprécient leur système de build originel…
Mais bon, même cmake ou meson, on peut considérer que c'est du code, ça ne liste pas stricto sensu les dépendences.
Je suis, ou ai été, sûrement très con, mais en fait, la raison initiale qui m'a fait rejeter hg était… c'est en python. Et j'avais (et toujours en vrai) plus confiance dans les langages compilés qui ont, par défaut, un minimum d'analyse statique.
Je n'ai aucune opinion sur hg en soit, et j'en ai entendu pas mal de bien.
D'un autre côté, je suis content d'avoir fait confiance à un outil codé dans un langage standardisé ISO vue la transition «difficile» entre python 2&3.
Ceci n'est en revanche qu'un détail d'implem. Git commence a avoir un 2nd utilisateur got, qui le rend d'autant plus crédible. À quand un autre outil de versionning assez fiables et simples sur le long terme pour avoir d'autres clients qui émergent (l'inverse du web)?
ne pas se faire envoûter par les sirènes de la programmation facile et les fourre-tout à fonctionnalités (aka bloatwares)
Et je pense que j'ai à peu près mon compte :p
Pour ajouter un peu de contenu, je pourrais par exemple parler de ma vieille machine, parfaitement fonctionnelle, "designed for windows millenium", que j'ai acquise avec 64Mo de RAM (j'ai réussi à trouver de quoi monter à presque 200Mo \o/).
Cette machine flambante neuve dispose même d'un lecteur de bande SCSI, la pointe de la modernité, je vous dit!
Elle marche parfaitement avec une Debian 9, mais je ne pourrais probablement pas la booter avec une debian 11.
Je soupçonne ce fait parce que la dernière fois que j'ai voulu booter une VM qui ait moins de 250Mo de ram, l'initrd faisait partir le système en couille: pas assez de RAM.
Après augmentation de quelques dizaines de megs, plus de problème, et la consommation mémoire mesurée au login était inférieure à 50Mo.
Les gros consommateurs individuels? Le noyau et, surtout, systemd-udevd (le seul composant systemd installé).
Autre chose, si je laissait faire les MàJ, elle finirait avec systemd, plutôt que runit.
Hors, systemd, la dernière fois que j'ai mesuré, avait (de mémoire, presque un an) une empreinte RSS de plus de 30Mio.
À comparer avec "runsvdir + ( runsv + svlogd ) * N + runit" qui ont, liés à glibc, environ 750Kio de RSS (en moyenne). Liés avec musl, ou liés statiquement (ou en utilisant leurs équivalents dans busybox-static), on tombe à 4Kio de RSS par process.
En gros, systemd a, il est vrai, très peu de coût RSS par daemon géré (non mesurable, en fait), mais un coût initial énorme, alors que runit à un faible coût initial, et un gros coût par daemon (entre 8Kio et 1.5Mio, selon qu'on utilise glibc en dynamique ou non). La conclusion, c'est qu'il faut un nombre de daemon élevé (entre 20 et 7500, selon que glibc ou pas) pour que systemd soit à égalité avec runit de ce point de vue.
Sur une machine qui a moins de 200Mio, ça compte. Bon, en pratique, cette machine permets toujours de communiquer via IRC, mails, de faire de la bureautique… les seuls trucs qu'elle ne peut plus faire, c'est accéder au «web moderne» et lancer des jeux (encore que, de mémoire, j'arrivais a y faire tourner wesnoth), donc ça reste une machine d'appoint, au cas ou ma machine de tous les jours soit détruite (ou celle de quelqu'un d'autre, c'est déjà arrivé que je la prête, il avait fallu que j'installe LXDE, c'était amusant aussi ça, tiens).
On peut aussi parler, évidemment, d'ÉtronJS, qui embarque chromium dans chaque «application». Je ne ferai l'insulte a personne de développer ce point sur un point de vue écologique.
En fait, je pense que, bon, pourquoi pas… pour faire un PoC, un prototype, ça peut le faire, mais pour de la prod (en plus ça plante si facilement… je ne compte plus les SIGILL dans mes dmesg, quasi systématiquement liés à ce truc)?
J'ai pris systemd comme example, un peu pour le troll, mais aussi parce que j'ai effectivement mesuré, mais ça s'applique évidemment (et beaucoup mieux) à de nombreux autres logiciels: transmission consomme ~60Mio de RSS, contre le double pour qbittorrent, pour prendre un exemple récemment vu. Kiwix-desktop est un monstre (près de 180Mo), qui ne fait pourtant quasiment que la même chose qu'un serveur HTTP…
Ce que je reproche à git, notamment pour un usage de ce type:
ne résiste pas aux déconnections (git clone d'un truc un peu gros sur une connection pourrie, couper la co: doit reprendre à zero);
performances exécrables (overhead du disque dur, bande passante, surtout quand on commence a utiliser des submodules), d'ou l'existence de git-lfs d'ailleurs (jamais testé, je sais pas ce que ça vaut, mais ça sent le workaround a 10 km);
interface horrible (on va pas se mentir: utiliser git, ça va à peu près, quand on a l'habitude, mais il suffit de voir quelqu'un qui apprend… c'est pas simple du tout). Attention: je ne connais pas mieux (ce qui ne veut pas dire que ça n'existe pas) mais le problème reste réel;
Outre ces points, il requiert une série d'actions complexes pour synchroniser des points ensemble, et je ne parle que de point à point (la gestion des conflits est loin d'être simple, et les patchs de conflit à résoudre qu'il génère sont loin d'être minimaux ou d'avoir une sémantique potable, en tout cas par défaut, peut-être que ça se configure…). Je n'ose imaginer le merdier à gérer pour avoir plus de 2 ou 3 cibles "remote"… et ça, c'est probable que ça soit pour tous les DVCS.
Il est possible qu'un autre DVCS fasse mieux: got par exemple, l'implémentation WiP d'openBSD, ou, possiblement encore plus mieux (parce que liés à git d'aucune façon), fossil, mercurial… mais git est bien le dernier que j'utiliserais pour un tel usage (je part du principe que le réseau ne doit pas être élitiste, donc un truc facile à utiliser et à apprendre pour un non-dev).
Probablement fossil, en fait. Au moins, par défaut il a une interface graphique (je considère une application web comme une interface graphique, oui), et déplacer un dépôt fossil est nettement plus simple: un seul fichier à déplacer.
Je me demande… qu'est-ce qui coûte le plus cher, entre un mail et un site bourré de JS, d'images animées, de trackers, de fontes, etc… c'est qui le plus cher, écologiquement parlant?
Ça coûte si cher de faire des calcules côté serveurs ?
Je dirais que oui.
L'infra et les compétences pour mettre en place des enregistrements automatiques des parties et faire du machine learning, ça coûte cher, c'est pas à la portée des jeux indé qui ont, j'imagine, déjà du mal à joindre les deux bouts.
Puis, pour voter, il faut une base de joueur qui soit principalement honnête. Un jeu avec moins de joueurs ou moins bien établi que CS pourrait très bien se faire troller par un afflux massif de cheaters, et ça, le ML y est vulnérable.
Peut-être aussi que les studios préfèrent se concentrer sur leur métier: faire des jeux funs, plutôt que s'emmerder à faire une lutte sans fin contre les tricheurs?
Je crois que les mêmePéTrois n'ont plus de brevet derrière et que donc les logiciels ont le droit de les implémenter en libre (alors qu'avant certains le faisaient mais pas forcément le droit? Je ne sais pas)
Tu as oublié (de décrire, dans le cercle vertueux que tu cites ;)) le fait que les jeux vidéos sont l'un des moteurs de l'amélioration des performances, notamment des GPU.
Plus de jeux et de joueurs sont linux à de bonnes chances de déclencher une amélioration de la qualité des pilotes graphiques, et donc de bénéficier aux non-joueurs.
Firefox […] Thunderbird c'est bien, il les conserve, mais je n'ai pas mon client lourd partout
Je trouve amusant de considérer qu'un navigateur web est moins lourd qu'un client mail (même si, c'est vrai que thunderbird est lourd, parce qu'il embarque, justement, le moteur de rendu de firefox, pour le coup)
Bon, je me débarrasserais pas pour autant du dual boot, parce que j'aime avoir un système de secours au cas ou je flingue ma distro (quand on bricole, ça arrive). Mais ça rendra justement ce système de secours plus fiable (moins utilisé, moins de risque de dommages).
[^] # Re: tss tss...
Posté par freem . En réponse au journal Software architecture considered harmful. Évalué à 2.
Comme ici: https://git.skarnet.org/cgi-bin/cgit.cgi/skalibs/tree/src/libstdcrypto
Vu le projet, je doute qu'il soit fait avec un IDE par contre, ou alors y'a des IDEs qui supportent autotools?
L'avantage d'une fonction par fichier, c'est le temps de compilation. Et un éditeur de code qui comprenne le langage peut largement permettre aux gens de naviguer entre les fichiers (le mien est pas config pour ça, mais rien ne l'empêcherait je pense)
[^] # Re: C++, haut niveau ?
Posté par freem . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 7.
Le C++ peut faire les deux, en fait (bas niveau, haut niveau). Après, gcc eux-mêmes utilisaient un garbage collector avant (j'avais vu un article sur lwn.net, qui expliquait qu'ils allaient intégrer du C++ pour réduire ça et donc améliorer les perfs, secoués par le succès alors montant de clang), et pourtant, c'est (c'était?) du C, donc bon…
On peut utiliser le C++ sans la STL, et dans ce cas on doit faire la gestion de la mémoire à la main (encore que, dans ce cas, on code soit-même ses wrappers…).
Parfois même, pas le choix, par exemple si on veut utiliser mmap (qui renvoie -1 et pas 0 en cas d'échec «On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set to indicate the cause of the error.») ou, plus parlant compte tenu du journal: dans le cas d'openGL ou dans de vulkan (ça retourne des handles, donc std::unique_ptr peut pas gérer sans intermédiaire).
Mais bon, je suis d'accord que:
Est juste une affirmation fausse: en C, si, il y a une gestion de la mémoire: malloc/calloc/realloc/free, c'est plus simple à utiliser que maintenir soit-même le tas et la pile du programme.
Toujours à ma connaissance en C, il n'y a pas besoin d'empiler manuellement avant d'appeler une fonction, ni de faire l'inverse en en sortant.
Ce qu'il manque au C (selon moi) pour alléger considérablement la charge des développeurs, c'est un mécanisme à la
defer(go, je crois?).Toujours en parlant de jeu vidéo, l'auteur devrais s'amuser un peu avec le langage de script de mindustry, la, il verrait ce qu'est une absence de gestion de la mémoire.
Et toujours à ma connaissance, en C++ les automatismes de gestion de la mémoire, ça se limite à la STL (mais je doute que Rust n'ait pas une lib pour tableaux dynamiques, listes chaînées, dictionnaires, … hein) ainsi qu'à la RAII (idem, je doute que Rust ne permette pas ce genre de choses, d'une façon ou d'une autre).
Comme je l'ai dit plus haut, la STL elle-même n'est pas parfaite, mais c'est bien assez bon dans 99% des cas.
Je me demande a quoi sert cette phrase en fait. Pourquoi dénigrer les autres langages (surtout en intro, ça ne donne pas envie)? Rust n'a-t-il donc pas assez de qualités?
[^] # Re: Précision : Microsoft ne vend plus le Kinect depuis 2017
Posté par freem . En réponse à la dépêche Robot humanoïde libre français : InMoov. Évalué à 4.
En meme temps le projet est de 2011, avec plusieurs presentations depuis, selon wiki la derniere est de 2016.
Perso, je suis surtout curieux de la taille de la machine en photo, je n ai pas vu l'info. Je me demande aussi quelles sont les capacites des mains, cet aspect n'est pas du tout mis en avant par le peu que j'ai lu.
Le reste, la vision, la voix synthetique, etc, c'est cool aussi mais c'est juste du cpu et des libs au final. Je me permets meme de douter de l'ouverture des licences des-dites libs, sans la moindre preuve, je precise. Sinon, ca ne serai pas un doute.
# ben... clang-format, non?
Posté par freem . En réponse au message application de convention d'écriture. Évalué à 2.
Tout est dans le titre.
Utilises clang-format pour générer un code formatté correctement à partir du code a ajouter, fais un diff, et si il y a des différences, tu envoies une erreur. Ensuite, tu places tout ça dans un pre-commit hook ainsi qu'un pre-merge (je suis plus sûr pour le 2nd, mais bref, le hook qui vérifie les patches avant de fusionner, parce que le pre-commit hook est malheureusement uniquement en local et n'est pas cloné à ma connaissance).
Je n'ai jamais utilisé cette technique avec clang-format, qui est sur ma TODO-list depuis perpette, mais j'ai fait exactement ça avec astyle, que j'utilise depuis avant la naissance de clang-format.
[^] # Re: key_mgmt=NONE
Posté par freem . En réponse au message connection wifi insecure. Évalué à 2.
Genial! Ca juste marche, merci. Je n ai pas pu tester encore la version iw, parce que par habitude, j ai installe wireless-tools…
bon ca marche parce que j ai une ip et acces au portail mitm, reste a demander la "cle" mais ca devrai le faire.
[^] # Re: on a le service qu'on paye.
Posté par freem . En réponse au journal La Poste ne distribue plus le courrier et le jette à la poubelle. Évalué à 6.
Contrairement a tes proches, la poste ou la sncf donnent du service a tout le monde (moyennant finances pour la sncf et le courrier pas electronique de la poste). Je doute que ca soit comparable.
[^] # Re: Je ne comprend pas
Posté par freem . En réponse au message connection wifi insecure. Évalué à 2. Dernière modification le 10 mai 2022 à 20:26.
Je pense tomber souvent sur des hotels sans wpa. De ma faible experience sur le sujet, ca semble la norme, en fait.
cela dis peut etre que c est du WPA sans pass, je suis incapable de faire le distinguo entre les deux
[^] # Re: Annonce!
Posté par freem . En réponse au journal Elon musk ouvrirait le code de tweeter ?. Évalué à 2. Dernière modification le 28 avril 2022 à 08:49.
Tout à fait.
En fait, tu remarqueras que je ne participle plus vraiment (je serais curieux de voir un histo de mes connexions récentes, pas sûr que ça soit techniquement possible ceci dit).
C'est à peine si je viens voir de temps en temps, en fait. Et je constate que le plus souvent, je me contente maintenant de survoler les titres des liens quand je m'ennuies, et éventuellement aller voir ce qu'ils s'en dit histoire de sourire. Les journaux, je les ignore de plus en plus.
Vu que j'ai pas grand chose à faire au taf en ce moment, je me suis loggué hier, mais je constate que je visite plus facilement (mais ne me suis pas loggué la bas depuis des mois, littéralement, possiblement des années je sais pas) developpez.com (qui pourtant a des contenus "journalistique" de qualité plus que douteuse, mais bon, ça occupe 2minutes).
Je ne vais pas continuer le hors sujet, ça n'a que peu (aucun en fait) d'intérêt.
Bref $WEBSITE_NAME, c'est un peu ce que les utilisateurs en font.
Je serais curieux de voir une liste des titres sur 12 mois, pour le coup. Pour les sujets, ça demande d'ouvrir la chose, donc plus d'efforts, pour peu d'intérêt au final (c'est vraiment une curiosité).
[^] # Re: Annonce!
Posté par freem . En réponse au journal Elon musk ouvrirait le code de tweeter ?. Évalué à 5.
hum…
Cet argument ne me frappe pas, je sais pas pourquoi…
Ah. Si. Je sais.
Parce que j'ai l'impression que la plupart des discussions causent de politique, bien souvent même pas liée au logiciel libre.
Je suppose que je me trompe, et je finirai donc dans les limbes du -10… ou pas, a chaque fois qu'on dis ça, on se trompe. Advienne que pourra, je m'en tape.
[^] # Re: D'un extrême à l'autre ?
Posté par freem . En réponse au journal De l'art d'être indépendant des dépendances. Évalué à 3.
C'est parce que tu prends la mauvaise fonte, avec du Comic sans MS, je suis sûr que ça serait moins compliqué, probablement pour ça que c'était tant utilisé quand les DVDs existaient pas encore.
Hop moi…
[^] # Re: Tu dois pas produire grand chose
Posté par freem . En réponse au journal De l'art d'être indépendant des dépendances. Évalué à 3.
Un truc que j'ai vécu.
Une application C++, une image debian dumpée sur des Beaglebone black. Code tout pété, pas portable (mais fait par des étudiants, donc c'est pas choquant pour moi).
Besoin de porter vers x86 + dalle graphique + dalle tactile (avant c'était RS232 vers un clavier/écran tout pourrave et tout buggué).
1ère interface graphique: ÉtronJS. Échec, trop de problèmes de stabilité, difficultés de MàJ, et les devs assassinaient leur pauvre OS qui n'avait rien demandé à coup de "wget npm | sudo bash -" ou trucs dans ce genre.
2nd interface graphique, SDL2 en xorg-less (parce qu'un certain nombre de problèmes difficiles à résoudre venaient de xorg). Échec, la gestion de l'entrée était bancale. Tentative de lecture du code (par moi, 1ère fois que j'interviens dans cette partie, du coup): nope, le code des framebuffer est… bon, disons, pas fou, et surtout, considéré expérimental.
Du coup, 3ème, faite par moi, dans l'urgence. J'ai malgré tout pris le temps de voir comment étaient foutues les (rares) libs qui prétendaient faire ce que j'avais besoin, systématiquement overkill, complexité de mise en oeuvre. Au final, ça a été faire une lib basique de widgets moi-même, en me basant sur /usr/include/linux/fb.h et une lib, qui est libinput-dev.
Si jamais il devait arriver que cette lib ne soit pas adaptée, un portage vers autre chose serait trivial.
Autre exemple, sur le même projet (l'appli graphique n'étant qu'un seul élément): le code historique implémentait, de mémoire, les websockets à la main, ou je ne sais trop comment, peut-être des fichiers dupliqués à la sauvage, je ne sais vraiment plus.
Mon choix a été d'évaluer plus d'une dizaine de libs et de lire la RFC, au cas où. Il s'avère que la plupart des libs qui font du websockets en C ou C++ ont une assez gueule, mais la RFC est trop complexe pour moi (enfin, j'y arriverai, mais perte de temps considérable). Malgré ça, j'ai trouvé une lib(pub parce qu'elle le vaut bien) qui tenait la route, mais ce n'était vraiment pas la 1ère que j'ai évaluée. J'ai également eu le plaisir de leur remonter un problème (de doc, rien de méchant) qui a été très vite corrigé. Si un jour il y avait eu un bug critique dans le code, j'aurait été probablement capable d'intervenir, de ce que j'ai lu du code (propre, documenté, par de techniques à la conW mode, du simple, de l'efficace).
Pour moi, la gestion de ses dépendances, c'est ça: un travail qui certes prend un peu de temps, mais permets de réduire les risques: de faire un mauvais choix, déjà, et si ton choix est pas optimal, soit de pouvoir corriger le problème toi-même, soit de pouvoir aisément changer pour une autre lib.
Ce n'est pas prendre l'outil parfait, vu que ça existe pas, mais de prendre un truc qui ne te fout pas dans la merde si t'as besoin de changer ou d'intervernir dessus.
Alors, non, je ne lis pas chaque foutu commit, ça serait horrible, surtout depuis que les gens s'amusent à coller les commits de CI dans l'historique du projet, mais oui, je lis quelques fichiers source "au hasard", je regarde la fréquence de commits, je lis la doc, je regarde la licence aussi.
Pour ce qui est projets à framework… bah, désolé pour ceux qui bossent avec, hein. Ce que j'ai vu, c'est que quand on se base sur un framework, il est compliqué d'en sortir le jour ou ça colle plus aux besoins. C'est sûr, il fait tout, c'est propre (vu de l'extérieur, et encore, même pas toujours) c'est rassurant, mais j'ai déjà vu des boîtes réimplémenter from scratch leur outil qu'ils avaient codé depuis plus de 10 ans parce qu'ils avaient utilisé, justement, un framework qui s'était avéré pas si adapté que ça, finalement.
Pour moi, utiliser un framework, c'est mettre tout ses oeufs dans le même panier: c'est rapide à faire, mais le jour ou le panier est percé, on perd tout.
Je comprend bien que l'auteur du journal va loin, à dire d'inspecter chaque commit, mais a bien y réfléchir, de ce que j'ai vu dans des boulots, remplacer le temps perdu à contourner l'API du framework et dans des réunions stériles pourrait très bien abattre une bonne partie du boulot en question.
Boulot qui peut être dégrossi, mutualisé, par ailleurs, par exemple en essayant d'utiliser au maximum des outils fournis par, au hasard, debian, ou toute autre distribution logicielle qui ne fait pas de rolling release. Évidemment, ça implique d'avoir confiance upstream, mais bon, on le fait déjà quand on utilise une lib de toute façon, parce que c'est pas lire un historique de commit qui va renseigner sur ce que fait vraiment le code.
Note: de manière très amusante, alors que je suis un grand utilisateur de C++, j'ai constaté qu'après revue de code, la plupart du temps, j'opte pour des bibliothèques C, dont l'interface publique tend à être plus propre, plus simple et mieux documentée. Je crois bien qu'a part GLM, je n'ai pas été impressionné par une seule lib C++ ces dernières années, en fait.
[^] # Re: Cargo.lock affligeant
Posté par freem . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 4.
Bien pour ça que j'ai vu pas mal de projets C ou C++ migrer vers cmake d'abord, et maintenant aussi vers meson (parfois même de cmake vers meson), au point que même certains IDE, il me semblent, n'ont plus leur propre système de build (ce qui se faisait beaucoup à une époque, systématiquement je dirais même?) mais se basent sur cmake/meson/whatever, pas sûr du tout, mais je ne serais pas surpris même que certains déprécient leur système de build originel…
Mais bon, même cmake ou meson, on peut considérer que c'est du code, ça ne liste pas stricto sensu les dépendences.
[^] # Re: Tentative de réponse
Posté par freem . En réponse au journal Effet de bords et PC sans OS ?. Évalué à 3.
Quid des sex-toys connectés, du coup?
[^] # Re: pardon, j'ai ri
Posté par freem . En réponse au journal Une CVE dans le compilateur rust. Évalué à 2.
Ce qui se fait d'ailleurs même pour des softs libres parfois.
[^] # Re: git?
Posté par freem . En réponse au journal Un réseau offline "delay-tolerant" avec NNCP. Évalué à 2.
Je suis, ou ai été, sûrement très con, mais en fait, la raison initiale qui m'a fait rejeter hg était… c'est en python. Et j'avais (et toujours en vrai) plus confiance dans les langages compilés qui ont, par défaut, un minimum d'analyse statique.
Je n'ai aucune opinion sur
hgen soit, et j'en ai entendu pas mal de bien.D'un autre côté, je suis content d'avoir fait confiance à un outil codé dans un langage standardisé ISO vue la transition «difficile» entre python 2&3.
Ceci n'est en revanche qu'un détail d'implem. Git commence a avoir un 2nd utilisateur
got, qui le rend d'autant plus crédible. À quand un autre outil de versionning assez fiables et simples sur le long terme pour avoir d'autres clients qui émergent (l'inverse du web)?[^] # Re: Empreinte environnementale
Posté par freem . En réponse au journal Forlater.email, un service pour lire plus tard. Évalué à 4. Dernière modification le 14 octobre 2021 à 11:41.
Ajoutes:
Et je pense que j'ai à peu près mon compte :p
Pour ajouter un peu de contenu, je pourrais par exemple parler de ma vieille machine, parfaitement fonctionnelle, "designed for windows millenium", que j'ai acquise avec 64Mo de RAM (j'ai réussi à trouver de quoi monter à presque 200Mo \o/).
Cette machine flambante neuve dispose même d'un lecteur de bande SCSI, la pointe de la modernité, je vous dit!
Elle marche parfaitement avec une Debian 9, mais je ne pourrais probablement pas la booter avec une debian 11.
Je soupçonne ce fait parce que la dernière fois que j'ai voulu booter une VM qui ait moins de 250Mo de ram, l'initrd faisait partir le système en couille: pas assez de RAM.
Après augmentation de quelques dizaines de megs, plus de problème, et la consommation mémoire mesurée au login était inférieure à 50Mo.
Les gros consommateurs individuels? Le noyau et, surtout, systemd-udevd (le seul composant systemd installé).
Autre chose, si je laissait faire les MàJ, elle finirait avec systemd, plutôt que runit.
Hors, systemd, la dernière fois que j'ai mesuré, avait (de mémoire, presque un an) une empreinte RSS de plus de 30Mio.
À comparer avec "runsvdir + ( runsv + svlogd ) * N + runit" qui ont, liés à glibc, environ 750Kio de RSS (en moyenne). Liés avec musl, ou liés statiquement (ou en utilisant leurs équivalents dans busybox-static), on tombe à 4Kio de RSS par process.
En gros, systemd a, il est vrai, très peu de coût RSS par daemon géré (non mesurable, en fait), mais un coût initial énorme, alors que runit à un faible coût initial, et un gros coût par daemon (entre 8Kio et 1.5Mio, selon qu'on utilise glibc en dynamique ou non). La conclusion, c'est qu'il faut un nombre de daemon élevé (entre 20 et 7500, selon que glibc ou pas) pour que systemd soit à égalité avec runit de ce point de vue.
Sur une machine qui a moins de 200Mio, ça compte. Bon, en pratique, cette machine permets toujours de communiquer via IRC, mails, de faire de la bureautique… les seuls trucs qu'elle ne peut plus faire, c'est accéder au «web moderne» et lancer des jeux (encore que, de mémoire, j'arrivais a y faire tourner wesnoth), donc ça reste une machine d'appoint, au cas ou ma machine de tous les jours soit détruite (ou celle de quelqu'un d'autre, c'est déjà arrivé que je la prête, il avait fallu que j'installe LXDE, c'était amusant aussi ça, tiens).
On peut aussi parler, évidemment, d'ÉtronJS, qui embarque chromium dans chaque «application». Je ne ferai l'insulte a personne de développer ce point sur un point de vue écologique.
En fait, je pense que, bon, pourquoi pas… pour faire un PoC, un prototype, ça peut le faire, mais pour de la prod (en plus ça plante si facilement… je ne compte plus les SIGILL dans mes dmesg, quasi systématiquement liés à ce truc)?
J'ai pris systemd comme example, un peu pour le troll, mais aussi parce que j'ai effectivement mesuré, mais ça s'applique évidemment (et beaucoup mieux) à de nombreux autres logiciels: transmission consomme ~60Mio de RSS, contre le double pour qbittorrent, pour prendre un exemple récemment vu. Kiwix-desktop est un monstre (près de 180Mo), qui ne fait pourtant quasiment que la même chose qu'un serveur HTTP…
[^] # Re: git?
Posté par freem . En réponse au journal Un réseau offline "delay-tolerant" avec NNCP. Évalué à 4.
Alors, git… non.
Un DVCS, oui, peut-être, mais pas git.
Ce que je reproche à git, notamment pour un usage de ce type:
Outre ces points, il requiert une série d'actions complexes pour synchroniser des points ensemble, et je ne parle que de point à point (la gestion des conflits est loin d'être simple, et les patchs de conflit à résoudre qu'il génère sont loin d'être minimaux ou d'avoir une sémantique potable, en tout cas par défaut, peut-être que ça se configure…). Je n'ose imaginer le merdier à gérer pour avoir plus de 2 ou 3 cibles "remote"… et ça, c'est probable que ça soit pour tous les DVCS.
Il est possible qu'un autre DVCS fasse mieux: got par exemple, l'implémentation WiP d'openBSD, ou, possiblement encore plus mieux (parce que liés à git d'aucune façon), fossil, mercurial… mais git est bien le dernier que j'utiliserais pour un tel usage (je part du principe que le réseau ne doit pas être élitiste, donc un truc facile à utiliser et à apprendre pour un non-dev).
Probablement fossil, en fait. Au moins, par défaut il a une interface graphique (je considère une application web comme une interface graphique, oui), et déplacer un dépôt fossil est nettement plus simple: un seul fichier à déplacer.
[^] # Re: Empreinte environnementale
Posté par freem . En réponse au journal Forlater.email, un service pour lire plus tard. Évalué à 8.
Je me demande… qu'est-ce qui coûte le plus cher, entre un mail et un site bourré de JS, d'images animées, de trackers, de fontes, etc… c'est qui le plus cher, écologiquement parlant?
[^] # Re: Et la vie privée ?
Posté par freem . En réponse au journal EAC fonctionne à présent sous Wine/Proton, BattlEye confirme le support . Évalué à 4.
Je dirais que oui.
L'infra et les compétences pour mettre en place des enregistrements automatiques des parties et faire du machine learning, ça coûte cher, c'est pas à la portée des jeux indé qui ont, j'imagine, déjà du mal à joindre les deux bouts.
Puis, pour voter, il faut une base de joueur qui soit principalement honnête. Un jeu avec moins de joueurs ou moins bien établi que CS pourrait très bien se faire troller par un afflux massif de cheaters, et ça, le ML y est vulnérable.
Peut-être aussi que les studios préfèrent se concentrer sur leur métier: faire des jeux funs, plutôt que s'emmerder à faire une lutte sans fin contre les tricheurs?
[^] # Re: commentaire obligatoire !
Posté par freem . En réponse au journal EAC fonctionne à présent sous Wine/Proton, BattlEye confirme le support . Évalué à 2.
Je crois que les mêmePéTrois n'ont plus de brevet derrière et que donc les logiciels ont le droit de les implémenter en libre (alors qu'avant certains le faisaient mais pas forcément le droit? Je ne sais pas)
[^] # Re: commentaire obligatoire !
Posté par freem . En réponse au journal EAC fonctionne à présent sous Wine/Proton, BattlEye confirme le support . Évalué à 4.
Tu as oublié (de décrire, dans le cercle vertueux que tu cites ;)) le fait que les jeux vidéos sont l'un des moteurs de l'amélioration des performances, notamment des GPU.
Plus de jeux et de joueurs sont linux à de bonnes chances de déclencher une amélioration de la qualité des pilotes graphiques, et donc de bénéficier aux non-joueurs.
[^] # Re: L'intérêt pour le joueur
Posté par freem . En réponse au journal EAC fonctionne à présent sous Wine/Proton, BattlEye confirme le support . Évalué à 2.
L'un n'empêche pas l'autre :)
[^] # Re: bof sauf peut-être pour les flux de syndication
Posté par freem . En réponse au journal Forlater.email, un service pour lire plus tard. Évalué à 2. Dernière modification le 29 septembre 2021 à 10:06.
Je trouve amusant de considérer qu'un navigateur web est moins lourd qu'un client mail (même si, c'est vrai que thunderbird est lourd, parce qu'il embarque, justement, le moteur de rendu de firefox, pour le coup)
[^] # Re: Linux devient Windows et macOS
Posté par freem . En réponse au lien systemd portable services: parce que les conteneurs, c'est trop mainstream. Évalué à 2.
Merci, je regarderais.
Bon, je me débarrasserais pas pour autant du dual boot, parce que j'aime avoir un système de secours au cas ou je flingue ma distro (quand on bricole, ça arrive). Mais ça rendra justement ce système de secours plus fiable (moins utilisé, moins de risque de dommages).
[^] # Re: Linux devient Windows et macOS
Posté par freem . En réponse au lien systemd portable services: parce que les conteneurs, c'est trop mainstream. Évalué à 2.
Boarf si on peut plus troller le dredi…