Les bases d'Internet, en images

Tout est dans le titre : en complément aux articles précédents "les bases en informatique pour comprendre Internet", voici un slideware pour creuser un peu plus le sujet, en particulier DHCP et DNS.

Vu que html et javascript ne sont pas des langages qui me passionnent (doux euphémisme), je ne me suis pas cassé la binette à intégrer le slideware à la plateforme de blogging (de toute façon je ne suis pas sur que ça aurait donné un super résultat vu que j'ai dessiné les slides avec une surface d'affichage plein écran sur du 24").

Donc, j'ai fait une simple intégration par lien html externe. L'accès au slideware se fait donc en cliquant sur ce lien.

Have fun 

PC Desktop Fanless 2/3 - La réception

Suite de mes aventures au pays du fanless. 

Le facteur a sonné à ma porte ce samedi dernier et m'a livré le magnifique boitier HDPLEX H5 (2nde génération), c'est un peu noël avant l'heure. 

J'avais déjà reçu le processeur, la carte mère et le SSD depuis quelques jours. Après une partie de chasse aux prix, j'avais fait mes emplettes chez RueDuCommerce pour le processeur et GrosBill pour le reste. La RAM est recyclée d'un ancien PC (c'est pour ça que j'ai pris une carte mère qui supporte la DDR3 et pas la DDR4).

Vous pouvez cliquer sur les photos pour les afficher en full screen et en HD.

ça y est la bête est arrivée

Premier constat, tout est extrêmement bien emballé et protégé, c'est du cousu main et de la grande qualité. C'est pas donné mais on en a pour son argent.

Au fond à gauche, c'est la moitié de l'alimentation électrique, le bloc DC/ATX qui reçoit le courant continu et dont sortent les différents câbles qui vont alimenter la carte mère, les disques etc.

Au fond à droite, c'est la façade avant du boitier.

Au milieu à gauche le dissipateur thermique pour le processeur

Au milieu à droite, les différentes pièces internes (incluant les connecteurs de la façade latérale). En avant plan, on a les plaques qui constituent le reste du boitier à plat en pièces détachées, chaque pièce étant protégée par une épaisse feuille de mousse, et le tout emballé dans un gros bloc de mousse dure.

La carte mère, le SSD et le processeur sont sur la droite. J'ai détaillé ces composants dans le premier article de cette série.

Il manque une pièce : la première partie du bloc d'alimentation électrique, celle qui reçoit le courant alternatif et le convertit en courant continu. 

J'ai fais un mail à HDPLEX pour signaler le problème, et j'ai eu un retour dans la foulée ; la pièce est expédiée à part et l'expédition est en cours. Avec le numéro de tracking fourni dans la réponse, j'ai pu voir qu'elle était cette fois ci envoyée de Hong Kong (probablement un souci de stock sur le dépôt Européen situé en Allemagne d'où provenaient le reste des pièces) par avion, et actuellement à Paris avant de m'être envoyée sur Reims. Ils ne regardent pas à la dépense chez HDPLEX.

Bon, c'est juste un petit désagrément temporaire.

l'alimentation électrique, le bloc DC/ATX

Tout est là, le bloc proprement dît dans son emballage anti-statique, les deux câbles pour l'alimentation de la carte mère, le câble avec une prise Molex et 3 prises SATA pour l'alimentation des périphériques. 

Il y a en sus deux câbles dont je n'aurais pas l'usage et qui servent à priori dans le cas où on utilise un boitier d'alimentation externe du type de ceux qu'on trouve avec les ordinateurs portables (deux câbles car deux types de connecteurs se rencontrent sur le marché). Je n'en aurais pas l'usage car j'ai choisi un bloc d'alimentation interne.

Zoom sur le bloc proprement dît (image provenant du site HDPLEX).

Les spécifications détaillées sont disponibles chez le fabricant.

Le boitier : fond, dessus, côtés

A l'avant plan, le fond : on remarque la qualité de la réalisation et le soin avec lequel sont tracés les différents repères.

A l'arrière plan, le dessus. Au fond à gauche un des deux côtés. Quelle beauté ! 

La particularité de ce boitier conçu pour les solutions fanless est que les côtés participent à la dissipation de la chaleur, d'où les ailettes et la matière.

Le boitier, la façade avant

La façade avant avec le trou destiné au positionnement de l'interrupteur.

Sur la gauche, le composant électronique avec 5 petits poussoirs activés par l'interrupteur, puis l'interrupteur de série (il est possible de le faire personnaliser avec la gravure au laser du motif de son choix), et la charnière de la façade.

Encore une fois, c'est emballé avec grand soin, avec un plastique dur moulé sur mesure.

Le boitier, le bazar interne

Ici encore, tout est protégé par un capot en plastique dur moulé sur mesure.

On voit sur la droite le bloc de connecteurs externes (usb3, usb2, connecteur pour alimenter un périphérique externe de son choix depuis l'alimentation interne, prise casque, bouton de reset) et les câbles (ou la nappe pour la connectique usb3) qui vont servir à raccorder tout ça à la carte mère.

Au milieu, on a la fiche qui servira à raccorder le PC au réseau électrique (partie femelle en haut) et au bloc d'alimentation (partie mâle en bas qui se branchera sur la pièce qui me manque, le convertisseur DC/AC). On voit les 4 patins qui se placeront sous le boitier. Puis, toute la visserie, les pièces mobiles pour obturer/ouvrir les ouvertures à l'arrière du boitier selon qu'on a ou pas branché des cartes d'extension sur les ports PCI(-E) de la carte mère, le support de disque etc.

On peut remarquer que les outils pour le montage sont fournis, délicate attention.

Le système de refroidissement

Là on touche au grandiose.

Alors on voit le bloc en cuivre qui va être posé sur le processeur pour en aspirer la chaleur (avec sa pâte thermique pré-appliquée). 

Puis le bloc avec des ailettes en bas à gauche, qui doit être en aluminium je pense, et qui va conduire la chaleur vers les tuyaux coudés en cuivre (qui seront clipsés sous le bloc en alu).

Les tuyaux en cuivre (caloducs) se chargeront quand à eux de promener  la chaleur et donc de la dissiper au sein du boitier, pour finalement la conduire sur les côtés du boitier qui finiront de l'absorber (le métal va absorber la chaleur sur toute sa surface et va bénéficier de l'air plus frais à l'extérieur du boitier). Si vous avez bien compris le principe, en plus d'avoir un ordinateur fanless, on a un radiateur, elle est pas belle la vie ! Ceci dis, je vous rassure c'est une boutade, le boitier ne chauffera pas assez pour constituer une gêne (mais on s'en assurera par quelques tests).

On peut remarque que la pâte thermique est fournie. A priori c'est la référence Z5 du fabricant Deep Cool, je ne la connais pas mais à priori, après quelques recherches sur le web, c'est un produit d'excellente qualité. Un benchmark sur harwaresecrets, mon site préféré, la classe très bien : c'est ici.

Le reste de l'alimentation électrique (bloc AC/DC)

Bon la pièce n'est pas là encore, mais je ne doute pas de la recevoir un peu plus tard. J'ai contacté HDPlex qui m'a rapidement rassuré, la pièce est en cours d'expédition.

Je met une photo prise sur le site HDPLEX.

Les spécifications détaillées sont disponible ici.

Et un premier upgrade en vue

Le boitier est tout nouveau et je fait partie du premier lot d'utilisateurs, mais néanmoins je ne suis pas le premier : HDPlex a eu des retours terrain des premiers assemblages et en a tenu compte pour améliorer quelques bricoles : la charnière de la façade avant, le bloc de prises façade (sur le côté).

J'ai eu un mail ce matin, les mises à jour de ces pièces vont m'être envoyées gracieusement ; du coup, plutôt que de re-démonter la machine, je vais attendre de les réceptionner.

Moi je trouve la démarche carrément honnête et professionnelle ; j'apprécie le geste.

Conclusion (temporaire)

Bon, j'espère recevoir rapidement la pièce qui manque et l'upgrade. Ensuite, y a plus qu'à...

Habituellement j'assemble des PC classiques, ici il y a un peu plus de travail :

• il faut assembler le boitier fourni en pièces détachées
• il faut assembler le système d'évacuation de la chaleur
• l'alimentation électrique est en deux parties indépendantes (voire 3 si on compte le câble qui fournit la connectique externe ; l'alimentation électrique est pensée de façon très modulaire)

Mais rien de bien compliqué à priori,c'est du mécano, donc plutôt fun. Et le manuel fourni est de super qualité, même si mon anglais très imparfait me joue des tours.

A suivre

Qu'est ce qu'un programme 2/2

Dans un premier article, nous avons parlé des programmes tels qu'ils étaient conçus à l'origine de l'informatique, c'est à dire du code machine produit par simple traduction d'un code source en code binaire (dans le cas de l'assembleur) ou de façon plus sophistiquée par compilation d'un code source en code binaire (dans le cas des langages compilés).

Nous allons maintenant voir qu'il existe d'autres possibilités.

Cet article est le second d'une série de deux. La lecture du premier est un pré-requis.
- Qu'est ce qu'un programme 1/2

Nous allons parler de langages utilisés dans le contexte du web, si vous ne maîtrisez pas les fondamentaux de l'architecture du web, je vous recommande de lire cette série d'articles :
Les bases pour comprendre le Web - Episode 1
Les bases pour comprendre le Web - Episode 2
Les bases pour comprendre le Web - Episode 3

Pourquoi ces autres possibilités ?

Assembleur : vraiment trop relou

Nous avons vu que l'assembleur était tout simplement un truc de malade : pour pouvoir programmer en assembleur, il faut savoir comment fonctionne le processeur ce qui est très compliqué ; du coup comme le langage est de très bas niveau, il faut écrire des centaines de lignes pour faire de choses très simples. 

On en réserve donc l'usage à des cas très spécifiques, et ça reste une affaire de spécialiste (ou de curieux passionné).

Langage compilé : encore trop compliqué pour la ménagère de 50 ans

Les langages compilés sont donc apparus pour permettre de simplifier la programmation : il n'y a plus besoin de connaître le fonctionnement du processeur ; le langage est de plus haut niveau et propose des instructions qui sont plus évoluées en ce sens qu'elles nous permettent plus directement de faire ce que l'on veut sans se soucier de la façon dont le processeur va faire (ou plus précisément de la façon dont le compilateur va traduire notre instruction de haut niveau en dizaines ou centaines d'instruction en code machine).

Donc vous me direz que tout est bien. Mais en fait non. 

L'utilisation d'un langage compilé nécessite toujours de comprendre, certes de façon beaucoup moins pointue, un certain nombre de mécanismes internes liés à l'électronique mise en oeuvre ; pour être plus précis, le développeur doit toujours se soucier de l'utilisation de la mémoire vive (RAM).

Tout programme manipule des données, et ces données sont lues et écrites dans la mémoire vive. La mémoire vive ce sont des composants électroniques qui comportent pleins de petits casiers dans lesquels le processeur range les données pour les retrouver quand il en a besoin. Chaque casier à une adresse précise qui permet de le référencer. 

Le programmeur dispose d'une abstraction pour ces cases en mémoire : ce sont les variables. Pour chaque donnée qu'il doit gérer, le programmeur déclare une variable (montantHT, tauxTVA, ageDuCapitaine) qu'il peut ensuite manipuler simplement. Or, une variable c'est tout simplement l'abstraction de l'adresse d'une case en mémoire. 

Mais où ça devient un peu compliqué, c'est qu'une case en mémoire a une taille fixe tandis que les données manipulées dans un programme ont des tailles différentes et/ou variables. Par exemple, un age est un chiffre compris entre 0 et 120 (soyons optimistes) et tiendra dans une seule case, par contre un nom a une taille potentiellement beaucoup plus grande et nécessitera entre une et deux cases par lettre (selon qu'on gère ou non les alphabets internationaux).

La conséquence de ceci, c'est qu'il faut avoir conscience de la taille occupée en mémoire par chaque type de données (par exemple pour chaque type numérique : entier signé, entier non signé, nombre à décimale, sur telle ou telle plage de valeurs possible ...). De plus, un programme ne peut généralement pas connaître à l'avance toutes les variables qu'il doit utiliser car cela va dépendre des interactions avec l'utilisateur du programme (par exemple de la quantité de données qu'il va saisir au clavier) ; du coup, le programme doit réserver dynamiquement (à l'exécution) des plages de la mémoire pour pouvoir y stocker les données saisies. Et ce n'est pas tout, une fois que la variable n'est plus nécessaire, il faut libérer la réservation afin que les cases en mémoire soient à nouveau disponibles pour un prochain usage, faute de quoi la mémoire étant en quantité limitée elle sera totalement utilisée et votre programme ne pourra pas continuer à fonctionner ; il plantera purement avec un joli message du genre "out of memory / mémoire insuffisante".

Cette gestion de la mémoire est délicate et constitue la principale source de bugs dans les programmes. Elle implique un minimum de compréhension du fonctionnement interne d'un ordinateur et donc de formation (et énormément de rigueur). 

De ce fait, les langages compilés sont généralement des outils réservés à des professionnels aguerris, et ne sont pas vraiment accessible à un individu lamda.

Langage compilé : outillage pénible

Imaginons un peu que nous voulions essayer d'écrire un programme pour réaliser une idée quelconque. Déjà, il va falloir écrire le programme avec un éditeur de texte, bon ça c'est de toute façon inévitable. Ensuite, il va falloir le compiler avec un premier outil, le compilateur. Ensuite, il va falloir lancer l'édition de lien avec le linker. Enfin, nous aurons un exécutable que nous pourrons lancer pour voir comment ça marche. Et si ça fait pas que qu'on voulait, ce qui est le cas dans 99 % au début, il faut modifier le code source, recompiler etc.

Première précision : lancer un compilateur ou un linker, c'est pas forcément simple : il peut y avoir des quantités de paramètres très techniques à préciser.

Seconde précision : une compilation ou une édition de lien ce n'est pas immédiat. Et selon la taille du code source ou le nombre de librairies externes à linker ça peut prendre pas mal de temps.

Bref, tout ça pour dire que de l'idée à la réalisation, il y a un certain nombre d'étapes et que ce n'est pas une solution idéale quand on veut tester rapidement des idées. Et on voudrait bien aller plus vite et se passer de toutes ces étapes.

Un dernier mot : la situation décrite ci-dessus n'est plus la situation actuelle. Aujourd'hui, on dispose d'IDE (Integrated Development Environment) qui combinent tous les outils en un et en facilitent énormément l'utilisation. En outre, les progrès des compilateurs, plus la considérable augmentation de la puissance des processeurs depuis 30 ans, font qu'aujourd'hui on peut faire du prototypage rapide d'idées avec des langages compilés. Mais ce n'était pas le cas à une époque.

Principes / avantages / inconvénients

Principe

Vu que le processeur est trop crétin pour comprendre ce qu'on lui dit (c'est toujours ce que disent les crétins incapables de se faire comprendre), et que Monsieur X est bien trop important pour s'abaisser à apprendre sa langue, il va recruter un domestique qui se chargera de l'intendance : on lui donnera nos ordres et il se démerdera avec le petit personnel (le processeur et la ram).

Bien sur, le domestique étant de basse extraction, il ne parlera pas notre langage châtié, mais l'effort pour se faire comprendre sera moindre, il faudra juste s'abaisser à son niveau.

Bon, ça c'était une image à la sauce grand siècle. Plus concrètement, on ne va plus écrire un programme dans le langage du processeur (plus ou moins indirectement, cf assembleur/compilateur), mais dans un autre langage qui sera compris par un programme chargé de l'exécuter. 

Ce programme saura faire un certain nombre de choses et aura donc un jeu d'instructions, comme le processeur, mais ce seront des instructions beaucoup plus simples et compréhensibles ; en outre, on n'aura plus à se soucier de la mémoire (enfin presque).

Avantages

Le premier avantage, c'est la simplicité du langage. Enfin, on a un langage accessible au plus grand nombre, sans devoir étudier pendant des semaines, sans se prendre trop la tête.

Le second avantage, c'est la facilité d'utilisation. Plus besoin de passer par une lourde phase de compilation, aussitôt le code est il écrit qu'on peut le tester pour voir ce que ça donne et ajuster en conséquence.

Le troisième avantage, c'est la portabilité du programme. La portabilité c'est la capacité à utiliser notre programme sur une machine avec un autre système d'exploitation, ou carrément sur une machine avec une autre architecture processeur. En effet, comme on s'adresse à un programme intermédiaire, il suffira que ce programme existe sur différents OS et matériels pour que notre programme fonctionne partout. Elle est pas belle la vie ?

Inconvénients

Comme toujours, les inconvénients découlent des avantages.

Vu qu'on a un intermédiaire entre nous et le processeur, l'exécution du programme est beaucoup moins rapide que dans le cas d'un langage compilé. Mais cet inconvénient est à relativiser pour deux raisons. Déjà, on n'a pas toujours besoin de vitesse : un programme peut se traîner sans que ce soit gênant, et un programme qui fait peu de calcul et beaucoup d'entrées/sorties avec des périphériques qui sont lents par nature (beaucoup de lecture/écriture de données sur disque par exemple) sera peu ralenti par rapport à une version compilée. Ensuite, les processeurs d'aujourd'hui sont tellement rapide qu'on arrive quand même à des vitesses satisfaisantes. Et pour finir, la plupart des outils actuels incorporent des optimisations de compilation à la volée (à l'exécution, on parle de compilation JIT, Just In Time) qui leur permettent d’accélérer grandement leur vitesse (le meilleur exemple étant le javascript).

Pour ma part, je dirais que le principal inconvénient vient du fait que ces langages sont conçus pour être accessibles à tout le monde, ils sont trop démocratiques en quelque sorte. Pour ce faire, leurs concepteurs ont du faire des choix et sacrifier des possibilités avancées pourtant indispensables pour optimiser ou structurer proprement un programme. Et en cachant la complexité, ils gênent aussi la possibilité de comprendre leur fonctionnement interne et la façon d'optimiser l'utilisation de la mémoire, ce qui est une gêne pour les développeurs professionnels soucieux de qualité. Une fois encore, ceci est à relativiser en fonction de la criticité des applications développées (en gros, pour une application pas essentielle et qui n'évoluera pas beaucoup, on se fout qu'elle soit mal optimisée et non maintenable tant qu'elle coûte 3 fois moins cher à produire), et du coût toujours en baisse de la mémoire (acheter de la mémoire coûte moins cher que d'en optimiser l'usage par les programmes).

On est ici en plein sur un conflit de génération entre informaticiens d'antan soucieux d'économiser les ressources et pointus techniquement, et informaticiens d'aujourd'hui qui se foutent royalement de comment ça marche tant que ça répond rapidement à leur besoin.

Ajoutons au passage, en ces jours de COP21, qu'on se soucie aujourd'hui d'écologie en informatique, et que l'efficacité d'un programme qui va moins solliciter le matériel, et donc moins consommer d'électricité, et donc moins polluer est devenue un sujet.

Les solutions

Les langages interprétés.

Une application directe des principes expliqués ci-avant. On a un programme, appelé "interpréteur"  (ou runtime, ou moteur d'exécution) qui va lire le code source et l'exécuter directement.

Le plus connu est le Basic, un langage pour débutants. Ceci dit, la plupart des langages Basic modernes sont aujourd'hui compilés.

Non aujourd'hui, si il faut parler de langage interprété, le plus répandu est sans doute le Javascript utilisé pour dynamiser les pages web. Ou le PHP utilisé pour le plus grand nombre de sites web sur la planète.

Le javascript devient de plus en plus performant grâce au fait que les moteurs js incorporent des techniques de compilation à la volée (JIT). Le principe de la compilation JIT est que l'interpréteur analyse le code ; quand il détecte des sections qui vont être appelées de nombreuses fois, il fait un calcul pour voir si il sera plus intéressant de supporter le coût d'une compilation qui surviendra une seule fois et permettra d'exécuter le code plus vite, plutôt que de l'interpréter. On a ainsi le meilleur des deux mondes, mais ça reste quand même moins rapide qu'un programme compilé.

PHP vient de sortir en version 7 et intègre également des mécanismes JIT ce qui lui permet d'aller 2X plus vite (que la version précédente, la v5, cherchez pas la v6 elle n'existe pas) ; et vu que 50% environ des sites web dans le monde sont écrits en PHP et qu'ils devraient migrer facilement sur cette version, le web mondial va accélérer en 2016 et 2017. Classe !

Les machines virtuelles

Alors une machine virtuelle, c'est un programme qui simule de façon plus ou moins complète un ordinateur. 

Si les plateformes techniques de virtualisation permettent de simuler un ordinateur au complet avec toute son électronique, nous nous intéresserons ici uniquement aux programmes qui simulent le fonctionnement d'un processeur et que nous appellerons "machine virtuelle". On peut d'ailleurs voir ces solutions assez anciennes comme les précurseurs des solutions de virtualisation actuelles qui sont à l'origine de l'essor de l'informatique dans le cloud.

Alors une machine virtuelle simule un processeur : elle a donc une architecture et à ce titre un jeu d'instruction. Et donc, on peut écrire des programmes qui vont être compilés dans ce jeu d'instruction, ou même pourquoi pas interprétés (même si à la base, ça n'a pas été conçu dans cet esprit).

Alors, on revient à nouveau à de la compilation. Quel avantage du coup ? Hé bien, ce processeur virtuel est plus simple et la compilation de code source beaucoup plus rapide que quand on compile pour un vrai processeur. On ne parle d'ailleurs normalement pas de code binaire pour le résultat final mais de p-code.

Mais les vrais avantages sont ailleurs. Ces processeurs virtuels prennent en charge une partie des tâches habituellement dévolues au programmeur, et en particulier la gestion de la mémoire. Un mécanisme appelé ramasse-miette (garbage collector) gère automatiquement le fait de libérer la mémoire qui n'est plus utilisée ce qui est un progrès considérable. Les développeurs n'ont plus d'accès direct à la mémoire et ne peuvent plus faire d'erreur au niveau des allocations mémoire (qui sont gérées par le processeur d'après les demandes simplifiées faites par les programmeurs).

Ce qui est amusant c'est que ces machines virtuelles font également usage de compilation JIT pour améliorer leur vitesse d'exécution. Mais alors que ces techniques sont récemment adoptées par les interpréteurs javascript, elles sont développées depuis au moins une quinzaine d'années.

Comme pour les interpréteurs on a la possibilité d'avoir du code portable entre OS/architectures processeurs dès lors que la machine virtuelle existe sur les environnements cibles.

Sur les 3 technologies principales utilisées aujourd'hui pour le Web, deux sont basées sur une machine virtuelle : Dot Net de Microsoft et Java de Oracle (anciennement Sun), la troisième étant PHP qui est interprété (au sein du serveur HTTP).

Microsoft et Oracle utilisent la virtualisation dans des objectifs différents. 

Microsoft n'a pas porté sa machine virtuelle, appelée CLR (Common Language Runtime, moteur d'exécution commun pour les langages), sur d'autres OS que les Windows ni à priori (suis pas un spécialiste Microsoft) sur d'autres architectures processeur que x86/x64 (à voir si la plateforme DotNet est supportée sur Windows RT, la version de Windows pour processeurs ARM). Mais Microsoft permet aux développeurs d'écrire leur code source dans de nombreux langages différents et de les compiler en p-code CLR ; ainsi le développeur peut choisir le langage qui supporte le paradigme qu'il préfère ou celui dont il préfère le langage pour des raisons de convenance personnelle. C# est le langage objet de la plateforme DotNet et il est le plus moderne, mais il est possible d'utiliser des version Microsoft de Basic par exemple pour les développeurs moins aguerris.

Oracle pour sa part a porté sa machine virtuelle appelée JVM (Java Virtual Machine), ou permis à d'autres de le faire en publiant les spécifications et en fournissant des outils de certification, sur à peu près tous les OS et architectures processeurs existants. Mais Oracle ne fournit qu'un seul langage (avec son compilateur et tout le nécessaire) pour développer sur le JVM : le langage Java.

Le fait que le langage Java soit extrêmement portable explique le fait qu'au début du Web de nombreux sites utilisaient des Applets. Les Applets sont des composants développés en Java et qui sont envoyés par le serveur Http avec les pages web qui les embarquent. Ils sont exécutés sur le poste client qui doit bien sur disposer d'une JVM. Pour diverses raisons, cette technologie est aujourd'hui tombée en désuétude, remplacée par le javascript (interprété, l'interpréteur est embarqué dans le navigateur, pas besoin d'installer un JRE - Java Runtime Environment, environnement d'exécuton Java - sur le poste client en plus du navigateur. Le JRE inclut la JVM).

Le langage Java est un langage Objet. Pour programmer en Java, il faut donc maîtriser le paradigme Objet ce qui fait de cette plateforme un outil plutôt réservé aux professionnels (le langage Java est très simple mais le mode de pensée Objet nécessite un long apprentissage). Mais depuis quelques années, on voit foisonner divers langages qui peuvent se compiler en p-code exécutable par la JVM (on utilise en général le terme bytecode même si il peut être source de confusion) et qui améliorent le langage Java (un peu trop académique, verbeux et peu productif) ou permettent le support d'autres paradigmes (simple scripting, programmation fonctionnelle) : Jython d'IBM (Pyton compilé), Scala (paradigme fonctionnel), Ruby, Groovy... Certains de ces outils permettent d'interpréter du code à la volée (sans passer par la phase de compilation).

Conclusion

Voila pour ce rapide tour d'horizon. 

On peut constater que chaque progrès sert de base au progrès suivant, et que quelquefois des idées anciennes laissées de côté reprennent de l'intérêt en fonction de l'évolution des technologies.

L'informatique est aujourd'hui un métier de masse ; des écoles d'ingénieurs de qualité très variable forment à tour de bras des armées de développeurs pour alimenter l'appétit vorace des sociétés de service en chair fraîche. Bien souvent ces développeurs sont formés sur une technologie pour être directement employables et n'ont pas forcément conscience de l'ensembles des possibilités. Espérons que ceci changera car ces jeunes trop vite formés et parfois peu intéressés par le métier, simplement attirés par le mirage d'un gros salaire et d'un premier emploi facile à décrocher, décrocheront rapidement pour une partie non négligeable et iront grossir le flot des informaticiens chômeurs. 

PC Desktop Fanless 1/3 - La conception

Un matin en me levant, j'ai décidé de changer mon équipement informatique. Hé houais suis comme ça moi, une vraie bête, une pure tête brûlée ;-)

Au cours de mes recherche, je me suis intéressé à un système Fanless. Ceci est mon histoire ;-) Plus sérieusement, voici un témoignage en matière de Fanless. Ca va aussi causer un peu de NAS à la marge.

Equipement initial

Le boiter est un Antec P180, en format grande tour, qui pèse un âne mort et prend plein de place. Mais qui a le dos large.

Le processeur est un Intel core i7-3770 (core 3éme génération) avec 8 Go de RAM (4 x 2 Go).

La carte mère Asus P8Z77-V LX2 (donc en chipset Z77) est très honnête.

Les disques sont plus qu'honorables avec un SSD Samsung 830 pour le système, deux disque durs 10 000 rpm en RAID 0 pour le travail (WD Velociraptor), et un gros disque 3 To 7200 rpm pour le stockage, plus un disque 1 To que j'ai du ajouter récemment pour le stockage toujours (ben oui, les vidéos ça prend de la place). 

Et avec tout ça, aujourd'hui je fais essentiellement un peu de bureautique sous MsOffice, et du surf sur Internet... plus quelques bidouilles sous Linux (dual boot), autant dire que c'est plus que luxueux et qu'il n'y avait pas vraiment urgence à changer.

A ma décharge je l'ai dimensionnée à une époque où pour mon activité professionnelle je faisais tourner plusieurs VM en parallèle, sous VMWare, pour héberger des bases de données ou des serveurs divers et variés sous Linux. Puis, j'utilisais des environnements de développement Java plutôt lourds (Eclipse avec moult plugins) sur des projets de taille non négligeable.

Bon quel intérêt à raconter tout ça, à part pour pour mon classement sur jemelapete.com ? Juste pour éclairer la suite.

Réflexion initiale, cahier des charges

Alors, les données du problème sont :

• J'ai déménagé, et mon bureau actuel est bien plus petit que celui dont je disposais avant. Je voudrais récupérer de la place sous le bureau pour avoir des blocs tiroir mais mon P180 prend la place.

• Je n'ai pas de place sur le dessus du bureau pour poser une mini tour, ni même un PC de tout petit format (genre NUC, ou mini ITX)

• Alors que ma configuration était assez silencieuse, j'ai maintenant des nuisances sonores : les ventilateurs ont vieilli (le P180 en est quand même à sa 3éme carte mère) ; la cage disque est bien pleine, ça chauffe et il faut ventiler plus fort.

• J'ai plein de fichiers auxquels je tiens, et plus de possibilité de sauvegarde au vu de mes volumes

• J'ai plein de temps à perdre et pas beaucoup d'argent à jeter par les fenêtres

La réflexion qui en découle est la suivante :

• Il me faut un PC de bureau en format dekstop classique (le format d'origine des PC, un bloc rectangulaire) comme ça je peux le poser sur mon bureau sous l'écran ou sous le scanner/imprimante

• Comme ce format limite les possibilités d'usage et que je veux un truc silencieux, j'ajoute un NAS que je mettrais dans une autre pièce et qui pourra faire autant de bruit qu'il faudra par rapport à ce que je veux lui faire faire. Et qui supportera des fonctionnalités RAID avancées pour la redondance et donc la sécurité de mes données (et bien sur une sauvegarde externe)

• Vu que j'ai du temps et quelques compétences, pas beaucoup d'argent à jeter par les fenêtres, et du matériel qui est tout sauf périmé, je vais recycler un maximum de choses de ma configuration existante

• Vu que je peux m’asseoir sur ma licence Windows qui est OEM (liée à ma configuration actuelle, non transposable sur une nouvelle machine), que Windows 10 me casse les bonbons (c'est officiel, W10 est un malware), et qu'il n'est pas question que je paye une nouvelle licence, et que je suis trop vieux pour m'emmerder à la pirater, je passe ces deux machines sous Linux. 

• Comme j'ai une dépendance sur Windows pour certains logiciels, et que je ne peux pas la lever, je vais me débrouiller pour me procurer une licence légale gratuitement ou à bas prix ; je l'utiliserais pour une VM W7 qui tournera sur le NAS, je m'y connecterais en bureau distant depuis le desktop. Il me faut donc un solution de virtualisation pour le NAS.

A partir de là, j'ai commencé par me mettre à jour sur le hardware actuel car j'avais lâché l'affaire depuis environ 2 ans 1/2 et que les choses évoluent très vite. Puis, je me suis mis à la page sur les distributions Linux et les environnements de bureau, sur les solutions de virtualisation, et tant qu'à faire d'infrastructure Cloud (bon j'ai un copain spécialiste du bignou qui m'a poussé au cul). 

Facile 2 mois plus tard, je sais à peu près où je vais. 

Et le Fanless là dedans ?

Pfouu relou le gars, 40 pages et il parle pas encore de Fanless !

Alors le Fanless c'est quoi ? C'est un PC sans aucun ventilateur donc très silencieux. La seule source de bruit possible résiduelle ce sont les disques durs mécaniques, et si on veut un PC totalement silencieux, noiseless, il suffit de renoncer aux disques durs mécaniques et n'user que de SSD.

Et là ça rentre bien dans mon cahier des charges : je veux un truc silencieux, et comme d'une part je vais déporter sur un NAS le stockage qui ne peut se faire qu'avec des disques mécaniques (le prix au To des SSD étant toujours rédhibitoire pour de gros volumes), et que d'autre part vu l'usage de ma machine de bureau je peux me contenter d'un "petit" disque, le SSD est dans mes prix.

Les contraintes spécifiques liées au Fanless

La dessus viennent  d'autres contraintes : 

• les processeurs puissants chauffent beaucoup. 
• les cartes vidéo encore plus

Bon, je ne joue pas avec ma machine, donc pas besoin de carte vidéo dédiée, la GPU intégrée d'un processeur Intel Core récent me suffira amplement. 

Pour le processeur, c'est un poil plus compliqué : il y a des solutions à base de gros boîtiers très aérés qui peuvent accueillir de gros blocs de refroidissement, mais ça ne rentre pas dans mon cahier des charges. Ces solutions sont aussi assez onéreuses (les blocs de refroidissement coûtent un bras, les alimentations électriques fanless aussi, et les boîtiers adaptés itou).

Rappelons ici que j'ai exclu les mini PC, genre NUC ou format mini ITX, car même ça ne rentre pas sur mon bureau. En outre ça limite trop les choix en terme de processeurs (trop peu puissants à mon gout). Ces solutions ne sont par ailleurs pas données non plus, et n'ont aucune évolutivité.

Donc je veux un boitier au format desktop. Et là, manque de bol je suis déphasé avec les tendances du marché, on ne trouve plus beaucoup de ces boîtiers sur le marché, et ils ne sont pas adaptés au fanless (trop petits pour un gros dissipateur, pas adaptés pour l'autre technique utilisée et dont je vais parler).

A ce stade, il ne me reste que la solution HTPC. Les HTPC (Home Theater PC) sont destinés initialement à une utilisation dans un salon, comme brique d'un système multimédia, et destinés à être connectés à divers équipements de salon (chaîne Hifi, ampli 5.1 télévision grand écran etc.). Comme un ventilateur qui fait un gros "vroum" pendant que vous regardez un films, ça ne le fait carrément pas, les technologies fanless sont assez développées sur cette niche.

La technologie utilisée pour réussir à refroidir des processeurs puissants, voire des GPU, consiste à conduire la chaleur sur les parois du boitier qui participe ainsi au refroidissement. C'est un peu comme un chauffage central : la CPU chauffe (comme le brûleur d'une chaudière), les watts dégagés sont aspirés par une pièce métallique posée dessus (comme le ballon d'eau d'une chaudière) et depuis laquelle partent des tuyaux (comme des conduites de chauffage) qui vont transmettre la chaleur aux parois du boitier qui vont la dissiper à l'extérieur (comme un radiateur qui chauffe une pièce). Tout comme un chauffage central donc, sauf qu'il n'y a pas d'eau et que seules les propriétés thermiques des métaux utilisés permettent la conductivité.

Cette tuyauterie amène des contraintes mécaniques : il faut de la place au sein du boitier pour faire circuler les tuyaux qui conduisent la chaleur de la CPU vers les parois, et toutes les cartes mères ou assemblages ne sont pas possibles. D'autre part, il faut un boitier spécifiquement conçu, avec une carcasse en métal qu soit bon conducteur thermique, ajourée, et avec des ailettes pour faciliter la dispersion (comme un radiateur on vous dis).

Enfin, il y a des limites à ce que ce systèmes peuvent évacuer comme chaleur. Cependant ici, j'ai trouvé des solutions capables de supporter des températures assez élevées pour offrir une palette de choix suffisante pour mes besoins en terme de processeurs.

Puis n'oublions pas non plus que les dernières générations de processeurs Intel (skylake) ont fait de gros progrès en terme de TDP (de température dégagée). Et qu'il existe des versions spécialement optimisée pour dégager moins de chaleur ; malheureusement ce sont soit des versions de processeurs pour bureau dégradées en cycle d'horloge (donc moins rapides), soit des versions spécialement conçues pour les ordinateurs portables qui coûtent cher et sont très difficile à se procurer en France pour des particuliers (mais ça se trouve à l'étranger).

Ces contraintes, plus le fait qu'on est sur un marché de niche, plus le fait que la clientèle HTPC a généralement le portefeuille bien garni (ben oui, c'est pas tout le monde qui a un système multimédia de pointe dans son salon), plus le fait que les HTPC trônent dans le salon et doivent avoir un très beau design qui ne fait pas tâche avec le reste des éléments Hifi hors de prix, font que ces boîtiers sont onéreux.

Donc conclusion temporaire, quel que soit mon choix, il va falloir passer à la caisse et redimensionner mon budget initial, ou renoncer au fanless.

Sources utiles, remerciements

Bon, le fanless m'est tombé dessus un peu par hasard, au fur et à mesure de mes promenades sur le web. En fait, j'avais défini une configuration classique puis au dernier moment j'ai voulu l'améliorer et la rendre fanless à moindre coût après avoir lu quelques informations sur le sujet.

Novice sur le sujet, j'ai imaginé une configuration comme j'ai pu, puis j'ai trouvé une "communauté du fanless Français" sur un forum de Hardware.fr animé par une bande de fous furieux. J'ai exposé mon idée, je me suis fait (gentiment) démonter en deux secondes car j'étais complètement à côté de la plaque. Déjà, ça m'a évité de faire fondre mon processeur ...

Puis grâce à l'aide de cette communauté je suis monté en compétences sur le sujet, et j'ai étudié diverses pistes qui m'ont été suggérées, pour finalement retenir celle du tout nouveau boitier HTPC de la société HDPLEX, le H5 2nde génération (tout nouveau).

Donc, pour les curieux, quelques bonnes adresses :

• Communauté Francophone du Fanless : le forum Hardware.fr dont je parlais plus haut
• Le fanless dans tous ses états : un blog animé par un fondu du fanless
• http://www.fanlesstech.com/ : pour identifier des matériels fanless

Ma config de bureau Fanless

A titre d'information, j'estime le surcoût lié au fanless à 250 Euros environ dans mon cas. Inutile de dire qu'en valeur relative c'est énorme par rapport au coût initial de ma configuration mais le silence est d'or.

Au final, j'estime que ça vaut le coût car le boitier HTPC répond parfaitement à mon cahier des charges, c'est un très bel objet qui me servira dans la durée, que je pourrais probablement recycler, et qui aura une valeur à la revente.

Le boitier / alimentation électrique

J'ai choisi le boitier HTPC H5 2nde génération, de la société HDPLEX.

Il répond parfaitement à mon cahier des charges. Il permet en théorie de refroidir des processeurs dégageant jusque 95 Watts. 

La lecture des spécifications techniques permet de voir qu'on a affaire à du matériel haut de gamme pensé par des spécialistes. Forcément le prix s'en ressent mais on n'a rien sans rien.

J'ai apprécié la qualité de la documentation, et la possibilité d'échanger avant achat sur le forum dédié à cet appareil : http://www.hd-plex.com/forum/showthread.php?t=2464

Je ne suis pas là pour faire l'article, je vous laisserais le soin de prendre connaissance des spécifications techniques sur le site du constructeur, et je me contenterais de quelques remarques :

• prenez bien soin de lire les spécifications techniques, et le guide d'installation
• n'hésitez pas à aller poser des questions sur le forum
• ne perdez pas de vue que, selon ce que vous voulez faire rentrer dedans, il peut y avoir des surcoûts (dissipateur supplémentaire pour carte graphique, nappe spécifique requise dans certains cas selon l'utilisation que vous faîtes des cartes d'extension PCI-E de la carte mère, cf manuel d'installation)
• bien sur, n'oubliez pas de choisir une alimentation électrique adaptée

J'ai été un peu perdu au début dans le choix de l'alimentation électrique. 

Jusqu'à présent, j'utilisais des alimentations ATX "classiques", une simple boite qu'on installe dans le boitier PC et d'où partent les câbles pour alimenter la carte mère et autres composants. 

Ici, cette boite est décomposée en deux éléments qu'on doit combiner de façon cohérente :

• AC/DC : un premier élément convertit le courant alternatif (AC) en courant continu (DC). Il faut le dimensionner en fonction de vos besoins, c'est à dire de la consommation cumulée maximum de l'ensemble de vos composants.

• DC/ATX : un second élément qui reçoit le courant continu du premier et d'où sortent les câbles habituels pour alimenter la carte mère etc.

La conception du boitier est très modulaire et vous laisse de nombreuses possibilités en terme d'alimentation électrique. Par exemple, le boitier AC/DC peut être interne ou externe. L'intérêt ici est que si vous disposez d'un chargeur d'ordinateur portable en rab, vous pouvez l'utiliser comme boitier externe et faire l'économie d'un élément. Le packaging comprend le nécessaire pour vous permettre de le raccorder. Je n'ai pas creusé cette possibilité mais il est possible de directement relier le boitier à un onduleur pour ceux qui veulent le summum du summum.

Pour ma part, j'ai pris l'option "combo 160W AC/DC + DC/ATX nanoATX". J'ai donc une alimentation interne de 160 W ce qui est parfait dans mon cas car je devrais l'utiliser à environ 50 % de ses capacités ce qui est l'idéal (c'est là qu'il y a le meilleur rendement, c'est à dire que l'énergie perdue en chaleur dégagée est la plus faible par rapport à l'énergie fournie).

Processeur

J'ai pris un core i5-6500 skylake. Son TDP est de 65 Watts.

Le boitier supporte des TDP de 95 Watts et j'aurais pu prendre plus puissant mais d'une part je préfère garder une marge de sécurité, et d'autre part ce processeur sera suffisant pour ma machine de bureau, sachant que dans mon projet pris dans sa globalité, les traitements lourds que je peux faire aujourd'hui et qui justifient un core i7 plus rapide et avec le HT (Hyper Threading), seront déportés sur le NAS (qui aura la CPU qui va bien).

Carte mère

J'ai pris la carte H110M-S2PV DDR3 de GigaByte.

Je n'aurais qu'un SSD à brancher, et quelques ports USB. Du coup, même pas besoin d'un support RAID par le chipset, pas question d'overclocking dans une configuration fanless, pas de carte vidéo bien sur. 

Bref, tout ceci me permet de prendre le chipset H110 le moins puissant et le moins évolué, ainsi qu'une carte d'entrée de gamme destinée au marché des petites configurations de bureau au prix tiré vers le bas. Pour autant, j'ai tapé dans la gamme UltraDurable GigaByte pour ne pas sacrifier la qualité.

J'ai pris la version DDR3 pour pouvoir réutiliser deux barrettes de RAM de mon PC actuel. J'upgraderais éventuellement ultérieurement en 2 x 4 Go avec des barrettes plus performantes mais pour le moment ça devrait bien suffire vu la vocation de la machine.

SSD

Bon là, j'ai un peu craqué, je dois bien l'avouer. Mais vu que je suis descendu en gamme en terme de processeur, je me suis dit autant soigner les I/O. Puis j'ai économisé sur la carte mère, alors ...

J'ai pris un SSD SandDisk Extreme PRO 240 Go. Il est clairement cher, pour le même prix je pourrais avoir un 480 Go ces jours ci (black friday), mais d'une part 240 Go me suffisent largement (le stockage sera sur le NAS), et d'autre part ce SSD se démarque largement dans tous les benchmark que j'ai pu lire en terme de rapidité,le machin est une vraie fusée.

RAM

2 x 2 Go en DDR3, de la PC3-12800 de qualité, de chez Corsair. Spécification ici.

Ma config de NAS

Juste deux mots. Ce ne sera pas une configuration fanless, car avec de nombreux disques ça ne me semble pas raisonnable.

Pour autant, j'ai étudié une configuration la plus silencieuse possible avant de renoncer face au surcoût. Le serveur sera dans une autre pièce que le salon, le bruit ne sera pas un problème.

Ce qui est déjà certain, c'est que je vais recycler de mon PC de bureau actuel :

• le processeur core i7-3770
• la carte mère ; elle supporte le RAID sur 4 ports SATA II + 2 ports SATA III
• l'alimentation électrique (une Seasonic S12 de qualité, bien dimensionnée, 550W de mémoire)
• un SSD Samsung 830 de 64 Go pour l'OS et le swap Linux
• un WD Velocirapor 10 000 rpm (j'en ai deux mais je ne pourrais pas brancher les deux)

J'aurais à acheter 32Go de RAM (ouch !), 4 disques NAS pour la grappe RAID (le gros poste de dépense), et un nouveau boitier. En effet, je ne suis pas satisfait par le P180 pour les configurations avec plein de disques. A priori, je prendrais ce boitier Phantek Enthoo Pro qui a un très bon rapport qualité/prix.

Pourquoi 32 Go de RAM ? Parceque je vais utiliser ce serveur en tant que serveur de VM et que c'est une application qui requiert beaucoup de RAM.

En terme de système, je vais me tourner vers une distribution CentOS avec KVM en solution de virtualisation (connecteurs disponibles pour CloudStack, Cloudstack pilotable par Vagrant) ; je dois encore checker le support du RAID semi logiciel par l'OS mais il me semble que c'est OK. Ce choix a été difficile, j'ai envisagé de nombreuses solutions, en particulier FreeNas (FreeBSD) et XPEnology.

Les disques SATAIII seront connectés en SATAII, c'est sans doute dommage mais je n'évalue pas la perte en performance. En outre, ce seront les disques destinés au stockage qui seront branchés dessus. 

En terme de disque, je dois encore réfléchir, c'est un gros poste de dépense. Pour le moment, je pense à des WD Red de 3To (4 x 3 To en RAID 10). Mais mon choix n'est pas arrêté, je pourrais peut être revoir ça pour diminuer le budget (4 WD30EFRX ça fait quand même 500 euros) : moins de disques et un simple RAID 1 + une sauvegarde externe partielle seraient moins cher. Je peux aussi distinguer plus finement mes fichiers entre ceux que je veux absolument préserver en cas de crash et ceux dont je pourrais me passer.

A suivre...

J'ai commandé les pièces. J'attends livraison pour poursuivre cette série d'article, avec la phase d'assemblage, puis la phase de test. 

Très Haut Débit : le FTTDP apporte une nouvelle possibilité

Si vous ne comprenez rien au différentes possibilités qui existent aujourd'hui pour bénéficier du Très Haut Débit (THD) en Fibre Optique (ou pas) à votre domicile, c'est bien normal : la situation est relativement complexe, plutôt opaque, et évolue rapidement. En outre, des enjeux industriels et politiques, le poids des lobbys et l'existence d'un organisme de régulation étatique (l'ARCEP) compliquent bien les choses.

Préambule

J'ai réalisé un premier article qui explique tout ça, et qui propose quelques liens intéressants sur des sites tiers. Lisez le en préambule cet article si vous découvrez le sujet.

Cet court article a pour objet de présenter une nouvelle alternative au FTTH, FTTLA, FTTB : c'est le FTTDP ...

FT quoi ?

FTTDP = Fiber To The Distribution Point, Fibre jusqu'au point de distribution

Cette fois ci, il ne s'agit pas d'une variation de la technologie utilisée pour la boucle locale, c'est à dire pour amener le haut débit au pied de votre immeuble (déploiement horizontal, fibre optique en point à point Free vs fibre optique multi-point Orange, vs câble TV coaxial Numéricable).

Non cette fois ci, il s'agit d'une variation sur le thème : comment distribuer le haut débit depuis le bas de votre immeuble (point de distribution) vers les paliers des appartements, donc sur la distribution verticale qui est réalisée par l'opérateur d'immeuble (rappelons que le raccordement final du palier jusqu'à l'appartement est du ressort de l'opérateur privé que vous aurez retenu individuellement et qui sera en pratique soit l'opérateur d'immeuble, soit un opérateur quelconque qui a relié votre immeuble avec sa boucle locale  - déploiement horizontal - et qui paie une redevance à l'opérateur d'immeuble pour utiliser son réseau dans l'immeuble).

Aujourd'hui, on trouve de la distribution verticale en fibre optique (Free, Orange) et en câble TV coaxial (Numéricable). 

La mise en place de cette distribution a un coût non négligeable et constitue un frein au déploiement du THD. En effet, l'opérateur d'immeuble supporte l'investissement et ne l'amortit que dans la mesure où les différents appartements souscrivent à la THD (auprès de lui directement, ou d'un autre opérateur auquel cas ils touchent une redevance pour l'utilisation de leur installation). Or le taux d'adoption n'est pas si rapide que ça, et encore moins dans les grandes villes où les NRA (concentrateurs téléphoniques) ne sont jamais très loin et permettent des débits honnêtes en xDSL.

En parallèle, les technologies évoluent (G.Fast, nouvelle norme xDSL) et permettent d'obtenir du THD sur la bonne vieille paire cuivrée (le réseau téléphonique commuté de papa et grand papa). Alors, attention bien sur, ces très hauts débits sur paire cuivrée ne peuvent être obtenus que sur de très courtes distances (disons de l'ordre de la centaine de mètres au max) et ne sont donc pas éligible pour amener le THD jusqu'au pied de l'immeuble (les distances à parcourir depuis les NRA - concentrateurs téléphoniques - étant trop longues et dépassant les capacités de la technologie). Néanmoins, ces technologies prennent tout leur sens pour le déploiement vertical qui se fait sur courte distance, avec un avantage énorme : tous les immeubles ont déjà un réseau téléphonique en paire cuivré installé, il n'est plus nécessaire de faire autant de travaux ; l'installation d'un équipement qui fait le "lien" entre l'arrivée de la boucle locale et le réseau en paire de cuivre de l'immeuble suffit.

Alors, cette technologie est émergente et les lourdeurs administratives font qu'on ne va pas la voir tout de suite en France, mais néanmoins c'est une piste prometteuse pour accélérer le déploiement de la THD en France.

Et en prime, cette technologie devrait offrir des débits montants supérieurs à ceux offerts par l'offre Numéricable sur cable coaxial (sachant que Numéricable a un monopole de fait dans de nombreuses villes, son réseau de câble TV étant propriétaire et non dégroupé).

Qu'est ce qu'un programme 1/2

Tout ce que vous avez toujours voulu savoir sur les programmes (sans jamais oser le demander).

Qu'est ce qu'un programme informatique ?

La réponse peut sembler évidente mais si on prend un peu de recul, cette question à priori simple amène des réponses potentiellement compliquées.

Et elle mérité d'être posée car comprendre ce qu'est "in fine" un programme permet de comprendre pas mal de choses sur le fonctionnement d'un ordinateur quel qu'il soit.

Préambule

Je vous invite éventuellement à (re)-lire cet article qui expose quelques notions de base (architecture processeur, système d'exploitation).

Rappelons rapidement qu'un processeur est, par construction, capable d'exécuter un nombre fini et limité d'opérations élémentaires. L'ensemble des ces opérations élémentaires constitue son "jeu d'instruction" et est un des éléments de base qui définit une architecture processeur. 

Notre première définition d'un programme est la suivante : "une suite d'instructions, chaque instruction étant une opération élémentaire disponible dans le jeu d'instruction du processeur".

Le processeur exécute séquentiellement les instructions qui ont préalablement été chargées en mémoire vive (RAM) par le système d'exploitation (OS). La suite d'instructions (le programme donc) a généralement été lue depuis un support de stockage (disque dur, DVD, etc.) où elle était stockée dans un fichier, appelé fichier exécutable par opposition aux fichiers de données qui stockent des informations et pas des instructions. 

Le processeur est donc capable d'exécuter tout programme, dès lors qu'il est exprimé dans son jeu d'instruction, ce qui en fait un outil très versatile (adaptable à de nombreux travaux). 

La vraie nature d'un programme

Un programme est donc une suite d'instructions, et chaque instruction est exprimée en langage machine, c'est à dire directement en binaire. Détaillons ceci.

A chaque instruction supportée par le processeur va correspondre un numéro unique qui l'identifie, par exemple 00000001 pour une addition ou 00100100 pour une soustraction. 

Les opérandes éventuelles d'un instruction sont également exprimée en binaire. Qu'entends on par opérande ? Hé bien par exemple les opérandes d'une instruction d'addition sont les deux valeurs à ajouter. 

En reprenant notre exemple précédent, si je veux ajouter 4 (00000100 en binaire) et 8 (00001000 en binaire), l'instruction sera un truc du genre 00000001 00000100 0000100, soit "ajouter" "4" "8" (cet exemple est bien sur fictif).

On peut déjà constater que ce code binaire, si il est directement compréhensible par le processeur, est totalement illisible d'un point de vue humain, du moins sans un effort considérable, et encore plus quand on sait qu'il existe des centaines d'instructions différentes, et que les êtres humains normalement constitués comptent en décimal et pas en binaire (et encore, nous avons simplifié la réalité).

Si on a programmé en binaire il y a des décennies sur des ordinateurs très simples munis de processeurs avec des jeux d'instructions très limités, il est bien évident que les possibilités sont très limitées d'un point de vue pratique (et uniquement d'un point de vue pratique) ; les processeurs modernes ont en outre des jeux d'instructions complexes rendant la tâche encore plus difficile.

Pour cette raison, on a inventé progressivement diverses techniques pour permettre aux programmeurs d'écrire des programmes sans devoir taper des suites de 0 et de 1.

Première étape : l'assembleur

On a commencé par attribuer un nom parlant à chaque instruction existante. Par exemple si 00000001 est l'instruction "addition", on lui a associé par exemple le libellé "ADD". 

Ensuite, comme exprimer des valeurs en binaire est vraiment trop chiant, on a donné la possibilité de les exprimer dans d'autres bases (en décimal - base 10 -, en octal - base 8 -, en hexadécimal - base 16 -, la plus utilisée étant l'hexadécimal pour des raisons d'ordre pratique sur lesquels je ne m'étendrais pas ici). 

Du coup, au lieu d'écrire 00000001 00000100 0000100 comme tout à l'heure, je peux écrire par exemple ADD 4 8. C'est déjà plus facile de comprendre que ça veut dire "additionne 4 et 8".

Mais le processeur lui ne comprend pas ADD 4 8, il ne comprend que 00000001 00000100 0000100. Ben oui, il est un peu obtus le machin.

Donc, il nous faut un programme qui va traduire ADD 4 8, qui est ce que le programmeur va écrire, en 00000001 00000100 0000100 qui est ce que le processeur va pouvoir comprendre et exécuter. Ce programme est facile à écrire car la traduction est immédiate, il suffit de remplacer chaque instruction "humaine" (ADD par exemple) en son équivalent binaire (00000001 par exemple) via une simple table de correspondance, et de traduire des valeurs exprimées en décimal/hexadécimal etc en binaire ce qui est une opération arithmétique très simple.

Ce programme c'est ce qu'on appelle un "assembleur". C'est aussi le nom qu'on donne au langage constitué par l'ensemble des mots comme "ADD" qu'on utilise en lieu et place des instructions binaires.

Cette première étape a permis d'écrire des programmes déjà beaucoup plus sophistiqués et intéressants que ce qu'il était humainement possible de faire en binaire.

Cependant, programmer en assembleur reste très compliqué car il faut avoir une connaissance intime du fonctionnement du processeur, et que le niveau d'abstraction des instruction reste très faible (notre exemple du ADD est volontairement simplifié). 

De fait, aujourd'hui la programmation assembleur est très peu utilisée, sauf pour des cas très précis où on a besoin absolument d'un programme très rapide et/ou le plus court possible : car l'assembleur a les qualités de ses défauts : étant proche du matériel, il permet d'écrire du code parfaitement optimisé à la fois pour la vitesse d'exécution et pour le nombre d'instructions nécessaire pour obtenir le résultat  souhaité. On recoure à l'assembleur pour les pilotes de matériel (drivers), le programme chargé de charger le système d'exploitation (bootloader) sur une carte mère équipé d'un firmware BIOS (voir cet article pour ceux qui veulent développer), et dans des contextes où il y a des contraintes  particulières de taille et de vitesse.

Seconde étape : les langages compilés

Après avoir créé l'assembleur, on a voulu aller plus loin. On a voulu pouvoir exprimer des programmes, donc des suites d'instructions, dans un langage le plus proche possible du langage "naturel" (c'est à dire du langage humain).

Alors, disons le tout de suite, programmer en langage naturel, ça reste encore de la science-fiction, et ça le restera sans doute toujours, car quel que soit le langage (Français, Anglais etc.) il reste beaucoup trop vague, trop riche, et beaucoup trop ambigu pour qu'on puisse le traduire en une suite d'instructions.

Du coup, on a créé de toutes pièces différents nouveaux langages ressemblant le plus possible à du langage humain, ainsi qu'un certain nombre de constructions intellectuelles, plus ou moins élaborées, permettant de faciliter l'écriture de programmes sophistiqués comportant un très grand nombre d'instructions.

Les paradigmes de programmation

Ces constructions intellectuelles, ou paradigmes, permettent d'organiser le grand volume d'instructions requis pour un programme de façon à ce que les choses restent gérables (que le code soit compréhensible, qu'il soit bien organisé, qu'on puisse mutualiser des sections de codes utilisables à plusieurs reprises, qu'on puisse faire évoluer un programme le plus facilement possible et sans casser ce qui marche déjà  etc.).

Il existe différents paradigmes de programmation, et il est probable qu'il en sorte d'autres des laboratoires de recherche en informatique dans les décennies à venir. Il n'y a pas de lien entre le fait qu'un langage s'appuie sur un paradigme donné et le fait qu'il soit compilé (nous verrons plus loin qu'il existe d'autres façon de produire des programmes que d'utiliser des compilateurs) mais nous introduisons cette notion dès à présent.

Je n'irais pas très loin dans le détail ici car il faudrait des encyclopédies entières pour décrire les différents paradigmes de programmation existants, je me contenterais de citer les plus importants et de les commenter succinctement :

• paradigme de programmation impérative : c'est le plus ancien, le plus simple, le plus connu des non professionnels, et celui pour lequel il existe le plus de langages. Parmi les langages impératifs les plus connus citons le langage C, ainsi que la langage Pascal qui a longtemps été utilisé en France pour l'enseignement de la programmation. Le BASIC, langage initialement conçu pour les débutant (Basic est un acronyme où le B figure Beginner, débutant en Français) était un langage impératif à ses origines.

• paradigme de programmation objet ; l'OOP (Object Oriented Programming, Programmation Orientée Objet en bon Français) est probablement le paradigme le plus utilisé aujourd'hui. On peut citer les langages Java, C#, C++ parmi les plus utilisés.

• paradigme de programmation fonctionnelle : ce paradigme bénéficie depuis quelques temps d'un engouement certain, notamment du fait qu'il est adopté par le langage Javascript (avec le paradigme objet, javascript supportant plusieurs styles de programmation. Précision tout de même, javascript n'est pas un langage compilé). Java (le langage le plus utilisé dans le monde actuellement) depuis sa version 8 permet de faire de la programmation fonctionnelle.

• paradigme de programmation déclarative : ici le développeur ne décrit pas une suite d'instruction qui permet d'atteindre un résultat, mais directement le résultat qu'il souhaite obtenir. Un très bon exemple est le langage HTML (qui bien sur n'est pas un langage compilé, mais qui est un bon exemple).

Si vous ne voyez pas ce que sont HTML et javascript, je vous conseille de consulter la série d'articles, de votre serviteur, sur le fonctionnement d'Internet et du Web :

• Les bases pour comprendre le Web - Episode 1
• Les bases pour comprendre le Web - Episode 2
• Les bases pour comprendre le Web - Episode 3

Processus de fabrication d'un programme > compilation

Donc à nouveau, comme avec l'assembleur, les programmeurs ont la possibilité d'exprimer des instructions dans un langage qui n'est pas un langage machine. Et à nouveau, il est nécessaire de traduire ces programmes en langage machine pour que le processeur puisse les comprendre. Cette opération est réalisée par un programme appelé compilateur : c'est la compilation.

On peut le deviner, la compilation est bien plus complexe que la simple traduction directe d'un code assembleur. Les instructions étant plus abstraites, et l'expressivité (les capacité d'expression) du langage infiniment plus évoluées, le compilateur a fort à faire. Pour cette raison, le code binaire résultant est moins optimisé que celui qu'on aurait écrit en assembleur (ou en binaire) ; par contre, il est humainement possible de le produire, et en tout état de cause ça prend infiniment moins de temps et ça coûte bien sur infiniment moins cher (les développeurs ça coûte cher en pizza et en café).

Donc en résumé, on a un code source écrit dans un langage quelconque (il en existe des centaines), un compilateur qui le lit et qui produit un code binaire directement compréhensible par le processeur.

Processus de fabrication d'un programme > édition de lien

Il nous reste une dernière étape pour obtenir un programme exécutable qu'on peut lancer depuis un système d'exploitation, par exemple tout simplement en double cliquant sur le fichier exécutable sous Windows.

En effet, un programme exécutable, pour diverses raisons que je laisse ce côté car nécessitant de longues et complexes explications, n'est pas constitué uniquement d'une suite d'instructions destinées au processeur ; il comporte également un entête qui stocke diverses informations indispensables pour permettre au système d'exploitation de le charger en mémoire et de le rendre ainsi disponible pour exécution par le processeur. Notez bien que ceci est également vrai pour les programmes écrits en assembleur. 

Cette dernière opération qui permet de fabriquer cet entête, et de réaliser un certain nombre d'autres opérations indispensables, s'appelle l'édition de liens (ou linkage, ou linking). Elle est souvent confondue avec la compilation car les outils modernes utilisés par les développeurs réalisent souvent les deux phases de façon transparente.

Pour être complet, il y a un cas où on n'a pas besoin de cette phase : c'est le cas où le programme ne va pas être chargé par le système d'exploitation ce qui est bien sur un cas de figure très réduit puisque le système d'exploitation est lancé dès le démarrage de l'ordinateur. Mais, l'OS étant lui même un programme, il faut bien un programme pour le démarrer, c'est ce qu'on appelle un bootloader ; et ce bootloader n'a pas besoin d'entête et est composé uniquement d'instructions. Pour plus de détail sur ce qu'est un bootloader, vous pouvez lire l'article suivant :
Comment démarre un ordinateur

Quels sont les programmes écrits avec des compilateurs ?

L'écrasante majorité des programmes que vous utilisez tous les jours ont été fabriqués ainsi : les développeurs ont écrit le code source dans le langage de leur choix, puis ils ont lancé la compilation et l'édition de lien pour obtenir au final un fichier exécutable directement utilisable par le système d'exploitation cible (celui pour lequel ils ont choisi de compiler), voire différents fichiers pour différents systèmes d'exploitation si tel était leur choix (si ils voulaient fabriquer un exécutable pour différents OS).


Troisième étape : les librairies partagées

Dès qu'on a eu des compilateurs, on a commencé à les utiliser pour produire pleins de programmes : ben oui, on avait inventé un super outil, c'était bien pour s'en servir.

Et très vite on s'est rendu compte d'un truc tout con : certains aspects étaient à gérer de façon récurrente dans la quasi totalité des programmes.

Que faire alors ?

• le développeur totalement abruti : il va ré-écrire, à chaque fois, dans chaque programme, la même chose ou à peu près. Pas très intelligent (même pas du tout)

• le développeur fainéant : il va copier/coller le code qu'il a déjà écris une fois pour un premier programme, dans tous les suivants. C'est déjà mieux mais si il y a une erreur dans son premier code, il va la reproduire partout, et si il la corrige une fois dans un programme, il devra faire la même correction dans tous les autres où il a déjà copié/collé le truc

• le développeur consciencieux : il va écrire une librairie et la réutiliser... D'où la question à 100 balles, mais c'est quoi une librairie ?

Alors une libraire c'est du code source, écrit dans un langage quelconque, et compilé en binaire avec un compilateur. Comme un programme, sauf que ce n'est pas un programme et qu'il ne peut pas être exécuté par un OS ; c'est juste une suite d'instructions.

Et cette librairie, il suffit de l'utiliser dans les différents programmes en la référençant. Dès lors, son utilisation sera prise en compte lors de la phase d'édition de lien qui suit la compilation dans la génération d'un fichier exécutable.

Et là, dernière subtilité importante, cette prise en compte peut se faire des deux façons suivantes.

Lien statique ou à la compilation

Le code de la librairie est ajouté dans l'exécutable généré. C'est comme le copier/coller du développeur fainéant, sauf qu'au lieu d'un copier/coller du code source par le développeur, c'est un copier/coller de code compilé par le compilateur (enfin l'éditeur de lien pour être précis).

Premier avantage : comme la taille du code source n'est pas augmentée, les temps de compilation ne sont pas impactés. Hé oui, compiler un gros programme, il fut un temps où ça pouvait prendre des heures ou des jours (moins vrai de nos jours avec la puissance des ordinateurs actuels et les progrès des compilateurs).

Second avantage : c'est une opération automatique et non manuelle, donc ça prend moins de temps, et le risque d'erreur est moindre.

Pour le reste, on a toujours les inconvénients de la solution "développeur fainéant". Si on corrige une erreur dans le code source de la librairie, il faut non seulement la recompiler mais également recompiler tous les programmes qui l'utilisent.

En outre, avec l'arrivée des OS multi-tâches, un autre problème s'est posé. Dans un OS multi-tâches, on peut exécuter simultanément plusieurs programmes. Il faut donc les monter tous en mémoire. Hors, si ils sont par exemple 3 à utiliser la même librairie qui fait 50 Ko, l'empreinte mémoire va être de 3 x 50 = 150 Ko. Hé oui, chaque programme embarque le code de la librairie, donc on le charge autant de fois que de programmes qui l'utilisent. Quand on avait des OS mono-tâches, on s'en foutait bien car on ne faisait tourner qu'un programme à la fois, mais ce temps est fini.

Donc au final, l'édition de lien statique à la compilation est peu utilisée. On lui préfère généralement l'édition de lien dynamique à l'exécution pour les raisons évoquées.

Lien dynamique ou à l'exécution

L'éditeur de lien ne vas plus copier/coller le code binaire de la librairie dans le programme exécutable. A la place il va modifier l'exécutable de telle façon que, lorsque le programme appelle une fonction de la librairie : 

• le système d'exploitation charge la librairie en mémoire. Il fait en sorte de ne la charger qu'une seule fois même si plusieurs programmes y font appel (gros avantage par rapport au lien statique donc)

• le programme principal exécute la code de la librairie

• quand le code de la librairie a fini de s'exécuter, le programme principal reprend la main

Et voilà, le tour est joué. Si on a 3 programmes qui utilisent la librairie de 50 Ko, elle n'est chargée qu'une seule fois, et la taille des 3 fichiers exécutables n'est pas augmentée (en tout cas, pas dans la même mesure).

Le gros problème, car il faut bien qu'il y en ait un, c'est que désormais nos 3 programmes ne peuvent fonctionner que si et uniquement si la librairie dont ils sont chacun dépendants est bien installée sur le système... En outre, pour peu que la librairie existe en diverses versions car elle a évoluée dans le temps, et qu'ils utilisent chacun une version différente, ça peut vite devenir le bordel.

Les librairies dynamiques sous Windows, ce sont les fameux fichiers DLL (Dynamic Link Library), et une des raisons de l'instabilité des versions anciennes de Windows c'est justement la mauvaise gestion de ce problème (ce qu'on appelle le DLL Hell, l'enfer des DLL).

Maintenant vous comprenez pourquoi quelques fois, un programme A qui marchait très bien, ne fonctionne plus après que vous ayez installé un programme B : le programme B a une DLL en commun avec A, et lors de son installation il a écrasé la version présente dans le système (et utilisée par A) par une version plus ancienne (utilisée par B).

Versions portables

Certains programmes sont compilés en deux versions. Une version qui fait le lien avec la librairie à l'exécution, et une version qui fait le lien à la compilation. La seconde version est dite "portable", elle est plus grosse mais il suffira de copier l'exécutable sur un OS compatible pour que ça fonctionne (pas de nécessité d'installer les DLL des librairies qu'il utilise).

Compatibilité binaire

Le mécanisme d'édition de lien introduit un couplage entre un programme et le système d'exploitation pour lequel il est compilé : le format de l'entête est spécifique à l'OS cible, de même que le mécanisme de gestion des librairies partagées. 

C'est pour cette raison qu'il n'existe pas de compatibilité binaire : bien que le programme soit une suite d'instructions en langage machine, il ne sera pas possible d'utiliser un même programme sur deux machines disposant d'un même processeur (enfin de deux processeurs supportant la même architecture, et donc le même jeu d'instructions) mais tournant sous des OS différents.

La compatibilité binaire est envisageable entre diverses moutures d'une même famille d'OS, ou dans des conditions bien précises, mais ceci reste délicat et compliqué, il est généralement plus simple de ne pas chercher à finasser et d'installer la version spécifiquement compilée pour l'OS de votre machine. Ou au pire, de se procurer le code source et de la compiler pour votre OS (une opération qui n'est pas rarissime sous Linux).

Il existe dans le cas où on veut utiliser un même programme sur différents systèmes d'exploitation, et même sur différentes architectures processeurs, une solution largement utilisée et qui ne repose pas sur les langages compilés. Cette solution passe par la virtualisation du processeur, nous aborderons ceci dans un second article.

Conclusion temporaire 

Comme en informatique rien n'est jamais simple, il existe également des programmes qui ne sont pas compilés dans le langage machine compris par le processeur :

• soit il ne sont pas compilés du tout, et on parle alors de langage interprété, 

• soit ils sont compilés dans un code machine virtuel c'est à dire dans un langage binaire ne correspondant pas au jeu d'instruction d'un processeur, mais à celui d'un ordinateur virtuel (un programme qui fait de façon logicielle ce que fait un ordinateur avec des pièces électroniques).

Il y a bien sur des raisons à cela, des avantages, et des inconvénients également.

Nous expliquerons cela dans un second article.