OpenBSD 5.5 est là... avec la faille Heartbleed d'OpenSSL

OpenBSD 5.5 est là… avec la faille Heartbleed d’OpenSSL

LibreSSL est en route, mais n'arrivera qu'avec la version 5.6

Avatar de l'auteur
Sébastien Gavois

Publié dans

Logiciel

05/05/2014 5 minutes
41

OpenBSD 5.5 est là... avec la faille Heartbleed d'OpenSSL

OpenBSD vient de publier une nouvelle version de son système d'exploitation. Estampillée 5.5, elle apporte plusieurs nouveautés dont la signature des paquets. Divers composants sont également mis à jour, dont OpenSSL qui passe en version 1.0.1f... mais qui est donc touché par la faille Heartbleed. Le fork LibreSSL, initié par OpenBSD, est encore en gestation et ne sera intégré à OpenBSD qu'à partir de la prochaine version 5.6.

 OpenBSD

OpenBSD 5.5 en hommage à Retour vers le futur

OpenBSD s'améliore et passe en version 5.5, mais...

OpenBSD est un système d'exploitation UNIX de type BSD, pour Berkeley Software Distribution, qui se veut simple et sécurisé par défaut. Au début de l'année, il a dû faire face à un problème financier important, mais un appel aux dons à permis de le tirer d'affaire. Une campagne de financement avait alors été lancée avec succès puisque sur les 150 000 dollars demandés, 153 000 ont été récoltés via 1 850 donateurs.

 

Quoi qu'il en soit, le système poursuit son chemin et vient de publier une nouvelle mouture estampillée 5.5. Comme souvent, les changements sont très nombreux. On peut par exemple citer le fait que les paquets soient désormais signés via Signify, tandis que le processus popa3d a été supprimé. Il s'agit d'une première étape puisque sendmail subira le même sort au profit d'OpenSMTPD, et ce, dès la mouture 5.6 d'OpenBSD. L'équipe annonce aussi le passage de la donnée time_t sur 64 bits, ce qui permet d'éviter le bug de l'an 2038, qui se produira le 19 janvier à 3h 14 min et 17 secondes en temps universel, avec un retour en 1901.

 

OpenBSD 5.5

...exploite toujours une version vulnérable d'OpenSSL (1.0.1f)

Mais c'est un autre point attire notre attention : OpenBSD 5.5 intègre OpenSSL 1.0.1f, une version touchée par la faille Heartbleed. Pour rappel, une version 1.0.1g a été mise en ligne début avril afin de corriger cet important problème de sécurité. Une situation quelque peu ubuesque pour un système mettant en avant la sécurité, en en faisant même son slogan.

 

En effet, jusqu'en 2002, le site indiquait « cinq ans sans vulnérabilité à distance dans l'installation par défaut », tandis qu'il précise désormais qu'il y en a eu seulement deux au cours des 12 dernières années. Sachez qu'une certaine polémique existe sur le sujet puisqu'il ne s'agit ici que des composants installés et lancés par défaut - et ils ne sont pas très nombreux, ce qui permet de limiter la casse.

 

La situation est d'autant plus étrange que suite à la découverte de la faille Heartbleed, OpenBSD s'est lancé dans un fork d'OpenSSL, financé depuis par l'OpenBSD Foundation : LibreSSL. Néanmoins, il est précisé que ce dérivé ne sera intégré que dans la prochaine mouture 5.6 qui devrait sortir le 1er novembre si le calendrier habituel est préservé. Theo de Raadt, le fondateur d'OpenBSD, précisait à nos confrères de ZDNet.com que 90 000 lignes de code C et 150 000 lignes de contenus avaient rapidement été supprimées, le but étant d'alléger le code afin d'enlever toute une partie ne disposant que d'un intérêt limité. Selon Theo de Raadt, c'est par exemple le cas de prise en charge de VMS et de Windows par exemple.

Bien évidemment, un patch existe

Bien évidemment, un patch est disponible afin de combler cette faille, mais il faudra l'installer séparément. On aurait largement préféré que ce soit le cas par défaut, surtout pour un OS mettant autant en avant la sécurité. Selon Loïc Blot, un ingénieur système UNIX qui s'exprime chez nos confrères de LinuxFR.org, l'explication serait que « d'après les différentes discussions que j'ai pu voir sur @tech, le processus de release d'OpenBSD étant strict et lancé, il était impossible de fournir un release patché ». Il faut rappeler qu'OpenBSD est disponible sous forme de CD et que ces derniers doivent être préparés bien en amont. Apparemment il s'agirait du 5 mars, soit un mois avant la découverte d'Heartbleed.

 

Est-ce pour autant un problème ? Pas tant que cela, à condition de bien prendre ses précautions. En effet, OpenBSD n'est pas un système d'exploitation pensé pour les débutants, même s'il est très bien documenté et qu'il est donc facilement accessible à tous. Il s'adresse généralement bien plus aux connaisseurs qui ne devraient donc avoir aucun mal à patcher l'OS... la principale préoccupation étant donc de ne pas oublier de le faire lors d'une installation ou d'une mise à jour. Notez que quatre autres patchs sont aussi disponibles.

 

OpenBSD 5.5 errata 

Les errata d'OpenBSD 5.5 

 

Pour télécharger OpenBSD c'est par ici que ça se passe, tandis qu'un guide pour effectuer une mise à jour depuis la version 5.4 est disponible par ici.

41

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

OpenBSD s'améliore et passe en version 5.5, mais...

...exploite toujours une version vulnérable d'OpenSSL (1.0.1f)

Bien évidemment, un patch existe

Commentaires (41)


Pour celles et ceux qui n’ont pas envie de recompiler la libssl, il y a une société qui s’appelle Mtier qui recompile le userland/kernel et les paquets OpenBSD qui ont eu des security fix et des bug fix.

Pour la 5.5 par exemple, tout est dispo ici.




Le fork LibreSSL, initié par OpenBSD, est encore en gestion gestation


Avant, j’utilisais le logiciel proprio Schtroumpf.



Et puis, j’ai vu la lumière et je suis passé à OpenSchtroumpf.

Mais comme y a eu un problème, j’ai switché sur LibreSchtroumpf.

Mais bon, y a aussi l’initiative FreeSchtroumpf.

Et aussi un projet de crowdfunding appelé CommunitySchtroumpf.



Ah, le libre, c’est tellement mieux. <img data-src=" />




L’équipe annonce aussi le passage de la variable time_t sur 64 bits, ce qui permet d’éviter le bug de l’an 2038, qui se produira le 19 janvier à 3h 14 min et 17 secondes en temps universel, avec un reboot en 1970.



On part de 1970 pour compter le temps, mais on reviendra en 1901 et pas en 1970 puisqu’on sera dans le négatif.









127.0.0.1 a écrit :



Avant, j’utilisais le logiciel proprio Schtroumpf.



Et puis, j’ai vu la lumière et je suis passé à OpenSchtroumpf.

Mais comme y a eu un problème, j’ai switché sur LibreSchtroumpf.

Mais bon, y a aussi l’initiative FreeSchtroumpf.

Et aussi un projet de crowdfunding appelé CommunitySchtroumpf.



Ah, le libre, c’est tellement mieux. <img data-src=" />





Ces salauds, qui adaptent les logiciels à leurs besoins au lieu de les subir !









lysbleu a écrit :



Ces salauds, qui adaptent les logiciels à leurs besoins au lieu de les subir contribuer !







<img data-src=" />









lysbleu a écrit :



On part de 1970 pour compter le temps, mais on reviendra en 1901 et pas en 1970 puisqu’on sera dans le négatif.





Ces salauds, qui adaptent les logiciels à leurs besoins au lieu de les subir !







Les timestamp sont des entiers signés ? :o









EMegamanu a écrit :



Les timestamp sont des entiers signés ? :o





Sous Linux, non, en tout cas. Il s’effectuera donc bien un retour en 1970.

Le bug de 2038 n’affecte que ceux qui stockent ça sur un signed 32 bits. Ceux qui sont sur un unsigned 32 bits ont (un peu) plus de marge !









127.0.0.1 a écrit :



Avant, j’utilisais le logiciel proprio Schtroumpf.



Et puis, j’ai vu la lumière et je suis passé à OpenSchtroumpf.

Mais comme y a eu un problème, j’ai switché sur LibreSchtroumpf.

Mais bon, y a aussi l’initiative FreeSchtroumpf.

Et aussi un projet de crowdfunding appelé CommunitySchtroumpf.







Sans troller autant que 127.0.0.1, c’est clair que c’est le problème numéro 1 de la communauté open-source ; plutôt que de discuter et de régler les situations, on préfère forker un projet et diviser la communauté en deux projets, et donc faire le travail plusieurs fois.



La ou ça se voit le plus clairement, c’est dans les software d’installation de distribution Linux. Tout ceux là font basiquement presque tous le même boulot niveau technique mais chaque distribution est passé du modèle générique console, a chacun le sien et on a X-Y software différents, maintenus, qui font tous la même chose.









Kamalen a écrit :



Sans troller autant que 127.0.0.1, c’est clair que c’est le problème numéro 1 de la communauté open-source ; plutôt que de discuter et de régler les situations, on préfère forker un projet et diviser la communauté en deux projets, et donc faire le travail plusieurs fois.









Oui et non. Certes il y a des forks… mais il est courant de voir :




  • des échanges entre les forks sur des fonctionnalités complémentaires

  • un fork devenir très actif et prendre la relève par rapport à un projet qui n’avait plus donné de signe de vie depuis belle lurette

  • voir des forks fusionner entre eux, voir avec le projet d’origine.







    heisspiter a écrit :



    Sous Linux, non, en tout cas. Il s’effectuera donc bien un retour en 1970.

    Le bug de 2038 n’affecte que ceux qui stockent ça sur un signed 32 bits. Ceux qui sont sur un unsigned 32 bits ont (un peu) plus de marge !





    Merci beaucoup de cette explication. :)











Kamalen a écrit :



Sans troller autant que 127.0.0.1, c’est clair que c’est le problème numéro 1 de la communauté open-source ; plutôt que de discuter et de régler les situations, on préfère forker un projet et diviser la communauté en deux projets, et donc faire le travail plusieurs fois.



La ou ça se voit le plus clairement, c’est dans les software d’installation de distribution Linux. Tout ceux là font basiquement presque tous le même boulot niveau technique mais chaque distribution est passé du modèle générique console, a chacun le sien et on a X-Y software différents, maintenus, qui font tous la même chose.







Le souci restant que quand on fork, c’est qu’en général on ne cible pas les mêmes choses … Le fait qu’ils se permettent de virer le support de VMS & Windows montre bien qu’ils n’ont pas la même cible <img data-src=" />



Et l’avantage du libre reste que si l’autre projet à fait quelquchose de bien … bah tu peux toujours piocher dans leur code source pour récupérer la fonctionalité <img data-src=" />









127.0.0.1 a écrit :



Avant, j’utilisais le logiciel proprio Schtroumpf.



Et puis, j’ai vu la lumière et je suis passé à OpenSchtroumpf.

Mais comme y a eu un problème, j’ai switché sur LibreSchtroumpf.

Mais bon, y a aussi l’initiative FreeSchtroumpf.

Et aussi un projet de crowdfunding appelé CommunitySchtroumpf.



Ah, le libre, c’est tellement mieux. <img data-src=" />







Provoc mis à part, je pense que la tu es peut être tombé sur le contre-exemple parfaitement justifié.

Cela fait déjà 4 ou 5 ans que je lis régulièrement des articles de développeurs expérimentés qui pestent sur openssl en disant (exemple à l’appui) que c’est un gros tas de code non documenté, incompréhensible et aussi difficile à intégrer correctement qu’à faire évoluer.



Après les choses sont ce qu’elles sont (manque de temps, de moyen, poids de la rétro-compatibilité) et je ne jettent pas la pierre à personne. Mais cela me semble être un de ces cas ou une remise à plat est la meilleure chose à faire.









Kamalen a écrit :



Sans troller autant que 127.0.0.1, c’est clair que c’est le problème numéro 1 de la communauté open-source ; plutôt que de discuter et de régler les situations, on préfère forker un projet et diviser la communauté en deux projets, et donc faire le travail plusieurs fois.



La ou ça se voit le plus clairement, c’est dans les software d’installation de distribution Linux. Tout ceux là font basiquement presque tous le même boulot niveau technique mais chaque distribution est passé du modèle générique console, a chacun le sien et on a X-Y software différents, maintenus, qui font tous la même chose.





Tout d’abord, il faut noter qu’OpenBSD n’est pas une distrib Linux.

De plus, Theo de Raadt, le chef du projet OpenBSD est un trolleur sans commune mesure.

Il aime taper sur Linux et tout se qui l’entoure… même si il n’a pas toujours tord <img data-src=" />



Alors au delà du procès d’intention que je fais <img data-src=" />, il me semble qu’on est dans le même cas dans le proprio quant à la diversité des logiciels que ce soit pour les players vidéo et/ou audio, les logiciels de retouche d’image, etc

Là aussi on a X-Y software différents qui font tous la même chose.

Et là par contre ça ne pose pas de pbs.<img data-src=" />





Néanmoins, il est précisé que ce dérivé ne sera intégré que dans la prochaine mouture 5.6 qui devrait sortir le 1er mai si le calendrier habituel est préservé.





Faudra m’expliquer là.



Selon la news, la mouture 5.6 est sortie depuis le 1er mai.

Pourquoi faire un article sur la 5.5??



<img data-src=" />








127.0.0.1 a écrit :



Avant, j’utilisais le logiciel proprio Schtroumpf.



Et puis, j’ai vu la lumière et je suis passé à OpenSchtroumpf.

Mais comme y a eu un problème, j’ai switché sur LibreSchtroumpf.

Mais bon, y a aussi l’initiative FreeSchtroumpf.

Et aussi un projet de crowdfunding appelé CommunitySchtroumpf.



Ah, le libre, c’est tellement mieux. <img data-src=" />





Oui enfin, qui utilise encore OpenSchtroumpf en 2014.

Je suis passé a LibreSchtroumpf aussi en 2012 après le patch “correctif” qui faisait planté la couleur de la moitié des users. Même si ils s’en sont excusé la faille #000000 a causé beaucoup de dégâts.

Le seul reproche que je fais a LibreSchtroumpf jusqu’à la c’est les problème d’incompatibilité avec la salsepareille de version inférieur a 1.0.13, même si le gout a été patché ca plante quand même souvent quand on en fais de la soupe.



N’investit pas dans CommunitySchtroumpf, Gargacorp a déjà passé un contrat de rachat de 1.2 millions avec eux et ça sent le piège.









js2082 a écrit :



Faudra m’expliquer là.



Selon la news, la mouture 5.6 est sortie depuis le 1er mai.

Pourquoi faire un article sur la 5.5??



<img data-src=" />







Effectivement il y a une erreur, la 5.5 est sortie le 1er mai et la 5.6 sortira le 1er novembre.









zempa a écrit :



Tout d’abord, il faut noter qu’OpenBSD n’est pas une distrib Linux.







Je parlais juste de ce que je connais, les soft qui installent la distrib Linux. Je connais la différence entre les deux <img data-src=" />







zempa a écrit :



Alors au delà du procès d’intention que je fais <img data-src=" />, il me semble qu’on est dans le même cas dans le proprio quant à la diversité des logiciels que ce soit pour les players vidéo et/ou audio, les logiciels de retouche d’image, etc

Là aussi on a X-Y software différents qui font tous la même chose.

Et là par contre ça ne pose pas de pbs.<img data-src=" />







C’est vrai que c’est le même principe, mais a un détail près, d’après moi ; les contributeurs propriétaires sont tous payés et travaillent a plein temps, ce qui n’est pas le cas de la majorité des contributeurs du libre, qui travaillent plutôt sur leur temps… libre ( <img data-src=" /> ).



Si l’idée du libre est de distribuer le plus largement possible, pourquoi diviser les forces ?









127.0.0.1 a écrit :



Avant, j’utilisais le logiciel proprio Schtroumpf.



Et puis, j’ai vu la lumière et je suis passé à OpenSchtroumpf.

Mais comme y a eu un problème, j’ai switché sur LibreSchtroumpf.

Mais bon, y a aussi l’initiative FreeSchtroumpf.

Et aussi un projet de crowdfunding appelé CommunitySchtroumpf.



Ah, le libre, c’est tellement mieux. <img data-src=" />







L’herbe est toujours plus verte chez le voisin. C’est vrai dans le proprio ET dans le libre.

Bah, ça me fait bosser sur des “grands projets de refonte”, ou des “projets de migration”, une fois sur du proprio, une fois sur de l’open source…



Les questions à se poser :




  • quel est le besoin ?

  • quel est mon budget ?

  • quelles sont les compétences à disposition ?

  • et enfin, pour quelle date de livraison ?



    Pour revenir à ton post, le libre te permet de changer assez facilement d’environnement, justement. Ca n’est jamais indolore, mais c’est faisable.



    Dans le proprio, je me suis tapé de la maintenance sur une webapp J2EE, mais sur serveur proprio, avec le framework et tout. Le client n’a jamais voulu faire/payer les mises à jour.



    Résultat : jusqu’à fin 2014, une JVM de 2002 continue de tourner en prod. Au niveau compatibilité de navigateur et d’applet, je laisse imaginer…









Kamalen a écrit :



Si l’idée du libre est de distribuer le plus largement possible, pourquoi diviser les forces ?





Parce que tu aurais envie de contribuer gratuitement à un truc auquel tu crois (à tord ou à raison) que ça ne va pas dans la bonne direction?



“Tiens aujourd’hui je vais aller mettre un peu de charbon dans ce train qui fonce dans le mur, histoire de faire quelque chose d’utile…”









atomusk a écrit :



Le souci restant que quand on fork, c’est qu’en général on ne cible pas les mêmes choses … Le fait qu’ils se permettent de virer le support de VMS & Windows montre bien qu’ils n’ont pas la même cible <img data-src=" />



Et l’avantage du libre reste que si l’autre projet à fait quelquchose de bien … bah tu peux toujours piocher dans leur code source pour récupérer la fonctionalité <img data-src=" />







On pourrait rajouter que Windows NT est un fork de VMS …. la boucle est bouclée <img data-src=" />









Kamalen a écrit :



Si l’idée du libre est de distribuer le plus largement possible, pourquoi diviser les forces ?







Non l’idée du libre c’est d’être libre d’adapter un logiciel à ta situation. C’est aussi d’avoir la liberté de travailler sur le projet que tu veux <img data-src=" />









Kamalen a écrit :



C’est vrai que c’est le même principe, mais a un détail près, d’après moi ; les contributeurs propriétaires sont tous payés et travaillent a plein temps, ce qui n’est pas le cas de la majorité des contributeurs du libre, qui travaillent plutôt sur leur temps… libre ( <img data-src=" /> ).



Si l’idée du libre est de distribuer le plus largement possible, pourquoi diviser les forces ?





L’idée est davantage d’adapter un logiciel existant à tes propres besoins.

Le partage est le corollaire et est “imposé” pour que les bénéfices se fassent dans les deux sens.

C’est comme cela que je vois les choses.









Kamalen a écrit :



Je parlais juste de ce que je connais, les soft qui installent la distrib Linux. Je connais la différence entre les deux <img data-src=" />







C’est vrai que c’est le même principe, mais a un détail près, d’après moi ; les contributeurs propriétaires sont tous payés et travaillent a plein temps, ce qui n’est pas le cas de la majorité des contributeurs du libre, qui travaillent plutôt sur leur temps… libre ( <img data-src=" /> ).



Si l’idée du libre est de distribuer le plus largement possible, pourquoi diviser les forces ?





En quoi c’est un mal de diviser les forces ? Justement grâce au libre, on ne perd rien, car on peut récupérer tout ce qu’a mieux fait l’autre, et vice versa. Au final, on a tous les effets bénéfiques de la concurrence (émulation entre les projets, choix effectués qui plaisent chez l’un mais pas chez l’autre) sans ses défauts (devoir réinventer la roue à chaque fois).



Bon, après y a des subtilités entre les licences qui font que des fois ce n’est pas possible, ça c’est un problème (oui je parle de toi GPL !).



Il n’y a qu’à prendre comme exemple le compilateur gcc, qui se reposait sur ses lauriers jusqu’à ce que clang vienne lui mettre un coup de pied aux fesses, ou bien openoffice, qui clairement ne s’améliorait pas assez vite, et qui grâce au coup de pouce involontaire d’Oracle a donné naissance à LibreOffice.









cyrilleberger a écrit :



<img data-src=" />





Contribuer à un fork, c’est aussi contribuer au projet original et à tous les autres projets qui voudraient s’en inspirer <img data-src=" />









seblamb a écrit :



On pourrait rajouter que Windows NT est un fork de VMS …. la boucle est bouclée <img data-src=" />





Pas du tout, c’est juste un jeu de mot avec VMS.

En réalité, Win NT est un fork d’OS/2.









alexandredenis a écrit :



Pas du tout, c’est juste un jeu de mot avec VMS.

En réalité, Win NT est un fork d’OS/2.





C’est plus compliqué …

http://windowsitpro.com/windows-client/windows-nt-and-vms-rest-story









lysbleu a écrit :



En quoi c’est un mal de diviser les forces ? Justement grâce au libre, on ne perd rien, car on peut récupérer tout ce qu’a mieux fait l’autre, et vice versa. Au final, on a tous les effets bénéfiques de la concurrence (émulation entre les projets, choix effectués qui plaisent chez l’un mais pas chez l’autre) sans ses défauts (devoir réinventer la roue à chaque fois).



Bon, après y a des subtilités entre les licences qui font que des fois ce n’est pas possible, ça c’est un problème (oui je parle de toi GPL !).



Il n’y a qu’à prendre comme exemple le compilateur gcc, qui se reposait sur ses lauriers jusqu’à ce que clang vienne lui mettre un coup de pied aux fesses, ou bien openoffice, qui clairement ne s’améliorait pas assez vite, et qui grâce au coup de pouce involontaire d’Oracle a donné naissance à LibreOffice.





Tu veux dire que tu peux profiter la logithèque android sans avoir à le supporter. ?









127.0.0.1 a écrit :





Ah, le libre, c’est tellement mieux. <img data-src=" />





C’te troll <img data-src=" />



Le pire c’est que t’as appâté grave avec celui là. Respect <img data-src=" />





En effet, OpenBSD n’est pas un système d’exploitation pensé pour les débutants et il s’adresse bien plus aux connaisseurs qui ne devraient donc avoir aucun mal à patcher l’OS…



Voilà, tout est dit.

On n’installe pas un openBSD pour ne pas l’administrer derrière…

Le choix n’est pas si incohérent que ca, c’est même plutôt logique de privilégier la robustesse du processus de build final / release et son planning, quand on est dans la situation d’openBSD.


Comme si c’était pas fait exprès, le gars qui a créé le fork qui sort son OS avec la faille qu’il veut dénoncer…








heisspiter a écrit :



Sous Linux, non, en tout cas. Il s’effectuera donc bien un retour en 1970.

Le bug de 2038 n’affecte que ceux qui stockent ça sur un signed 32 bits. Ceux qui sont sur un unsigned 32 bits ont (un peu) plus de marge !







(coupage de cheveux en 0b100) un entier 32 bits signé se stocke exactement comme un entier 32 bits non signés, c’est à dire sur 4 octets (ou 32 bits, ça marche aussi) <img data-src=" /> (/mode)



Trève de plaisanterie :

si tu compiles ça sur un linux :



#include “stdio.h”

#include “time.h”

/ double quote, les inferieur/supérieur passe pas en commentaire /

int main() { time_t t=-1; struct tm *date=gmtime(&t);



printf("%d-%d-%d\n",date-&gt;tm\_mday,date-&gt;tm\_mon,date-&gt;tm\_year);   



}



tu obtiens bien le 31-12-1969 et pas une date en 2038 comme ça serait le cas si time_t n’était pas signé.



ça veut pas dire grand chose que linux utiles un time_t non signé. J’imagine que dans le noyau ils ont pris des précautions, mais je doute que (par exemple) tous les outils de la suite GNU utilise cette convention, et dans la lib C, visiblement ils ont gardé le type signé









baldodo a écrit :



(coupage de cheveux en 0b100) un entier 32 bits signé se stocke exactement comme un entier 32 bits non signés, c’est à dire sur 4 octets (ou 32 bits, ça marche aussi) <img data-src=" /> (/mode)







Être stocké sur le même nombre de bits != avoir la même représentation binaire. Un entier signé n’est pas stocké de la même manière qu’un entier non-signé:







EMegamanu a écrit :



Les timestamp sont des entiers signés ? :o





time_t n’a pas de definition officielle. Ca peut même être un float/double.









metaphore54 a écrit :



Tu veux dire que tu peux profiter la logithèque android sans avoir à le supporter. ?





Pas compris <img data-src=" />



Dans la libc tout entier 32bits signé ou non signé se stocke de la même manière pourvu qu’il soit strictement positif (il peut y avoir un 0- ) et inferieur ou égal à 2^31 : c’est la norme. Pour les autres ils sont dans des ensembles disjoints donc, évidemment ils ont un codage spécifique.








baldodo a écrit :



Dans la libc tout entier 32bits signé ou non signé se stocke de la même manière pourvu qu’il soit strictement positif (il peut y avoir un 0- ) et inferieur ou égal à 2^31.







inférieur strictement à 2^31 bien sur, mon doigt a rippé ;)









Kamalen a écrit :



Sans troller autant que 127.0.0.1, c’est clair que c’est le problème numéro 1 de la communauté open-source ; plutôt que de discuter et de régler les situations, on préfère forker un projet et diviser la communauté en deux projets, et donc faire le travail plusieurs fois.





C’est pas systématiquement un problème, et de plus c’est pas un problème lié à l’open-source.



Pour le 1er point, parmi les gros fork dont je me souvienne, il y a OpenOffice/LibreOffice, MySQL/MariaDB. Dans les 2 cas ce sont des réussites. Il y a aussi libjpeg et libjpeg-turbo pour des trucs moins visibles. Bref, généralement quand y’a un fork c’est qu’il y a une bonne raison quand même.



Pour le second point, la division des ressources est énormément plus importantes sur les logiciels propriétaires. Un exemple concret sont les pilotes graphiques. Intel, Nvidia et AMD fait chacun sa pile graphique complète. Alors qu’avec la pile 3D libre (Mesa), il y a énormément de code commun pour toutes les cartes !

J’avais trouvé un bug d’affichage sur Left 4 Dead 2 avec quelques Radeon HD 4000 et des options graphiques particulières. Quelque mois plus tard le bug a été corrigé… par un gars d’Intel. C’était un bug dans le compilateur GLSL, utilisé par Intel, AMD et Nvidia.









baldodo a écrit :



Dans la libc tout entier 32bits signé ou non signé se stocke de la même manière pourvu qu’il soit strictement positif (il peut y avoir un 0- ) et inferieur ou égal à 2^31 : c’est la norme. Pour les autres ils sont dans des ensembles disjoints donc, évidemment ils ont un codage spécifique.





Avec cette précision, nous sommes d’accord <img data-src=" />









Drepanocytose a écrit :



C’te troll <img data-src=" />



Le pire c’est que t’as appâté grave avec celui là. Respect <img data-src=" />







La recette est connue: un fond de vérité, une dose d’exagération, et un zest de provoque… <img data-src=" />









127.0.0.1 a écrit :



La recette est connue: un fond de vérité, une dose d’exagération, et un zest de provoque… <img data-src=" />





Un bon troll bien gras aurait été de dire :



« Pas besoin de bogue pour revenir en 1901, avec le Libre on y est déjà ! » <img data-src=" />









paradise a écrit :



« Pas besoin de bogue pour revenir en 1901, avec le Libre on y est déjà ! » <img data-src=" />





As-tu posté ce commentaire avec Chrome ou Firefox ? <img data-src=" />

Dans ce cas il y a un problème, il n’est pas daté de 1901 !