En cette période estivale à forte teneur de départ aéroportuaire, il est parfois long (donc chiant) d’attendre dans les longs couloirs des aéroports. On est vite tenté de sortir son portable (téléphone ou ordinateur) pour faire deux ou trois choses sur le net. Si on n’a pas d’abonnement Internet sur notre téléphone, cela se révèle un peu plus ennuyant.

Dans certains aéroport internationaux (si ce n’est pas maintenant la quasi totalité) se trouvent des spots WiFi disponibles pour les passagers. Cependant, les accès sont loin d’être gratuits. Relativement ennuyant quand on a pas envie, soit de payer pour 20 min de surf, soit de laisser son numéro de carte bancaire à un système dont on ne connait pas les tenants et les aboutissants.

Pour cela: une technique que j’avais utilisé à l’époque où je bossais au sein du groupe Eclair. En cette période, mes collègues, mes boss et moi-même prenions de temps à autre l’avion pour des escapades punitives commerciales et techniques.

A l’époque, je me souviens, mon boss interpellait l’équipe avec la phrase « bon, il nous faut du WiFi », puis rajoutait en se tournant vers moi avec un sourire qui en disait long: « combien de temps ? ». Sous-entendu évident: en combien de temps nous trouveras-tu une possibilité d’avoir du WiFi gratos.

La technique est relativement simple et je pense, peut marcher n’importe où. Je l’ai testé dans plusieurs aéroports et hôtels.

Principe de base des interactions clients/hotspots:
Quand un nouveau client WiFi arrive sur le spot public, le client est redirigé vers une page d’accès lui demandant soit son identifiant et mot-de-passe, soit sa carte bancaire. Suivant le type d’abonnement, le client a un jeton de temps compris entre 10 min, 30min voire parfois 1h. Après cela, la session expire et la page d’accès réapparaît.

La méthode est assez enfantine:
Il s’agit de faire une sorte hijack de la session (le jeton-temps) d’un autre client présent ou non expirée dans le réseau.

La procédure est relativement simple et ne nécessite pas d’application tierce (genre aircrack & co), mais elle est chiante si vous l’effectuez à la main:

• Connectez-vous normalement à la borne WiFi.
• Prenez un navigateur
• Allez sur n’importe quel site
• Vous allez être redirigé vers la page d’accès: cela prouve que vous êtes déjà bien connecté au bon spot WiFi.
• Récupérez votre adresse IP, votre route (gateway), votre masque de réseau (netmask) et l’adresse IP du DNS donné par le spot WiFi.
• Quand cela est fait, changez simplement votre adresse IP en commençant par la première de la plage réseau (hors adresse IP de la gateway).

Exemple, si on vous délivre une adresse IP en 192.168.0.x et que le netmask est le 255.255.255.0 (et que la gateway se trouve en 192.168.0.1), mettez 192.168.0.2; Ouvrez votre navigateur et essayez de vous connecter de nouveau à un site. Si la redirection apparaît: ce n’est pas une session déjà établie ou bien qui a déjà expirée.

Retentez le coup avec la 192.168.0.3, puis la 192.168.0.4, et ainsi de suite. Dès que vous avez choppé une bonne session, le véritable site demandé apparaîtra.

A l’époque, pour simplifier la procédure, j’avais écris un script shell qui effectuait cela rapidement et vérifiait si la redirection était active ou non (un simple « GET » avec un grep sur un mot-clé de la page d’accès, et le tour est joué: si le mot apparaissait: on passe à l’adresse suivante)

Voila, c’est aussi simple et idiot que cela. Je ne sais même pas si c’est légal en fait et si cela rentre dans le cadre de « défaut de sécurisation de sa ligne Internet »

PS: pour les hotspots utilisant l’adresse MAC en sus, cette dernière peut être aussi modifié au besoin

Depuis longtemps, je gueulais sur le multi-fenêtrage de GIMP que je trouvais chiant à souhait (en plus des autres problèmes inhérents à GIMP). Je n’en pouvais plus de la non-gestion des groupes des calques, qui est pourtant une option pratiquement de base dans Photoshop. Quand un graphiste m’envoyait un PSD, GIMP se plantait lamentablement sur le z-index des différents calques… En bref, il me fallait la version de développement de GIMP qui résolvait une bonne partie de mes problèmes (pas tous malheureusement).

Mon côté fainéant s’est tourné directement vers une solution « toute prête ». Celle de Matthaeus, alias matthaeus123, qui consistait a insérer son repository dans votre source-list (non, ce n’est pas sexuel)

Autant vous le dire rapidement: Matt boit. Ou alors il se drogue. Tout du moins, il doit faire l’un ou l’autre voire les deux. La version compilée par ses soins est tout simplement inutilisable en production ET en développement (en plus de mettre le bordel dans les librairies déjà installées sur votre système qui vous obligerons soit a réinstaller les packages, soit à linker salement, mais passons).

Au début, on se dit que tout va bien, mais dès qu’on dépasse 1 ou 2 calques, dans 1 ou 2 groupes et on effectue quelques menus opérations mineures (genre la sélection), et bien là, c’est le drame: GIMP devient lent, mais leeeeennnt. D’une lenteur telle que le système ne réagit plus pendant quelques secondes.

On va dire que j’étais assez dégoûté par cette version de GIMP. Ok, c’est une version de développement, mais quand même. Mais dans le doute, je me suis dit « si ca se trouve, ce #%$& a oublié de virer les éléments de développements, genre debug & co…« . J’ai bien fait, c’était exactement cela, mais pour cela, il faudra se remonter les manches et compiler soit-même le GIMP des familles.

Allez, zou, on commence.

On prépare un peu le système.

 $ apt-get install intltool $ apt-get install python-dev python-gtkglext1 python-gtk2-dev $ apt-get install libgtk2.0-dev libglib2.0 $ apt-get install automake1.10 $ apt-get install ruby $ apt-get install openexr libpng-dev $ apt-get install libopenexr-dev libopenexr libopenexr6 $ apt-get install libjasper-dev libjasper1 $ apt-get install libgdk-pixbuf2.0-dev libgdk-pixbuf2.0-0 

GIMP nécessite les librairies GEGL et BABL

 $ git clone git://git.gnome.org/babl     Initialized empty Git repository in /tmp/toto/babl/.git/    remote: Counting objects: 3692, done.    remote: Compressing objects: 100% (994/994), done.    remote: Total 3692 (delta 2977), reused 3252 (delta 2677)    Receiving objects: 100% (3692/3692), 705.61 KiB | 272 KiB/s, done.    Resolving deltas: 100% (2977/2977), done. 

On lance la configuration pre-compilation:

 $ ./autogen.sh --prefix=/usr/local --enable-mmx --enable-sse \                       --disable-option-checking --disable-libtool-lock \                       --disable-dependency-tracking 

Notez qu’on prépare le paquetage pour une installation future dans /usr/local
A la fin de la configuration, n’ayez pas le geste habituel du « make », nous allons laisser cela à checkinstall. (sans cela, le travail de checkinstall va être hasardeux)

Pour informations, checkinstall est un programme qui se tapera la compilation ET la génération d’un paquetage lié à votre système. Cela évite d’avoir des fichiers qui s’installent partout et sans contrôle du gestionnaire de paquetages.

Même si checkinstall peut-être lancé sans être root, je vous conseille un petit sudo pour éviter toute frayeur, notamment pour la seconde partie. Sans cela, ce dernier trouvera des erreurs mineures, genre des changements de droit impossible et écartera les fichiers sans raison apparente et de façon assez aléatoire.

 $ sudo checkinstall --install=no --pkgname=libbabl --pkgversion=0.1.3                             --pkgrelease=1 --pkggroup=libs -y 

Durant mes premières compilations-tests, j’ai rencontré des problèmes avec checkinstall notamment sur la création des répertoires. Si vous rencontrez une erreur de ce type, n’hésitez pas a les créer à la main et de relancez la procédure.

A la fin, on vérifie le paquetage généré:

 $ dpkg --field ./libbabl_0.1.3-1_i386.deb     Package: libbabl    Priority: extra    Section: libs    Installed-Size: 1852    Maintainer: prae@arsenalgear    Architecture: i386    Version: 0.1.3-1    Depends:    Provides: libbabl    Conflicts:    Replaces:    Description: Package created with checkinstall 1.6.2  $ dpkg --contents ./libabl_0.1.3-1_i386.deb    < < plein de fichier dont notamment les librairies (.so) et les headers (.h) >> 

Validé, on installe le paquetage dans le système:

 $ sudo dpkg -i ./libbabl_0.1.3-1_i386.deb 

On passe à la librairie GEGL (dépendante de la librairie BABL)

 $ git clone git://git.gnome.org/gegl     Initialized empty Git repository in /tmp/toto/gegl/.git/    remote: Counting objects: 33001, done.    remote: Compressing objects: 100% (8245/8245), done.    remote: Total 33001 (delta 26804), reused 30095 (delta 24634)    Receiving objects: 100% (33001/33001), 23.32 MiB | 153 KiB/s, done.    Resolving deltas: 100% (26804/26804), done. 

On définit maintenant l’environnement avant la compilation. Vu que la librairie BABL se trouve dans /usr/local, il se peut que vous n’ayez pas /usr/local/lib dans votre environnement ldconfig.

On passe directement en root pour préparer l’environnement pour checkinstall qui arrivera plus tard (rappel: on peut le faire aussi en utilisateur normal, mais assumez les problèmes de checkinstall après coup)

 $ sudo -s # export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib/" # ./autogen.sh --prefix=/tmp/gegl --enable-mmx --enable-sse --disable-glibtest \                       --disable-option-checking --disable-libtool-lock \                       --disable-dependency-tracking     [...]    Building GEGL with prefix=/tmp/gegl    Optional features:       GEGL docs:       yes       Build workshop:  no       Build website:   no  (asciidoc not found)       SIMD:            sse:yes mmx:yes       Multi threading:    Optional dependencies:       asciidoc:        no  (asciidoc not found)       enscript:        no  (enscript not found)       GIO:             yes       GTK+:            yes       Ruby:            yes       Lua:             no  (usable lua not found)       Cairo:           yes       Pango:           yes       pangocairo:      yes       GDKPixbuf:       yes       JPEG:            yes       PNG:             yes       OpenEXR:         yes       rsvg:            no  (usable librsvg not found)       SDL:             no  (SDL library not found)       openraw:         no  (openraw library not found)       Jasper:          yes       graphviz:        yes       avformat:        yes       V4L:             yes       spiro:           no  (usable SPIRO library not found)       EXIV:            no  (exiv2 library not found)       umfpack:         no  (usable umfpack library not found) 

Vérifiez les formats supportés. Si certains formats vous inspirent mais en « no », installez les librairies adéquates.

 # checkinstall --install=no --pkgname=libgegl --pkgversion=0.1.3 \                     --pkgrelease=1 --pkggroup=libs -y 

Si la compilation de GEGL plante à cause de la librairie BABL non trouvé, vous avez surement oublié de modifier votre LD_LIBRARY_PATH correctement.

Si vous en êtes sûr et certain, vérifiez que vous n’avez pas modifié la variable LD_LIBRARY_PATH en tant qu’utilisateur, puis avoir lancé checkinstall en « sudo ». Si c’est le cas, un petit sudo avant, redéfinition de LD_LIBRARY_PATH, et dans la même session root, relancer checkinstall

Sinon, vérifiez bien le chemin qui mêne vers votre librairie BABL (avez-vous installé le package ? ;-)

Vous avez soit le choix du dépositaire de source, soit directement le tarball 2.4.7.

- Version Source Tarball :

$ wget ftp://ftp.gimp.org/pub/gimp/v2.7/gimp-2.7.1.tar.bz2
$ bunzip gimp-2.7.1.tar.bz2
$ tar -xvf gimp-2.7.tar
$ ./configure --prefix=/usr/local/gimp-2.7/ --enable-binreloc-threads --enable-mmx --enable-sse 

- Version GIT :

$ git clone git://git.gnome.org/gimp )
$ export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib/"
$ ./autogen.sh --prefix=/usr/local/gimp-2.7-201110/ --enable-mmx --enable-sse --disable-glibtest --disable-option-checking --disable-libtool-lock  --disable-dependency-tracking --enable-binreloc-threads --enable-mmx --enable-sse --disable-gtk-doc
$ ./configure 

   [...]   Extra Binaries:     gimp-console:        yes     gimp-remote:         no (not enabled)   Optional Features:     D-Bus service:       no     Language selection:  yes   Optional Plug-Ins:     Ascii Art:           no (AA library not found)     Help Browser:        no (WebKit not found)     LCMS:                no (lcms not found or unusable)     JPEG:                yes     JPEG 2000:           yes     MNG:                 no (MNG header file not found)     PDF:                 Using PostScript plug-in (libpoppler not found)     PNG:                 yes     Print:               yes     PSP:                 yes     Python:              yes     Script-Fu:           yes     SVG:                 no (librsvg not found)     TIFF:                yes     TWAIN (MacOS X):     no     TWAIN (Win32):       no     URI:                 yes (using GIO/GVfs)     Windows ICO          yes     WMF:                 no (libwmf not found)     XJT:                 yes     X11 Mouse Cursor:    yes     XPM:                 no (XPM library not found)   Plug-In Features:     EXIF support:        no (libexif not found or too old)   Optional Modules:     ALSA (MIDI Input):   no (libasound not found or unusable)     Linux Input:         yes (HAL support: no)     DirectInput (Win32): no     Color Correction:    no (lcms not found or unusable)     Soft Proof:          no (lcms not found or unusable) 

Afin de garder l’ancienne version de GIMP, on l’installera dans /usr/local.
Comme d’habitude, si vous avez envie de plus d’options, installez les librairies adéquates.

 $ sudo checkinstall --install=no --pkgname=gimp --pkgversion=2.7.1 \                             --pkgrelease=1 --pkggroup=graphics -y 

Sitôt terminé, on vérifie le paquetage et on l’installe

Et enfin, on fait joujou avec le nouveau bébé:

 $ /usr/local/gimp-2.7/bin/gimp-2.7 

*Enjoy la nouvelle version sans lag…*

Depuis pratiquement 2 semaines:

1. 192.168.0.254                                0.4%  2072    2.0   3.8   0.9 221.2  17.4
2. *******-*-**-**-***-***.fbx.proxad.net       0.3%  2071   21.1  24.1  19.1 258.5  17.9
3. 213.228.6.254                               40.2%  2071   23.0  25.6  19.0 276.3  21.9
4. bzn-crs16-1-be1001.intf.routers.proxad.net   0.5%  2071   32.9  25.9  19.9 284.7  21.0
5. cbv-6k-1-po20.intf.routers.proxad.net       29.5%  2071   25.6  25.7  19.7 221.2  19.1
6. 74.125.50.116                                0.6%  2071   37.7  28.9  19.3 274.1  25.1
7. 209.85.250.142                               0.4%  2071   40.3  32.3  19.6 439.0  30.3
8. 64.233.175.115                               0.4%  2071   47.1  25.3  19.9 280.7  20.0
9. par03s01-in-f104.1e100.net                   0.7%  2071   34.8  25.5  19.4 275.5  21.5

Va falloir que Proxad/Free fasse un truc …, ca devient relou…

En voulant passer à un kernel Linux classique à un kernel Linux RT, j’ai eu quelques peu soucis (vraiment mineur) comme par exemple la recompilation du module kqemu.

 kqemu-1.4.0pre1/kqemu-linux.c: In function ‘kqemu_open’: kqemu-1.4.0pre1/kqemu-linux.c:227: error: implicit declaration of function ‘init_MUTEX’

Une petite recherche sur le fameux init_MUTEX dans le fichier « kqemu-linux.c » et on le remplace par son équivalent sémaphorien: sema_init()

Voici le patch convi:

 --- kqemu-1.4.0pre1-orig/kqemu-linux.c  2008-05-30 22:33:34.000000000 +0200 +++ kqemu-1.4.0pre1/kqemu-linux.c       2010-04-24 21:42:49.784346001 +0200 @@ -224,7 +224,7 @@      ks = kmalloc(sizeof(struct kqemu_instance), GFP_KERNEL);      if (!ks)          return -ENOMEM; -    init_MUTEX(&ks->sem); +    sema_init(&ks->sem, 1);      ks->state = NULL;      filp->private_data = ks;      return 0;

Et après, on fait comme d’habitude: insmod/modprobe du petit kqemu.ko

 [11891.041088] QEMU Accelerator Module version 1.4.0, Copyright (c) 2005-2008 Bellard [11891.041163] KQEMU installed, max_locked_mem=1022996kB.

C’est beau comme du Zola.

NOTE: Attention, j’y vais un peu à l’arrache, remplacer une fonction comme cela avec une autre peut entraîner des effets de bord indésirable. Si vous utilisez ce patch, il n’y aucune garantie.

Récemment, je viens d’installer la dernière Ubuntu Lucid Lynx 9.10.

J’ai été surpris par pas mal d’évolution, une rapidité au démarrage incroyable, un KDE4 enfin stable et une prise en charge évoluée des périphériques. Mais j’ai été aussi étonné par le load average très conséquent sur un portable…

Ma configuration est assez simple:

• Portable Samsung
• Processeur Intel Core2 Duo T7100 cadencé à 1.80GHz
• 2 Go de RAM
• NVidia GeForce 8400M G
• Aucune application ne venant perturber le système

Sans Xorg

Le système pouvait loader jusqu’à 0.70 sans aucune raison: la loose quoi.

Sous Xorg

C’est pire, un load approchant les 2.0 sans rien d’actif

C’est pas possible, avec une Ubuntu 8.04, mon système ne loadait pas autant. Que s’est-il passé entre les deux releases ? Et sur les forums, impossible de trouver une put#%$* d’informations sur ce load average aussi haut.

La solution ?

Après une soirée rhum-banana, drogues et prostiputes, j’ai eu une illumination: et si cela venant du nouveau scheduler ? En effet – si ma mémoire est bonne – il y a eu des petites frictions entre kernel hackers sur les nouveaux schedulers. Hop hop, il est temps de tester cette possible voie.

Alors on a soit la méthode bourrine qui consiste a recompiler son kernel Linux avec un nouveau scheduler. Mais bon, si on se plante, va falloir refaire à chaque fois.

Ou bien on va faire un gros bisous au paquetage « linux-image-rt » disponible dans le repository Ubuntu.

 Si drivers nvidia proprio: $ wget http://us.download.nvidia.com/XFree86/Linux-x86/195.36.15/NVIDIA-Linux-x86-195.36.15-pkg1.run -O ~/NVIDIA-Linux-x86-195.36.15-pkg1.run $ apt-get install linux-image-rt $ vi /etc/default/grub             GRUB_DEFAULT=1             #GRUB_HIDDEN_TIMEOUT=0             GRUB_HIDDEN_TIMEOUT_QUIET=false $ update-grub2

On reboote le tout et sur le prompt grub, on selectionne la version « RT« 

Avec les drivers Nvidia

Là, le X devrait planter car pas de drivers nvidia. Sélectionnez « Passer en mode console ».
Sous le terminal, on lance la procédure d’installation du drivers nvidia (sudo sh ./NVIDIA-Linux-x86-195.36.15-pkg1.run )

Avec les drivers nouveau

Rien a faire

On finit l’optimisation en modification les options du schedulers directement:

 echo 100000 > /proc/sys/kernel/sched_min_granularity_ns echo 1000 > /proc/sys/kernel/sched_wakeup_granularity_ns 

Selon Ingo Molnar, kernel hacker sur les schedulers, pour un desktop, il faut que ces chiffres soient aussi bas que possible. ( a contrario, un server doit avoir des chiffres plus élevés)

Si vous voulez que ces options soient fixées, éditez le /etc/sysctl.conf

 vm.swappiness = 0 kernel.sched_min_granularity_ns = 100000 kernel.sched_wakeup_granularity_ns = 1000 

Pour vm.swappiness, reportez-vous à la documentation. Chez moi, cela améliore un peu les performances, mais peut-être que chez vous cela n’aura pas les mêmes effets.

Tip #1:
Modifiez le /proc/sys/kernel/sched_time_avg. Suivant les paramètres, chez moi, j’arrive à des performances améliorées

Tip #2:
J’ai été amené a modifier le lancement kernel en mettant l’option « mem=2048M » sur la ligne GRUB_CMDLINE_LINUX_DEFAULT dans le fichier /etc/default/grub (n’oubliez pas le petit « update-grub2″). Notez que chez mon cobaye (pour valider), cela n’a eu aucune influence.

Tip #3:
N’oubliez pas de vous mettre en performance au niveau du « scaling governor » sur vos processeurs:

 echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor 

Résultat ?

Mon load average est redescendu fortement. Maintenant avec un VLC en activité, un navigateur, mon lecteur de flux RSS, et plein d’autres stuffs, le load average est entre le 0.02 et 0.20. Je suis même tombé à un load average à 0.00 (avec VLC !). Et surtout: le ventilo ne crache plus ses poumons … ouf!

Cependant, le load average monte assez rapidement pour des raisons parfois étranges. Je ne doute pas que des optimisations doivent être encore effectuées. Que ce soit au niveau kernel (recompilations, changements paramètres, …), modifications paramètres sysfs, modifications paramètres procfs, etc…). Je trouve regrettable ce genre de problème pour une distribution comme Ubuntu. Et je suis encore plus étonné que personne ne soit tombé dessus encore aujourd’hui.

Au passage, si vous trouvez de nouvelles optimisations en ajout, faites péter ;-)

Liens divers:

• Lealinux Mailing List: Load average trs haut sous (k)ubuntu lucid 10.04
• Lwn: Schedulers, the plot thickens
• LinuxFR: Sortie du noyau Linux 2.6.23
• KernelTrap sur swappiness
• Swappiness en français

SNET: A new security module, called snet (which is short for « security for network syscalls ») was recently posted as an RFC on the linux-security-module mailing list.

Its purpose is rather simple—much simpler than the two current mainline users of the LSM interface—intercept system calls for networking and call out to user space to determine if they are to be allowed.

The idea is to be able to create Linux versions of the « personal firewall » that is popular on Windows machines. Reaction to snet was mixed, partially because of a disdain for that type of security tool, but also because it is implemented using LSM.

The main idea is to capture events coming from userspace, whenever a processus is doing some network syscall (sys_listen, sys_bind, ..). For that, it’s seems that LSM structure is the most simple, as far as we just have to connect on LSM hooks with struct security_operations {}

From The Director of « Autant on emporte les IO », Samir Bellabes

Trouvé au détour d’un post : http://mirror.facebook.com/facebook/patches/

Petit listing:

[   ] ap_source_defense.patch                                 27-Sep-2007 17:55     6k [   ] ap_UnsetErrorDocument.patch                             27-Sep-2007 17:54     3k [   ] apc_bindump-1.patch                                     12-Nov-2007 20:21    72k [   ] php_ini_includes.5.2.4.patch                            09-Oct-2007 03:36     8k [   ] php_mysql_t.patch                                       12-Nov-2007 14:17    12k [   ] xdebug_connectback-2.0.0.patch                          27-Sep-2007 17:55     3k 

Hmmmm … sounds like good …

GEGL (Generic Graphics Lib) is a graph based image processing framework.
Original design was made to scratch GIMP‘s itches for a new compositing and process core and this core is being designed to have minimal dependencies. and a simple well defined API.

Features

• Output in RGB, CIE Lab and Y’CbCr color models with 8bit, 16bit integer and 32bit floating point per component. Possible to extend to ICC managed output in babl.
• Non destructive editing
• C, C#, Python and Ruby interfaces.
• Extendable through plug-ins.
• XML serialization format (not-finalized)
• Iterative processing.
• Efficient subregion evaluation.
• Per node caches.
• Processing and display of image buffers larger than RAM
• Internal sparse pyramidial render cache.
• Bounding box based hit detection.
• Rich core set of processing operations that internally computes with 32bit floating point, linear light RGB.
  • PNG, JPEG, SVG, EXR, RAW, ffmpeg and other image sources.
  • Pattern renderers
  • Arithmetic operations
  • porter duff compositing
  • SVG filter modes and full set of compositing ops from SVG-1.2 draft
  • Gaussian blur, bilateral-filter, symmetric nearest neighbour, unsharp mask.
  • Color correction.
  • Text layout using pango

Et un petit Hello World GEGL des familles.

Miam !

Parce que je suis un fainéant, je chiffre certain de mes fichiers non-critiques avec le mode « crypt » de vim (touche :X).
Je suis étonné de constater que lorsque vim ouvre un fichier chiffré, le fichier vim-swap possède les infos déchiffrées …
La méthode de contournement serait de désactiver les fichiers vim-swap, mais je trouve bizarre que les développeurs de VIM ne soit pas offusqués de cela lorsqu’ils ont développés ce mode…
Cela laisse un goût amer, je trouve.

• Vim Tips: Using Crypt Mode … or GPG
• Vim Plugin: GPG
• Vim Doc: SwapFile

Petite note de la documentation :

 LIMITES DU CHIFFREMENT L'algorithme de chiffrement utilisé par Vim est faible. Il est suffisamment solide pour tenir à distance le menu fretin, mais certainement pas assez pour résister à un expert en chiffrement disposant du temps nécessaire. Soyez également conscient que le fichier d'échange n'est pas chiffré ; donc quand vous êtes en cours d'édition, une personne avec les privilèges du super-utilisateur peut lire le texte non chiffré dans ce fichier.    Une manière d'éviter que des personnes lisent votre fichier d'échange est de ne pas en utiliser. Si vous spécifiez l'argument "-n" sur la ligne de commande, aucun fichier d'échange n'est utilisé (à la place, Vim place tout en mémoire). Par exemple, pour éditer le fichier chiffré "fichier.txt" sans fichier d'échange, utilisez la commande suivante : 	vim -x -n fichier.txt Si l'édition est en cours, le fichier d'échange peut être désactivé avec : 	:setlocal noswapfile Comme il n'y a aucun fichier d'échange, le recouvrement est impossible. Enregistrez le fichier un peu plus souvent pour limiter le risque de perdre vos modifications. Tant que le fichier est en mémoire, il n'est pas chiffré. Quiconque disposant des privilèges suffisants peut regarder dans la mémoire de l'éditeur et découvrir le contenu du fichier.    Si vous utilisez un fichier "viminfo", soyez conscient que le contenu des registres y est également écrit en clair.    Si vous voulez vraiment sécuriser le contenu d'un fichier, éditez-le uniquement sur ordinateur portable non connecté à un réseau, utilisez de bons outils de chiffrement et conservez l'ordinateur dans un endroit verrouillé quand vous ne l'utilisez pas.

Pourquoi Mozilla Firefox me bouffe autant de ressources système que l’application que je code au taff et qui gère des flux live HD ?
Oh! allez! je vais me dire que j’ai supppeeer bien optimisé mon appli … je vois que cela sinon …

(pour le petit tommy qui a pas suivi au fond, c’est un pseudo coup de gueule contre firefox qui me bouffe la moitié de mes ressources système et me fait lagguer mon système …)