A quoi ressemble un système d'exploitation sans shell?

Le premier système d'exploitation que j'ai utilisé (1981) après l'université était PRIMOS sur un mini-ordinateur Prime. C'était un système d'exploitation en partage de temps et il prenait en charge un certain nombre d'utilisateurs, chacun utilisant un terminal connecté à l'ordinateur via un câble RS232. Vous deviez vous connecter au terminal en donnant un nom d'utilisateur et un mot de passe. Votre session de terminal était comme une coquille. Vous pouviez éditer des fichiers, compiler, exécuter toutes ces choses que nous faisons actuellement. Tous les terminaux avaient accès au même système de fichiers. En grande partie, ces terminaux n'étaient pas plus que des machines à écrire - pas d'éditeurs WYSISWYG, même emacs était un rêve.

Le système d'exploitation était structuré de la même manière qu'ils le sont maintenant et pouvait être imaginé comme une série de couches d'oignon. La couche la plus interne avait une fonctionnalité très basse - comme le contrôle du matériel, l'accès à la mémoire. En se déplaçant vers l'extérieur, le système de fichiers serait ajouté puis les couches utilisateur. Dans votre programme, vous seriez en mesure d'interagir avec certaines couches, mais pas avec les plus internes (donc vous ne seriez pas en mesure de toucher au partage de temps ou au matériel réel - lumières, etc.). Un ordinateur sans coquille serait comme l'une de ces couches internes, il pourrait être capable d'accéder à un disque dur et à un lecteur de bande (vraiment!), mais il ne saurait rien sur les fichiers ou les utilisateurs.

Pour démarrer un ordinateur ancien, vous aviez besoin de charger un ensemble de premières instructions de base (cela pourrait impliquer de basculer des interrupteurs physiques dans une séquence définie sur l'ordinateur). Cette séquence initierait un deuxième petit programme, qui pourrait permettre au lecteur de bande de fonctionner. Ensuite, vous chargeriez un système plus complexe via le lecteur de bande, ce qui pourrait mettre le lecteur de disque en ligne. Vous pourriez imaginer un système d'exploitation sans coquille comme l'un de ces chargeurs initiaux.

Aujourd'hui, les ordinateurs ont des séquences similaires, donc lorsque vous démarrez la machine, elle charge son BIOS, qui démarre les disques, les cartes réseau, la carte vidéo, etc., puis le BIOS cherche un programme spécifique sur le disque dur et l'exécute (du moins sur Windows). Unix fait quelque chose de similaire en configurant progressivement le noyau en commençant par des modules très basiques et en les développant jusqu'à arriver à l'invite de connexion

Système d'exploitation en tant que définition est plutôt ambigu. Est-ce un noyau en lui-même? Est-ce le noyau et aussi des outils accompagnants? Linux est le noyau mais GNU/Linux est le système d'exploitation basé sur le noyau Linux et les outils du projet GNU. Shell est une partie intégrale d'un tel système d'exploitation.

Cependant, une fois que Linux est démarré et fini "booting", vous devez lui dire quel programme exécuter. À partir de là, tout est entre les mains de ce programme particulier. Par défaut, c'est init qui sait quoi faire ensuite et pourrait éventuellement vous amener à un agréable écran de connexion GUI. Mais ça ne doit pas toujours être comme ça. Vous pouvez démarrer comme ceci

kernel /boot/vmlinuz-2.6.30 root=/dev/sda1 ro init=/bin/fancy

Ensuite, le programme /bin/fancy affichera "Bonjour le monde!". On n'a pas besoin de shell pour cela. Si vous souhaitez démarrer un autre programme, il suffit de créer un nouveau processus avec man 2 fork et man 2 execve, ou lire à partir du périphérique terminal et accepter l'entrée de l'utilisateur. Toujours pas besoin de shell.

À mon avis, le shell du système d'exploitation est un programme capable de lire l'entrée de l'utilisateur et ensuite démarrer d'autres programmes. Si vous y réfléchissez, il est assez évident pourquoi quelqu'un voudrait écrire un tel programme.

Même si vous n'avez pas besoin de lire l'entrée de l'utilisateur de manière interactive, il est beaucoup plus pratique d'écrire un simple script shell pour votre tâche. Dans ce cas, c'est simplement un interprète de commandes shell stockées. Vous pouvez tout aussi bien écrire votre programme dans l'interprète d'un autre langage.

Les systèmes d'exploitation sans coques de ligne de commande ou interfaces graphiques ont de nombreux autres types de "visages".

Les systèmes embarqués font simplement leur travail sans aucune interface utilisateur, comme le système de gestion du moteur de votre voiture (auquel vous pouvez accéder de différentes manières via l'interface OBD2 et un terminal approprié). Ou peuvent avoir des claviers numériques, des boutons ou autre chose (pensez : four à micro-ondes, ascenseur, ou la façade d'un système audio moderne). Que vous considériez cela comme une forme de coque est bien sûr subjectif.

Voici une recette de haut niveau sur la façon dont, en tant qu'amateur, vous pouvez créer un ordinateur utile sans coquille :

• Construisez une carte de circuit imprimé pour un microcontrôleur, ou obtenez une carte générique.
• Raccordez-la pour piloter des dispositifs utiles, comme, par exemple, un capteur d'humidité et une vanne d'eau. Le microcontrôleur dispose de broches périphériques à cet effet : UART, GPIO, et ainsi de suite.
• Écrivez le micrologiciel pour surveiller le capteur et arroser le sol.
• Téléversez le micrologiciel à l'aide des outils de développement (Ainsi, aucune coquille n'est nécessaire sur l'ordinateur hôte pour charger et exécuter quoi que ce soit, et le micrologiciel est stocké dans la mémoire flash sur la puce). La programmation peut impliquer que le microcontrôleur soit branché sur une carte de programmation spéciale, ou il peut y avoir une manière de le faire tout en étant sur votre carte actuelle. La carte s'interface avec votre PC (de nos jours via USB, par exemple) et vous utilisez des outils comme un IDE, ou des outils en ligne de commande sur l'hôte.
• Déployez la chose : elle est maintenant essentiellement une boîte noire électronique qui surveille d'une manière ou d'une autre l'humidité du sol et déclenche l'irrigation, sans autres entrées ou sorties.

Les premiers ordinateurs polyvalents sans coquilles avaient un moyen d'entrée, comme la lecture de cartes perforées. Mais bien sûr, les cartes perforées devaient être distinguées : est-ce qu'une carte perforée donne à l'ordinateur une commande spéciale, ou est-ce un morceau d'un programme Fortran ? Ainsi, des "langages de contrôle de travaux" ont dû être développés, qui sont de facto des lignes de commandes.

Avant les cartes perforées et les langages de contrôle de travaux, les programmeurs devaient basculer des interrupteurs afin d'introduire du code binaire dans la machine. Vous avez peut-être entendu des histoires de personnes âgées qui devaient "basculer" la séquence d'instructions pour initier un démarrage. Cela se fait encore aujourd'hui, d'une certaine manière : des dispositifs existent toujours qui ont des cavaliers ou des interrupteurs DIP, et il y a certains avantages à ceux-ci par rapport aux réglages dans le micrologiciel.

Le premier ordinateur sur lequel j'étais bloqué était un Siemens 305 en 1977, j'apprenais le FORTRAN IV. Il avait une machine à écrire pour exécuter des commandes et imprimer des messages diagnostiques sur papier, un lecteur de cartes perforées, un lecteur/enregistreur de bandes perforées et une imprimante. Sans oublier le disque dur amovible de 40 Mo, d'environ 16 pouces. Il avait donc déjà un shell, et l'interface était la machine à écrire.

Je me souviens d'avoir exécuté un débogueur et un éditeur de texte (DDT et emacs) comme l'équivalent d'une coquille de commande dans les années 1970. Donc, si vous exécutez emacs en mode console avec n'importe quel autre programme exécuté via eshell vers un débogueur qui exécute le programme, vous aurez une expérience similaire.

Notez qu'emacs dispose d'un environnement lisp complet, donc en plus d'une bonne édition de l'historique des commandes et de multiples terminaux virtuels, vous disposez d'une facilité de création de macros et de scripts très performante intégrée.