E V a écrit 59 commentaires

tout à fait d'accord. Mais souvent les auteurs souhaitent savoir si leur produit est utilsé ou pas, par qui, etc. Ils devraient faire une enquete après le télechargement si c'est important pour eux.

Léa Linux est un site inestimable pour les débutants. Ce site m'a permis d'apprendre à configurer mon systeme à une époque et j'aimerais ici dire merci à Léa.

voilà une bonne reference à mettre dans ses bookmarks
http://www.tsi.enst.fr/tsi/enseignement/ressources/mti/(...)

mais si il y a perte: la quantifiacation du signal alors?

Mais si c'est n'importe quoi. Une fois que le son digital est passé dans l'ampli analogique, puis dans les HP, il s'enrichit (harmoniques ajoutées), se dégrade (hautes/basses fréquences filtrées) et se bruite. Donc l'étude, qui ne tient pas compte de ce petit problème n'est pas allée jusqu'au bout. C'est juste une bonne idée ... qui foire à la fin.

Pour les ventilos:
man gedicoustic.... heu... cf gedicoustic chez tout marchand de matériel de bricolage. C'est magique.

Alors là c'est facile. Et moi je réponds en français: Atari c'est trop de la merde. Vive Amiga.

Je n'ai pas lu l'article. Mais l'idee d'imposer une taxe sur Internet alors là! Ca me met vraiment en colère. Je n'ai JAMAIS utilisé ma connexion 50h pour télecharger un morceau de musique.

Mon idée à moi: si ils veulent faire de l'argent zont cas produire de meilleurs disques d'abord et les vendre moins cher ensuite. Mais tout ce qu'ils veulent, c'est vendre de la merde, beaucoup et le plus cher possible. De toute façon il n'y a que les nouveautés super médiatiques qui se vendent 24EUR. Perso, un disque c'est comme un livre. Si j'aime, je photocopie pas. J'achète. Et je les duplique/compresse pour les écouter au travail sans les abimer. Je fais la même chose avec les vinyls d'ailleurs.

Je me rappelle avoir vue une expos de Karl Sims à la fin des années 80 au Centre G. Pompidou. Il utilisait déjà des connections machines (machines massivement parallèles) pour faire des trucs incroyables d'un point de vue graphique (ça valait bien mieux que les meilleurs demo de mon amiga à l'époque). Je crois aussi que ses résultats à l'époque, où l'on voyait des systèmes complexes qui évoluaient tout seuls, ont motivé beaucoup de chercheurs dans la communauté des réseaux de neurones. Je trouve ça marrant de voir à nouveau ces principes appliqués dans un film (un excellent film au passage).

Marrant que personne n'ait publié les performances respectives des différents formats:
en fonction des critère suivants
taille du code, FLOP par octet de fichier son, PSNR/SNR pour differents bitrate, SNR dans différentes bandes, etc...
Ce serait très instructif et aussi facile à réaliser avec un peu de temps.

Debian est ma distribution préférée. Pour moi, c'est une erreur de vouloir se servir du nom "Debian" pour faire autre chose que Debian, c'est à dire une distribution rigoureuse, parfois exigente, notamment au niveau de l'installation. Choisir le nom "Debian-Desktop" va peut être semer la confusion, induire les gens en erreur, voire, on peut craindre de rompre l'harmonie stable/test/unstable, mélanger les paquets... bref pas bien... dangereux...

GénialISSIME!
Un grand merci pour ce lien!

Bizarre que personne ne mentionne ce problème bien réel (je ne suis pas le seul à constater cela, cf rapports de bugs/issues). A croire que personne n'utilise OO *vraiment*! Les polices TrueType ne sont pas bien gérées de manière générale (essayer d'imprimer des polices truetype pour voir...). En plus, les polices par défaut sont affreuses, voire, il manque plein de caractères. Sans parler des problèmes sur l'affichage des polices à l'écran qui surviennent aléatoirement.

Bref... c'est pas sérieux tout ça.

Le proprio, c'est mal. Et pourquoi pas?. La connaissance n'a pas de prix, elle devrait être libre.
Après que ce soit utopique.. d'accord.

Peut-être aussi:
Ne pas oublier de faire un 'make clean' ou un 'make-kpkg clean' (pour méthode debian) avant de compiler. Ne pas oublier de déplacer le repertoire des modules aussi avant d'installer le nouveau noyau. Jouer avec le modules insmod/ lsmod

Cela dit petite remarque personnelle sur URPMI.
Quand on est habitué à Debian, on ne peut pas s'empecher de penser que URPMI est vraiment pas au point. J'en ai fait l'expérience et je n'aime pas.
En plus, pour le calcul scientifique Mandrake c'est pas top au niveau des paquets. Soient il n'existent pas, soit ils sont à moitié installés (cf Gnu Scientific Library par exemple)

mefiez-vous des effets d'annonce... free n'est pas capable de fournir ses freebox, et en plus il promet la lune ;)

Et d'où ça sort cela? Rumeur de chez Wanadoo?

PREUVE:
J'ai un PIII 600Mhz avec une NvidiaTNT2
à 600Mhz ça plante jamais
à 716Mhz ça plante quasiment jamais
à environ 750Mhz je regarde pas la TV 15 minutes tranquille
à 800Mhz ça plante en 30 secondes.

Les cartes TV ne font pas bon ménage avec l'overclocking.

Je remarque qu'il faut aller pecher la news de plus en plus loin dans les archives...
Je ne connais pas bien. Mais j'ai surtout l'impression que l'on ne peut pas faire grand chose d'intéressant avec pour le moment. Se limiter à wrapper les routines de bases LAPACK/BLAS c'est assez léger pour une utilisation intensive. Des tas (enfin ... moins de dix quand même) de bibliothèques C++ le font déjà avec plus ou moins de succés.
Le minimum de fonctionnalités pour qu'un logiciel scientifique prenne de l'essort c'est >= GSL à mon avis. Sinon ça ne vaut pas le coup et personne n'acceptera d'investir du temps là dedans.

D'abord, le nouveau systeme d'archives de linuxfr est penible.
Ensuite flush ou lush on a le droit aux typos!
Plus sérieusement, le problème c'est que un matin je vais décider de commencer un projet avec gsl. Ensuite, le lendemain je m'aperçois que je dois utiliser une autre bibliothèque. et hop! je dois convertir toutes les vecteurs et matrices pour utiliser la nouvelle bibliothèque qui n'aura pas le m^eme format. Ca c'est vraiment pénible! Je ne comprends pas du tout la position qui consiste à dire que ce n'est pas un probleme. Pour moi, quand pour mon travail, ça l'est. Et si je veux faire de l'informatique de bas niveau, je ferai du C/C++, point, mais écrire un algorithme en C, ca prend du temps. Pourquoi les gens sont pret à payer 10kEUR une licence Matlab à votre avis?

Je veux que ce soit simple avant tout. et que je puisse écrire
y=A*x ou (* A x) peu importe mais que ce ne soit pas idx_machin1multmachin2transp puis gsl_matrix_mult, puis gsl_blas_dgemm. Voilà! Je suis pour "Un code simple et lisible"

Scilab est un langage à part (raison historique: avant c'etait un concurent propriétaire de matlab developpé par l'INRIA). Aujourd'hui Scilab est devenu libre parce que le retard accumulé par rapport à son concurrent est devnu trop grand et le logiciel était condamné à mourir sinon. Cela ne fait pas pour autant de Scilab un concurent sérieux à Matlab. Il vaudrait peut etre mieux privilégier des alternatives différentes et plus puissantes que Matlab. Flush semble avoir le potentiel et le lisp n'est pas trop difficile à apprendre. Malheureusement, après avoir examiné la question de près, il me semble que le choix des auteurs concernant la manipulation des matrices est douteux. Pourquoi passer par la notion de tenseurs pour multiplier deux matrices? De plus, il n'est pas clair que la mise en oeuvre garrantit des performances interessantes. Notamment il n'est pas précisé dans la présentation du logiciel que flush s'appuie sur des routines de type BLAS/ATLAS, ce qui pourrait être quand meme un argument vendeur. De plus, l'interface avec des matrices gsl me semble plus être une redondance qu'un atout. D'autant que gsl possède aussi a ce stade deux types de routines pour la manipulation de matrices (gsl natif et BLAS)

Bref que penser ?

Matlab c'est pas libre, c'est cher et c'est pas ideal pour tout. OK. Mais Scilab et Octave manquent de fonctionalités et cela freine enormement leur diffusion.
En plus, Scilab et un langage très différent de Matlab. Certaine fonctionalités comme les sorties graphiques ne sont pas faciles à utiliser (par rapport à Matlab). Les parametres des fonctions sont souvent alambiqués et jamais compatibles avec Matlab. Meme un truc bete comme la fft n'est pas compatible avec Matlab.
Personnellement c'est Scilab qui me fait ch... Si on utilise Matlab c'est quand même pour la simplicité. Octave, du fait de la compatibilité Matlab, j'aime mieux, mais ça manque de tout. C'est certainement bien pour les petits projets, genre, quand on a pas matlab sous la main.

Avec lush, on peut espérer que la comunauté scientifique developpe de chouets outils pour LUSH et que ça finisse par devenir aussi intéressant que Matlab.

Il est effectivement temps de remplacer Matlab. Or Scilab et Octave n'arrivent pas à la semelle de Matlab (désolé mais c'est quand même un peu vrai!). Lush me semble être vraiment capable de révolutionner la programmation scientifique. A tester absolument!

Je constate une nette amélioration des performances sur l'EPSON 2400 (par rapport au driver Sane) . Meilleure définition (c'est ça qui compte quand on scanne des diapos), autocalibration des couleurs de bonne qualité, meilleure prise en compte des caractéristiques hardware du scanner.

Ce driver est le bienvenu!

Dommage que le logiciel iscan soit un peu sommaire par rapport à xsane (il manque les histogrammes je crois)
Le chgt de driver se repercute aussi sur xsane qui propose de meilleure options mais iscan propose en plus une option unsharp (je crois qu'il aurait mieux valu écrire sharpen mais bon... l'anglais et les coréens...) qui améliore le rendu au delà de ce que l'on obtient dans Gimp.

A priori la nouvelle pouvait sembler enthousiasmente. Mais je me suis très vite arreté quand j'ai vu la phrase fatidique:
"Register for this tutorial"