UNIX, POSIX et SUS : références et à‑propos

Pour garder une trace et regrouper ces liens ensemble.

POSIX, tout le monde (les gens concernés) connait. SUS est moins connu. Il existe un rapport entre les deux, historique et concret. Se pose aussi la question de la conformité des environnements informatiques à POSIX ou SUS, sachant que la conformité à SUS implique la conformité à POSIX.

Rappel de la signification des acronymes

• POSIX = “Portable Operating System Interface” = « Interface portable, de système d’exploitation ». Il manque le X : il a été ajouté pour faire une référence à UNIX.
  
• SUS = “Single UNIX Specification” = « Seule et unique spécification d’UNIX ». UNIX n’a rien à voir avec le mot « unique », c’est seulement en français que les deux mots semblent phonétiquement similaire.
  
• UNIX = UNICS, ça n’est pas un sigle (mais UNICS en est un).
  
• UNICS = “UNiplexed Information and Computing Service” = « Service uniplexe d’information et de traitement de l’information ». Il faut comprendre « uniplexe » par opposition à « multiplexe » et étendre la notion de traitement de l’information à celle du calcul (“computation” en Anglais, qui a donné le mot “computer” = « ordinateur »).

POSIX et SUS

Les deux seuls références publiquement accessibles que je connaisse :

• The Open Group Base Specifications Issue 7, IEEE Std 1003.1™-2008 (pubs.opengroup.org), alias POSIX.1-2008
• The Single UNIX® Specification, Version 2 (pubs.opengroup.org), alias SUSv2

SUS version 2 seulement est accessible publiquement. La dernière versions, SUS version 3 est accessible moyennant paiement. L’intérêt d’acheter la dernière version dépend de ce qui est en jeux. La dernière version en travail, est la version 4.

POSIX vs SUS

Jusqu’à aujourd’hui, je ne connaissais que POSIX et pensais que SUS était un ancêtre périmé et non‑standardisé de POSIX. J’ai pris conscience de ce qu’est SUS en cherchant la spécification de CURSES (la librairie pour les applications en mode texte sur les consoles), dont j’avais appris qu’elle était « définie par POSIX » (finalement pas exactement), mais dont je ne trouvais aucune trace dans ma copie locale de POSIX.1-2008. Je l’ai finalement trouvé dans un document qui ressemblait beaucoup à la spécification POSIX.1-2008, mais différent tout de même, et plus ancien. Je ne comprenais plus et ne m’expliquais pas qu’un document plus récent qu’un autre plus ancien, puisse être moins complet…

Je me suis donc mis en quête de comprendre ce qui relie et distingue, POSIX et SUS.

Pour résumé très succinctement la chronologie et les relations :

1. D’abord il y a eu le système d’exploitation Multics, dans la seconde moité des années 1960, jusqu’au années 1970 principalement, et entièrement disparu depuis 2000.
2. En 1970, né le système d’exploitation Unics, nommé d’après Multics. Contrairement à Multics, Unics n’était pas multiplexé, et c’est ce qu’exprimait son nom : il fournissait des fonctionnalités similaires à celles fournies par Multics, mais il n’exécutait pas les applications en temps partagé; il était de conception plus simple et moins ambitieuse (le multitâche est entré dans le monde d’UNIX plus tard).
3. Pas très longtemps plus tard, environ en 1971 ou 1972, Unics et renommé UNIX, un nom qui ne semble pas être un acronyme.
4. Plusieurs systèmes d’exploitation dérivés d’UNIX voient le jour, plus ou moins compatibles entre eux.
5. En 1988, l’IEEE (“Institute of Electrical and Electronics Engineers”), un organisme qui entre autre est l’auteur de standardisations, décide de créer un standard pour les interfaces avec les systèmes d’exploitation, de manière à ne pas gaspiller le développement des applications et à les rendre portables d’un environnement informatique à l’autre. UNIX est choisi comme base, parce qu’il ne présentait pas de risque de monopole, plusieurs éditeur de logiciels étant impliqués, et non‑pas un acteur unique. Les UNIX étant cependant tous différents bien que très proches, il fallait standardiser cette base commune; POSIX était né.
6. L’IEEE n’étant pas propriétaire de la marque UNIX (parce que c’est une marque), il ne lui était pas possible de proclamer proposer une spécification standard d’UNIX. D’autres parties ont cependant put se le permettre, l’organisation X/Open. Mais ils n’ont pas repris POSIX, qui appartenait à l’IEEE, ils ont créer un autre standard, la SUS, inspirée de POSIX.
7. Plus tard, X/Open devient l’OpenGroup, et POSIX est rapproché de SUS, pour devenir un sous‑ensemble de SUS, SUS devenant alors POSIX + des extensions, auxquelles je crois il est fait référence sous le nom de XSI.

Ce qu’il faut retenir en pratique, c’est que POSIX, constitue le noyaux de SUS, autant qu’il y a toujours un noyaux dans une pêche. À chaque version de SUS, correspond donc une version de POSIX.

Un détail important à ce point‑ci : la version publiquement disponible de SUS et la version publiquement disponible de POSIX, ne concordent pas.

• SUS version 2 date de 1997, et son noyau était le POSIX de l’époque, le POSIX tout court, ou encore POSIX IEEE 1003.
• SUS version 3 date de 2001, et son noyau est POSIX.1‑2001
• SUS version 4 date de 2008, et son noyau est POSIX.1‑2008

Ors, la version publiquement disponible de SUS, est la version 2, et la version de POSIX publiquement disponible la plus récente à la date de ce message, est la version 1‑2008.

Il faut bien l’avoir à l’esprit quand vous consultez l’une ou l’autre : quand vous‑vous référez à SUS, ne vous‑y référez que pour les extensions, comme par exemple X/Open Curses. Pour le reste, référez‑vous à POSIX.1‑2008 ou ultérieur. Dit plus simplement, ne vous référez à SUS que pour ce que vous ne trouvez pas dans POSIX. Pour chaque aspect du standard, prenez des deux documents qui le couvre, le plus récent. Pour les sockets et l’interface réseau, ce sera par exemple POSIX, mais pour Curses/NCurses, ce sera SUS, parce que POSIX ne couvre pas ce domaine.

Quels systèmes sont vraiment conformes à POSIX ou SUS ?

Pour faire court, seuls les systèmes commerciaux sont garantis conformes, parce que la procédure de validation n’est pas gratuite. Ceci exclus donc les dérivés de Linux et les BSD « gratuits ». Il serait probablement possible de les faire valider en les finançant par un coût d’achat modique pour les gens qui les télécharge, mais 99.9% des gens qui les téléchargent trouveraient cela outrageusement intolérable, que de payer 10 cents pour ça, alors que cela suffirait probablement à financer les 30 000€ nécessaire à la validation (quoique que se poserait aussi la question des rythmes de développement, qui rendraient nécessaires, des re‑validations peut‑être trop fréquentes).

Un projet intéressant, de l’équipe de développement du système d’exploitation FreeBSD, de faire tout ce qu’ils peuvent pour rendre l’environnement FreeBSD strictement conforme à POSIX et au C ISO 99 : FreeBSD C99 and POSIX® Conformance Project (freebsd.org).

Deux images. La première est un arbre qui représente l’histoire et les relations entre les dérivés d’UNIX. La seconde est un arbre du même style, pour l’histoire réciproquement dépendante de SUS et POSIX.

Généalogie des UNIX et Unix‑like

Généalogie et histoire de POSIX et SUS

Une autre image de la généalogie des UNIX. Je ne peux plus dire où je l’avais trouvé.

Pas directement à propos de POSIX et SUS, mais utile à lier. Il existe un registre des identifiants de systèmes d’exploitation à l’IANA. Dans ce registre, on trouve les identifiants des systèmes UNIX‑like les plus répandus, ce qui peut être utile pour s’y référer et les distinguer de manière intelligible.

Ce registre n’est pertinent que dans le cadre de l’identification des types d’hôtes sur le réseau Internet (voir RFC 952DOD Internet host table specification). Il n’est pas pertinent pour identifier une plateforme utilisateur en général (il ne distingue par les environnements de bureau, les capacités multimédias, etc).

Le registre : Operating system names (iana.org).

Idem, utile à lier, un registre des noms officiels des types de terminaux : Terminal type names (iana.org).

Intéressant à noter, est que l’IBM-3812-1 / IBM-5553-B01 (jamais entendu parler de celui là avant ), est l’objet d’une RFC : IBM's iSeries Telnet Enhancements (tools.ietf.org).

J’ouvrirai peut‑être un jour un sujet sur le thème confus des terminaux VTnnn.

Assez en rapport, voir aussi : Les standards du C (le langage, ISO/IEC 9899).

Une consultation en ligne bien faite et bien pratique, des pages man : Mankier (mankier.com).

Chaque page man est présentée sous une forme structurée avec un panneau de navigation à gauche, qui ressemble plus aux applications de consultation de fichier d’aide contemporaine qu’à l’archaïsme habituel avec les pages man.

Il est possible de documenter une ligne de commande : site sait reconnaitre la commande, et les options utiliser, pour n’afficher que l’aide spécifique à une ligne de commande en particulier.

J’ignore s’il est possible d’avoir la même chose en local.

Je pensais justement à faire quelque chose de similaire un jour, eh bien ça a finalement été fait par quelqu’un.

Pas un standard, cependant assez intéressant pour être lié ici :

The Art of Unix Programming (faqs.org), Eric Steven Raymond, 1999‑2003.

LSB, Linux Standard Base, est une extension de POSIX. Je ne savais pas que ce standard se définit ainsi, c’est pourquoi je ne l’avais pas mentionné avant. Je croyais c’était à part …

LSB est actuellement à la version 5. Il existe un standard ISO en plusieurs parties, pour la version 3.1. Il existe une procédure de certification LSB, mais elle est critiquée, et apparemment pour de bonnes raisons.

• Linux Standard Base (linuxfoundation.org), pour la présentation sur le site de la fondation Linux ;
• Linux Standard Base — Specifications Archive (linuxfoundation.org), pour les documents de la spécification, pour chaque versions de celle‑ci ;
• Freely Available Standards (standards.iso.org), pour le standard ISO, pour LSB 3.1 (cherchez “Linux Standard Base (LSB) core specification 3.1” dans la page, et lisez bien la licence d’utilisation des documents de l’ISO).

Une vidéo de présentation d’une librairie Python nommée URWID, contient un long prologue sur les types de terminaux et confirme malheureusement l’absence de standard dans le domaine, même maintenant.

Use curses, don't swear — Sean Zicari — 2013


J’en profite pour donner le lien vers un standard quand‑même, même si limité, l’ECMA 48 : Control Functions for Coded Character Sets — ECMA 48 (ecma-international.org).