Nanawel a écrit 250 commentaires

Intéressant aussi ! Ça pourrait suffire à mes besoins en effet. Je note, je note.

Intéressant, mais je n'arrive pas à déterminer s'il est possible de faire ça en plug-and-play, qu'il gère les galleries tout seul simplement en fonction des dossiers. Sinon la saisie des infos dans un fichier de config en dur sur le serveur est beaucoup trop laborieuse pour mon usage.

Merci quand même !

Peut-être un peu lourd en effet, mais sacrément complet le bestiau. J'y jetterai quand même un oeil, merci !

Ça a l'air pas mal oui ! Je le mets dans la liste "à tester" :)
Merci !

Ça explique peut-être le problème que ma mère a dans la même situation avec une clé USB sur un autoradio (il a fallu que j'explique que "non, la clé USB n'est pas rayée" ^^).

J'aurais jamais pensé que la fragmentation des fichiers pouvaient en être l'origine, à tester pour confirmer.

Oui c'est de la presse. Mais du genre pas "20 Minutes" gratuit à la sortie du métro et bardé de 50% de pub. Si si ça existe.

Snif :'(

Si ça a touché le cloud d'Amazon ça expliquerait pourquoi le serveur hébergeant les archives de phamtomjs étaient en carafe pendant plusieurs heures.

M'a pété mes builds tout ça, tsss.

Merci pour l'info, on peut considérer que "ça n'arrivera plus" alors (ha ha).

FDN bien sûr. Relayé sur mon LAN via un dnsmasq installé sur mon serveur maison (hop, un peu de pub).

En beaucoup moins "tutorialisé", j'avais fait un article quand j'avais dû numériser un lot de cassettes VHS il y a 2 ans. Si jamais tu trouves de quoi compléter ton article…

http://www.lanterne-rouge.info/2014/01/num%C3%A9risation-de-vhs-sous-linux.html

La seule chose que je comprend, c'est que les mec ils ont des ballz …

Bim, voilà où ça mène les expressions sexistes :

À l'époque, c'est le MIT qui a conçu et développé le logiciel embarqué pour cette mission d'exploration spatiale. L'équipe était alors dirigée par l'informaticienne Margaret Hamilton, une des pionnières dans son domaine.

Je l'ai utilisé pas mal en 2009 et je confirme : c'est presque du Swing en JS. Avec beaucoup de composants déjà fournis par le toolkit, mais qu'il est possible d'étendre à la manière de ce qui se fait en Java (le système d'héritage fera peut-être crisser des dents à certains experts en JS…).

Quelqu'un pourrait préciser les cas d'utilisation de cette commande et de l'utilitaire duperemove plus généralement ?
D'après ce que je vois, ça ne fonctionne que sur du BTRFS, c'est ça ?
Et ça dédoublonne… les blocs de données utilisées par les fichiers ?

Tout pareil que le monsieur du dessus, j'aime beaucoup. Bonne continuation !

Merci pour ton retour, j'ai eu accès à la bêta mais je n'ai pas encore eu le temps de m'y mettre.
Ce qui me rassure c'est que tu me confirmes que le renouvellement peut être entièrement automatisé et transparent, ce qui était justement une de mes interrogations initiales. Yapuka quoi.

Bizarre, dis comme ça ça ressemble à une erreur disque. Ta "machine qui trainait chez toi" elle a un disque dur fiable ?

Ajouté à mes flux RSS.
Par contre en plus de décider d'un nom, vous pourriez ajouter un favicon à votre site ? :)

je suis passé avec soulagement à Debian, que je n'ai pas quitté depuis, et que j'utilise actuellement en version Testing (c'est important pour la suite).

Avec une phrase pareille je m'attendais pas du tout à trouver un troll sur systemd plus loin. Pas du tout.

Je plussoie doublement. Un album aussi légendaire que l'histoire qu'il raconte, et Sir Lee n'y est pas étranger.

… je ne ferai même pas de plaisanterie liée au vocabulaire utilisé.

Bronsonisé.

Ah oui c'est déjà plus lisible.
Par contre j'ai du mal à expliquer la "marche" qui est visible pour les 2 dernières valeurs pour les Core 2/Phenom II/Q9550, surtout que ces processeurs ne sont pas de toute première jeunesse…

Ok j'arrête la bibine avant de poster. Je n'avais pas vu le "for 3s" sur chaque ligne…

Allez, si chacun sort la sienne.

$ openssl speed aes
Doing aes-128 cbc for 3s on 16 size blocks: 26522705 aes-128 cbc's in 2.98s
Doing aes-128 cbc for 3s on 64 size blocks: 7312141 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 256 size blocks: 1921893 aes-128 cbc's in 2.98s
Doing aes-128 cbc for 3s on 1024 size blocks: 486496 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 8192 size blocks: 61218 aes-128 cbc's in 2.98s
Doing aes-192 cbc for 3s on 16 size blocks: 23437851 aes-192 cbc's in 3.00s
Doing aes-192 cbc for 3s on 64 size blocks: 6334651 aes-192 cbc's in 3.00s
Doing aes-192 cbc for 3s on 256 size blocks: 1612836 aes-192 cbc's in 2.99s
Doing aes-192 cbc for 3s on 1024 size blocks: 405075 aes-192 cbc's in 3.00s
Doing aes-192 cbc for 3s on 8192 size blocks: 50885 aes-192 cbc's in 2.99s
Doing aes-256 cbc for 3s on 16 size blocks: 20354366 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 64 size blocks: 5441752 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 256 size blocks: 1384644 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 1024 size blocks: 347388 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 43499 aes-256 cbc's in 2.99s
OpenSSL 1.0.1j 15 Oct 2014
built on: Wed Oct 15 16:39:39 CEST 2014
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -Wl,-O1,--sort-common,--as-needed,-z,relro -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     142403.79k   156514.05k   165102.22k   166612.68k   168287.87k
aes-192 cbc     125001.87k   135139.22k   138088.97k   138265.60k   139414.69k
aes-256 cbc     108919.68k   116478.97k   118551.46k   118971.68k   119178.53k

$ cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 60
model name  : Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz
stepping    : 3
microcode   : 0x9
cpu MHz     : 3467.734
cache size  : 8192 KB
physical id : 0
siblings    : 8
core id     : 0
cpu cores   : 4
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt
bugs        :
bogomips    : 6986.82
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

Edit : je remarque que les temps dans la première partie du bench sont peu ou prou les mêmes entre un Atom D2500, un Phenom II, et les deux i7 qui sont pourtant des CPU très différents. Quelqu'un aurait une explication à donner ?

Oui effectivement c'est bien le même problème.
J'aimerais quand même savoir s'il est possible de consulter les options de montages utilisées par GVFS, même si j'imagine que les API clients sont pas les mêmes entre mount.cifs et GVFS.