Rust n'est pas imposé, les réfractaires peuvent toujours utiliser le C.Y'a aucun intérêt à perdre son temps sur d'autres langages quand on veut s'adresser à la machine.
Il faut vivre avec son temps, sans forcément renier ce qui marche
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
Discussion :
Rust n'est pas imposé, les réfractaires peuvent toujours utiliser le C.Y'a aucun intérêt à perdre son temps sur d'autres langages quand on veut s'adresser à la machine.
Il faut vivre avec son temps, sans forcément renier ce qui marche
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
Et oui ! Et la gestion mémoire ne devrait plus être un sujet aujourd'hui, En tout cas ce n'est pour moi plus un sujet depuis deux décennies au moins, heureusement.Envoyé par chrtophe
Et puis, utiliser l'argument du "je ne sais pas sécuriser la gestion mémoire" pour justifier de l'usage d'un nouveau langage, ca confine dans un amateurisme certain.
Vivre avec son temps, ca serait de voir Linux devenir une alternative grand public aux O/S actuels... Vivre avec son temps ca serait d'avoir un un pack office en Europe ou bien un Z pour remplacer X... mais si on en est encore à la gestion mémoire...
Parfois il m'arrive de faire qqc compilation sur Ubuntu + Eclipse, mais on est très loin de Win95 + Borland c++ (ne serait-ce que pour la gestion de projet) ou Win98 + Visual Studio 6 que j'utilise encore pour compiler des app compatible WinXP. ca fait 30 ans quand même! Si Linux vivait avec son temp, la communauté s'occuperait de satisfaire les développeurs et les utilisateurs plutot que de tourner en rond sur le noyau à implémenter des choses inutiles...
Il faut remettre les choses dans le contexte de l'époque.
En C, le programmeur sait ce qu'il fait, c'est un langage pouvant faire du bas niveau. Vu que le programmeur est censé savoir ce qu'il fait, les contrôles sont limités, ce qui permettait à l'époque de pouvoir écrire un compilateur "facilement" dans un contexte de puissance limitée à l'époque.
Est ensuite apparu une surcouche pour la programmation orientée objet : le C++. Depuis les langages ont divergés. Le fameux ramasse-miette par exemple, qui va limiter les problèmes mémoire, demande des ressources qui à l'époque étaient précieuses.
On parle d'une époque ou les PC (ou les machines antérieures) ne disposaient pas de MMU, les OS n'étaient pas sécurisés, chaque appli pouvait accéder complètement à la mémoire, pas de problème de sécurité : il n'y avait pas Internet.
L'ordinateur du programme Apollo, à la même époque que l’arrivée du C : c'est un CPU à 1Mhz, 4 Ko de RAM, 36Ko de ROM, pour 32 Ko.
Le premier IBM PC : CPU 4,77 Mhz, 16 Ko de RAM sans disque dur.
Voila avec quoi on bossait. Et pourtant le C est toujours là.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Je serais curieux d'avoir les details, il y a certes moyen avec de bons outils d'améliorer la sécurité mémoire du C, mais en général, même si c'est déjà mieux que rien, ça reste partiel parce que le langage n'a pas été pensé pour ça. Après il y a des solution du type Fil-C mais ça a un impact significatif sur les performances, ce qui est contradictoire avec la raison pour laquelle beaucoup choisissent le C.
Sauf que le compilateur est justement le premier outil pour vérifier et valider l’exécution du code. Et si le langage a été conçu pour l'aider dans cette tache, il peut-être plus efficace.
Je me disais que j’exagérais un peu en disant :
mais cette fois ci, ça n'a pris que 9 messages.
Le C est un langage des système et des programmes exécutés. Le Rust en est un autre. On est d'accord que le Java ou le Python ne seront jamais adapté à du bas niveau comme un OS, mais le Rust en a tout à fait les capacités.
C'est très simple, vous faites une surcouche checkedMalloc/CheckedFree qui va allouer un peu plus de mémoire que demandée pour avoir des zones check avant et après l'espace demandé et vous enregistrez l’état des pointeur (alloc/free) dans un tableau. Ainsi vous êtes en capacité de savoir si tout a bien été libéré à la fin du programme et si rien n’a été écrit en dehors des espaces alloués... Avec la puissance des PC actuels, vous pouvez même faire un appel dans un timer qui vérifie que les « espace check » restent intègre durant le déroulement du programme...
Tous les développeurs de logiciels ont ce genre d'outils, ce n'est pas possible de développer qqc de fiable autrement.
Vous répétez que Rust n'est pas imposé et reste une option, mais il est entrain de s'imposer à la communauté des développeurs Linux, comme une contrainte qui va consommer de la ressource, gaspiller du temps, et générer quantité de bug et regressions pour des années, alors qu'il y aurait d'autre priorités bien plus importantes. comme fournir un IDE qui sache réellement gérer les projets de compile par exemple...
Sauf que les erreurs de sécurité mémoire sont à l'origine de plus des 2/3 des vulnérabilités critiques constatées en C et C++. C'est un constat récurent fait par tous ceux qui entretiennent de grosse base de code critique et donc très surveillées comme Oracle, Microsoft, Mozilla, Google, ... Donc, soit même les application les plus critiques sont gérées par des hordes d'amateurs (j'en doute), soit malgré toute la compétence possible, quand un code atteint un minimum de complexité, on finit forcément par faire des erreurs.
Et ça pour le coup, j'ai l'impression de devoir le répéter tous les 5 messages.
C'est des sujets qui n'ont rien a voir. Windows qui est un OS on ne peut plus grand public, lui aussi introduit Rust progressivement dans son OS, y compris le noyau.
Quant a remplacer Office et X, je serais le premier heureux, mais ça n'a rien a voir avec le langage, ils pourraient être refait en n'importe quel langage, et s'il fallait en choisir un, je ne prendrait certainement pas le C, et même probablement pas le Rust, du moins dans le cas de X.
Ben si, Quand on a des ressources limitées, on ne peux pas adopter les mêmes priorités et stratégies que les grands groupes industriels. La priorité de Linux devrait être de proposer des alternatives réelles et d’inonder le marché de solutions faciles d’accès pour les grands cas d’usage, comparables avec ce qui se fait sur Windows / macOS … Et ca commence par un outil de développement genre Visual C qui proposerait au moins les même services sur les workflow principaux...
C'est plus ou moins ce que je supposais. C'est des systèmes de détection au Runtime classiques qui ont un surcout qui fait qu'on ne les active souvent pas en production et qui peuvent rater des cas particuliers. Les compilateurs modernes ont généralement déjà les outils nécessaires pour faire ce type de vérification et les applications qui prennent la sécurité au sérieux les utilisent au moins pendant la phase de développement.
C'est très bien, mais loin d'être parfait, sinon ça ferait longtemps qu'on aurait plus de vulnérabilités mémoire, or ça reste le problème majoritaire dans les application C++, y compris celles très surveillées.
Il n'impose quasiment rien a ceux qui ne souhaitent pas s'en soucier. Le cœur du noyau restera en C et l'interface entre ce noyau et le Rust est à la charge du projet Rust for Linux qui assume la maintenance en cas de changement de l'API dans le code C.
En ce qui concerne les bug et régression, pour le moment il semblerait que Rust soit plus bénéfique que problématique le langage étant beaucoup plus strict.
On est dans du projet libre, on ne parle pas de ressources qu'un dirigeant pourrait affecter facilement selon sa volonté.
Les gens qui travaillent sur le noyau sont plutôt spécialistes du très bas niveau, généralement des volontaires qui apprécient ce genre de travail. Ils ne vont pas naturellement se mettre à programmer un Office ou X : c'est des compétences très différentes.
Mais ils ont les compétences pour faire un IDE genre Visual C. ils ne le font pas non plus.
Il vaut mieux un système qui détecte les bugs à la compilation qu’à l’exécution. Et c’est ce que fait Rust pour les allocations mémoire.
Pour l’indexation des tableaux, il vaut mieux détecter les erreurs dès l’usage d’un index inadapté que plus tard lors d’une étape de vérification (libération de la mémoire par exemple). (À l’extrême, en Ada on peut même avoir l’erreur lors de l’assignation d’un index trop grand - avant même son usage - si le type de l’index est bien choisi).
Sinon, en matière d’IDE, il y a VS Code, Netbeans, Eclipse (entre autres)… bref l’embarras du choix.
Je suis pas sûr que l'on puisse honnêtement rendre Rust responsable de ça, vu que la situation était déjà la même des années avant son introduction dans Linux, et même bien longtemps avant sa création.
Les tentatives de faire des IDE ne manquent pas (Code Blocks, QtCreator, Kate, Eclipse CDT, ...), mais c'est généralement pas des développeur bas niveau que ça motive le plus. Beaucoup sont très contents de travailler avec variantes de vim et emacs.
« La priorité de Linux »… derrière Linux (au sens large), il y a une multitude de profils de développeurs, chacun s’intéressant à des aspects différents (noyaux, interface graphique, IDE, suite bureautique, intégration d’une distribution…) et avec des agendas et motivations différents.
Et chacun est libre de contribuer s’il trouve une lacune… (nouveau logiciel/fonctionnalité, correctifs, bug report, documentation…).
Le plus gros problème de Linux sur le bureau concerne les applications. Ainsi, la plupart des logiciels commercialisés le sont uniquement pour Windows et Mac. Et même, LibreOffice Calc ne rivalise pas complètement avec Excel. C’est un peu un problème de poule et œuf (pas de prise en compte tant que Linux n’est pas assez répandu, et réciproquement)
Par contre, côté serveur, Linux a fait sa place… même SQL server tourne dessus !
Côté serveur ou même embarqué, d’accord... mais même dans ces secteurs professionnels, avoir un IDE équivalent d'un VC6 apporterait une dynamique nouvelle et permettrait justement d’avoir plus de contribution.
Une condition qui ferait venir des développeurs (comme moi ou d’autre) c’est d’avoir une gestion de projets aboutie, ou l'on peut monter des fichiers sources (généralement sur disque réseau local) et définir des options de compilation pérennes. Le but étant d’avoir une espace de travail ou l’ont construit des projets dans la durée, qu’on peut faire évoluer dans un univers cross-plateforme, comme on peut le faire avec XCODE et VisualStudio par exemple.
Pour moi c’est le prérequis pour faire venir des légions de développeurs sur linux, et le fait que ce ne soit pas déjà fait, comme une priorité première, est un très mauvais signal. Ca veut dire qu’il n’y a personne qui comprend les besoin des développeurs d’applications…
Dans ce contexte, les débats sur la sécurisation de la mémoire ou l’implémentation d’autre langage que le C ou le C++ paraissent totalement hors sujet.
C'est bien le cas de Linux. Il est ou le prob. donc ?Le but étant d’avoir une espace de travail ou l’ont construit des projets dans la durée, qu’on peut faire évoluer dans un univers cross-plateforme
On a pas besoin de développeurs d'application dans ce cas de figure, mais de développeur noyau.Ca veut dire qu’il n’y a personne qui comprend les besoin des développeurs d’applications
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Cross platforme est vague. Si c’est pour pouvoir compiler pour Arduino ou STM32, on sait faire.
Si c’est pour des applications Desktop, on a quelques bibliothèques GUI transplateforme (Qt, Gtk, en particulier). J’ai déjà utilisé QtCreator pour faire une application sous Windows et la recompiler ensuite sur Linux. (Et en fait, l’application est essentiellement une adaptation d’une application faite sur MacOS). Aucun problème… D’ailleurs pour un projet multiplateforme, on a plus un problème de bibliothèque que d’IDE.
Et le nombre de CVE suffit à prouver que l’on a un problème avec le langage C… on peut invoquer des aspects théoriques (il est possible de faire du code sûr), mais en pratique les faits sont têtus.
pas avec Eclipse en tout cas, donc avec quel IDE ?
On a vu. et un noyau sans application, ca sert à rien.
Un noyau sans application ? Lequel ? On a déjà LibreOffice, et une multitude de logiciels libres qui tournent dessus. Voire des exclusivités : Je me rappelle, en 1995, mon ex utilisait mon PC sous Linux car il n’y avait que lui qui faisait tourner LyX… Côté application commerciale (en desktop), cela vient un peu : je m’intéresse au domaine musical, et il y a Reaper et Pianoteq qui sont disponibles. Je pense que si peu d’applications commerciales sont disponibles sur Linux, c’est que peu d’utilisateurs sont prêts à payer. (Choisir Linux est aussi un état d’esprit qui consiste à préférer des choses gratuites… Comme Gimp plutôt que Photoshop, LibreOffice plutôt que Microsoft Office, etc).
et en IDE qui sait gérer un projet de compilation genre VC6 ou Borland C++, y'a quoi ?
La question prend le problème par le mauvais bout. Pour faire un développement portable, on prend des outils portables… j’ai cité Qt et QtCreator (avec qmake derrière). Si tu n’aimes pas qmake, il y a Cmake qui est multiplateforme aussi.
Commencer à prendre du propriétaire puis se dire «*mince, comment porter ?*» ne marche pas très bien. (Mais il peut y avoir de bonne surprises : Lazarus peut convertir un projet Delphi… et il me semble que VC6 a une option Project/Convert to Makefile).
Répondre avec citation
Partager