Apprendre à  aimer Linux

  Mais comment se sentir à  l’aise dans un contexte Linux après avoir passé de nombreuses années à  apprendre l’OS/400 et l’iSeries ? Tout simplement en établissant des analogies entre les deux plates- formes. En effet, de nombreux principes clé de l’OS/400 (utilisateurs, groupes, listes de bibliothèques, fichiers de sortie, jobs actifs, par exemple) ont leur homologue Linux. Bien sûr, les noms Linux peuvent différer des noms OS/400 que vous connaissez si bien. Mais si vous connaissez leur principe de fonctionnement dans l’OS/400, il sera facile d’appliquer les mêmes concepts dans un environnement Linux avec les commandes appropriées. La figure 1 montre une liste de comportements de l’OS/400 et leurs fonctions Linux correspondantes. L’OS/400 utilise des bibliothèques pour stocker des objets : programmes exécutables, fichiers bases de données, index et même bibliothèques. Chaque type d’objet a son propre ensemble de commandes uniques pour créer, supprimer, et manipuler des objets individuels, qui contiennent leur propre information d’authentification. L’orientation objet de Linux est plus simple. Dans Linux, tout – même un programme exécutable – est un fichier, et un seul ensemble de commandes peut en principe manipuler tous les fichiers. Les fichiers ne contiennent aucune information d’authentification ; au lieu de cela, le système de fichiers Unix de Linux rattache un ensemble minimal d’attributs de sécurité à  l’entrée de répertoire pour chaque fichier. Mais Linux possède une structure de répertoires très souple. On peut imbriquer des répertoires (l’équivalent des bibliothèques OS/400) à  n’importe quelle profondeur : un fichier réside dans un répertoire, lequel peut résider dans un autre répertoire, et ainsi de suite. Le concept est le même que celui des répertoires PC (en fait, des développeurs de logiciels PC ont emprunté à  Unix l’idée des répertoires imbriqués).

  Cette imbrication de répertoires requiert un descripteur de fichiers plus complexe que celui de l’OS/400. L’OS/400 spécifie l’emplacement de tout objet par le descripteur bibliothèque/ objet, mais Linux doit fournir un chemin vers le fichier ou le répertoire. Voici quelques exemples de chemins de répertoires Linux courants :

• /etc – ce chemin de répertoire stocke les fichiers utilisés par les sous-systèmes (réseau, courrier, par exemple)

• /usr/local – stocke les bibliothèques d’applications (Star Office, kits de développement Java, serveurs applicatifs Web, par exemple)

• /bin, /usr/bin et /usr/sbin – stockent les utilitaires système et les produits

• /home – stocke les répertoires et fichiers utilisateur

  Linux permet de créer n’importe quel type de structure de répertoires. On peut aussi ajouter des commandes personnalisées à  tout répertoire. Généralement, on place les commandes créées par l’utilisateur sous /usr/local/bin, et les produits programmes (kits de développement Java, par exemple) et les applications personnalisées (Star Office Office, par exemple) dans les répertoires sous le répertoire /usr/local. Linux utilise également un concept appelé path list, comparable aux listes de bibliothèques de l’OS/400. La path list (liste des chemins) est stockée dans une variable d’environnement globale appelée $PATH et on peut l’afficher à  l’aide de la commande echo : echo $PATH /usr/local/bin:/usr/etc:/usr/sbin: /usr/bsd:/sbin:/usr/bin /bin La path list est une simple liste de chemins de répertoires, tout comme la liste des bibliothèques de l’OS/400 est une liste de noms de bibliothèques. Dans les deux cas, chaque instance exécutable – appelée job sous OS/400 et process sous Linux – a sa propre liste de bibliothèques ou de chemins. Toutefois, les listes de bibliothèques de l’OS/400 et la path list de Linux diffèrent par leur domaine d’action (scope). L’OS/400 utilise la liste de bibliothèques comme chemin de recherche pour trouver n’importe quel objet, mais Linux utilise sa path list pour trouver uniquement des fichiers exécutables. Cette différence confère aux listes de bibliothèques de l’OS/400 un avantage dans un environnement de test, où l’on souhaitera parfois orienter une application vers des objets de données dans une bibliothèque de test ; il suffira d’insérer la bibliothèque de test dans la liste des bibliothèques avant la bibliothèque de production principale. Linux n’a pas de possibilité équivalente.