Parallélisez et accélérez vos transferts de fichiers !
En savoir plus7,50 € TTC
Sysadmin
p. 04 Les capabilities sous Linux
En couverture
p. 14 Parallélisez vos transferts de fichiers
Cet article est un retour d'expérience. Il a pour but de vous présenter comment, dans un institut de recherche en biologie, nous avons entamé la migration de plusieurs centaines de téraoctets de données vers un seul et même serveur de fichiers. Cette migration a lieu dans le cadre d'un achat de nouveau matériel, destiné à remplacer plusieurs serveurs de stockage hétérogènes.
Repères
p. 26 Pourquoi PHP est-il un meilleur langage que Python ?
Netadmin
p. 30 MIMEDefang
Unixgarden
p. 44 Monter son propre NAS sous FreeBSD 9
Code(s)
p. 54 Base de données embarquée dans un navigateur
p. 62 Interception de signal avec dump de la pile d'appel
p. 66 Anatomie d'une des particularités de la libc
p. 70 PHPExcel : la solution ultime pour échanger des données entre PHP et votre tableur
p. 76 Google App Engine accueille les applications PHP
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 ! ».
Si vous croyez que le format ASCIIZ (aussi appelé « chaîne de caractères à terminateur nul » à la base du langage C et d’UNIX) est le pire péché originel de l’informatique, accrochez-vous. Il est amplifié par un autre péché bien plus grave, commis au nom du minimalisme, excusé au nom de la compatibilité et perpétué par l’oubli des alternatives. Si vous avez lu l’article de mars 2023 [1] jusqu’au bout, vous avez probablement compris que la plupart des langages de programmation actuels n’utilisent qu’une seule pile. C’est la source de nombreux problèmes (de sûreté, de sécurité, de complexité et bien d’autres) aux origines de failles variées (représentant peut-être un cinquième des CVE) que nous sommes habitués à mitiger, sans les résoudre vraiment. Dans cette première partie lovecraftienne, nous irons jusqu’au fond de l’impasse pour démontrer l’absurdité, les difficultés et les dangers imposés par ce système.
Au détour d'un petit projet incluant des échanges USB avec un adaptateur série utilisant une puce FTDI FT232R, j'ai rencontré un problème susceptible de survenir dans diverses situations. Même si aujourd'hui UTF-8 semble avoir toujours été présent dans nos terminaux, éditeurs, codes et que sais-je encore, les utilisateurs et programmeurs les plus aguerris se souviennent sans peine de la souffrance vécue lors de la transition depuis le bon vieux Latin1 (alias iso-8859-1). Mais la dure réalité est la suivante : UTF-8 n'est pas partout !