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

Plus de détails

7,90 € TTC

 
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

A propos du magazine
Logo

Le magazine de référence technique pour les développeurs et les administrateurs sur systèmes UNIX, open source & embarqué !

Pionnier dans son domaine, GNU/Linux Magazine est depuis 1998 une véritable référence technique pour pour tous les développeurs et administrateurs sur systèmes Unix, open source et embarqués. Le premier magazine français 100 % Linux se démarque grâce à une ligne rédactionnelle résolument technique et pédagogique. Chaque mois de nombreux thèmes sont abordés permettant de toucher à différents domaines de l’informatique, que ce soit de l’intelligence artificielle, de la sécurité, de l’embarqué, du système/réseau ou du hack.

Nouveaux produits