Discussion utilisateur:Silex6/Bac à sable

Système d'exploitation

Salut,

Avant de commencer :

1. je veux juste préciser que je n'ai pas de prétention à une connaissance définitive du sujet. J'ai simplement eu, au cours de l'année dernière, à travailler intensivement sur le Tanenbaum (entre autres), et c'est là-dessus que je me fonde.
2. je suis bien conscient que l'article est en construction, et que certains manques sont liés à cela. J'imagine donc que je vais te dire des choses que tu sais bien.

Nulle arrogance donc dans mes propos, mais l'idée d'arriver à l'article le plus clair, complet et précis possible.

Je te livre mes remarques. D'abord, l'essentiel : c'est largement mieux organisé que l'article actuel. Ensuite, point par point.

L'introduction

• il serait intéressant d'insérer, en parallèle de l'idée de coordination, l'idée d'abstraction. En effet, le SE coordonne le matériel et fournit une abstraction pour le manipuler. (Je ne suis pas totalement satisfait de ma formulation, mais je pense que l'idée est juste).

Je viens de retrouver une phrase intéressante de Tanenbaum : « un système d'exploitation a deux grandes fonctions : offrir des abstractions aux programmes utilisateurs et gérer les ressources de l'ordinateur ». Gérer les ressources de l'ordinateur = coordonner l'utilisation du matériel, comme tu l'écris.

• il me semble que dans le cas de Linux, ce n'est pas l'API qui est fixée (par POSIX), mais les appels système. L'API (utilisée en C par ex avec les bibliothèques système) est un enrobage des appels systèmes. La différence est au niveau du "contrat", qui ne porte pas sur l'API (comme dans Windows) mais sur les appels.

Peut-tu préciser. A ma connaissance l'API est un ensemble de fonctions que le logiciel applicatif peut appeller par des appels système. les librairies C ne sont que des connecteurs sur l'API. est-ce correct ?

Bib C = connecteurs sur l'API : je suppose que c'est correct, mais seulement sous Windows.

D'après Tanenbum pp.53-62, l'appel système est réalisé par le noyau. Le programmeur Linux utilise une bibliothèque avec des fonctions du type read(), etc. La fonction read() (programmée en assembleur) réalise un déroutement vers le noyau, qui réalise l'appel système read. Une fois l'appel réalisé, on retourne en mode utilisateur.

C'est maintenant que ça se complique. POSIX est une norme qui spécifie les appels système, alors que sous Windows, la norme spécifie directement une API que j'ai envie d'appeler centrale (Win32). Sous cette API centrale (garantie, malgré les évolutions XP->Vista->...), il y a des appels systèmes, mais non garantis par Microsoft. Au contraire, POSIX garantit qu'on peut réaliser un certain nombre d'appels au système, mais ne garantit aucune API (par exemple : rien sur la signature des fonctions printf et compagnie en C). Le contrat ne porte pas sur le même point. (Remarque : c'est assez incroyable, mais POSIX ne spécifie aucun appel système relatif à la gestion de la mémoire, alors qu'il y a bien évidemment la fonction malloc en C.)

Sous Linux (comme sous Windows d'ailleurs), le contrat portant sur la bibliothèque standard C (une API aussi !) relève de la norme ANSI, pas de POSIX. On a donc bien une API contractuelle pour le système, mais elle est définie par l'ANSI, donc pas au niveau du SE. Pour le reste, le contrat avec OpenGL (autre API !) dépend d'OpenGL, etc.

Pour conclure, je pense qu'il faut s'appuyer sur la notion de "contrat" au niveau de l'interface haute (SE/Applis), mais que ce n'est pas évident à rédiger en une phrase. Un truc comme "Le SE fournit un contrat aux applications qui interagissent avec lui, soit sous forme d'une API, soit sous formes d'appels systèmes (une ou des bibliothèque(s) standardisée(s) peuvent être définies au-dessus, mais elles ne relèvent pas du SE)".

J'espère que ce que je dis n'est pas trop faux.

Je reprécise ma pensée : le programmeur utilise toujours une bibliothèque pour programmer ses applications (une API). La question est de savoir où s'arrête l'interface haute du SE. Est-ce que l'API en fait partie (Windows) ou non (Linux : elle fait partie du langage C qui est étroitement lié au SE mais n'en fait pas partie à proprement parler) ? Un malade pourrait reprogrammer en assembleur sa bibliothèque perso de fonctions qui font les appels système avec Linux puisqu'il connaît les appels système sous-jacents (intérêt : 0). Ce ne serait pas possible en Windows (à moins d'avoir des infos non divulguées par Microsoft).--Juju2004 (d) 11 septembre 2009 à 19:00 (CEST)

• je continue à penser qu'une distinction devrait faite assez rapidement entre SE au sens strict, et SE avec ensemble d'applications (ne serait-ce que pour éviter les débats ultérieurs). Par exemple, ta définition initiale exclut le shell (cas Linux), mais tu le réintègres ensuite en parlant des utilitaires.

A mon avis la définition du SE au sens strict est celle qui est indiquée dans les premières lignes de l'intro, et les logiciels utilitaires sont des bonus qui sont livrés en bundle avec le SE - ne serait-ce que parce qu'ils sont indispensable à une utilisation même minimaliste de l'ordinateur.

C'est tout à fait défendable mais pour éviter l'ambiguïté, une phrase du type "Un SE est fourni avec divers logiciels utilitaires" est préférable à "Un SE contient en outre...". Note que cela ouvre une brèche pour : le navigateur internet, le client mail, etc.

fait. j'ai mis fourni avec.

• à mon avis, l'introduction du concept d'E/S pourrait-être faite avant de parler d'image numérique, pour simplifier la compréhension.

tout à fait.

Caractéristiques

• ràs, sinon que tu pourrais rajouter le terme de "multiprogrammation".

en quoi est-ce en rapport avec le SE ? ca relève de la programmation, non ? l'article parle de multitâches, ca me parait suffisant, non ?

Les termes sont parfois assez flous. Pour moi, multitâche signifie qu'il y a une impression de simultanéité dans l'exécution des processus, alors que multiprogrammation signifie plutôt qu'il y a plusieurs processus en mémoire. La différence est qu'au départ, la multiprogrammation se contentait de switcher de processus lorsqu'il y avait une E/S, mais sa préemption. On pouvait très bien avoir un processus qui n'utilisait pas les périphériques et qui monopolisait l'UC pendant une heure. Donc, à peu près, multiprogrammation est plus général et/ou plus primitif.

est-tu en train de parler de la différence entre le multitâches coopératif et préemptif ? Ca pourrait être intéressant d'aborder le sujet dans la section exécutif.--Silex6 (d) 12 septembre 2009 à 18:54 (CEST)

En fait, j'évoque une époque (OS/360, 1966 - rassure-toi, je n'ai pas connu , j'ai à peu près le même âge que toi) ou la coopération était assez faible, voire ressemblait à : premier arrivé, premier servi. Le seul intérêt était d'occuper l'UC au maximum pour des traitements plutôt style batch. Lorsque l'un s'interrompait, on passait au suivant, etc. Ce n'était pas vraiment du multi-tâches, mais on "multiprogrammait" en quelque sorte, puisqu'il y avait plusieurs programme en cours d'exécution en mémoire, sans apparence de simultanéïté (qui caractérise plutôt le multitâche, à mon sens).

Ces techniques étaient celle des précurseurs des exécutifs d'aujourd'hui. je pensait aborder ce sujet dans la section histoire.

Je pense que c'est effectivement une bonne idée de commencer par ce que tout le monde a à l'esprit en matière de SE, puis d'expliquer les différentes évolutions qui nous ont amené là dans une section à part.

Sinon, les expressions "coopératif" et "préemptif" seront utiles, c'est sûr. Ce que j'en sais, c'est que la différence existe en particulier à propos des threads : si les threads existent dans l'espace noyau, ils peuvent être préemptés, alors que s'ils sont implantés dans l'espace utilisateur (à l'intérieur d'un processus), il faut les programmer pour les faire collaborer (sinon un des threads peut utiliser tout le temps alloué au processus). Mais peut-être penses-tu à autre chose, directement au niveau du système ?

Fonctionnalités et Histoire

C'est clairement en chantier, donc je laisse.

Composition

• pour la composition, je pense qu'il faudrait introduire l'idée suivante : les fonctionnalités doivent être prise en charge par des éléments logiciels. Exemple : manipuler des fichiers (fonctionnalité) -> système de gestion de fichiers (élément logiciel). Il n'y pas toujours homologie, comme sous Linux où les périphériques en général se manipulent via le SGF. Avec une autre particularité : certains de ces éléments appartiennent au noyau, d'autre non. Ça pourrait donner une idée claire de ce dont il est question.
• l'inventaire ne me paraît pas encore assez organisé : peut-être en commençant par la déf du noyau, puis en détaillant les éléments usuels du noyau (l'exécutif), ceux qui y sont parfois, et les autres. Tu pourrais terminer par l'interface haute (interface de prog, utilitaires, IHM) et l'interface basse (pilotes). À toi de voir...
• sur l'API, même remarque que pour l'intro.
• pour chercher des poux : comment l'interface de programmation peut-elle faire partie du SE si elle est intermédiaire entre le SE et les applications ? Ou ferait-elle partie des utilitaires ? Je n'attends pas de réponse à cette question, mais c'est pour te demander de préciser encore les définitions.

• je ne connaissais pas le terme d'exécutif, mais ce qu'il recouvre me paraît clair.

Je ne suis pas sûr que ca soit le terme approprié. De nombreux articles parlent du kernel, ce qui introduit une confusion, vu que le noyau (kernel en anglais) peut contenir une grande partie du SE, ou au contraire ne pas exister sur certains SE...

D'accord avec toi : le noyau, c'est vraiment autre chose. Encore que ta description recouvre pour moi (de manière intuitive) tout ce qu'on s'attend à trouver dans un micro-noyau (hors interfaces).

Biensur! dans une archi à micro-noyau, le micronoyau contient uniquement l'exécutif.

J'ai sous les yeux un schéma qui distingue (toujours cas Linux) trois composants principaux : le composant d'E/S (fichiers, périphériques, réseaux, tous 3 unifiés sous VFS), le composant de gestion de mémoire (mémoire virtuelle, gestion des pages présente en mémoire, cache de pages), le composant de gestion des processus (gestion des signaux, création et terminaison des processus, ordonnancement de l'UC). En haut, l'interface des appels système, en bas le répartiteur d'interruptions. Si le terme exécutif n'est pas standard, je crois que les 7 composants (logiques) suivants seraient admissibles :

• interface haute : appels système ou API
• composant de gestion de fichiers
• composant de gestion de périphériques
• composant de gestion du réseau
• composant de gestion de la mémoire
• composant de gestion des processus
• interface basse : gestion des interruptions

A ce moment là, ça risque de faire un peu double emploi avec la section sur les fonctionnalités.

Je pense à l'avenir supprimer la section sur les fonctionalités. celle-ci fait doublon avec la composition, section dans laquelle les fonctionalités de chaque composant sont déja détaillées.

Parfait

• sur le noyau : parfaitement clair. Un détail : il existe des systèmes sans noyau (pas de protection), notamment ceux avant que la possibilité matérielle existe.

Voilà, c'est tout pour l'instant. À nouveau : je n'ai pas de réponse claire à tous les problèmes que soulève la rédaction d'un tel article. Et encore une fois : bon courage.--Juju2004 (d) 11 septembre 2009 à 13:12 (CEST)

Quelques exemples

Salut. Je viens de jeter un coup d'œil au tableau des exemples, et je trouve ça ÉNORME ! Quel travail... Sur le reste, j'ai encore des remarques, mais je te laisse un peu avancer, sinon ça va commencer à ressembler à du harcèlement.--Juju2004 (d) 12 septembre 2009 à 14:16 (CEST)

Salut. il y a tout juste 20 SE différents. et les infos sont tirées des pages détaillées sur chaque SE. le tableau final prends beaucoup de place. faut-il raccourcir ? quoi enlever ?--Silex6 (d) 12 septembre 2009 à 18:47 (CEST)

Je maintiens : je trouve vraiment ce tableau synthétique très intéressant. Ce serait vraiment dommage de le raccourcir. Mais il est vrai qu'il existe un article Liste des systèmes d'exploitation et un modèle {{Palette Systèmes d'exploitation}} qui marchent un peu sur le même sujet (avec moins de précision au niveau fonctionnalités). Pour l'instant, j'aurai tendance à laisser : si l'article final est gros, 20 exemples, c'est loin d'être de trop.

Suggestion : je viens de remarquer que ton tableau est conçu d'après ta section caractéristiques (j'ai mis du temps !) ce qui est logique. Mais pourquoi ne pas rapprocher les deux ? En fait, je trouve qu'une section "typologie" serait intéressante. Ensuite :

• Une sous-section "caractéristiques" qui décrit les caractéristiques à utiliser pour différencier les SE de manière pertinente (exactement comme tu l'as fait). Pour enfoncer une porte ouverte : il est par exemple plus pertinent de différencier un SE d'un autre par le fait que l'un sera en multi-utilisateurs que de remarquer que l'un est un produit MS et l'autre Mac.
• Une sous-section avec ton tableau d'exemples, qui viendrait parfaitement illustrer le propos.

Cette section "typologie" serait placée tout au début, pour montrer un peu de quoi l'on parle. Le débutant serait assez bien introduit dans le sujet, avant une description plus poussée des composants.--Juju2004 (d) 13 septembre 2009 à 12:34 (CEST)

J'ai rajouté, il y a quelque jours, une introduction concernant le lien entre l'utilisation cible et la composition exacte du SE. ca se trouve en en-tête de la section composition. faisant suite à ta remarque, j'ai ajouté une mention dans l'en-tête de l'article.

Exécutif

INFO IMPORTANTE : Au détour de mes lectures, j'ai trouvé le terme "exécutif". C'est un terme Windows et il n'y a pas forcément d'équivalent pour tous les SE. Je suis un perdu dans l'archi Windows, mais il me semble que l'exécutif Windows gère les objets (le gestionnaire d'objet semble être un ensemble de service utiles à différents "trucs"), les E/S, les processus, la mémoire, le cache, la config, et qu'il y a aussi un moniteur de sécurité. Comme ce terme n'est pas générique, je crois que ça pose deux problèmes :

• un problème wikipédien : ça sent la guerre éditoriale ! (les quelques pourcents de linuxiens n'apprécieront pas forcément)

effectivement il y a un risque de guerre d'édition, et il serait bon de trouver le terme adéquat. Pour info, je l'ai pris de AmigaOS, un SE plus ancien que Windows et Linux, multitâches et sans noyau (exo-kernel). voir aussi l'article en:Exec (Amiga) qui parle de kernel = noyau pour cette fonctionalité.--Silex6 (d) 13 septembre 2009 à 11:42 (CEST)

PS - voir aussi la description de cet ouvrage: [1] --Silex6 (d) 13 septembre 2009 à 11:52 (CEST)

Je pense qu'il faut agir avec prudence, parce que sous Unix/Linux il n'existe rien de ce nom : les composant d'E/S, de gestion de mémoire et de gestion des processus sont bien distincts. Et le système de gestion de fichiers fait partie du composant d'E/S, alors que dans Windows ils sont l'un dans l'exécutif, l'autre en dehors (sauf erreur de ma part). Il y a un risque de confusion entre une idée générale (celle que j'avais comprise au début) et un ou des cas particuliers (Windows ou AmigaOS). Il faut qu'à l'arrivée tout le monde entende bien la même chose sous le même mot (même problème qu'avec le mot SE, finalement). D'autre part, dans la description de l'ouvrage auquel tu fais référence, je comprends "multitasking executive" comme "système multitâche" (ou quelque chose d'avoisinant). En tout cas, ça ne permet pas de trancher définitivement.

• un problème plus grave : ça fait référence à une organisation particulière de SE.

A mon avis, ce serait plus simple (et plus intéressant) de

1. partir avec des unités plus petites et communes (gestion des E/S, gestion des processus, etc.), un peu comme là : Noyau_de_système_d'exploitation#Fonctions_g.C3.A9n.C3.A9ralement_remplies_par_un_noyau, mais en insistant sur les autres fonctions (gestion des fichiers, sécurité, réseau, système graphique (cas Windows), sécurité, etc.)
2. décrire les regroupement d'unités qui existent dans certains SE (et leur but) :
   • l'exécutif pour windows
   • VFS pour linux, qui chapeaute la gestion de périphériques, le réseau et les fichiers.

De manière générale, je trouve que l'article commence vraiment à ressembler (au niveau structure) à ce qu'on peut en attendre. Je serais parti plus dans le technico-technique d'emblée (ce qui aurait été une erreur), et je trouve que ton approche générale plutôt descriptive est vraiment très bien.--Juju2004 (d) 12 septembre 2009 à 23:48 (CEST)

15 septembre 2009, la synthèse

Bonjour. maintenant que l'article est plus ou moins complet - toutes les sections ont été remplies - il serait bon de faire une synthèse des points en suspens.

• API, appels systèmes et librairies, la distinction ?

la discussion porte sur la bibliothèque ANSI C, une bibliothèque d'API normalisé (par ANSI), et qui permet d'appeller des fonctions du SE. A mon avis cette bibliothèque est un outil de développement, c'est un outil normalisé et disponible pour de nombreux SE (Windows y compris), mais il ne fait pas partie du SE.

Tout à fait. Comme je te l'avais écrit ci-dessus, ce qui est particulier, c'est que l'interface haute des POSIX n'est pas une API, à la différence de celle des Windows. Il vaut mieux parler, je crois, d'abord d'interface haute (que sollicitent les applications), puis distinguer deux cas.

N'est-ce pas un peu trop détaillé ? ce genre de détail (interface haute / basse) aurait plutot sa place dans l'article interface de programmation, non ?

• Exécutif, est-ce le terme approprié ?

J'ai choisi le mot moteur d'exécution en publiant l'article. à voir...

Je t'ai mis mes doutes ci-dessous.

• concept d'entrée/sortie avant de parler d'image numérique.

OK sur le principe, mais la phrase le SE s'occupe de gérer les entrées/sorties dite telle quelle c'est du jargon de technicien, et pour un néophyte ca ne veut rien dire. Alors je préfère partir d'un cas concret, et amener le lecteur au concept d'entrée/sortie.

• typologie de SE.
• la section histoire
• qu'est-ce qui manque par rapport à l'article actuel ?

L'article a été publié dans Système d'exploitation. le bandeau en travaux sera retiré une fois les travaux de détail terminés.

J'arrive un peu après la bataille. J'ai été occupé, mais je vois que toi aussi, parce que le résultat est vraiment intéressant. Tu as eu raison de publier, car l'article est en tous points supérieur au précédent. Cela dit, je vois encore pas mal de problèmes, mais c'est plutôt dans le détail ou la formulation, et il faut que je prenne le temps de lire bien ce que tu as fait.

Je t'en mentionne quelques uns que j'ai vus en passant :

• je suis allé voir l'article Moteur d'exécution, et j'ai bien l'impression que ça ne désigne pas le coeur du SE, mais une application qui sert d'environnement d'exécution, comme dans le cas d'un langage interprété ou du JRE. Je continue à penser qu'il faut diviser cette section en ses éléments de base.

en effet, la définition du moteur d'exécution telle qu'elle est dans l'article à ce sujet ne corresponds pas du tout.

le terme Ordonnanceur, c'est mieux ?

• sur les années 60 : « Les systèmes d'exploitation ont alors été construits de manière à permettre l'exécution simultanée de plusieurs programmes » : je pense que la formulation est maladroite, parce qu'on n'est pas dans des commutations toutes les x millisecondes. C'est plutôt (au début) le chargement simultané de plusieurs programmes dont l'un prend le relais de l'autre lorsque cet autre est bloqué sur une E/S.

oui, c'est exactement ce que j'ai écris, non ? .

• dans la section "Composition", le noyau me semble hétérogène aux autres éléments. Comme s'il se superposait à ces composants sans en faire partie, en un sens. Je pense qu'il faudrait l'isoler () d'une manière ou d'une autre. Peut-être une section "structure", avec la structure abstraite : le noyau et les couches autour, avec la notion de service fourni par la couche n à la couche n+1, les micro (exo, etc.) noyaux. (Dans cet section, l'idée d'"exécutif" aurait largement sa place, car c'est une partie de la structure qui assemble les éléments de la partie composition) En gros : 1. les éléments ; 2. la structure.

parce que le noyau n'est pas un ensemble qui assure une fonctionalité en particulier, contrairement au sujet des autres sections. mais je ne vois pas de moins mauvaise place ou le mettre . A part peut-être avant la section moteur d'exécution.

• Je m'arrête là pour l'instant...

De manière générale, en adoptant le point de vue du non-connaisseur, je me dis qu'il faudrait parfois être plus explicite. Un simple exemple sur le SE : « Il sert d'intermédiaire entre les logiciels applicatifs et le matériel et offre une manière unifiée d'exploiter les périphériques de l'ordinateur par l'intermédiaire d'interfaces de programmation banalisées. » Question de non-connaisseur : pourquoi diable a-t-on besoin de cette manière unifiée ?

c'est expliqué dans la phrase suivante de la section interface de programmation:

« L'utilisation de la même interface de programmation quel que soit le matériel, le protocole ou le système de fichier concerné assure la portabilité des logiciels applicatifs: Un logiciel applicatif donné pourra fonctionner sur différents ordinateurs, quels que soit leur configuration, en particulier quel que soit le matériel, le système de fichier ou le protocole utilisé. »

la phrase est cependant trop longue pour être placée telle quelle dans la section d'introduction.

Est-ce donc si compliqué que ça ?

c'est une large palette de programmes. c'est écrit plusieurs fois dans l'article...

Vu comme c'est écrit très simplement, ca a pas l'air très compliqué, mais à mettre en oeuvre c'est une autre histoire...

etc. En gros : à quoi sert finalement ce truc (le SE) ?

Je réfléchis aux points en suspens, mais je ne vais pas pouvoir te donner de réponse plus complète avant demain soir (au mieux). En tout cas,  ! --Juju2004 (d) 14 septembre 2009 à 21:23 (CEST)

merci

Nouvelles suggestions

Je n'ai pas trop le temps, alors voici quelques éléments de réflexion (à partir de la version du 15 vers midi).

Le plan d'ensemble

Je te propose un ré-agencement des éléments de la manière suivante (avec quelques indications) :

1. Typologie (avec phrase du type : Il existe quelques caractéristiques générales qui permettent décrire les systèmes d'exploitations.)
   1. Caractéristiques essentielles
      • multi-tâches
      • multi-utilisateurs (dépend de multi-tâches)
      • temps réel
      • multiprocesseurs
      • utilisation
      • noyau
      • type de matériel
   2. Exemples (Avec ton tableau, ou un renvoi vers la section des exemples.)
2. Histoire (Je discuterai plus loin du contenu)
3. Composants
   1. Gestionnaire de processus (ordonnancement avec trois principes : equité = que des processus équivalents aient un temps processeur équivalent, équilibre = utilisation optimale des ressources, partage des ressources entre utilisateurs. De plus, la possiblité de moduler en fonction d'une politique (les priorités).)
   2. Gestionnaire de mémoire

J'ai créé une section séparée concernant la gestion de la mémoire mémoire virtuelle parce que ce n'est pas une fonctionalité de l'ordonnanceur. Le sujet est complexe et la section est par conséquent un peu longue.--Silex6 (d) 17 septembre 2009 à 13:22 (CEST)

Je vais jeter un oeil

1. 1. Gestionnaire de fichiers
   2. Gestionnaire d'E/S (avec la question des interruptions : comment un disque signale-t-il que le bloc a été copié en mémoire ?)
   3. Gestionnaire Réseau
   4. Interface de programmation
   5. Interface avec les périphériques (= les pilotes)
   6. Composant graphique (??)
2. Organisation
   1. Le noyau
   2. les couches autour du noyau
   3. Exemples (Exemples de rassemblement des éléments en unités plus grosses)
      • Exécutif sous windows (indiquer les composants rassemblés)
      • VFS sous linux (indiquer les composants rassemblés).

J'ai placé l'organisation générale (architecture) avant la composition, ca me semble plus logique.--Silex6 (d) 17 septembre 2009 à 20:27 (CEST)

Je me réponds à moi-même: C'est pas une bonne idée, la compréhension de l'architecture nécessite la connaissance préalable des différents composants. je l'ai donc remise à la fin.--Silex6 (d) 17 septembre 2009 à 20:27 (CEST)

1. Les logiciels fournis avec le SE (Par ordre de complexité croissante)
   1. Les utilitaires (différence claire avec une application ?)
      • configuration
      • manipulation des fichiers
      • shell
   2. L'interface graphique (??)
      • le système graphique (linux, parce que sous windows il est directement dans le SE)
      • le bureau (exploitation de l'interface graphique de manière

Le système graphique fait à mon avis partie du système - comme son nom l'indique. à ne pas confondre avec l'environnement de bureau. Je pense que dans l'état actuel la distinction est assez claire dans l'article.--Silex6 (d) 17 septembre 2009 à 12:16 (CEST)

Tout juste ! C'est typique, comme tu dis. Je pense (voir ta réponse ailleurs) que plutôt qu'une déf, tu as raison de donner des éléments typiques.

1. 1. les applications évoluées (Juste à évoquer)
      • traitement de texte
      • navigateur internet, etc.

Dans mon idée, il s'agit d'un article généraliste sur LES SE. et non pas un article sur certains SE en particulier. Si un éditeur a décidé de mettre en bundle des logiciels qui n'ont rien à voir avec le SE, est-ce qu'il faut le mentionner dans un article généraliste ? j'en doute.--Silex6 (d) 16 septembre 2009 à 21:15 (CEST)

Encore une fois : d'accord. Tu peux peut-être repréciser une distinction entre utilitaire et application (je n'ai pas regardé les dernières versions, donc : si ce n'est pas déjà fait).

1. Quelques exemples (S'ils n'ont pas été déplacés ci-dessus).
2. etc.

Je pense que la distinction entre composants et organisation est fondamental pour bien comprendre le SE. Les composants remplissent chacun un rôle bien délimité. Leur organisation dépend du SE (comme tu l'as très justement écrit, un micro-ordinateur ou un serveur n'ont pas besoin de la même interface graphique, par exemple).

Introduction

1. J'aurais tendance à mettre, après la première phrase, ceci :
2. En effet, chaque élément matériel (processeurs, disque, moniteur, etc.) ne comprend que le langage machine. Si chaque application programmait elle-même ces élements matériels, cela poserait trois types de problèmes :

• des problèmes de complexité et de dépendance vis-à-vis du matériel ;
• des problèmes de concurrence entre les applications

1. Sur la question de l'image numérique, je pense qu'il y a une idée un peu ambigüe la-dessous. Prends le cas Linux : le SE assure la gestion du moniteur, du clavier, de la souris. L'idée d'image numérique me semble d'un autre ordre.

Parce que Linux n'est qu'un noyau, et pas un SE complet. en plus il est basé sur un SE (Unix) qui date d'avant l'arrivée des interfaces graphique. De mon point de vue le X Window System fait partie intégrante du SE, même si il est mis en oeuvre par un service hors du noyau.--Silex6 (d) 16 septembre 2009 à 22:34 (CEST)

Tout à fait pertinent. J'ai tendance à l'oublier... Mais ça continue à poser le problème de la délimitation du SE et des bibliothèques logicielles autour. Quelles sont le bibliothèques qui font "réellement" partie du SE ? (Je n'ai pas la réponse, évidemment). On peut prendre le cas d'OpenGL, bibliothèque 3D pour X-Window system. Dedans, dehors ?

La bonne réponse est: ca dépends des SE. Tu sais, il existe des librairies d'includes pour intégrer un ordonnanceur dans des logiciels applicatifs pour DOS... L'article indique une liste de fonctions qui sont typiques des SE, rien de plus.--Silex6 (d) 17 septembre 2009 à 20:44 (CEST)

1. le SE n'est pas fourni qu'avec des utilitaires, mais presque toujours avec des applications.

Histoire

En gros, c'est bon. Je pense qu'il manque quelques épisodes et quelques précisions. Dans l'ordre :

• « L'idée est alors venue d'isoler les instructions routinières dans un programme séparé. Un programme qui réside continuellement dans la mémoire, quel que soit le programme en cours d'exécution. ». Ces instructions ou bloc d'instructions routinières étaient souvent liées à la programmation du matériel, et ce programme résidant fut le premier embryon de SE.
• Pour les micro-ordinateurs, il manque un peu d'ordre et de continuité :

1. on créé le Altair
2. il est difficile à programmer (et donc limité à des hobbyistes)
3. Allen et Gates développent le BASIC
4. Kildall et le CP/M
5. 1980 : IBM conçoit l'IBM PC et achète le BASIC de Gates. IBM demande à Gates un SE, et Gates les envoie vers Kildall. Kildall refuse de traiter avec IBM. Alors Gates rachète le DOS à Seattle Computer Products et vend le pack DOS/BASIC à IBM.
6. Jobs et Xerox
7. 1984 : macOS
8. 1984 : Stallman : GNU, pour un système cohérent de logiciels (SE large ) afin de remplacer UNIX.
9. 1985 : windows 1.0, qui s'inspire du mac.

Windows 1.0 n'est pas un SE. comme indiqué à la note 13, c'est un environnement de bureau.

Je n'avais pas lu la note 13 ! C'est donc un environnement de bureau construit sur le SE MS-DOS ?

exact. jusqu'à la sortie de Windows NT et 95.

Je laisse quelques dates, et puis :

1. fin des années 80 : guerre des UNIX, entre BSD et System V (d'AT&T). Incompatibilités grandissantes.

Parler de guerre me parait exagéré. A mon avis s'est plutôt révélateur d'une saine conccurence. Après tout l'interopérabilité dépends du bon vouloir des éditeurs. Vu sous cet angle je me demande si un paragraphe est justifié pour un phénomène aussi ordinaire (dans le marché en général)...

L'expression "guerre des UNIX" ou "guerres des UNIX" est une expression standard (surtout en anglais, voir en:Unix wars). Le fait en lui-même a peu d'importance, c'est vrai, mais il est à l'origine de la définition de POSIX par l'IEEE. A ma connaissance, mais c'est à vérifier, c'est une des première standardisations dont l'origine est dans l'action des utilisateurs. Voir aussi [2].

1. ? : POSIX

Ca peut être intéressant d'expliquer le but de POSIX dans la conccurence entre les Unix.

-> Le libre

1. 1990 : Linux sous licence GPL : le projet de Stallman va aboutir.
2. 1992 : L'université de Berkley, en manque de fonds, abandonne BSD et le met sous licence GPL. C'est la naissance de FreeBSD, un temps bloqué par des procédures en justice d'AT&T.

Peut-tu me donner les sources à ce sujet, en particulier les procédures en justice. ce que j'ai trouvé sur le net ne corresponds pas. [3].--Silex6 (d) 17 septembre 2009 à 13:47 (CEST)

Je regarde ça pour des détails.--Juju2004 (d) 17 septembre 2009 à 21:26 (CEST)

Voilà les réfs

1. Tanenbaum p.768 (fin section 10.1)
2. en:USL_v._BSDi, avec USL qui appartenait à Bell Labs d'AT&T. ce procès a bloqué tous les descendants de BSD.
3. voir aussi : en:Berkeley_Software_Distribution : « The lawsuit slowed development of the free-software descendants of BSD for nearly two years while their legal status was in question, and as a result systems based on the Linux kernel, which did not have such legal ambiguity, gained greater support. Although not released until 1992, development of 386BSD predated that of Linux, and Linus Torvalds has said that if 386BSD had been available at the time, he probably would not have created Linux.[5] »--Juju2004 (d) 18 septembre 2009 à 20:28 (CEST)

Ca permet d'avoir l'origine des 4 grands systèmes : Windows évidemment, mais aussi MacOS X (par FreeBSD), UNIX, et Linux (que tu as bien mis).

Autres

Sur l'interface de programmation, je ne connais pas du tout cette idée de logiciel serveur, aussi je pense que ce serait bien que tu expliques un peu ce que c'est.

c'est typique des archi micro-noyau: un processus en espace utilisateur s'occupe de traiter certaines fonctionalités. c'est utilisé entre autre pour les système de fichiers. Les logiciels applicatifs passent par une API pour envoyer les requêtes.--Silex6 (d) 16 septembre 2009 à 21:24 (CEST)

Sur le réseau, j'aurais tendance à donner une traduction entre parenthèses en modèle TCP/IP (le plus courant). Et à préciser que le modèle OSI n'est en général pas implémenté en tant que tel. Je pense aussi (d'après ce que je lis) que tu devrais mettre les choses ainsi :

1. 5 à 7, les applications (mise en forme du message),
2. 1 à 2 le matériel (les trames d'un point à un autre)
3. il reste les niveaux 3 et 4 (réseau -> routage, et transport -> connexion et fiabilité). Les détailler un peu.

Enfin, une petite requête. Je vois que tu commences à recevoir des félicitations méritées, et ça m'arrangerait bien que tu me mettes un petit message par rapport à ma participation (au moins sur ma page de discussion). J'ai en effet besoin parfois d'un peu de crédit pour appuyer certaines de mes interventions sur WP. Merci d'avance.--Juju2004 (d) 16 septembre 2009 à 16:15 (CEST)

C'est une importance réorganisation de l'article. je vais donc mettre la version fraîchement publiée dans le bac à sable, puis la réorganiser selon le plan que tu propose, histoire de voir ce que ca donne.--Silex6 (d) 16 septembre 2009 à 16:45 (CEST)

Peut-être même plus précisément, je verrais bien une distinction entre "composants fonctionnels" (gestionnaire de ceci et de cela, en bref tout ce qui remplit une fonction, qui ajoute une fonctionnalité) et "composants structurels" (noyau, exécutif, etc. qui concernent la structure du SE). Mais je ne sais pas si c'est très clair.--Juju2004 (d) 16 septembre 2009 à 17:05 (CEST)

Merci pour le PS !--Juju2004 (d) 16 septembre 2009 à 19:37 (CEST)

Introduction

L'introduction de l'article en anglais en:Operating System présente le système d'exploitation comme un ensemble de programmes qui rends des services aux logiciels applicatifs. c'est une excellente explication de à quoi sert un SE - question dont la réponse n'est pas évidente dans la version en francais.--Silex6 (d) 19 septembre 2009 à 11:46 (CEST)

Ca rejoint un peu l'idée d'abstraction que j'avais mentionnée il y a quelques jours. Rendre un certain nombre de services bien précis, c'est masquer la complexité couche matérielle, donc en fournir une abstraction. De manière plus générale, cette logique de service se retrouve avec chaque couche : noyau pour couche1, couche1 pour couche2, etc. En tout cas, c'est vrai que l'intro anglaise est plutôt bonne.

PS. je pense que tu verras que j'ai posté une réponse à l'intéressante remarque d'Outs.--Juju2004 (d) 19 septembre 2009 à 13:27 (CEST)

Le marché

Bonjour. je travaille actuellement sur la section le marché. La section concernant Microsoft et le droit à la concurrence est un peu long, mais je sais pas comment raccourcir, c'est déja le résumé de près de 50 pages de documents juridiques .--Silex6 (d) 20 septembre 2009 à 00:29 (CEST)

Salut. Quand je lis ta section sur le marché des SE, j'y vois presque un article indépendant. Avec une sous-section histoire (une histoire des SE, mais du point de vue de leurs succès et échecs commerciaux et non plus de leurs fonctionnalités), ce serait un bon article. Encore du travail !!!

Pour ce qui est de l'article actuel, je pense comme toi que la section est un peu longue. Mais il est dommage de jeter tout cela, d'autant que c'est bien mieux écrit que là : Microsoft#Affaires_judiciaires (d'où l'idée précédente d'un article indépendant). J'aurais tendance à garder l'intro (avec ajout de la date à laquelle elle est valide : 2009). Ensuite, (je taille dans ton texte) :

Dans un décret datant de 1995, le département de la justice des États-Unis interdit à Microsoft de conclure des contrats avec les fabricants de matériel informatique (Dell, Compaq, Fujitsu) pour inclure le système d'exploitation Windows dans leur matériel. Il interdit également à Microsoft de conclure des contrats pour la vente liée de ses produits avec tout autre produit logiciel. voir Licence d'exploitation OEM. Des pratiques que le département de la justice juge contraire au Sherman Antitrust Act. Ce décret n'est pas appliqué et lorsque la société est attaquée en justice pour la vente liée de son navigateur web Internet Explorer dans le système d'exploitation Windows 95. Microsoft obtient finalement l'annulation du procès sur l'argument que la justice n'est pas équipée pour juger du bien fondé du design des produits de haute technologie (sic).

Entre 1999 et 2000 une enquête est ouverte concernant la position de Microsoft. L'enquête, menée par les juge Thomas Jackson et Richard Posner (ce dernier est spécialiste du droit à la concurrence) amène à la conclusion que la position de monopole de Microsoft sur le marché du compatible PC est bien protégée par une abondance de logiciels applicatifs construits pour Windows. Microsoft échappe de peu à la scission en deux sociétés. La société est par contre dans l'obligation de publier les spécification de ses technologies, en particulier les interfaces de programmation et les protocoles réseau [29].

En 2007 Microsoft est condamné par la Commission Européenne à une amende de près de 500 millions d'Euros pour violation de l'article 82 du traité CE et l'article 54 de l'accord EEE (des textes relatifs au droit de la concurrence et l'abus de position dominante). [30]

C'est moins bien, c'est moins précis, mais l'essentiel y est.--Juju2004 (d) 20 septembre 2009 à 11:16 (CEST)

Après réflexion c'est un peu mon idée: enrichir un peu cette section, puis la placer dans l'article Microsoft#Affaires judiciaires, puis laisser un résumé dans l'article Système d'exploitation.--Silex6 (d) 20 septembre 2009 à 15:23 (CEST)

J'ai mis de coté la section complète, et remplacé cette section par un résumé. l'intro a été placé dans l'en-tête de la section marché.--Silex6 (d) 20 septembre 2009 à 23:26 (CEST)

Terminologie informatique

Bonjour,

Merci pour ton excellente initiative de classer la terminologie informatique par thèmes. Je suis pour tout ce qui va dans le sens de la structuration. Sur le classement que tu proposes, mon avis serait de séparer les sociétés et les organismes, ce n'est pas sur le même plan. Sinon, essaye de ne pas trop révolutionner l'article terminologie informatique. Il faudrait quand même capitaliser sur ce qui a été écrit sur l'origine des termes et sur l'usage. Je n'ose pas enrichir ce que tu as mis car c'est dans un bac à sable personnel (?). Tu peux peut-être ventiler tes réflexions vers l'article dès maintenant (sans enlever ce qui y est déjà). Au passage, je te signale que j'ai créé l'article qualité logicielle ; la Wikipedia franophone a du retard sur les autres sur ce thème également très important. Bon travail.Pautard (d) 14 octobre 2009 à 09:59 (CEST)

Bonjour. je ne pense pas que ca soit une bonne idée de trop enrichir la (très longue) liste des abréviations en informatique. en fait j'essaye de faire une liste classée des abréviations courantes, basée sur la page abréviations en informatique, elle-même éclatée en 26 pages (une pour chaque lettre de l'alphabet), en mettant le minimum d'informations (l'abréviation, et si le sujet est important, alors je met une courte explication).

Je ne prévois pas d'enlever quoi que ca soit dans la page terminologie informatique, tout au plus de rajouter une section avec un rapide survol des abréviations courantes.

Concernant l'article qualité logicielle, ca m'intéresse (j'ai travaillé dans ce domaine), mais je n'ai pas le temps de m'en occuper maintenant. Ce que je peut dire c'est qu'il s'agit d'un sujet hautement subjectif et limite ésotérique, et donc le sourcage des textes est indispensable !--Silex6 (d) 14 octobre 2009 à 12:42 (CEST)