7,74 € TTC
p. 06 Kunai, le service discovery simplement
p. 14 Notre 11 septembre : mêmes effets et mêmes conséquences
p. 18 Le premier ordinateur à circuit intégré est allé sur la Lune
p. 26 La compression dans tous ses états
p. 36 Des bits comme s'il en pleuvait : une appliance SAN/NAS sous NetBSD
p.48 Authomatic : Python, OAuth et réseaux sociaux
p. 54 Cordova : quoi de neuf ?
p. 60 Introduction à PostScript – Éléments du langage
p. 66 Générez la documentation de vos APIs avec apidoc
p. 76 Planificateur – les outils
De jour en jour la quantité de données que nous collectons augmente. Ces données il faut les stocker, ce qui occupe forcément un espace physique non négligeable. Plus la quantité de données croît, plus il faut d'espace pour les stocker, c'est logique. Mais que se passe-t-il si l'espace de stockage ne croît pas suffisamment vite ? Il me vient à l'esprit une image couramment employée pour montrer l'expansion de l'Univers et qui peut s'appliquer ici. La question de départ est la suivante : pourquoi ne fait-il pas jour tout le temps puisque les étoiles emplissent l'Univers de lumière ? Ceci s'explique par l'expansion de
l'Univers : si nous prenons un robinet qui coule à débit constant pour remplir une baignoire, mais que cette baignoire grossit sans cesse, l'eau ne pourra jamais la remplir et déborder. L'eau représente la lumière et la baignoire l'Univers : l'Univers étant en expansion, la lumière émise ne pourra jamais le remplir. Dans le cas des données, on peut se dire que l'on se retrouve dans la même situation : la quantité de données acquise croît, mais dans le même temps les capacités
de stockage croissent encore plus vite... (sinon Google aurait de gros problèmes avec Gmail). Mais à force de stocker tout et n'importe quoi, de ne plus faire le ménage dans nos données et d'en collecter toujours plus de manière automatisée, ne va-t-il pasarriver un moment où notre capacité de stockage nous fera défaut ?Nos smartphones ont des capteurs de plus en plus performants et,sans modification des paramètres comme le font la plupart des gens,
il faut être en possession d'un volume de mémoire assez conséquent pour conserver des « photos ». Heureusement que ces dernières utilisent
un format compressé, un format qui nécessite un
traitement avant de pouvoir être archivé,
de manière à occuper le moins
de place possible.
Une fois
compressées, il faut
passer par une étape de
décompression, les données n'étant pas
lisibles en l'état. Ce mois-ci vous pourrez expérimenter
différents algorithmes de compression pour en disséquer lefonctionnement et adapter éventuellement l'un d'entre eux aux
données que vous manipulez et ne plus dépendre exclusivementde l'expansion de l'espace de stockage.J'espère que vous aurez noté que, pour la première fois, cet édito aura revêtu la forme d'un calligramme ! Un poisson aurait sans doute été de mise en ce mois d'avril, mais un poisson compressé n'aurait pas été du meilleur effet en première page...
Tristan Colombo
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...

Soyons clairs, je ne suis pas fan de Lua en tant que langage de programmation. Le simple fait que les tableaux débutent à l'indice 1 me perturbe totalement et constitue pour moi une véritable aberration. Mais, d'un autre côté, Lua est aussi le langage par excellence lorsqu'il s'agit d'embarquer des fonctionnalités de scripting au sein d'une application ou d'un outil. Du moins, c'est ce que tend à montrer sa popularité dans ce domaine et, si l'on n’a jamais tenté l'expérience, on peut se demander pourquoi. La réponse est évidente après quelques lignes de code et on se surprend soi-même à dire, à haute voix qui plus est, « Ah ! Mais c'est excellent, en fait ! ».
Dans un précédent article [1] paru dans le numéro 260, nous avions fait connaissance avec le développement noyau du côté de NetBSD. Remettons le couvert aujourd'hui, mais en nous penchant sur OpenBSD qui, de bien des manières et sur bien des plans est drastiquement différent des autres systèmes de la famille des héritiers de l'historique BSD que sont NetBSD, FreeBSD ou en encore DragonFly BSD. À commencer par le fait qu'il n'y a pas de modules kernel (LKM) dans OpenBSD...
Continuons cette série avec une surprise tout droit sortie de C++98 !