Gaël Le Mignot a écrit 812 commentaires

Bien sur il y a des bugs et il y (ou il y aura) des trous de sécurité trouvés dans ces serveurs, mais aucun ne permet de récupérer un shell en root.

Euh... tu me trouves un admin qui fait tourner Apache en root ? C'est vraiment pas prudent du tout ça...

Et avec un OS bien conçu (suivez mon regard) même un sshd, un telnetd ou autre ftpd n'a pas besoin des droits root (ni même d'aucun droit). La sécurité c'est d'abord dans le design général du système qu'elle se fait, pas dans le choix du langage.

Pour les machines virtuelles java, la spec impose une phase de vérification des bytecodes qui vérifie que le compilo n'a pas fait n'importe quoi (hauteur de pile en entrée et à la sortie des méthodes, et pas mal d'autres choses).

Oui, je sais, mais ça ça sert plus pour les applets ou autre (quand on exécute sur sa machine du code provenant de l'extérieur) pas pour ce qui est serveur (quand tu exécutes du code en qui tu as confiance).

Euh... le segfault ça n'a rien à voir avec les exceptions... c'est intercepter le signal SIGSEGV (11) avec sigaction(2) qu'il faut faire pour récupérer ça, les exceptions ne serviront à rien là dessus...

Sinon, parler de 'segment' mémoire c'est un peu abusif puisque Linux n'utilise que la pagination, pas la segmentation.

Pour Zope et pour Caudium, ils sont tous les deux codés en C _et_ en un langage de script, avec un coeur en C et les extensions dans un langage de script (Python et Pike respectivement), ce qui est un choix raisonable (d'ailleurs avec Apache des extensions peuvent être écrites en Perl et je n'ai rien contre).

Pour http://e-docs.bea.com/(...) je ne connais pas, mais j'aimerais bien voir leurs perfs et leur tenue de charge...

Eh, mais arrète ton obsession !
Tu crois qu'il n'y a qu'en C qu'il y a des bugs ? Tu crois qu'en Java, en Caml, en Ada, en Python ou en VB y'en a pas des bugs ?!

Programmer en C, de manière sure, c'est parfaitement faisable il faut juste avoir un peu de méthode et faire gaffe à ce qu'on fait. Bien sûr quand on code on fait parfois des erreurs, mais c'est pareil dans _tous_ les langages.

C'est pas le langage qui fait un bon ou un mauvais programme, mais l'architecture globale du soft (le design) et les programmeurs (leur compétence, leur maîtrise du langage et le soin qu'ils ont mis à coder ce programme là). Et pour ça, le C n'est pas du tout un mauvais langage, parce qu'il peut assez facilement être _complêtement_ maîtrisé.

Alors cesse de crier contre le C à chaque trou de sécu d'un programme écrit en C. Regarde dans le monde MS, et tu verras que le C++ c'est pire. Enfin, non, c'est pas le C++ mais le logiciel propriétaire. Et pour les autres langages (Java, Caml, ...) ils ne sont pas viables pour un projet aussi critique niveau perf qu'un serveur Web.

> En allant par là, tu as oublié que tout le monde n'utilisais pas la glibc

Tu utilises quoi comme libc toi ? Tu proposes quoi comme alternative réelle à la GNU Lib C pour le noyau Linux ?

> ni forcément bash

Comme shell utilisateur, non, comme shell de script sur un noyau Linux, je ne vois pas trop qui utilise autre chose

> Au passage, concernant les passerelles, il est quand même assez fréquent d'éviter la (lourde) glibc.

Pour mettre quoi ? Lourde en quoi ?

Un peu d'arguments concrets STP

> +XFree+Samba+Apache(+libc5 ?)+...

Ma gate n'a ni XFree, ni Samba, ni Apache. Le serveur Web de prologin.org n'a pas XFree ni Samba, mais a Apache. Mon laptop aura XFree mais ni Samba ni Apache. Ma main box a XFree, Samba et Apache. Etc...

C'est là toute la différence. Que tu installes une Debian, une Slackware, une Mandrake, une RedHat ou une LFS, que ce soit sur une gate, un serveur Web, ou un poste de travail, tu as toujours le noyau Linux et les outils GNU, parce que sans ça tu ne peux rien faire.

C'est ce que l'on appelle le système d'exploitation: l'ensemble des composants qui permettent aux programmes utilisateurs de fonctionner. Et ce système, ce qui est commun partout et sans qui rien ne fonctionne, est composé du noyau Linux et programmes GNU, d'où le nom correct et juste: GNU/Linux.

Parce que vous confondez OS et distribution. Une distribution c'est un OS _plus_ des applications.

Debian GNU/Linux, Mandrake, ... c'est l'OS GNU/Linux avec des applications par dessus. Xfree, Apache, ... ne font pas partie de l'OS.

Sauf que tes composants non-GNU ils changent d'une machine à l'autre, et ce sont des applications, pas des composants du système.

> Il faut tout bonnement arrêter de faire de la politique sur Linux, Le logiciel libre _est_ politique par essence. Ou plutôt, éthique, philosophique et idéologique. C'est justement la notion de _liberté_, les notions de partage de la connaissance et du savoir (notions qui viennent tout droit des philosophes des Lumières par exemple) qui sont à l'origine du logiciel libre et qui motivent un grand nombre de programmeurs.

> Sous prétexe que Linus ait utilisé un soft sous licence GNU pour compiler linux et après que tous les softs soit GNU aussi ne fait pas le GNU. Encore un qui confond OS et noyau. Linux est un _noyau_. Un noyau tout seul ça ne fait rien. Le système d'exploitation, c'est GNU/Linux, c'est à dire le noyau Linux + la libc GNU + le linker GNU + le shell GNU (utilisé pour tous les scripts de démarrage) + les outils GNU + ... Donc c'est bien un système GNU, dans lequel un composant a été remplacé par Linux. D'où GNU/Linux. C'est pas compliqué pourtant !

> Windows est effectivement un OS au top niveau

dis, je peux l'encadrer ? ou au moins le rajouter parmi les fortunes... s'il te plait...

mwarf qu'est-ce qu'on se marre :)

-1

> TOUTE l'industrie du software est d'accord la dessus.

parce que si l'industrie le fait c'est qu'elle a raison ? si on a plus de x86 c'est que x86 c'est mieux, si on a plus de windows c'est que windows c'est mieux ?

Pour Mozilla, si c'est en C++ c'est qu'ils se sont basé au départ sur du code de Netscape qui était en C++.

Pour le reste, je me demande vraiment qui manque d'objectivité...

-1 (débat de sourd entre un "connard susceptible borné qui fait chier" (d'après la tribune) et un employé de chez MS qui se contente de faire des éloges infondées sur sa boite)

Bien évidemment je parle du cas où l'objet est de la classe fille, par exemple la classe mère a une méthode apply() qui prend un pointeur sur une méthode et fait des trucs avec, et une méthode de la classe fille veut appeler apply() avec l'une de ses méthodes à elle en paramètre.

Pour le reste, bon, entre les attaques personelles et l'éloge d'une société qui produit AMHA les pires softs ayant jamais existé, surtout d'un point de vue de la sécu (win 9x, IIS, Outlook, IE, ...), il n'y a _rien_

Je suis étudiant donc mon avis ne compte pas et j'ai forcément tord ? Et ben bravo...

décidément... ça devient n'importe quoi ici :(

J'ai parlé de _méthodes_ pas de _fonctions_

-1

> Pour l'instant tu donnes plutôt l'impression de quelqu'un qui fait du C++ sans savoir bien s'en servir.

STP, évite de juger les gens que tu ne connais pas, merci, et c'est valable dans le cas général, pas seulement ici.

-1 car HS

Je passe sur la première partie qui tient plus des attaques personnelles et le diffamation que de l'argumentation.

Je ne jamais dit que les templates étaient plus crades que des #define, mais qu'au niveau des concepts c'est la même chose, et que c'est beaucoup moins lisible qu'un vrai code générique comme on le fait en C.

Ensuite, non, tu ne peux pas utiliser les méchanismes du C (pointeurs et pointeurs de fonction) lorsque tu utilises les méchanismes du C++, cf ce que j'ai dit ailleurs, ça ne marche pas, tu buttes sans arrêt sur les limites que le compilo est obligé de te mettre...

Maintenant, peut-être quoi ça te convient mieux pour je ne sais quelles raisons, mais pour faire du C++ au taf 40h/semaine, je peux t'assurer que tous les jours ou presque je butte sur des trucs qui seraient beaucoup simple à faire de manière élégante en C...

Quand à ce que tu fais à ton boulot, quoi on voit le résultat, bon, sans commentaires ;)

> J'appelle pas ca de la programmation mais un hack douteux.

Tu appelles ça comme tu veux...

> Quand a passer un pointeur sur la methode d'une surclasse je vois pas ou est le probleme:

C'est tout l'inverse que je disais moi... passer à une méthode de CHello un pointeur sur une méthode fournie par CHelloWorld, sans que CHello ne connaisse même l'existence de CHelloWorld.

> GTK+ c'est pas très joli et libre

oulàlà, ton troll, il est vraiment pas joli non plus.

[-1]

Complètement faux, essaie de passer une méthode "char *foo(char *)" là où le compilo attend une méthode "void (*)(void *)" et ça ne marchera jamais, essaie de passer un pointeur sur une attribut ou une méthode d'une surclasse à une méthode d'une sous-clase, ...

Ce sont des trucs qui sont rendus impossibles car ils rentrent en conflit avec les méchanismes objets _très_ limités du C++.

Quand au code aussi optimisé, je l'ai expliqué des dizaines de fois, c'est complètement faux aussi, ou en tous cas avec les compilateurs que j'ai pu tester.

Sauf que quand on parle d'open source, on fait référence à http://opensource.org/docs/definition.php(...) en général, pas juste au "source ouvert", et surtout en français quand tu utilises le terme anglais, c'est bien parce que tu veux parler de l'Open Source défini par l'OSI et non le nom commun "source ouvert".

Maintenant, si tu ne penses qu'à la qualité du soft et pas du tout aux aspects éthiques qui sont soulevés, c'est AMHA que tu n'as rien compris à la raison d'être du logiciel libre.

Non, les méthodes virtuelles sont _très loin_ de permettre tout ce que permettent les pointeurs de fonction, mais alors très loin.

Et c'est justement parce que le compilo fait des trucs d'une manière et que moi j'aimerais bien les faire d'une autre...

Quand au code illisible, les templates c'est assez fort dans ce genre là

T'as oublié le -1, et oui, c'est n'importe quoi, tu vas me dire aussi qu'on a pas de threads en C ou en C++ parce qu'il n'y en a pas dans l'API standard du langage ? Ben oui, c'est du même niveau ce que vous me dites là...

Avoir des fonctionalités comme les tables de hachage, les listes chainées, ... dans une lib externe au lieu de les avoir dans le langage lui-même, c'est beaucoup mieux, ne serait-ce que parce que si tu veux développer dans un environement minimum (comme pour faire de l'embarqué), tu peux; que si tu veux utiliser une autre implémentation c'est bcp plus simple, ...

> - templates --> bouffe un peu plus de place car specifique a chaque type de donnee mais le code est optimal pour ton type de donnee

bouffe _beaucoup_ plus de place, avec des conséquences sur la vitesse d'exécution (cache, TLB, ...) et surtout les autres limitations dont j'ai parlé (absence de compilation séparée, ...)

> En C, le truc identique aux templates, ca n'existe pas, faut tout te degotter a la main

Si, ça fait avec des #define, c'est pas joli joli, mais ça revient exactement au même que les templates, c'est le même niveau de saleté (du code dupliqué lors de la compilation)

T'as rien compris à mon message, j'ai pas dit que je réécrivais l'algo, mais qu'avec les templates le compilo générait le code à chaque fois que l'algo est appelé justement au lieu de l'avoir une fois pour toute dans une lib.