Sytoka Modon a écrit 4566 commentaires

Oui et non.

Gimp a été conçu à l'origine pour un environnement en FollowMouse or actuellement, on est en plein période CLickToFocus et plein écran. Donc Gimp s'adapte, certes lentement…

Quelqu'un qui n'a jamais fait du FollowMouse mais toujours du CLickToFocus a du mal à comprendre ce genre d'application. Personnellement, je regrette que ce type d'environnement soit en retrait de nos jours. C'est en partie logique car le CLickToFocus est adapté au petit écran (portable, tablette, cellulaire) alors que le FollowMouse fonctionne mieux sur grand écran.

A ma connaissance, ce n'est même pas dans Debian donc ça limite les chances de la voir marcher ailleurs que sous Ubuntu…

Humm… "Allo Intel, arrêtez vos bricolages avec vos Core i7 à 3 GHz

Il reste les anciennes couches sur les proc actuels. Intel les as justement viré sur les Xeon PHI. D'ailleurs, Intel voulait repartir de zéro avec l'Itanium et a du bricoler en urgence le jeux amd64 pour ne pas se faire manger… Sinon, le 8086 était le proc le plus pourris, bien plus merdique à programmer que le Z80 ou le 6502. Mais ce n'est pas toujours la meilleure solution qui gagne ;-)

Personnellement, je suis admiratif des ingénieurs d'Intel. C'était pas forcément évident de relever tous les challenges qu'ils ont eu depuis 40 ans… certes, ils ont les moyens.

Un bon point d'entrée serait de contacter Raphaël Hertzog - http://raphaelhertzog.fr/ - https://wiki.debian.org/RaphaelHertzog. Il me semble que c'est un des meilleur point d'entrée en France sur ce sujet.

Je trouve frustrant en 2015 de tomber

Ça tombe bien, Debian cherche des personnes pour les aider à gérer leur infrastructure ;-)

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.