Sytoka Modon a écrit 4586 commentaires

Surtout, il faut tester btrfs et zfs sur plusieurs mois car ce sont des systèmes de fichier qui ralentissent petit à petit. Un test brut comme ça ne veut pas dire grand chose sur ce genre de système COW.

Le propre de la justice, c'est justement la prescription. C'est un des fondements de celle-ci et c'est très important.

De nos jours, on se crois trop fort et on voudrait limiter celle-ci et en reporter la date comme pour le droit d'auteur (cf mickey). C'est une énorme erreur.

Seuls les crimes contre l'humanité n'ont pas de prescription. Et encore, je trouve (mais ne suis pas spécialiste) que cette notion de crime contre l'humanité à tendance a s'élargir avec le temps.

XFS est employé quasiment systématiquement sur toutes les grosses partitions. Il marche très bien et malgré de très nombreuse panne électrique, je n'ai jamais perdu une donnée sur mes baies de disque en RAID.

A ma connaissance, quasiment toutes les partitions de plus de 5To sont en XFS dans le monde professionnel.

Encore une victoire pour Debian GNU/Linux, première distribution GNU/Linux loin devant Redhat, mais tout aussi loin devant SuSE ;-)

C'est pas Moode mais Moose.

Sinon, tu es en train de me dire que tu préfères les langages qui ont plusieurs paradigmes pour faire de l'objet en fonction de ce que tu es en train de faire ? Si oui, Perl5 est donc parfait pour toi ;-)

Par ailleurs, il y a Mouse qui est un Moose simplifié mais il n'est plus trop recommandé. Les personnes de Perl travaillent beaucoup sur Moose et sur son optimisation. A moins d'une application critique en terme de temps, Moose parait aujourd'hui le meilleur choix.

Si cela ne te convient toujours pas, il y a plein d'autres systèmes objets sur le CPAN...

C'est stable maintenant ? J'avais essayé au début lors des annonces ici mais chez moi, ça plantait rapidement.

Perso, je suis sous wmii qui a le défaut de ne pas se souvenir de la position des fenêtres à la fermeture / plantage mais sinon, je le trouve très bien et j'adore sa manière d'empiler les fenêtres en pile. Très pratique lorsqu'on a comme moi toujours un gros paquet de terminaux.

La partie fenêtre flottante est un peu léger mais ça fonctionne quand même. Généralement, on met ce genre de fenêtre par application dans un bureau spécial (le 3 ou le 4 chez moi).

Bref, je trouve wmii souple et pratique sans être "chiant" comme certains wm lorsqu'on les prends en main au début.

Tout à fait d'accord avec toi, et dans un langage comme Eiffel, la programmation par contrat pousse encore plus loin la logique des langages à typage statique. En effet, pourquoi s'arrêter en si bon chemin ;-)

Tout cela me fait penser à l'Extreme programming qui place les tests dans le coeur de la méthode.

Moose, c'est du Perl5 ;-)

Tu es un ralleur jamais content. Je te montre que Perl est un langage souple qui sais se modifier dans la continuité pour adopter des manières de programmer très puissantes que tu ne trouves pas forcément dans le système objet des autres langages qui commencent eux aussi à se faire vieux... mais tu préfères rester sur ton langage pour une raison bidon, surtout que la paradigme objet est dans Perl5, certes il est un peu bizarre et peu blesser certain.

Une chose assez sympa est la rencontre de Moose et de POE, cela donne de la programmation événementielle objet : MooseX::POE

http://search.cpan.org/~getty/MooseX-POE-0.210/lib/MooseX/PO(...)

Il me semble aussi mais code en Ada ne veut pas dire non plus code sans erreur ;-)

Justement, si tu ne sais pas, c'est que tu n'y connais rien en Perl Moderne et donc tu bases tes critiques sur du vécu lointain...

Moose est le framework Perl conseillé aujourd'hui pour faire de l'objet et les développeurs ont vu les choses en grand et en plus, cela reste compatible avec Perl 5 !

http://www.iinteractive.com/moose/

> ya que le Perl objet qui est imbitable et qui n'aurait jamais du exister

Tu as regardé du coté de Moose ?

Je ne trouve pas personnellement le code Python ou Ruby particulièrement lisible, voila pour une partie de ma réponse.

Ensuite ta comparaison sur les voitures est intéressante, j'en conclue que Perl est la Mercedes et Ruby la 2CV ;-)

Exact, j'ai des amis chercheurs qui enregistrent des sessions de travail afin d'analyser cela avec des sociologues et essayer de comprendre ce qui se passe et surtout détecter les points clefs qui amène à l'innovation.

Ils travaillent avec de la HD et des systèmes pour mettre 4 films en 1 afin d'avoir un aperçu de toute la(les) scènes. Malgré cela, c'est jamais assez précis...

Je pense que c'est un outil qui dans ce cadre de l'observation du comportement sur des personnes qui sont évidement de plein grès dans l'expérience, cela peut être intéressant.

Tu connais le Perl Moderne ?

Quelque soit le langage, il est assez facile d'écrire du code incompréhensible... Perl est un langage qui évolue régulièrement et en 10 ans, la manière de programmer est devenue très différente.

Un petit exemple que j'ai vu passer il n'y a pas longtemps. L'objectif est de piloter mpd depuis une interface web écrite avec dancer. C'est pas un exemple archi-compliqué mais c'est intéressant à voir à mon sens.

http://blog.preshweb.co.uk/2010/11/dancerjukebox-music-queui(...)

https://github.com/bigpresh/DancerJukebox

Justement, je voudrais pouvoir virer la couche samba...

C'est que notre ami Pierre n'est plus tout jeune ;-)

Tu peux mais personnellement, je lance un script avec les classes de cfengine en option via cfengine. C'est un script que j'ai bidouillé à partir d'un script développé par Steve Kemp pour debian.

Le problème que j'ai eu la version intégré dans cfengine, c'était trop verbeux et surtout, dès qu'il y avait trop de paquet à installer, ça plantait pour un histoire de longueur de ligne si je me souviens bien...

Sous Linux, je déploie avec cfengine qui est bien plus souple ;-)

Chez nous, la fonction première de l'agent OCS est de déploiement ;-) Le projet FusionInventory est très bien mais c'est surtout la partie agent d'installation qui m'intéresse le plus...

La manière qu'à OCS pour déployer un paquet est génial, découper en petit morceau de manière automatique, le client récupère tout cela via http en prenant son temps, tout simplement génial et bien mieux que tout le reste ou malheureusement, cela passe trop souvent par un partage samba ;-(

Pour Pulse2, ma remarque est que je ne connais personne l'ayant utilisé et je ne sais pas s'il est utilisé ailleurs que sur un serveur Mandriva. C'est tout.

L'agent OCS fait deux choses : remonté de l'inventaire et déployer un logiciel. Il fait donc deux choses.

Ce qui n'est pas bien. Si l'installation plante, le code retour n'est pas toujours bon. Donc parfois OCS dis que le logiciel est déployé mais en fait non. Si on veut de nouveau l'installer, il faut aller effacer la ligne avec le timestamp du logiciel dans le fichier history... Un peu nul. On devrait avoir une option pour forcer une ré-installation sans avoir à refaire un nouveau paquet identique !

Autre chose pas terrible, pas possible d'installer un logiciel toutes les x fois, chose que fait très bien cfengine. Par exemple, un logiciel est en pratique un bête script qui bidouille trois clefs de registre pour forcer des sécurités. On veut les ré-appliqué toutes les deux heures par sécurité. Impossible avec OCS puisqu'il n'installe le logiciel qu'une fois. Faut passer ensuite pas la commande AT mais la gestion de celle-ci est un peu pourris.

Dans le même esprit, on pourrait lancé un nettoyage via CCleaner ou une défragmentation régulière...

En fait, il y a presque tout dans l'agent pour faire cela.

Autre chose avec OCS, la commande que tu lances ouvres une invite de commande... J'ai pas trouvé de solution pour avoir un truc 100% silencieux qui marche sur tous les postes sauf à mettre en tout début de script .bat la commande cmdow.exe (et penser à rajouter cette commande dans les exceptions des anti-virus).

J'ai regardé du coté d'OPSI mais tu deviens très dépendant de lui...

Comment on fonctionne avec OCS, on fait des zip qui ont tout dedans et surtout un script install.bat. L'idée est que l'installation via OCS ou à la main est la plus proche possible. OCS lance install.bat qui fait toute la suite. Les choses sont donc bien distinctes et simple à maintenir. Et puis, on peux diffuser les paquets zip même aux personnes qui ne sont pas gérer par OCS, ou on peut remplacer OCS par un autre système à terme.

blablablabla... cf guerre des Malouines !

Justement, je cherche un script pour installer une imprimante en IPP (ou HTTP) en mode silencieux.

Il y a aussi pour gérer un parc

- OCS Inventory : marche mais est un peu limité je trouve

- OPSI : a l'air de tout faire

- Pulse2 : un peu trop Mandriva mais je n'en sais pas plus

- WPKG : basique comme OCS

Ces systèmes me semblent basés sur des clients agents assez basique et ne reprennent pas malheureusement la stratégie de cfengine. Du coup, ça fait des gros serveurs compliqué...

J'avoue que j'aime bien cfengine qui fonctionne en deux étapes :

- 1 - synchronise une base de fichier (ensemble de règles, fichiers...)

- 2 - on applique en fonction de classe un ensemble de règle sur la version locale de la base

C'est très robuste aux pannes réseaux et tout peut être découpé en morceaux plus petits. Vraiment très très efficace.

J'ai mis 10000 mais on aurait pu mettre autre chose, c'est juste pour dire qu'on n'utilise pas 100% de la machine. Pas mal de code MPI ont du mal au delà de 1000 (source SGI d'il y a quelques années), on a un code qui fonctionne avec 2000 coeurs mais son efficacité est moindre et aller au delà n'est pas forcément "rentable". En effet, on n'a pas non plus un nombre d'heure illimité et comme tu payes (sur tes crédits d'heures) à la minute par coeur, plus tu prends de coeur, plus ton compteur descend vite vers zéro !

Comme tu as pas mal de "run" à faire (type plan d'expérience), on va pas souvent à plus de 2000 coeurs sur nos codes.

Je suis intéressé de savoir s'il y en a beaucoup ici qui font des gros calculs sur 20000 coeurs par exemple et quelles est l'efficacité du parallélisme à ce niveau là ?

Au niveau du calcul, il y a encore du boulot pour améliorer/inventer la programmation très massivement parallèle.