Je ne veux pas dire, mais critiquer OpenSSL ok... le code n'est pas top, l'API crade et la doc presque inexistante. Par contre oser vanter les qualités de GnuTLS par rapport à OpenSSL... c'est l'hôpital qui se fou de la charité. Parce que franchement... il n'y a pas beaucoup plus immonde que GnuTLS.
Ah ben non en fait, ils ne sont coupables que d'ignorance
Ouhla, de mieux en mieux. L'ignorance est une excuse pour raconter n'importe quoi dans une news.
et de ne pas avoir épluché tous les forums pendants des heures gratos pour que môssieur soit satisfait.
Si pour toi c'est trop demander que la personne qui propose une news lise à minima les références qu'elle fourni... Je pense effectivement pouvoir venir t'expliquer ce qu'est le respect.
Le manque de respect c'est d'oublier que les modérateurs sont bénévoles et n'ont pas de compte à te rendre.
Haha je m'y attendais à celle là. Le fameux bénévolat des modérateurs.
Et toi, y penses-tu aux bénévoles d'OpenBSD qui contribuent du temps et de l'argent pour en faire ce qu'il est aujourd'hui ? Tu penses à quel point ce type de news leur manque de respect à ces *bénévoles* ?
Il faudrait savoir... Soit tu me reproches de ne pas lire une news... soit tu me reproches de la lire. Que faire dans ces conditions mon cher patrick_g ?
Je vais me répéter... mais se prétendre un site d'information relativement technique dans le monde des logiciels libres et publier ça... WAW !
Pour être franc, rien que le fait que les modérateurs ne se soient pas urinés dessus en lisant la news m'atterre...
Ma 1ere réaction en lisant ton message a été "Moouaaaaarff", parce que le fait qu'un mec a peut être, éventuellement, mais y faut voir on est pas sur,
Tu as lu les *faits* ? Il n'y a absolument AUCUNE preuve de quoi que ce soit.
introduit une backdoor dans OpenBSB comme "sujet aussi sensible" on fait mieux.
Le problème (et si tu avais lu les liens donnés dans la news tu l'aurais su) c'est que si la rumeur était vraie, elle ne concernerait pas seulement OpenBSD mais *tous* les systèmes BSD et des dizaines d'équipementiers de produits de réseau, de sécurité, etc.
Donc oui, je ne sais pas ce qu'il te faut de plus... mais c'est sensible.
"Une news aussi polémique" : j'aimerais savoir en quoi cette news est polémique ?
Je t'invite à lire le tout premier commentaire.
En ce qui concerne la modération, les modo ont fait leur boulot, ils ont estimé que la news était publiable, ils l'ont donc publié.
C'est là le problème. Ce site se dit un minimum technique. Et concentrer dans une seule dépêche autant d'inexactitudes et de raccourcis, c'est surréaliste. Même les sites généralistes ont été plus factuels.
D'ailleurs au passage, vu le nombre de sites généralistes ayant relayé cette information, encore une preuve (s'il était besoin d'en faire) que le sujet est sensible.
Dans le cas présent c'est justement le fait d'avoir lu qui m'a fait gueuler. La NdM initiale ne corrigeant absolument rien aux calomnies que contient cette dépêche.
La deuxième NdM rectifie la news, mais pardonne moi l'expression de saison... cette dépêche est maintenant un vrai sapin de noël.
Je pense surtout qu'un site comme celui-ci, qui est considéré par du monde comme une référence et qui propose dans une dépêche de telles calomnies sur un projet, c'est ça, le manque de respect !
Que les modérateurs n'aient pas l'obligeance de passer deux minutes avant de vérifier ce qui peut se lire instantanément dans les sources... surtout pour une news aussi polémique sur des sujets aussi sensibles... c'est ça, le manque de respect !
Ici le manque de respect, il vient de ce site... envers les lecteurs, et le projet en question.
Euh... le framework crypto d'OpenBSD ainsi que des parties de la stack IPsec ont été repris par les autres BSD. Comment est-ce que les éventuelles backdoor, ou tout du moins les problèmes trouvés récemment pourraient ne pas se retrouver chez les autres ?!?
D'ailleurs, un certain nombre ont été corrigés dans OpenBSD, mais ne le sont toujours pas chez les autres. Je pense notamment aux drivers pour tirer parti des accélérateurs crypto matériels.
Comme à l'accoutumée sur Trollfr, encore un torchon inexact et bourré de raccourcis.
Rappelons qu'à l'époque ce système d'exploitation était celui des 13 serveurs DNS racine.
Là je me dis... O M G. Mais comment prendre le reste de ce billet au sérieux après ça... A quel endroit as-tu lu une telle débilité ?
En raison de l'expiration du délai de la clause de confidentialité signée avec le FBI, c'est Gregory Perry, un ancien contributeur du projet de cryptographie d'OpenBSD qui nous révèle ça.
Vous avez au moins *lu* les mails de Theo de Raadt ? Ce mec (Gregory Perry) n'a jamais fait partie du projet, de près ou de loin !
Le but était de surveiller la circulation de données chiffrées, en insérant du code malicieux dans la pile réseau IPSEC d'OpenBSD.
Le but *aurait* été. Il n'existe aujourd'hui aucune preuve qu'il y ait eu volontairement la moindre vulnérabilité.
Et puis on parle d'OpenBSD... Tu t'es au moins un minimum renseigné où était également utilisé ce code ? TOUS les autres BSD utilisent le framework crypto d'OpenBSD ainsi que de très nombreux produits commerciaux. D'ailleurs depuis près d'une semaine, des problèmes (trouvés après l'audit, sans lien apparent avec le FBI) ont été corrigés dans OpenBSD mais ne le sont toujours pas chez les autres BSD.
Je sais mais j'ai jamais essayé de peur de tout peter, si le prog a était compilé avec une libc qui a un numéro différent du mien ça va pas tout peter ?
Je n'ai jamais eu de souci. J'essaie toujours d'avoir un système de base supérieur ou égal en date à mes packages. Et dieu sait que je le fais souvent (toutes les semaines).
Heu les packages précompilés demandent des versions particulières de la libc, si tu n'as pas (encore) compilé cette version, l'install ne passe pas.
C'est pour cela que les options pour forcer l'update existent. Perso j'update tous mes packages avec : pkg_add -u -F libdepends -F update -F alwaysupdate -F updatedepends
Et comme je le disais, quand tu suis les logs du CVS ou la faq et qu'il y a des changements aux libs, tu t'arranges pour compiler le système avant de mettre à jour les ports en suivant les recommandations et ça passe. Comme je te dis, ça fait 3 ans que je fais cela... aucun souci.
En compilant mes ports moi-même j'évite de devoir recompiler le userland fréquemment (c'est long) et je limite le downtime.
La je comprends pas tout... tu préfères utiliser les ports, mais tu trouves long de compiler le userland ?!? Tu ne dois pas avoir beaucoup de ports alors. La machine en question est un serveur ? Si de toute manière tu dois recompiler un kernel pour raidframe, tu dois aussi compiler le userland pour ce kernel et je vois pas le problème...
Ça fait environ 3 ans que je tourne en -current (kernel+userland compilé par moi), et je n'utilise QUE les packages pré-compilés (snapshots). Je me suis monté un mirroir ftp sur une machine en local pour que les update aillent plus vite et ça marche du feu de dieu.
Il n'y a absolument aucun problème à compiler toi même ton kernel+userland (même si c'est un kernel avec raidframe) et d'utiliser les packages des snapshots. Tout se passe bien quand on suit les logs du CVS ou la faq : http://www.openbsd.org/faq/current.html
Après oui, c'est pas supporté... mais si tu suis -current, tu le sais déjà ;).
Non. Dans GCC 4.1 c'est un "ProPolice réécrit" apportant fonctionnellement les mêmes choses que ProPolice mais ce n'est pas ProPolice (au sens de celui écrit par Hiroaki Etoh d'IBM).
Au moment où le patch pour FreeBSD est apparu c'était une autre version de GCC qu'ils utilisaient, d'où le besoin du patch. Par contre si tu regardes le commentaire dans le lien fourni plus haut :
CURRENT: FreeBSD-CURRENT now has GCC-4.2 where ProPolice/SSP is provided by default. This patch is thus no longer needed.
Les développeurs des BSD et particulièrement d'OpenBSD qui ont été les premiers à intégrer par défaut ProPolice, n'aiment pas le système équivalent de GCC. Marc Espie disait à ce propos en 2005 :
Instead, GCC 4.0 will ship with a framework called mudflap, which does about as much as "flap, flap, flap" flying through code. It catches one valid bound violation every April the 1st, and complains about valid code every other day of the year.
Quand quelqu'un achète une voiture, c'est pour l'utiliser régulièrement, avoir des fonctionnalités, comme la clim, l'auto radio CD, sièges chauffants, etc. qui apportent vraiment à l'utilisation et au confort.
Un installateur, mis à part à l'installation de ton système, c'est à dire peut-être 15min une fois par an et encore... tu ne l'utilises jamais. C'est pour cela qu'il doit être simple, aller à l'essentiel et faire ce qu'on lui demande, pas plus.
Ajoutons à cela que Slackware ne vise en aucun cas la même catégorie d'utilisateurs que les autres distributions...
Si tu veux vraiment comparer les installateurs à des voitures, compare les à des véhicules utilitaires qui sont dénués de tout superflu, pas à des voitures de tous les jours pour monsieur tout le monde.
Personnellement ça m'énerverai de constater que mon binaire x86 est tout lent parce qu'il a été généré par un compilo rapide de façon à être compatible VAX....
Ce que tu dis montre clairement que tu n'es pas développeur et que tes remarques sont sans aucun fondement.
Pour toi un compilateur rapide produit du mauvais code ? C'est faux... PCC produit du bon code avec seulement très peu d'optimisations...
Pour toi un bon binaire i386 voudrait dire un binaire vax lent et vice versa ? C'est complètement incohérent.
Tu penses qu'il y a beaucoup de versions d'OpenBSD qui tournent actuellement sur du VAX dans le monde ?
Non je ne le pense pas... par contre ce dont je suis sûr c'est que le fait de maintenir des archis lentes et complètement dépassées depuis des lustres comme le vax permet à OpenBSD de régulièrement découvrir des bugs qui ne seraient jamais remontés sur des plateformes rapides.
Qui a dit que PCC était prêt ? Tout le monde sait qu'il n'en est qu'au commencement et que la route sera très longue... Je te rappel au passage le titre de la dépêche :
cross-compilation pour les machines peu puissantes
Je te rappel que dans le post original, Etienne parlait du besoin de compiler rapidement. Tu considères que la vitesse d'un compilateur, c'est être capable de cross-compiler sur des machines puissantes quand sur l'archi cible c'est trop lent ?
Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).
J'ai chez moi une vieille Sun SparcClassic, qui met environ une semaine pour compiler le système complet. Je ne parle même pas de mon VAX... Si tu étais développeur, tu comprendrais que passer d'un compilo qui met une semaine pour compiler un OS à un autre qui met 5 fois moins de temps, c'est un TRES GROS avantage.
Et puis quant à la portabilité, gcc l'est oui, mais c'est en comptant sur le fait qu'il soit catastrophique sur les archis autres que i386/amd64/PPC. Tu as déjà comparé gcc à sun studio sur sparc ? Tu as déjà comparé gcc à mipspro sur mips ? Si c'était le cas, tu verrais que gcc est très loin d'être ce petit bijou que tu crois être...
# GnuTLS vs OpenSSL... mouais
Posté par vosgien_ . En réponse à la dépêche GnuTLS ajoute le support de DTLS. Évalué à 3.
Je ne veux pas dire, mais critiquer OpenSSL ok... le code n'est pas top, l'API crade et la doc presque inexistante. Par contre oser vanter les qualités de GnuTLS par rapport à OpenSSL... c'est l'hôpital qui se fou de la charité. Parce que franchement... il n'y a pas beaucoup plus immonde que GnuTLS.
Un petit article très intéressant ici.
[^] # Re: Mais qui valide la publication de ces torchons ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à -3.
[^] # Re: Mais qui valide la publication de ces torchons ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à 0.
[^] # Re: Mais qui valide la publication de ces torchons ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à -4.
[^] # Re: Mais qui valide la publication de ces torchons ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à -1.
Ouhla, de mieux en mieux. L'ignorance est une excuse pour raconter n'importe quoi dans une news.
et de ne pas avoir épluché tous les forums pendants des heures gratos pour que môssieur soit satisfait.
Si pour toi c'est trop demander que la personne qui propose une news lise à minima les références qu'elle fourni... Je pense effectivement pouvoir venir t'expliquer ce qu'est le respect.
[^] # Re: Mais qui valide la publication de ces torchons ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à -1.
Haha je m'y attendais à celle là. Le fameux bénévolat des modérateurs.
Et toi, y penses-tu aux bénévoles d'OpenBSD qui contribuent du temps et de l'argent pour en faire ce qu'il est aujourd'hui ? Tu penses à quel point ce type de news leur manque de respect à ces *bénévoles* ?
Visiblement non.
[^] # Re: Information vraie ou fausse ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à -9.
Il faudrait savoir... Soit tu me reproches de ne pas lire une news... soit tu me reproches de la lire. Que faire dans ces conditions mon cher patrick_g ?
Je vais me répéter... mais se prétendre un site d'information relativement technique dans le monde des logiciels libres et publier ça... WAW !
Pour être franc, rien que le fait que les modérateurs ne se soient pas urinés dessus en lisant la news m'atterre...
[^] # Re: Mais qui valide la publication de ces torchons ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à 2.
Tu as lu les *faits* ? Il n'y a absolument AUCUNE preuve de quoi que ce soit.
introduit une backdoor dans OpenBSB comme "sujet aussi sensible" on fait mieux.
Le problème (et si tu avais lu les liens donnés dans la news tu l'aurais su) c'est que si la rumeur était vraie, elle ne concernerait pas seulement OpenBSD mais *tous* les systèmes BSD et des dizaines d'équipementiers de produits de réseau, de sécurité, etc.
Donc oui, je ne sais pas ce qu'il te faut de plus... mais c'est sensible.
"Une news aussi polémique" : j'aimerais savoir en quoi cette news est polémique ?
Je t'invite à lire le tout premier commentaire.
En ce qui concerne la modération, les modo ont fait leur boulot, ils ont estimé que la news était publiable, ils l'ont donc publié.
C'est là le problème. Ce site se dit un minimum technique. Et concentrer dans une seule dépêche autant d'inexactitudes et de raccourcis, c'est surréaliste. Même les sites généralistes ont été plus factuels.
D'ailleurs au passage, vu le nombre de sites généralistes ayant relayé cette information, encore une preuve (s'il était besoin d'en faire) que le sujet est sensible.
[^] # Re: Information vraie ou fausse ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à 0.
Dans le cas présent c'est justement le fait d'avoir lu qui m'a fait gueuler. La NdM initiale ne corrigeant absolument rien aux calomnies que contient cette dépêche.
La deuxième NdM rectifie la news, mais pardonne moi l'expression de saison... cette dépêche est maintenant un vrai sapin de noël.
[^] # Re: Mais qui valide la publication de ces torchons ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à 2.
Je pense surtout qu'un site comme celui-ci, qui est considéré par du monde comme une référence et qui propose dans une dépêche de telles calomnies sur un projet, c'est ça, le manque de respect !
Que les modérateurs n'aient pas l'obligeance de passer deux minutes avant de vérifier ce qui peut se lire instantanément dans les sources... surtout pour une news aussi polémique sur des sujets aussi sensibles... c'est ça, le manque de respect !
Ici le manque de respect, il vient de ce site... envers les lecteurs, et le projet en question.
[^] # Re: Et si finalement
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à 1.
D'ailleurs, un certain nombre ont été corrigés dans OpenBSD, mais ne le sont toujours pas chez les autres. Je pense notamment aux drivers pour tirer parti des accélérateurs crypto matériels.
# Mais qui valide la publication de ces torchons ?
Posté par vosgien_ . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à 6.
Rappelons qu'à l'époque ce système d'exploitation était celui des 13 serveurs DNS racine.
Là je me dis... O M G. Mais comment prendre le reste de ce billet au sérieux après ça... A quel endroit as-tu lu une telle débilité ?
En raison de l'expiration du délai de la clause de confidentialité signée avec le FBI, c'est Gregory Perry, un ancien contributeur du projet de cryptographie d'OpenBSD qui nous révèle ça.
Vous avez au moins *lu* les mails de Theo de Raadt ? Ce mec (Gregory Perry) n'a jamais fait partie du projet, de près ou de loin !
Le but était de surveiller la circulation de données chiffrées, en insérant du code malicieux dans la pile réseau IPSEC d'OpenBSD.
Le but *aurait* été. Il n'existe aujourd'hui aucune preuve qu'il y ait eu volontairement la moindre vulnérabilité.
Et puis on parle d'OpenBSD... Tu t'es au moins un minimum renseigné où était également utilisé ce code ? TOUS les autres BSD utilisent le framework crypto d'OpenBSD ainsi que de très nombreux produits commerciaux. D'ailleurs depuis près d'une semaine, des problèmes (trouvés après l'audit, sans lien apparent avec le FBI) ont été corrigés dans OpenBSD mais ne le sont toujours pas chez les autres BSD.
[^] # Re: Oui
Posté par vosgien_ . En réponse à la dépêche Sortie d’OpenBSD 4.6 pour les 14 ans du projet. Évalué à 1.
Je n'ai jamais eu de souci. J'essaie toujours d'avoir un système de base supérieur ou égal en date à mes packages. Et dieu sait que je le fais souvent (toutes les semaines).
[^] # Re: Oui
Posté par vosgien_ . En réponse à la dépêche Sortie d’OpenBSD 4.6 pour les 14 ans du projet. Évalué à 1.
C'est pour cela que les options pour forcer l'update existent. Perso j'update tous mes packages avec :
pkg_add -u -F libdepends -F update -F alwaysupdate -F updatedependsEt comme je le disais, quand tu suis les logs du CVS ou la faq et qu'il y a des changements aux libs, tu t'arranges pour compiler le système avant de mettre à jour les ports en suivant les recommandations et ça passe. Comme je te dis, ça fait 3 ans que je fais cela... aucun souci.
En compilant mes ports moi-même j'évite de devoir recompiler le userland fréquemment (c'est long) et je limite le downtime.
La je comprends pas tout... tu préfères utiliser les ports, mais tu trouves long de compiler le userland ?!? Tu ne dois pas avoir beaucoup de ports alors. La machine en question est un serveur ? Si de toute manière tu dois recompiler un kernel pour raidframe, tu dois aussi compiler le userland pour ce kernel et je vois pas le problème...
[^] # Re: Oui
Posté par vosgien_ . En réponse à la dépêche Sortie d’OpenBSD 4.6 pour les 14 ans du projet. Évalué à 1.
Il n'y a absolument aucun problème à compiler toi même ton kernel+userland (même si c'est un kernel avec raidframe) et d'utiliser les packages des snapshots. Tout se passe bien quand on suit les logs du CVS ou la faq :
http://www.openbsd.org/faq/current.html
Après oui, c'est pas supporté... mais si tu suis -current, tu le sais déjà ;).
[^] # Re: FreeBSD 8
Posté par vosgien_ . En réponse à la dépêche Night of the living BSDeads. Évalué à 1.
Par contre, résumer cette utilisation à "juste" me semble un peu limite. Combien de distribs linux le font par défaut ?
[^] # Re: FreeBSD 8
Posté par vosgien_ . En réponse à la dépêche Night of the living BSDeads. Évalué à 4.
Au moment où le patch pour FreeBSD est apparu c'était une autre version de GCC qu'ils utilisaient, d'où le besoin du patch. Par contre si tu regardes le commentaire dans le lien fourni plus haut :
CURRENT: FreeBSD-CURRENT now has GCC-4.2 where ProPolice/SSP is provided by default. This patch is thus no longer needed.
[^] # Re: FreeBSD 8
Posté par vosgien_ . En réponse à la dépêche Night of the living BSDeads. Évalué à 3.
Instead, GCC 4.0 will ship with a framework called mudflap, which does about as much as "flap, flap, flap" flying through code. It catches one valid bound violation every April the 1st, and complains about valid code every other day of the year.
[^] # Re: Slackware est et reste ma distribution préférée
Posté par vosgien_ . En réponse à la dépêche Slackware 12.2 est disponible. Évalué à 3.
Quand quelqu'un achète une voiture, c'est pour l'utiliser régulièrement, avoir des fonctionnalités, comme la clim, l'auto radio CD, sièges chauffants, etc. qui apportent vraiment à l'utilisation et au confort.
Un installateur, mis à part à l'installation de ton système, c'est à dire peut-être 15min une fois par an et encore... tu ne l'utilises jamais. C'est pour cela qu'il doit être simple, aller à l'essentiel et faire ce qu'on lui demande, pas plus.
Ajoutons à cela que Slackware ne vise en aucun cas la même catégorie d'utilisateurs que les autres distributions...
Si tu veux vraiment comparer les installateurs à des voitures, compare les à des véhicules utilitaires qui sont dénués de tout superflu, pas à des voitures de tous les jours pour monsieur tout le monde.
[^] # Re: Besoins d'OpenBSD
Posté par vosgien_ . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 5.
Ce que tu dis montre clairement que tu n'es pas développeur et que tes remarques sont sans aucun fondement.
Pour toi un compilateur rapide produit du mauvais code ? C'est faux... PCC produit du bon code avec seulement très peu d'optimisations...
Pour toi un bon binaire i386 voudrait dire un binaire vax lent et vice versa ? C'est complètement incohérent.
Tu penses qu'il y a beaucoup de versions d'OpenBSD qui tournent actuellement sur du VAX dans le monde ?
Non je ne le pense pas... par contre ce dont je suis sûr c'est que le fait de maintenir des archis lentes et complètement dépassées depuis des lustres comme le vax permet à OpenBSD de régulièrement découvrir des bugs qui ne seraient jamais remontés sur des plateformes rapides.
[^] # Re: Besoins d'OpenBSD
Posté par vosgien_ . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 2.
http://linuxfr.org/2006/11/07/21588.html
[^] # Re: PCC concurrent de GCC ?
Posté par vosgien_ . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 4.
Campagne de dons pour le compilateur PCC
[^] # Re: PCC concurrent de GCC ?
Posté par vosgien_ . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 1.
Si tu avais lu la news complètement, tu aurais pu voir que la conformance à la norme C99 est un des principaux objectifs de PCC.
[^] # Re: Alternative ?
Posté par vosgien_ . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 3.
I used bytebench. Hm, a rerun on some of the passes shows that the difference is not much more against gcc 3.3.5 with -O2:
Test pcc -O gcc -O2 % of gcc performance
dhry2 1197813 1359242 88%
int 168286 186189 90%
float 190144 192564 99%
arithoh 2264451 3354473 67%
short 198920 198930 100%
double 145081 192597 75%
---
Average 87%
The cases where pcc is significantly slower is missing optimizations like strength reduction etc.
[^] # Re: Besoins d'OpenBSD
Posté par vosgien_ . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 6.
Je te rappel que dans le post original, Etienne parlait du besoin de compiler rapidement. Tu considères que la vitesse d'un compilateur, c'est être capable de cross-compiler sur des machines puissantes quand sur l'archi cible c'est trop lent ?
Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).
J'ai chez moi une vieille Sun SparcClassic, qui met environ une semaine pour compiler le système complet. Je ne parle même pas de mon VAX... Si tu étais développeur, tu comprendrais que passer d'un compilo qui met une semaine pour compiler un OS à un autre qui met 5 fois moins de temps, c'est un TRES GROS avantage.
Et puis quant à la portabilité, gcc l'est oui, mais c'est en comptant sur le fait qu'il soit catastrophique sur les archis autres que i386/amd64/PPC. Tu as déjà comparé gcc à sun studio sur sparc ? Tu as déjà comparé gcc à mipspro sur mips ? Si c'était le cas, tu verrais que gcc est très loin d'être ce petit bijou que tu crois être...