Sytoka Modon a écrit 4561 commentaires

En gros c'est un client lourd qui utilise firefox pour l'affichage ? On n'arrête pas le progrès ;-)

Encore une fois, c'est pas parce qu'on charge deux fois un programme ou une bibliothèque qu'on double l'espace mémoire. Le format ELF est justement fait pour permettre au noyau Linux de ne pas dupliquer le code et il ne duplique les variables que si elles sont modifiés.

Je vais testé cela d'ici peu. J'avais essayé sous Wheezy lors de sa sortie mais ça n'avait pas marché… On trouvait des astuces ici ou la mais rien de bien fonctionnel en pratique.

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 ;-)