ccomb a écrit 1325 commentaires

Ni le flash™, je suppose. Moi le flash ça m'énerve de plus en plus.
Les gars ne se posent même plus la question de l'opportunité de faire du flash ou non, ils le font par défaut, même si ça n'apporte rien. Ca m'énerve d'autant plus que je suis sûr que 90% des animations flash dans le monde sont faites avec un flash piraté ou en évaluation. Et le web est encore une fois en train de se faire monopoliser par une techno propriétaire contrôlée par une seule société. C'est ahurissant.

Tout ce qu'on gagne en ouverture/liberté d'un côté avec l'augmentation de part de marché de mozilla est perdu par l'augmentation du flash. Il devient vraiment urgent de proposer une alternative à base de SVG et autres. Ca pourrait partir d'inkscape, dont l'évolution est très rapide, mais pas suffisante pour espérer un support de l'animation avant 2 ans.

En tout cas, avec bientôt 20% de mozilla, on va enfin pouvoir mettre des PNG transparents partout... C'est au moins ça.

[fin du hors sujet d'énervement]

En quoi le fait que quelqu'un puisse vendre ton programme te gêne ?

La personne ou l'entreprise qui vent ton programme ne pourra de toute façon pas le vendre à un prix énorme, puisqu'on pourra le trouver gratuitement ailleurs.
Et le fait de le vendre permet, grâce aux gains, d'en faire de la pub et de le faire connaitre plus largement. Je trouve que ce serait intéressant, justement.

Si les logiciels libres étaient vendus plus souvent , ils pourraient concurrencer beaucoup plus vite les logiciels proprios.

Il semble exister un vieux driver OSS :
http://www.linuxant.com/drivers/riptide/index.php(...)

Le probleme est que les drivers par défaut sont maintenant des drivers ALSA,
et personne ne semble s'être donné la peine de porter le driver pour ALSA.
Donc il faut essayer de le faire marcher en OSS.
Si tu es débutant, tu risques de galérer, essaye de trouver quelqu'un qui puisse te le faire.
Si tu as un peu de courage :
installation : http://www.linuxant.com/drivers/riptide/install.php(...)
Les drivers précompilés disponibles sont pour le noyau 2.4, donc il faut les compiler soi-même, car sur la mdk10, c'est du 2.6...
Et ils n'ont probablement pas été portés pour le noyau 2.6, d'ailleurs.

Donc tu peux toujours essayer de compiler ça :
http://www.linuxant.com/drivers/riptide/archive/riptide-0.6lnxtbeta(...)
(en lisant tous les fichiers texte README, INSTALL, etc...)
Et tu devras aussi passer en noyau 2.4

Résumé :

C'est la galère, et tu perdras moins de temps à essayer de trouver une carte son un peu plus standard et qui possède de bons drivers ALSA.

Pour la bonne cause, tu devrais envoyer un mail au fabricant en lui demandant de faire un bon driver (libre) pour linux, et/ou de publier les specs complètes de
son matériel afin que quelqu'un puisse le faire à leur place.

Et quand un truc explose... après il n'y a plus rien !
Donc finalement un prix explosif, c'est un prix nul. muahaha.

N'oublions tout de même pas http://www.opencascade.org(...)
(même si ça me parait pas compatible avec la GPL)

On peut voir une présentation flash-c'est-mal™ ici : http://ezaurus.com/(...)

Je le veuuuux.

Euh, Blender n'était utilisé qu'en milieu professionnel, c'est un logiciel professionnel de naissance. Ça s'est ressenti au moment où il a été libéré, car son interface n'était vraiment pas facile à prendre en main comme peut l'être un logiciel grand public. C'était un peu le vi de la 3D. Les progrès sont tellement gros que maintenant il suffit de 2h de tutoriel pour s'en sortir un minimum.
Voir l'historique : http://www.blender.org/modules/documentation/htmlI/x115.html(...)

Et pour en être vraiment sûr, il suffit de voir la galerie :
http://www.blender3d.org/cms/Gallery.55.0.html(...)

XMMS (que tout le monde a certainement dû laisser tomber depuis des lustres, ou alors ils devraient y penser)

Je suis prêt à changer si tu me trouve un player qui puisse faire du crossfade + pitchshift + timeshift.

Amusant, moi, sur cooker, j'ai deja eu ma carte wifi qui a grillé ( réparé en réinstallant la carte sous xp ), j'était dans l'impossibilité de lancer OpenOffice pendant 2 jours, j'ai un kde énorme compilé avec des symboles de debug pour aider au debug, et je passe mon temps sur une distro qui par définition n'est pas fini, donc, tu m'excuseras, on doit pas avoir la même cooker.

Amusant, moi, sur Debian/Sid, j'ai jamais eu aucun problème grave, et je suis même prévenu automatiquement, avant la mise à jour, des problèmes graves potentiels.
(c'était juste pour recatapulter le troll.)

Néanmoins, lorsqu'on retire un périphérique encore monté, on se retrouve vite dans des situations foireuses, où on ne peut plus démonter, où les données sont perdues, où le module ou le port usb finit parfois même par se bloquer, et ce n'est pas tolérable.
S'il n'y a pas d'option sync au montage, il faut afficher des fenêtres d'information claires pour dire qu'il faut penser à démonter (ou éjecter, ou détacher...) le périphérique. Et si par mégarde on le retire quand même, il faudrait mettre un gros warning à l'écran puis laisser la possibilité de le rebrancher immédiatement afin de le démonter proprement, et que tout se passe bien ensuite.

Dernièrement, j'ai testé le script "bench de clé USB" (...) et j'ai franchement été décu de ma RH FC1.

Attention, ce n'est pas un problème de distrib. Tout le monde a les mêmes perfs de merde avec ce script. C'est juste parce que le montage est fait en mode "sync", et que pour les clefs USB ça divise les perfs d'écriture par 10 ou 20.

C'est dommage parce que le mode sync est une sécurité pour pas mal de gens, surtout pour les périphériques amovibles. Il faudrait que le noyau soit capable de déterminer tout seul le bon I/O blocksize, ou de prendre en compte l'option de montage -o blocksize pour la fat. Ou bien il faudrait modifier "cp" pour qu'il choisisse lui-même ce I/O blocksize.

Merci,
c'est ce que j'avais commencé à comprendre ici : https://linuxfr.org/comments/492203.html#492203(...)

Mais est-ce que le noyau ne pourrait pas déterminer automatiquement ce ioblocksize ? Par exemple en prenant d'abord 512 puis en doublant jusqu'à obtenir le meilleur taux ?
Ou sinon, il devrait prendre automatiquement ce qui a été spécifié lors du montage avec l'option -o blocksize, mais il n'en tient pas compte.

Ca doit être possible en créant un répertoire représentant la clef usb, puis en effectuant une synchro avec unison soit manuellement avec unison-gtk, soit automatiquement avec une ligne de commande unison via un script hotplug ou udev.
Dans ce cas il faudrait trouver un moyen de limiter automatiquement la taille du répertoire. (sans devoir créer une partition pour ça)

pour info, voir aussi ça : http://bugzilla.kernel.org/show_bug.cgi?id=2119(...)

C'est pas bourré de pubs, msn ?

(Je sais pas, j'ai jamais essayé, et les gens qui veulent me joindre ont appris à utiliser jabber via gaim)

Dans ton cas, le meilleur ioblocksize n'est pas 65ko, mais 512ko.

Bon, tout ça prouve bien une chose : le mode "sync" n'est pas du tout adapté aux clefs usb, alors que ce serait le type de périphérique pour lequel ce serait le plus pratique. (Débranchement intempestifs)

Il faudrait une option de montage qui permette de dire au noyau de prendre un ioblocksize égal à la taille du fichier à transmettre. Ou bien qu'il le fasse tout seul.
Ou bien qu'il commence par sa valeur par défaut puis qu'il augmente tout seul le ioblocksize pour trouver l'optimal.

J'ai le meme probleme sur tous les noyaux, sauf 2.4.22 à 2.4.26.
Tous les 2.6 et les 2.4<=.21 ont le probleme.
(voir le rapport de bogue)

ok, donc il vaut mieux mettre ça :
filesize=`ls -s $infile |awk '{print $1}'`

J'ai l'impression qu'il calcule le ioblocksize en fonction de la partition.
Quand je formatte en FAT32, j'obtiens, 512
en FAT16 2048, et en FAT12 (oui en FAT12 !:) 32768

Mais si je force le ioblocksize à 65536 avec dd sur une FAT12, je monte à un taux de 450ko/s ce qui est le maximum que j'ai vu avec mon i-stick.

il ne calcule pas correctement la variable $filesize.
Que donne :
ls -s /bin/bash |cut -d' ' -f1
?

Tant qu'on est parti dans le HS, j'ai aussi un blocage de carte réseau, mais sur PCI, qui n'arrive pas à dépasser 20ko/s lors d'un transfert avec SSH.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245398(...)

J'y ai passé plusieurs dizaines d'heures pour l'instant, mais rien n'est résolu.

Reessaye avec
sh -x usb-storage-benchmark.sh

Je ne sais pas quel est le patch inclus dans le noyau Debian, mais en tout cas l'option sync change beaucoup de choses !

Ca ce serait l'idéal, mais ça ne marche pas.

Y'a des gens qui confondent les Logical Sectors (la taille des secteurs sur le disque) avec les IO Blocks (la taille des blocks transférés vers le disque)...