freem a écrit 5019 commentaires

Salut et bienvenue.
Pour info, il y a un bouton repondre en bas des commentaires, ca permets de garder une arborescence dans les discussions, comme pour une mailing list.

Sinon, je me suis toujours pose la question, a quel public sont destines ces evenements, quel est le niveau de "culture logicielle" necessaire en moyenne pour ne pas s'y sentir etranger?
Question encore plus valable je pense pour ceux qui (comme moi, pour le coup) n'ont pas d'utilisateurs volontaires de LL (comprendre: qui savent ce qu'est un ll, et qui en utilisent, avec ou sans contribution) dans leur entourage.

Une question, toute bête, mais pourquoi tu t'emmerdes avec select()?

Ce n'est que m'on avis personnel, mais je trouve les codes qui utilisent select imbuvables, poll me semble tellement plus lisible, plus intuitif:

• tu initialise un tableau qui contiens autant d'instances de pollfd que de fd à surveiller, ces structures contenant: le fd en question, un bitfield uniquement lu (donc, pas besoin de le réécrire après un appel, contrairement à select de mémoire) qui contiens les évènements à surveiller, un autre uniquement accédé en écriture. Accessoirement, le timeout est juste un entier en millisecondes, je trouve ça tellement plus simple.
• tu le passes à poll.
• tu récupères le nombre d'évènements et tu itères sur ton tableau pour voir quelles structures ont leur revent pas à 0
• le tour est joué.

Au niveau avantages:

• pas besoin de rafraîchir les tableaux qui contiennent les files à surveiller
• une seule structure pour tous les types d'évènements
• pas de limitation hard-codée par le système (donc, pas de gâchis d'espace ni de limitations dans le nombre de descripteurs à surveiller)
• pas de macros (donc des messages d'erreur plus simples à comprendre et en cadeau bonus une type safety un peu moins crade)
• données mémoire plus compacte
• on peut désactiver la surveillance sur un fd en lui affectant une valeur négative, tandis que select requiert uniquement des fd valides.

Les inconvénients… je n'en connais pas. Ah, si, la doc indique que c'est un peu plus récent (POSIX.1-2001, contre une apparition de select dans 4.4BSD) mais franchement, ça fait quand même plus de 15 ans, ça devrait le faire sur la plupart des systèmes.

Bon, tu fais ce que tu veux, mais ton bug est très probablement lié au fait que, justement, select ait une interface dégueulasse:

        rv_select = select(usbfile_select+1, &set, NULL, &set, &timeoutValue);

Tu utilises 2 fois la même structure, du coup, select, ben, il écrit 2 fois dedans…

Je pense que c'est une reference a ca.

Ça doit être en exploitant les gens qui pensent comme des bites, pour le coup…

Non, je ne me moque pas, je n'ai vraiment pas lu. Cependant!

Cependant, bien que ton post ressemble (présentation,formulation) à la question d'un étudiant, elle ressemble à celle d'un étudiant qui a cherché.

Du coup, les gens voudrons bien te répondre, je pense. Enfin, ceux qui savent. Je vais essayer d'améliorer ta façon de poser des questions pour avoir des réponses plus rapides et pertinentes, de mon côté:

• montrer que tu as cherché: OK.
• débuts de solutions: OK
• expliciter le problème réel, et non la solution imaginée: PAS OK (pour info, je tombe encore souvent dans ce travers). On sait que tu as résolu ton problème en suivant certains liens. Super. Mais on ne sait pas quel était ton problème de base, du coup on ne peux pas y répondre. Essaie d'être exhaustif et synthétique: c'est difficile, oui, mais c'est le plus efficace. Ici, tout est flou de mon point de vue.
• exposer un bout de code minimal sur les forums permettant de reproduire le problème, et expliciter le problème: PAS OK non plus: beaucoup de commentaires ici, trop, on sent que tu ne comprends pas ce que tu as fait, ça n'encourage pas à lire.

Enfin, c'est mon avis. Ne le prend pas mal surtout, j'essaie surtout ici de t'aider à avoir des réponses en posant les bonnes questions: c'est une compétence vitale aux informaticiens.
C'est une des raisons pour lesquelles ont doit savoir se faire comprendre des autres: demander l'aide de nos pairs.

Pour ça, la publication d'un journal sera grandement appréciée :)

L'air de rien, ce simple exemple me rappelle un jeu d'énigmes (et zut, je ne me rappelle plus le nom du jeu, mais le contexte et les perso, si: un jeu de puzzle, avec 2 poissons, un gros et un petit, dont les aventures les amènent à déplacer nombre d'objets que l'on imagine polluants, qui rendent la mer sale, et dont les commentaires d'ailleurs nous font comprendre que que c'est pénible).

Concrètement, si vous voulez convaincre ou persuader des gens de travailler sur un projet de jeu vidéo (je ne connais pas le monde du plateau, pas en tant que potentiel contributeur en tout cas) sans frais de votre part (mais en amenant les idées, et, l'air de rien, c'est loin d'être du vent, tout dev expérimenté le sais… en fonction du niveau de développement des idées en questions) et en gardant un esprit très libre, j'ai peut-être quelques pistes pour vous aider:

• opengameart est un site qui offre des ressources artistiques généralement libres, à voir selon les licences particulières si elles correspondent aux besoins, et au pire elles peuvent parfois servir à bricoler un «POC», une Preuve De Concept en français (Proof Of Concept).
• freegamedev est un site qui héberge une communauté de développeurs de jeux amateurs et libristes, vous devriez être plutôt bien accueilli la-bas, et bien que je doute qu'ils aideront pour la réalisation du jeu lui-même (ils travaillent sur leurs propres projets libres) je ne doute pas qu'ils vous donneront d'autres indications, ainsi que des questions et conseils des plus pertinents.

Pour finir, quand vous deux aurez une bonne idée du résultat final souhaité, je pense qu'un journal ici-même (c'est ouvert à tous) pourra ouvrir des pistes pour la réalisation elle-même, éventuellement au travers d'une levée de fond.

Voila, je n'aide pas des masses, mais je pense que ces pointeurs pourront le faire mieux que moi. Ceci dit, je suis moyennement confiant pour l'avenir de votre projet:

• d'une part, rien n'est dit, c'est généralement mauvais signe, d'autant que vous n'avez pas l'air d'avoir de connaissances du tout sur les technologies du jeu vidéo (mais, ce n'est pas bloquant, avec le bon conseil)
• d'autre part vous semblez très axés sur le côté logiciel libre, ce qui peut plaire à des activistes ou contributeurs (je suis personnellement intrigué par le projet, mais vu que vous n'en parlez pas…) et donc cela peut impliquer une réutilisation des ressources, ce qui est important.

À noter, quand même, je ne connais pas vos engagements politiques ni vos notions de droit, mais quand on parle de conception logicielle et artistiques, c'est nécessaire de savoir: pour raccourcir très grossièrement, la propriété intellectuelle fermée, appelée copyright, interdit toute réutilisation; la philosophie GNU force la publication de toute modification publiée sous forme libre (et en pratique quasi-inexploitable commercialement sans une infrastructure dédiée au service) et reste la philosophie BSD, qui est celle avec le moins de restrictions.
Ce sont des raccourcis, mais je pense que c'est mieux d'avoir conscience des implications diverses et variées.

Après, tu peux le faire aussi avec un script. Passer sur BSD juste pour ifstated, ça me semble overkill.

Tu n'es pas joueur… j'ai dis que ça me fournirai une excuse, mais je reste un minimum pro, j'essaierai autre chose d'abord, c'est évident: moi, BSD, ça m'éclaterai, mais mes collègues, c'est pas sûr, et puis j'ai un travail a accomplir.

Il faut donc avoir plusieurs serveurs chez plusieurs hébergeurs que tu ping et tu ne bascule que si plusieurs tombent. Par exemple, 8.8.8.8, le site de ta boîte et ping.online.net.

D'accord. C'est bien vu. J'avais à la base compris que tu parlais d'avoir plusieurs outils pour surveiller que la connexion est bien active, pas de vérifier plusieurs sites au cas ou l'un est HS.

Merci pour ces infos, je ne suis vraiment pas habitué à bosser sur du réseau, mais entre mes problématiques perso et de taf, en 1 mois j'en ai appris beaucoup grâce à vous deux, entres autres (pas sûr que sur ma dernière question il n'y avais que vous deux, et puis il me faut compter tous les liens que j'ai lu, grâce à vos mot-clés) :)

Et pourtant, «l'énergie est notre avenir, économisons la» XD

Merci à vous deux pour ces éclaircissements.

l'etape au dessus, c'est de detecter si tu arrives à joindre un service externe (ping vers google, telnet vers un site web)
et de changer la route par defaut pour passer par l'autre interface.

C'est l'objectif.

Il y a ifstated chez les BSD mais je ne connais pas d'équivalent sous les distributions Linux.

On est sous Debian parce qu'on connais un peu Debian (quand je dis un peu, c'est vraiment un peu, je suis le plus «calé» et je ne me considère vraiment pas comme un expert), à priori, rien n'interdirais d'utiliser un *BSD (enfin, reste à voir si le matos serait compatible, bien sûr, mais ça me donnerai un prétexte)

il vaut mieux avoir plusieurs services à haute fiabilité derrière.

C'est à dire?

maintenant je trouve etrange que ta config parle d'une carte GPRS, mais active une interface ppp0
cela ne devrait-il pas etre ppp0 dans ton fichier /etc/network/interfaces ?

Pour le coup, j'ai bêtement suivi la doc de Debian, et il reste un comportement qui m'intrigue beaucoup: il faut manuellement faire un ifup gprs pour que la connexion s'établisse, et c'est bien ppp0 qui apparaît quand je fais un ifconfig (ça m'avais aussi surpris).

Le fichier /etc/network/interfaces au stade avant les expérimentations réseau:

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

# oui, en plus il y a 2 ethernet, pour faire simple, alors qu'un aurait suffit
allow-hotplug eth1
iface eth0 inet dhcp

allow-hotplug gprs
iface gprs inet ppp
  provider gprs

Mais si ce double swap engendre un problème, je serai bien incapable de le résoudre.

J'ai oublié de mentionner que l'on peut désactiver la 1ère partition de swap, en enlevant la ligne correspondante dans /etc/fstab (je te conseilles la lecture de man fstabavant).

Je laisse mes disques vivre tranquillement leur vie, l'origine du problème doit être ailleurs pour ma part.

Clairement, mais tu m'as demandé mon anecdote :)

Euhh simple, pas pour moi,

Pardon, l'habitude :)

En fait, il est possible de rediriger ce qui s'affiche sur un terminal dans un fichier, il suffit d'ajouter > mon_fichier après la commande. Bon, même sans la montée de charge, je suppose qu'on pourrait toujours avoir quelques infos…

il faudrait que je l'étende avec Gparted depuis un Live CD, mais j'hésite à bidouiller les partitions si le résultat n'est pas certain.

Il est possible d'utiliser un fichier pour le swap, également: dd if=/dev/zero of=mon_fichier bs=taille_fichier; mkswap mon_fichier; echo '/chemin/complet/mon_fichier none swap defaults 0 0' >> /etc/fstab.
La commande dd permets de créer le fichier «nom_fichier» d'une taille de taille_fichier, sachant que l'on peut utiliser (entres autres) le modificateur d'unité "G" pour indiquer des giga-octets (cf man dd), mkswap initialise le fichier comme étant un fichier de swap, et enfin le echo ajoute la description du fichier swap dans le fichier /etc/fstab, qui décrit les points de montage.
ddn'as pas, et ne doit pas, être exécuté en tant que root ou via sudo (enfin, on peut, c'est juste qu'une erreur de frappe peut détruire le système), mkswap n'en a probablement pas besoin non plus, mais le echo dans le fstab si. À noter que le '>>' permets d'ajouter à un fichier, tandis que le '>' écrase le contenu existant. Il ne faut surtout pas se tromper dans cette manipulation!. Enfin, tu pourrais aussi utiliser un éditeur de texte, bien sûr ;)

À noter que, n'utilisant pas de swap, j'ignore comment le système se comporte en présence de 2 swap distincts.

Mais toi, comment t'en es tu sorti ?

À l'époque, j'étais tombé sur un bug de udev qui, suite à une mauvaise manipulation d'un de mes disques de ma part, faisait ce que l'on appelle une boucle infinie, en allouant de la mémoire. Vu que le noyau à, par défaut, une politique optimiste pour l'allocation de la mémoire vive (il considère qu'il en restera bien un peu donc laisse tout passer) et que j'utilisais du swap, mon système envoyais les données de la mémoire vive vers le swap et vice-versa en permanence, ce qui résultait en un très gros ralentissement du système jusqu'au freeze (et ce, dès le démarrage, c'était donc pire que ta situation… j'ai ouvert un rapport de bug chez debian, et n'ai eu des nouvelles qu'un an après: il a été clos parce que franchement, j'avais la flemme de répondre à un problème survenu 1 an auparavant et que ça a donc été considéré réglé.).
Je m'en suis sorti en refaisant la table des partitions que j'avais endommagée. La similarité potentielle, c'est une erreur de «matériel» suite à un changement logiciel (la mise en veille), et le fait que le processus qui es responsable d'exposer le matériel au système soit le même que celui qui gelait mon système.

Pour le coup, il n'est pas certain que ce soit ça le problème, c'est juste que ce n'est pas impossible.

On peut présupposer qu'il ne souhaite pas non plus qu'une partie de sa configuration soit en accès libre

On peut, en effet, mais ça n'est que suppositions.

Comme par example la conf wpa_supplicant ou tout autre information qu'il juge importante.

Sauf que rien ne force a avoir le wpa_supplicant.conf dans /etc (pour ma part il est dans mon $HOME à la maison, ne serait-ce que parce que c'est plus simple pour le multiboot). Je ne sais pas ce qu'est le reste, mais à part le fstab et 2-3 fichiers critiques aux fonctionnement du système, je doute que ce soit une solution inenvisageable de les déplacer.

Il a dis que les mises à jour système nécessitent un reboot. Ce qui, en gros, veut dire les libs et programmes qui sont nécessaires à faire fonctionner ta machine et qui ne peuvent être déchargées aisément. En gros, le kernel, la libc, l'init. Dans une moindre mesure, X11 (il te faut au moins fermer ta session à priori), dbus & co.
LibreOffice ne fait pas vraiment partie de cette couche bas niveau la.

Après, je pense aussi que microsoft traîne pas mal de casseroles, je pense notamment au fait que le système dans son ensemble manque d'organisation au niveau des dépendances, ce qui fait qu'une lib sera bien souvent installée de nombreuses fois sur le système, et du coup la mettre à jour est loin d'être aussi rapide et «simple» que sur d'autres systèmes qui utilisent une hiérarchie plus clean, qui ont aussi plus de contrôle sur qui met quoi où: Microsoft n'a aucun contrôle sur ce que font les installateurs, ou presque. Tandis qu'avec des systèmes tels que Debian, ou l'immense majorité des paquets installés (je parle du cas que j'imagine le plus répandu, pas des machines avec des chiées d'images docker, de repo externes ou de trucs installés à coup de make;make install proviens d'un dépôt maîtrisé par la distribution, c'est plus simple.

Pourquoi ne pas juste chiffrer le home du coup?
Ok, ton disque fonctionnerait sur un autre système, mais les données du home, qui sont ce que tu sembles vouloir protéger, seraient protégées?

La force de l'habitude?

Sinon, en pratique, tu fais comment pour configurer un système en multiboot sous UEFI sans boot loader?
Je suis très intéressé par une piste: je n'ai jamais aimé grub (et l'ai très peu utilisé) mais les alternatives que je connais (lilo, syslinux) ont leurs contraintes (grub en a d'autres). Du coup, si je pouvais directement gérer en passant par l'UEFI, ça m'aiderait.

Il y a une zone qui se modifie continuellement, je ne sais bien entendu pas interpréter.

C'est normal que ça se modifie en permanence, les applications ne fonctionnent en fait pas en permanence, juste assez vite pour en donner l'impression. Et comme le tri se fait en fonction de la puissance de calcul demandée par les applications à un moment t, l'affichage change.

Il faudrait en fait ces informations juste avant que ça ne plante, pour le coup, c'est à ce moment la qu'elles seraient intéressantes (et sans avoir stoppé udev au préalable, bien sûr. Je ne sais pas si tu l'as fait, naturellement, mais c'est au au cas ou).
Pour avoir des traces, en fait, il "suffirait" de faire ressortir les informations dans un fichier, c'est simple, mais ça les écraserait en permanence, du coup on n'aurait pas la montée de charge, qui aurait été intéressante si le problème viens bien d'une saturation des ressources.

Je ne sais pas ce qu'est "udev".

Pour faire simple, le noyau linux détecte le matériel, dynamiquement. Udev lui permets d'exposer le matériel aux applications, en gérant les droits associés et en publiant des fichiers dans /dev.

Si tu pouvais m'expliquer comment on stoppe udev, je vais en attendant essayer de trouver par moi-même, mais c'est pas gagné…

Deux solutions, toutes deux dans un terminal, toutes deux ont un effet pervers (plus de reconnaissance automatique du matériel inséré après les manipulations) et sont limitées dans le temps (jusqu'au prochain redémarrage):

• sudo service udev stop
• sudo killall -9 udevd

La première méthode est plus propre, mais risque d'échouer si udev est effectivement en défaut, la seconde risque de ne pas fonctionner si le système d'init (systemd, très probablement) décide de redémarrer udev, ce qui est probable.

Tu me donnes de l'espoir, j'espère vraiment que c'est la solution

Cette idée est juste pour tester que la cause viens bien de la, il ne s'agit vraiment pas d'une solution, tu l'auras compris. C'est vraiment pour du diagnostique…

Il y aurait un autre moyen de vérifier si c'est un problème de ressources qui viennent à manquer, maintenant que j'y pense.
Toujours dans un terminal: watch -n1 "ps -A -opcpu,rss,vsz,comm | tail -n+2 | sort -n -r". Cette ligne se compose de 4 commandes: watch qui permets de lancer le reste périodiquement ("-n1" signifie chaque seconde), "ps" qui affiche des informations sur une sélection de processus ("-A" pour tous les processus, le reste permets de sélectionner les informations à afficher: usage processeur, deux «types de mémoire», et le nom du processus) tandis que le reste sert à enlever la ligne d'en-tête de ps ("tail -n+2 affiche les résultats en partant de la ligne 2) et de trier ce qu'il reste (par défaut sur la 1ère colonne, le -n indique que la valeur est numérique, et le -r sert à inverser le tri, pour que les plus gros soient en 1er).

Les commandes passées à watch sont entourées de "pour que watch prenne en compte la totalité.
Le problème de cette méthode, c'est le taux de rafraîchissement faible et le manque de traces, mais c'est toujours mieux que rien.

sauf que le detail c'est qu'on parle d'une personne agee, qui a vu plus de 60 ans d'evolution des techs et des moeurs, et depuis la 2e gm ca a mechamment bouge… vote et travail des femmes, internet, conquete de l'espace, et tous les impacts societaux lies, entres autres, a ca….

normal que les anciens soient largues, et meme nous on ne peux gerer toutes les manipulations (un coup de fatigue peut arriver).

comment tu veux qu'on t'aide sans infos sur ce que tu as (essaye de) faire?
On est comme toi, on n'as pas de 6eme sens pour la divination…

Oui et non…

De maniere generale, oui, parce qu'a part des cas particuliers (je ne serai pas surpris qu'il existe encore du matos utilisant ce media dans certains ateliers), plus personne n'utilise ca.
Mais ce n'est pas la racine du probleme, le kernel sait gerer les disquettes.

Ceci dit, j'ai une question: y a-t-il une disquette dans le lecteur? Parce qu'il semble que ce soit le cas, et qu'elle soit fichue (secteur 0, erreur d'entree/sortie).

J'ai deja experimente ce genre de problemes, et la cause etait udev qui partait en boucle infinie a cause d'un probleme dans la table de partitions, avec allocation memoire et donc acces disques (diode de disque dur zllumee non stop) a cause de l'usage du swap (et pas de oom killer, je ne sais pourquoi?)
Du coup, autre question: est-ce que stopper ou tuer udev apres la sortie de veille resouds (jusqu'au prochain reboot) le probleme?

À savoir que c'est aussi utile pour debugguer, vu que ça peux jouer le rôle d'un sniffer du coup. Hors, ici, on pourrais imaginer une machine avec 2 ports série: un avec le produit propriétaire, l'autre avec le hard, on pilote le hard à partir du proprio, on intercepte les trames et hop, le tour est joué.
Enfin, il faudrait jouer un peu avec socat, tee et les dumps, mais c'est plus simple que chercher à deviner à partir de fuzzing.

Le seul problème est que la sortie est brute, et que les convertisseurs que je connais (hd et od) attendent soit d'avoir assez de données, soit un retour chariot… faudrait que j'en implémente un, un jour, me serait utile au taf.

J'ai testé nemiver (à plusieurs reprises, avec plusieurs versions de debian). Il m'a tout sauf convaincu, j'ai trouvé l'interface à la fois bordélique et vide (étrange concept), et comme c'est une application graphique, c'est conçu pour un usage à la souris ou alors avec des raccourcis claviers qu'il faut deviner. Généralement, quand je teste un debugger, c'est que ma patience avec celui que j'utilise atteint ses limites, donc je cherche un truc qui soit à la fois bien foutu, assez puissant et s'apprenne vite. Cgdb a, quand je l'ai découvert, rempli ces conditions.
Mais vu que c'est debian, il y a peut-être eu des changements depuis dans la version upstream.

Quant à l'autre, je ne connaissais pas, mais à vue de nez, ça ressemble à un IDE (vue la description qu'ils en font) et donc c'est hors concours.

Merci pour l'explication (et merci aussi à Xavier, mais comme on ne peux pas répondre à 2 messages d'un coup…)

Mais le standard est respecté, justement, c'est juste que les optimisations les plus agressives exploitent les trous laissés parfois volontairement par les standards pour essayer (résultat non garantit) d'aller au plus vite pour un même résultat conforme au standard.

Enfin, c'est sûr, si on compare à des langages qui sont basés sur des implémentations de référence, forcément ça peut surprendre. Mais je ne crois pas que ces langages soient ou souhaitent être réputés pour leurs performances.