tu peux désactiver l'overcommit, mais pas jouer sur l'OOM
J'ai pas dit que je peux pas, j'ai dis que je ne sais pas faire, nuance.
Tu m'excusera de ne pas m’apitoyer sur ton sort ?
Sans le moindre problème.
Tu as l'air de faire ça tellement bien tout seul.
Ouai, non, en fait, je ne fais que parler de vécu, d'un type qui se démerde comme il peut pour que des systèmes expédiés au loin marchent sans intervention humaine, dans un respect complet de la Rache, méthodologie imposée par le patron.
Je ne suis pas certain que tu ai choisi le meilleur endroit pour ton besoin d'empathie ;)
J'ai autre chose a faire qu'attendre l'empathie. Je préfère en fait la laisser de côté, bien plus simple de s'améliorer en technique quand on met de côtés les sentiments.
Au pire, je peux finir a -10, et alors? Je n'en mourrai pas, j'apprendrais des remarques (à tout score, hein, de toute façon).
(en fait c'est même plus toi très agaçant de voir quelqu'un se plaindre et à chaque proposition qu'on lui fait en faire des caisses pour expliquer pourquoi le monde est cruel avec lui sans véritablement répondre)
Justement, voici ta phrase:
Hors de la remise en cause de vos choix, éviter que l'OOM killer flingue le service qui te sert à le piloter
Bon, à la relecture de mon dernier message, je note que je n'ai en effet pas indiqué n'avoir pas de connaissance sur le fonctionnement exact de l'OOM killer, je vais donc te plusser (je m'abstiens généralement, mais, tu est a -1 alors que c'est pertinent).
Cela dis, je ne sais plus si j'ai déjà explicité ça, mais l'OOM killer n'interviens jamais, ce qui cause un freeze du système. S'il faisait son boulot de tuer, les services (genre ssh et son tunnel inversé) soit redémareraient, soit seraient toujours exploitables.
Ici, je parle de freeze système, parce que l'OOM killer ne fait justement pas son boulot. Peut-être est-ce dû à la configuration par défaut, certes. Je compte vraiment creuser le sujet, je m'intéresse de plus en plus à cette partie qu'en tant que développeur je ne connais que trop: le contrôle des ressources d'un système. C'est plutôt passionnant en plus, connaître un peu mon système a pas mal changé ma façon d'architecturer le code, l'air de rien.
… c'est que j'ai l'intention d'expérimenter la partie pratique a tête reposée (p'tet les prochaines vacances, et j'enchaînerais sur la lecture de ton journal sur la puce libre en arrivant p'tet a y comprendre quelque chose sur ce sujet passionnant :)). Merci pour tout.
Sinon, j'ai quelques questions, un peu hors-sujet, sur la partie théorique.
Tu décris plusieurs étapes qui semblent en grande partie automatisées, plusieurs d'entres elles me rappellent fortement des étapes d'électronique (des mes cours d'il y a 15 ans, dans peu de temps je dirais 20…), sauf que ben on partait du schéma… que tu appelles ici netlist, le placement et le routage étaient fait principalement manuellement, avec une "faible" aide logicielle. Je me souviens des "chevelus", notamment, et ça semble pour le coup encore d'actualité avec Kicad (oui, http).
Je suis loin de maîtriser le-dit logiciel (j'ai pas du tout bossé l'électronique ces 15 dernières années, mais pas a cause du manque d'intérêt, et je n'ai commencé à m'y remettre qu'anecdotiquement il y a quelques mois), et je suis bien conscient que c'est loin de la création de circuits intégrés, mais je suis intrigué par le fait que Kicad semble avoir des contributeurs embauchés par le CNRS, et que plusieurs étapes que tu définis comme très longues semblent automatiques avec ta pile? Mis a part l'échelle (de quelques cm pour l'électroniques à quelques mm pour la µélec) qu'est-ce qui, selon toi, l'explique?
La solution que tu proposes est très bas niveau, et tu as du apprendre plein de choses…
Ce qui était le but, je l'ai même précisé:
pas la peine de chercher une raison pragmatique: si je voulais juste un live, j'irai en chercher un directement
Il y a une tonne de live cd qui traînent, je ne vois pas vraiment de bonne raison de faire ce que j'ai fait si le seul objectif est d'avoir un système live qui juste marche.
L'autre solution […]
J'aurai peut-être en effet indiquer ces pointeurs, même si je t'avoue que je n'ai même pas pris la peine de chercher: perso, si je veux un système transportable, je prend un disque externe et j'y installe ma distro. Simple, efficace, souple.
Qu'est ce qui est inclus dans le initrd avec cette méthode ?
Je ne l'ai pas customisé, c'est vraiment comme si j'avais installé Debian sur un CD. Tu as raison, cela fait partie des choses qu'il faudrait faire ensuite, pour avoir vraiment un truc propre, à l'issue de ce journal, l'iso est franchement bancale, elle ne peux même pas s'éteindre proprement :)
Avec une étiquette (label ou volume name), /dev/disk/by-label/ ?
Ça réduirait le problème, encore que le risque de collision reste important. L'idéal serait d'utiliser un UUID, mais je n'ai pas regardé comment ça fonctionne avec une iso. Probablement de la même manière qu'une partition normale, pour le coup.
Je ne sais ce que Debian a besoin, mais si il suit le FHS, il ne manquerait pas non plus /run et /tmp ?
Il y a aussi probablement le bazar de PAM qu'il faudrait copier avant de monter /var, et au fur et a mesure que j'ajouterais des composants, il y aura de plus en plus de choses à copier. Probablement.
C'est juste le strict minimum pour que ça marche. Ce que j'ai fait la, c'est un "hello world".
Après j'ai l’impression que ton problème vient premièrement du fait que tu as désactivé l'overcommit et pas de MariaDB lui-même, ce qui est un nid à problème en soit :-)
Comme je l'ai dis, s'il était facile de configurer mariadb pour qu'il ne consomme que ce dont il a réellement besoin, j'aurai pu laisser l'overcommit désactivé, ce qui aurait fait certes crasher un soft à répétitition, mais aurais éviter un reboot physique du système. Et quand ledit reboot nécéssite de faire plus de 300 bornes, ben…
Bref, le problème est d'une part le fait que l'overcommit fait freeze le système, et d'autre part le fait que mariadb est incapable de fonctionner avec moins de 600Mo de ram sans overcommit, alors qu'en pratique, mariadb n'a pas besoin de toute cette mémoire.
Enfin, quand je dis que mariadb en est incapable, je veux surtout dire qu'il est extrêmement ardu de le configurer pour qu'il soit vraiment adapté à son environnement réel. Parce que, ben, la doc, elle est… disons, floue, pour être sympa.
Cela dis, j'ai l'impression a te lire que tu n'as pas lu mes précédentes interventions, parce que j'ai déjà expliqué ces points. J'ai l'impression que tu ne fais que défendre un outil, en disant qu'il s'adapte aux usages, mais tu n'expliques a priori pas les usages ou tu l'as vu fonctionner?
Où est le contenu réel?
Moi, je vois juste des photos, avec des liens. Si mon navigateur n'affichait que le texte, ça tiendrait sur un tty, et p'tet même en 40x10. J'ai donc moinssé.
Comme dit plus haut, le problème ici est surtout que c'était une connerie monstrueuse d'utilise celui-ci dans notre cas. C'est juste pas fait pour.
Maintenant, essayer de réduire le dégât en attendant le temps de pouvoir migrer vers une vraie solution adaptée, aurait été de lire une doc qui ne mens pas. Ici, la doc m'a, selon moi, menti. Je parle de celle dans les pages de manuel ainsi que celle accessible sur le net, qui ne permets pas, de mémoire, aisément de choisir une version.
c'est clairement le plus populaire.
Windows est l'OS le plus populaire. Il a des qualités réelles, mais n'est que rarement choisi pour celles-ci, il est plutôt choisi par habitude plutôt qu'une analyse du plus pertinent pour l'usage. Linux devenant de plus en plus utilisé, nos distros font aussi des choix que je considère dans cette optique.
Sauf que le problème, c'est qu'il n'interviens jamais dans la configuration par défaut, et ça résulte en un système freeze. La configuration par défaut est faite pour des systèmes dans lesquels la maîtrise n'est pas pas un problème parce qu'on peut rebooter d'une manière ou d'une autre, le système par défaut n'est pas autonome.
C'est (un de mes) mon soucis, justement: je me retrouve avec des softs (mysql ici) poussés par des débutants (avant que j'arrive, même si je ne me considère pas comme bon, j'ai un peu plus de recul qu'un étudiant, mais la boite a une histoire) parce que c'est ce qu'on apprend a l'école, mais l'école n'enseigne que des cas idéaux avec des ressources infinies, sans enseigner les cas ou les ressources sont limitées, qui existent pourtant dans la majorité des équipements informatiques (routeurs, switch, montres, radio-réveil, mobilier urbain, etc).
Ce n'est pas simple a expliquer, et a gérer encore moins, surtout que je me considère plutôt comme tech que comme décisionnaire ou architecte… faut naviguer entre compréhension de l'histo et ses racines, sa propre considération de l'idéal et les réalités de la boîte… donc pardonnes mes biais, raccourcis et imprécisions
Le coup de "vi" est dans toutes les distributions, pas emacs, c'est un faux prétexte, on est bien d'accord…
Je ne suis pas entièrement d'accord, du fait que vi est implémenté dans busybox, et est le seul éditeur de texte interactif disponible par exemple dans le mode rescue de Debian.
Il va aussi se retrouver du coup dans l'initramfs en cas de problème, et la aussi, il sera le seul. Du coup, savoir s'en servir aide je pense à se dépatouiller plus facilement de situations pénibles (ou de faire des installs custo de Debian sans passer par l'installateur normal qui est, honnêtement, bien pénible quand on sait exactement ce qu'on veut).
L'avantage de savoir de vim, du coup, c'est qu'on sait de facto se servir de busybox vi, même s'il est vrai qu'il n'est pas ce qu'il y a de plus génial (forcément, le but est d'avoir un truc réellement minimal, pour le coup, qui puisse rentrer dans un très petit espace).
(même notepad).
Ah, notepad gère enfin les fins de ligne non "CRLF"? Jamais testé, mais je me demande s'il supporte l'UTF8 aussi :p
Pas con, j'essaierai. Je pense que mysql va se ramasser, mais ça vaut le coup d'essayer.
J’ai vu le cas de logiciels (notamment un navigateur web pour lequel c’est flagrant, peut-être Midori, mais je ne suis pas sûr) qui allouent une quantité de mémoire très importante mais n’en utilisent réellement qu’un peu.
Tous les navigateurs graphiques que j'ai essayé pour le moment en font partie, virtualbox aussi. Ce sont les seuls que j'aie remarqués pour l'instant.
Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus.
Et en n’allouant pas de swap (une façon efficace de ne pas en utiliser), est-ce que MySQL fonctionne quand même ou pas ?
Sans problème. C'est juste que, du coup, il y a plus de 600Mio de réservés sur un système qui n'en a que 512Mio. Tant que ça marche…
Honnêtement, ça fait longtemps que je n'utilise plus de fichier d'échange: à quoi bon? C'est juste un coup a user plus vite le disque et faire quasi freeze le kernel. Je préfère de loin qu'un gros bloatware comme [insérer ici un navigateur mainstream de votre choix] se mange un oom kill. Et l'hibernation est plus lente qu'un cold-boot sur mes machines depuis bien avant que j'aie un SSD.
J’aurais tendance à penser que la taille mémoire totale (physique + swap) fixe une limite à l’overcommit, mais ça reste à voir…
Selon la doc (je voulais pas dire de connerie en me basant sur ma mémoire, un peu trop floue):
si overcommit = 0: le noyau essaie d'estimer la mémoire restante (swap+ram) lors d'un malloc;
si overcommit = 1: quand y'en a plus, y'en a encore;
si overcommit = 2 (mon réglage habituel et souhaité): si y'en a plus, y'en a plus.
Par défault, c'est sur 0, et overcommit_ratio vaut 50 (% de ram+swap). Sauf que, l'estimation, elle se fait par allocation, si ma mémoire est bonne (la, j'ai la flemme d'aller lire plus avant, désolé), ce qui fait que si 10 process ont alloué 5 fois chacune 10% de ta mémoire totale, mais sans la remplir, bah ça marche. Jusqu'a ce qu'une appli remplisse réellement la mémoire, bien sûr.
J'avoue ne pas savoir comment configurer l'oom killer.
Le truc, c'est que le code qui fuit, une fois qu'on sait qu'il fuit, on le corrige (pour le coup, c'est un code à nous).
Par contre, ben, comme on a aussi des problèmes hardwares, on a mis longtemps avant de détecter cette fuite (ça c'est fait de manière… fortuite, pour le coup).
Donc bon, je dirais qu'en fait, le plus simple c'est juste de pas squatter la RAM, de sorte a ce que l'overcommit soit désactivable. En plus, si mysql se servait vraiment de tout ça, il marcherait pas (et on serait passé à autre chose depuis longtemps, probablement sqlite pour mon plus grand bonheur, qui aurai au passage drastiquement simplifié le déploiement puisqu'on peut gérer une BDD binaire et la packager, au moins, alors que j'ai l'impression qu'avec mysql, on peut juste dumper le SQL et le restaurer par script. Pas génial pour faire un paquet.).
Il semble que la commande tc permets de manipuler les cgroups, et il me semble que ces derniers peuvent appliquer des restrictions sur l'usage des ressources à un groupe de processus. Comme je l'ai dis, je n'ai pas encore beaucoup creusé le sujet, donc je n'ose pas m'avancer trop, mais si ton but est de restreindre les ressources de la conversion pour éviter de tuer le serveur, ça me semble une piste viable.
Et en écrivant ceci, je me souviens de la commande nice, qui permets à minima de gérer les priorités. Si tu donnes a webp une priorité faible, tu ne devrais pas trop impacter le serveur, je suppose. Reste à voir comment ça joue avec le swap, forcément.
Je connais pas du tout bash (je préfère essayer de rester posix, pas encore eu a recourir à des bashismes ou zshisme pour le moment), et j'ai encore jamais eu l'utilité de xargs, mais je pense que j'aurai utilisé basename pour virer le suffix moi.
Passeriez vous par ce script ou rajouteriez vous une temporisation entre chaque conversion afin d'éviter de faire monter le server dans les tours ou d'autre opti?
En supposant que cwebp ne soit pas multithreadé, déjà, moi je lancerais plusieurs job simultanés. Et si il faut limiter le nombre, incrémenter un compteur jusqu'à une valeur définie et une fois atteinte, remplacer l'incrément par un wait.
Après, vue la "complexité" de ton script, je doute que tu puisses grapiller des cycles en l'optimisant, je pense que le CPU est bouffé par cwebp, pas par bash.
Si le problème est de justement limiter l'usage des ressources, et non d'aller au plus vite, j'imagine qu'utiliser les cgroups via tc devrais pouvoir faire le job, mais je n'ai pas encore creusé cet aspect du contrôle des ressources, je l'avoue.
J'ai lu les manpages, et essayé divers changements, sans effets actifs, parfois même avec des conflits entre la manpage et le binaire (debian, donc p'tet lié à des patch debian).
Je me souviens pas, mais j'ai essayé de réduire déjà:
le nombre de threads, 15-20 thread/process pour notre usage, c'est un pur gâchis, et chacun consomme son quota;
la mémoire par thread;
le nombre de requêtes acceptables en parallèle;
Et autres dont je n'ai plus souvenir: c'était y'a 4-5 mois, et je suis pas dba. Déjà que je dois apprendre à gérer un parc, faire une chiée de scripts, coder en C++ et former mes collègues, le tout sans moi-même être formé… pfiou. Le plus simple sera largement de remplacer ça par un outil plus adapté. Ce qui m'empêche pas de regretter la qualité faible de la doc. Pour le fun, j'essaierai un jour de me faire une vm avec d'autres BDD, et voir si j'arrive à mieux maîtriser l'occupation des ressources système.
P'tet que je changerais d'avis et que je considérerai mysql comme le fleuron, après ça.
Tu comprends mal. Un des logiciels maisons faits a eu une fuite de mémoire. Réactiver l'overcommit, et ajouter les conditions à la fuite mémoire à fait freeze les systèmes. Déplacement obligatoire pour rebooter, à plusieurs centaines de kilomètres.
Quand l'overcommit était désactivé, ben, sql marchait pas, mais le prog avec fuite mémoire se serait fait tuer dès le 1er dépassement de capacité, ce qui aurait évité le freeze.
N'étant pas un dev kernel, ni mysql/mariadb, je n'ai sûrement pas toutes les clés en main, mais pour moi, allouer plus de mémoire qu'il n'y en a vraiment de dispo sur le système, c'est une mauvaise chose que ça réussisse. Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus. Le choix de mysql était de base mal fait, mais voila, il a été fait avant que j'arrive, je n'ai pas eu mon mot a dire, alors j'ai fait avec de mon mieux.
Ah, j'oubliais, ces systèmes embarqués (aujourd'hui, un peu plus de 200) à plusieurs 10aines voires 100aines de km, sur lesquels on a la main via de la 2/3G (et ce, de façon aléatoire compte tenu de la captation de certains coins), ils utilisent runit pour gérer le moindre service, donc si l'un d'eux meurt, il est relancé à propre, ce qui réduit considérablement le problème. J'aurais pu utiliser systemd aussi, certes, ça serait revenu au même. J'aurai aussi pu utiliser les cgroups, il faudrait, même, mais voila, il faut le projet avance et je sais pas utiliser les cgroups.
SInon, ça a quoi de magique pour toi, l'overcommit? A quel moment tu trouves ça logique d'allouer des ressources inexistantes à un processus?
j'utilise la capacité d'Emacs à ouvrir des fichiers sur une machine distante à travers une session SSH (C-x C-f /ssh:user@host:/path/to/file). vi sait le faire aussi il me semble.
Jamais testé. De mon côté, je préfère utiliser sshfs, ça me permets d'utiliser la totalité de mon environnement principal sur la machine distante, notamment zfs.
Après concernant vi lui même, bien que je le connaisse peu, il me semble qu'il est aussi versatile qu'Emacs et qu'il peut permettre de faire à peu près tout.
vi est un simple éditeur de texte. A ma connaissance, il ne se programme pas, ne peux servir de frontal à gdb ou autres logiciels. vim en revanche, le peux probablement. En revanche, tout logiciel qui sait interagir avec des fichiers et un tty peut l'intégrer aisément (probablement la même pour emacs, mais j'ai l'impression que le paradigme d'emacs est plutôt l'inverse).
si on compare l'installation de base des deux, je pense qu'il ne doit pas y avoir beaucoup d'écart en terme de perf ou de conso de ressources.
Vi est, entres autres, fournis par busybox. Le build de debian hors installateur l'inclue. Je doute que emacs soit, même de loin, un candidat pour intégration busybox.
Enfin, a propos du fait que tu serais démuni sans ta conf d'Emacs : en même temps, c'est ça qui fait la force d'un outil adapté à ton usage et à tes besoins.
Dans ton cas, je partirais sur un parc de systèmes diskless, sauf pour le prof.
L'avantage, c'est que tu peux close les sessions à l'extinction des machines (hors débranchement, forcément), pas de risque de laisser des traces, des systèmes tout frais à chaque fois… par contre, faut que les élèves sauvent leurs travaux. Aussi, ça implique que les machines aient une alim fiable, sinon, ben, perte de travail aussi.
On peut aussi coller du diskless en sauvegardant le $HOME sur un serveur de fichiers, ça évite ces problèmes, mais c'est moins facile a mettre en place.
Un parc diskless, ça implique par contre d'avoir un LAN isolé ou d'avoir la main sur le DHCP maître, pour qu'il autorise BOOTP, et d'avoir un serveur TFTP/NFS pour héberger le système bootable. Autre avantage, c'est que si les élèves collent des virus sur leurs machines, via usb ou autres, ben, ça sera juste en ram, donc ça affectera qu'eux.
Je peux t'aider a déployer ça si t'as plus d'infos sur la config réseau de ta salle.
non, je parle bien de millisecondes, mais on parle du traitement de 800x600 pixels, pas juste de 32 entiers… chaque pixel étant codé sur 32 bits, et dans un format défini par le noyal, qui n'est pas identique au format RGBA de spng entres autres.
Me reste beaucoup a apprendre, et j'admets avoir aimé bosser sur ça: du graphisme low-level, c'est fun, surtout quand il faut coder une lib a destination de dev débutants, que libinput dépends du temps pour choper toutes les inputs et que, pour éviter les emmerdes, j'ai choisi d'interdire l'usage de multi-thread (multi-process avec comm par socket, c'est plus simple a debug, et de toute façon les threads seraient permanents…). Du coup, j'ai passé un peu de temps a optimiser.
À noter que j'ai réduit le temps moyen a 5ms, rotation incluse, avec des changements d'archi logicielle qui rendent l'usage de memcpy possible, donc, pour en revenir au comm précédent, probablement facilitent l'usage d'instructions dédiées par le compilo, sans pour autant attaquer moi-même l'ASM. J'en serai presque fier, s'il ne restait pas tant a améliorer…
C'est ce que je pense, oui, j'ai d'ailleurs déroulé la boucle manuellement après un peu de lecture sur SIMD. Je pourrais ptet encore booster en exploitant les flottants dans l'incrément, histoire de parraléliser calculs sur float et calculs sur entiers, mais bon, le plus gros des dégâts viens maintenant des cache miss a mon avis, vu que je fait une translation d'axes x/y sur 800*600 cases.
Sinon merci pour le respect dont tu fais preuve dans cette discussion, même si tu n'es pas d'accord avec moi (ce qui n'est pas le cas de tout le monde).
C'est normal, je pense. Même si je me log plus trop souvent sur linuxfr (la raison: j'ai l'impression que le contenu deviens plus orienté politique/bienpensance que technique, et j'aime juste la technique, la perf, causer ce cycles CPU, de Kio de ram, bref…)
Je précise : quand je dis "je suis dans le même cas" c pas par rapport au tilling, mais par rapport au fait que je n'aime pas supporter des soft hypers lents. Je préfère un environnement un peu moins joli mais plus léger. (je me suis rendu compte de la confusion de mes propos après coup).
j'avais compris.
Un jour lointain, je publierais un journal pour faire la pub d'une distro release-based orientée clavier & hackers. J'y travaille (sur la distro), mais les powerusers, c'est exigeant, donc attends pas et bidouille de ton côté. Pour la perf, un des pré-requis, c'est que le core tournera sur la plus vieille machine que j'ai a dispo: un 586 avec moins de 200Mio de ram. J'y fais déjà tourner debian, donc c'est facile, mais Debian c'est pas axé hacker pour moi, déjà que le côté poweruser a pris une sacrée claque…
s’attaquer à la pénurie de compétences avancées sur les bases de données
Pardon, mais, p'tet que le problème vient du fait que la doc est contre-intuitive? Chose qui sera jamais corrigée par des rencontres au sommet…
Désolé si je suis amer, mais je me tape (connotation négative volontaire) des systèmes "embarqués" (beaglebone black, 512Mio de ram, ça va, les ressources sont larges) sous debian, dont les softs utilisent mysql… pardon, mariadb.
Vu que "peu" de ram, systèmes sur mmc, distants (plusieurs 100aines de km, on peut pas y aller en un jour), et proprio (mea culpa) j'ai essayé de désactiver l'overcommit.
Soit. Sous linux, pas de souci, ça se fait en 1 ligne de conf. Par contre, ben, mariadb démarrait plus: pour une DB utilisée par 3 processus, il lui faut 10 threads/process, chacun bouffant sa dose de MébiOctets de RAM… bien trop pour l'usage.
Lecture de manpage. Modif de fichiers de conf. Essai… rien ne change. Réduire le nombre de threads ou la taille des caches ne fait RIEN, contrairement a ce que promets la manpage…
Alors, je sais, c'est pas fait pour l'embarqué, mais je dois faire avec, jusqu'a ce qu'on migre vers ce bon vieux sqlite, mais quand même, pourquoi qu'elle semble mentir, la doc? Pourquoi que c'est si dur de trouver des infos? Pourquoi qu'embarquer ce machin dans du proprio (désolé, vraiment, j'aimerai pouvoir release le code en libre, ma boîte y gagnerais même en qualité de code, parce que la, quand je lis le code, je pleure) embarqué, c'est pas possible?
Avant de s'attaquer aux problèmes avancés, attaquer la base serait p'tet pas mal.
Merci de votre lecture, vous pouvez moinsser maintenant :)
J'ai lu en diagonale le journal avant sa promotion. Je ne m'y suis pas attardé parce que 1) j'étais au taf 2) je n'y connais pas grand chose et 3) je l'ai bookmarké, pour quand j'aurai le temps.
Les FPGAs, j'ai découvert leur existence sur linuxfr, dans mon esprit, c'est mêlé avec des termes du genre verilog, VHDL, eux-mêmes étant liés (toujours dans mon esprit) à "plus bas niveau que l'assembleur".
Bref, me suis bookmarké ton journal parce que je pense qu'il me permettra d'augmenter ma compréhension de l'informatique de manière générale, et je pense que c'est un but qui est quand même vachement proche de ce que je suppose être un des objectifs du libre. Après tout, une des libertés est bien celle d'étudier, avec selon moi une connotation d'apprendre, de partager la connaissance.
Du coup, je pense que ton journal est plus qu'éligible au "rang" de dépêche, même si tu parles d'un hello world.
Accessoirement, c'est juste super cool de faire un hello world de ce style!
PS: bon courage pour la suite et meilleurs voeux de réussite.
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 3.
J'ai pas dit que je peux pas, j'ai dis que je ne sais pas faire, nuance.
Sans le moindre problème.
Ouai, non, en fait, je ne fais que parler de vécu, d'un type qui se démerde comme il peut pour que des systèmes expédiés au loin marchent sans intervention humaine, dans un respect complet de la Rache, méthodologie imposée par le patron.
J'ai autre chose a faire qu'attendre l'empathie. Je préfère en fait la laisser de côté, bien plus simple de s'améliorer en technique quand on met de côtés les sentiments.
Au pire, je peux finir a -10, et alors? Je n'en mourrai pas, j'apprendrais des remarques (à tout score, hein, de toute façon).
Justement, voici ta phrase:
Bon, à la relecture de mon dernier message, je note que je n'ai en effet pas indiqué n'avoir pas de connaissance sur le fonctionnement exact de l'OOM killer, je vais donc te plusser (je m'abstiens généralement, mais, tu est a -1 alors que c'est pertinent).
Cela dis, je ne sais plus si j'ai déjà explicité ça, mais l'OOM killer n'interviens jamais, ce qui cause un freeze du système. S'il faisait son boulot de tuer, les services (genre ssh et son tunnel inversé) soit redémareraient, soit seraient toujours exploitables.
Ici, je parle de freeze système, parce que l'OOM killer ne fait justement pas son boulot. Peut-être est-ce dû à la configuration par défaut, certes. Je compte vraiment creuser le sujet, je m'intéresse de plus en plus à cette partie qu'en tant que développeur je ne connais que trop: le contrôle des ressources d'un système. C'est plutôt passionnant en plus, connaître un peu mon système a pas mal changé ma façon d'architecturer le code, l'air de rien.
# lu que la moitié, mais j'ai une bonne raison...
Posté par freem . En réponse au journal Conception d’un circuit intégré avec Qflow. Évalué à 4.
… c'est que j'ai l'intention d'expérimenter la partie pratique a tête reposée (p'tet les prochaines vacances, et j'enchaînerais sur la lecture de ton journal sur la puce libre en arrivant p'tet a y comprendre quelque chose sur ce sujet passionnant :)). Merci pour tout.
Sinon, j'ai quelques questions, un peu hors-sujet, sur la partie théorique.
Tu décris plusieurs étapes qui semblent en grande partie automatisées, plusieurs d'entres elles me rappellent fortement des étapes d'électronique (des mes cours d'il y a 15 ans, dans peu de temps je dirais 20…), sauf que ben on partait du schéma… que tu appelles ici netlist, le placement et le routage étaient fait principalement manuellement, avec une "faible" aide logicielle. Je me souviens des "chevelus", notamment, et ça semble pour le coup encore d'actualité avec Kicad (oui, http).
Je suis loin de maîtriser le-dit logiciel (j'ai pas du tout bossé l'électronique ces 15 dernières années, mais pas a cause du manque d'intérêt, et je n'ai commencé à m'y remettre qu'anecdotiquement il y a quelques mois), et je suis bien conscient que c'est loin de la création de circuits intégrés, mais je suis intrigué par le fait que Kicad semble avoir des contributeurs embauchés par le CNRS, et que plusieurs étapes que tu définis comme très longues semblent automatiques avec ta pile? Mis a part l'échelle (de quelques cm pour l'électroniques à quelques mm pour la µélec) qu'est-ce qui, selon toi, l'explique?
[^] # Re: Autre piste
Posté par freem . En réponse au journal Création d'un système live-CD basé sur Debian. Évalué à 4.
Ce qui était le but, je l'ai même précisé:
Il y a une tonne de live cd qui traînent, je ne vois pas vraiment de bonne raison de faire ce que j'ai fait si le seul objectif est d'avoir un système live qui juste marche.
J'aurai peut-être en effet indiquer ces pointeurs, même si je t'avoue que je n'ai même pas pris la peine de chercher: perso, si je veux un système transportable, je prend un disque externe et j'y installe ma distro. Simple, efficace, souple.
[^] # Re: rootfs
Posté par freem . En réponse au journal Création d'un système live-CD basé sur Debian. Évalué à 3.
Je ne l'ai pas customisé, c'est vraiment comme si j'avais installé Debian sur un CD. Tu as raison, cela fait partie des choses qu'il faudrait faire ensuite, pour avoir vraiment un truc propre, à l'issue de ce journal, l'iso est franchement bancale, elle ne peux même pas s'éteindre proprement :)
Ça réduirait le problème, encore que le risque de collision reste important. L'idéal serait d'utiliser un UUID, mais je n'ai pas regardé comment ça fonctionne avec une iso. Probablement de la même manière qu'une partition normale, pour le coup.
Il y a aussi probablement le bazar de PAM qu'il faudrait copier avant de monter /var, et au fur et a mesure que j'ajouterais des composants, il y aura de plus en plus de choses à copier. Probablement.
C'est juste le strict minimum pour que ça marche. Ce que j'ai fait la, c'est un "hello world".
# Damn small linux?
Posté par freem . En réponse au message Une machine virtuelle légère avec python3.7. Évalué à 2.
Tout est dans le titre. DSL semble plus adaptée à ce que tu veux faire. Sinon, p'tet Alpine, aussi.
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 2.
Comme je l'ai dis, s'il était facile de configurer mariadb pour qu'il ne consomme que ce dont il a réellement besoin, j'aurai pu laisser l'overcommit désactivé, ce qui aurait fait certes crasher un soft à répétitition, mais aurais éviter un reboot physique du système. Et quand ledit reboot nécéssite de faire plus de 300 bornes, ben…
Bref, le problème est d'une part le fait que l'overcommit fait freeze le système, et d'autre part le fait que mariadb est incapable de fonctionner avec moins de 600Mo de ram sans overcommit, alors qu'en pratique, mariadb n'a pas besoin de toute cette mémoire.
Enfin, quand je dis que mariadb en est incapable, je veux surtout dire qu'il est extrêmement ardu de le configurer pour qu'il soit vraiment adapté à son environnement réel. Parce que, ben, la doc, elle est… disons, floue, pour être sympa.
Cela dis, j'ai l'impression a te lire que tu n'as pas lu mes précédentes interventions, parce que j'ai déjà expliqué ces points. J'ai l'impression que tu ne fais que défendre un outil, en disant qu'il s'adapte aux usages, mais tu n'expliques a priori pas les usages ou tu l'as vu fonctionner?
# On dirait un bookmark
Posté par freem . En réponse à la dépêche Les femmes et l’informatique — émission « Libre à vous ! » du 5 novembre 2019. Évalué à 5.
Pourquoi c'est une dépêche?
Où est le contenu réel?
Moi, je vois juste des photos, avec des liens. Si mon navigateur n'affichait que le texte, ça tiendrait sur un tty, et p'tet même en 40x10. J'ai donc moinssé.
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 2.
Comme dit plus haut, le problème ici est surtout que c'était une connerie monstrueuse d'utilise celui-ci dans notre cas. C'est juste pas fait pour.
Maintenant, essayer de réduire le dégât en attendant le temps de pouvoir migrer vers une vraie solution adaptée, aurait été de lire une doc qui ne mens pas. Ici, la doc m'a, selon moi, menti. Je parle de celle dans les pages de manuel ainsi que celle accessible sur le net, qui ne permets pas, de mémoire, aisément de choisir une version.
Windows est l'OS le plus populaire. Il a des qualités réelles, mais n'est que rarement choisi pour celles-ci, il est plutôt choisi par habitude plutôt qu'une analyse du plus pertinent pour l'usage. Linux devenant de plus en plus utilisé, nos distros font aussi des choix que je considère dans cette optique.
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 2.
Sauf que le problème, c'est qu'il n'interviens jamais dans la configuration par défaut, et ça résulte en un système freeze. La configuration par défaut est faite pour des systèmes dans lesquels la maîtrise n'est pas pas un problème parce qu'on peut rebooter d'une manière ou d'une autre, le système par défaut n'est pas autonome.
C'est (un de mes) mon soucis, justement: je me retrouve avec des softs (mysql ici) poussés par des débutants (avant que j'arrive, même si je ne me considère pas comme bon, j'ai un peu plus de recul qu'un étudiant, mais la boite a une histoire) parce que c'est ce qu'on apprend a l'école, mais l'école n'enseigne que des cas idéaux avec des ressources infinies, sans enseigner les cas ou les ressources sont limitées, qui existent pourtant dans la majorité des équipements informatiques (routeurs, switch, montres, radio-réveil, mobilier urbain, etc).
Ce n'est pas simple a expliquer, et a gérer encore moins, surtout que je me considère plutôt comme tech que comme décisionnaire ou architecte… faut naviguer entre compréhension de l'histo et ses racines, sa propre considération de l'idéal et les réalités de la boîte… donc pardonnes mes biais, raccourcis et imprécisions
[^] # Re: Sobriété ? Quelques questions...
Posté par freem . En réponse au journal Minimalisme numerique. Évalué à 1.
Ah tiens, merci de l'info, ça sera utile pour quand j'aurai la flemme de taper busybox :)
[^] # Re: Sobriété ? Quelques questions...
Posté par freem . En réponse au journal Minimalisme numerique. Évalué à 4.
Je ne suis pas entièrement d'accord, du fait que vi est implémenté dans busybox, et est le seul éditeur de texte interactif disponible par exemple dans le mode rescue de Debian.
Il va aussi se retrouver du coup dans l'initramfs en cas de problème, et la aussi, il sera le seul. Du coup, savoir s'en servir aide je pense à se dépatouiller plus facilement de situations pénibles (ou de faire des installs custo de Debian sans passer par l'installateur normal qui est, honnêtement, bien pénible quand on sait exactement ce qu'on veut).
L'avantage de savoir de vim, du coup, c'est qu'on sait de facto se servir de busybox vi, même s'il est vrai qu'il n'est pas ce qu'il y a de plus génial (forcément, le but est d'avoir un truc réellement minimal, pour le coup, qui puisse rentrer dans un très petit espace).
Ah, notepad gère enfin les fins de ligne non "CRLF"? Jamais testé, mais je me demande s'il supporte l'UTF8 aussi :p
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 2.
Pas con, j'essaierai. Je pense que mysql va se ramasser, mais ça vaut le coup d'essayer.
Tous les navigateurs graphiques que j'ai essayé pour le moment en font partie, virtualbox aussi. Ce sont les seuls que j'aie remarqués pour l'instant.
Sans problème. C'est juste que, du coup, il y a plus de 600Mio de réservés sur un système qui n'en a que 512Mio. Tant que ça marche…
Honnêtement, ça fait longtemps que je n'utilise plus de fichier d'échange: à quoi bon? C'est juste un coup a user plus vite le disque et faire quasi freeze le kernel. Je préfère de loin qu'un gros bloatware comme [insérer ici un navigateur mainstream de votre choix] se mange un oom kill. Et l'hibernation est plus lente qu'un cold-boot sur mes machines depuis bien avant que j'aie un SSD.
Selon la doc (je voulais pas dire de connerie en me basant sur ma mémoire, un peu trop floue):
Par défault, c'est sur 0, et overcommit_ratio vaut 50 (% de ram+swap). Sauf que, l'estimation, elle se fait par allocation, si ma mémoire est bonne (la, j'ai la flemme d'aller lire plus avant, désolé), ce qui fait que si 10 process ont alloué 5 fois chacune 10% de ta mémoire totale, mais sans la remplir, bah ça marche. Jusqu'a ce qu'une appli remplisse réellement la mémoire, bien sûr.
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 2.
J'avoue ne pas savoir comment configurer l'oom killer.
Le truc, c'est que le code qui fuit, une fois qu'on sait qu'il fuit, on le corrige (pour le coup, c'est un code à nous).
Par contre, ben, comme on a aussi des problèmes hardwares, on a mis longtemps avant de détecter cette fuite (ça c'est fait de manière… fortuite, pour le coup).
Donc bon, je dirais qu'en fait, le plus simple c'est juste de pas squatter la RAM, de sorte a ce que l'overcommit soit désactivable. En plus, si mysql se servait vraiment de tout ça, il marcherait pas (et on serait passé à autre chose depuis longtemps, probablement sqlite pour mon plus grand bonheur, qui aurai au passage drastiquement simplifié le déploiement puisqu'on peut gérer une BDD binaire et la packager, au moins, alors que j'ai l'impression qu'avec mysql, on peut juste dumper le SQL et le restaurer par script. Pas génial pour faire un paquet.).
[^] # Re: dirname/basename?
Posté par freem . En réponse au message fichier de sortie sans l'extension du fichier source. Évalué à 3.
Il semble que la commande tc permets de manipuler les cgroups, et il me semble que ces derniers peuvent appliquer des restrictions sur l'usage des ressources à un groupe de processus. Comme je l'ai dis, je n'ai pas encore beaucoup creusé le sujet, donc je n'ose pas m'avancer trop, mais si ton but est de restreindre les ressources de la conversion pour éviter de tuer le serveur, ça me semble une piste viable.
Et en écrivant ceci, je me souviens de la commande
nice, qui permets à minima de gérer les priorités. Si tu donnes a webp une priorité faible, tu ne devrais pas trop impacter le serveur, je suppose. Reste à voir comment ça joue avec le swap, forcément.# dirname/basename?
Posté par freem . En réponse au message fichier de sortie sans l'extension du fichier source. Évalué à 2.
Je connais pas du tout bash (je préfère essayer de rester posix, pas encore eu a recourir à des bashismes ou zshisme pour le moment), et j'ai encore jamais eu l'utilité de xargs, mais je pense que j'aurai utilisé
basenamepour virer le suffix moi.En supposant que cwebp ne soit pas multithreadé, déjà, moi je lancerais plusieurs job simultanés. Et si il faut limiter le nombre, incrémenter un compteur jusqu'à une valeur définie et une fois atteinte, remplacer l'incrément par un
wait.Après, vue la "complexité" de ton script, je doute que tu puisses grapiller des cycles en l'optimisant, je pense que le CPU est bouffé par cwebp, pas par bash.
Si le problème est de justement limiter l'usage des ressources, et non d'aller au plus vite, j'imagine qu'utiliser les cgroups via
tcdevrais pouvoir faire le job, mais je n'ai pas encore creusé cet aspect du contrôle des ressources, je l'avoue.[^] # Re: Sobriété ? Quelques questions...
Posté par freem . En réponse au journal Minimalisme numerique. Évalué à 4.
Pardon, faute de frappe: je voulais dire, zSH, et non zFS. ooups….
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 2.
J'ai lu les manpages, et essayé divers changements, sans effets actifs, parfois même avec des conflits entre la manpage et le binaire (debian, donc p'tet lié à des patch debian).
Je me souviens pas, mais j'ai essayé de réduire déjà:
Et autres dont je n'ai plus souvenir: c'était y'a 4-5 mois, et je suis pas dba. Déjà que je dois apprendre à gérer un parc, faire une chiée de scripts, coder en C++ et former mes collègues, le tout sans moi-même être formé… pfiou. Le plus simple sera largement de remplacer ça par un outil plus adapté. Ce qui m'empêche pas de regretter la qualité faible de la doc. Pour le fun, j'essaierai un jour de me faire une vm avec d'autres BDD, et voir si j'arrive à mieux maîtriser l'occupation des ressources système.
P'tet que je changerais d'avis et que je considérerai mysql comme le fleuron, après ça.
[^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 3. Dernière modification le 10 novembre 2019 à 02:30.
Tu comprends mal. Un des logiciels maisons faits a eu une fuite de mémoire. Réactiver l'overcommit, et ajouter les conditions à la fuite mémoire à fait freeze les systèmes. Déplacement obligatoire pour rebooter, à plusieurs centaines de kilomètres.
Quand l'overcommit était désactivé, ben, sql marchait pas, mais le prog avec fuite mémoire se serait fait tuer dès le 1er dépassement de capacité, ce qui aurait évité le freeze.
N'étant pas un dev kernel, ni mysql/mariadb, je n'ai sûrement pas toutes les clés en main, mais pour moi, allouer plus de mémoire qu'il n'y en a vraiment de dispo sur le système, c'est une mauvaise chose que ça réussisse. Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus. Le choix de mysql était de base mal fait, mais voila, il a été fait avant que j'arrive, je n'ai pas eu mon mot a dire, alors j'ai fait avec de mon mieux.
Ah, j'oubliais, ces systèmes embarqués (aujourd'hui, un peu plus de 200) à plusieurs 10aines voires 100aines de km, sur lesquels on a la main via de la 2/3G (et ce, de façon aléatoire compte tenu de la captation de certains coins), ils utilisent runit pour gérer le moindre service, donc si l'un d'eux meurt, il est relancé à propre, ce qui réduit considérablement le problème. J'aurais pu utiliser systemd aussi, certes, ça serait revenu au même. J'aurai aussi pu utiliser les cgroups, il faudrait, même, mais voila, il faut le projet avance et je sais pas utiliser les cgroups.
SInon, ça a quoi de magique pour toi, l'overcommit? A quel moment tu trouves ça logique d'allouer des ressources inexistantes à un processus?
[^] # Re: Sobriété ? Quelques questions...
Posté par freem . En réponse au journal Minimalisme numerique. Évalué à 4.
Jamais testé. De mon côté, je préfère utiliser sshfs, ça me permets d'utiliser la totalité de mon environnement principal sur la machine distante, notamment zfs.
viest un simple éditeur de texte. A ma connaissance, il ne se programme pas, ne peux servir de frontal à gdb ou autres logiciels.vimen revanche, le peux probablement. En revanche, tout logiciel qui sait interagir avec des fichiers et un tty peut l'intégrer aisément (probablement la même pour emacs, mais j'ai l'impression que le paradigme d'emacs est plutôt l'inverse).Vi est, entres autres, fournis par busybox. Le build de debian hors installateur l'inclue. Je doute que emacs soit, même de loin, un candidat pour intégration busybox.
+1
# le clonage est-il vraiment idéal?
Posté par freem . En réponse au message Aide pour faire du clonage dans une salle de classe, svp. Évalué à 2.
Dans ton cas, je partirais sur un parc de systèmes diskless, sauf pour le prof.
L'avantage, c'est que tu peux close les sessions à l'extinction des machines (hors débranchement, forcément), pas de risque de laisser des traces, des systèmes tout frais à chaque fois… par contre, faut que les élèves sauvent leurs travaux. Aussi, ça implique que les machines aient une alim fiable, sinon, ben, perte de travail aussi.
On peut aussi coller du diskless en sauvegardant le $HOME sur un serveur de fichiers, ça évite ces problèmes, mais c'est moins facile a mettre en place.
Un parc diskless, ça implique par contre d'avoir un LAN isolé ou d'avoir la main sur le DHCP maître, pour qu'il autorise BOOTP, et d'avoir un serveur TFTP/NFS pour héberger le système bootable. Autre avantage, c'est que si les élèves collent des virus sur leurs machines, via usb ou autres, ben, ça sera juste en ram, donc ça affectera qu'eux.
Je peux t'aider a déployer ça si t'as plus d'infos sur la config réseau de ta salle.
[^] # Re: quand je vois "demon système en python"…
Posté par freem . En réponse au journal Mini-projet (python): un démon système pour gérer des raccourcis clavier. Évalué à 2.
non, je parle bien de millisecondes, mais on parle du traitement de 800x600 pixels, pas juste de 32 entiers… chaque pixel étant codé sur 32 bits, et dans un format défini par le noyal, qui n'est pas identique au format RGBA de spng entres autres.
Me reste beaucoup a apprendre, et j'admets avoir aimé bosser sur ça: du graphisme low-level, c'est fun, surtout quand il faut coder une lib a destination de dev débutants, que libinput dépends du temps pour choper toutes les inputs et que, pour éviter les emmerdes, j'ai choisi d'interdire l'usage de multi-thread (multi-process avec comm par socket, c'est plus simple a debug, et de toute façon les threads seraient permanents…). Du coup, j'ai passé un peu de temps a optimiser.
À noter que j'ai réduit le temps moyen a 5ms, rotation incluse, avec des changements d'archi logicielle qui rendent l'usage de memcpy possible, donc, pour en revenir au comm précédent, probablement facilitent l'usage d'instructions dédiées par le compilo, sans pour autant attaquer moi-même l'ASM. J'en serai presque fier, s'il ne restait pas tant a améliorer…
[^] # Re: quand je vois "demon système en python"…
Posté par freem . En réponse au journal Mini-projet (python): un démon système pour gérer des raccourcis clavier. Évalué à 2. Dernière modification le 05 novembre 2019 à 22:07.
C'est ce que je pense, oui, j'ai d'ailleurs déroulé la boucle manuellement après un peu de lecture sur SIMD. Je pourrais ptet encore booster en exploitant les flottants dans l'incrément, histoire de parraléliser calculs sur float et calculs sur entiers, mais bon, le plus gros des dégâts viens maintenant des cache miss a mon avis, vu que je fait une translation d'axes x/y sur 800*600 cases.
[^] # Re: quand je vois "demon système en python", je crains pour l'aututonomie de mon o
Posté par freem . En réponse au journal Mini-projet (python): un démon système pour gérer des raccourcis clavier. Évalué à 2.
C'est normal, je pense. Même si je me log plus trop souvent sur linuxfr (la raison: j'ai l'impression que le contenu deviens plus orienté politique/bienpensance que technique, et j'aime juste la technique, la perf, causer ce cycles CPU, de Kio de ram, bref…)
j'avais compris.
Un jour lointain, je publierais un journal pour faire la pub d'une distro release-based orientée clavier & hackers. J'y travaille (sur la distro), mais les powerusers, c'est exigeant, donc attends pas et bidouille de ton côté. Pour la perf, un des pré-requis, c'est que le core tournera sur la plus vieille machine que j'ai a dispo: un 586 avec moins de 200Mio de ram. J'y fais déjà tourner debian, donc c'est facile, mais Debian c'est pas axé hacker pour moi, déjà que le côté poweruser a pris une sacrée claque…
# s’attaquer à la pénurie de compétences avancées sur les bases de données
Posté par freem . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 9. Dernière modification le 05 novembre 2019 à 21:53.
Pardon, mais, p'tet que le problème vient du fait que la doc est contre-intuitive? Chose qui sera jamais corrigée par des rencontres au sommet…
Désolé si je suis amer, mais je me tape (connotation négative volontaire) des systèmes "embarqués" (beaglebone black, 512Mio de ram, ça va, les ressources sont larges) sous debian, dont les softs utilisent mysql… pardon, mariadb.
Vu que "peu" de ram, systèmes sur mmc, distants (plusieurs 100aines de km, on peut pas y aller en un jour), et proprio (mea culpa) j'ai essayé de désactiver l'overcommit.
Soit. Sous linux, pas de souci, ça se fait en 1 ligne de conf. Par contre, ben, mariadb démarrait plus: pour une DB utilisée par 3 processus, il lui faut 10 threads/process, chacun bouffant sa dose de MébiOctets de RAM… bien trop pour l'usage.
Lecture de manpage. Modif de fichiers de conf. Essai… rien ne change. Réduire le nombre de threads ou la taille des caches ne fait RIEN, contrairement a ce que promets la manpage…
Alors, je sais, c'est pas fait pour l'embarqué, mais je dois faire avec, jusqu'a ce qu'on migre vers ce bon vieux sqlite, mais quand même, pourquoi qu'elle semble mentir, la doc? Pourquoi que c'est si dur de trouver des infos? Pourquoi qu'embarquer ce machin dans du proprio (désolé, vraiment, j'aimerai pouvoir release le code en libre, ma boîte y gagnerais même en qualité de code, parce que la, quand je lis le code, je pleure) embarqué, c'est pas possible?
Avant de s'attaquer aux problèmes avancés, attaquer la base serait p'tet pas mal.
Merci de votre lecture, vous pouvez moinsser maintenant :)
[^] # Re: Pourquoi en faire une dépêche ?
Posté par freem . En réponse à la dépêche k1g1 : le premier FPGA Libre…. Évalué à 4.
J'ai lu en diagonale le journal avant sa promotion. Je ne m'y suis pas attardé parce que 1) j'étais au taf 2) je n'y connais pas grand chose et 3) je l'ai bookmarké, pour quand j'aurai le temps.
Les FPGAs, j'ai découvert leur existence sur linuxfr, dans mon esprit, c'est mêlé avec des termes du genre verilog, VHDL, eux-mêmes étant liés (toujours dans mon esprit) à "plus bas niveau que l'assembleur".
Bref, me suis bookmarké ton journal parce que je pense qu'il me permettra d'augmenter ma compréhension de l'informatique de manière générale, et je pense que c'est un but qui est quand même vachement proche de ce que je suppose être un des objectifs du libre. Après tout, une des libertés est bien celle d'étudier, avec selon moi une connotation d'apprendre, de partager la connaissance.
Du coup, je pense que ton journal est plus qu'éligible au "rang" de dépêche, même si tu parles d'un hello world.
Accessoirement, c'est juste super cool de faire un hello world de ce style!
PS: bon courage pour la suite et meilleurs voeux de réussite.