Sytoka Modon a écrit 4546 commentaires

Enfin, Linux gère 4096 coeurs... Je sais que SGI a fait une machine SMP a plus de 1024 coeur qui marche.

Au dela de 1024 ceurs, il faut aussi que les codes tournent... mais bon, j'ai vu un 'vrai' code tourner sur plus de 10000 coeurs en restant efficace. Cela fait plaisir de voir que cela marche. La limite n'est pas encore la.

On sais tous que le x86 a gagné grace à l'argent d'intel et non pour ses propriétés intrinsèques. Si tu avais le même pognon dans le 6502, on serait tous équipés de 6502 aujourd'hui ;-)

Ensuite, on bosse pour la plupart sur x86 et on est bien content qu'il marche bien. C'est pas pour cela qu'il faut le bénir.

J'ai fait très peu d'assembleur mais le x86 était déjà une horreur. J'espère que le x86_64 est mieux.

Et il gère les "layers" ?

Parce que par derrière, ils utilisent tous plus ou moins la même bibliothèque...

Moi j'aime bien xpdf, facile à tapper dans un terminal, rapide au lancement, pas trop de dépendance, pas de kdeinit... pas de gconfd... pas tout un tas de service qui ne servent à rien et qui vont à l'encontre de la philosophie UNIX.

Et puis, j'aime bien l'IHM de xpdf, sobre et sans menu inutile.

Bref, je ne suis pas fanat des IHM moderne, toute pareille et pas forcément adapté au type du document. Par exemple, je ne trouve pas meilleur lecteur postscript que gv. Les trucs intégrés à gnome ou à kde sont à mon sens bien moins pratique.

Justement, il manque un comparatif.

Je me souviens avoir eu un docuement PDF entre les mains dans une réponse a un appel d'offre. J'utilise en temps normal xpdf mais justement, au niveau d'une image, il devait y avoir une "layer" et j'avais l'ancienne version de l'image ! Bref, j'ai gueulé que le document était faux alors que c'était xpdf qui avait tord...

En effet, avec acroread, aucun soucis.

Bref, les autres lecteurs qu'Acrobat, c'est bien mais il faut en connaitre les limites. Or sur cette page, comme l'ont dis d'autres, il y a de tout et du pas bon mais en plus, on ne sais rien de ce que savent faire ces logiciels et il y a 36 versions du format PDF.

Site a oublier tant qu'un gros travail n'est pas réalisé dessus. Désolé.

Je viens de jeter un coup d'oeil a Perl et notament vers les modules Inline. pas vu de Inline::SQL par contre on a les

Inline::Java
Inline::Python
Inline::Ruby
....

Je n'ai jamais utilisé en pratique mais c'est bien dans la philosphie Perl de mettre de la glue dans tous les sens.

Il est clair que les GOTO ne sont pas un plus pour l'analyse de flot. Il est vrai que dans les block a iterator de Sather, le premier iterator qui finit termine le block et finit tous les autres iterators du block. C'est pas un comportement classique (ajoute le paradigme 'one' à l'appel d'un iterators (ce qui prouve que ce n'est pas une méthode)) et montre que ce concept de block iterator est différents de l'approche objet classique.

Sinon, en gros, si je comprends bien COP, c'est un peu SCOOP mais adapté au concept de la programmation par prototype. C'est génial lorsque cela marchera car après avoir lu Meyer, on était vachement frustré de ne pouvoir essayer pour de vrai.

Sinon, je te conseille de regarder du coté d'Erlang pour la gestion des erreurs. C'est très intéressant et vraiment différents de ce que font les autres et en plus dans une philosophie multi-coeur. Avec ton COP, cela pouvoir s'intégrer vu le peu que je devine.

Ensuite, question timing... On est tous un peu surchargé et c'est pas la tendance ministerielle actuelle qui va changer la donne ;-( C'est dommage qu'il n'y ai pas plus de moyen humains sur ce projet.

J'ai cru comprendre que le code C généré par Lisaac était ... imbitable mais que cela n'avait pas d'importance parce que pas destiné a être lu par l'homme. Alors je ne comprends pas trop ce qui gène de mettre des GOTO la dedans. Un GOTO n'a rien en bas niveau, d'ailleurs, en assembleur, il y en a plein ;-)

Je ne me souviens plus exactement mais COP, c'est le truc de Meyer pour faire du parallèle ? Je suis surpris si c'est cela que ce modèle soi disant génial (je suis incapable de juger s'il est bien ou non dans l'absolu, pas assez de recul la dessus) ne soit toujours pas implémenté.

Je pense que les langages qui font tout pour favoriser un parallélisme simple et qui marche seront de plus en plus utilisé dans le futur. Avec l'augmentation du nombre de coeur, il faut clairement un langage parallèle dans son âme (un peu comme Erlang). C'est d'ailleurs ce qui m'inquiète avec Perl6 car j'aime beaucoup Perl et je n'ai pas l'impression que l'aspect parallèlisation ait été au coeur de la conception du nouveau langage.

Justement, les foreach de Perl sont super clair et on sais que les boucles sont une source énorme de bogue. Donc question : quand est-ce que vous implémentez les iterators à la Sather dans Lisaac, pas les Iterators tout mauvais des autres langages ?

Sinon, comme je l'ai dis dans un autre post, je me suis mis a essayer Erlang et il y a des concepts vraiment intéressants à reprendre même si je ne suis pas sur que cela soit facile de placer cela dans un langage procédural. En fait, Erlang, c'est presque le symétrique du Fortran ;-)

> Maintenant, qqsoit le language on peut écrire cradement (c'est moins vrai
> pour le python ;-). ça on est d'accord ...

Ben je suis désolé mais je n'y comprends rien en Python. J'ai même du balancé un site web en Zoppe pour faire du SPIP car Python me gonflait plus que la normale, et pourtant je déteste le PHP qui n'aurait jamais du exister car c'était du sous perl.

Non, le Python n'est pas mieux que les autres, il a ses fans mais il a aussi des inconvénients comme les autres.

Pour me changer les idées, je me suis mis à Erlang et là au moins, on change de perspective. C'est amusant.

Si Sather implémentait le retour multiple sans définir de type à l'aide de tuple. C'est exactement ce que tu as écrit (a la syntaxe type Eiffell près).

D'ailleurs, c'est marrant, dès qu'on parle Lissac ici, je sors mon Sather;-)

Faut arrêter de dire que le Perl est incompréhensible !

Je ne comprends rien aux programmes Java avec leur millions de lignes, leur millions de classe, les fichiers de conf XML de Tomcat ;-)

J'ai travaillé avec pas mal de personne qui n'avait jamais fait de Perl, qui n'en pensait que du mal mais qui avait fait du PHP ! Et bien, tous ont compris de suite les programmes ! Evidement, il y a quelques règles à respecter pour avoir du Perl lisible mais c'est pareil dans tous les langages.

Sinon, il y a des milliers de modules sur le CPAN et la doc est très claire pour les utiliser. Je n'ai pas vraiment de soucis avec les paramètres.

Au niveau objet, je ne sais pas pourquoi le mot clef 'class' n'a pas été intégré pour faire plaisir aux gens. A mon avis, c'est pas si difficile à faire pour les bons programmeurs Perl. Mais pour les gens comme moi, on peut déjà utiliser Moose ou Mouse et c'est pas plus dur que de faire une classe en Java.

NTFS fragmente à mort !

Tu installes un Windows XP sur une partition de 15Go, tu fais les mises à jour et tu regardes la fragmentation, c'est lamentable... pour une machine qui n'a même pas encore servit en production.

Rien n'empêche de ne faire qu'une écriture. Option 'secure-delete=1' par exemple. Et puis, il peut mettre des zéro ou des chiffres aléatoire... Encore une fois, je pense que déléguer cette tâche a un processus parallèle asynchrone me semble une bonne idée.

> Par nature le copy-on-write defait toute stratégie d'effacement sécurisé
> puisque les blocs ne sont pas écrasés mais réécrits à côté.

Je ne vois pas ou est le problème...

Pour vraiment effacer les données, il faut ré-écrire dessus un certain nombre de fois et non une seule fois.

Rien n'empêche d'écrire le fihcier n+1 sur l'ancien fichier n.

Mieux encore, rien n'empêche d'avoir une option de montage, du style 'secure-delete' qui écrirait dans un journal tous les block qui ne servent plus et qu'un processus parallèle de BtrFS s'occuperait en tâche de fond d'effacer entre 4 et 7 fois avec des données aléatoires.

Bref, je ne vois pas ou est la sécurité de ré-écrire au même endroit.

Au contraire, je t'ai préparé le sommaire ! Y-a plus qu'a remplir les blancs...

Pas forcément. comme BtrFS a un notion du bloc (les autres système de fichier aussi), alors il ne copiera que les blocks modifiés mais pas l'ensemble du fichier.

C'est exactement ce que fait LVM lors d'un snapshot.

C'est finit, le 2.6.29 basule en mode deboguage, Linus a annoncé cela.

http://lwn.net/Articles/314471/

Au bilan, les trois grands apport de cette version seront

* squashfs : un système de fichier compressé en lecture seule

* Btrfs (en mode développement, pas pour l'utilisateur lambda)

* Les "modes settings" pour les cartes graphiques Intel (chose que faisait avant X-Window et qui bascule petit à petit dans le noyau).

> Le site oss.oracle.com est entièrement down pour le moment, désolé, voici une version
> en cache :

Pas de pot, je fais une dépêche la dessus et leur site est HS depuis déjà un bout de temps. Idem tout à l'heure, je n'ai pas pu mettre la référence de la partie réseau associé BtrFS.

A mon avis, on est trop nombreux à vouloir y aller ! DLFP a trop de succés !

Au niveau des formules, j'ai lu un support MathML. En pratique, cela marche comment ? Il faut se farcir le MathML ou on peut tapper en LaTeX les formules ?

Je pose cette question car on a un certain nombre de document collaboratif à réaliser mais il y a toujours plein de formule a intégrer dedans.

> btrfs permet de faire des snapshots d'un répertoire quelconque du
> système de fichier

Cette fonctionalité est géniale car elle va permette de faire des sauvegardes à cout CPU quasi nul. Il va être très facile de programmer des retours arrières pour tout un tas d'opération (upgrade de système par exemple). Cette fonctionalité va de paire avec le snashot de snapshot. Les possibilités sont énormes.

> Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur
> Wikipédia

Je ne sais pas si Patrick a écrit la version anglaise sur Wikipedia. Je suis partis sur cette version la car je savais que pas mal de personne sauterais sur la version Française de wikpedia. Ainsi le débat n'est en que plus animé, la version anglaise étant assez différente de la version française.

Au niveau de la séparation avec la couche LVM et le fait que cette séparation ne soit pas effective, je trouve cela dommage. J'aurais préféré que le système LVM et le device-mapper soient étendus afin de pouvoir répondre aux questions existentielles des systèmes de fichier.

Sinon, je n'y connais rien en système de fichier, j'essaye juste d'être un utilisateur avertis ;-)

Sinon, il y a une "extension" a BrtFS qui me semble aussi intéressante : CRFS (Coherent Remote File System), Il s'agit en fait d'une couche réseau pour accéder au système de fichier à distance. A suivre... car je ne sais pas ce que cela apporte par rapport a du NFSv4 ou du parrallèle NFS. En tout cas, il est bien préciser que CRFS se base sur les fonctionalités de BtrFS.

J'ai utilisé il y a longtemps LilyPond et c'était très bien, très propre pour ce que j'en faisais.

Depuis quelques temps, je me suis mis à l'accordéon diatonique et on fonctionne (on est plusieurs) par tablature. D'ailleurs, je trouve cela très bien car on travaille plus sur le rythme que savoir si c'est un LA ou un DO !

Bref, à par tabledit qui n'est pas libre et qui ne tourne pas sous Linux, je n'ai rien trouver pour faire des tablatures de type diato et c'est très dommage.

Du coté de LilyPond, j'ai vu passer un patch sur le sujet mais pas intégré dans le main du programme et maintenant assez agé.

Question : LilyPond se spécialise-t-il sur la "grande" musique ou certains développeurs seraient intéressé par la musique plus traditionnelle (folk) ?

Je n'ai pas essayer G'MIC mais le traitement d'un photo numérique d'un 5M de pixel avec GREYStoration prend plusieurs minutes sur mon P4 2,5GHz...

Il faut donc voir les points suivants :

- combien de temps est perdus dans le chargement déchargement dans G'MIC

- combien de temps je passe à interfacé mon code C++ (G'MIC) avec le code C (Gimp), sachant que le C++ et le C ne font pas toujours bon ménage si on commence à trop vouloir mélanger...

- combien de temps je vais gagner à passer par des appels système ?

- combien de temps mon algorithme de calcul pourra être réduit dans le futur.

Dans les cas de calculs longs avec des temps de transfert court et s'il n'y a pas a court terme de moyen de diminuer le temps de calcul, le passage par pipe est une bonne solution alliant souplesse, modularité, indépendance, maintenance.

Dans mon cas à moi, le code était en fortran 90, le post-traitement en C++ et l'hyperviseur en Perl. Faire parler tout cela via des pipes m'a permis d'avoir une grande souplesse de développement, de perdre des poullièmes de secondes et d'avoir des modules complémentement indépendant tant que le langage dans le pipe suivait une certaine convention.

Je crois qu'avec G'MIC, on est aussi dans cette problématique pour le moment. Rien n'empêche une fois que tout marche bien et que c'est utilisé par pleins de personne, de remplacer les pipes par des appels à des bibliothèques standardisés.

J'ai fait du calcul de structure ou le temps de calcul est long sur le temps de chargement de fichier. Dans ce type de problème, passer les données par des pipes est très pratique pour les raisons suivantes :

- chaque programe est indépendant. Il est plus facile a débogguer

- les programmes peuvent dans des langages différents

- il est facile de remplacer les pipes par des netcat et d'avoir une couche réseau...

Avec un peu de Perl, on arrive ainsi a faire des choses vraiment intéressante qui n'était pas du tout prévu par les différents programmes à la base. Par exemple, j'avais fait un hyperviseur en Perl qui me pilotait le programme de calcul ainsi que le post-traitement. Ainsi, je récupérait les images en cours de calcul pour monter un petit film, le tout sans garder un seul résultat intermédiaire et en modifiant quasiment que très peu les programmes originels.

Et puis, c'est chown -R apache:apache

Les utilisateurs ont le droit d'avoir un . dans leur login, il faut prendre l'habiture de mettre : dans la commande chown.

> Ceci dit je ne suis pas sur de vouloir poursuivre un opérateur qui par
> ailleurs me rend de grands services...

Nous savons tous qu'il y a du Linux la dedans et au niveau de la gestion des réseaux, cela ne va pas aller en diminuant.

Moi, je trouve cette procédure très bien. Free est pris en exemple car ils ont été le fer de lance de ce procédé. Si Free est condanné, je ne suis pas inquiet, les autres devront changer rapidement de méthode ou se voir eux-aussi inlfiger un procès.

Ce n'est pas parce que free rend bien des services que l'on doit fermer les yeux. Et comme d'autres l'ont dis, il n'y a rien dans une freebox aujourd'hui que les autres opérateurs ne sachent pas. Donc ici, cacher l'information n'a de sens que pour mettre l'utilisateur final dans l'opacité du fonctionnement des réseaux ADSL. Ce n'est pas bon.