Le premier mai, OpenBSD est de sortie, comme chaque année.
OpenBSD est un système d'exploitation orienté sécurité et réseau, dont les principaux avantages sont la stabilité, grâce aux audits sur le code source, mais également l'ensemble très large de fonctionnalités réseau qu’il fournit.
Le changement majeur de cette version est dans la continuité du fork d’OpenSSL, LibreSSL (cf. Bob Beck, LibreSSL - The first 30 days and the Future, BSDcan 2014 ; Ted Unangst, LibreSSL: More Than 30 Days Later, EuroBSDCon 2014). En effet, neuf jours après la sortie d'OpenBSD 5.6, la vulnérabilité POODLE a pointé son nez. Adieu SSL 3, SSH 1 et MD5 !
Ont contribué à cette dépêche (par ordre de dispersion) : BAud, karchnu, Loïc Blot, Xavier Teyssier, palm123, zurvan, Cédric Krier, Rolinh, Xavier Claude, Ellendhel, Dareg, Nÿco, Stéphane Aulery. Aucune moule n'a été blessée durant la rédaction.
Sommaire
- Mises à jour
- Ci-gisent hp300, mvme68k et mvme88k
- Passage de GCC à llvm / clang ?
- Changement de boutique officielle
- Conclusion
Mises à jour
Logiciels
Dans les grandes lignes, OpenBSD, accompagné de ses ports, c'est :
- xserver 1.16.4 ;
- GCC 4.8.4 et 4.9.2 ;
- Gnome 3.14.2 ;
- Go 1.4.1 ;
- Libreoffice 4.3.5 ;
- LLVM/CLANG 3.5 ;
- Firefox 35.0.1 et 31.4.0-ESR ;
- Mono 3.12.0 ;
- Perl 5.20 ;
- PHP 5.3.29, 5.4.38, 5.5.22 et 5.6.5 ;
- Xfce 4.10 ;
- et bien d'autres… (plus de 9 000 ports)
Réseau
- la couche des mbufs bénéficie désormais du multi-processing de manière sécurisée ;
- les interfaces carp nécessitent obligatoirement l’option carpdev ;
- il est possible de changer la taille de la file d’attente des paquets IPv6.
Sécurité
- l’espace d’adressage du noyau a été renforcé au moyen des mécanismes W^X (aucun emplacement mémoire n’est à la fois accessible en exécution et en écriture) ;
- il n’est plus possible de charger des modules noyau ;
-
procfsa été supprimé ; -
/var/tmpest maintenant un lien symbolique vers/tmp; ce n’est qu'un premier pas vers la réduction de la surface d’attaque de la partition/var; - SHA512 remplace MD5 pour les séquences initiales de TCP ainsi que dans le générateur de nombres aléatoires ;
- le passwd ne gère plus que le chiffrement Blowfish ;
- SSLv2/3 ont été complètement retirés d’OpenBSD au profit de TLS (y compris pour OpenSMTPD), ils sont aussi désactivés par défaut dans LibreSSL ;
- LibreSSL gère des algorithmes AEAD et le PFS par défaut ;
- toutes les architectures bénéficient enfin (débuté en 2003 par les libraires) de PIE, le système d’allocation en position aléatoire des programmes en mémoire (cf. Pascal Stumpf, Converting OpenBSD to PIE, AsiaBSDCon 2015 : transparents, papier).
Pilotes
Parmi une trentaine de nouveaux pilotes on remarque notamment :
- controlleurs USB 3.0 (USB eXtensible) ;
- modem USB de l’Arduino Leonardo.
Serveur web
Nginx a été retiré de base. Si vous souhaitez l’utiliser il faut passer par les packages. Il a été remplacé par httpd inclus dans base lors de la sortie de la version précédente. Le module FastCGI a été notablement amélioré rendant httpd compatible avec davantage d’applications web courantes (cf. Reyk Flöter, OpenBSD's new httpd, AsiaBSDCon 2015 : transparents, papier).
Entré en septembre 2011 et sorti en mai 2015, après moins de quatre ans, Nginx n’aura pas fait long feu, alors qu’Apache avait rendu service pendant seize ans.
Pour rappel, httpd n’offre pas toutes les fonctionnalités de Nginx mais seulement celles utiles au projet — ce qui devrait suffire au commun des mortels évidemment. Pour 10 000 lignes de code, la chose est honnête :
- fichiers statiques : sert les fichiers et répertoires statiques via l'option auto-indexing ;
- fastCGI : FastCGI direct (pas de cache) et asynchrone via des sockets UNIX ou locaux ;
- sécurité : sécurité avant tout, chrooté avec privsep par défaut ;
- SSL/TLS : connexions sécurisées en TLS 1.2 via LibreSSL ;
- serveurs virtuels : serveurs virtuels par nom ou IP ;
- reconfiguration : rafraîchissement de la configuration sans interruption ;
- journalisation : journalisation pour chaque serveur via des fichiers de log ou syslog ;
- accès : blocage, ralentissement et redirection de connexions.
L’ajout de Server Name Indication (SNI) et des certificats client est envisagé.
Installation
- il est possible de booter sur les architectures PowerMac7,2 et PowerMac7,3 avec un noyau multiprocesseur ;
- les interfaces réseau virtuelles trunk (agrégation de liens physiques) sont disponibles durant les mises à jour ;
- les fonctionnalités cryptographiques ont été retirées du ramdisk — également compilé sans optimisation — afin de récupérer de l’espace pour d’autres fonctionnalités ;
- les ensembles etcXX.tgz et xetcXX.tgz ont été fusionnés avec baseXX.tgz et xbaseXX.tgz.
Divers
Mandoc prend en charge les codages UTF-8 et ISO-8859-1. Les programmes man et apropos sont maintenant des façades de mandoc (cf. Ingo Schwarze, New trends in mandoc, BSDcan 2014).
L’implémentation des opérations atomiques a été complétée pour toutes les architectures avec les nouvelles primitives :
- atomic_cas_uint ;
- atomic_swap_uint ;
- atomic_add_int ;
- atomic_sub_int ;
- atomic_inc_int ;
- atomic_dec_int et membar_sync.
Les développeurs travaillent activement à supprimer le verrou global du noyau. Sans cela, il est impossible d’exploiter correctement une machine multi-processeur. Pour le moment, seuls 20 appels système sur 208 sont sans verrou. Par contre, le sous-système audio est déjà sans verrou, ainsi que le pilote réseau myx.
L’usage des fonctions d’allocation de mémoire (propres à OpenBSD : reallocarray() et mallocarray()) a été généralisé pour prévenir les débordements d’entier, en lieu et place de la politique précédente concernant calloc(). Elles offrent un compromis entre la flexibilité de realloc() et la lenteur de calloc() — cette dernière initialise systématiquement la totalité de la mémoire allouée, sans considération d'utilité.
Ci-gisent hp300, mvme68k et mvme88k
La prise en charge de plusieurs architectures a été retirée d'OpenBSD 5.5 : hp300, mvme68k, mvme88k. Le fait n’avait pas été signalé. Les disques durs des machines du responsable de ces ports ont rendu leur dernier soupir. Il a décidé de ne pas réanimer ces infortunés Lazare.
Noone sane will mourn these ports anyway. So long, and thanks for the fish. — Miod Vallat
Aucune personne qui soit saine (d’esprit ?) ne pleurera ces ports de toute façon. Salut, et encore merci pour le poisson — Miod Vallat
NdM : de toute façon Miod Vallat maintient un grand nombre de ports sur toutes sortes de machines.
Passage de GCC à llvm / clang ?
FreeBSD intègre clang dans base depuis la version 9 (janvier 2012), permettant la compilation quasi complète (World et le noyau GENERIC) pour certaines architectures (i386, AMD64, ARM, PowerPC, PowerPC64). Clang n’est pas encore le compilateur par défaut, excepté pour l'architecture x86 depuis novembre 2012.
NetBSD, quant à lui, propose clang comme alternative depuis mars 2014 pour les architectures i386, AMD64 et ARM.
Et OpenBSD dans tout ça ? La question revient régulièrement sur les listes de discussion avec le même constat. Clang manque encore de prise en charge pour les architectures autres que X86, ARM et PowerPC, ce qui freine son adoption en l’état. Toutefois ce n’est pas le seul obstacle.
En juillet 2013, Miod Vallat, le mainteneur des patchs d’OpenBSD pour GCC, a fait part de l’état d’esprit des développeurs sur la question.
Une poignée d’entre eux se familiarise avec les entrailles de llvm / clang espérant dans quelques mois / années pouvoir compiler les architectures principales. La route sera longue.
Toutefois, une question de fond a été soulevée. OpenBSD recherche d’abord et avant tout un compilateur proposant les standards de C / C++ au complet, un support de longue durée (LTS) et une optimisation du code qui n’introduise pas de bogues — pas trop agressive.
Tout se résume à une question de confiance envers le compilateur qui devrait être quasi exempt de bogues et produire des programmes exactement conformes à leur code source. OpenBSD travaille d’arrache-pied pour que sa version de GCC s’approche le plus possible de cet idéal. Une bascule vers clang remettrait en cause tous ces efforts.
Il faut bien constater qu’à ce jour, aucun compilateur libre ne répond à tous ces critères pourtant légitimes. Alors quid d’un support LTS de GCC et llvm / clang, comme pour le noyau Linux ou Firefox ?
Changement de boutique officielle
Depuis octobre 2014, OpenBSD Europe Store, tenue par Zednax, est devenue la boutique privilégiée d’OpenBSD.
La Computer Shop of Calgary d’Austin Hook est toujours en activité, mais devrait fermer à moyen terme — on peut le penser — car il « a acheté une ferme avec des vaches et des chèvres » (sic, pour sa retraite ?). Austin continuera au second plan, en fidèle gardien des traditions, prodiguant ses conseils et son aide.
Après quelques adaptations nécessaires au démarrage pour le paiement en tout point du globe, Theo de Raadt est très content des services rendus par OpenBSD Europe Store qu’il a qualifié de « transparente, responsable, propre ». En bref, de très bonnes relations se sont établies et ce n’est pas sans raison. Longue vie à OpenBSD Europe Store !
Conclusion
Fidèle à elle-même, la communauté OpenBSD continue son chemin avec des moyens modestes mais capables d'innover et de relever les enjeux actuels comme le fork d’OpenSSL.
La liquidation du verrou global du noyau en est un exemple. Il sera intéressant de comparer combien de temps il faudra aux développeurs d’OpenBSD là où ceux du noyau Linux ont mis 31 mois.
Aller plus loin
- Site officiel : openbsd.org (313 clics)
- OpenBSD Release Notes (79 clics)
- OpenBSD 5.6 to 5.7 changes (84 clics)
- OpenBSD Europe Store (56 clics)
- OpenBSD 5.7 errata (45 clics)
- Chanson officielle d’OpenBSD 5.7 : « Source Fish » (79 clics)
- DLFP : OpenBSD 5.6 (176 clics)
# Compilateur sans bugs
Posté par gasche . Évalué à 10.
Il existe un compilateur C qui est garanti "quasiment sans bug", c'est Compcert, un compilateur prouvé correct : il vient avec une preuve formelle, vérifiée par ordinateur, que si le compilateur produit un fichier assembleur alors celui-là a la même sémantique que le programme C de départ. Malheureusement, ce n'est pas du logiciel libre (restriction à un usage non-commercial), en tout cas pour l'instant.
[^] # Re: Compilateur sans bugs
Posté par anaseto (site web personnel) . Évalué à 3. Dernière modification le 01 mai 2015 à 12:16.
Et puis il a deux autres limitations importantes dans ce contexte : nombre limité d'architectures supportées (une des raisons pour lesquelles openbsd n'utilise pas clang, déjà) et temps de compilation assez élevés (au moins de l'ordre du double que gcc, si je me souviens bien).
[^] # Re: Compilateur sans bugs
Posté par dest . Évalué à 10.
La compilation 2 fois plus longue, c'est chiant pour les développeurs mais quand tu t'appelles OpenBSD et que tu recherches la sécurité dans ton dev, t'as envie que la génération de code soit juste.
2 fois plus long, c'est pas cher payé au rapport du temps que ton serveur va tourner et exécuter ledit code.
Après si c'est pas libre, c'est une autre histoire.
[^] # Re: Compilateur sans bugs
Posté par anaseto (site web personnel) . Évalué à 7.
Ce n'est pas aussi simple. Compcert est un compilateur pensé pour du code qui s'exécute dans des systèmes critiques, code qui lui-même a été analysé de mille façons pour s'assurer qu'il n'a pas de bugs en soi. Il apporte une garantie très agréable pour ce genre de logiciels. Mais dans le contexte d'un compilateur pour tout un OS assez généraliste, même avec certaines priorités, la plupart du code n'a pas pu, ne peut pas, se permettre autant de perfection, et du coup n'entre pas dans le cadre visé. En pratique, ça signifie par exemple que la version patchée de gcc dans OpenBSD utilise des méthodes pour faire en sorte que les failles dans du code buggué ne soient pas si facilement exploitables. Si tu remplaces le gcc actuel, puis que tu compiles tout OpenBSD avec Compcert (si c'est vraiment possible), c'est pas sûr que le résultat sera plus sûr, en fin de compte : pour cela il faudrait que les programmes n'aient pas de bugs.
Bref, ce qui serait bien c'est un compilateur libre écrit avec l'objectif d'être suffisamment correct, mais utilisé pour tout un OS, ce qui inclut compiler du code avec des bugs et faire en sorte qu'ils soient moins gênants ou les détecter si c'est possible, mais aussi des bons messages d'erreurs, génération de code pour suffisamment d'architectures, pas trop mais suffisamment optimisant (sachant que les applications d'OpenBSD sont quand même variées), et suffisamment rapide, car je pense que le temps de compilation a bien une importance : le code d'OpenBSD, ainsi que l'ensemble des ports, est en train de se compiler en permanence, il me semble, du coup si tu doubles le temps de compilation, tu ralentis le procédé et, même avec plus de machines, tu augmenterais au moins la facture d'électricité… Le fait est, qu'actuellement, ce qui s'approche le plus d'un tel compilateur semble être le gcc patché d'OpenBSD.
[^] # Re: Compilateur sans bugs
Posté par Stéphane Aulery (site web personnel) . Évalué à 3. Dernière modification le 01 mai 2015 à 17:02.
Je pense que tu as lu le message de Miod, non ? Tu as complètement exposé les attentes et problématiques, là où j'ai résumé en trois phrases. Merci anaseto.
SA
[^] # Re: Compilateur sans bugs
Posté par anaseto (site web personnel) . Évalué à 2.
Oui, je l'avais lu il y a quelques temps.
[^] # Re: Compilateur sans bugs
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Dès que j'ai lu cela et je me suis dis de suite, ça c'est un truc de l'INRIA. Gagné !
Je ne sais pas quand l'INRIA va comprendre que son modèle ne marche pas toujours ? Enfin, le code source est sur github, je vois que les choses bougent ;-)
[^] # Re: Compilateur sans bugs
Posté par gasche . Évalué à 4.
Je trouve que ta remarque sur l'INRIA tombe un peu à plat, car dans le cas de Compcert (ainsi que dans le cas de tous les logiciels produits par des équipes INRIA dont j'ai personnellement connaissance, et qui sont en très grande majorité des logiciels libres) c'est l'auteur du logiciel qui a choisi la licence. Il me semble normal et légitime que les auteurs soient libres de choisir la licence qui leur semble adaptée (même si en l'occurrence je déplore ce choix), et tu y vois un rôle de l'institut employeur qui n'est pas présent en réalité.
[^] # Re: Compilateur sans bugs
Posté par claudex . Évalué à 7.
Moi, il me semble normal que ce l'employeur qui décide (c'est lui qui paye après tout).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Compilateur sans bugs
Posté par rewind (Mastodon) . Évalué à 2.
Le droit d'auteur dans la fonction publique, c'est un peu compliqué. Et dans le cas de l'enseignement supérieur et de la recherche, les auteurs restent maîtres des droits d'auteur. C'est notamment pour cette raison que si un prof d'université écrit un bouquin (ce qui est dans ses missions), la rémunération au titre des droits d'auteur lui revient directement. Donc, dans le cas de l'INRIA, c'est pareil, c'est l'auteur qui décide et l'INRIA n'a pas son mot à dire. La fonction publique n'est pas un employeur comme les autres.
[^] # Re: Compilateur sans bugs
Posté par claudex . Évalué à 5.
C'est pour ça que je disais ce qui me semblait normal d'un point de vue personnel et non un point vue objectif/légal.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Compilateur sans bugs
Posté par gasche . Évalué à 6.
Je voulais dire que la licence était un choix qui venait de l'auteur (avec lequel j'imagine que l'employeur est d'accord), et que le principe que les auteurs d'une œuvre puissent choisir la licence qu'ils souhaitent est un des tenants de base du logiciel libre. (C'était une remarque abstraite sans considérer le statut de l'auteur dans ce cas précis.)
La législation est assez compliquée sur la question de qui détient les droits quand un employé crée une œuvre. Par exemple le régime légal des journalistes précise explicitement qu'ils ont les droits d'auteur pleins sur les articles qu'ils écrivent (en contrepartie de leur salaire ils cèdent à leur employeur un droit d'exploitation temporaire). Le code de la propriété intellectuelle accorde les droits d'auteurs pleins aux auteurs d'une œuvre de l'esprit même quand ils sont salariés, sauf dans le cas du logiciel qui est une exception spécifique (à mon avis ça vient d'une vision industrielle de la programmation où les salariés sont des perçus comme des ouvriers interchangeables et non des créateurs). Le régime des fonctionnaires du public accorde automatiquement les droits d'exploitation à l'employeur, sauf dans le cas qui ne sont pas soumises "au contrôle hiérarchique"—donc pas dans le cas des enseignants et enseignants-chercheurs. Pour les chercheurs et enseignants-chercheurs, donc, les œuvres de l'esprit sont entièrement la propriété de l'employé, sauf le logiciel sur lequel la situation est peu claire, mais a priori l'auteur a les droits moraux et l'employeur les droits d'exploitation (automatiquement).
Dans le cas concret de Compcert, les headers de licences mentionnent clairement un "copyright INRIA", mais le choix de licence vient de l'auteur.
[^] # Re: Compilateur sans bugs
Posté par gasche . Évalué à 5.
Par ailleurs il faut faire une distinction entre ce que dit la loi et ce qui nous semble juste. Malheureusement ce n'est pas toujours la même chose.
Dans l'absolu je suis de l'avis qu'il faudrait toujours laisser aux auteurs le choix. Le fait qu'une entité utilise une relation de pouvoir pour imposer systématiquement des choix aux auteurs ne me semble pas juste. Par contre, le fait que le salaire vienne en contrepartie d'un droit d'exploitation semble juste (mais la question de savoir si ce droit d'exploitation est exclusif ou non est délicate).
Dans le cadre de la recherche malheureusement il y a des cas où des directives venant de l'employeur peuvent avoir un effet bénéfique à un moment donné. Par exemple l'INRIA demande depuis 2013 à ses chercheurs de mettre toutes leurs publications en libre accès sur la plateforme d'archivage HAL. Cela va à l'encontre du principe selon lequel chaque auteur devrait être libre de choisir le mode de diffusion de ses articles, mais c'est quand même une décision qui a eu un impact positif sur l'intérêt commun. Dans le cas des articles scientifiques il y a peu d'oppositions personnelles à la mise en libre-accès, c'est plutôt la flemme d'enregistrer un article dans une interface parfois lourde, et l'existence de demande de cession de droits tout à fait immorales venant des éditeurs scientifiques—on peut à la rigueur dire que cette demande entérine une position d'ensemble du code des chercheurs et enseignants-chercheurs et protège les chercheurs individuellement des pressions contraires des éditeurs.
Maintenant aurait-on intérêt à essayer d'obtenir des organismes de recherche des décisions fermes sur les licences des logiciels produites par leurs employé-e-s ? Bien sûr je serais content d'une directive imposant aux chercheu-r-se-s de produire du logiciel libre (mon opinion est que tout le logiciel produit par la recherche publique devrait être libre), mais ça me semble une pente très dangereuse, car rien ne garantit que l'année suivante, après le changement de gouvernement ou à la direction de l'organisme, on ne se retrouve pas avec une obligation de licence propriétaire et dépôt de brevet automatique (une idée tout à fait réaliste si on prend connaissance du guide de l'intelligence économique pour la recherche divulgué par le gouvernement, tout à fait hostile au logiciel libre).
Je pense donc qu'il est plus sûr et plus sage de laisser les chercheurs décider individuellement le régime de divulgation de leurs œuvres—en accord avec leur employeur.
[^] # Re: Compilateur sans bugs
Posté par claudex . Évalué à 5.
Je ne suis pas d'accord, l'auteur qui bosse dans le cadre de son emploi est influencé par tout ce qui gravite autour et qui va dirigé d'une manière ou d'une autre son travail. Sinon, il bosserait comme indépendant si ça n'avait pas d'influence et serait libre d'accorder une licence d'exploitation à qui il veut.
C'est valable pour toutes les décisions liées à la recherche. De là à dire que c'est très inefficace et très politisé…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Compilateur sans bugs
Posté par anaseto (site web personnel) . Évalué à 3.
Je suis assez d'accord : pour le citoyen externe au milieu, le fait que ce qui est produit par la recherche publique ne soit pas libre (et ça vaut aussi pour les publications) peut donner à juste titre l'impression qu'il paît de ses impôts des choses qui ne reviennent pas au citoyen, ou du moins pas de façon très transparente ou optimale. Après, je suis d'accord que les directives peuvent être dangereuses, et j'imagine aussi qu'il y a des cas où un raisonnement aussi simple n'est pas suffisant et d'autres cas où ça n'a pas vraiment d'importance. Personnellement, je trouve un peu que le cas de Compcert est un peu dans ce dernier cas pour le moment, car le public intéressé actuellement, comme airbus, ne me donne pas l'impression de trop s'intéresser au libre, malheureusement. Ceci dit, peut-être que plus de monde sera intéressé dans un certain nombre d'années et, alors, ça deviendra effectivement dommage.
[^] # Re: Compilateur sans bugs
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Qu'est ce que la recherche publique ?
Actuellement, dans les laboratoires universitaires, environ 20% du budget (hors salaire des fonctionnaires et des bourses ministères) sont des crédits récurrents. Ces 20% ne permettent même plus d'assurer une fonctionnement minimale (financement des locaux… Yep, on paye un loyer !). Donc 80% sont sur contrat donc c'est de l'argent que le chercheur se démène pour l'avoir (appel à projet, rapports intermédiaires, finaux, réunionite…). Une partie provient d'institution publique (Europe, ANR…) et une partie de boite privée (qui doivent en recevoir plus de l'état en parallèle), assez souvent il y a un mixte de plein de financement car on n'arrive pas toujours à tout financer sur un seul contrat…
Je suis pour la diffusion universelle MAIS il faut reconnaître que la concurrence est là. Les autres pays sont loin de mettre sur la table leur recherche publique et ne se gêne pas pour venir piocher chez nous (par exemple, il y a quelques années, on faisait venir des experts étrangers lors des comités d'évaluation AERES qui repartaient chez eux avec une feuille de route toute faite financé par le contribuable). Il y a des domaines, comme en SPI, ou la recherche publique est au service des français mais en ne mettant pas tout sur la table. Le contribuable s'y retrouve normalement via la bonne santé des entreprises !
Faut-il publier le code source du logiciel permettant de simuler la combustion des futures fusée Ariane VI ?
Il y a des principes et une réalité. Je n'ai pas d'avis complètement tranché. Je serais par contre plutôt partisan pour définir une charte pour les entreprises bénéficiant de la recherche publique (arrêter les paradis (et les bidouilles) fiscaux, salaire max dans l'entreprise à 20 fois le SMIC…). Déjà, rien que cela, ça pourrait être intéressant de voir ce que cela donne.
Des domaines très ouverts comme la mécanique quantique ne diffusent pas tout sur le coup. Par exemple, le CERN garde les données de manip quelques années avant diffusion le temps pour les chercheurs de trouver et publier. L'idéal publique est obligé de se contorsionner aux notions de concurrences et d'état nation dans nombre de cas…
[^] # Re: Compilateur sans bugs
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Désolé de tomber à plat… ce doit être l'âge du coup je tombe dans les clichés ;-) Ceci dis, faire un compilateur C non libre aujourd'hui, je ne suis pas sur que ce soit un choix très judicieux pour assurer sa diffusion… L'INRIA fait plein de truc super mais malheureusement, je n'ai pas l'impression d'en voir beaucoup sur les ordinateurs de mon laboratoire. D'ailleurs, en disant cela, je me demande s'il y aurait un 'grep' magique sous Debian qui pourrait nous donner ce genre de réponse ?
[^] # Re: Compilateur sans bugs
Posté par claudex . Évalué à 4.
https://codesearch.debian.net/results/inria/page_0 ? (Il faut sans doute affiner)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Compilateur sans bugs
Posté par gasche . Évalué à 2.
Chercher "Copyright.*inria" est assez efficace. Au total on trouve 58 paquets concernés, ce qui me semble assez impressionnant.
[^] # Re: Compilateur sans bugs
Posté par gasche . Évalué à 4.
En fait il faut faire Copryright.*(inria|INRIA), et là on a 210 paquets qui semblent pertinent. Par exemple
ocamlapparaît dans cette nouvelle recherche mais n'était pas inclus dans l'ancienne.[^] # Re: Compilateur sans bugs
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je vois Erlang et tout un tas de truc pas spécialement INRIA… Que l'INRIA participe est logique mais la plupart de ces paquetages ne sont pas portés par l'INRIA comme le sont OCaml et Scilab… Par exemple, David Tschumperlé, leader du projet Cimg/G’MIC travaille au GREYC, une UMR, et il est CNRS si mes souvenirs sont bons (http://opensource.graphics/about/).
[^] # Re: Compilateur sans bugs
Posté par gasche . Évalué à 2. Dernière modification le 04 mai 2015 à 17:43.
Il y a des faux positifs qui vienent du fait que, pour une raison que j'ignore, la DTD xhtml1-strict porte un copyright partagé contenant INRIA (j'imagine que des chercheurs ont participé à son élaboration):
C'est la seule chaîne avec INRIA dans le paquet
erlang, et c'est pareil pourmono(j'ai regardé indépendamment). Malheureusement je ne connais plus assez bien le langage de requête degrepmais je ne crois pas qu'on puisse facilement exclure les lignes qui contiennent aussi la chaîne "W3C" (si quelqu'un trouve je suis preneur).Si tu regardes les hits pour cimp tu vois que David Tschumperlé était membre de l'équipe Odysée à l'INRIA Sophia-Antipolis:
De toute façon je ne sais pas si distinguer les contributions INRIA et CNRS a vraiment du sens : ce sont deux instituts proches et leurs chercheurs collaborent très souvent (avec un certain nombre d'équipes mixtes etc). INRIA se veut peut-être un peu plus appliqué (donc statistiquement il est normal que les retombées logicielles soient "plutôt INRIA"), mais je ne connais peu de gens qui serait très heureux à l'INRIA et malheureux au CNRS ou inversement, plutôt qu'un choix c'est souvent que les gens vont là où ils trouvent un poste (en tout cas dans le contexte de recrutement actuel, c'était peut-être différent avant).
[^] # Re: Compilateur sans bugs
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Il y a des personnes du W3C à l'INRIA de Grenoble. J'en ai croisé un une fois en formation…
Si, le CNRS est beaucoup plus gros ;-) En fait, le CNRS est un EPST un peu particulier car il est fusionnel avec les universités. La recherche universitaire en France est assez particulière en cela. Cela me semble bien moins le cas de l'INRIA (que je connais pas super bien) où les chercheurs me semblent suivre une hiérarchie parfois plus proche du CEA (fonctionnement par projet piloté par le haut) que de l'autonomie quasi totale que l'on a à l'université (d'ailleurs, je ne sais pas si la majorité des chercheurs INRIA sont dans des unités propres ou sont disséminés dans des UMR comme les CNRS ?). Par ailleurs, beaucoup de personne au CNRS font du code mais dans des domaines pas du lié à l'informatique…
[^] # Re: Compilateur sans bugs
Posté par gasche . Évalué à 3.
P.S.: le travail de présentation et d'interaction avec le code source des paquets Debian sources.debian.net qui nous permet cette discussion a justement été développée et déployée par l'IRILL, un laboratoire (public) de recherche sur ce qui touche au logiciel libre et à la qualité logicielle. Aucun des auteurs originaux, Matthieu Caneill et Stefano Zacchiroli, n'est affilié INRIA (non pas que j'y attache une quelconque importance), mais l'institut co-finance l'IRILL.
# Verrou global
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Dans mes souvenirs qu'il y a quelques années, les développeurs d'OpenBSD avaient choisit que garder le verrou global, car mettre des verrous plus fins, en rendant le code plus complexe (et donc plus dur à auditer d'un point de vue sécurité) ne valait pas le coup dans leur optique de sécurité avant tout.
Qu'est ce qui a changé depuis ? Les problèmes de performances, avec la présence de multi-core dans la machine de Mme Michu, ont-ils rendu à présent le compromis intéressant ? Sont-ils plus nombreux pour pouvoir maintenant auditer un code plus complexe ? Ont-ils juste changé d'avis ?
[^] # Re: Verrou global
Posté par Stéphane Aulery (site web personnel) . Évalué à 5. Dernière modification le 03 mai 2015 à 12:53.
Le Big Kernel Lock a été introduit pour implémenter le SMP. Mais le SMP a besoin d’être amélioré et ça passe notamment par l'abandon du Big Kernel Lock au minimum pour ses mauvaises interactions avec les mutexes (Voir le compte-rendu de David Gwynne pour le n2k14 hackathon et celui de Martin Pieuchot pour le s2k15 Hackathon).
Quand j'ai écrit la dépêche, j’ai extrapolé — je ne sais plus pourquoi, mea culpa — sur l’élimination générale du Big Kernel Lock. L'objectif court terme est de s'en séparer dans les sous-systèmes réseaux et audio, et ainsi d'exploiter tous les processeurs pour le réseau et le son. Le problème de performance du réseau et de pf revient souvent.
Le userland, par contre, exploite déjà tous les processeurs.
Rétrospectivement cette discussion confirme mon extrapolation mais pas le délai.
SA
# SNI
Posté par Aris Adamantiadis (site web personnel) . Évalué à 4.
Ca me fait sourire :) (pour pas dire LOL).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.