freem a écrit 5059 commentaires

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.

et pour autant je promeus la démarche devops, docker n'étant pas dans mes solutions préférées pour diverses raisons

Du coup, c'est quoi tes solutions préférées? Par pure curiosité.

Bref, ce n'est pas le sujet qui est de réduire l'empreinte des logiciels demandés pour un fablab :-)

Allons allons, ce n'est pas comme si c'était la première fois que des digressions arrivent sur linuxfr, et en plus, il a posté un jeudi soir, le moment idéal pour avoir un journal exposé au trolldi dès le matin à la 1ère heure :p

Je suppose que je t'ai mal compris dans ce cas, ou que je me suis mal exprimé. Je vais développer un peu plus, en citant de manière plus ciblée:

difficulté de mise à jour

c'est justement un de ces points forts

Comparé aux gestionnaires de paquets traditionnels, dont apt, non? Ou alors, comparé à quoi?

lancer un nouveau container […] est bien plus rapide

Pour moi, relancer juste un service après une MàJ, c'est plus rapide que relancer un service ET ses dépendances… du coup, en quoi, par exemple, apt serait-il plus lent que docker?

lancer un nouveau container […] est bien plus reproductible et facilite le retour arrière

Ici, je veux bien t'accorder le bénéfice du doute, dans le cas que je connais le mieux (apt), un paquet foireux pourrait effectivement n'être pas reproductible et donc ne pas faciliter le retour en arrière.

Sauf que, en pratique, j'ai fait suffisamment de va-et-viens entre les diverses versions de Debian (avec un peu d'apt-pinning et quelques repos externes, dont 1 non-free, au passage, pour bien essayer de foutre la merde) pour savoir que les paquets Debian sont solides, très solides.

Hum… en quoi les paquets apt seraient-ils lents, non-reproductibles ou empêcheraient le retour en arrière?

Je suis curieux de voir tes références, parce que j'ai personnellement fait pas mal joujou avec l'apt-pinning et le yoyo entre une stable et une unstable/sid, en passant par testing, et sans problèmes particuliers.

Ok, finalement j'ai réussi. Pour info, si l'on n'utilise pas logind, ce qui est mon cas, ou que l'on n'a pas la possibilité d'utiliser des pilotes compatibles DRM/KMS, il est possible de contourner le problème en:

• installant xserver-xorg-legacy
• mettant ou ajoutant la clé de configuration needs_root_rights=yes dans /etc/X11/Xwrapper.config`.

Trouvé via ces 2 liens.

C'est un peu hors-sujet, mais du coup, un des problèmes qui me bloquaient est enfin résolu :)

si c'est un disque qui sera deplacable (usb) il n'est pas recommandé d'utiliser ext4 car il ne sera alors pas lisible sur windows/osx

Pour être exact, il ne sera pas utilisable sous windows tant que le pilote correspondant n'est pas installé. Mais il existe des outils qui permettent d'accéder à des partitions ext4 depuis windows. Pour OS X, je ne sais pas.

Enfin, c'est un détail, de toute façon je suis d'accord qu'il vaut mieux utiliser ntfs pour faire transiter des données d'un os à l'autre, ça simplifie les choses pour les non linuxiens, qui sont bien plus nombreux.

Intéressant, merci, il faudra que je l'essaie. Ca peut toujours servir ce genre de trucs.

Le truc, c'est que sous Debian, pour installer KDevelop, il faut installer KDE, no way pour moi, j'ai autre chose à faire de ma bande passante et de mon espace disque.

Et pour ce qui est de QtCreator… comment dire… la dernière fois que j'ai utilisé ce machin, il ne me restait plus que l'équivalent d'une feuille A6 pour coder.
Comparé à mon i3 combiné avec mes urxvt, le gain d'espace est juste évident. La seule chose qui me fait parfois envie dans les IDEs, c'est bien leurs debuggers, et encore.

Les debuggers les plus puissants et les mieux foutus que j'aie vu, c'était sous windows, et aucun n'incluait, à ma connaissance, de fonctionnalités d'édition de code:

• softice un débugger en ring 0,
• IDA qui même dans sa version démo est capable de rendre la lecture de code assembleur relativement aisée,
• w32dasm lui était un peu léger en fonctionnalités il faut le reconnaître, mais ollyDbg en revanche était très bien.

Si un seul IDE sous linux dispose d'un interface à gdb (ou llvm, pourquoi pas) aussi efficace que n'importe lequel de ces outils, je suis curieux de savoir duquel il s'agit (cgdb en est, lui aussi, extrêmement loin, nous somme d'accord, mais au moins il se lance dans la seconde même avec des machines pas sur-puissantes).
Bon, dans le cas de softIce, il y avais bien rr0d mais j'avoue ne jamais avoir joué avec, et le projet semble mort depuis bien des années.

Enfin, je serai aussi preneur du sondage github, je ne savais même pas que github en faisait…

D'accord. Bon ben j'aurais appris un truc aujourd'hui :)

C'est ici. Bon, il n'y a pas des masses de projets dessus, certes (6 dont c'est le forum officiel, 9 «invités») mais bon, ça lui éviteras de parcourir la toile et je pense qu'une telle proposition sera acceptée avec joie.

La variable Do est initialisé à 0 par défaut.

À quel endroit? Je ne vois aucune affectation à Do autre que dans EraseAll moi. Le standard spécifie qu'une variable est toujours initialisée à 0? Je n'en suis pas si sûr… d'ailleurs, je surpris qu'il n'y ait pas le classique warning "value not initialised" ou un truc dans ce goût la.