NuxBSD: Free Infos

Gentoo Menu

Installation alternatives
Manuel de Gentoo pour l'architecture AMD64
Manuel:Parties/Installation/Média/fr
Complete Handbook AMD64 / Versions médias d'installation préoccupations
Manuel complet AMD64 / A partir de l'environnement minimal
Manuel AMD64 Complete / Préparation du réseau
Manuel AMD64 / Mettre l'environnement minimal en place
Manuel complet AMD64 / Construction du système
Manuel complet AMD64 / Construire le noyau Linux
Manuel complet AMD64 / Configuration du processus de démarrage
Manuel complet AMD64 / Configuration du système
Manuel AMD64 Complete / Finition

Xorg

Gentoolkit
Gentoolkit est une suite d'outils destinée à faciliter l'administration d'un système Gentoo. Ce document couvre les bases de quelques uns des outils présents dans cette boîte à outils.

USE
USE Flag
Lors de l'installation de Gentoo (ou de toute autre distribution) l'utilisateur doit faire des choix qui dépendent de l'environnement dans lequel il travaille. La configuration d'un serveur diffère de la configuration d'une station de travail. Une station dédiée au jeu diffère d'une station dédiée au rendu 3D.

Ceci n'est pas seulement vrai pour déterminer quels paquets installer, mais aussi pour déterminer quelles fonctionnalités un paquet doit prendre en charge. S'il n'y a nul besoin d'OpenGL, pourquoi s'embarrasser à l'installer et à le maintenir et pourquoi compiler la plupart des paquets avec la prise en charge d'OpenGL ? Si quelqu'un ne désire pas utiliser KDE, pourquoi s'embarrasserait-il à compiler les paquets avec la prise en charge de KDE si ces derniers peuvent fonctionner correctement sans ?

Afin d'aider les utilisateurs à décider ce qu'ils doivent installer/activer et ce qu'il ne doivent pas installer/activer, Gentoo leur permet de spécifier leur environnement d'une manière aisée. Cela force l'utilisateur à décider de quoi il a réellement besoin et facilite le travail à Portage pour prendre les décisions utiles.

Portage

N new (not yet installed)
S new SLOT installation (side-by-side versions)
U updating (to another version)
D downgrading (best version seems lower)
r reinstall (forced for some reason, possibly due to slot or sub-slot)
R replacing (remerging same version)
F fetch restricted (must be manually downloaded)
f fetch restricted (already downloaded)
I interactive (requires user input)
B blocked by another package (unresolved conflict)
b blocked by another package (automatically resolved conflict)

D-Bus est un logiciel de communication inter-processus permettant à des applications de communiquer entre elles. Hautement influencé par le système DCOP ( (Desktop COmmunication Protocol), est une technologie informatique de communication entre les processus et les composants logiciels d'un système) implémenté dans KDE 2 et KDE 3, il l'a remplacé dans KDE 4.

D-Bus permet à des programmes clients de s'enregistrer auprès de lui, afin d'offrir leurs services aux autres programmes. Il leur permet également de savoir quels services sont disponibles. Les programmes peuvent aussi s'enregistrer afin d'être informés d'événements signalés (parce que gérés) par le noyau, comme le branchement d'un nouveau périphérique.

D-Bus est mis en œuvre en tant que démon (daemon). Les utilisateurs peuvent en lancer plusieurs instances, chacune étant nommée un canal (channel). Généralement, il y a un canal privilégié, nommé le canal système (system channel), et des instances privées pour chaque utilisateur connecté. D-Bus

Initscripts System V UNIX System V, ou System V (soit « système cinq », 5 étant écrit en chiffre romain), est une version du système d'exploitation d'origine UNIX, dévoilée par l'entreprise AT&T en janvier 1983.

System V, par son traitement rigoureux des accès aux données partagées, est une version majeure d'UNIX ; avec le système version BSD, c'est une des deux principales branches de la famille des systèmes UNIX.

La plupart des systèmes UNIX propriétaires (comme AIX, HP-UX, ou encore IRIX) descendent directement de System V1. La raison principale est que ces entreprises avaient acheté une licence UNIX auprès d'AT&T. Bien que Linux ne descende pas directement de System V, il s'en inspire beaucoup du fait que System V a servi de base à l'élaboration de la norme POSIX, que Linux tente de respecter au maximum.

En janvier 1979, American Telephone & Telegraph avait publié la septième édition d'Unix, qui comportait environ 10 000 lignes de code. C'est de cette version que partirent Ken Thompson et des chercheurs de Berkeley pour développer indépendamment un nouveau shell ; peu après (1981), les ingénieurs d'AT&T publiaient la nouvelle version officielle d'Unix, System III.

System V est le successeur du System III de 1982. Cette année-là, le procès intenté en 1975 contre le monopole d’American Telephone & Telegraph était arrivé à son terme : par décision de justice, la compagnie était démembrée, ce qui déboucha entre autres sur la création d’AT&T. Conséquence de ce démembrement, cette nouvelle société obtenait par là-même l’autorisation de commercialiser son système d'exploitation, Unix : pour un montant symbolique, elle le distribua dans un grand nombre d'établissements de recherche (500 sites en 1977, dont 125 universités américaines2).

Le point de départ de cette nouvelle étape est la prise en charge du concept de mémoire partagée par plusieurs processus concurrents. Pour cela, System V attribue systématiquement à chaque processus un identifiant et une clef, qui permettent de gérer, par l'intermédiaire de sémaphores, les priorités d'accès sur un fichier (un segment-mémoire), une file de messages ou un flux de données3,4.

Dans les années qui suivirent la création d’AT&T, il y eut plusieurs groupes de travail successifs pour poursuivre le projet de System V, à commencer par l’Unix Support Group (USG) ; puis il y eut Unix System Development Laboratory (USDL), AT&T Information Systems (ATTIS) et enfin Unix System Laboratories (USL).

Au milieu des années 1980, l’autre variante répandue d’Unix était celle du Berkeley Software Distribution (BSD), développé par l’Université de Californie à Berkeley (c'est pourquoi on parlait alors d’« Unix Berkeley5 »). Depuis la version BSD 4.2, elle intégrait notamment un ingrédient faisant défaut à System V : le protocole d'échange réseau TCP/IP.

Quoique dérivée de la « septième édition » d’Unix, comme System V, elle s’en était considérablement écartée ; de plus, les distributions commerciales créaient autant d’idiomes à l’intérieur des deux philosophies d'Unix. Ainsi, lors d'une conférence Usenix, des représentants d’AT&T portaient des pin’s avec l'inscription : System V: Consider it Standard, tandis que plusieurs constructeurs informatiques proposaient des ordinateurs émulant System V. Les vendeurs de stations de travail professionnelles équipaient presque tous leurs machines d’un système d’exploitation BSD, et leurs prospectus signalaient qu’une migration “4.2 > V” était disponible.

Si AT&T vendait des ordinateurs qui tournaient en version de base sous le System V d’UNIX, la plupart de ses clients connaissaient plutôt les versions des différents fabricants de stations de travail, dérivées du System III d’AT&T. Les utilisateurs pouvaient s'y retrouver grâce à un document synoptique, le System V Interface Definition, qui recensait les options par défaut et le format de sortie des commandes.

En 1984, un groupe de constructeurs informatiques se regroupa au sein de l'initiative X/Open pour un format ouvert, et leur choix se porta sur Unix. X/Open inspira les dirigeants d’AT&T qui, pour aplanir les différences nées des différents idiomes d'Unix, s'associèrent à leur tour en 1987 à Sun Microsystems (à l'époque l'un des principaux acteurs du monde des stations de travail UNIX), pour publier la « version 4 » du System V (SVR4).

Si cette initiative fut saluée par les consommateurs et la presse professionnelle, les autres compagnies franchisées par Unix craignaient un favoritisme envers Sun6 : elles se groupèrent donc en 1988 pour partie au sein de l’Open Software Foundation (OSF), et pour partie sous la bannière d’AT&T sous le collectif UNIX International (UI). Les différends techniques prirent bientôt une tournure de compétition commerciale agressive opposant les deux « versions libres » d’Unix, celle de X/Open constituant un compromis.

De la fin des années 1980 au début des années 1990, System V constituait donc l’une des deux grandes versions d'UNIX, l’autre étant la Berkeley Software Distribution. Eric S. Raymond résume la confrontation entre System V et BSD de la façon suivante :

« En fait, dans les années qui suivirent la bifurcation entre les deux systèmes, la communauté Unix était déchirée par la première phase de la guerre des Unix — une querelle interne, opposant System V et BSD. Cette querelle se jouait sur différents niveaux, les uns techniques (« Berkeley sockets » contre « flux » de SysV, commande tty de BSD contre signal termio de SysV), les autres plus culturels. Le désaccord était du genre cheveux longs contre cheveux courts ; les programmeurs et les ingénieurs étaient plutôt partisans de Berkeley et BSD, les professionnels plutôt en faveur d'AT&T et son System V. »

Eric S. Raymond, The Art of Unix Programming (2003), p. 38 Si Hewlett-Packard, IBM et d'autres constructeurs optaient pour System V, leurs concurrents (par exemple Sun Microsystems et DEC) proposaient des extensions de BSD. Cela dit, tout au long de sa phase de développement, System V s'enrichissait de caractéristiques de BSD, et il faut dire que des variantes de BSD, comme le système Ultrix de DEC, se voyaient dotées de caractéristiques du System V.

Depuis le début des années 1990, avec les efforts de standardisation, comme la norme POSIX et la popularité de Linux, les différences entre System V et BSD sont passées au second plan. UNIX System V

OpenRC est un système init basé sur les dépendances qui maintient la compatibilité avec le système prévu d' initialisation programme, normalement situé dans /sbin/init . Il ne fonctionne pas comme un remplacement pour le /sbin/init fichier. OpenRC est 100% compatible avec les scripts Gentoo de, ce qui signifie une solution peut être trouvée pour exécuter les dizaines de démons dans le principal référentiel Gentoo. OpenRC, cependant, n'a pas été conçu pour être utilisé exclusivement par Gentoo Linux et peut être utilisé sur d' autres distributions et les systèmes BSD.

systemd / Installation Gnome3 à partir de zéro
GNOME-gdm
Systemd est un système d’initialisation et un daemon qui a été spécifiquement conçu pour le noyau Linux comme alternative à System V. Il a pour but d'offrir un meilleur cadre pour la gestion des dépendances entre services, de permettre le chargement en parallèle des services au démarrage, et de réduire les appels aux scripts shell. Le projet a été lancé par Lennart Poettering en 2010 et publié sous licence GNU LGPL version 2.12. Le nom de ce programme vient de « system daemon » : le daemon du système.

Ce projet a suscité de vives controverses chez les développeurs de GNU/Linux.

Systemd est basé sur quelques dizaines de binaires gérant l'ensemble du système de boot, et quittant ainsi la philosophie UNIX du KISS3.

Systemd adopte un nouveau système de log appelé « The Journal », permettant de loguer plus rapidement et plus efficacement les différentes phases de démarrage. Les logs sont authentifiés afin de réduire les chances de corruptions lors d'un piratage, ils sont portables, et l'outil comporte une gestion de saturation de l'espace disque afin de mieux gérer les traces. Tout service géré par systemd est automatiquement logué, sauf si celui-ci demande à ne pas l'être. Il est par défaut compatible avec un environnement réseau et peut passer par les protocoles standard tels que syslog4.

Systemd comporte un outil nommé « systemd-analyze », permettant d'analyser le temps de démarrage, de tracer les différentes étapes et de sortir les analyses sous formes de simples graphiques (format SVG), permettant de comprendre simplement les goulets d'étranglement de la séquence de démarrage.

Systemd diffère de l'init de System V en :

• Utilisant des sockets et des bus pour démarrer et gérer les services. Il est ainsi plus facile de paralléliser des services interdépendants ;
• Utilisant les cgroups pour suivre les processus des services en plus des PID. Cela permet de maintenir la trace des démons même s'ils se dupliquent ;
• Permettant sauvegardes et restaurations de l'état du système (XDG Desktop Entry) ;
• Parallélisant mieux, avec donc un temps de démarrage bien plus court.
• Permet de monter ou démonter les points de montage ;
• Élabore un système de gestion transactionnel des dépendances des services ;
• Les services sont configurés dans des fichiers de type XDG « Desktop Entry »5, également utilisées par des environnements de bureau tel que Xorg et différents bureaux utilisant X11, tels que KDE, GNOME, XFCE, LXDE ou Unity.
• La documentation de systemd comporte à elle seule actuellement 579 entrées, référençant 216 pages de manuel, soit 72 % de toutes les pages de manuel d'Unix v7 pour un seul logiciel.

En avril 2012, le code source d'udev a été intégré dans systemd6. systemd remplace donc System V et udev dans leurs fonctions respectives7. Systemd

Gnome sans sytemd

Le Kernel Linux est un noyau de système d'exploitation de type UNIX. Le noyau Linux est un logiciel libre développé essentiellement en langage C par des milliers de bénévoles et salariés communiquant par Internet.

Le noyau est le cœur du système, c'est lui qui s'occupe de fournir aux logiciels une interface de programmation pour utiliser le matériel. Le noyau Linux a été créé en 1991 par Linus Torvalds pour les compatibles PC. Initialement conçu pour l'architecture de processeur x86, il a ensuite été porté sur de nombreuses autres, dont m68k, PowerPC, ARM, SPARC et MIPS. Il s'utilise dans une très large gamme de matériel, des systèmes embarqués aux superordinateurs, en passant par les téléphones mobiles et ordinateurs personnels.

Ses caractéristiques principales sont d'être multitâche et multi-utilisateur. Il respecte les normes POSIX ce qui en fait un digne héritier des systèmes UNIX. Au départ, le noyau a été conçu pour être monolithique. Ce choix technique fut l'occasion de débats enflammés entre Andrew S. Tanenbaum, professeur à l'université libre d'Amsterdam qui avait développé Minix, et Linus Torvalds. Andrew Tanenbaum arguant que les noyaux modernes se devaient d'être des micro-noyaux et Linus répondant que les performances des micronoyaux n'étaient pas bonnes. Depuis sa version 2.0, le noyau, bien que n'étant pas un micro-noyau, est modulaire, c'est-à-dire que certaines fonctionnalités peuvent être ajoutées ou enlevées du noyau à la volée (en cours d'utilisation). Noyau_Linux

Nvidia

Alsa

PulseAudio

USB
Guide Microphone

Bluetooth

Eix

Eclean

Gentoo Menu