Janvier / Janvier 2019

GNU/Linux Magazine 222

Chroot, machine virtuelle ou conteneur ?

Que choisir et pourquoi ?

  • Les différentes solutions disponibles
  • Mise en œuvre avec des exemples concrets
En savoir plus

7,90 € TTC

Anciens Numéros

LIVRAISON OFFERTE en France Métropolitaine à partir de 50€
GNU/Linux Magazine 272

GNU/Linux Magazine 272

Novembre / Décembre 2024
9,90 €
GNU/Linux Magazine 271

GNU/Linux Magazine 271

Septembre / Octobre 2024
9,90 €
GNU/Linux Magazine 270

GNU/Linux Magazine 270

Juillet / Août 2024
9,90 €
GNU/Linux Magazine 269
9,90 €
GNU/Linux Magazine 268

GNU/Linux Magazine 268

Mars / Avril 2024
9,90 €
GNU/Linux Magazine 267

GNU/Linux Magazine 267

Janvier / Février 2024
9,90 €
GNU/Linux Magazine 266

GNU/Linux Magazine 266

Novembre / Décembre 2023
9,90 €
GNU/Linux Magazine 265

GNU/Linux Magazine 265

Septembre / Octobre 2023
9,90 €
sommaire

Actus & Humeur

p. 06  Empaquetez (facilement) votre projet avec upt
p. 12  Après le code source, le code moral !
p. 16  Faut-il nécessairement réfléchir pour programmer ?

IA, Robotique & Science

p. 24  Confrontation de plans cadastraux et de photos satellite avec OpenCV

IoT & Embarqué 

p. 42  Retrouvez le plaisir du test HDL avec Cocotb

Kernel & Bas niveau  

p. 52  Une introduction à LuaJIT

Système & Réseau 

p. 58  Chroot, machine virtuelle ou Kubernetes ?
p. 71  Imprimer en ligne de commandes

Mobile & Web 

p. 78  Le langage Dart et les Web Apps

Sécurité & Vulnérabilité

p. 92  Découvrez ou redécouvrez Ansible-Vault

édito

Pendant longtemps je n'ai utilisé que les commandes « naturelles » du Shell. Jamais un alias ni de scripts ne contenant ne serait-ce que deux ou trois lignes pour être certain d'être opérationnel en toute situation, sur n'importe quelle machine. Pourtant il est possible de devenir beaucoup plus productif en utilisant ces outils correctement. Pourquoi alors se restreindre à un usage somme toute fort limité du Shell ?

Pendant mes études, dans ce qui s’appelait alors une Licence d’Informatique (et qui est maintenant un L3),   j’ai eu la chance d’avoir un professeur en « Système et Réseau » qui nous a obligés à n’utiliser que les commandes naturelles du Shell, à n’écrire nos programmes qu’à l’aide de Vi (ou à l'extrême rigueur avec Xemacs), à utiliser Awk, Sed et autres outils indispensables, mais peu engageants de prime abord. S’il n’avait pas été là à nous pousser dans cette direction qui n’était pas la voie la plus simple, aurions-nous réellement découvert tout le potentiel de ces outils ? Les aurions-nous simplement utilisés alors qu’ils semblaient si rébarbatifs ? Bien entendu, comme dans chaque promotion il y a bien eu le groupe des « petits rigolos » qui utilisaient nedit en douce et faisaient semblant d’employer Vim. Les mêmes qui, passant de Pascal à C, ajoutaient des macros pour pouvoir continuer à écrire du Pascal, mais en C :

code-edito.jpg

Oui, c'est horrible, mais il y a vraiment des gens qui ont fait ça dans leur vie et ne se sont jamais remis en question… et même certains qui ont eu leur diplôme et continuent probablement à sévir en contribuant au développement de diverses applications et services que nous utilisons (et là ça fait peur, même si tout de suite on comprend mieux bon nombre de dysfonctionnements). 

Je pense en tout cas que pour la majorité des étudiants de l'époque, le fait d'être contraints à une utilisation stricte de ces outils a été bénéfique. Et tant pis pour les autres...

Ce n'est pourtant que 20 ans après (ouch !) que je me rends compte de l’intérêt pédagogique de cette approche... mais j’en ai peut-être été tellement marqué que j'ai tardé à utiliser des scripts et des alias. La peur de ne pas être capable de se débrouiller sans Internet (qui en était à ses balbutiements à l'époque), d’oublier les commandes ? Et puis un jour ce fut la révélation : il était désormais trop tard pour oublier ces commandes, elles étaient ancrées en moi. Ma décision fut prise et je passai aux alias et aux mini-scripts qui me firent gagner un temps non négligeable !

Cette réflexion m’a amené plus loin : dans mes enseignements, je propose régulièrement à mes étudiants de les aider pour tester Linux (ils sont bien sûr majoritairement sous Windows), de les accompagner dans l’apprentissage de Vim ou de LaTeX. Sans succès ! Mes UEs portent sur des projets algorithmiques, de la Programmation Orientée Objet ou du développement Web et je me voyais mal imposer quelque chose sans lien direct avec le cours. Mais finalement, il y a des cas où si personne n’est là à nous pousser, à nous faire « mal », nous n’avançons pas. Donc cette année mes étudiants vont souffrir : ils rendront leur projet sous LaTeX ! Ainsi, ils pourront choisir en connaissance de cause avant d’utiliser LibreOffice ou même Word. Une fois dans leur vie, ils auront goûté à LaTeX et peut-être qu’un jour, après m’avoir haï pour certains, ils me remercieront...

Apprendre, ça fait mal. Espérons que vous ne souffriez pas trop à lire GNU/Linux Magazine :-) !

Tristan Colombo

Le magazine de référence technique pour les développeurs sur systèmes open source et les ingénieurs R&D !

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...

Chroot, machine virtuelle ou Kubernetes ?
GNU/Linux Magazine n°222

Cela ne vous frappe pas que tout le secteur informatique ait les yeux rivés sur Kubernetes ? Moi, ça me donne à réfléchir. En quoi est-ce qu'un chroot ne ferait pas aussi bien le travail ? Les machines virtuelles seraient donc en fin de vie ? Quels sont les cas d'usage des conteneurs, et aussi quand ne pas les utiliser ? Je peux sûrement amener ici quelques éléments de réponse.

Empaquetez (facilement) votre projet avec upt
GNU/Linux Magazine n°222 Free
Les logiciels que nous utilisons sur nos distributions GNU/Linux et *BSD proviennent généralement des dépôts associés à ces dernières. Ils y sont présents, car les mainteneurs de notre OS préféré les ont empaquetés : cela nous évite de devoir recompiler les sources nous-mêmes, de résoudre les problèmes de dépendances ou de parfaire l'intégration avec le reste de notre système. Nous verrons dans cet article comment les empaqueteurs ont réussi à automatiser une partie de leur travail. Nous proposerons ensuite une solution logicielle permettant à toutes les distributions d'empaqueter facilement le code disponible sur des plateformes telles que PyPI, RubyGems ou CPAN.
Le langage Dart et les Web Apps
GNU/Linux Magazine n°222

Dart a été développé initialement par Google qui souhaitait l'imposer comme un nouveau langage pour le Web et l'intégrer dans son navigateur Chrome. Aujourd'hui Dart est un langage à part entière, incontournable pour le Web grâce à un compilateur Dart vers JavaScript, mais aussi qui permet de générer des applications natives Android et iOS connectées, ou même d'écrire des applications en mode console. Il est standardisé par la norme ECMA-408 et c'est un projet open source.

Ce magazine est intégralement disponible sur Linux Magazine Connect
© 2024 - LES EDITIONS DIAMOND