Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    février 2017
    Messages
    746
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 746
    Points : 26 113
    Points
    26 113

    Par défaut Il n’y a rien de mieux que le langage de programmation C pour le développement de systèmes d’exploitation

    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

    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.

    Nom : Redox.png
Affichages : 6732
Taille : 586,4 Ko
    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Post-Doctorant
    Inscrit en
    juillet 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Post-Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 127
    Points : 533
    Points
    533

    Par défaut

    Le gros soucis ça reste qu'atteindre un haut niveau de fiabilité dans un composant aussi critique d'un OS nécessite un boulot de dingue. Et à l'échelle d'un truc qui fait plusieurs millions de lignes de code, c'est juste infaisable d'obtenir des vraies garanties de fiabilité avec un effort raisonnable. Et C est définitivement l'un des langages où c'est le plus difficile. Ce n'est pas parce qu'un langage est de plus haut niveau que nécessairement il occulte tous les détails de bas niveau (et on pourrait aussi arguer que C occulte lui aussi énormément de détails selon comment on l'utilise). Mais si on prend des retours d'expérience comme HACL* (F-Star) ou Pip protokernel (Coq), on peut voir que l'utilisation d'un langage de haut niveau n'implique pas de cacher les détails nécessaires au bas niveau, simplement de devoir effectivement les prendre complètement en compte et pas juste de tester un ensemble restreint de scénarios.

  3. #3
    Membre confirmé
    Inscrit en
    juin 2010
    Messages
    577
    Détails du profil
    Informations forums :
    Inscription : juin 2010
    Messages : 577
    Points : 551
    Points
    551

    Par défaut

    Le top reste le combo C/C++/C#, j'arrive la lire de l'object-c sans problème mais je n'aime pas trop la syntaxe quoique le délire de considérer que tout est un dictionnaire est assez funky

  4. #4
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Post-Doctorant
    Inscrit en
    juillet 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Post-Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 127
    Points : 533
    Points
    533

    Par défaut

    Citation Envoyé par redcurve Voir le message
    Le top reste le combo C/C++/C#
    Ça dépend des objectifs, encore une fois. Faire du code sûr en C, c'est pas simple. Il y a qu'à voir comment des projets comme seL4 en ont chié pour arrivé à un niveau EAL7 de sûreté (25 personnes-année pour 10K lignes de C - sachant que c'est la preuve qui a été hardcore, pas le process de certif en lui même). Et honnêtement, pour des composants aussi critiques qu'un OS, avoir des vraies garanties de sécurité et sûreté, ça serait pas un mal.

  5. #5
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 876
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 876
    Points : 3 077
    Points
    3 077

    Par défaut

    Je me demande si à l'époque de Torvalds, il y avait des pattern de programmation comme actuellement.

    Bien découper le code ça aide
    Si la réponse vous a aidé, pensez à cliquer sur +1

  6. #6
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 645
    Points : 2 849
    Points
    2 849

    Par défaut

    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

  7. #7
    Membre actif Avatar de Se7h22
    Homme Profil pro
    Développeur Web
    Inscrit en
    août 2010
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2010
    Messages : 120
    Points : 291
    Points
    291

    Par défaut

    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.

  8. #8
    Membre éclairé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    404
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 404
    Points : 793
    Points
    793

    Par défaut

    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.

  9. #9
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    26 942
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 26 942
    Points : 39 908
    Points
    39 908

    Par défaut

    Pour un truc bas niveau comme ça, je tendrais à privilégier le C++, qui permet de descendre exactement à aussi bas niveau que le C quand on en a besoin, avec l'ajout de la sécurité sur la manipulation des ressources.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  10. #10
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    10 815
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 10 815
    Points : 24 098
    Points
    24 098

    Par défaut

    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.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutoriels/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  11. #11
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 645
    Points : 2 849
    Points
    2 849

    Par défaut

    Citation Envoyé par chrtophe Voir le message
    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.
    Entre les bugs de gestion mémoire ou de concurrence, les failles de sécurité à la buffer overflow et autres, les codes inmaintenables, etc, l'intérêt du C reste également à prouver.

    Concernant les alternatives au C, Rust semble quand même avoir des vrais intérêts.
    https://www.rust-lang.org/what/embedded
    https://www.redox-os.org/

  12. #12
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    10 815
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 10 815
    Points : 24 098
    Points
    24 098

    Par défaut

    Entre les bugs de gestion mémoire ou de concurrence, les failles de sécurité à la buffer overflow et autres, les codes inmaintenables, etc,
    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.

    l'intérêt du C reste également à prouver.
    Tous les OS du marché sont à ma connaissance basé sur le C.

    Je vais jeter un œil sur Redux, Même si ça perce pas, l'alternative reste intéressante à étudier.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutoriels/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  13. #13
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Post-Doctorant
    Inscrit en
    juillet 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Post-Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 127
    Points : 533
    Points
    533

    Par défaut

    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.

  14. #14
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 645
    Points : 2 849
    Points
    2 849

    Par défaut

    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.
    C'est aussi ce que disaient les programmeurs assembleur des programmeurs C il y a quelques décénnies...

    Citation Envoyé par chrtophe Voir le message
    Tous les OS du marché sont à ma connaissance basé sur le C.

    Je vais jeter un œil sur Redux, Même si ça perce pas, l'alternative reste intéressante à étudier.
    Haiku OS -> C++ https://fr.wikipedia.org/wiki/Haiku_...7exploitation)
    MaRTE OS -> Ada https://fr.wikipedia.org/wiki/MaRTE_OS
    MirageOS -> OCaml https://mirage.io/
    Mezzano -> Common Lisp https://github.com/froggey/Mezzano
    ...

    Evidemment, ce ne sont pas des OS mainstream mais ça prouve qu'il est parfaitement possible de programmer un OS dans d'autres langages. 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.

  15. #15
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    10 815
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 10 815
    Points : 24 098
    Points
    24 098

    Par défaut

    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.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutoriels/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  16. #16
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 645
    Points : 2 849
    Points
    2 849

    Par défaut

    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....

  17. #17
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    10 815
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 10 815
    Points : 24 098
    Points
    24 098

    Par défaut

    empêcher les buffer overflow
    Dans ce cas je t'invite à lire :
    How Rust’s standard library was vulnerable for years and nobody noticed

    seg fault pushing on either side of a VecDeque
    https://github.com/rust-lang/rust/issues/44800

    This is a buffer overflow bug in the standard library’s implementation of a double-ended queue. The data written out of bounds is controlled by the attacker. This makes it a good candidate for a remote code execution exploit.

    The bug affects Rust versions 1.3 to 1.21 inclusive. It is causing a crash that is relatively easy to observe, yet it has gone unnoticed for two years. In the release that fixed it it did not even get a changelog entry. No CVE was filed about this vulnerability.
    Mais rassure-toi, il n'y a a pas de CVE.

    Il ne faut pas croire qu'un langage plus récent/évolué qu'un autre n'engendrera pas de problèmes, ni qu'il n'y aura pas de vecteurs d'attaques identiques à ceux connus voire de nouveaux.

    Après dans cet exemple, un segfault kille le processus, le problème est donc en théorie circonscrit mis à part la perte éventuelle de données dans l'appli crashée.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutoriels/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  18. #18
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 645
    Points : 2 849
    Points
    2 849

    Par défaut

    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.

  19. #19
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Ancien développeur matériel électronique (Hard/Soft)
    Inscrit en
    avril 2002
    Messages
    2 365
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ancien développeur matériel électronique (Hard/Soft)
    Secteur : Service public

    Informations forums :
    Inscription : avril 2002
    Messages : 2 365
    Points : 7 709
    Points
    7 709

    Par défaut

    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.
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  20. #20
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 645
    Points : 2 849
    Points
    2 849

    Par défaut

    Citation Envoyé par Vincent PETIT Voir le message
    Je ne sais pas si vous voyez ce que je veux dire ? [/I]
    Pour être honnête non :
    - Un langage n'a pas besoin d'un OS mais d'un "runtime system". Même le C en a un (https://en.wikipedia.org/wiki/Runtime_system#Examples).
    - Il est tout à fait possible de faire un OS avec un langage à exception et à garbage collector. Il faut "juste" que ce soit dans le runtime system. Au passage, il me semble que Rust n'a pas de garbage collector ni d'exception à la try/catch.
    - Rust fait du typage statique : les types sont vérifiés à la compilation. Il n'y a pas besoin de système de typage dans le runtime system.

    Pour info, Redox OS fonctionne directement sur le matériel, sans passer par un OS support.
    https://discourse.redox-os.org/t/run...hardware/146/8
    https://doc.redox-os.org/book/overvi..._redox_is.html

Discussions similaires

  1. [Graphiques] Quoi de mieux que JFreeChart ?
    Par elitost dans le forum Graphisme
    Réponses: 4
    Dernier message: 21/04/2006, 16h20
  2. D7P mieux que D6P ?
    Par David dans le forum EDI
    Réponses: 5
    Dernier message: 16/06/2004, 21h15
  3. [dBase]il y a mieux que la commande sql UPDATE ?
    Par sana72 dans le forum Autres SGBD
    Réponses: 4
    Dernier message: 12/12/2002, 11h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo