karteum59 a écrit 876 commentaires

Des gens plus compétents que moi et très impliqués sur le sujet (au hasard, Keith Packard) ont conclu que le problème des sockets était un non-problème avec très peu d'overhead. L'overhead est ailleurs (apparemment, la nature de la XLib, ses appels bloquants et son caching inapproprié seraient davantage problématiques, d'où l'apparition de XCL/XCB). j'ajoute que sur une machine locale, il s'agit de sockets UNIX et que l'extension XSHM permet d'utiliser de la mémoire partagée (donc d'éviter les transfert que tu décris). Même les projets destinés à l'embarqué (comme feu PicoGUI ou les plus actuels Xynth/XFast) utilisent une architecture client/serveur comparable.

Par contre, j'ai tendance à être pas mal de l'avis de John Smirl (qui critiquait les efforts placés dans EXA dans la mesure où tous les chips actuels ont des capacités 3D, et qui préconisait +/- une couche d'abstraction 100% EGL/OpenGL à la place, surtout que les avancées d'OpenGL (shaders...) permettent d'imaginer des applications inconcevables par le passé, au hasard http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf ).

L'architecture de DirectFB 2.0 semble aussi s'orienter vers l'utilisation de backends (comme OpenVG) exploitant davantage l'accélération matérielle http://directfb.org/wiki/index.php/DirectFB_2.0:_Efficient_2(...)

celui-ci est plutôt sympa : http://www.ldlc.com/fiche/PB00063095.html (77€). Personnellement j'en ai trouvé un chez un fournisseur local à moins de 30€.
Y'a moyen de savoir où ? :)

celui-ci est plutôt sympa : http://www.ldlc.com/fiche/PB00063095.html (77€). Personnellement j'en ai trouvé un chez un fournisseur local à moins de 30€.
Y'a moyen de savoir où ? :)

http://billposer.org/Software/msort.html

le top reste d'utiliser un système de fichiers adapté répartissant les écritures
Normalement ça ne devrait rien changer car les CF devraient normalement intégrer la gestion du wear-levelling dans le hard (contrairement à une bête mémoire NAND sur un système embarqué, qui peut dans ce cas nécessiter l'emploi de JFFS2 ou équivalent).

Par contre, le wear-levelling ne fonctionne évidemment que s'il reste de l'espace disponible. Lorsque la carte est quasi-pleine, ça marche beaucoup moins bien...

J'ai eu la même idée, mais attention : Ce n'est gratuit que la 1e année (après c'est 6€ / an) ! Je ne dis pas que c'est très cher, mais simplement si c'est la gratuité qui t'a fait faire la démarche, pose-toi bien la question de savoir si tu comptes le garder (donc payer) après ou pas. Car si c'est juste pour jouer tant que c'est gratuit, alors évite de l'utiliser pour ton jabber/mail principal sinon tu vas en être dépendant (si tout le monde te contacte à cette adresse...).

La première dose est gratuite... :)

Deux petites choses :
- si tu payes ton rechargement via une carte bancaire, peut-on encore parler d'anonymat (vu qu'on peut tout à fait faire une corrélation entre n° de Navigo et n° de carte)... ?
- je crois que le Navigo Découverte ne marche pas avec les Vélib's

Tu trouves une doc sur le sujet ici :
http://linux-wizard.net/howto.php?section=1&key=urpmi_pa(...)

ne m'empêche pas de penser plus largement au logiciel libre et pas seulement à ma pomme

Joli... ;o)

Pour OpenOffice, soit, ils ne vont pas tout refaire maintenant.
Pour Abiword/KOffice, le support .doc était largement plus limité, et l'ouverture de ces documents est peut-être une bonne nouvelle pour pouvoir enfin se passer du lourdingue OpenOffice ! (surtout sur des vieux PCs retapés)

Le meilleur compromis alors c'est peut-être la LGPL, même pour les applis !

Avec la LGPL, je garantis que mon travail et ce qui en est dérivé reste libre, mais je n'impacte pas le choix des autres.

Avec la LGPL, je ne mets pas de limite technique à cause de choix politique (un autre exemple ? Tiens, suppose que je veuille expérimenter un noyau d'OS avec davantage de parties en user-space (sous forme de libs) et un micro-noyau tout petit. Je ne peux pas me baser sur Linux car autrement toutes les libs/applies qui se linkeront (par exemple) à ma lib qui gère le système de fichiers devront être sous GPL ! Aucun problème de cet ordre si tout était LGPL !)

Les devs BSD reconnaissent souvent eux-mêmes que la GPL leur pose problème, mais pas la LGPL... !

Par contre, je doute que les chipsets Intel puissent servir de copro pour du calcul scientifique, à l'instar des puces NViDIA
http://www.nvidia.com/object/cuda_home.html

C'est un peu hors-sujet, mais qqun sait-il pourquoi les distributions ne proposent jamais de rpm "différentiels" ? D'un binaire version n à sa version n+1, je suis sûr que la différence (via bsdiff, xdelta ou sdelta) doit être de taille minime, et pour upgrader ma Mandriva je préfèrerais de loin ne télécharger que la différence plutôt que les packages entiers (surtout pour des gros trucs comme KDE ou OpenOffice !)...
Peut-être qu'il y a une bonne raison de ne pas le faire ("patcher" via bsdiff a peut-être des inconvénients), mais pour l'instant je ne vois pas !

tu peux regarder du coté de BLAS, LAPACK

Heu ouais en fait je parlais de quelque chose de simple comme Matlab. BLAS, LAPACK ce n'est pas vraiment le même niveau de concision / lisibilité...
Dans Matlab (ou it++) je fais inv(H) pour avoir l'inverse de ma matrice. Je fais fft(x) pour calculer la FFT, je vais A*B pour le produit de matrices, etc. Bref, simple !

Pour certaines applications un peu plus spécifiques (traitement de signal / télécom), la bibliothèque it++ est faite pour simplifier la vie des gens qui connaissent Matlab (mais avec les avantages de la rapidité du C++). -> http://itpp.sourceforge.net/

Par contre, ayant très succinctement regardé le Fortran (95, pas 77), il m'a semblé que ce langage avait une syntaxe assez proche de Matlab, une gestion des tableaux très puissante, tout en étant compilé (même s'il n'y a pas de GC). QQ1 sait-il s'il existe une bibliothèque (libre) dans ce langage permettant d'avoir aisément les fonctions classiquement utilisées dans Matlab (FFT, plot, inversion de matrices...) ?

Par contre je trouve que ça le fait moins (voire pas du tout) sous windoze. De là à dire qu'ils n'ont testé que sous cet OS...

La taille de la page n'a pas forcément grand chose à voir : il suffit de quelques algos js mal conçus (une boucle infinie ne prend que quelques caractères à écrire... :)

Il y a longtemps, j'avais utilisé une bibliothèque (trouvée sur Freshmeat) appelée kiss_fft. Super simple et amplement suffisant pour les petits projets. Hors fftw (qui peut s'apparenter à prendre un marteau-piqueur pour en foncer un clou) Il y a une raison pour ne pas avoir copié/collé d'autres libs plus simples comme celle-ci ?

Ouais, c'est la fin des haricots ! :)

Qq1 a essayé TinyLDAP ?
http://www.fefe.de/tinyldap/

fslint est en effet excellent (et il y en a plein d'autres, à la finddupes, duper, dupefinder, etc.), mais ces programmes ne permettent pas de répondre de manière synthétique lorsqu'une arborescence complète est dupliquée (et impossible de modifier l'énorme pipe de fslint dans ce sens...). Ils ne permettent généralement pas non plus de renvoyer les doublons entre ton disque et des fichiers gravés sur CD/DVD.

<ma_vie>
Du coup j'avais écrit un petit programme (en C) capable de faire ça. Il faudra que je le release un de ces jours une fois que ce sera débuggé...
</ma_vie>

A propos de détecteur de fichiers dupliqués, cet article de Yann Guidon est aussi bien intéressant (comme toujours :)
http://f-cpu.seul.org/whygee/lm-gdups/article_gdups.html

Tu rompt avec tes amis pour de telles raisons toi ? Wow, et après les geeks se plaignent de ne pas avoir de vie sociale...

Sinon, ne te méprends pas : à titre personnel, je n'utilise presque que des logiciels libres. Mais il faut s'y faire : les logiciels propriétaires existent, et si qqun ou une boîte a envie de vivre de cette activité c'est son choix et il faut le respecter.

Donc, si un de mes potes trouve un logiciel proprio séduisant, ben il n'a qu'à l'achèter ou alors il contribue à un projet libre qui répondra à ses besoins, mais en tout cas il ne crache pas sur le type qui a bossé pour rendre son soft "séduisant" car c'est son choix de le laisser propriétaire !

Même si ce n'est plus libre, même si c'est triste, il y a toujours une différence énorme entre l'APL et celles du type Microsoft... (si tous les logiciels proprio avaient cette licence, au moins on ne serait plus enfermé avec des formats de fichiers et un code-source secrets...)

SI je me souviens bien, quand Kurt Skauen a arrêté de bosser sur son bébé et l'a confié à qqun (je sais plus comment il s'appelait), ce nouveau mainteneur a souhaité utiliser le noyau linux et focaliser Atheos proprement dit sur les couches supérieures.

Cette orientation n'a pas tellement plu à Skauen ni à la communauté. Le retour à une base 100% Atheos a donc été effectué par la suite, entretenant la confusion...

A l'époque (et ça doit être pareil aujourd'hui), le kernel Atheos était globalement en C pour les parties basses, et en C++ pour la couche graphique & les APIs. C'était assez propre et lisible. Je trouve dommage qu'il n'ait pas eu plus de succès. Il est surtout impressionnant qu'un homme seul (Kurt Skauen) ait réussi à atteindre ce niveau de fonctionnalités (il avait même réussi en peu de temps à adapter KHTML à ses APIs GUI Atheos pour son ABrowse...)

Qqun peut-il me dire pourquoi il ne serait pas possible d'utiliser la même base d'algorithmes de manière plus générique, à la fois pour le scheduler des processus, des IO, de la QoS réseau (tc), etc. ? Il existe déjà une pléthore d'algos (WFQ et autres), et il me semble (sauf erreur de ma part) qu'il y a de la similitude entre les problématiques de traffic shaping et de scheduling processus... Donc ne serait-il pas possible d'avoir une "libscheduler" dans le noyau qui puisse servir simultanément tout ça ?

Réciproquement, si je devais mettre en oeuvre un scheduler pour de la QoS réseau, est-il sensé d'imaginer copier-coller CFS de Ingo Molnar ? (ou un autre scheduler processus du noyau, mais je prends CFS pour exemple puisqu'il paraît qu'il est top :).

C'est toi qui a raison : on utilise tout notre cerveau, mais seulement 10% simultanément ! (et si ce n'était pas le cas, tu aurais probablement un petit problème : pour faire une analogie, tu imagines utiliser 100% de tes muscles simultanément ? Tu serais un peu emmerdé AMA... :)