en local, aucun intérêt, rsync n'utilisera pas son algo delta,
cet algo qui permet de transmettre uniquement les différences d'un fichier n'a d'intérêt que lors d'un transfert entre 2 processus RSYNC qui disposent chacun d'un cpu distinct et à travers un réseau dont la bande passante est (très) inférieure aux débits des disques
en local, il y a 1 seul rsync qui tourne, le fichier source va être lu intégralement, et le fichier destination va être aussi créé en totalité,
pas la peine de calculer les différences sur un fichier, c'est du travail superflu
désolé si pas très clair, au boulot, pas trop le temps de développer, mais tu trouveras pleins de tuto et d'explication sur le principe de fonctionnement de RSYNC, faut juste réaliser qu'il y a 2 utilisations (1 RSYNC isolé, ou 2 RSYNC qui causent entre eux)
tu as bien un daemon rsync (serveur) qui tourne sur la machine cible capable de répondre à ta commande rsync locale (client) ?
parce que j'ai l'impression que tu ne fais que de la copie entre un répertoire local et un répertoire distant au moyen d'un accès ssh, et dans ce cas, tu auras les mêmes échanges qu'avec un rsync purement local
des fichiers de bdd ça bouge beaucoup (un changement de structure, une optimisation, et le fichier est presque entièrement différent)
tu as analysé les différences de fichiers entre 2 rsync (commande cmp par exemple) ?
petite expérience :
prend un de tes gros fichiers, fais un rsync,
puis concatène avec un fichier plus petit,
refait un rsync et observe
si tout le fichier est retransféré il y a effectivement un pb, ou un bug, ou option de rsync pas adaptée (tu n'es pas le premier à constater ce comportement, mais je n'ai encore lu de diagnostic du pb, ni de solution…)
à ma connaissance,RSYNC ne transfère que les blocs de fichier qui diffèrent entre le master et le slave
le slave demande un bloc au master, chacun calcule une somme de contrôle de son côté, si les sommes sont différentes ---> transfert du bloc de fichier, et on passe au bloc suivant
mais il ne faut pas s'amuser à compresser ou chiffrer ses fichiers avant le RSYNC, sinon il y a de bonne chances que tous les blocs soient différents (comme dis plus haut, une option de gzip permet de palier ce problème, merci pour l'info :-)
tu dis que tu ne fais que des insert dans ta bdd et tu en déduis que ton dump au format binaire ne diffère que vers la fin, est-ce que tu as vérifié (peut-être que le dump est compressé par défaut) ???
certains bios ont la fonctionnalité, mais elle n'apparaît pas dans le setup !
ceux qui ont l'option dans le setup et qui l'ont désactivé ne sont pas à l'abri de la voir réactivée par voie logicielle (suite à un téléchargement malencontreux par exemple, ou une màj de "sécurité") !
l'article dit que la société qui gère ce composant n'a la trace que d'une petite partie de ces activations, ce qui laisse penser que la fonctionnalité est utilisée par d'autres entités (pirates ou NSA…)
d'après la définition, crypté = caché/secret
le chiffrement est une méthode de cryptage, mais pas la seule (on peut aussi utiliser un coffre fort physique ;-)
dit autrement
tout ce qui est chiffré est crypté, mais tout ce qui est crypté n'est pas forcément chiffré
Strangest of all was the ability of infected machines to transmit small amounts of network data with other infected machines even when their power cords and Ethernet cables were unplugged and their Wi-Fi and Bluetooth cards were removed.
il faut vite faire la rétro-ingénierie du truc, l'appliquer au reste des logiciels et on pourra ensuite arrêter toutes les centrales nucléaires, cool
je crois que c'est déjà le cas actuellement,
mais si j'ai bien compris, cisco a toute une gamme de produit utilisant le H264 et on peut imaginer que ça leur simplifierait la vie que le navigateur qui a une part de marché non négligeable puisse tout de même communiquer avec leurs produits sans avoir à demander à l'utilisateur d'installer manuellement un codec (pas toujours autorisé par les admins en entreprise)
donc Firefox pourrait (en théorie) :
- récupérer le binaire
- comparer avec un binaire compilé en interne (serveurs de mozilla)
- si identiques, charger et exécuter, sinon avertissement ?
je suppose que télécharger le binaire permet à cisco de tenir une comptabilité des licences à payer aux escrocs consortium MPEG-LA
la ligue des cambrioleurs modernes te dit merci :-)
sérieusement, je ne suis pas allé voir ton projet en détail et mon commentaire n'est pas très constructif,
mais j'espère que la sécurité a été prise en compte dès le départ…
ou bien que les utilisateurs ont été sensibilisés aux risques de piratage (informatique) et n'emploient que des pseudonymes (séparés de leurs comptes fesse bouc) qui ne permettraient pas de remonter à l'adresse des domiciles de tes compagnons de randonnée
mais bonne idée tout de même, ça méritait d'être fait
je pensais plutôt aux fabriquant de PC, on n'arrête pas de dire que ce marché est moribond…
(en même temps on nous prédit la fin des mails depuis pas mal de temps aussi)
oui, je n'ai pas lu tous les détails, mais il semble bien que la NZ se soit alignée sur l'Europe sur ce coup :
on a l'impression que les brevets sont interdits, mais en fait ils sont autorisés (syndrome "en tant que tel")
Tout le problème des brevets logiciels en Europe vient la façon avec laquelle le système des brevets a interprété de plus en plus librement ces quatre petits mots "en tant que tel". Le bon sens n'accorderait pas beaucoup d'importance à ça. Bien entendu, il existe, avec ou sans ce paragraphe, diverses inventions techniques dans lesquelles des méthodes mathématiques ou des algorithmes peuvent jouer un rôle auxiliaire. L'insatiable système des brevets s'est pourtant raccroché désespérément à ces quatre mots comme à une lueur d'espoir. Ils ont déclaré: "Cela veut dire que nous n'avons qu'à trouver un alibi technique et nous pouvons alors breveter les logiciels en disant que nous ne brevetons pas les logiciels en tant que tels. Nous brevetons les logiciels en les dépeignant comme faisant partie intégrale d'une invention technique."
L'Office européen des brevets a étendu cette approche au-delà de ce que l'on peut imaginer. Par exemple, une barre de progression sur un écran d'ordinateur est selon eux une invention technique et pas un logiciel. Comment justifient-ils cette classification? Ils disent que la barre de progression rend l'utilisation d'une ressource ou d'un appareil technique plus efficace et un écran est après tout un appareil technique avec un nombre limité de pixels.
c'est un sujet tellement technique (légalement parlant) qu'il faut vraiment être un avocat dans cette partie très spécialisée du droit sur la "propriété intellectuelle" pour y comprendre quelque chose
et les médias généralistes (et mêmes informatiques) ont répandu cette vrai/fausse bonne nouvelle sans hésitation
ton principal souci c'est de faire évoluer la bdd (sans perdre les données) lorsque ton programme monte en version
ça signifie :
1- il faut être capable d'identifier de façon certaine la version de bdd qui est en cours d'utilisation (table version, ou md5 du schéma)
2- être capable d'appliquer toutes les modifications entre cette version et la version qui est en cours d'installation
et le pire, c'est que si un utilisateur a sauté 1 ou plusieurs versions, tu dois être capable d'appliquer plusieurs patches sur le schéma de la bdd
le point 2 va te contraindre à garder la trace (dans ton svn ou ailleurs) de toutes les versions de bdd des paquets que tu auras mis à disposition
voilà comment je procéderai :
à chaque nouvelle version stable de bdd (correspondant à une version de mon paquet d'installation) je générerai un script de migration (en m'aidant d'outils comme MySQL Workbench, mysqldiff, etc)
avec chaque paquet, je livrerai tous les scripts de màj depuis la première version de bdd,
à chaque installation j'appliquerai tous ces scripts dans l'ordre
une autre façon de faire serait :
faire un export des données
supprimer la bdd
recréer la bdd dans la dernière version connue
ré-importer les données
au lieu d'avoir à gérer des scripts de màj de bdd, il faut gérer des versions différentes de format d'export/import
c'est peut-être plus simple, je ne sais pas..
après réflexion, la génération automatique de scripts de migration est sans doute LA mauvaise idée (risque de perte de données en cas de changements complexes/mutliples)
avoir un outil qui montre les différences est très utile, mais ensuite il vaut mieux générer (ou ajuster) le script manuellement
j'ai le même pb, j'avais déjà pensé à un gestionnaire de version pour stocker les schémas,
mais les fichiers update1.1To1.2.sql, tu les génères à la mano ?
une petite recherche montre qu'il existe des outils (commerciaux et libres) pour générer ces scripts pour les différents SGBD (SQL Server, MySQL, PostgreSQL)
Les technologies sous-jacentes qui étaient jusqu'alors réservées aux marchés AIX / AS400, sont désormais accessibles à d'autres, au prix d'une licence d'exploitation.
[^] # Re: gzip
Posté par pralines . En réponse au message Rsync : sauvegarde incrémentale de gros fichiers. Évalué à 1. Dernière modification le 21 novembre 2014 à 10:30.
en local, aucun intérêt, rsync n'utilisera pas son algo delta,
cet algo qui permet de transmettre uniquement les différences d'un fichier n'a d'intérêt que lors d'un transfert entre 2 processus RSYNC qui disposent chacun d'un cpu distinct et à travers un réseau dont la bande passante est (très) inférieure aux débits des disques
en local, il y a 1 seul rsync qui tourne, le fichier source va être lu intégralement, et le fichier destination va être aussi créé en totalité,
pas la peine de calculer les différences sur un fichier, c'est du travail superflu
désolé si pas très clair, au boulot, pas trop le temps de développer, mais tu trouveras pleins de tuto et d'explication sur le principe de fonctionnement de RSYNC, faut juste réaliser qu'il y a 2 utilisations (1 RSYNC isolé, ou 2 RSYNC qui causent entre eux)
Envoyé depuis mon Archlinux
[^] # Re: gzip
Posté par pralines . En réponse au message Rsync : sauvegarde incrémentale de gros fichiers. Évalué à 1.
tu as bien un daemon rsync (serveur) qui tourne sur la machine cible capable de répondre à ta commande rsync locale (client) ?
parce que j'ai l'impression que tu ne fais que de la copie entre un répertoire local et un répertoire distant au moyen d'un accès ssh, et dans ce cas, tu auras les mêmes échanges qu'avec un rsync purement local
Envoyé depuis mon Archlinux
[^] # Re: gzip
Posté par pralines . En réponse au message Rsync : sauvegarde incrémentale de gros fichiers. Évalué à 2. Dernière modification le 20 novembre 2014 à 19:00.
des fichiers de bdd ça bouge beaucoup (un changement de structure, une optimisation, et le fichier est presque entièrement différent)
tu as analysé les différences de fichiers entre 2 rsync (commande cmp par exemple) ?
petite expérience :
prend un de tes gros fichiers, fais un rsync,
puis concatène avec un fichier plus petit,
refait un rsync et observe
si tout le fichier est retransféré il y a effectivement un pb, ou un bug, ou option de rsync pas adaptée (tu n'es pas le premier à constater ce comportement, mais je n'ai encore lu de diagnostic du pb, ni de solution…)
Envoyé depuis mon Archlinux
[^] # Re: gzip
Posté par pralines . En réponse au message Rsync : sauvegarde incrémentale de gros fichiers. Évalué à 5.
à ma connaissance,RSYNC ne transfère que les blocs de fichier qui diffèrent entre le master et le slave
le slave demande un bloc au master, chacun calcule une somme de contrôle de son côté, si les sommes sont différentes ---> transfert du bloc de fichier, et on passe au bloc suivant
mais il ne faut pas s'amuser à compresser ou chiffrer ses fichiers avant le RSYNC, sinon il y a de bonne chances que tous les blocs soient différents (comme dis plus haut, une option de gzip permet de palier ce problème, merci pour l'info :-)
tu dis que tu ne fais que des insert dans ta bdd et tu en déduis que ton dump au format binaire ne diffère que vers la fin, est-ce que tu as vérifié (peut-être que le dump est compressé par défaut) ???
Envoyé depuis mon Archlinux
[^] # Re: Autre lien pour suivi en direct
Posté par pralines . En réponse au journal Pose toi Philae ! . Évalué à 3.
sympa le xkcd live
mais il y a un truc que j'ai pas compris : U.S. Scientists
c'est une mission européenne non ?
ça ne devrait pas plutôt être : E.U. Scientists
je suppose que j'ai manqué quelque chose, mais quoi ?
Envoyé depuis mon Archlinux
# systemd / timers
Posté par pralines . En réponse au message Lancer un service systemd par période avec cron. Évalué à 6. Dernière modification le 14 octobre 2014 à 20:10.
tant qu'à faire du systemd, autant y aller à fond ;-)
https://wiki.archlinux.org/index.php/Systemd/Timers
edit : damned, grillé
Envoyé depuis mon Archlinux
# Linux Command To Find SATA Link Speed
Posté par pralines . En réponse au message connaître la norme sata de mon portable. Évalué à 6. Dernière modification le 23 septembre 2014 à 23:58.
salut,
c'est plutôt dans les sorties de dmesg ou de smart que tu trouveras les vitesses de tes contrôleurs sata, cf cette page :
Linux Command To Find SATA Link Speed
dmesg | grep -i ahci | grep -i --color Gbps
[ 1.937844] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[ 1.939901] ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
Envoyé depuis mon Archlinux
[^] # Re: ROM de base ?
Posté par pralines . En réponse au journal Retour d'expérience ordiphone Moto G 4G et installation d'apk. Évalué à 2.
très imagé, mais pas très précis :-)
juste histoire de déterminer ton niveau d'intégrisme, peux tu nous indiquer le modèle de smartphone sur lequel tu fais tourner replicant STP ?
Envoyé depuis mon Archlinux
[^] # désactivable ?
Posté par pralines . En réponse au journal Computrace, une backdoor pour votre plus grand bien. Évalué à 6.
oui, c'est désactivable, parfois…
certains bios ont la fonctionnalité, mais elle n'apparaît pas dans le setup !
ceux qui ont l'option dans le setup et qui l'ont désactivé ne sont pas à l'abri de la voir réactivée par voie logicielle (suite à un téléchargement malencontreux par exemple, ou une màj de "sécurité") !
l'article dit que la société qui gère ce composant n'a la trace que d'une petite partie de ces activations, ce qui laisse penser que la fonctionnalité est utilisée par d'autres entités (pirates ou NSA…)
Envoyé depuis mon Archlinux
# manque de doc (euphémisme)
Posté par pralines . En réponse au message Logiciels Libres et Collectivités : gestion des convocations. Évalué à 1. Dernière modification le 30 avril 2014 à 16:44.
trouvé un :
COPY users (id, firstname, lastname, username, password, last_login, group_id, userconf_id, created, modified, active, last_logout, last_import, mail, pwdmodified, rev, rev_date, seance_sync_date) FROM stdin;
e64e47b6-9027-4d73-a49b-70fd2ee0475e Administrateur Administrateur Administrateur mot de pass non valide \N 26b380d8-93b2-41e9-9f68-da98c55ccb30 5e213ed2-09e2-4638-a2a4-67b22829657f 2013-11-07 15:54:40.942895 2013-11-07 15:54:40.942895 t \N \N \N f \N \N \N
.
dans :
101_idelibre_coll.sql
donc
username = Administrateur
password = Administrateur (à modifier à la première connexion ?)
je n'ai pas trouvé de doc ou de readme pour faire l'install……..
je suppose qu'il faut exécuter les instructions sql des fichiers 000 à 101 (ou 200 ?)
Envoyé depuis mon Archlinux
[^] # Re: Erreurs 404
Posté par pralines . En réponse au journal Nouvelle boutique en ligne Linux. Évalué à 2.
d'après la définition, crypté = caché/secret
le chiffrement est une méthode de cryptage, mais pas la seule (on peut aussi utiliser un coffre fort physique ;-)
dit autrement
tout ce qui est chiffré est crypté, mais tout ce qui est crypté n'est pas forcément chiffré
bon vendredi :-)
Envoyé depuis mon Archlinux
[^] # Re: POC super green
Posté par pralines . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 2. Dernière modification le 04 novembre 2013 à 21:37.
ah mince, je me suis quasiment arrêté de lire après cette étonnante affirmation digne d'un premier avril,
faut dire qu'à aucun moment il ne parle de portable et que les batteries sont mentionnées vers la fin de l'article
merci de m'avoir corrigé
Envoyé depuis mon Archlinux
# POC super green
Posté par pralines . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 4. Dernière modification le 04 novembre 2013 à 20:26.
http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/
Strangest of all was the ability of infected machines to transmit small amounts of network data with other infected machines even when their power cords and Ethernet cables were unplugged and their Wi-Fi and Bluetooth cards were removed.
il faut vite faire la rétro-ingénierie du truc, l'appliquer au reste des logiciels et on pourra ensuite arrêter toutes les centrales nucléaires, cool
Envoyé depuis mon Archlinux
[^] # Re: kot kot codec?
Posté par pralines . En réponse au journal Cisco paie le h264 en faveur de Mozilla. Évalué à 2. Dernière modification le 02 novembre 2013 à 19:26.
je crois que c'est déjà le cas actuellement,
mais si j'ai bien compris, cisco a toute une gamme de produit utilisant le H264 et on peut imaginer que ça leur simplifierait la vie que le navigateur qui a une part de marché non négligeable puisse tout de même communiquer avec leurs produits sans avoir à demander à l'utilisateur d'installer manuellement un codec (pas toujours autorisé par les admins en entreprise)
Envoyé depuis mon Archlinux
[^] # Re: bigre
Posté par pralines . En réponse au journal Cisco paie le h264 en faveur de Mozilla. Évalué à 4. Dernière modification le 02 novembre 2013 à 10:15.
donc Firefox pourrait (en théorie) :
- récupérer le binaire
- comparer avec un binaire compilé en interne (serveurs de mozilla)
- si identiques, charger et exécuter, sinon avertissement ?
je suppose que télécharger le binaire permet à cisco de tenir une comptabilité des licences à payer aux
escrocsconsortium MPEG-LAEnvoyé depuis mon Archlinux
# bigre
Posté par pralines . En réponse au journal Cisco paie le h264 en faveur de Mozilla. Évalué à 10.
récupérer silencieusement un binaire de cisco !
je suis étonné que Mozilla accepte ça, c'est quoi la suite, le support des drm !
je suppose (j'espère) qu'ils ont l'assurance ou les moyens de s'assurer de l'innocuité de ces binaires !
parce que c'est bien beau la disparition du flash/silverlight, mais je vois pas l'avancée (au niveau liberté/sécurité)…
Envoyé depuis mon Archlinux
# mode parano
Posté par pralines . En réponse à la dépêche Sortie de R.A.S. v0.1. Évalué à 9.
la ligue des cambrioleurs modernes te dit merci :-)
sérieusement, je ne suis pas allé voir ton projet en détail et mon commentaire n'est pas très constructif,
mais j'espère que la sécurité a été prise en compte dès le départ…
ou bien que les utilisateurs ont été sensibilisés aux risques de piratage (informatique) et n'emploient que des pseudonymes (séparés de leurs comptes fesse bouc) qui ne permettraient pas de remonter à l'adresse des domiciles de tes compagnons de randonnée
mais bonne idée tout de même, ça méritait d'être fait
Envoyé depuis mon Archlinux
[^] # Re: Ha tout de même
Posté par pralines . En réponse au journal Dukepad: une tablette libre à monter soit même. Évalué à 0.
je pensais plutôt aux fabriquant de PC, on n'arrête pas de dire que ce marché est moribond…
(en même temps on nous prédit la fin des mails depuis pas mal de temps aussi)
Envoyé depuis mon Archlinux
[^] # Re: Ha tout de même
Posté par pralines . En réponse au journal Dukepad: une tablette libre à monter soit même. Évalué à -2.
faut pas s'attendre à un miracle, c'est annoncé par la Oracle Corporation :
http://arstechnica.com/information-technology/2013/09/innovative-monstrosity-oracle-makes-tablet-with-raspberry-pi-and-java/
et sur :
https://wiki.openjdk.java.net/display/OpenJFX/DukePad
c'est fou, un copyright Oracle et la mention GPL v2 sur la même page…
ça fait un moment qu'on voir fleurir les annonces de projet "open"-hardware, les temps sont dur pour les constructeurs…
Envoyé depuis mon Archlinux
[^] # Re: La Nouvelle-Zélande bannit les brevets sur les logiciels… ou pas
Posté par pralines . En réponse à la dépêche La Nouvelle-Zélande bannit les brevets sur les logiciels. Évalué à 6. Dernière modification le 29 août 2013 à 22:38.
oui, je n'ai pas lu tous les détails, mais il semble bien que la NZ se soit alignée sur l'Europe sur ce coup :
on a l'impression que les brevets sont interdits, mais en fait ils sont autorisés (syndrome "en tant que tel")
http://www.nosoftwarepatents.com/fr/m/politics/current.html
c'est un sujet tellement technique (légalement parlant) qu'il faut vraiment être un avocat dans cette partie très spécialisée du droit sur la "propriété intellectuelle" pour y comprendre quelque chose
et les médias généralistes (et mêmes informatiques) ont répandu cette vrai/fausse bonne nouvelle sans hésitation
Envoyé depuis mon Archlinux
[^] # Re: Pourquoi n'allez vous pas voir ce que j'ai fait pour vous en faire une idée ?
Posté par pralines . En réponse au message Méthode pour gérer les montées de version de structure de base de données. Évalué à 2.
ton principal souci c'est de faire évoluer la bdd (sans perdre les données) lorsque ton programme monte en version
ça signifie :
1- il faut être capable d'identifier de façon certaine la version de bdd qui est en cours d'utilisation (table version, ou md5 du schéma)
2- être capable d'appliquer toutes les modifications entre cette version et la version qui est en cours d'installation
et le pire, c'est que si un utilisateur a sauté 1 ou plusieurs versions, tu dois être capable d'appliquer plusieurs patches sur le schéma de la bdd
le point 2 va te contraindre à garder la trace (dans ton svn ou ailleurs) de toutes les versions de bdd des paquets que tu auras mis à disposition
voilà comment je procéderai :
une autre façon de faire serait :
au lieu d'avoir à gérer des scripts de màj de bdd, il faut gérer des versions différentes de format d'export/import
c'est peut-être plus simple, je ne sais pas..
Envoyé depuis mon Archlinux
[^] # MA mauvaise idée
Posté par pralines . En réponse au message Méthode pour gérer les montées de version de structure de base de données. Évalué à 1. Dernière modification le 29 août 2013 à 16:37.
je me répond à moi même :
après réflexion, la génération automatique de scripts de migration est sans doute LA mauvaise idée (risque de perte de données en cas de changements complexes/mutliples)
avoir un outil qui montre les différences est très utile, mais ensuite il vaut mieux générer (ou ajuster) le script manuellement
Envoyé depuis mon Archlinux
[^] # Re: Solution pour une base MySQL.. que je m'étais inventé pour un projet pas open source
Posté par pralines . En réponse au message Méthode pour gérer les montées de version de structure de base de données. Évalué à 1.
j'ai le même pb, j'avais déjà pensé à un gestionnaire de version pour stocker les schémas,
mais les fichiers update1.1To1.2.sql, tu les génères à la mano ?
une petite recherche montre qu'il existe des outils (commerciaux et libres) pour générer ces scripts pour les différents SGBD (SQL Server, MySQL, PostgreSQL)
les source :
http://stackoverflow.com/questions/685053/what-is-best-tool-to-compare-two-sql-server-databases-schema-and-data
http://stackoverflow.com/questions/225772/compare-two-mysql-databases
les outils qui ont retenu mon attention et que je compte tester (MySQL/PostgreSQL et libres) :
http://adamspiers.org/computing/mysqldiff/
Envoyé depuis mon Archlinux
# waarp = équivalent opensource de cft
Posté par pralines . En réponse au message automatisation de transferts de fichiers. Évalué à 5. Dernière modification le 28 août 2013 à 16:34.
https://linuxfr.org/news/waarp-le-moniteur-de-transfert-de-fichier-open-source
http://www.waarp.it/fr/
Envoyé depuis mon Archlinux
# non, ça c'est les rideaux, essaie encore Chantal !
Posté par pralines . En réponse au journal Power8 - OpenPower : l'hégémonie du x86 pourrait-elle être bousculée dans le monde serveur ?. Évalué à -6. Dernière modification le 27 août 2013 à 21:54.
Envoyé depuis mon Archlinux