Sytoka Modon a écrit 4558 commentaires

amusant de claquer comme ça la porte aux nez des pirates en herbe.

Le pb est qu'on va claquer la porte de nos propres utilisateurs avec cette règles ;-) Moi j'ai besoin de plus d'un an pour mettre à jour tous les postes de mes utilisateurs…

ces licences CC avec des restrictions à la noix.

Il me semblait que la notion de commercial n'étant pas claire au final, il fallait -1- éviter ces licences, voire -2-, CC allait les virer dans ses nouvelles versions ?

Ça, c'était quasiment impossible entre Squeeze et Wheezy à faire. Si ça marche, c'est génial !

pour info, je n'aime pas ni utilise Debian et ai quand même cliqué sur "inutile"

Tiens, un Zenitram qui se montre utile ;-)

Debian utilise par défaut Dash et non Bash. L'empreinte mémoire est plus faible. De plus, le format ELF est tel que si tu as 10 Dash de lancés, tu ne consommes pas 10 fois la taille d'1 Dash. Seule la partie variable est dupliquée, non la partie en assembleur (il me semble).

Il me semble que Minix essaye aussi cette voie (http://www.minix3.org/). Il y a aussi Qubes qui explore une voie parallèle (https://www.qubes-os.org/) à base de Xen et de Linux.

Pas de soucis. Après tout bidouillage (ajout de tag…), je fais en général la commande suivante qui permet de mettre la date des fichiers à l'heure de chaque photo.

jhead -ft *.jpg


Un format que je me dis qu'un jour, il faudrait que je teste : Sereal (https://metacpan.org/pod/Sereal). Voila un petit lien sur les performances du bousin https://github.com/Sereal/Sereal/wiki/Sereal-Comparison-Graphs.

Par exemple, pour enlever 1h15 à toutes les photos

jhead -ta-1:15 *.jpg


Va faire un "screen /dev/ttyUSB0" sous tmux ! Tu utilises quoi pour aller sur un port console RS232 (un commutateur par exemple).

J'ai découvert il y a peu que putty pouvait faire la même chose et putty sous GNU/Linux… J'avoue que je ne l'ai jamais utilisé que sous Windows mais il y en a qui l'utilise sous GNU/Linux.

apt-cache search putty


On utilise pas les mêmes outils selon l'objectif…

• Par exemple, j'ai découvert il y a peu http://www.evqueue.net pour gérer des paquets de petits boulots en vrac. Il y en a d'autres notamment des monstres en Java ;-)

• Ansible ou autre (puppet, chef cfengine…) pour l'admin système

• Slurm, Torque, OAR… pour le HPC

• make -j, GNU Parallel, Parallel::ForkManager… pour des petits boulots locaux à une machine

J'utilise un peu tout cela mais tout dépend de la tâche à faire. Je ne pense pas qu'un seul outil puisse tout faire.

dinosaures qui utilisent encore screen ?

Moi pour faire du terminal série. C'est plus pratique que minicom (je trouve) et j'ai pas envie de lancer putty pour faire cela.

screen /dev/ttyS0


Attach/detach to Neovim instances running in the background(like tmux)

Cela pourrait d'ailleurs peut être se faire via un greffon tmux afin de ne pas ré-inventer la lune (et puis pas mal d'utilisateur de vim utilise tmux (ou screen - perso tmux avec un config a la screen).

Tu dois, si jamais tu DISTRIBUE ton logiciel modifié, fournir ton code sous licence gpl v2 (et comme tu ne va pas tout ré écrire, tu préservera le copyright des auteurs originaux.

Afin d'être encore plus précis, tu doit distribuer le code source à la personne a qui tu donnes ou tu vends ta version si elle te le demande. Il n'y a aucune obligation de redistribution à tout le monde.

A mon avis, pour avoir réagit en premier, je pense qu'il serait bien et temps de prendre un bouquin sur Perl ;-)

Tu rajoutes une bête loop et cela devrait faire l'affaire…

for my $file (@ARGV) ....


Bref, ça commence à sentir le roussi pour le Fortran. C'est dommage car c'est un excellent langage, mais j'ai l'impression que les temps sont durs pour les langages non généralistes.

Je ne serais pas aussi dur. Cela fait des années et des années que 99% des personnes pensent que le Fortran est mort et il est toujours la. Il a fortement évolué, bien plus de le C par exemple… Il y a 15 ans, c'était impossible de faire du Fortran sans avoir un compilateur privateur, de nos jours, gfortran s'en sors pas si mal sur de nombreux code (même si le résultat n'est pas aussi rapide qu'avec ifort). Pour les Coarrays, cela avance via OpenCoarray (http://opencoarrays.org/) mais il faut bien voir que l'objectif est d'avoir une manière simple de faire du parallèle intégré dans le langage donc on ne sera pas plus rapide qu'un code hybride aux petits oignons OpenMP/MPI… Il n'y a pas de magie derrière les Coarray ;-)

De notre coté, on utilise de plus en plus hdf5 et netcdf4 parallel (MPI). Il y a des gains énorme à basculer la dessus pour les entrées sorties.

Je crois qu'on est d'accord sur tout en pratique ;-) Je suis d'accord que l'architecture POWER est bien mais l'histoire montre cet argument ne suffit pas, surtout si le prix est d'un ordre de 2. Même Intel a du enterrer son Itanium, c'est pour dire. Mais cette guerre avec AMD fait que leur Xeon arrache désormais en puissance !!

Sinon, je parlais du prix marché DELL car quand on attaque ce genre de machine, on a souvent un marché. Je n'ai pas parlé de marché IBM car un, on n'en a pas et deux, dans nos derniers appels d'offre, IBM ne faisait pas de cadeaux ;-( Ceci dis, je suis curieux de voir ce que cela va donner car la réaction d'Intel est toujours intéressante.

La FFTW est géniale mais va l'utiliser sur 10_000 coeurs ;-) La version MPI a encore des sacrés progrès à faire et il faut surtout qu'un mathématicien trouve trouve une méthode géniale pour paralléliser la FFT sur un cluster ! Nvidia et Intel cherche aussi (Nvidia en a vraiment besoin pour ses GPU, idem pour Intel avec les Xeon Phi) mais pour le moment, je n'ai rien vu de génial.

Les langages fonctionnels seront plus rapide que le C/C++/Fortran le jour où les compilateurs auront une vision globale du code meilleure qu'un bon programmeur

Les compilateurs ont déjà une vision globale, par exemple l'option -ipo de ifort.

IL n'y a pas qu'un problème de compilateur, si tu fais du HPC sur un très grand nombre de cœur, tu mappes ta structure de données sur des tableaux. C'est une des raisons pour lesquelles il faut souvent écrire les codes spécifiquement pour le HPC. Via le bus InfiniBand, tu attaques via ton code hybride MPI/OpenMP tout en adresse (Fortran). Tu minimises toutes les copies. C'est une manière de programmer très différentes d'Erlang qui fait tout l'inverse par exemple ;-)

J'aimerais bien qu'un code Erlang soit plus performant qu'un code Fortran mais en on n'en est pas encore là. Par contre, il est tout à fait possible qu'à moyen terme, du code Erlang (ou équivalent) soit plus facile à concevoir et à maintenir et soit suffisamment performant pour qu'on s'en satisfasse sur les gros clusters HPC ;-)

On se retrouve donc contraint à développer en Fortran ou C/C++

Je rappelle pour ceux qui l'aurait oublié que le Fortran est un langage objet gérant l'héritage simple.

Pour avoir joué il longtemps avec cela, il faut penser à flusher (flush) car les écritures se font en mode block généralement pour aller plus vite donc en général, l'autre programme ne reçoit jamais les données si elles sont petites…

Dans ton cas, je n'ai pas regardé de près ton code. Désolé.

Actuellement, on est sur HP et les stations HP sous GNU/Linux sont de la daube en boite… Un des rares points ou DELL est clairement mieux ;-)

J'ai eu de l'Alpha, du POWER, de l'Itanium… et même du SPARC et du 68000 sous UNIX. A par l'Alpha, les autres ont toujours été trop cher pour un quelconque gain réel. Avec 15k€, j'ai une machine DELL avec 512Go RAM et c'est la RAM qui coûte cher sur ce genre de machine ! Via le marché public de la recherche, on a un DELL R630 avec 16Go RAM a moins de 1kE. Les gros acheteurs ont tous des marchés négociés s'ils ne sont pas trop mauvais.

Ma dernière machine exotique Itanium plantait lamentablement sur un bête 'modprobe 8021q', c'était sur la Suse officielle du constructeur… Ceci dis, je ne suis pas dans le domaine bancaire et Oracle n'a pas mis les pieds chez moi ;-) Le seul domaine ou nous utilisons les machines IBM, ce sont les supercalculateurs Blue Gene de l'IDRIS mais c'est un sacré boulot en terme de ressources humaines pour avoir un code performant dessus.

Concernant ARM, je suis d'accord avec toi, ça avance mais pas aussi vite qu'on pourrait l'espérer. L'embarqué est clairement encore la priorité…

On a joué dans le temps l'architecture Alpha car c'était très proche du PC en pratique. Cela aurait pu marcher si les offres s'étaient maintenu.

A plus de 20kE le ticket d'entrée, je doute que l'offre IBM aille bien loin… C'est pas avec ce genre de ticket qu'on maintient une architecture compétitive face à la puissance du x86. Cf la machine Itanium ou même Intel a du jeter l'éponge. Je crois bien plus à la carte ARM mais il faut effectivement que celle-ci monte encore un peu en puissance mais c'est bien ce qui se passe depuis quelques années…

Car ce n'est un secret pour personne, bigblue cherche à imposer son architecture comme étant une vraie alternative au traditionnel x86.

Enfin, c'est pas gagné ! L'hyperviseur propriétaire, j'aime pas du tout et le prix ? Pour prendre une vrai place, il faut que cela soit au même prix, IBM a toujours été hors de prix. Leur stratégie sur le libre n'a jamais été clair (cf l'affaire OpenOffice par exemple). A mon avis, ils jouent leur survis car même les banques ne doivent plus avoir envie de payer une fortune leurs bécanes.

Pour la virtualisation de milliers de VM, il y a une piste intéressante avec par exemple la machine Moonshot d'HP à base de processeur ARM. Entre l'ARM et le x86, cela va être dur de se maintenir sur un créneau généraliste…

http://www8.hp.com/us/en/products/servers/moonshot/index.html