Je serais curieux de voir le code pour comparer les 2 implémentations et voir le résultat, si il est disponible.
i<>
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
C'est un peu mieux. C'est moins invasif. Cela marche bien sous Linux, mais c'est plus galère sous windows.
Dans le projet blinken light, tu as un ordinateur par ligne relié par Ethernet, et chaque point est relier par RS232 avec un petit variateur pour commander une lampe halogène de 500W.
Tu peux imaginer des ubidules qui gère plusieurs projecteurs RGB qui sont "étalé" sur une grande surface (plus large qu'une surface d'immeuble).
Le coté intelligent serait le réglage automatique de la position de chaque point et l'autocalibration de chaque couleur.
En fait, c'est surtout que ext4 se comportait comme XFS en réordonnancement aussi les rename avec les write, ce qui pouvait faire en sorte de changer le nom du fichier avant que l'écriture soit effective. D'ou le débat de l'utilisation de fsync() mais qui est lente alors que le rename sous-entendait une relation d'ordre.
Les logs monstrueux, c'est quelle taille 1 Go ? 10 Go ? plus ? Les log pour les simu VHDL tracent tout :)
En fait, en VHDL, les simu sont longues donc on préfère loger un max pour relire ensuite. Mais si l'execution est pas trop lente, le choix de quoi loguer peut être fait au runtime.
Concernant la suite, je te donne l'état des réflexions et les pistes que l'on peut suivre. Je ne te dis pas que c'est la meilleur solution, je ne te dis pas qu'il n'y a que ça à faire, je ne te dis pas non plus tout ce qui est envisageable de faire sans casser le modèle de programmation de Lisaac.
Je trouve hallucinant que tu me reproches de te donner les pistes que l'on explore. Je te donnes les pistes, pour toi, c'est que je troll en sous entendant je ne sais quoi. Je parle du présent, tu me dis, je m'en fout il manque telle truc. Tu me dis je me tiendrait au courant des nouveautés, je te donne des pistes pour le future, tu me dis que je troll.
Un système de trace pourrait éviter tout recompilation, certe, c'est du futur, certe, cela n'existe pas encore. Moi pourquoi forcément, me le renvoyer dans la figure, sans éventuellement accepter que le boulot pourrait être fait de cette façon. Ou encore, j'avais parlé dans un autre commentaire de séparation du proto en test des autres proto, mais on dirait que tu l'as oublier, ou alors, il fallait encore que je me répète ?
J'arrêtes là la conversation. Il n'y en a pas. Quoi que je dis ou propose, je troll ou je dénigre. J'ai l'impression qu'il est impossible de proposer un truc un minimum différent sans se faire défoncer.
C'est toi qui disait "Le minimum, c'est de regarder l'état de l'art de ce qui se fait.". C'était bien le but de ton intervention ?
Donc renseignes toi sur des logiciels comme "Prover", les générateurs automatique de pattern de test (ATPG), les techniques de back propagation que l'on retrouve dans les "Static Timing Analyzer" pour comprendre ce qui peut se faire statiquement.
Renseignes toi aussi les process induit pour les logiciels critiques comme la DO-178, IEC 61508 et la EN 50128, pour comprendre comment est censé se faire une spec.
Je crois que niveau validation/test, tu t'es trompé de siècle.
M'enfin, c'est un peu de la déformation professionnel, les avions, c'est pas censé planter.
Alors évidemment, les assertions ne doivent pas être ignorer, elles sont complémentaires, mais elles ne remplacent en aucun cas le feedback de l'exécution.
Dis moi les projets sur lequel tu bosses, que je ne les utilise pas. Parce que se contenter de test exploratoire pour faire de la validation, c'est franchement léger.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
Tu as l'air de dire que je suis l'origine des trolls, c'est tout de même rarement le cas. Je me contenterais du minimum.
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant...
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ? Il y a quelques temps j'avais poser des questions dans des journaux sur comment développer différentes applications, quel outils manquait, etc... A quelques exceptions prêt, les résultats n'allaient pas bien loin. C'est un peu le syndrome décrit par Ford: "si j'avais écouté mes clients, j'aurais fait des chevaux plus rapide".
C'est très difficile de connaitre les vrais besoins. Ton besoin n'est pas d'avoir un temps de compilation faible, par exemple. Ton besoin est de pouvoir être efficace dans la recherche d'erreur dans des équations. Cela peut se résoudre avec un temps de compilation rapide, ou cela peut se résoudre avec un système de trace, que j'ai toujours trouvé génial pour les applications écrite en VHDL ou Verilog: les systèmes de waveform. Ou encore avec un système de dimension sur les données, avec les assertions, etc... Il y a d'autres solutions, donc.
Dans mon code, j'ai des assertion pour vérifier l'indicage des tableaux et autre conneries du même style, donc généralement tous ces bigs sont résolus très rapidement.
En lisaac, les tableaux sont dynamiques donc, il n'y a pas d'erreur possible la dessus.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Je sais, c'est mon boulot "professionnel" avec des compiles qui peuvent prendre une nuit, avec des équipes de test, de validation, d'intégration, des étapes de relecture, et franchement les temps de compile qui se chiffrent en dizaine de minute, cela n'est rien du tout :)
Si tu compile LLVM et CLang par exemple (non ce n'est pas de la provoc de compiler une aure compilo que lisaac....) La première compile prend pas loin d'une heure. Par contre, une fois que c'est fait, juste modifier une fichier source, implique de ne recompiler que ce fichier et de refaire l'édition de liens, c'est pas instantané bien sûr, mais c'est très rapide.
Tu ne refait une compilation globale avec optimisation inter-modules que pour une compilation finale.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
A plus court terme, il y a à faire une sortie propre de la 0.39 sans bug et avec une doc potable, et surtout une syntaxe stabilisée. Ensuite, il faut de la réflexivité. Il y a à corriger les derniers problèmes sur COP, le modèle multitache. Il y a à trouver un moyen de tester les assertions automatiquement (par génération de vecteur d'entrée, par montecarlo, par propagation arrière,etc...).
fsync() à une sorte de sémantique d'urgence, qui fait ralentir tout le système.
Souvent on voudrait juste un fdone(), quitte à le mettre dans un thread. Mais j'ai aucune idée de comment il est possible de garantir l'atomicité d'une modification sans fsync(). En gros, on veut écrire 64K, mais en cas de problème on veux soit la version précédente sois la nouvelle version mais pas un mixte. Je pense qu'un simple write (sys_write()) doit avoir cette sémantique avec les nouveaux systèmes de fichier mais que l'on a aucune idée de la taille max qu'il peut gérer comme cela (une page de 4K ? un buffer autour de 1Mo ? une grosse page de 4Mo ?).
et ce qui est important c'est que c'est toi qui veut nous vendre quelque chose, donc c'est à toi de nous convaincre.
Je crois surtout que je vais arrêter de me stresser dans des querelles stériles, cela n'apporte rien du tout, et cela ne sert à rien. A te lire, cela desserre aussi le projet. Donc, je vais oublier linuxfr pour la suite de Lisaac, inutile de perdre le temps de tout le monde.
Je suis toujours intéresser pour comprendre les vrai besoins des utilisateurs de langage, cela m'a toujours passionner. J'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile). Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
"+" à la place d'un "-", je veux bien comprendre que cela soit difficile à attraper statiquement, mais cela dépend aussi de comment tu écris ton contrat. Il y a des contrats ou tu utilises des propriétés à conserver, genre "f(a,b)=f(b,a)", cela permetrait d'attraper certaine erreur dans les équations. On pense aussi mettre une lib qui vérifie la dimension physique des opérations (cela n'aura pas le + à la place du -, certe).
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur.
Et sur la masse total d'erreur ?
Autant pour une version finale, pas de problèmes pour un build d'une demie heure, autant pour une compilation de debugage, c'est poubelle direct.
C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.
Je dirais que en théorie tu as raison. Mais dans ce cas, comment expliques tu que tout les utilisateurs de SSD considèrent que leur PC a perdu toutes ses petites latences qui rend l'ordinateur "mou" et surtout comment voit-il une différence entre SSD comme avec le X25-e ?
J'ai lu il y a un moment un blog d'un codeur du noyau linux. Il était content des nouveaux OCZ vertex, qui sont les 1er SSD a être compétitif face à ceux d'intel.
Au bout d'un moment, git lui remontait des erreurs dans ses fichiers (git utilise des hash sha-256). Il s'est rendu compte que les OCZ faisait moins attention à ses données que les disques intel. Il est donc retourné dépité sous intel.
On peut même dire que la différence entre SSD pro type X25-e et X25-M, c'est la bande passante des paquets de 4Ko en écriture aléatoire. En gros autour de 1Mo pour les disques dures et à plus de 10 Mo pour les SSD pro.
C'est une donnée très importante pour toutes applications qui passent leur temps à faire des fsync() comme firefox avec SQLlite.
Est-ce qu'il y a des filtres pour "gommer" les déformations géométriques des objectifs ? Il existe un logiciel libre dont j'ai oublier le nom qui utilise une formule connu avec 3 paramètres. Ceux ci sont dans une base de donné pas mis à jour (fulla de mémoire, mais j'ai pas vérifier depuis un moment).
Il serait super utile tout de même d'avoir un plugin qui permet de faire un truc "au jugé" à la main. (http://wiki.panotools.org/Lens_correction_model ). Si il est possible de faire ça par plan de couleur, cela permet aussi de récupérer des abérations chromatique (les franges violettes).
Si mais de façon bizarre, en gros, tu as interdiction de modifier, tu lis des trucs commun, et tu écris ailleurs. Beaucoup d'algos peuvent se faire comme ça. En gros, cela ressemble à un filtre shell :)
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
i<>
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
C'est un peu mieux. C'est moins invasif. Cela marche bien sous Linux, mais c'est plus galère sous windows.
"La première sécurité est la liberté"
# Ecran géant
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ubiquitous computing. Évalué à 2.
Le coté interaction serait là uniquement pour définir la géographie des points.
http://blinkenlights.net/arcade
Dans le projet blinken light, tu as un ordinateur par ligne relié par Ethernet, et chaque point est relier par RS232 avec un petit variateur pour commander une lampe halogène de 500W.
Tu peux imaginer des ubidules qui gère plusieurs projecteurs RGB qui sont "étalé" sur une grande surface (plus large qu'une surface d'immeuble).
Le coté intelligent serait le réglage automatique de la position de chaque point et l'autocalibration de chaque couleur.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
En fait, en VHDL, les simu sont longues donc on préfère loger un max pour relire ensuite. Mais si l'execution est pas trop lente, le choix de quoi loguer peut être fait au runtime.
Concernant la suite, je te donne l'état des réflexions et les pistes que l'on peut suivre. Je ne te dis pas que c'est la meilleur solution, je ne te dis pas qu'il n'y a que ça à faire, je ne te dis pas non plus tout ce qui est envisageable de faire sans casser le modèle de programmation de Lisaac.
Je trouve hallucinant que tu me reproches de te donner les pistes que l'on explore. Je te donnes les pistes, pour toi, c'est que je troll en sous entendant je ne sais quoi. Je parle du présent, tu me dis, je m'en fout il manque telle truc. Tu me dis je me tiendrait au courant des nouveautés, je te donne des pistes pour le future, tu me dis que je troll.
Un système de trace pourrait éviter tout recompilation, certe, c'est du futur, certe, cela n'existe pas encore. Moi pourquoi forcément, me le renvoyer dans la figure, sans éventuellement accepter que le boulot pourrait être fait de cette façon. Ou encore, j'avais parlé dans un autre commentaire de séparation du proto en test des autres proto, mais on dirait que tu l'as oublier, ou alors, il fallait encore que je me répète ?
J'arrêtes là la conversation. Il n'y en a pas. Quoi que je dis ou propose, je troll ou je dénigre. J'ai l'impression qu'il est impossible de proposer un truc un minimum différent sans se faire défoncer.
D'ailleurs, tu n'as pas répondu sur Octave vs C.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Donc renseignes toi sur des logiciels comme "Prover", les générateurs automatique de pattern de test (ATPG), les techniques de back propagation que l'on retrouve dans les "Static Timing Analyzer" pour comprendre ce qui peut se faire statiquement.
Renseignes toi aussi les process induit pour les logiciels critiques comme la DO-178, IEC 61508 et la EN 50128, pour comprendre comment est censé se faire une spec.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 1.
M'enfin, c'est un peu de la déformation professionnel, les avions, c'est pas censé planter.
Alors évidemment, les assertions ne doivent pas être ignorer, elles sont complémentaires, mais elles ne remplacent en aucun cas le feedback de l'exécution.
Dis moi les projets sur lequel tu bosses, que je ne les utilise pas. Parce que se contenter de test exploratoire pour faire de la validation, c'est franchement léger.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
Tu as l'air de dire que je suis l'origine des trolls, c'est tout de même rarement le cas. Je me contenterais du minimum.
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant...
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ? Il y a quelques temps j'avais poser des questions dans des journaux sur comment développer différentes applications, quel outils manquait, etc... A quelques exceptions prêt, les résultats n'allaient pas bien loin. C'est un peu le syndrome décrit par Ford: "si j'avais écouté mes clients, j'aurais fait des chevaux plus rapide".
C'est très difficile de connaitre les vrais besoins. Ton besoin n'est pas d'avoir un temps de compilation faible, par exemple. Ton besoin est de pouvoir être efficace dans la recherche d'erreur dans des équations. Cela peut se résoudre avec un temps de compilation rapide, ou cela peut se résoudre avec un système de trace, que j'ai toujours trouvé génial pour les applications écrite en VHDL ou Verilog: les systèmes de waveform. Ou encore avec un système de dimension sur les données, avec les assertions, etc... Il y a d'autres solutions, donc.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
En lisaac, les tableaux sont dynamiques donc, il n'y a pas d'erreur possible la dessus.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Je sais, c'est mon boulot "professionnel" avec des compiles qui peuvent prendre une nuit, avec des équipes de test, de validation, d'intégration, des étapes de relecture, et franchement les temps de compile qui se chiffrent en dizaine de minute, cela n'est rien du tout :)
Si tu compile LLVM et CLang par exemple (non ce n'est pas de la provoc de compiler une aure compilo que lisaac....) La première compile prend pas loin d'une heure. Par contre, une fois que c'est fait, juste modifier une fichier source, implique de ne recompiler que ce fichier et de refaire l'édition de liens, c'est pas instantané bien sûr, mais c'est très rapide.
Tu ne refait une compilation globale avec optimisation inter-modules que pour une compilation finale.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
A plus court terme, il y a à faire une sortie propre de la 0.39 sans bug et avec une doc potable, et surtout une syntaxe stabilisée. Ensuite, il faut de la réflexivité. Il y a à corriger les derniers problèmes sur COP, le modèle multitache. Il y a à trouver un moyen de tester les assertions automatiquement (par génération de vecteur d'entrée, par montecarlo, par propagation arrière,etc...).
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
Souvent on voudrait juste un fdone(), quitte à le mettre dans un thread. Mais j'ai aucune idée de comment il est possible de garantir l'atomicité d'une modification sans fsync(). En gros, on veut écrire 64K, mais en cas de problème on veux soit la version précédente sois la nouvelle version mais pas un mixte. Je pense qu'un simple write (sys_write()) doit avoir cette sémantique avec les nouveaux systèmes de fichier mais que l'on a aucune idée de la taille max qu'il peut gérer comme cela (une page de 4K ? un buffer autour de 1Mo ? une grosse page de 4Mo ?).
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je crois surtout que je vais arrêter de me stresser dans des querelles stériles, cela n'apporte rien du tout, et cela ne sert à rien. A te lire, cela desserre aussi le projet. Donc, je vais oublier linuxfr pour la suite de Lisaac, inutile de perdre le temps de tout le monde.
Je suis toujours intéresser pour comprendre les vrai besoins des utilisateurs de langage, cela m'a toujours passionner. J'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile). Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur.
Et sur la masse total d'erreur ?
Autant pour une version finale, pas de problèmes pour un build d'une demie heure, autant pour une compilation de debugage, c'est poubelle direct.
C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.
"La première sécurité est la liberté"
[^] # Re: AMHA
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Surfez avec Internet Explorer et offrez vous un système de sauvegarde gratuit. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: et le kernel dans tout ça ??
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
Si tu fais une copie de fichier de 1 Mo par exemple ou moins, un SSD serait plus rapide qu'une grosse baie raid 5.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: filtre anti-déformation
Posté par Nicolas Boulay (site web personnel) . En réponse au journal G'MIC : Goinfrez Moi d'Images Cristallines !. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Durable!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 3.
Au bout d'un moment, git lui remontait des erreurs dans ses fichiers (git utilise des hash sha-256). Il s'est rendu compte que les OCZ faisait moins attention à ses données que les disques intel. Il est donc retourné dépité sous intel.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 3.
C'est une donnée très importante pour toutes applications qui passent leur temps à faire des fsync() comme firefox avec SQLlite.
http://www.pcworld.fr/image/zoom/1045351/ControllerWR (intel SLC, c'est le X25-e)
"La première sécurité est la liberté"
# filtre anti-déformation
Posté par Nicolas Boulay (site web personnel) . En réponse au journal G'MIC : Goinfrez Moi d'Images Cristallines !. Évalué à 2.
Il serait super utile tout de même d'avoir un plugin qui permet de faire un truc "au jugé" à la main. (http://wiki.panotools.org/Lens_correction_model ). Si il est possible de faire ça par plan de couleur, cela permet aussi de récupérer des abérations chromatique (les franges violettes).
"La première sécurité est la liberté"
[^] # Re: cohérence de cache<
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: 2 mots clefs... ou pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je ne vois pas de licence là-bas. Cela serait à ajouter qq part, d'ailleurs.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
"La première sécurité est la liberté"