IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Il n'y a rien de mieux que le langage de programmation C pour le développement de systèmes d'exploitation
D'après Linus Torvalds

Le , par Patrick Ruiz

1.1KPARTAGES

11  2 
La déclaration est de Linus Torvalds – le créateur du système d’exploitation open source Linux – lors d’une de ses interventions à l’Intel Open source Technology Center en 2012. Il répondait à la question de savoir s’il voit un autre langage de programmation à part le C qui soit taillé sur mesure pour le développement de systèmes d’exploitation. Quelques extraits de sa réponse …

Citation Envoyé par Linus Torvalds
Je dois dire que je suis assez vieux jeu sur des sujets comme celui-là. La raison pour laquelle je me suis lancé dans Linux et les systèmes d’exploitation en général est que j’aime vraiment le hardware ; j’aime explorer l’aspect matériel. Je ne le dis pas pour souligner que je suis un expert en hard parce que me tendre un fer à souder serait une mauvaise idée. Ce que je veux dire c’est que j’aime interagir avec le matériel à partir du logiciel. Vu sous cet angle, je n’ai pas encore vu un langage de programmation qui approche seulement le langage C. Cette affirmation ne tient pas uniquement à ce que le C soit utile pour générer du bon code pour piloter le matériel. Ce qu’il faut dire en plus c’est que l’usage du C fait sens pour des personnes qui pensent comme un ordinateur. Je crois que la raison pour laquelle il en est ainsi est que les personnes qui ont conçu le langage C l’ont fait à un moment où les compilateurs devaient être simples ; à un moment où le langage devait être adapté à la sortie ou au résultat attendu. Donc lorsque je lis du code en langage C, je sais à quoi va ressembler le code assembleur et c’est ce qui m’intéresse.
Certes, la déclaration de Linus Torvalds date, mais 7 années plus tard, des avis récoltés sur la toile lui donnent un coup de neuf.

Citation Envoyé par un internaute
Le C est à bien des égards un langage ingénieux. C'est une très bonne abstraction du matériel sous-jacent. Assez transparent pour "voir" ce qui se passe à un niveau inférieur et juste assez haut niveau pour fournir quelques constructions utiles et éviter la peine de faire usage de l'assembleur.

Bon nombre de ses "défauts" sont en fait la conséquence directe de cette conception. Si vous comprenez le processeur et la mémoire, vous trouverez le C naturel. D'autres langages qui sont vantés comme modernes, plus faciles et tout le reste, font tellement abstraction de l'aspect matériel qu'une grande partie du contrôle fin est perdue. C'est un compromis.

C a certainement des défauts. Il porte en lui un héritage dont il est difficile de se débarrasser, mais la façon dont il garde le programmeur près du matériel n'est pas un défaut, c'est une caractéristique dont il faut dire qu'elle est de plus en plus difficile à trouver.

La sortie de Linus Torvalds est antérieure à la publication de la première version stable de Rust – l’un des langages de programmation pressentis comme remplaçant du C sur le terrain du contrôle du hardware. En fait, au moment où Linus s’exprime, Rust n’en est qu’au stade de l’enfance.

Citation Envoyé par un internaute
De nos jours, Rust est une véritable alternative et offre des caractéristiques qui le rendent tout simplement plus polyvalent. Nous avons d'abord besoin d'un code sûr et donner des garanties de sécurité élevées est l'un des aspects les plus importants d'un système d'exploitation ou d'un programme. Je suis absolument sûr que quelque chose de similaire à Rust sera utilisé pour écrire le système d'exploitation qui remplacera Linux sur le long terme.
Ce qu’il faut en effet souligner à propos de Rust est que le langage garde une vision proche de la machine. Il est clairement prévu pour être utilisable pour des applications de très bas niveau comme un noyau, des pilotes de périphériques ou de l'embarqué temps réel. Il permet aussi d'éviter certains points complexes du C++, mais n'est pas aussi radical. Il s’appuie pour cela sur des génériques et un système de macros plus propre que celui de C++. Il est par contre plus complexe sur un point particulier : il surveille à la compilation la durée de chaque variable ; il vient qu'une utilisation des pointeurs qu'il ne peut garantir sûre refusera de compiler. Pour éviter cela le développeur doit bien assimiler les notions de propriété et de durée de vie d'un pointeur qui permettent de garantir que le code est sûr. Cela permet d'avoir une garantie absolue qu'il n'y aura aucune erreur de sécurité mémoire.

Dans la liste des systèmes d’exploitation créés à partir de Rust on compte Redox. L’équipe de développeurs derrière cet OS le présente comme un « système d’exploitation open source qui vise l’intégration des innovations au sein de Rust à un microkernel et un ensemble complet d’applications. » Le système d’exploitation est publié sous licence MIT.

Le GUI Orbital sous Redox


De façon générale, l’intervention de Linus Torvalds relance le débat sur la question de savoir quel langage pourrait remplacer le C. Il y a 4 ans, l’architecte logiciel Andrei Alexandrescu a dressé un comparatif de Go, Rust et D. De façon brossée, il en resssortait que pour ses caractéristiques d’introspection statique, son temps de compilation rapide ajouté à d’autres atouts uniques, le langage D est le remplaçant idéal du C.

Sources : YouTube, Redox

Et vous ?

Que pensez-vous de la déclaration de Linus Torvalds ?

Depuis 2012, quel langage de programmation s’est d’après vous positionné en véritable remplaçant du C ?

Pourquoi le langage C pourrait encore avoir de longues années devant lui ?

Voir aussi :

Programmation : un « Pony » peut cacher un langage, l'outil adéquat, d'avis d'utilisateurs, pour le développement d'applications concurrentes

C2 : un langage qui se présente comme une évolution de C, plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements

Quel avenir pour le langage C ? Un développeur expérimenté fait ses adieux au langage et livre ses inquiétudes quant à son avenir

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de
https://www.developpez.com
Le 25/03/2019 à 21:14
Citation Envoyé par hotcryx Voir le message
Je me demande si à l'époque de Torvalds, il y avait des pattern de programmation comme actuellement.

Bien découper le code ça aide
Non non. A l'époque de Torvalds (paix à son âme), on faisait marcher un chaton sur le clavier et quand ça compilait on sortait une nouvelle release. https://en.wikipedia.org/wiki/Design_Patterns
9  0 
Avatar de Se7h22
Membre confirmé https://www.developpez.com
Le 25/03/2019 à 21:36
Citation Envoyé par Patrick Ruiz Voir le message
La déclaration est de Linus Torvalds – le créateur du système d’exploitation open source Linux – […]
Pour rappel, Linus Torvalds est le créateur du noyau Linux, et non du système d'exploitation GNU/Linux ;-)

Sinon, je n'ai pas vraiment d'avis sur la question, même si j'imagine qu'il a plus ou moins raison vu que le langage C à fait ses preuves, je pense. Mais il n'est pas inimaginable qu'il soit remplacé un jour pour réaliser des systèmes d'exploitation.
7  0 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 25/03/2019 à 23:41
Personnellement en 30 ans de dev, j'ai toujours decoupé mes softs en couches (regle d'or) et jamais eu aucun probleme de conception, quel que soit le langage.
Le principe des micros services on en faisait deja a l'epoque sous Linux - c'etait meme un principe elementaire, combiner des applications/utiltaires faisant individuellement des choses tres simples. Tu peux batir un OS avec ce simple principe.
Alors oui on a inventé C# parce que C/C++ etait considéré comme trop compliqué (oui avoir de la rigueur c'est pas donné a tout le monde). Du coup maintenant on code en C# sans se poser des questions (sauf que nombre de devs ne comprennent meme plus pourquoi des fois y a des problemes de GC et autres). C# a permis de democratiser la programmation et mettre le C au niveau du visual basic - n'importe qui peut faire du C#, c'est sa force.
C'est la base de tout. Les patterns on les suivait sans le savoir; tout comme je me rends compte qu'on a toujours ete agile dans les devs. Cycle en vie etant plus theorique car dans la pratique c'etait une forme d'agilité qui prevalait.
6  0 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 29/03/2019 à 15:56
Citation Envoyé par chrtophe Voir le message
Il s'agit souvent d'un problème d'interface chaise clavier, de mauvaise programmation. C'est sûr que ce type de problèmes est masqué par le langage quand tu utilises du C++ ou autre.
Oui c'est précisément le point : il est très facile de faire du code buggé en C, bien plus facile que dans beaucoup d'autres langages, et dans le même temps les dites erreurs peuvent être beaucoup plus difficile à détecter. On sait bien que les problèmes sont avant tout dus à de la mauvaise programmation, mais justement la question est là : qu'est ce qu'on devrait utiliser pour qu'il soit plus difficile de faire de la mauvaise programmation. Et pour ça, C n'est pas un cadeau.

Citation Envoyé par chrtophe Voir le message
Tous les OS du marché sont à ma connaissance basé sur le C.
Et une nouvelle fois ce n'est pas parce que c'est ce qui est fait partout que c'est une bonne chose. C'est pour une bonne part dû à l'histoire, et à la formation des développeurs qui font généralement ces systèmes qui n'ont pour leur vaste majorité jamais vraiment autre chose que C. Faire du soft blindé en C c'est extrêmement coûteux. Et si tu prends un domaine comme les systèmes formellement vérifiés quand tu as un soft qui est composé que 10 000 lignes de C et 200 000 lignes de code dans un langage de vérification, finalement c'est peut être plus tout à fait exact de dire que la base de confiance c'est C.
6  1 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 30/03/2019 à 13:04
Voici ce que j'ai dit :
Je reste septique sur l'utilisation d'autre chose que le C pour un OS, (du moins pour le noyau et les pilotes). L'intérêt qu'autre chose que le C reste à prouver.
Je n'ai pas dit que ce n'était pas faisable.

ça prouve qu'il est parfaitement possible de programmer un OS dans d'autres langages.
Et quel est l’intérêt ?
La prédominance du C dans les OS, c'est essentiellement parce qu'il est simple, supporté par tous les fabricants de matériel et connu par tous les programmeurs.
Là je suis d'accord avec toi. Et c'est quand même des éléments majeurs.

Il est à noter qu'à l'origine Unix (origine de Linux, de MacOS via freeBSD) n'était pas programmé en C, mais a été entièrement réécrit en C. Cela date des années 70. Depuis, bien d'autres langages ont été créés, Unix n'a pas été réécrit dessus. Microsoft, qui à la base créait des compilateurs, n'a pas utilisé autre chose que le C/C++ (C++ étant un sur-ensemble de C) pour écrire Wiindows.

Pour tes exemples :

- Haiku : démarré en 2001, en beta depuis septembre 2018 : inexploitable vu la lenteur (j'ai testé). Juste un navigateur : mais qui semble à peu près fonctionnel. Libreoffice a été porté dessus semble t'il. J'ai arrêté là.
- Marte OS : c'est un système temps réel, comme QNX ou windows CE, fourni sous forme de tar.gz : contenant des fichiers .c ??? .Pour un système embarqué, j'utiliserais plutôt de l'Arduino, qu'on programme plutôt ... en C. Par ailleurs il boote via Grub, le noyau se présente sous forme d'un fichier ELF. Il te faut donc Linux pour le compiler.
- MirageOS : système basé sur le principe d'unikernel, en gros c'est de la virtualisation, il te faut un hyperviseur. Je ne sais pas si on peut vraiment considérer ça comme un OS.
- Mezzano : On peut lancer Doom ou Quake : super. Rien d'autre d'utile, et pareil : lenteur extrème.
Pour rester objectif, la lenteur est quand-même à pondérer par le fait que j'ai testé en VM. Mais avec l'UEFI maintenant, même pas sûr qu'oin puisse booter en réel (sauf dans le cas d'utilisation de Grub, bootloader de linux).

Tous ces trucs sont des proofs of concepts de possibilité de coder un OS avec autre chose que le C, mais en quoi est-ce mieux, ou moins bien ?
Il existe aussi des Os en js (OS.js), en VB.net (Flux OS) : ça n'en fait pas des langages adaptés au remplacement du C pour coder un OS.

Quant à Redox, Super lent et impossible d'aller sur le net, impossible de saisir un eURL dans le browser (j'ai peut-être pas compris comment ça marche)

ReactOS, projet d'OS alternatif compatible Windows est compatibles avec les pilotes windows, fait tourner AbiWorld, Nero, firefox, liste non exaustive. Il est écrit en C et toujours en version Alpha. Pourquoi je le cite ? Car grâce au projet Haiku, dont le test ne m'a que très moyennement convaincu, ReactOS dispose d'un pilote USB de stockage de masse .ReactOS et Wine, connu pour permettre de lancer des executables Windows sous Linux sont des projets qui s'apportent mutuellement des choses.

Je n'ai donc vu aucun des OS sités non écrit en C exploitable (ça veut pas forcément dire qu'il n'y en a pas). Je reconnais le gros travail fait, mais il reste encore beaucoup à faire.
6  1 
Avatar de Vincent PETIT
Modérateur https://www.developpez.com
Le 31/03/2019 à 14:29
Salut,
Il y a quelques choses que je ne comprends pas ci après, j'ai l'impression que tout ceci est un faux problème.
Citation Envoyé par SimonDecoline  Voir le message
- empêcher les buffer overflow
- empêcher les data race condition
- empêcher les allocations non libérées
- empêcher les accès à des zones mémoires invalides ou libérées
- avoir un vrai système de type et non des "void *" + cast
- avoir des vrais types génériques
- avoir un langage plus expressif, qui rend le code plus court et plus lisible
- ...

Je travaille souvent en C sur des microcontrôleurs sans aucun OS et sans ce dernier il n'y a aucune gestion des overflow, si on en fait un il ne se passe rien du tout, pas plus que de mécanisme de violation des zones mémoires. On peut se balader n'importe où dans la mémoire sans aucun problème. Sans OS, pas question de faire des try catch en espérant attraper un événement puisque rien n'est implémenté. Sans OS ça ne "try"era rien, pas plus que ça "catch"era quelque chose. Un langage prenant en charge le garbage collector va se trouver dans de beaux draps si on l'utilise pour faire un OS car lors de l'écriture de celui-ci, le mécanisme sous-jacent n'est pas encore implémenté. Un langage qui a un vrai système de type ne peut pas les mettre en oeuvre pendant l'écriture de l'OS car idem, tout reste à implémenter.

Les langages plus récents et plus performants le sont parce qu'ils tournent sur un OS mais sans OS, directement face au processeur, les langages aussi récent soient ils se retrouvent littéralement à poils comme le langage C.

Je ne sais pas si vous voyez ce que je veux dire ?

Je pense personnellement qu'il peut y avoir pleins d'autres langages pour faire un OS mais directement face au processeur tous ces autres langages ne seront pas (ou pas beaucoup) plus armés que le C. En revanche, une fois qu'il y a un OS, il y a pléthore de langages bien plus préformant dans leur interaction avec l'OS.
5  0 
Avatar de
https://www.developpez.com
Le 31/03/2019 à 12:34
Citation Envoyé par chrtophe Voir le message
Merci pour l'article. Je t'invite à le relire également car visiblement tu l'as mal compris ou les choses ont évoluées.

L'article vante principalement les méthodes de travail qui mettent en avant la sécurité, comme les CVE. Le bug que tu mentionnes a un CVE, c'est même écrit dans l'article (https://cve.mitre.org/cgi-bin/cvenam...E-2018-1000657).

L'article parle effectivement de ce bug de la lib rust mais il parle aussi d'une faille dans libjpeg qui, pendant 10 ans, permettait de récupérer les mots de passe du navigateur !

Il parle aussi de python : "Python runtime gets at about 5 remote code execution vulnerabilities per year"

Il parle aussi des buffer overflow dans une bibliothèque utilisée par tous les navigateurs web : "When I asked the maintainers to file a CVE, they said that if they filed one for every such bug they fixed they’d never get any actual work done."

du langage C en général : "it is evident that humans are unable to write secure C code, unless they swear off dynamic memory allocation altogether"

et du langage rust en général : "There is a mathematical proof of correctness for a practical subset of safe Rust and even some inherently unsafe standard library primitives, and ongoing work on expanding it to cover even more of the language."

Bref, si ton avis est que le langage C convient et que le problème vient des développeurs, l'article dit à peu près exactement le contraire.
4  0 
Avatar de
https://www.developpez.com
Le 30/03/2019 à 23:01
Citation Envoyé par chrtophe Voir le message
Et quel est l’intérêt ?
Alors, sans ordre particulier :
- empêcher les buffer overflow
- empêcher les data race condition
- empêcher les allocations non libérées
- empêcher les accès à des zones mémoires invalides ou libérées
- avoir un vrai système de type et non des "void *" + cast
- avoir des vrais types génériques
- avoir un langage plus expressif, qui rend le code plus court et plus lisible
- ...

Maintenant c'est sûr qu'avec des programmeurs parfaits qui ne font pas d'erreur, tout cela est inutile mais dans ce cas je me demande pourquoi il y a eu 2000 CVE en 20 ans (https://www.cvedetails.com/product/4...l?vendor_id=33) et pourquoi les programmeurs linux ne codent pas directement en binaire plutôt que de s'embêter avec des compilateurs....
4  1 
Avatar de Médinoc
Expert éminent sénior https://www.developpez.com
Le 02/04/2019 à 10:51
Le problème, c'est que les exceptions que tu mentionnes n'ont rien à voir avec les exceptions C++; elles y sont complètement orthogonales et le C++ n'a pas vocation à les attraper.
Un try/catch du C++ n'attrape que les exceptions explicitement lancées avec un throw. C'est purement une question de contrôle de flux d'exécution et gestion des ressources.

D'un autre côté, c'est aussi un argument contre le C++: Utiliser des classes et destructeurs peut-il vraiment assurer la libération des ressources alors qu'on est à un niveau où l'on doit pouvoir gérer aussi les exceptions venant du hardware?
3  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 28/03/2019 à 20:55
Je reste septique sur l'utilisation d'autre chose que le C pour un OS, (du moins pour le noyau et les pilotes). L'intérêt qu'autre chose que le C reste à prouver.
3  1