Nicolas Boulay a écrit 16010 commentaires

J'ai le même problème mais avec un NAS en utilisant Samba, que je partage avec un windows. J'imagine que les ACL ne fonctionnent pas sous windows ?

"La première sécurité est la liberté"

Les ACL n'ont pas besoin d'être explicitement géré par les applications ?

"La première sécurité est la liberté"

Je pense que tu es bien incapable de savoir ou tirer des photos dont la durée de vie dépasse 10 ans, surtout à la lumière. Il suffit de voir la tronche de tirage papier à jet d'encre.

Ensuite, les photos papier, cela prend une place énorme, cela brule, cela s'abime,...

"La première sécurité est la liberté"

Je ne crois pas que les clef usb soient faite pour le stockage à long terme. Il suffit de voir les différences avec les SSD.

"La première sécurité est la liberté"

Je veux dire par là que c'est évident qu'un disque en ligne meure : il est inaccessible, il gratte, etc... Il va pas moisir pendant 1 ans ou 2 avec que tu t'en rendes compte. Le problème est que pendant cette année, la deuxième copie meure elle aussi en silence.

"La première sécurité est la liberté"

Le problème est le même que les CD/DVD c'est que les données peuvent mourir silencieusement. Il faut scanner en continue avant de tout perdre.

Un disque te prévient quand il meurt.

"La première sécurité est la liberté"

En plus, il a du avoir la honte de sa vie.

"La première sécurité est la liberté"

Il ne faut pas exagérer.

Je dois être à 64 Go de données pour mes photos. Au début, cela faisait un DVD, puis 2 puis 4. Même en doublant tous les ans (ce qui ne sera pas vrai très longtemps), il y a de quoi tenir encore un an. Il suffit de changer de modèle pour utiliser les nouveaux avec 250 Go de disque, et ainsi de suite.

Pour info, un DVD est infiniment moins fiable qu'un CD. Une partie de la gestion d'erreur est faite par le comportement de la décompression vidéo. Le reed solomon du CD permet de gérer une belle rayure de 1 mm de large.

"La première sécurité est la liberté"

Un kimsufi à 30€/mois et son 160 Go de HD :
+ pas si chère que ça
+ évite d'avoir tout au même endroit (contre le feu, le vol, les inondations, l'orage,...)
+ WAF compliant
- upload vraiment limitant
- gestion d'un serveur toujours en ligne (mettre à jour la sécurité, ne pas faire de boulette de config,...)

Un NAS type synology en raid 1et gigabyte (400€):
+ ultra rapide (~30Mo/s)
+ assez simple (enfin je cherche toujours le moyen de partager le répertoire en utilisant samba sans avoir le problème de gestion des utilisateurs sur un linux et un windows)
+ facilement upgradable
- un peu chère
- c'est local
- cela bouffe de la place et du courant

Le must serait un NAS distant pour éviter de se taper la gestion de sécurité d'un serveur dédié. Mais je ne crois pas que cela existe.

"La première sécurité est la liberté"

Tu veux dire que la pile est alloué par loader selon des directives d'un shell ? Comme créer un process en C avec une taille de pile spécifié ?

Sous Linux, la taille de la pile est fixé habituellement par le shell. Sous windows, c'est fixe dans le binaire (16 Mo, il me semble). Mais comment faire l'opération de fixer une taille de pile sous Linux depuis un autre binaire (qui n'est pas un shell donc).

Je note l'histoire de la stack alternaltive.

"La première sécurité est la liberté"

"déférencer" cela ressemble beaucoup au free() ou au delete(), non ?

"La première sécurité est la liberté"

J'adore aussi l'allocation dans la pile. C'est ultra rapide et déalloué automatiquement à la fin du contexte.

Par contre, comment tu gères une pile trop petite ? J'ai l'impression que tu te prends un "segfault" impossible à récupérer. Je me demande aussi si il existe un moyen simple de fixer la taille d'une pile autrement que par un appel à "clone()". D'ailleurs l'allocation de la pile est un mystère. J'ai l'impression que c'est fait à la demande sur une zone de taille fixe. Donc, c'est soit l'équivalent d'un mmap() de taille fixe, soit l'utilisation d'un mmap avec l'option GROWDOWN.

"La première sécurité est la liberté"

Qu'on peut faire du GC en temps réel soft et collaborer avec le GC pour minimiser le jitter


Je suis super déçu :

"* Essentially a “garbage collector with knobs”"
Large interrupts are avoided at the cost of small, regular, and
predictable collections

En gros, on refait un peu de truc manuel, et on passe plus souvent avec une durée limitée au lieu d'attendre le fait de manquer de mémoire... :/

Présentation d'un GC moderne, aka G1:

G1 a l'air plus sympa avec une sorte de typage de la mémoire en jouant sur la probabilité de rester en vie d'une région mémoire.

"La première sécurité est la liberté"

firefox utilisait malloc de la libc ou sont propre allocateur (qui utilisait mmap ou sbrk)?

"La première sécurité est la liberté"

Si ton entrée, c'est du C...

Si la version C n'est pas correct, quel sont les cas d'utilisation ayant une bonne stabilité dans ce cas ?

"La première sécurité est la liberté"

C'est un capteur de compact, malheureusement...

"La première sécurité est la liberté"

Quelqu'un avait passé un commentaire ou il avait essayer de compiler des programmes disponibles sous une distributions Linux en utilisant LVM, les résultats n'étaient pas fameux. L'idée est sympa si LVM marche.

"La première sécurité est la liberté"

Ils visent aussi leur activité au travers des participations aux séances, aux commission des lois et au proposition de lois et amendement.

"La première sécurité est la liberté"

Je trouve qu'un site comme http://www.deputesgodillots.info est enfin du vrai travail de journaliste. Il montre qu'un certain nombre de député ne font rien du tout et ne servent à rien. Le site est polémique mais il cite des sources officiels. J'espère que tousces députés inutiles ne seront pas réélu.

"La première sécurité est la liberté"

il te manque quoi en photo numérique sous Linux ?

"La première sécurité est la liberté"

Le HT n'étant pas un franchement une gestion du multithread "hjeavy" ;)


Si. vu les comportements observé sur les consoles. Il avait été déduit que l'ordonnanceur d'instruction devait faire un coup un thread un coup l'autre. Dans le cas du x86, c'est plutot un partage des ressources dispo en fonction de la demande. La différence est que les ressources d'un x86 sont plus grande et qu'il y a donc plus de chose à partager.

Dans le cas du x86, l'execution mono thread n'est pas 50% plus lent avec un thread que 2 thread cote à cote. Le cpu est capable d'executer à "pleine vitesse" sur un thread. Sur le PPC, le pipeline semble long (ce qui se voit dans la fréquence max), d'où la grosse perte en mono thread.

"La première sécurité est la liberté"

Oh ben si pour toi un p4HT c'est la même chose que le xenon ou que le cell, on se demande qui se débat dans les sables mouvant...

Ou est-ce que j'ai dis ça ? Pour toi SMT == hyperthreading == p4 ?!

Mais il y a une limite de fréquence sur une puce (entre autre dépendant du maximum de porte qu'un signal doit traverser, etc...), et ne pas savoir ça montre juste à quel point tu es pédant sans pour autant t'être renseigné un minimum.

Il y a aussi cette condition là. Mais c'était tellement évident, je ne l'ai pas cité ;) Pour info, c'est mon métier.

Donc où est la limite que tu met pour dire qu'une architecture est proche ou pas ? Qui la fixe ? Toi ? Sur quel base ?

Sur le nombre de pipeline mis en parallèle et la gestion ou pas de l'OO pour ce qui concerne la comparaison x86/ARM.

"La première sécurité est la liberté"

Tu t'enfonces un peu beaucoup là...

Non je sais pas, si le gars qui a conçu la puce dis que c'est le cpu de la ps3, c'est qu'il n'y connais absolument rien certainement...

Je ne connais pas le bouquin, mais j'ai l'impression que tu n'y a pas compris grand chose.

Et sur quel base ? ah euh aucune...

si. Tout ce qui concerne les similitudes de comportement.

On dirais que tu viens de décrire un p4 HT à 3Ghz.

Oui et alors ? Il faut tout de même enlever le coter out of order du PPC des consoles, ce qui doit représenter et de loin la partie la plus complexe (la gestion des pipelines et de la cohérence des données, quoi...). Par contre, le HT des P4 est considéré comme bien meilleur que celui du ppc du cell ou de la xbox. Ils ont sacrifier la complexité à la vitesse.

C'est pas de ça dont tu parlais mais d'un ppc qui peut en réalité monter jusqu'a plus que 4Ghz ?

Quel rapport avec la fréquence max ? La fréquence d'un chip est savant mélange de performance de la téchnologie, du trie final, de la tension et donc de la consommation du chip voulu. Tu peux avoir des x86 à 4Ghz depuis longtemps si tu acceptes un radiateur très couteux et plus de 300W de consommation. Aucune puce numérique ne fixe sa fréquence, ta remarque n'a aucun sens.

Donc, pour toi, un arm c'est la même chose qu'un x86, vu que les instructions et les unités de calcul en face n'entre pas en ligne de compte pour savoir si un cpu est différent.

C'est pas le plus important. Par exemple les G4 et les athlons 1er du nom avait la même micro-architecture d'origine IBM. Le g4 était "balancé", l'Athlon orienté vitesse (beaucoup plus gros mais 20% plus rapide).

Dans important je veux parler de complexité à réaliser et à tester. D'un point de vue architecture, les arm9 10 11 sont proche des 486. Le cortex A8, proche d'un pentium, le cortex A9, proche d'un pentium pro/2/3...

"La première sécurité est la liberté"

Si tout se passe bien, j'aimerais d'ailleurs bien porter Lisaac sur l'architecture LLVM.

LLVM est très loin d'être utilisable donc bon...

"La première sécurité est la liberté"

Il y a des gens pour, le maintient des numéro de département ?

Enfin, je veux dire autre que des personnes qui veulent encore pouvoir faire chier les parisiens. (note pour ses gens là; les numéros de 70 à 74 ne sont pas en Ile de France)

"La première sécurité est la liberté"