Sytoka Modon a écrit 4546 commentaires

Bien sur mais ce n'est pas top. D'abord c'est pas intégré dans ssh, les options de la ligne de commande sont très différentes, cela fonctionne par profile. Pas évident de rediriger un port en parallèle. Il y a mosh qui est dans le même esprit que x2go mais en console et il n'utilise ssh que pour ouvrir la connexion, il bascule ensuite en UDP et est très robuste sur des réseaux à très bas débit, ce que n'est pas x2go.

Bref, x2go, c'est très bien mais il reste du travail pour que tout le monde bascule dessus. Et au rythme actuel, plus personne ne sera sous X ;-(

Ceci dis, ça fait chier que Xorg/ssh n'est pas intégré la libnx…

Yep, c'est pas dans la ligne de mire…

Il existe un compilateur C qui est garanti "quasiment sans bug" … Malheureusement, ce n'est pas du logiciel libre

Dès que j'ai lu cela et je me suis dis de suite, ça c'est un truc de l'INRIA. Gagné !

Je ne sais pas quand l'INRIA va comprendre que son modèle ne marche pas toujours ? Enfin, le code source est sur github, je vois que les choses bougent ;-)

Je pensais à Raphaël car il a piloté le projet https://tracker.debian.org/ et a été co-mainteneur de dpkg pendant longtemps (dont il viens d'ailleurs de se retirer). Mais effectivement, il y a plein d'autres développeurs Debian très compétent en France (dont les deux derniers DPL) ;-)

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