Dans un lointain passé, nos chers navigateurs (Netscape ???) ne possédaient qu'une barre d'adresse où il fallait indiquer l'adresse exacte du site internet que nous souhaitions atteindre. Plus tard, on a introduit une barre de recherche spécifique (elle se situe à droite de la barre d'adresse dans Firefox). Elle permet de faire des recherches directement sur des sites web (Google, Yahoo, Youtube, Wikipedia...) sans passer par la page d'accueil dudit site. Puis vint Google Chrome qui, par soucis d'ergonomie, et surtout pour passer systématiquement par leur moteur de recherche, a fusionné la barre d'adresse et la barre de recherche. En suiveur, cette fonctionnalité a été implémenté dans Firefox.

Jusqu'à présent, les deux barres (adresse et recherche) sont conservées, mais depuis peu, Mozilla a décidé de les lier pour éviter les confusions. Donc, si on sélectionne un moteur dans la barre de recherche et qu'on tape sa recherche dans la barre d'adresse, il va utiliser le moteur nouvellement sélectionné et non celui par défaut. Personnellement, je n'apprécie pas du tout ce changement (sélectionner le moteur actuel dans une autre barre dédiée, illogique ??). Bref, il existe un addon pour revenir au comportement précédent, mais sans aller jusqu'à l'installer, Firefox intègre une fonctionnalité de confort : Les mots clés de la barre de recherche. Ainsi, si on assigne le mot clé "y:" au moteur de Youtube et qu'on tape dans la barre d'adresse "y: The Inspector Cluzo", il va directement aller sur Youtube, même si le moteur actuel est Google ! Ça reste un contournement, mais c'est mieux que rien...

Astuce : ne pas affecter de mot clé pour le moteur de recherche par défaut, sinon Firefox ne résoudra pas la requête

Dans les prochaines version de Firefox, il est question de fusionner ces deux barres qui, pour le coup, ont vraiment la même fonctionnalité. Cette astuce (trouvée sur le net) sera donc encore plus utile.

Voilà ma première application Android : Silent Night*. Enfin presque... En réalité, je n'ai fais que reprendre une application déjà existante pour l'améliorer. Et c'est toute la force du logiciel libre : pouvoir analyser, adapter, corriger et améliorer l'existant pour nos propres besoins. Le cas de Silent Night est typique : l'application n'est plus compatible avec la dernière version d'Android, l'auteur n'a pas envie de s'y replonger. Pourtant, c'est une application simple, efficace et qui ne demande pas de lire vos SMS... Ni une, ni deux, je dégaine eclipse et met à jour l'application.

Même sans sortie officielle, je m'étais déjà penché sur le SDK d'Android. Personnellement, je trouve que c'est du bon gros bricolage. J'avoue n'avoir lu les tutoriaux que rapidement, mais j'ai quand même l'habitude de réaliser des applications pour PC. Les concepts pour mobile sont peut être différents, néanmoins, je trouve que l'API est une horreur à prendre en main (même si la documentation est très jolie). Rien ne semble clair (Intent, Fragment, Services...), surtout quand on rajoute la lourdeur des constructeurs à la Java. Pire encore : les applications sont incompatibles d'une version sur l'autre ! Le tout saupoudré d'un eclipse bien lourd (avec des bibliothèques qui ne sont compilées qu'en 32 bits !).

En 9 ans, Google n'a pas su redresser la barre pour proposer quelque chose de propre. Comme Microsoft avec Windows, le produit est trop répandu sur le marché pour changer radicalement. Même si le système en lui même est "beau", stable et performant (à grand coup d'optimisations), créer une application est un vrai calvaire (pour un débutant du moins). De plus, malgré qu'il soit open source, c'est un système assez fermé où l'utilisateur est régulièrement piégé entre le tout Google et le racket d'informations de la part des applications (lire vos SMS et accéder à Facebook est absolument indispensable pour une application qui allume le flash de l'appareil photo !). À ce propos, je ne peux que conseiller d'installer f-droid qui ne contient que des applications open source (comme Silent Night). Elles ne sont pas forcément de meilleure qualité, mais au moins on évite d'alimenter un carnet d'informations personnelles qui sera revendu plus tard par l'éditeur.

Mais que fait la concurrence ?

Propriétaires

• iOS : tout le monde connait. C'est du Apple, fermé au possible.
• WindowsPhone : peu utilisé, mais l'interface semble particulièrement bien adapté (et n'est pas une simple copie du premier).
• OS 10.2 de BlackBerry : il faut un BlackBerry.

Libres

• Firefox OS : comme ChromeOS, il est basé autour d'un navigateur. L'idée est intéressante, mais limité aux téléphones bas de gamme (pour le moment?). Faire des applications en HTML5/JavaScript, ce n'est pas trop mon truc.
• Sailfish OS : Peut être le meilleur futur concurrent d'Android. Enfin un SDK en Qt ! Mais pour le moment, rien ne pointe à l'horizon.
• Ubuntu Touch : Grosse déception pour ce dernier. Les performances et la qualité générale sont décevantes (test de novembre). Il y a eu beaucoup de promesses et pas grand chose au final...

En attendant, il y a Android... Jusqu'à ce, qu'un jour, peut être, Samsung décide de migrer l'ensemble de ses appareils vers un autre système... Le seul avantage, est que la réalisation d'applications sur mobile donne à manger à plein de développeurs.

*Silent Night permet de couper le son et/ou de passer en mode avion pendant une période donnée (configurable). C'est le mode avion qui était cassé sur les versions récentes d'Android. Pour l'activer, il faudra quand même avoir un téléphone rooté (merci Google).

Un système informatique, c'est comme une voiture : avant tout du visuel. GNOME est avec KDE un des deux environnements de bureau majeurs qui ont permit l'essor de GNU/Linux. D'abord en rattrapant leur retard sur les systèmes existants (Windows, Mac, BeOS...), puis en devenant innovant. Pour GNOME, dans sa troisième version, il s'agit de GNOME Shell et de son concurrent Unity chez Ubuntu. Comme souvent, une nouvelle version apporte son lot de bugs, mais aussi un changement de philosophie, ce qui a amené la communauté à se diviser et pester autant que possible sur ce nouvel environnement.

Forcément, au bout de 3 ans de développement, le bureau a gagné en maturité et fait maintenant partie de l'installation par défaut chez Debian. S'il est parfaitement utilisable et même agréable au jour le jour, il y a pourtant quelques détails passablement énervants, dont la gestion (par défaut) de alt-tab. Les développeurs de GNOME 3 ont introduit le concept de bureau "par application" et non plus "par fenêtres" : un bureau contient une seule application en plein écran. Résultat : alt-tab permet de naviguer entre les applications et non plus entre les fenêtres (qui sont groupées). Sauf que, la majorité des applications sont encore multi fenêtrées et qu'on aj'ai souvent plusieurs fenêtres de la même application lancées en même temps. Bref, de quoi se casser la tête à chaque alt-tab.

Pour revenir au comportement par défaut, il faut lancer l'utilitaire dconf-editor, puis naviguer dans l'arbre :

org -> gnome -> desktop -> wm -> keybindings

Il faut ensuite copier les valeurs de switch-applications dans switch-windows.

Autre astuce : le triage des dossiers/fichiers dans nautilus. Pour activer/désactiver l'affichage des dossiers en premier, il faut modifier :

org -> gnome -> nautilus -> preferences -> sort-directories-first

Voilà de quoi retrouver un peu de sérénité avec GNOME 3 !

Mon Samsung r780 vient de fêter ses 4 ans. 4 ans en informatique, c'est entre 2 et 4 générations. Autant dire qu'on pourrait presque le voir comme obsolète. Pourtant, il n'a pas à rougir avec ses 4Go de RAM et son double cœur i5.

J'utilise clavier, souris et écran externe, l'intérieur est donc quasi neufs. La batterie aussi étant donné qu'elle n'est pas connectée. Néanmoins, avec le temps, il commence à chauffer énormément, en été comme en hiver provoquant des coupures de sécurité intempestives. Ce point là a été réglé avec une bombe d'air (5€-8€) : un coup à chaque entrée/sortie d'air disponible et c'est reparti ! Il faut cependant faire attention à bien garder la bombe à la verticale, sinon le gaz se liquéfie ! (obligé de passer un coup de séchoir avant la remise sous tension).

Autre point très Très TRÈS désagréable : le wifi. Sa gestion est catastrophique sous Linux. Deux murs fins suffisent pour avoir des déconnexions et un débit plus que réduit, alors que c'est à peu près correct sous Windows (et parfait via un smartphone)... Les derniers firmware de Debian (firmware-realtek dans non-free) semblent plus stables, mais le débit est toujours anémique.

Dernier goulot d'étranglement : le disque dur. À 5400tr/min, il fait pâle figure face à la dernière génération de SSD. Plusieurs options d'amélioration sont possibles :

• Acheter un disque 2.5" à 7200tr/min ou 10000tr/min : pas facile à trouver et consomme plus.
• Utiliser uniquement un SSD : la fiabilité d'un SSD dans le temps est encore à prouver. De plus, les gros SSD sont chers.
• Coupler un SSD (pour le système) avec un disque externe (pour les données) : ça prend de la place, une alimentation et un port USB (il n'en reste qu'un de libre), ou utiliser le port eSata.
• Coupler le disque avec un SSD en cache (intégré ou via une carte d'extension).

C'est la dernière solution que j'ai retenue. Les SSD au format ExpressCard ne sont quasiment plus fabriqués, j'ai donc opté pour la solution du SSHD (Seagate Momentus Laptop thin). Pour 60€, j'ai 500Go de disque (contre 640Go) avec un cache SSD de 8Go. Vous allez me dire : 8Go, c'est rien. Le minimum du minimum chez les SSD c'est 64Go. Certes, mais la vraie question est : est-ce que le système + les logiciels utilisés fréquemment tiennent dans ces 8Go ? Si on ne joue pas, la réponse est oui ! Bien sûr, les accès hors cache (directement depuis le disque) seront toujours aussi lent, mais 80% de mon utilisation passera par le cache SSD !

Pour préserver la licence de Windows, je choisis de faire un simple dd et là, c'est le drame : le nouveau disque est plus petit que l'ancien, donc la table des partitions a des références hors disque. Les mauvais BIOS bloqueront à cette étape. En passant par un live USB, je rétabli la table des partitions. Une fois passé cette longue copie, c'est au tour de la ré installation de GNU/Linux. La dernière fois, c'était il y a 4 ans, je ne suis donc pas forcément au fait de ce qui s'est passé depuis. Alors, quand on me parle de LVM, des VG, des PV et des LV, je suis complètement perdu !

En fait LVM (Logical Volume Manager) n'a rien de très compliqué. Il permet d'abstraire des Volumes Physiques (PV) au sein de Groupes de Volumes (VG), pour en exporter un ou des Volumes Logiques (LV). C'est une "vieille" technologie héritée des serveurs qui, eux, manipulent de multiples espaces de stockage. On ne travaille plus qu'avec des volumes virtuels auxquels on peut ajouter/retirer des volumes physiques, faire des sauvegardes, faire du RAID... Les deux points qui m'intéressent particulièrement sont de 1) Chiffrer le volume et 2) Avoir du RAID. J'aurais aussi pu utiliser BTRFS qui intègre toutes ces fonctionnalités dans son cœur, mais je trouve plus élégant d'utiliser des couches séparées (stabilité, portabilité...). Pour l'anecdote, la première implémentation pour Linux date de 1998, mais sa popularité sur les machines personnelles est toute récente.

Chiffrer le disque est surtout utile en cas de perte/vol de l'ordinateur ou si on pratique des activités illégales et qu'on s'attend à recevoir la police pour dîner (ce qui n'est pas mon cas). Le RAID, quant à lui, permettra (dans l'avenir) de monter un serveur de sauvegarde en utilisant le SheevaPlug (ou une CuBox ?) ! En effet, les NAS sont hors de prix alors qu'on peut faire du RAID logiciel qui ne requiert pas un très gros débit pour juste de la sauvegarde.

Bref, je configure un groupe de volumes de 100Go qui va exporter les volumes logiques "system" et "swap" ainsi qu'un groupe de 250Go qui exportera home. "system" sera chiffré avec un mot de passe (au démarrage), "swap" avec une clé aléatoire et "home" avec une clé dans un fichier (/etc/luks-keys/home). Fichier qui sera lui même sauvegardé dans un autre endroit (après avoir été chiffré avec GPG) afin de pouvoir récupérer les données en cas de problème avec le volume "system". Cette configuration a l'avantage de ne demander le mot de passe qu'une seule fois tout en permettant de monter "home" depuis un autre système (si on possède le fichier de clés).

/boot sera (pour la première fois) une partition à part et non chiffrée (n'ayant pas de BIOS UEFI qui supporte une table des partitions GPT...). Petite blague : le noyau a pris de l'embonpoint et il est nécessaire d'augmenter la taille de la partition (200Mo), là où 20Mo suffisaient jadis.

Pour toutes les manipulations, il y a une procédure très bien expliquée sur le wiki d'ArchLinux. J'ai quand même dû rajouter l'option "rootdelay=1" à la ligne de commande au démarrage (il faudra vraiment que je règle le problème sans passer par ce bidouillage).

Dernier point : les systèmes de fichier utilisés. Comme on a un SSD, il faut éviter de trop écrire dans le cache, donc éviter autant que possible les systèmes de fichier journalisés, surtout sur /boot et / (qui risquent fortement de se retrouver dans le cache), ajouter les options "noatime" et "nodiratime" lors du montage des partitions, utiliser un maximum de parties du système en RAM (/tmp, /var...), ainsi que mettre le swappiness à 0 ("vm.swappiness = 0" dans /etc/sysctl.conf) afin de réduire au maximum l'utilisation du swap (qui risque aussi de se retrouver rapidement dans le cache SSD).

À vue de nez, l'utilisation courante semble deux à trois fois plus rapide (pari gagné). Je pense qu'on pourrait gagner encore sans LVM ni chiffrage (le noyau implémente un algorithme AES générique : pas d'accélération/optimisation matérielle). C'est aussi l'occasion de passer à Nouveau : il est un peu plus lent que les pilotes NVIDIA, mais il fait le job. Pour mon utilisation il suffit amplement.

Conclusion : pour ~70€, j'ai retrouvé un ordinateur qui tient tout à fait la route, au moins pour quelques années !

Wireshark (previously Ethereal) is the best open source protocol dissector/analyzer. You can analyze an incredible amount of protocols, not only Internet ones, but every stream based protocols. Moreover you can add your own filters/dissectors written either in C or in Lua. Nevertheless, the documentation on the net concerning Lua dissectors is light and sparse. It's been hard for me to make something that works even if it's, at the end, not really complicated. I'll try to explain the basis of Lua dissectors.

1) Installation

You need to have a wireshark that supports Lua support (wireshark -v). After that, create or edit ~/.wireshark/init.lua. To load a new plugin, just type

dofile("mydissector.lua")

Create the new file ~/.wireshark/mydissector.lua

2) Post Dissector

There are three types of dissectors :

• Dissector : you add your own protocol
• Chained dissector : you add new fields to an existing protocol
• Post dissector : you interact after all packets has been parsed

An example for each of one can be found here. I'll describe a post dissector, but other types of dissectors has pretty the same format.

Tip 1
If you want to display someting on the console, just do

print(something)

Tip 2
If the base array is not defined, add this to ~/.wireshark/init.lua

-- Display Bases
 base = {
    ["NONE"] = 0,
    ["DEC"] = 1,
    ["HEX"] = 2,
    ["OCT"] = 3,
    ["DEC_HEX"] = 4,
    ["HEX_DEC"] = 5,
}

First, you need to define your protocol : Proto(<internal name>, <displayed name>)

p_dummyproto = Proto("dummyproto","DummyProto")

Then, define your fields : ProtoField.TYPE(<internal name>, <displayed name>, [base], [values], [mask])
TYPE are defined here

-- Simple field without value
local f_X =  ProtoField.uint16("dummyproto.f_X","Field X")
-- Simple field displayed in hex format
local f_Y =  ProtoField.uint8("dummyproto.f_Y","Field Y", base.HEX)
-- Field with precomputed values and bitfield
local VALS_ZZ    = {[0] = "Single", [1] = "Dual"}
local f_Z =  ProtoField.uint8("dummyproto.f_Z","Field Z", base.HEX, VALS_ZZ, 0x3)

Third step is to register each field

p_dummyproto.fields = {f_X, f_Y, f_Z}

After that, the big part : protocol dissection. Fields are organized as a tree. You have to parse each byte (or range of bytes) in the given buffer and append your fields. Be careful : objects returned by :add function has userdata type and cannot be directly manipulated.

function p_dummyproto.dissector(buffer,pinfo,tree)
   -- Access to another field
   local f_udp_port = Field.new("udp.port")

   -- If it exists and has the right value
   if f_udp_port and tostring(f_udp_port) == tostring(5555) then
     -- Add our protocol dissection with data in buffer[17, 17+14]
     local subtree = tree:add(p_dummyproto, buffer(17,14))

     -- Add a subtree to our root for the first two bytes
     local t = subtree:add(f_X, buffer(17, 2))

     -- Add a sub subtree
     local t2 = t:add(f_Y, buffer(17, 1))

     -- Parse sub data
     parse_data(t, buffer, 18)
   end
end

function parse_data(tree, buffer, start)
     -- Wireshark integrate bitop from luajit http://bitop.luajit.org/
     field_1 = buffer(start, 1):uint()
     field_1 = bit.band(field_1, 0x3)

     -- You can also append free text information to current field
     if field_1 < 16 then
         tree:append_text(" field information")
     end
end

Finally register your post dissector

register_postdissector(p_dummyproto)

A complete example can be found here. It's a full reimplementation of ARP protocol dissector in Lua.