Par exemple "Objets répartis avec Ada 95" est en français, et fait un // avec CORBA, ce qui facilite la compréhension, ou bien "Building Robust Distributed Sytem".
Sinon, le plus simple est de parcourir les exemples distribués avec.
Ada contient plus que deux choses intéressantes, heureusement :-)
Pour les génériques versus les templates de Java 1.5, no comment, je ne connait pas Java 1.5.
Imiter par une classe n'est pas forcément simple. Prend la basique déclaration d'un type float à point fixe définissant un pourcentage avec une précision mini de 1/1000 : tu écris type Percent is delta 0.001 range 0.0 .. 100.0;
En dehors des opérateurs habituels, tu devra écrire le code des attributs standard Small, Delta, Fore, Aft, Digits, Scale et Round. Ta classe ne va pas être triviale.
Ca se complique encore si on parle mapping mémoire. Si je décrit par exemple un registre avec un booleen en bit 1, un integer en bit 2 a 5 et un énuméré sur les bits 6 à 16, ce que je fais par une simple déclaration en Ada, ta classe devra en revanche contenir du code pour décaler les bits et récupérer les champs.
Je ne sais pas ce qu'est l'architecture de sécurité. Pour l'introspection et le chargement dynamique de classe, il est vrai que c'est utile. Mais Ada est un langage compilé, et dans ce domaine, la bataille n'est pas "fair" :-)
Je ne peux pas te montrer ici que les points fort d'Ada ne se limitent pas à deux choses, alors je vais choisir un exemple pour moi spectaculaire : l'annexe distribuée. Elle permet de distribuer une application normale sans en changer une ligne de source.
C'est à dire qu'a partir des même sources, je peux compiler une appli monolitique tournant sur une machine, ou répartie sur plusieurs machines avec différents OS et différents Byte ordering.
Sans changer les sources, et sans le moindre appel explicite à RPC ou autre middleware.
Je le rappelle, je parle d'un logiciel libre, dispo sur de nombreuses plateforme et que tu peux essayer tout de suite en faisant (par exemple) apt-get install gnat-glade :-)
Juste quelques questions et remarques, vu que ça fait bien longtemps que je n'ai pas programmé en Ada et donc que je ne connais pas bien la version 95. Pour la productivité, les programmes non buggués, etc. il y a aussi de nombreuses études qui montrent que Java explose C++ et C, et je t'avoue que je ne suis pas super convaincu. J'ai vu chez Thomson (oups Thales) de bons ingénieurs bosser en Ada et en C++, et franchement, ce qui faisait la différence avec les nazes, c'était plus les méthodes travails que le langage.
Que Java soit plus productif que C++, c'est normal, le langage est mieux conçu.
Qu'il vaille mieux avoir un bon avec visual C++ qu'un naz avec GNAT, je suis d'accord, c'est également mon expérience.
Mais pour comparer les langages, gardons tout égal par ailleur, sinon on va pas s'en sortir :-)
Je suis d'accord (à 98% :-) avec tout ce que tu dis, mais je te trouve un peu pessimiste sur la question de la dispersion.
La communauté du libre est tellement immense que peu importe si les initiatives sans lendemain foisonnent. Ce qui reste est énorme.
Par exemple, je ne suis pas sur que nos bureaux sous Linus seraient meilleurs si Kde, Gnome et GNUStep ne faisaient qu'un.
Juste pour info : dans quels domaines utilises-tu Ada (toi, personnellement - pas "en général") ? Est-ce que tu bosses dans une boite où on code en Ada, on fait plein d'applis avec qu'on vend à des client ?
:-)
J'utilise actuellement Ada 95 dans les communications tactiques militaires chez Thales. Je t'épargne le reste de mon CV, qui commence dans l'industrie, avec Ada, en 91.
T'es tellement ancré dans tes certitudes que tu ne crois pas un seul instant que je puisse être un gars sérieux et expérimenté qui parle en connaissance de cause. Il doit forcémment y avoir une faille...
Donc le langage ne sert à rien, dans l'état actuel des choses. Java ou C# feront bien mieux le boulot.
Le langage ne sert à rien parce que j'ai l'embarras du choix dans les libs?
Soyons sérieux!
Descend de ton petit nuage rose. Une lib standard maintenant, c'est au minimum un parseur xml (DOM et SAX) et html, http, ftp, une toolkit graphique, un framework pour faire de l'appel de méthode à distance (genre RMI/CORBA/SOAP etc...), la sérialisation de n'importe quel objet, la gestion de date/heure, etc... et ça pas en GPL parce que tout le monde ne fait pas du libre, merci.
... Sans compter l'existence d'outils genre IDE, framework de test unitaire et de profiling...
Tout cela existe en Ada, en lib ou dans le langage.
Oui, tout.
Je ne me lance pas dans l'énumération : comme tu aurais pu en avoir confirmation en 5 minutes avec google, je suppose que tu n'as que faire des réponses.
Java et C# on a ça en standard. Pour C++, y a Qt qui fait à peu près le boulot. Autrement : ton langage ne sert à rien à part pour certaines applis spécialisées.
Ben oui, mais Ada et quelques centaines d'autres langages ont ca aussi. Mais tu va bien réussir à éliminer deux ou trois obscurs dialectes avec ce genre de critère...
Bref, reviens nous voir quand il existera theadaserverside.com, et une version d'Intellij Idea pour Ada.
Je ne connais pas, mais c'est peux comme si je te disais reviens me voir quand tu auras des User defined assignement et des clauses de représentations : la moitié des lecteurs ne connaissent que de nom, alors ca fait sacrément avancer le débat!
C'est l'erreur d'appréciation habituelle de ceux qui ne connaissent pas Ada.
Pour prendre le dernier chiffre que j'ai vu passé, toute chose étant égales par ailleurs, un soft en Ada a en moyenne 4 fois moins de bug trouvé après livraison qu'un soft en C. Je passe sur les autres chiffres (dispo pour celui qui cherche un minimum), qui montre les gains spectaculaires en cout de developpement, de test et même de temps de localisation des bugs.
Cela ne s'explique pas par les simples défauts syntaxiques, et il ne s'agit pas d'une querelle des "{}" contre les "begin end". Ne te contente pas de survoler un pdf, essaye avec objectivité avant de juger.
Personnellement, je ne trouves pas "assez mineur" de devoir passer 4 fois plus de temps en tête à tête avec gdb.
L'argument de la lib standard est caduque, puisque le groupe Ada de l'ISO qui procède en ce moment à la seconde révision du langage, planche sur le sujet.
Il est vrai que la lib existante ne contient pas, par exemple, de structure de données. Il faut piocher dans les lib dispo en GPL, et il y l'embarras du choix, ce qui n'est pas un avantage. Mais note également que je peux te retourner l'argument, puisque Ada propose en standard des choses pour lesquelles il te faudra en Java piocher dans une lib extérieure.
Soyons positif : pour faciliter ton passage à Ada, et si c'est pour toi le plus important, c'est la... lib :-), il existe un strict équivalent de la STL en Ada et en GPL. Tu vois, tu n'as plus de raison d'hésiter, tu naviguera en terrain connu!
On ne peut pas comparer Ada et Perl ou Python, ce n'est pas la même vocation.
Ada n'est pas un langage de script, Ada est fait pour le génie logiciel. Son crénau, c'est pil poil des gros projet comme Apache ou le kernel Linux, écrit par des centaines de personnes, dont le code est relu des milliers de fois et pour lesquels il faut intégrer chaque jour des dizaines de patchs en limitant les effets de bord.
Ada permet de faire tout ce que tu fais en C/C++/Java, goretteries comprises. Il est donc au moins aussi souple.
Comme il permet également de faire des choses que les autres ne font pas, il est donc plus souples.
Tu peux pas faire plus caré, comme raisonnement!
Plus sérieusement, Ada te propose une sémantique de haut niveau que tu n'a pas en C++ ou en Java. Cela te permet de décrire dans le code des choses que les autres mettent dans les commentaires ou dans des doc, avec toutes les incohérences que cela entraine. En Ada, le source en dit tellement que beaucoup de commentaires sont évités. Et bien sur, le compilateur qui est ton meilleur ami vérifie pour toi.
Moi, je ne trouve pas qu'un outils puissant soit chiant. Ce que je trouve chiant c'est de galérer deux heures pour trouver un bug qui aurait été tout simplement impossible avec Ada.
Je rève! Ton argument, c'est que Java c'est moins bien que C ou C++ parce que plein de gros projets l'utilisent?
C'est un argument de mouton de Panurge 5ième Dan, ca!!
Tu te rends compte que tu parles d'un sur-assembleur des année soixante et d'un langage expérimental démoulé trop chaud et devenu universel à la surprise général? Je manque d'imagination, mais j'en ai assez pour envisager que leur utilisation dans tout un tas de projet est du à beaucoup d'autres facteurs que les qualité techniques.
Bon, j'arrète de faire l'avocat de Java (j'ai une réputation de sérieux à défendre :-) mais ton argument vaut zéro.
Exemple : je ne connais pas UN SEUL programme "sérieux" fait avec Eiffel, et pourtant, c'est un langage moderne, c'est à dire conçu avec une vrai préocupation de génie logiciel. C, C++ et Java font pâle figure à coté.
PS : en revanche, merci pour ce grand moment d'humour : la critique de Java sur la portabilité entre compilo et entre plateforme, suivit de l'apologie de C/C++, ca vaut 10/10!
Et puis si tu veux profiter des API Java, de la JVM et même de .NET, tu n'est pas obligé de te contenter d'un langage de second choix.
Il y a des compilateur Ada pour la cible JVM, des bindings aux API et même A#,
voir http://www.ada-france.org/article27.html.
Ne pas confondre langage et API/Framework/JVM/etc./etc.
J'espère que tu n'es pas assez naif pour croire que ce qui est plus récent est meilleur? Plus probablement tu parles sans savoir, et tu propages une des idées recue les plus commune mais également une des plus fausses.
Contrairement à ce que tu crois, à côté d'Ada, Java est un langage d'une pauvreté à faire pleurer.
Va lire http://libre.act-europe.fr/Software_Matters/03-C_pitfalls.pdf.
Lors de la prochaine allusion à Ada, t'aura l'air de connaitre ton sujet, au lieu d'avoir l'air d'un mouton de panurge.
| Le kernel de mandrake inclut le patch grsecurity, et la sécurisation se fait via
| msec, qui, par exemple, restorent les permissions, vérifient les logs etc.
Le patch grsecurity est d'ailleurs un vrai régal à appliquer et régler sur Debian.
Le site de grsecurity a des présentations très intéressantes sr le deal perfo/sécurité.
Quand aux autres outils, ils sont présent en abondance dans la Debian normal.
Pour s'en persuader, et puisque personne n'en à parlé, je donne l'URL indispensable pour accompagner cet article : http://www.debian.org/doc/manuals/securing-debian-howto/.(...)
Ne me remerciez pas, tout le plaisir a été pour moi :-)
MDR!
Et pourtant après le premier mail j'aurai parié pour un classique flame emacs/xemacs dans les trois mails qui suivaient!
Tout ca pour savoir si un emacs en mode texte dont tout le monde se fout est dispo dans truc ou dans machin. Ca fait belle lurette que même dans la pire brouette y a de quoi faire tourner 12 emacs sous X. En cas de pb de performances, il s'agit probablement d'autre chose.
Note que des choses intéressante sur l'utilisation de stable/unstable ont été dites (et je vois que tu résiste à participer au débat :), mais ce n'est clairement pas le troll... enfin je veux dire le sujet :-)
Donc, pour envenimmer le flame... pardon : pour recadrer le débat, est-ce que ce emacs avec Gtk est disponible en deb non-officiel quelque part?
Ta phrase commence raisonablement, mais derrière "ou autre" se cache un monde que tu ne sembles pas connaître. Ca n'a pas l'air de te géner pour lancer des phrases définitives.
Il n'est bien sur pas question de Perl.
Ada est un langage compilé. Ce qui fait la différence en terme de sécurité, c'est principalement la qualité de la conception du langage, et tout ce qu'il permet de vérifier à la compilation. Les (très utiles) checks ajouté à l'exécution peuvent être retirés par les options de compilation.
Dans ce cas, tu ne perd rien en performance, mais tu gardes le bénefice des vérifications à la compilation.
C'est probablement essentiellement la même chose pour Eiffel.
Mon trollomètre a frémis :-)
Tu veux savoir si j'imagine d'utiliser un langage qui me permet de développer en 40% moins de temps avec 10 fois moins de défaut trouvé après release?
Tu veux sérieusement que je réponde? :-)
Je parle pour ce que je connais, Ada. Va voir dans http://libre.act-europe.fr/Software_Matters/(...) l'étude Ziegler dans Programming Languages and Software Construction.
Maintenant si je dois développer un serveur SMTP from scratch sans Ada, et qu'on me prouve que Eiffel, Python ou le langage de la mére Denis présentent ne serais-ce qu'un quart de ces avantages, eh ben j'achète le Kernighan & Mère Denis et je m'y met.
Parce que le soir, je préfère passer 1 heure avec mes enfants qu'avec gdb.
Je sais, je sais, je ne suis décidement pas un vrai code warrior :-)
Ce n'est pas repousser le problème, c'est le traiter là ou tu peux.
Il n'y a évidemment pas de solution parfaite, et la faille peut-être dans les librairies appelées, mais tu aura 10 fois moins de problèmes de ce genre.
C'est autant de temps supplémentaire que tu passera sous emacs et non sous gdb. A moins d'être debbugo-dépendant, c'est quand même le but, non?
Effectivement, "buffer overflow" est devenu une news tellement banale...
Je ne sais pas ce que sont ProPolice et StackGuard, mais je pense que le plus simple est quand même de privilégier des applis utilisant un langage de programmation qui empèche ce genre de faille (quand elles existent!).
Le Secure Programming for Linux and Unix HOWTO (http://www.dwheeler.com/secure-programs(...)) a tout un chapitre sur ce sujet.
Après avoir longement parlé de C/C++ (et justement de ProPolice et StackGuard), il termine par :
The problem of buffer overflows is an excellent argument for using other programming languages such as Perl, Python, Java, and Ada95. After all, nearly all other programming languages used today (other than assembly language) protect against buffer overflows.
Je sais bien qu'on ne fait pas toujours ce que l'on veut (le site de mon assoc http://www.ada-france.org/(...) doit bien tourner sur une machine à 95% avec des programmes en C alors qu'il fait la promotion du langage Ada).
Mais bon, il faut quand même rappeller cette évidence de temps en temps, histoire que tout le monde soit conscient que le temps énorme que l'on perd sur ces stupidités est facile à éviter dés le début d'un projet.
Je confirme, je parlais bien des développements répartis sur plusieurs continents.
La programmation répartie est un sujet pasionnant, et très bient traité dans Ada 95, mais ca ne concerne qu'une petite partie des projets "libres".
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 2.
Il y a des références sur le site de Sam Tardieu : http://www.rfc1149.net/biblio(...)
(DSA est l'acronyme de Dystributed System Annex)
Par exemple "Objets répartis avec Ada 95" est en français, et fait un // avec CORBA, ce qui facilite la compréhension, ou bien "Building Robust Distributed Sytem".
Sinon, le plus simple est de parcourir les exemples distribués avec.
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 1.
Pour les génériques versus les templates de Java 1.5, no comment, je ne connait pas Java 1.5.
Pour le typage, il ne se réduit pas à la la simple contrainte de range. La richesse du typage Ada est inégalée. Il y a quelques exemples dans l'article Introducing Ada sur CodeMage : http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/Introducing(...)
et des comparaisons plus directe avec Java dans Multilanguage Programming on the JVM: The Ada 95 Benefits http://libre.act-europe.fr/Why_Ada/ada-on-jvm.pdf(...)
Imiter par une classe n'est pas forcément simple. Prend la basique déclaration d'un type float à point fixe définissant un pourcentage avec une précision mini de 1/1000 : tu écris
type Percent is delta 0.001 range 0.0 .. 100.0;
En dehors des opérateurs habituels, tu devra écrire le code des attributs standard Small, Delta, Fore, Aft, Digits, Scale et Round. Ta classe ne va pas être triviale.
Ca se complique encore si on parle mapping mémoire. Si je décrit par exemple un registre avec un booleen en bit 1, un integer en bit 2 a 5 et un énuméré sur les bits 6 à 16, ce que je fais par une simple déclaration en Ada, ta classe devra en revanche contenir du code pour décaler les bits et récupérer les champs.
Je ne sais pas ce qu'est l'architecture de sécurité. Pour l'introspection et le chargement dynamique de classe, il est vrai que c'est utile. Mais Ada est un langage compilé, et dans ce domaine, la bataille n'est pas "fair" :-)
Je ne peux pas te montrer ici que les points fort d'Ada ne se limitent pas à deux choses, alors je vais choisir un exemple pour moi spectaculaire : l'annexe distribuée. Elle permet de distribuer une application normale sans en changer une ligne de source.
C'est à dire qu'a partir des même sources, je peux compiler une appli monolitique tournant sur une machine, ou répartie sur plusieurs machines avec différents OS et différents Byte ordering.
Sans changer les sources, et sans le moindre appel explicite à RPC ou autre middleware.
Je le rappelle, je parle d'un logiciel libre, dispo sur de nombreuses plateforme et que tu peux essayer tout de suite en faisant (par exemple) apt-get install gnat-glade :-)
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 1.
Juste quelques questions et remarques, vu que ça fait bien longtemps que je n'ai pas programmé en Ada et donc que je ne connais pas bien la version 95. Pour la productivité, les programmes non buggués, etc. il y a aussi de nombreuses études qui montrent que Java explose C++ et C, et je t'avoue que je ne suis pas super convaincu. J'ai vu chez Thomson (oups Thales) de bons ingénieurs bosser en Ada et en C++, et franchement, ce qui faisait la différence avec les nazes, c'était plus les méthodes travails que le langage.
Que Java soit plus productif que C++, c'est normal, le langage est mieux conçu.
Qu'il vaille mieux avoir un bon avec visual C++ qu'un naz avec GNAT, je suis d'accord, c'est également mon expérience.
Mais pour comparer les langages, gardons tout égal par ailleur, sinon on va pas s'en sortir :-)
[^] # Re: Mono 0.24
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 2.
La communauté du libre est tellement immense que peu importe si les initiatives sans lendemain foisonnent. Ce qui reste est énorme.
Par exemple, je ne suis pas sur que nos bureaux sous Linus seraient meilleurs si Kde, Gnome et GNUStep ne faisaient qu'un.
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 1.
Juste pour être clair, je ne voulais pas troller Eiffel qui est pour moi un des bons élèves de la classe.
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 3.
:-)
J'utilise actuellement Ada 95 dans les communications tactiques militaires chez Thales. Je t'épargne le reste de mon CV, qui commence dans l'industrie, avec Ada, en 91.
T'es tellement ancré dans tes certitudes que tu ne crois pas un seul instant que je puisse être un gars sérieux et expérimenté qui parle en connaissance de cause. Il doit forcémment y avoir une faille...
Donc le langage ne sert à rien, dans l'état actuel des choses. Java ou C# feront bien mieux le boulot.
Le langage ne sert à rien parce que j'ai l'embarras du choix dans les libs?
Soyons sérieux!
Descend de ton petit nuage rose. Une lib standard maintenant, c'est au minimum un parseur xml (DOM et SAX) et html, http, ftp, une toolkit graphique, un framework pour faire de l'appel de méthode à distance (genre RMI/CORBA/SOAP etc...), la sérialisation de n'importe quel objet, la gestion de date/heure, etc... et ça pas en GPL parce que tout le monde ne fait pas du libre, merci.
...
Sans compter l'existence d'outils genre IDE, framework de test unitaire et de profiling...
Tout cela existe en Ada, en lib ou dans le langage.
Oui, tout.
Je ne me lance pas dans l'énumération : comme tu aurais pu en avoir confirmation en 5 minutes avec google, je suppose que tu n'as que faire des réponses.
Java et C# on a ça en standard. Pour C++, y a Qt qui fait à peu près le boulot. Autrement : ton langage ne sert à rien à part pour certaines applis spécialisées.
Ben oui, mais Ada et quelques centaines d'autres langages ont ca aussi. Mais tu va bien réussir à éliminer deux ou trois obscurs dialectes avec ce genre de critère...
Bref, reviens nous voir quand il existera theadaserverside.com, et une version d'Intellij Idea pour Ada.
Je ne connais pas, mais c'est peux comme si je te disais reviens me voir quand tu auras des User defined assignement et des clauses de représentations : la moitié des lecteurs ne connaissent que de nom, alors ca fait sacrément avancer le débat!
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 2.
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 3.
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 2.
[^] # Re: promouvoir Ada plutôt que Java ou C# :-)
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 1.
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 3.
[^] # Re: Trusted Debian 1.0
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Trusted Debian 1.0. Évalué à 3.
| msec, qui, par exemple, restorent les permissions, vérifient les logs etc.
Le patch grsecurity est d'ailleurs un vrai régal à appliquer et régler sur Debian.
Le site de grsecurity a des présentations très intéressantes sr le deal perfo/sécurité.
Quand aux autres outils, ils sont présent en abondance dans la Debian normal.
Pour s'en persuader, et puisque personne n'en à parlé, je donne l'URL indispensable pour accompagner cet article : http://www.debian.org/doc/manuals/securing-debian-howto/.(...)
Ne me remerciez pas, tout le plaisir a été pour moi :-)
[^] # Re: Parfait !
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Sortie de GNU Emacs 21.3. Évalué à 8.
Et pourtant après le premier mail j'aurai parié pour un classique flame emacs/xemacs dans les trois mails qui suivaient!
Tout ca pour savoir si un emacs en mode texte dont tout le monde se fout est dispo dans truc ou dans machin. Ca fait belle lurette que même dans la pire brouette y a de quoi faire tourner 12 emacs sous X. En cas de pb de performances, il s'agit probablement d'autre chose.
Note que des choses intéressante sur l'utilisation de stable/unstable ont été dites (et je vois que tu résiste à participer au débat :), mais ce n'est clairement pas le troll... enfin je veux dire le sujet :-)
Donc, pour envenimmer le flame... pardon : pour recadrer le débat, est-ce que ce emacs avec Gtk est disponible en deb non-officiel quelque part?
Même pour unstable :-)
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 1.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 2.
Il n'est bien sur pas question de Perl.
Ada est un langage compilé. Ce qui fait la différence en terme de sécurité, c'est principalement la qualité de la conception du langage, et tout ce qu'il permet de vérifier à la compilation. Les (très utiles) checks ajouté à l'exécution peuvent être retirés par les options de compilation.
Dans ce cas, tu ne perd rien en performance, mais tu gardes le bénefice des vérifications à la compilation.
C'est probablement essentiellement la même chose pour Eiffel.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 7.
Tu veux savoir si j'imagine d'utiliser un langage qui me permet de développer en 40% moins de temps avec 10 fois moins de défaut trouvé après release?
Tu veux sérieusement que je réponde? :-)
Je parle pour ce que je connais, Ada. Va voir dans http://libre.act-europe.fr/Software_Matters/(...) l'étude Ziegler dans Programming Languages and Software Construction.
Maintenant si je dois développer un serveur SMTP from scratch sans Ada, et qu'on me prouve que Eiffel, Python ou le langage de la mére Denis présentent ne serais-ce qu'un quart de ces avantages, eh ben j'achète le Kernighan & Mère Denis et je m'y met.
Parce que le soir, je préfère passer 1 heure avec mes enfants qu'avec gdb.
Je sais, je sais, je ne suis décidement pas un vrai code warrior :-)
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 1.
Il n'y a évidemment pas de solution parfaite, et la faille peut-être dans les librairies appelées, mais tu aura 10 fois moins de problèmes de ce genre.
C'est autant de temps supplémentaire que tu passera sous emacs et non sous gdb. A moins d'être debbugo-dépendant, c'est quand même le but, non?
# Re: Faille de sécurité importante dans Sendmail
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 5.
Je ne sais pas ce que sont ProPolice et StackGuard, mais je pense que le plus simple est quand même de privilégier des applis utilisant un langage de programmation qui empèche ce genre de faille (quand elles existent!).
Le Secure Programming for Linux and Unix HOWTO (http://www.dwheeler.com/secure-programs(...)) a tout un chapitre sur ce sujet.
Après avoir longement parlé de C/C++ (et justement de ProPolice et StackGuard), il termine par :
The problem of buffer overflows is an excellent argument for using other programming languages such as Perl, Python, Java, and Ada95. After all, nearly all other programming languages used today (other than assembly language) protect against buffer overflows.
Je sais bien qu'on ne fait pas toujours ce que l'on veut (le site de mon assoc http://www.ada-france.org/(...) doit bien tourner sur une machine à 95% avec des programmes en C alors qu'il fait la promotion du langage Ada).
Mais bon, il faut quand même rappeller cette évidence de temps en temps, histoire que tout le monde soit conscient que le temps énorme que l'on perd sur ces stupidités est facile à éviter dés le début d'un projet.
Lionel
[^] # Re: Non, il n'y a pas de troll dans la news !
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Conclusion du premier concours logiciel libre d'Ada-France. Évalué à 1.
La programmation répartie est un sujet pasionnant, et très bient traité dans Ada 95, mais ca ne concerne qu'une petite partie des projets "libres".
Je profite de cette réponse pour ajouter une petite référence au "Big Online Book of Linux Ada Programming" :
http://www.vaxxine.com/pegasoft/homes/book.html(...)
A connaitre!