> Skrooge vise donc une population moins au fait des principes de compta, et plus désireuse de faire une gestion "intuitive".
Je rêve d'une application lourde qui serait aussi simple à utiliser que https://www.buxfer.com/
Rapide à comprendre/utiliser, ergonomique, sort les graphiques utiles etc. bref que du bon.
Je vais essayer Skrooge. Jusque ici il manque une application pour les gens qui veulent simplement importer les relevés de leur banque, tagger les entrées et regarder comment ça évolue sans y passer plus de 10 minutes par mois....
> Est ce que si j'oublie ma clef USB contenant ma clef privée (avec pass-phrase) quelqu'un pourra se servir de cette clef?
C'est le but de la protection par chiffrement symétrique (passphrase) de la clé privé. Voler la clé sur le support de stockage ne suffit pas pour avoir une clé opérationnelle.
Après dire qu'il suffit d'avoir une passphrase pour que ce genre d'événements n'arrive pas, ca me semble un tantinet naïf...
Posté par ckyl .
En réponse au journal Yum vs Apt.
Évalué à 4.
> sur une batterie de serveurs, faire une mise à jour ou une bête installation demande plus de temps. C'est un fait, et ça peut jouer.
Ça prend 10 secondes de plus... Me dit pas que tu utilises yum itérativement à la main sur chaque machine sur une batterie de serveur.
Yum pourrait être plus rapide c'est un fait. Après est ce vraiment un problème et un critère de choix ou seulement du confort ? Note aussi que c'est bien plus rapide dans les dernières Fedora.
> S'il y avait eu une passe-phrase sur la clef ce ne serait pas arrivé.
À partir du moment ou un compte utilisateur est compromis il est très facile de récupérer la clé SSH associée, mot de passe ou non. Le mot de passe protège des vols de la clé par accès au support de stockage (partage NFS, clé USB, mauvaise permission de fichier, vol de laptop etc.) pas plus.
Au passage c'est moi ou y'a beaucoup de gens qui balance des trivialités ou du n'importe quoi avec condescendance ? Vu le niveaux des commentaires je trouve ca assez déplacé de casser du sucre sur l'équipe infrastructure d'apache qui jusqu'à preuve du contraire est très compétente... Sur ce cas précis 12 heures entre la compromission et la détection/analyse/prise de mesures/communication/restauration de service sur de la prod c'est du beau boulot. On peut voir le palmarès des donneurs de leçon ?
> Certes, les applications auto-hébergées risquent davantage que les versions centralisées de disparaître à jamais (perte d'intérêt de l'hébergeur, etc.), mais le risque est mieux réparti.
Pour le moment l'expérience prouve plutôt le contraire. Va faire un tour sur des forums autorisant les images, et regarde le nombre d'image qui ne sont plus disponibles et d'où elles viennent. C'est très compréhensible étant donné que c'est le métier du premier, et ce n'est que le "hobby" de l'autre.
Si la perte d'un flickr, d'un imageshack ou autre serait un séisme. l'avantage des gros services c'est que tu as tout de même une chance que quelqu'un tente de sauver le tout vu l'importance du bouzin. Mes images que je link vers mon site perso, le jour ou j'ai plus envie de maintenir tout est perdu...
Pour moi quand on publie du contenu, c'est comme quand on écrit un soft. On le fait pour les lecteurs (les utilisateurs). Un des buts étant qu'une ressource ne change jamais d'adresse et soit accessible pour toujours. Dans les auto hébergés qui se prend la tête à garder les URL à coup de mod_rewrite quand il migre de gallery a zen photo ?
Dans la branche dont on parle, ca ne me semble pas très courant. Dans le BTP ou la métallurgie c'est autre chose.
Et pour information c'est 35 jours de CP + 10 jours de RTT + recup. Les contrats ne sont pas aux 39h.
> Si tu n'appliques pas la loi, pourquoi tu te plains de travailler plus et reproche en même temps à un chercheur de le faire ?
Je ne reproche pas aux chercheurs de le faire. Je reproche de mélanger ce que certains décident de faire et leur contrat de travail.
Néanmoins, je suis d'accord avec leurs revendications; tant sur le boulot que sur la rémunération (personnellement j'aurais répondu "LOL" aux RH en voyant le contrat).
> Vous êtes tenus aux mêmes lois
La loi dit 35 heures, et 25 jours de CP. Tu peux même bosser 37h30 sans RTT grâce aux heures sup.
Y'a plus de boites qui ont lu la loi dans ce sens là, que dans le sens "je touche pas à ton salaire, je déclare 39h et je te donne 35 jours de CP + 25 jours de RTT"...
> comparer les montants que vous touchez à la fin du mois.
C'est pour cela que je faisais remarquer le volume de congé et la qualité de vie, en rebondissant sur le commentaire initial.
Si je voulais prendre le même volume de repos via des congés sans solde actuellement, tu peux retirer entre 300 et 400 euros sur le net par mois. C'était le sens de ma remarque initiale.
Cela dit, même en retirant ce montant, je perdrais encore pour passer d'un CDI vers un CDD (et sans prime de fin de précarité)... Après chacun défini l'équilibre qui lui plait, pour moi c'était une bonne expérience.
Mais si tu as bossé à l'INRIA, tu comprends beaucoup de choses en constatant leur politique de RH. Dommage...
> Comme je disais (Le smiley ne change pas la lourdeur de la chose - ça devient vite lassant) :
Si je me permets la remarque c'est que j'y ai bossé. Quitte a être mal payé autant avoir une bonne qualité de vie, il n'y a que toi pour y voir une critique.
Pour répondre au commentaire d'au dessus; 49 jours de congés (CP + RTT), hormis ne pas dépendre du syntec et bosser pour air france ou probtp, tu auras du mal à trouver plus... C'est exactement le double de ce que j'ai actuellement.
> Dans la recherche c'est généralement 7j/7 avec des horaires assez importants chaque jour.
Déjà, tu es complètement hors sujet. On parle ici d'un poste d'ingénieur en tant que contractuel de la fonction publique. Si les chercheurs se laissent volontairement exploiter en bossant 7j/7 pour des clopinettes; en expliquant qu'ils font ca pour l'amour de la recherche mais passent 70% de leur temps à faire de l'administratif, c'est leur soucis et pas le sujet ici...
Pour un junior, c'est intéressant; le boulot est souvent bien, tu rencontres des gens compétents, et ca ouvre beaucoup de possibilité. Pour un premier boulot la grille INRIA reste acceptable. Et tu as une très bonne qualité de vie: congé + horaire très souple + "personne te demande rien".
Si c'est pas ton premier taff ,soit tu tiens vraiment à ta qualité de vie et tu acceptes un salaire pourri (ne pas oublier que c'est un CDD sans prime de fin de contrat etc.). Soit tu fais comme tout le monde, tu vas voir ailleurs...
> car les horaires sont libres et que parfois quand tu as bossé une semaine jusqu'à 3h du mat, tu as envie de faire la grasse mat un jour)
Tu devrais relire ton contrat de travail. Tu as un volume horaire et des heures de travail. Tout le monde s'en fou de les respecter ou non, mais évite de te faire mal sur ton lieu de travail à 3h du matin...
Maintenant tu n'as toujours pas répondu à mes questions pourtant très simples. Il n'y a pas de piège, je te demande juste d'étayer tes affirmations:
- En quoi YAML est plus adapté qu'XML pour le META.yml ? Les deux solutions sont parfaitement recevables (et bien d'autres); seulement tu nous expliquais que YAML était beaucoup plus adapté qu'XML pour cette tâche. Sur le plan verbosité/lisibilité tu n'as pas contesté, et pour la perte de fonctionnalité tu as proposé un traduction vers XML...
- Tu critiques les fichiers de configuration de Tomcat en mettant en cause XML. Puisque tu es le seul à avoir parler d'XML et de fichier de configuration dans ce thread, je suppose que tu proposais d'utiliser YAML à la place ? Peux tu nous montrer en quoi cela améliorerait les choses ?
Au cas oú tu ne parlais pas d'utiliser YAML; alors pourrait tu nous montrer rapidement comment tu verrais un fichier de configuration objectivement plus simple pour Tomcat ?
> Il est trivial de faire yaml2xml donc valider un yaml est facile...
Où est ton schema pour décrire un document yaml ? Ou alors tu l'écris en XSD ? (oui je sais c'est facile cf. kwalify mais chacun fait son truc dans son coin).
> Mais comme dans les formulaires, même si le client valide son fichier (formulaire), c'est au serveur de valider le fichier de conf au lncement.
Puisqu'il faut valider côté serveur, ca n'a aucun sens de proposé une aide à la personne qui édite un document ? La logique m'échappe un peu.
> Cette histoire de validation est à mon sens bidon. Il y a plus de 10000 modules je crois sur le CPAN et cela MARCHE !
Version courte:
Cette histoire de yaml est à mon sens bidon. Il y a plus de 18564 packages RPM dans fedora et cela MARCHE !
À quoi sert yaml alors qu'un bête fichier texte fait exactement la même chose.
Version longue:
En XML tu définis la structure de ton document via un schema XML ou un DTD. Cette définition est non ambigüe et peut être utilisée pour: produire une documentation sur le format de fichier, vérifier que le document que l'on rédige est valide, vérifier que le document que l'on nous transmet a la structure attendue, aider l'éditeur du document en lui montrant les elements, les attributs, les valeurs acceptable et la documentation associée etc.
En YAML, pour gagner quelques caractères et par ce que les chevrons n'ont pas l'air de te plaire tu: écris une spec ambigüe en langage naturelle ( http://module-build.sourceforge.net/META-spec-v1.3.html ) , dois humainement vérifier que ton document correspond à la spec, vérifier la structure de ton arbre avant de l'utiliser dans tes applications, doit lire la doc pour savoir ce que tu as le droit de mettre ou pas.
Petit exercice pratique: Prendre un "fichier inkscape". Le convertir en YAML de la manière que tu veux. Nous montrer que le fichier est devenu "humainement compréhensible" et donc que le problème était bien la technologie utilisée pour stocker les données.
Après on pourra discuter des fonctionnalités que tu as perdu en passant au YAML, de la légèreté gagnée ou de la différence de performance etc. Voir même de l'utilité que tel format de fichier soit "humainement compréhensible".
> Après, je vois que les fanatiques de java et de Tomcat trouvent leur fichier XML lisible et super. Je voudrais voir un serveur d'application Tomcat avec autant de module que le CPAN ;-)
Tu compares deux technologies différentes pour deux utilisations différentes. Ce n'est pas très rigoureux ni très objectif. Tout d'abord fixons l'utilisation à un module CPAN. En YAML ca donne:
Tout d'abord on constate que l'idée de python de se servir de l'indentation, en pratique c'est pas vraiment une bonne idée. Bon courage pour retrouver le document initial maintenant que templeet à bouffer les espaces. (Soyons clair je développe en python, mais c'était vraiment une idée à la con)
Personnellement je trouve pas ca plus ou moins lisible... META.yml décrit quelque chose de trivial. Ca s'exprime très simplement quelque soit la technologie.
Par contre comment je vérifie que mon META.yml est correct ? Quand j'écris mon document comment je découvre la structure du document ? Pourquoi je dois spécifier "Config: 0", c'est à dire devoir spécifier une valeur à que je veux dire "je m'en fou" ?
J'ai rien contre YAML et je trouve aussi que XML est overkill parfois et surtout pas adapté aux documents non arborescents tout comme YAML. Mais il faut pas dire n'importe quoi non plus.
Maintenant je t'invite à nous montrer en quoi YAML permettrait de rendre les fichiers de configuration de Tomcat plus lisible mais surtout plus facile à manipuler. Personnellement je les trouves pas pire qu'un fichier de conf d'exim mais bon...
> XML s'en fout des retours à la ligne, des tabulations et des espaces. Un document sur une seule ligne ou sur 100 lignes (avec le même contenu) seront vu comme deux documents identiques d'un point de vue XML
Dit comme cela c'est faux. Les espaces sont significatifs en XML si le document n'a pas de DTD. Il peuvent être ignoré, par défaut, que lorsqu'une DTD est spécifiée. De même il est possible de spécifier le comportement vis à vis des espaces via l'attribut xml:space.
> Les neuneus qui se prennent pour des showmen et remplissent leurs présentations de photos « amusantes » et autres lolcatz me les brisent.
Marrant en général ce sont les meilleurs présentateurs. Inconvénient leurs slides sont inutilisables sans l'orateur. C'est, entre autre, ce qui rend la présentation en vraie intéressante. Les mecs réfléchissent un peu plus à leur présentation que faire des bullet lists. Faut avoir le niveau et l'expérience pour que ca passe bien... Des slides ca sert de support à une présentation, si ce n'est pas pour présenter alors autant écrire un article.
Je ne l'ai pas regardé puisque cette présentation ne m'intéresse pas vraiment, mais il me semble que tu as la vidéo. L'as tu regardé ? Connaissant pas mal le domaine mais pas django, et ayant juste survolé les slides, je vois les idées qu'il avance et ca ne me semble pas du tout vide. Tu as regardé la partie 2 au moins ?.
Cela dit, même si ca présentation était complètement ratée, traiter Cal Henderson de "neuneu" c'est assez comique. Pour information c'est l'auteur de "Building Scalable Web Sites" soit l'un des livres de référence sur le sujet. Le dimanche matin c'est aussi le chief architect de flickr.
Quand on est un bon développeur on ne réinvente surtout pas roue; surtout pour ce qui concerne la sécurité. Si ton système ou les bibliothèques de ton environnement de développement fournissent une fonction telle que crypt() alors tu l'utilise et c'est tout.
Si vraiment il n'y a pas d'implémentation disponible; alors tu réimplémentes un standard en faisant super super super attention. Donc tu cherches "key derivation function" dans google; puisque c'est de ca dont il s'agit. Tu tombes sur des trucs comme PBKDF2, bcrypt ou scrypt, c'est fait pour. Si tu poses des questions comme "comment utiliser MD5 (une "cryptographic hash function") pour hasher un password", alors là, effectivement, tu es mal barré...
Donc si, tu mélanges tout et tu le fais avec assurance. Le débat sur les KDF c'est toi qui l'a amené dans un journal qui n'avait strictement rien à voir. Encore dans ce commentaire tu confonds allègrement les deux types de fonctions.
Après si 90% des devs et des admins sont pas capables de se documenter correctement sur un sujet, de trouver un standard, ou s'en foutent éperdument; le problème il est entre la chaise et le clavier. C'est pas du tout mon domaine, mais quand j'ai quelque chose à implémenter, je prends 1h pour me documenter sur le sujet. Libre a toi de vouloir continuer d'utiliser un marteau ("cryptographic hash function") plutôt qu'un tournevis ("key derivation function") pour enfoncer une vis...
> Sinon, le coup du "il faut prendre un hash plus lent parce que ca emmerde plus l'attaquant" ..., c'est relativement nul comme sécurité.
Non, c'est dans les buts d'un password hash a fin de ralentir les possibilités de brute force offline. Ca passe par l'ajout d'un graine afin de ne pas pouvoir casser plusieurs mdp à la fois et d'éviter les rainbow tables, mais aussi par avoir un algorithme couteux, configurable et pas trop optimisable en hardware pour ralentir encore le processus. Le papier de bcrypt que j'ai donné plus haut l'explique bien.
Avec DES il était en effet possible d'implémenter en hardware pour pas cher un truc vraiment performant. Les algorithmes modernes essayent de faire en sortent qu'il ne soit pas possible d'optimiser significativement la vitesse de hashage pour un nombre d'itérations donné.
Tu viens de prouver exactement le contraire de ce que tu disais. DES est plus faible que bcrypt ou scrypt, entre autre, par ce qu'il est facilement optimisable en hard.
> Comme je l'ai déjà, un hash sans grain de sel ne sers à rien dans pas mal de cas. Ou sont les grains de sels dans ce que je vois ?
C'est triste de ne pas comprendre (ou de ne pas vouloir comprendre) à ce point là l'objet du concours SHA-3.
SHA-3 à pour but de sélectionner une "cryptographic hash function", c'est à dire une fonction qui a les propriété suivantes:
- Il est facile de calculer le hash pour n'importe quel message
- Il n'est pas possible de générer un message ayant un hash donné
- Il n'est pas possible de modifier un message sans changer son hash
Où as tu vu que l'on cherchait à standardiser un password scheme ou un password hash ?
Tu me sembles tout mélanger. Le fait que crypt fasse sa tambouille interne en utilisant des fonctions de hashage comme MD5, SHA-[256||256] ou des block cypher (DES, Blowfish), t'a certainement induit en erreur. Les fonctions de hashages peuvent servir de bases pour élaborer un algorithme de password hash mais c'est tout. Le plus marrant c'est que l'algo à base de MD5 à plus la réputation d'être expérimental (made in PHK tout de même) plus que conçu cryptographiquement... Les implémentations sur les autres plateformes se contentant de copier celle de FreeBSD en mettant du genre:
195 /* The original implementation now does something weird: for every 1
196 bit in the key the first 0 is added to the buffer, for every 0
197 bit the first character of the key. This does not seem to be
198 what was intended but we have to follow this to be compatible. */
Ca reste dommage de mélanger des choses aussi grossières, quand on donne des lecons...
Un très bon papier d'OpenBSD sur la conception de bcrypt qui explique les principes d'un password scheme et d'une fonction de password hash: http://www.openbsd.org/papers/bcrypt-paper.ps
> OK, le lien est quand même faible. Ils suivent la même procédure.
Ils suivent le même processus, dans le même but, et ne sont tout les deux que des alias vers un des algos proposé. AES c'est rindjael avec trois longueur de clé. SHA-3 sera l'un des 14 algorithmes encore en course. C'est sur qu'il n'y a aucun rapport.
> Désolé mais tu te contredie sur les deux dernières lignes. C'est une procédure NIST dans les deux cas. Pour moi, la communauté intervient plus de nos jours on va dire dans leur procédure mais cela reste du NIST. Bref, ton argumentation n'est pas bien développé à ce niveau là si tu cherches à convaincre quelqu'un.
C'est chapeauté par la même organisation. Ca ne contredit en rien ce que je dis.
Avant le NIST arrivait avec son algo made in NSA et l'imposait comme standard. Personne n'a jamais eu vraiment confiance en DES. De même le changement entre SHA-0 et SHA-1 n'a, je croi,s jamais été justifié par la NSA (c'est pas mon domaine, corrigez moi si j'ai faux).
Pour AES et SHA tu as une procédure ouverte à la communauté, qui a satisfait tout le monde dans le cas d'AES. Pour citer bruce scheier "I have nothing but good things to say about NIST and the AES process", http://www.schneier.com/crypto-gram-0010.html#8
> Mais je ne tiens pas à MD6 ! Je dis, tiens il n'est plus la, surprenant !
Ta réponse concernant la vitesse pouvait laisser croire le contraire avec son point d'exclamation. Peux tu m'éclairer sur le sens de ta remarque sur la vitesse ? (En tenant compte du fait que tu savais qu'il y avait 14 autres algorithmes jugé aussi robuste que la version lente de MD6 et qui eux sont plus rapides)
> Sinon, je préfère effectivement qu'il y ait plus qu'un seul hash
Note que personne ne te force à utilise AES ou SHA si tu penses que d'autre fonctions sont moins exposées ou plus sures.
Le problème c'est que des gens aptes a étudier la robustesse d'un algo et d'une implémentation il n'en existe qu'une poignée. AES/SHA te certifie que la communauté de la cryptanalyse pense que cette fonction est robuste, rapide et implémentable sur tout type de plateforme. C'est un "survival of the fittest"
Multiplié les algos, c'est réduire le temps que cette poignée de personne a pour les valider... Je suis pas certain que tu arrives à l'effet voulu.
> Sinon, je ne vois pas le rapport entre l'AES et le hash mais je dois avoir oublié un truc
Entre AES et le hash aucun. Par contre entre AES et SHA-3, il y en a un petit... Ils suivent le même processus de standardisation par le NIST: concours ouvert, deux rounds puis élection finale, fenêtre de plus d'une année pour la cryptanalyse.
SHA-3 sera au hash ce que AES est au chiffrement: la solution estimé la meilleure par la communauté de la cryptographie. Contrairement à DES et SHA-(0,1,2) qui avaient été poussé unilatéralement par le NIST (et donc la NSA).
Pourquoi tenir absolument à MD6 alors que les auteurs ont demandé de le retirer de la compétition ? De toute façon on a besoin d'un algo le plus performant possible pour certains usages. L'algorithme élu sera plus robuste et plus rapide...
Tu penses vraiment que le monde serait meilleur avec douze algos de hash différents selon les usages ? Ca va justement à l'encontre de l'idée d'AES, SHA etc.
> C'est marrant comme questions, alors qu'on ne se la posait pas il y a 30 ans
Je suis d'accord avec toi mais ta remarque s'applique à tout. Y'a pleins de trucs qui existaient pas y'a 30 ans et qui pourtant sont très très pratiques au quotidien :-) Selon le contexte et ton humeur, tu utilises un appareil photo et ses fonctionnalités différemment. Tu peux te passer de beaucoup de choses, et il y a un vrai plaisir de sortir des photos à la main et à l'ancienne (voir de faire joujou avec des semflex). De la à dire que ca ne sert à rien...
Perso dans les conditions et pour les sports que je pratique, un bon AF, les modes A/T et un vrai mode rafale à >5 imgs/s sont un vrai plus. Si tu rates une image, tu ne peux pas la refaire et le but c'est de ne pas avoir trop de déchets.
D'un point de vue photo pure, tu as plus de plaisir à sortir une seule image parfaite, en prenant ton temps pour la compo, avec un focale fixe, tout en manuel et dirigeant le rider. Mais dans ce cas, tu ne rides plus et tu sors dix photos par saison. C'est une pratique différente.
C'est pas le mien (mon appareil n'est pas tropicalisé) et je sais pas dans quel état il a fini.
Comme dit plus haut, en restant dans la limite du raisonnable, le seul point faible de ce genre de matos est la lentille des objectifs qui peut se rayer avec le sable (rajouter un filtre permet de la protéger mais il reste toujours des trous). J'ai déjà vu des mecs se servir de leur 1D comme parapluie sous une bonne averse :-)
Effectivement. Ça dépend de ton utilisation. Pour faire du studio, du portait ou de l'archi ca doit être marrant comme matos. Étant donné les manipulations pour faire une mise au point (faut ouvrir le diaphragme à fond via bague, faire la MAP puis refermer) faut pas être pressé et pas trop que ca bouge non ?
Après un bon AF c'est tout de même vachement utile si tu fais du sport ou de l'animalier, faire ta MAP à la main (+ ouverture/fermeture du diaphragme) avec un télé genre 200 1.8 de 3kg pendant que t'as la bestiole qui court c'est une autre histoire. AF + mode rafale en sport ca fait des merveilles aussi.
Vu le prix des Takumar sur ebay, ca donne envie d'essayer sur un 50mm.
Y'a peut être un relation de cause à effet avec le fait que tu passes ton temps à dire des choses fausses et à t'en servir comme justificatif par ce que t'aime pas un truc ?
> Mais je pense que ces choses n'avait pas la place dans mon journal.
Et donc ton journal il sert à quoi ? Tu essais de dire qu'un GC ne sert à rien, que c'est inefficace et que firefox, si les devs n'étaient pas des tocards, ne devrait pas en utiliser.
Pour justifier l'inefficacité tu te sers de l'argument "scanner toute la mémoire" "scanner plein de région mémoire" et tu présentes de algorithmes avec des mots compliqués comme itératif ou ŕecursif. Mais en réalité ce n'est pas être pas si inefficace que tu voudrais bien le croire... Tu as regardé combien de temps ton firefox passait dans le GC ? Sinon tu parles dans le vide.
De même tu parles de récupération mémoire et que firefox préfère faire swapper que de réclamer la mémoire. Premièrement tu peux me donner la source de cette info ? Deuxièmement, on t'explique que faire des free ne te libérera pas plus la mémoire si le tas est fragmenté (et avec un appli type browser avec tab ca fragmente très facilement). Bref tu utilises une informations non vérifiable (et que je pense erronée) et une autre fausse...
Ca serait la première fois, ca passerait. Mais tu le fais à répétition, alors oui je suis sec. Quand tu viendras avec de vrai arguments ca changera peut être. Pour le moment tu as décidé que Java et les GC c'était pas bien, et tu utilises n'importe quoi pour le dire... Si c'est si mauvais que ca, c'est pas très compliqué de venir avec des chiffres vérifiables qui montrent que c'est le cas.
Au passage tu as raté un des vrais problème lié à l'utilisation d'un garbage collector: La création d'un objet, n'est plus vu comme une allocation mémoire pouvant échouer. Tu vas te prendre une vilaine runtime exception sortie de nulle part, que personne ne gère, si tu es à cours de mémoire. Là ou pouvait traiter tranquillement l'erreur, on se retrouve avec le même problème qu'un programme qui explose sa pile.
[^] # Re: et Kmymoney ?
Posté par ckyl . En réponse à la dépêche Skrooge, le petit nouveau de la gestion des finances personnelles. Évalué à 4.
Je rêve d'une application lourde qui serait aussi simple à utiliser que https://www.buxfer.com/
Rapide à comprendre/utiliser, ergonomique, sort les graphiques utiles etc. bref que du bon.
Je vais essayer Skrooge. Jusque ici il manque une application pour les gens qui veulent simplement importer les relevés de leur banque, tagger les entrées et regarder comment ça évolue sans y passer plus de 10 minutes par mois....
[^] # Re: Ce n'est pas une faille de sécurité de apache
Posté par ckyl . En réponse au journal apache.org compromis. Évalué à 4.
C'est le but de la protection par chiffrement symétrique (passphrase) de la clé privé. Voler la clé sur le support de stockage ne suffit pas pour avoir une clé opérationnelle.
Après dire qu'il suffit d'avoir une passphrase pour que ce genre d'événements n'arrive pas, ca me semble un tantinet naïf...
[^] # Re: Comparaison
Posté par ckyl . En réponse au journal Yum vs Apt. Évalué à 4.
Ça prend 10 secondes de plus... Me dit pas que tu utilises yum itérativement à la main sur chaque machine sur une batterie de serveur.
Yum pourrait être plus rapide c'est un fait. Après est ce vraiment un problème et un critère de choix ou seulement du confort ? Note aussi que c'est bien plus rapide dans les dernières Fedora.
[^] # Re: Ce n'est pas une faille de sécurité de apache
Posté par ckyl . En réponse au journal apache.org compromis. Évalué à 10.
À partir du moment ou un compte utilisateur est compromis il est très facile de récupérer la clé SSH associée, mot de passe ou non. Le mot de passe protège des vols de la clé par accès au support de stockage (partage NFS, clé USB, mauvaise permission de fichier, vol de laptop etc.) pas plus.
http://people.apache.org/~jim/committers.html ça en fait des possibilités de clés à voler. Sans parler de tout les process automatiques...
Au passage c'est moi ou y'a beaucoup de gens qui balance des trivialités ou du n'importe quoi avec condescendance ? Vu le niveaux des commentaires je trouve ca assez déplacé de casser du sucre sur l'équipe infrastructure d'apache qui jusqu'à preuve du contraire est très compétente... Sur ce cas précis 12 heures entre la compromission et la détection/analyse/prise de mesures/communication/restauration de service sur de la prod c'est du beau boulot. On peut voir le palmarès des donneurs de leçon ?
[^] # Re: lilUrl & co
Posté par ckyl . En réponse au journal Sans maîtrise, la puissance n'est rien. Évalué à 6.
Pour le moment l'expérience prouve plutôt le contraire. Va faire un tour sur des forums autorisant les images, et regarde le nombre d'image qui ne sont plus disponibles et d'où elles viennent. C'est très compréhensible étant donné que c'est le métier du premier, et ce n'est que le "hobby" de l'autre.
Si la perte d'un flickr, d'un imageshack ou autre serait un séisme. l'avantage des gros services c'est que tu as tout de même une chance que quelqu'un tente de sauver le tout vu l'importance du bouzin. Mes images que je link vers mon site perso, le jour ou j'ai plus envie de maintenir tout est perdu...
Pour moi quand on publie du contenu, c'est comme quand on écrit un soft. On le fait pour les lecteurs (les utilisateurs). Un des buts étant qu'une ressource ne change jamais d'adresse et soit accessible pour toujours. Dans les auto hébergés qui se prend la tête à garder les URL à coup de mod_rewrite quand il migre de gallery a zen photo ?
[^] # Re: Cadre confirmé
Posté par ckyl . En réponse au message Offre d'emploi pour faire évoluer les forges (gforge, ...). Évalué à 2.
Dans la branche dont on parle, ca ne me semble pas très courant. Dans le BTP ou la métallurgie c'est autre chose.
Et pour information c'est 35 jours de CP + 10 jours de RTT + recup. Les contrats ne sont pas aux 39h.
> Si tu n'appliques pas la loi, pourquoi tu te plains de travailler plus et reproche en même temps à un chercheur de le faire ?
Je ne reproche pas aux chercheurs de le faire. Je reproche de mélanger ce que certains décident de faire et leur contrat de travail.
Néanmoins, je suis d'accord avec leurs revendications; tant sur le boulot que sur la rémunération (personnellement j'aurais répondu "LOL" aux RH en voyant le contrat).
> Vous êtes tenus aux mêmes lois
La loi dit 35 heures, et 25 jours de CP. Tu peux même bosser 37h30 sans RTT grâce aux heures sup.
Y'a plus de boites qui ont lu la loi dans ce sens là, que dans le sens "je touche pas à ton salaire, je déclare 39h et je te donne 35 jours de CP + 25 jours de RTT"...
> comparer les montants que vous touchez à la fin du mois.
C'est pour cela que je faisais remarquer le volume de congé et la qualité de vie, en rebondissant sur le commentaire initial.
Si je voulais prendre le même volume de repos via des congés sans solde actuellement, tu peux retirer entre 300 et 400 euros sur le net par mois. C'était le sens de ma remarque initiale.
Cela dit, même en retirant ce montant, je perdrais encore pour passer d'un CDI vers un CDD (et sans prime de fin de précarité)... Après chacun défini l'équilibre qui lui plait, pour moi c'était une bonne expérience.
Mais si tu as bossé à l'INRIA, tu comprends beaucoup de choses en constatant leur politique de RH. Dommage...
[^] # Re: Cadre confirmé
Posté par ckyl . En réponse au message Offre d'emploi pour faire évoluer les forges (gforge, ...). Évalué à 3.
Si je me permets la remarque c'est que j'y ai bossé. Quitte a être mal payé autant avoir une bonne qualité de vie, il n'y a que toi pour y voir une critique.
Pour répondre au commentaire d'au dessus; 49 jours de congés (CP + RTT), hormis ne pas dépendre du syntec et bosser pour air france ou probtp, tu auras du mal à trouver plus... C'est exactement le double de ce que j'ai actuellement.
> Dans la recherche c'est généralement 7j/7 avec des horaires assez importants chaque jour.
Déjà, tu es complètement hors sujet. On parle ici d'un poste d'ingénieur en tant que contractuel de la fonction publique. Si les chercheurs se laissent volontairement exploiter en bossant 7j/7 pour des clopinettes; en expliquant qu'ils font ca pour l'amour de la recherche mais passent 70% de leur temps à faire de l'administratif, c'est leur soucis et pas le sujet ici...
Pour un junior, c'est intéressant; le boulot est souvent bien, tu rencontres des gens compétents, et ca ouvre beaucoup de possibilité. Pour un premier boulot la grille INRIA reste acceptable. Et tu as une très bonne qualité de vie: congé + horaire très souple + "personne te demande rien".
Si c'est pas ton premier taff ,soit tu tiens vraiment à ta qualité de vie et tu acceptes un salaire pourri (ne pas oublier que c'est un CDD sans prime de fin de contrat etc.). Soit tu fais comme tout le monde, tu vas voir ailleurs...
> car les horaires sont libres et que parfois quand tu as bossé une semaine jusqu'à 3h du mat, tu as envie de faire la grasse mat un jour)
Tu devrais relire ton contrat de travail. Tu as un volume horaire et des heures de travail. Tout le monde s'en fou de les respecter ou non, mais évite de te faire mal sur ton lieu de travail à 3h du matin...
[^] # Re: Cadre confirmé
Posté par ckyl . En réponse au message Offre d'emploi pour faire évoluer les forges (gforge, ...). Évalué à 4.
Étant donné le nombre de jour de congés, on pourrait presque dire que c'est un mi-temps en effet :-)
[^] # Re: CPAN de Perl
Posté par ckyl . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 1.
- En quoi YAML est plus adapté qu'XML pour le META.yml ? Les deux solutions sont parfaitement recevables (et bien d'autres); seulement tu nous expliquais que YAML était beaucoup plus adapté qu'XML pour cette tâche. Sur le plan verbosité/lisibilité tu n'as pas contesté, et pour la perte de fonctionnalité tu as proposé un traduction vers XML...
- Tu critiques les fichiers de configuration de Tomcat en mettant en cause XML. Puisque tu es le seul à avoir parler d'XML et de fichier de configuration dans ce thread, je suppose que tu proposais d'utiliser YAML à la place ? Peux tu nous montrer en quoi cela améliorerait les choses ?
Au cas oú tu ne parlais pas d'utiliser YAML; alors pourrait tu nous montrer rapidement comment tu verrais un fichier de configuration objectivement plus simple pour Tomcat ?
[^] # Re: CPAN de Perl
Posté par ckyl . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 5.
Où est ton schema pour décrire un document yaml ? Ou alors tu l'écris en XSD ? (oui je sais c'est facile cf. kwalify mais chacun fait son truc dans son coin).
> Mais comme dans les formulaires, même si le client valide son fichier (formulaire), c'est au serveur de valider le fichier de conf au lncement.
Puisqu'il faut valider côté serveur, ca n'a aucun sens de proposé une aide à la personne qui édite un document ? La logique m'échappe un peu.
> Cette histoire de validation est à mon sens bidon. Il y a plus de 10000 modules je crois sur le CPAN et cela MARCHE !
Version courte:
Cette histoire de yaml est à mon sens bidon. Il y a plus de 18564 packages RPM dans fedora et cela MARCHE !
À quoi sert yaml alors qu'un bête fichier texte fait exactement la même chose.
Version longue:
En XML tu définis la structure de ton document via un schema XML ou un DTD. Cette définition est non ambigüe et peut être utilisée pour: produire une documentation sur le format de fichier, vérifier que le document que l'on rédige est valide, vérifier que le document que l'on nous transmet a la structure attendue, aider l'éditeur du document en lui montrant les elements, les attributs, les valeurs acceptable et la documentation associée etc.
En YAML, pour gagner quelques caractères et par ce que les chevrons n'ont pas l'air de te plaire tu: écris une spec ambigüe en langage naturelle ( http://module-build.sourceforge.net/META-spec-v1.3.html ) , dois humainement vérifier que ton document correspond à la spec, vérifier la structure de ton arbre avant de l'utiliser dans tes applications, doit lire la doc pour savoir ce que tu as le droit de mettre ou pas.
Excuse moi j'ai du rater un truc quelque part...
[^] # Re: Pour le reste de leurs activités, les deux entreprises restent indÃ
Posté par ckyl . En réponse au journal Microsoft et Yahoo! se marient. Évalué à 3.
Dans les poids lourds nous avons:
- Yahoo! mail
- Flickr
- Yahoo! answers
- Yahoo! actualité section insolite
[^] # Re: Exemple
Posté par ckyl . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 4.
Après on pourra discuter des fonctionnalités que tu as perdu en passant au YAML, de la légèreté gagnée ou de la différence de performance etc. Voir même de l'utilité que tel format de fichier soit "humainement compréhensible".
[^] # Re: CPAN de Perl
Posté par ckyl . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 8.
Tu compares deux technologies différentes pour deux utilisations différentes. Ce n'est pas très rigoureux ni très objectif. Tout d'abord fixons l'utilisation à un module CPAN. En YAML ca donne:
--- #YAML:1.0
name: Module-Build
abstract: Build and install Perl modules
version: 0.20
author:
- Ken Williams<kwilliams@cpan.org>
license: perl
distribution_type: module
requires:
Config: 0
recommends:
Archive::Tar: 1.00
build_requires:
Test: 0
urls:
license: http://dev.perl.org/licenses/
meta-spec:
version: 1.3
url: http://module-build.sourceforge.net/META-spec-v1.3.html
generated_by: Module::Build version 0.20
Tout d'abord on constate que l'idée de python de se servir de l'indentation, en pratique c'est pas vraiment une bonne idée. Bon courage pour retrouver le document initial maintenant que templeet à bouffer les espaces. (Soyons clair je développe en python, mais c'était vraiment une idée à la con)
En XML ca donnerait quelque chose comme ca:
<module>
<name>Module-Build</name>
<abstract>Build and install Perl modules</abstract>
<version>0.20</version>
<author>
<name>Ken Williams</name>
<email>kwilliams@cpan.org</email>
</author>
<license>perl</license>
<requires>
<module name="Config"/>
</requires>
<recommends>
<module name="Archive::Tar" version="1.00"/>
</recommends>
</module>
Personnellement je trouve pas ca plus ou moins lisible... META.yml décrit quelque chose de trivial. Ca s'exprime très simplement quelque soit la technologie.
Par contre comment je vérifie que mon META.yml est correct ? Quand j'écris mon document comment je découvre la structure du document ? Pourquoi je dois spécifier "Config: 0", c'est à dire devoir spécifier une valeur à que je veux dire "je m'en fou" ?
J'ai rien contre YAML et je trouve aussi que XML est overkill parfois et surtout pas adapté aux documents non arborescents tout comme YAML. Mais il faut pas dire n'importe quoi non plus.
Maintenant je t'invite à nous montrer en quoi YAML permettrait de rendre les fichiers de configuration de Tomcat plus lisible mais surtout plus facile à manipuler. Personnellement je les trouves pas pire qu'un fichier de conf d'exim mais bon...
[^] # Re: espaces dans XML
Posté par ckyl . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 10.
Dit comme cela c'est faux. Les espaces sont significatifs en XML si le document n'a pas de DTD. Il peuvent être ignoré, par défaut, que lorsqu'une DTD est spécifiée. De même il est possible de spécifier le comportement vis à vis des espaces via l'attribut xml:space.
Bref c'est loin d'être aussi trivial que ça.
http://www.oracle.com/technology/pub/articles/wang-whitespac(...)
http://www.ibm.com/developerworks/xml/library/x-diff/index.h(...)
[^] # Re: à propos de Django
Posté par ckyl . En réponse à la dépêche Sortie de Django 1.1. Évalué à 4.
Marrant en général ce sont les meilleurs présentateurs. Inconvénient leurs slides sont inutilisables sans l'orateur. C'est, entre autre, ce qui rend la présentation en vraie intéressante. Les mecs réfléchissent un peu plus à leur présentation que faire des bullet lists. Faut avoir le niveau et l'expérience pour que ca passe bien... Des slides ca sert de support à une présentation, si ce n'est pas pour présenter alors autant écrire un article.
Je ne l'ai pas regardé puisque cette présentation ne m'intéresse pas vraiment, mais il me semble que tu as la vidéo. L'as tu regardé ? Connaissant pas mal le domaine mais pas django, et ayant juste survolé les slides, je vois les idées qu'il avance et ca ne me semble pas du tout vide. Tu as regardé la partie 2 au moins ?.
Cela dit, même si ca présentation était complètement ratée, traiter Cal Henderson de "neuneu" c'est assez comique. Pour information c'est l'auteur de "Building Scalable Web Sites" soit l'un des livres de référence sur le sujet. Le dimanche matin c'est aussi le chief architect de flickr.
[^] # Re: MD6
Posté par ckyl . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 5.
Si vraiment il n'y a pas d'implémentation disponible; alors tu réimplémentes un standard en faisant super super super attention. Donc tu cherches "key derivation function" dans google; puisque c'est de ca dont il s'agit. Tu tombes sur des trucs comme PBKDF2, bcrypt ou scrypt, c'est fait pour. Si tu poses des questions comme "comment utiliser MD5 (une "cryptographic hash function") pour hasher un password", alors là, effectivement, tu es mal barré...
Donc si, tu mélanges tout et tu le fais avec assurance. Le débat sur les KDF c'est toi qui l'a amené dans un journal qui n'avait strictement rien à voir. Encore dans ce commentaire tu confonds allègrement les deux types de fonctions.
Après si 90% des devs et des admins sont pas capables de se documenter correctement sur un sujet, de trouver un standard, ou s'en foutent éperdument; le problème il est entre la chaise et le clavier. C'est pas du tout mon domaine, mais quand j'ai quelque chose à implémenter, je prends 1h pour me documenter sur le sujet. Libre a toi de vouloir continuer d'utiliser un marteau ("cryptographic hash function") plutôt qu'un tournevis ("key derivation function") pour enfoncer une vis...
[^] # Re: MD6
Posté par ckyl . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 2.
Non, c'est dans les buts d'un password hash a fin de ralentir les possibilités de brute force offline. Ca passe par l'ajout d'un graine afin de ne pas pouvoir casser plusieurs mdp à la fois et d'éviter les rainbow tables, mais aussi par avoir un algorithme couteux, configurable et pas trop optimisable en hardware pour ralentir encore le processus. Le papier de bcrypt que j'ai donné plus haut l'explique bien.
Avec DES il était en effet possible d'implémenter en hardware pour pas cher un truc vraiment performant. Les algorithmes modernes essayent de faire en sortent qu'il ne soit pas possible d'optimiser significativement la vitesse de hashage pour un nombre d'itérations donné.
Tu viens de prouver exactement le contraire de ce que tu disais. DES est plus faible que bcrypt ou scrypt, entre autre, par ce qu'il est facilement optimisable en hard.
[^] # Re: MD6
Posté par ckyl . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 5.
C'est triste de ne pas comprendre (ou de ne pas vouloir comprendre) à ce point là l'objet du concours SHA-3.
SHA-3 à pour but de sélectionner une "cryptographic hash function", c'est à dire une fonction qui a les propriété suivantes:
- Il est facile de calculer le hash pour n'importe quel message
- Il n'est pas possible de générer un message ayant un hash donné
- Il n'est pas possible de modifier un message sans changer son hash
Où as tu vu que l'on cherchait à standardiser un password scheme ou un password hash ?
Tu me sembles tout mélanger. Le fait que crypt fasse sa tambouille interne en utilisant des fonctions de hashage comme MD5, SHA-[256||256] ou des block cypher (DES, Blowfish), t'a certainement induit en erreur. Les fonctions de hashages peuvent servir de bases pour élaborer un algorithme de password hash mais c'est tout. Le plus marrant c'est que l'algo à base de MD5 à plus la réputation d'être expérimental (made in PHK tout de même) plus que conçu cryptographiquement... Les implémentations sur les autres plateformes se contentant de copier celle de FreeBSD en mettant du genre:
195 /* The original implementation now does something weird: for every 1
196 bit in the key the first 0 is added to the buffer, for every 0
197 bit the first character of the key. This does not seem to be
198 what was intended but we have to follow this to be compatible. */
Ca reste dommage de mélanger des choses aussi grossières, quand on donne des lecons...
Un très bon papier d'OpenBSD sur la conception de bcrypt qui explique les principes d'un password scheme et d'une fonction de password hash: http://www.openbsd.org/papers/bcrypt-paper.ps
Le code source de la glibc http://repo.or.cz/w/glibc.git?a=tree;f=crypt;hb=HEAD des choses comme md5-crypt.c valent le coup d'oeil
[^] # Re: MD6
Posté par ckyl . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 7.
Ils suivent le même processus, dans le même but, et ne sont tout les deux que des alias vers un des algos proposé. AES c'est rindjael avec trois longueur de clé. SHA-3 sera l'un des 14 algorithmes encore en course. C'est sur qu'il n'y a aucun rapport.
> Désolé mais tu te contredie sur les deux dernières lignes. C'est une procédure NIST dans les deux cas. Pour moi, la communauté intervient plus de nos jours on va dire dans leur procédure mais cela reste du NIST. Bref, ton argumentation n'est pas bien développé à ce niveau là si tu cherches à convaincre quelqu'un.
C'est chapeauté par la même organisation. Ca ne contredit en rien ce que je dis.
Avant le NIST arrivait avec son algo made in NSA et l'imposait comme standard. Personne n'a jamais eu vraiment confiance en DES. De même le changement entre SHA-0 et SHA-1 n'a, je croi,s jamais été justifié par la NSA (c'est pas mon domaine, corrigez moi si j'ai faux).
Pour AES et SHA tu as une procédure ouverte à la communauté, qui a satisfait tout le monde dans le cas d'AES. Pour citer bruce scheier "I have nothing but good things to say about NIST and the AES process", http://www.schneier.com/crypto-gram-0010.html#8
Après tu penses ce que tu veux...
[^] # Re: MD6
Posté par ckyl . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 1.
Ta réponse concernant la vitesse pouvait laisser croire le contraire avec son point d'exclamation. Peux tu m'éclairer sur le sens de ta remarque sur la vitesse ? (En tenant compte du fait que tu savais qu'il y avait 14 autres algorithmes jugé aussi robuste que la version lente de MD6 et qui eux sont plus rapides)
> Sinon, je préfère effectivement qu'il y ait plus qu'un seul hash
Note que personne ne te force à utilise AES ou SHA si tu penses que d'autre fonctions sont moins exposées ou plus sures.
Le problème c'est que des gens aptes a étudier la robustesse d'un algo et d'une implémentation il n'en existe qu'une poignée. AES/SHA te certifie que la communauté de la cryptanalyse pense que cette fonction est robuste, rapide et implémentable sur tout type de plateforme. C'est un "survival of the fittest"
Multiplié les algos, c'est réduire le temps que cette poignée de personne a pour les valider... Je suis pas certain que tu arrives à l'effet voulu.
> Sinon, je ne vois pas le rapport entre l'AES et le hash mais je dois avoir oublié un truc
Entre AES et le hash aucun. Par contre entre AES et SHA-3, il y en a un petit... Ils suivent le même processus de standardisation par le NIST: concours ouvert, deux rounds puis élection finale, fenêtre de plus d'une année pour la cryptanalyse.
SHA-3 sera au hash ce que AES est au chiffrement: la solution estimé la meilleure par la communauté de la cryptographie. Contrairement à DES et SHA-(0,1,2) qui avaient été poussé unilatéralement par le NIST (et donc la NSA).
[^] # Re: MD6
Posté par ckyl . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 2.
Tu penses vraiment que le monde serait meilleur avec douze algos de hash différents selon les usages ? Ca va justement à l'encontre de l'idée d'AES, SHA etc.
[^] # Re: [X] un reflex ET un compact
Posté par ckyl . En réponse au sondage Mon appareil photo actuel est. Évalué à 3.
Je suis d'accord avec toi mais ta remarque s'applique à tout. Y'a pleins de trucs qui existaient pas y'a 30 ans et qui pourtant sont très très pratiques au quotidien :-) Selon le contexte et ton humeur, tu utilises un appareil photo et ses fonctionnalités différemment. Tu peux te passer de beaucoup de choses, et il y a un vrai plaisir de sortir des photos à la main et à l'ancienne (voir de faire joujou avec des semflex). De la à dire que ca ne sert à rien...
Perso dans les conditions et pour les sports que je pratique, un bon AF, les modes A/T et un vrai mode rafale à >5 imgs/s sont un vrai plus. Si tu rates une image, tu ne peux pas la refaire et le but c'est de ne pas avoir trop de déchets.
D'un point de vue photo pure, tu as plus de plaisir à sortir une seule image parfaite, en prenant ton temps pour la compo, avec un focale fixe, tout en manuel et dirigeant le rider. Mais dans ce cas, tu ne rides plus et tu sors dix photos par saison. C'est une pratique différente.
[^] # Re: Utilité du Réflex
Posté par ckyl . En réponse au sondage Mon appareil photo actuel est. Évalué à 2.
Comme dit plus haut, en restant dans la limite du raisonnable, le seul point faible de ce genre de matos est la lentille des objectifs qui peut se rayer avec le sable (rajouter un filtre permet de la protéger mais il reste toujours des trous). J'ai déjà vu des mecs se servir de leur 1D comme parapluie sous une bonne averse :-)
[^] # Re: [X] un reflex ET un compact
Posté par ckyl . En réponse au sondage Mon appareil photo actuel est. Évalué à 1.
Après un bon AF c'est tout de même vachement utile si tu fais du sport ou de l'animalier, faire ta MAP à la main (+ ouverture/fermeture du diaphragme) avec un télé genre 200 1.8 de 3kg pendant que t'as la bestiole qui court c'est une autre histoire. AF + mode rafale en sport ca fait des merveilles aussi.
Vu le prix des Takumar sur ebay, ca donne envie d'essayer sur un 50mm.
[^] # Re: Comme d'habitude avec yellowiscool
Posté par ckyl . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 7.
Y'a peut être un relation de cause à effet avec le fait que tu passes ton temps à dire des choses fausses et à t'en servir comme justificatif par ce que t'aime pas un truc ?
> Mais je pense que ces choses n'avait pas la place dans mon journal.
Et donc ton journal il sert à quoi ? Tu essais de dire qu'un GC ne sert à rien, que c'est inefficace et que firefox, si les devs n'étaient pas des tocards, ne devrait pas en utiliser.
Pour justifier l'inefficacité tu te sers de l'argument "scanner toute la mémoire" "scanner plein de région mémoire" et tu présentes de algorithmes avec des mots compliqués comme itératif ou ŕecursif. Mais en réalité ce n'est pas être pas si inefficace que tu voudrais bien le croire... Tu as regardé combien de temps ton firefox passait dans le GC ? Sinon tu parles dans le vide.
De même tu parles de récupération mémoire et que firefox préfère faire swapper que de réclamer la mémoire. Premièrement tu peux me donner la source de cette info ? Deuxièmement, on t'explique que faire des free ne te libérera pas plus la mémoire si le tas est fragmenté (et avec un appli type browser avec tab ca fragmente très facilement). Bref tu utilises une informations non vérifiable (et que je pense erronée) et une autre fausse...
Ca serait la première fois, ca passerait. Mais tu le fais à répétition, alors oui je suis sec. Quand tu viendras avec de vrai arguments ca changera peut être. Pour le moment tu as décidé que Java et les GC c'était pas bien, et tu utilises n'importe quoi pour le dire... Si c'est si mauvais que ca, c'est pas très compliqué de venir avec des chiffres vérifiables qui montrent que c'est le cas.
Au passage tu as raté un des vrais problème lié à l'utilisation d'un garbage collector: La création d'un objet, n'est plus vu comme une allocation mémoire pouvant échouer. Tu vas te prendre une vilaine runtime exception sortie de nulle part, que personne ne gère, si tu es à cours de mémoire. Là ou pouvait traiter tranquillement l'erreur, on se retrouve avec le même problème qu'un programme qui explose sa pile.