benja a écrit 1211 commentaires

Rajoute ceci au début du script (juste après le shebang) et ensuite consulte le fichier log pour voir ce qu'il se passe. Aussi pour que cela fonctionne il faut que systemd se charge de la mise en veille… Rajouter un PATH=/sbin:$PATH ne peut pas faire de tort aussi.

exec >/tmp/log
exec 2>&1
set -x

lesquels, mdadm?

libraspberrypi0, -doc et -dev. Les deux derniers dépendent de librasberrypi0 en même version. Tu peux les enlever sans crainte, ça devrait déjà arranger ton bazard. Donc : dpkg --purge libraspberrypi-doc libraspberrypi-dev suivit d'un apt update; apt install -f.

Il me semble aussi qu'il a déjà trouvé la solution. Ce qu'il manque c'est simplement de mettre un script dans /lib/systemd/system-sleep/ et de le rendre exécutabe. Genre swap.sh:

#!/bin/sh

case $1 in
  post)
    swapoff -a; swapon -a
    ;;
esac

À tester !

source: man systemd-suspend.service

Toutafé d'accord, mon point est que parler d'overhead de cat dans ce genre de situation est absurde. Rien que compiler une regex doit prendre plus de temps qu'un fork+exec. Un argument plus "valable" serait la copie dans un pipe, et encore ça me semble tout autant négligeable proportionnellement. Bref j'attends une démonstration avec des chiffres, bonne chance ;-)

Si on en est à ce niveau d'optimisation peut-être vaudrait-il mieux commencer par questionner la pertinence de faire ce traitement par un script shell ?

Quel est le % des donnés "inactives" dans ces 8 GO ? Genre un documents openoffice de 200 pages qui est minimisé/sur un autre desktop depuis 2 jours… Est-ce que les 5 secondes que tu vas perdre en le rouvrant compensent le ralentissement général induit par la non utilisation de la ram ou son coût ?

Si on aime avoir des applis random qui crachent parce qu'on est à court de mémoire, si on n'utilise jamais tmpfs, si on passe son temps à changer d'applications et d'onglets toutes les secondes de sorte à n'avoir aucune donnée qui n'est pas constamment lue, alors oui je suppose que le swap ne sert à rien. Sinon il parait que les gens sérieux la laissent et "qu'en générale" (!= sur une grappe de calcul) ça augment les performances car les données inactives sont dégagées afin de faire de la place pour le cache disque.

http://raspberrypi.stackexchange.com/questions/9050/held-broken-packages

Apparemment t'as réussi à installer une version plus récente d'un paquet que celle disponible dans tes dépots (ou alors raspian a merdé quelque part). btw t'as pas oublié d'apt update au moins ?

Bah faut arrêter avec ce dogme uuoc. En mode interactif. c'est un workflow plus naturel je trouve. Pour 2 raisons liées à l'utilisation de l'historique : 1) on fait un cat simple pour voir le contenu du fichier avant d'effectuer un traitement 2) garder la partie fixe (on change rarement le fichier lors de la mise au point d'un pipeline) à gauche (chez moi lorsque je reprends la dernière commande, mon curseur se trouve en fin de ligne).

Mwouais j'ai du mal avec cet argument populiste ;-) Je pense que c'est parce qu'il permet de pointer en dehors du filesystem qu'il est utilisé.

Par contre c’est plus puissant, évidemment :)

N'empêche que ça n'est pas parfait:
- on n'a pas moyen de retrouver les liens qui pointent vers un fichier sans faire de recherche exhaustive
- un lien symbolique peut être invalide et n'empêche pas la suppression d'un fichier pointé.
- un lien dur n'est jamais invalide mais ne peut pas sortir d'un filesystem
- modèle de permission pas flexible.

Pour ce qui est de ton te exemple il marche tout aussi bien avec des lien durs. D'ailleurs c'est généralement la solution retenue pour ce cas de figure, je ne comprends pas pourquoi xz ne le fait pas. Le lien dur a l'avantage que l'on voit directement le nombre de lien et d'empêcher la suppression du fichier tant qu'il reste un lien existant.

En "pratique" on peut aller raisonnablement jusqu'à une trame ethernet complète sans gros souci. Voir plus (4k) mais alors on conseil de faire une détection. Cf. RFC 3225 sur EDNS.

s/x > 0/x >= 0/

qu'un int, fut-il sur 64 bits

Attention, attention ! Contrairement à une croyance fort répandue, le type int sur linux/amd64 ne vaut pas 64 bits ! Merci de ne pas caster des int en pointeur et vice-versa, en vous remerciant d'avance pour les bugs évités :)

Sans répondre directement à ta question (qui demande une connaissance de l'architecture sous-jacente, x86 je suppose dans ton cas), quelques remarques:

• premature optimization is the root of all evil. Dans ton cas, et vue la complexité des différentes couches utilisées par ton application, tu peux simplement arrêter de te poser la question car tu ne verras probablement pas la différence (sauf juste par curiosité, pour la beauté du geste ou pour apprendre :p)
• mesure, mesure, mesure. toute spéculation ne vaut rien dans qu'elle n'a pas été mesurée.

Sinon pour répondre à ta question de int signed vs unsigned, j'ai comparé la sortie de gcc des deux types d'addition, il n'y a aucune différence (merci la représentation en complément à 2)… "La vérification du signe" (je me demande bien ce que tu veux dire par là ??) est faite de manière automatique avec la mise à jour du registre des flags. Btw, le C est indéfini en ce qui concerne les overflows, donc bon si tu ne testes pas dans ton code, le compilo ne va pas rajouter du code par magie pour faire quelque chose d'indéfini. Ça peut par contre avoir une incidence sur l'optimisation de certains tests que tu aurais toi-même écrits. Genre si tu fais "if (x > 0)" avec x unsigned, le compilo peut supprimer le test (désolé pour cet exemple absurde je n'en ai pas de meilleur sous la main).

En ce qui concerne la taille des données, "int" (signé ou non-signé) est sensé être la représentation la plus efficace pour le cpu cible. De plus, ce que tu vas gagner en utilisation mémoire tu risques de le perdre en faisant des accès non-alignés (bien que x86 semble moins pénalisant que d'autres archis). Aussi avec une représentation plus petite qu'un mot cpu, la différence signé vs non-signée a une incidence car le cpu doit faire une extension du bit de signe en fonction de l'instruction utilisée (je doute qu'un compilo émette facilement une addition sur 8bit). À voir donc…

Bon en y repensant et après vérif, il s'avère que la fragmentation est gérée au niveau IP, donc bon ça "pourrait" marcher d'avoir des gros paquets en UDP, mais c'est vivement non recommandé car il faut que le destinataire et/ou les routeurs ou nats intermédiaires fassent la reconstruction. Ça augment aussi fortement la probabilité de perdre un paquet.

En UDP, le protocole applicatif doit gérer la retransmission lui même (ou pas, si ça n'est pas utile). Un exemple de protocole serait "OCTET 24 VAUT 251" dans un sens, dans l'autre "JE N'AI PAS RECU L'OCTET 31, PRIERE DE LE REENVOYER".

Note pour plus de clarté: chaque chaine serait un datagramme indépendant, écrit séparément par un appel à sendmsg. Et reçue séparément par chaque recv.

BTW ce sont des questions très pertinentes !

-Est ce que tout les octects du fichiers seront à peu près en ordre ?

TCP: pas à peu près mais complètement. Car chaque paquet est numéroté en séquence. Donc le receveur est en mesure de savoir ce qu'il lui manque, et il peut induire la retransmission de certains paquets qu'il n'aurait pas reçu. Ce qui est retourné par l'appel recv()/read() est garanti d'être dans l'ordre. Mais le receveur n'a aucun moyen de savoir si le receveur ne va pas encore envoyer des données. Si je te téléphone, ben je te dirais "au revoir" avant de raccrocher, tu sauras alors que je n'aurai plus rien à te dire. Par contre si je raccroche sans rien dire, tu ne saura pas si la communication a été coupée ou si j'ai effectivement raccroché. (note que TCP a théoriquement moyen de détecter la "fermeture" d'une connection, mais ça n'est pas très fiable car un firewall pourrait simuler la fermeture de la connexion, ton application n'y verrait que du feu).
UDP: non

-Est ce qu'on aura une moitié de fichier à destination ou rien du tout ?

On aura ce qu'on aura reçu jusque là, modulo ce qui n'a pas encore pu être réassemblé (genre si on reçoit les paquets TCP 1 - 2 - 4 - 5, ben l'OS ne pourra au maximum ne retourner que 1 - 2 à l'application).

-Tu parles du streaming mais ce n'est pas plutot UDP qui est utilisé pour ca ?

Non, TCP == connecté (ou stateful) == on travaille avec un stream, une connection. Il est "découpé en paquet" de manière arbitraire par la stack tcp/ip et/ou les routeurs intermédiaires. On a la garantie que ce qui est read()/recv() le sera dans le même ordre que ce qui a été write()/send() de l'autre, mais on n'a pas de garantie quant à la taille des paquets tant en écriture qu'en lecture. La pile TCP a le droit de fusionner plusieur write en un seul paquet ou inversément de diviser un write en plusieurs paquets du côté émission. Similairement du côté réception, un paquet pourrait être réparti sur deux appels à read, ou encore plusieurs paquets pourraient être fusionnés. Cela permet d'augmenter les performance: par exemple en fusionnant des write() successifs de petite taille dans un seul paquet ou inversément d'attendre un certain temps après la réception d'un paquet pour voir s'il y en a un juste derrière dont les données pourraient être retournées lors du même appel à read()/recv().

UDP == non-connecté (ou stateless) == l'unité de transfert est le datagramme. Dans ce cas, il me semble que la taille du buffer passé à recv/recvfrom doit être supérieure à la taille du plus gros datagramme recevable. En tout cas ce qui est certain c'est que l'os ne "réassemble" pas plusieurs datagrammes tel qu'il le ferait en TCP; car cela impliquerait l'utilisation d'un numéro de séquence attaché aux paquets afin d'éviter des le mélanger et rendrait de facto le protocole "stateful"… Cela veut dire qu'en pratique il faudra que le datagramme soit inférieur au plus petit MTU de la route utilisé (parce que sinon il va se retrouvé découpé en morceaux par le routeur et donc le récepteur n'aura plus aucun moyen de réassembler les fragments dans l'ordre, le paquet sera perdu).

Comme Alumnium95 le mentionne, il y a des séparations entre les couches physiques, de protocoles (IP/TCP, IP/UDP) et applicatives (HTTP, DNS, etc.) Mon commentaire initial porte à confusion, je parlait de protocole dans la couche applicative évidemment. Pour éviter le cas de figure du routeur qui prend feu justement. Un protocole applicatif serait, p.e., d'écrire la chaine "ATTENTION J'ENVOIS UN FICHIER DE 42 OCTECTS" suivit du fichier en question, le récepteurs est donc au courant qu'il devra compter 42 octets à compter de la fin de cette chaîne reçue… En UDP, le protocole applicatif doit gérer la retransmission lui même (ou pas, si ça n'est pas utile). Un exemple de protocole serait "OCTET 24 VAUT 251" dans un sens, dans l'autre "JE N'AI PAS RECU L'OCTET 31, PRIERE DE LE REENVOYER". La confusion avec stream vient du fait qu'en générale, on n'utilise udp lorsque l'on n'a pas besoin de retransmission, par exemple lorsqu'on stream un flux audio en direct, ben si on a perdu une trame audio alors tant pis, ça n'aurait aucun sens de vouloir la diffuser plus tard (ça serait inaudible).

Par définition, un arrêt de travail pour cause de maladie n'est pas un choix (et coûte cher à l'employeur). L'employeur est aussi légalement tenu de protéger ses employés, par exemple en prenant les mesures de sécurité nécessaires par rapport à un risque connu ou prévisible. Bref, cela n'a pas l'air d'un traitement de faveur, simplement le minimum légal (en plus d'être un bon calcul pour l'employeur).

Très juste. D'ailleurs en lisant ce thread je me dis que quelques uns devraient penser à faire une imprimante open-hardware en mode fair-phone :-)

On a l'air d'avoir une expérience similaire : linux fonctionne très bien pour le desktop (ma mère l'utilise exclusivement sur son ordi depuis au minimum 2004). Ce que j'aurais du écrire c'est "que dire que linux n'est pas prêt pour le desktop équivaut à dire que linux n'est pas parfait". Par rapport à la concurrence, il fait aussi bien, voire mieux. Et en plus, il est libre ;-)

stait à Gnome ou KDE ou LXDE ou Enligthenment de conquérir ce qu'il fallait

Bah… Ça serait wmaker que ça serait encore utilisable… Des gens s'y sont bien fait (ou pas) à windows 8. Ici, l'histoire du log qui fout le système en l'air, bah ça détruit l'expérience utilisateur, au même titre qu'un driver buggé, du hardware de mauvaise qualité, etc. Je suis pas sûr que gnome, mozilla, Red Hat, Lennart, ou une quelconque organisation ou individu puisse y faire quelque chose pour conquérir ce qu'il fallait… Les bugs seront corrigés parce que 1) il y a quelqu'un qui a l'intérêt, la volonté et les compétences de le faire 2) le logiciel est libre. Plus loin commence l'utopie ;-)

Tu dois lire sur la socket tant qu'elle est valide: tu pourrais très bien lire une chaîne vide, ça n'est pas pour autant qu'il n'y aura pas des données disponibles lors d'une prochaine lecture. Orthogonalement à ce problème, tu as aussi intérêt aussi à t'assurer que toutes les données ont été transférées, c.-à-d. en utilisant un protocole.

J'ai écouté attentivement un des talks de Lennart, simplement pour me tenir au fait des prochaines révolutions qui attendent le gentil utilisateur que je suis[1]. J'ai appris que son objectif actuel était d'implémenter des uid/gid dynamiques. Si j'ai bien compris, l'idée serait d'ajouter une couche de traduction (utilisant la technologie des namespaces) entre l'application et le filesystem. Celle-ci serait aussi responsable de maintenir une base de donnée contenant ces associations dynamiques. J'avoue avoir du mal à évaluer l'intérêt d'une telle fonctionnalité[2], il y a-t-il quelqu'un pour m'éclairer ?

1: Globalement je suis satisfait, j'ai le sentiment d'avoir un peu de répit avant de devoir me réadapter au sens Darwinien.
2: Je peux bien m'imaginer la complexité que ça va engendrer au niveau administration… enfin… quel est le prix de la survie ?

Un autre point sensible, amha, c'est justement le langage Nix. Il me semble que, tôt ou tard, le besoin se fait sentir d'ajouter de la modularité et de l'abstraction. Du coup, le risque de se retrouver avec une "surcouche" au dessus de Nix me semble important. De ce point de vue, Guix me semble bien mieux placé. Guix est Nix avec la partie déclarative remplacée par un moteur scheme (guile). Notez que je n'ai jamais utilisé Nix (guix bien) donc mon analyse est forcément erronée ;-)