benja a écrit 1211 commentaires

Après le check et la réparation éventuelle du fs, il y a une grande chance que la base de donnée de dpkg soit corrompue. Dans ce cas, il est possible de restaurer un backup depuis /var/backups/dpk.status.*, gunzipper au besoin, et remplacer avec le fichier /var/lib/dpkg/status que l'on aura préalablement sauvé au cas où. Ensuite un « apt-get update; apt-get install -f » devrait remettre le système dans un état cohérent (note: d'abord essayer de lancer ces commandes avant de restaurer un backup). Il se peut qu'il reste des fichiers orphelins (c.-à-d. des fichiers dont le paquet n'est pas marqué comme installé), refaire l'upgrade et/ou installer les paquets manquants (i.e. ceux qui ont été installés après le backup dpkg), devrait remettre la plupart des choses en ordre.

Oui c'est très certainement que cet argument semble tenir la route…

Cependant là on parle de plusieurs ordres de grandeur de différence. Faudrait pas fantasmer non plus hein, une telle différence, ça n'existe pas ;) Que je sache le pétrole a un prix mondial grosso-modo uniforme et son prix influence le prix de quasiment toutes les autres denrées. Pour rebondir sur ton exemple, tu imagines beaucoup de gens qui épargneraient un cent-millième de millilitre de pétrole par mois ??

«La vrai raison c'est une faille de l'hyperviseur accessible via le linux en OtherOS. Du coup pour éviter un piratage facilité, ils l'ont enlevé.»

Oui enfin depuis que les clefs privées ont été rendues disponibles, toute la sécurité s'est écroulée. Du coup, cet argument étant devenu un non-argument, pouquoi n'ont-ils pas restauré la fonctionnalité ? (ok, c'est une question purement réthorique)

Secondo, n'aurait été pas-t-il possible de corriger la-dite faille de l'hyperviseur au lieu de retirer la fonctionnalité OtherOS ?
(c'est encore une question purement réthorique, à moins que quelqu'un de chez sony passe par ce forum et réponde :o)

Pour mémoire, l'hypervisuer empêchait, en-autre, l'accès du Linux au GPU. Le linux devant se contraindre à un accès de type "frame-buffer"; ce qui du coup enlevait beaucoup d'intérêt pour cette machine en tant que machine de bureau ou machine de jeu Linux. Amha, c'est derrière cela qu'on aurait plus de chance de trouver la vrai raison d'un tel changement de cap…

Dans ton exemple, il devrait y avoir deux --exclude !? Peux tu lancer ta commande avec set -x activé ?

Je voulais en avoir le coeur net.
1) peu-importe le format de liste utilisé, il y a moyen d'arriver avec eval
2) on ne sait pas utiliser les backquotes sans eval; le problème c'est que le shell fait l'expansion glob après celle des backquotes. Le eval dans ce cas sert à retirer les backslashs :-/

showarg.sh (chmod +x):

#! /bin/sh

while [ -n "$1" ]
do
  echo "arg: $1"
  shift 1
done

test.sh:

mkdir -p /tmp/t/A /tmp/t/B; touch /tmp/t/A/a
liste1="--exclude \"/tmp/t/A/*\" --exclude \"/tmp/t/B*\""
liste2="--exclude '/tmp/t/A/*' --exclude '/tmp/t/B*'"
liste3="--exclude /tmp/t/A/* --exclude /tmp/t/B*"

set -x

echo  OK
eval ./showargs.sh $liste1
eval ./showargs.sh $liste2
eval ./showargs.sh `echo "$liste3" | sed 's/\*/\\\*/g' `

echo  NOK: quote dans le argv
./showargs.sh $liste1
./showargs.sh $liste2
./showargs.sh `echo $liste1`
./showargs.sh `echo $liste2`
./showargs.sh `echo "$liste1"`
./showargs.sh `echo "$liste2"`

echo  NOK: expansion glob
./showargs.sh $liste3
eval ./showargs.sh $liste3
./showargs.sh `echo $liste3`
./showargs.sh `echo "$liste3"`
./showargs.sh `eval echo $liste1`
./showargs.sh `eval echo $liste2`
./showargs.sh `eval echo $liste3`

echo NOK: backslashs
./showargs.sh `echo "$liste3" | sed 's/\*/\\\*/g' `

Et le jour on n'a pas de bash sous la main, on ne sait plus comment faire ;-)
Note: je ne pense pas qu'une façon soit meilleure qu'une autre, je cite simplement d'autres moyens d'y arriver, disons pour la culture.

Ou sinon plus simple, tu peux aussi faire:
tar ... `echo $liste`.
Je suppose que la solution du tableau fonctionne aussi même si moins portable.

Eval te permet d'avoir une expansion en 2 temps.
Le problème est que ton ${liste_exclusion} est passé à tar en temps qu'un seul argument.
Eval va forcer son expansion avant d'appeller tar. Il te faudra aussi rajouter une paire de quote autour de tes globs pour qu'ils ne soient pas substitué parl le eval…

Pour info, Qt a été revendu à Digia en aôut 2012…

http://digia.com/en/Home/Company/News/Digia-to-acquire-Qt-from-Nokia/

Pour complèter la réponse de NeoX, quand tu lance 'sh script.sh', le programme 'sh' va lire le fichier 'script.sh' et l'interprêter. Et la première ligne qui commence par '#' est ignorée car ce caractère indique le début d'un commentaire dans la syntaxe shell (c.a.d. que tu mettrais à la place '#! /outsiplou' cela marcherait encore).
Lorsque tu lance '/path/to/script.sh', le noyaux linux va lire ce shebang pour déterminer le nom de l'interprèteur et il va ensuite le lancer avec comme premier paramètre le nom du script.

Bref, cela fonctionnerait aussi partout si tu lançais 'bash test.sh'.

PS: la ligne 'bash --version' de ton script ne teste pas l'interprèteur qui est utilisée, mais lance une nouvelle commande bash. Sous linux, il est possible de tester /proc/$$/exe qui pointe vers le binaire du shell courant, i.e. utiliser '/proc/$$/exe --version' à la place te donnerait un résultat plus pertinant… (+1 à celui qui donne une manière portable de tester le shell courant :))

PS2: les bonnes pratiques conseillent d'utiliser la version du shebang avec espace ('#! /path/') bien que les 2 fonctionnent…

Certains gestionnaires de fichiers créent un répertoire caché qui sert de corbeille. De mémoire, ce répertoire s'appelle .trash, situé à la racine du média amovible (note: quand le nom d'un fichier/répertoire commence par un point, celui-ci est "caché", ls -a ou l'option "afficher les fichiers cachés" de ton gestionnaire de fichier te permettent de les voir).

Si la solution précédant ne fonctionne pas, une autre solution pourrait être de supprimer ce répertoire et de créer un fichier portant le même nom à sa place. Il sera dès lors impossible pour le gestionnaire de fichier d'y déplacer un fichier. Reste la question de savoir comment le gestionnaire de ficher réagirait précisément à cette situation… Bref, à tester ;-)

qwertu

la configuration SPF voulue par steamchouette

Vous prennez le problème dans le mauvais sens, je penses : c'est bien le destinataire (i.e. free ou gandi dans ce cas) qui peut se prémunir, totalement (du moins c'est l'objectif tel qu'il est considéré, en admettant que tous les serveurs émetteurs disposent d'enregistrements SPF), d'un email impersonnifié, en utilisant SPF. C.-à-d. c'est le récepteur qui met en oeuvre, de manière à faire force, le contrôle SPF. Là preuve est qu'un serveur émetteurs disposant d'informations SPF souhaite toujours pouvoir envoyer un message à un serveur même si ce récepteur n'est pas capable de vérifier SPF; et ceci pour les simples et bonnes raisons qu'il n'est pas possible de savoir, à priori, si un serveur récepteur (voir une passerelle, gandi en l'occurence) implémente SPF et que SPF ne peut se déployer que d'une manière graduelle, c.-à-d. que SPF ne doit être mis en oeuvre que si les 2 parties, soit émetteur/récepteur ou émetteur/passerelle, le mettent en oeuvre (la justification de cette dernière raison tombe sous le sens).
De ce point de vue là, il est souhaitable que free implémente une whitelist. Aussi que gandi vérifie à sa place les enregistrements SPF (pour ne pas perdre de fonctionnalité).

PS: merci de ne pas me tenir rigueur pour les erreurs, imprécisions et termes trop approximatifs; vous corrigerez volontier.

Tu peux aussi aller voir du côté des routeurs type WRT (http://wiki.openwrt.org/toh/start). Un vieux linksys se trouve facilement voir se jette, mais bon ce n'est plus très performant au standard actuels.

Comparer SDL et OpenGL, n'est-ce pas un peu comme comparer des pommes à des poires ?

Ok /me doit apprendre à lire plus loin que le titre :)

Bon quand tu fais X : SIG, ben SIG c'est SIG. donc SIG.a != un type inféré, c'est SIG.a point. Ensuite (X:SIG with type t = Y.t) ben c'est une autre signature.

module A2 : (Ai with type b  = Int_set.elt) = A(Int_set);;

let pas_bien = A2.f 1;;
val pas_bien : A2.a = <abstr>

C'est plus sympa que d'espèrer que le compilateur va briser l'abstraction de type, ce qui rendrait le language un peu caduque. I.e. vouloir faire en sorte que Ai.b = int c'est mal comprendre l'intérêt de ce système de typage, mais bon cela viendra avec la pratique, courage ! ;-)

http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual018.html

Bah pour une utilisation basique, y a pas vraiment besoin de man ni d'une grosse mémoire, une ligne de commentaire suffit dans le fichier cron. Bon après certains cron ont des fonctions spécifique (onboot, etc.) ça peut être intéressant de regarder la référence, mais bon…
# m h dom mon dow command
minute hour day_of_month month day_of_week sh -c "echo ai-je une bonne mémoire ?"


De rien ;-)

Non ce n'est pas un bug, les typedefs désignent bien deux choses différentes lorsque l'architecture n'est pas 64bits : un unsigned long long pour poker et une structure de deux membres pour OCaml. Il n'y a aucun espoir de pouvoir faire passer l'un pour l'autre et, justement, le compilateur l'interdit.

Ce qui pourrait peut-être marcher c'est renommer une variante avec une macro du préprocesseur avant d'inclure un des entêtes (sans oublier de le désactiver juste après pour ne pas impacter les autres inclusions!) et ensuite utiliser le nouveau nom dans ton code. Par exemple en renommant l'alias d'OCaml :

#define uint64 ocamluint64
#define int64 ocamlint64
#define uint32 ocamluint32
#define int32 ocamlint32
#include <caml/config.h>
#include <caml/autreentête OCaml>
#undef uint64
#undef int64
#undef uint32
#undef int32

#include <poker_defs.h>

void ma_fonction_utilisant_le_type_ocaml(ocamluint64);

Sans résultat garanti ;-)

Ben on n'arrive déjà pas à faire tourner correctement Xorg avec un 2Ghz…

À ce prix là, est-ce que 2000 personnes bénévoles ne seraient pas plus efficaces que 4 ?

Pour les (futurs) fans du lisp, il y a clojure qui est sympa aussi. Comme scala, il y a des mécanismes pour gèrer simplement la concurrence et cela tourne sur la JVM.

PS: dans le cas ou /boot est sur la même partition que /, les paths sont absoluts par rapport à root, p.e. /boot/memdisk et /path/to/iso.

Ok super, ravi de savoir que tu as trouvé une solution :)