Ca va t'as fait une bonne balade ? Perso j'ai eu un peu chaud, mais à l'ombre ca allait.
Pour ce qui est de la définition d'un OS, juste le noyau est peut-être trop strict, j'en convient. Tu peux si celà t'amuse y inclure la preomière couche shell qui se trouve au dessus, mais pour moi c'est principalement une interface (et plus généralement un ensemble d'outil "wrapper") qui permettent d'exploiter le coeur du système, cad le noyau. Donc même si tu veux y inclure cette partie, ce sont en gros les même services qui sont offerts. Bref, on ne considère pas l'OS comme incluant toutes les autres couches situées au dessus (sinon on n'en fini plus) : on limitera donc la notion d'OS au noyau et à son interface utilisateur (les utilisateurs seront des processus bien entendu) et aux services qu'il fournit.
j'aimerai cependant revenir sur mon idée qui est de définir les différentes couches au dessus comme des couches de services, toutes situées à différents niveaux. Celà peut être des daemons qui jouent le rôle de serveur, celà peut être des bibliothèques de fonctions, celà peut être des exécutables, celà peut être des clients riches, etc. (je te laisse enrichir cette partie si tu veux)
Au niveau des serveurs, on est d'accord, il faut tenir compte du côté "multi-utilisateur".
Au niveau des bibliothèques, ce n'est pas obligatoire, mais celà suppose que chaque nouveau client va charger la bibliothèque. Il peut être avantageux de construire une bibliothèque de service qui est les propriétés d'un serveur (normal elle fournit des services), ce qui lui permettrai de ne pas être chargé 1000 fois par exemple, où de mieux gérer certaines ressources d'autre part. C'est en celà qu'il peut être utile aux développeurs de penser multi-utilisateur, pour que leur bibliothèque soit réellement multi-utilisateur plutôt de se contenter de la notion multi-utilisateur du noyau qui est surtout là pour isoler les processus et leurs propriétaires (bref pour moi le noyau joue là surtout un rôle de sécurité).
Au niveau des exécutables, tu l'as dit toi même, un certain nombre doivent en tenir compte, que ce soit sudo ou d'autres.
Au niveau des interfaces utilisateurs, qui sont pour la plupart là pour proposer une interface aux services en dessous, il me semble également important de faire ressortir la notion de multi-utilisateur ergonomiquement : j'y penses pour Gnome ou KDE qui doivent gérer une interface permettant de simplifier l'utilisation de plusieurs sessions graphiques, mais aussi par exemple pour une interface de serveur comme proftpd.
Bref, si tu regardes bien, il y a quand même un GRAND nombre de couches logicielles qui doivent tenir compte de l'aspect multi-utilisateur, celà ne représente pas pour moi une minorité de composants comme tu sembles l'indiquer. Je penses que tu comprends mieux pourquoi on veut familiariser les développeurs avec cette notion : il risque fortement de la rencontrer, sans se contenter de la possibilité offerte par le noyau (qui est là pour fournir des services BASIQUES) de lancer plusieurs fois une applications sous des id utilisateurs différents.
Tu prends même les applications de très haut niveau, comme par exemple un traitement de texte, la mode est au travaille colaboratif, il y a une notion de multi-utiliateur à présenter à l'humain et à exploiter pour par exemple fusionner des documents en tant réelles, effectuer une présentation en groupe, etc. C'est donc utile dans un cadre professionnel, à tous les niveaux applicatifs (serveurs comme outils graphique), mais aussi dans un cadre familiale (Gnome KDE)
Voilà voilà, j'espère que tu ne considère plus toutes ces situations comme des exceptions complètement à part qui confirme ta règle.
Pour le multi-tâche, c'est marrant, on t'a pas beaucoup vu répliquer :-)
Allez, il fait beau, profites en encore au lieu de glandouiller devant linuxfr comme moi :)
[^] # Re: Ah, le tas d'aneries habituel
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 2.
Pour ce qui est de la définition d'un OS, juste le noyau est peut-être trop strict, j'en convient. Tu peux si celà t'amuse y inclure la preomière couche shell qui se trouve au dessus, mais pour moi c'est principalement une interface (et plus généralement un ensemble d'outil "wrapper") qui permettent d'exploiter le coeur du système, cad le noyau. Donc même si tu veux y inclure cette partie, ce sont en gros les même services qui sont offerts. Bref, on ne considère pas l'OS comme incluant toutes les autres couches situées au dessus (sinon on n'en fini plus) : on limitera donc la notion d'OS au noyau et à son interface utilisateur (les utilisateurs seront des processus bien entendu) et aux services qu'il fournit.
j'aimerai cependant revenir sur mon idée qui est de définir les différentes couches au dessus comme des couches de services, toutes situées à différents niveaux. Celà peut être des daemons qui jouent le rôle de serveur, celà peut être des bibliothèques de fonctions, celà peut être des exécutables, celà peut être des clients riches, etc. (je te laisse enrichir cette partie si tu veux)
Au niveau des serveurs, on est d'accord, il faut tenir compte du côté "multi-utilisateur".
Au niveau des bibliothèques, ce n'est pas obligatoire, mais celà suppose que chaque nouveau client va charger la bibliothèque. Il peut être avantageux de construire une bibliothèque de service qui est les propriétés d'un serveur (normal elle fournit des services), ce qui lui permettrai de ne pas être chargé 1000 fois par exemple, où de mieux gérer certaines ressources d'autre part. C'est en celà qu'il peut être utile aux développeurs de penser multi-utilisateur, pour que leur bibliothèque soit réellement multi-utilisateur plutôt de se contenter de la notion multi-utilisateur du noyau qui est surtout là pour isoler les processus et leurs propriétaires (bref pour moi le noyau joue là surtout un rôle de sécurité).
Au niveau des exécutables, tu l'as dit toi même, un certain nombre doivent en tenir compte, que ce soit sudo ou d'autres.
Au niveau des interfaces utilisateurs, qui sont pour la plupart là pour proposer une interface aux services en dessous, il me semble également important de faire ressortir la notion de multi-utilisateur ergonomiquement : j'y penses pour Gnome ou KDE qui doivent gérer une interface permettant de simplifier l'utilisation de plusieurs sessions graphiques, mais aussi par exemple pour une interface de serveur comme proftpd.
Bref, si tu regardes bien, il y a quand même un GRAND nombre de couches logicielles qui doivent tenir compte de l'aspect multi-utilisateur, celà ne représente pas pour moi une minorité de composants comme tu sembles l'indiquer. Je penses que tu comprends mieux pourquoi on veut familiariser les développeurs avec cette notion : il risque fortement de la rencontrer, sans se contenter de la possibilité offerte par le noyau (qui est là pour fournir des services BASIQUES) de lancer plusieurs fois une applications sous des id utilisateurs différents.
Tu prends même les applications de très haut niveau, comme par exemple un traitement de texte, la mode est au travaille colaboratif, il y a une notion de multi-utiliateur à présenter à l'humain et à exploiter pour par exemple fusionner des documents en tant réelles, effectuer une présentation en groupe, etc. C'est donc utile dans un cadre professionnel, à tous les niveaux applicatifs (serveurs comme outils graphique), mais aussi dans un cadre familiale (Gnome KDE)
Voilà voilà, j'espère que tu ne considère plus toutes ces situations comme des exceptions complètement à part qui confirme ta règle.
Pour le multi-tâche, c'est marrant, on t'a pas beaucoup vu répliquer :-)
Allez, il fait beau, profites en encore au lieu de glandouiller devant linuxfr comme moi :)