Sytoka Modon a écrit 4558 commentaires

Pour en rajouter une couche sur debian que j'aime beaucoup, au dela de l'aspect mutli-plateforme bien connu, debian fait aussi un boulot peu connu sur le port d'autres noyaux, Hurd dans le temps (il me semble que c'est mort) et BSD de nos jours.

j'avoue que je rêve de pouvoir faire un jour la commande suivante

apt-get install bsd-kernel

Et hop, je change de système et je passe sur un coeur BSD... avec packet filter et tout ce qui va bien ;-)

Il parait que ce n'est pas possible pour le moment, trop de chose changent entre un coeur Linux et un coeur BSD.

Quelqu'un sais ou en est le port BSD et s'il y a un certaine coordination de prévu avec la sortie de Lenny ?

Non à ma connaissance mais c'est justement la que cela devient intéressant. Ton programme pourrait peut être se coupler à OCS un peu comme GLPI.

Justement, ssh enregistre les noms des machines dans le fichier known_host sous forme de hash dans les dernières versions (en fait, depuis quelques temps maintenant) justement pour ne pas donner à l'attaquant la possibilité de voir sur quelles machines la personne s'était connectée.

En fait, il y a pas mal de petit détail comme cela dans ssh pour divulger le moins d'information possible.

Historiquement, il faut un script du type expect pour donner son mot de passe a ssh car celui-ci a été conçu pour justement éviter de d'écrire son mot de passe dans un fichier ou sur la ligne de commande. Cela dis, rien n'interdit de faire un script expect. Je dois dire qu'expect dépanne bien dans certaines situations autre que ssh (installation automatique de logiciel propriétaire...)

A vu de nez, cela ne serait pas intéressant de fusionner cela dans OCS inventory ?

Peut être, il n'empêche que les Xscale avec le jeux d'instruction WMMX, c'est bien Intel qui les a fait.

Depuis, Intel a revendu sa partie ARM à Marvell et pousse sa stratégie x86 au maximum sur les plate-bande d'ARM avec l'ATOM.

Ceci dis, je ne suis pas sur que le monde ARM soit aussi complexe que le seul x86 ! Si tu rajoutes la partie AMD64, l'x86 a largement une longueur d'avance en terme de bordel. Si mes souvenirs sont bon, le x86 boote encore en 16bits au niveau du BIOS ?

Si l'alpha est mort, c'est que la puissance commercial n'a pas suivis. Ils n'ont pas été capable de produire des PC en grande quantité au même prix.

Je me souviens qu'en 98-99, l'Alpha était un grand espoir. J'en ai eu un entre les mains et c'était du bonheur. Mais on ne les trouvais plus ensuite ou alors a des prix défiant toute concurrence...

Si mes souvenirs sont bons, Windows tournait aussi sur Alpha (mais pas chez nous, on tournait déjà sous debian).

Des arguments de compatibilité sont donnés pour expliquer la force de l'x86, mais il y a encore peu, il y avait plus de processeur de la gamme ARM de fabriqué que de dérivée x86 ! Je n'ai pas les chiffres actuels.

Apple n'a pas arrêter de changer de processeur et est toujours là avec son OS qui monte, qui monte...

Le x86 arrive sur sa fin, le amd64 le remplace progressivement. Même s'il y a un mode compatible, pour moi, ce sont quand même deux processeurs différents, on le voit bien, c'est pas la même version de Linux, de Windows...

Donc, l'OS dominant Windows va être obligé de passer en grande série sur Windows64 et les éditeurs seront obligé de suivre. La compatibilité sera cassé comme elle l'a été entre Windows 3.11 et Windows 95. Et Windows 64 sera encore l'OS dominant car Linux n'a pas encore assez de part de marché pour renverser la tendance, l'échéance me semble trop proche.

Sinon, il y a comme dis plus bas l'Itanium d'Intel mais, pour en avoir une machine Itanium, il ne doit pas y avoir le dixième (centième) des moyens de l'amd64 sur l'Itanium. Si cela continue ainsi, l'Itanium va mourrir gentilement. A mon sens, Intel est en train de fusionner les deux gammes Itanium et amd64, le chipset sera commun, les cartes mères... On va pouvoir faire des vrais machines SMP avec de l'amd64. Je ne sais pas ce qu'il va rester à l'Itanium, le rôle d'un coprocesseur ?

Bref, le x86 a encore de l'avenir devant lui mais comme pour le 8086 avant lui, il sera la mais va doucement disparaitre pour laisser la place a l'amd64.

PS : comme debian, je préfère l'appellation amd64 a x86_64 car c'est une creation AMD et non Intel. L'appellation amd64 redonne donc a AMD ce qui est a AMD.

> Mais il n'utilise qu'un seul core [1], tout comme Mozart, Smalltalk et
> Scheme.

A priori, la machine Erlang est capable du multi-coeur depuis quelques années déjà (ele était mono coeur avant).

> Mon petit doit me dit que ce test crée plein de thread qui ne font
> quasiment rien. Du coup ce test test la rapidité de création de thread, et
> les implémentations purement userspace gagne haut la main car il n'y a
> pas tout l'overhead kernel...

On sais bien en utilisant la bibliothèque OpenMP qu'on a intérêt à lancer la boucle parallèle la plus large possible sur le code source, c'est à dire le plus tôt possible et de la fermer le plus tard possible. En effet, le lancement des threads est terrible en terme de performance.

On utilise donc des prama OpenMP de type singleton pour dire que certains passages ne sont pas à faire en parallèle. Cela permet de garder les threads ouvert mais qui ne font rien (sauf un) pour la suite du programme.

Un petit tour du coté d'OpenMP est aussi très intéressant pour comprendre une partie de la problématique.

Il est clair que si la conception du langage fait que le compilateur est capable de faire cela a notre place, c'est génial.

Mais aussi un de ses points faibles...

Le LISP est plus vieux que le Fortran mais sa syntaxe n'a pas réussi à percer pendant tout ce temps malgré son élégance.

Donc, c'est bien d'avoir un langage fonctionnel comme Erlang avec une autre syntaxe, cela explore d'autre voie de la sociologie humaine.

Enfin, Intel a peut être aussi intérêt a foutre le bordel dans l'ARM ?

Je suis d'accord avec toi mais il était bon de dire que Linux sais faire tourner des codes sur plus de 128 coeurs dès aujourd'hui.

Ensuite, il est clair que le mode de fonctionnement n'est pas exactement le même sur un bureau que sur une machine de calcul.

Je me suis mis il y a peu sur ce langage et il m'impressionne !

Les notions de base sont simples, tout est basé sur une notion d'objet immutable et sur de la récursivité. Tout passe par message ou presque. La gestion des erreurs est plutôt par processus indépendant (un calculateur / un superviseur).

En plus Erlang évite la syntaxe du LISP ou de CAMEL. Cela reste a mon sens bien plus clair pour quelqu'un qui vient du monde C / Fortran.

Bref, c'est étonnant qu'un langage ou on écrit

a = 2

a = 3 -> erreur

puisse être aussi performant.

Je vous conseille d'aller voir ce langage, rien que pour la culture générale, c'est passionant.

C'est marrant de voir qu'Ada95 qui est un des rares langages a avoir la notion de tache normalisé est aussi mauvais... C'est terrible de voir son score.

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.