dimanche 04 janvier
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Sortie d'OpenBSD 3.9

Posté par patrick_g (page perso, ). Modéré le 01 mai 2006.
0
Muguet rime avec sécurité. Réglé comme une horloge le projet OpenBSD annonce aujourd'hui, exactement six mois après la précédente, la sortie officielle de la version 3.9 de son OS.
Renommés pour leur quête inlassable de la sécurité et pour leur intransigeance envers la liberté et la propreté du code, les développeurs de ce système d'exploitation dérivé d'Unix nous proposent plusieurs évolutions fort intéressantes.

Les récents problèmes de financements du projet semblent également avoir conduit à un effort encore plus soutenu de communication et de promotion à destination du monde extérieur. On peut ainsi lire sur le net plusieurs articles et interviews intéressants qui permettent de se faire une idée plus juste des atouts particuliers de ce système.

NdM : Merci également à Landry Breuil et Louis Nyffenegger pour leur proposition d'article.

> Lire la suite (56 commentaires, moyenne: 4,6).   [dépêche : 3721 caractères]

Cette version met l'accent sur la lutte contre le blob (c'est d'ailleurs le thème de la chanson rituelle qui accompagne chaque sortie). Un blob c'est un pilote (ou une portion de pilote) qui n'est disponible que sous forme binaire. La différence avec un firmware binaire est que ce dernier tourne directement sur le périphérique (une souris USB par exemple) alors qu'un blob fonctionne sur le processeur principal de l'ordinateur, en espace noyau. Les blobs entraînent donc des graves problèmes de portabilité sur les différentes architectures, de correction des bugs ou de sécurité générale du système et c'est pourquoi ils sont bannis d'OpenBSD.

Sur le site KernelTrap on peut lire une interview de Jonathan Gray and Damien Bergamini sur leur travail d'écriture d'une version libre du driver des cartes ethernet Nvidia. Damien (qui est français) explique notamment que, dans la lutte contre le blob, OpenBSD est un peu esseulé :
Traduction libre : "Nous ne voulons pas de ces blobs dans notre système parce que nous ne pouvons pas les maintenir nous mêmes. Aujourd'hui les blobs surgissent partout (le dernier qui me vient à l'esprit est le démon Linux binaire pour la carte Intel PRO/Wireless 3945ABG). Malheureusement cela ne va pas s'arrêter car plusieurs systèmes, réputés open-source, ont laissé tomber et décidé d'accepter ces blobs" (c'est moi qui souligne).
L'interview fleuve que le site ONLamp a réalisé à l'occasion de la sortie de la version 3.9 évoque également cette bataille cruciale contre les drivers binaires :
Traduction libre : "Certaines personnes on fait ce qui est de plus en plus commun chez FreeBSD, ils ont inclus un driver qui n'est en fait qu'un code "glue" qui entoure un blob binaire. Ils ont même eu une licence spécifique à FreeBSD pour le distribuer. C'est un scénario terrifiant que nous n'avons jamais envisagé de suivre dans OpenBSD".

Du coté des nouveautés techniques de la 3.9 on peut signaler l'interface unifiée de gestion des capteurs (température, ventilateurs, courant...etc) qui simplifie beaucoup l'obtention d'informations sur l'état des machines. Également le port vers les Mac G5, l'amélioration (par le français Marc Espie) des outils pkg_add et pkg_delete, l'audit complet du source pour traquer les usages fautifs de la macro queue(3), l'amélioration profonde du démon hostapd qui permet la communication entre les points d'accès wifi, l'introduction de l'outil sdiff de comparaison visuelle de deux fichiers afin de faciliter la gestion des configurations en cas d'upgrade du logiciel, le démon apmd pour faire varier la vitesse du processeur en fonction de la charge et beaucoup, beaucoup d'autres choses.

Dans les versions futures (qui sont évoquées à la fin de cet article) les développeurs vont travailler sur le support de l'ACPI (pour les portables) et des cartes RAID (pour les serveurs). La version multiprocesseur de l'OS va également faire l'objet d'efforts particuliers.

Pour ses qualités techniques propres comme pour son combat opiniâtre pour la liberté du code, le projet OpenBSD mérite donc votre attention et votre soutien. Vous pouvez acheter le CD de la version 3.9, épater votre copine de geek en portant un T-shirt de grande classe ou bien plus directement faire un don.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Les blobs c'est l'amoco cadiz !

Posté par Christophe Garault (page perso, ) le 01/05/2006 à 13:28. (lien). Évalué à 10.

Vous avez remarqué ce pauvre Tux tout englué de mazout?

http://www.openbsd.org/lyrics.html

C'est vraiment dommage que ce projet soit si seul à lutter contre la propriétarisation des drivers. Mais on en revient inlassablement à cette lancinante question: "vaut-il mieux céder une part de sa liberté en échange de fonctionnalités accrues, ou rester 100% libre quitte à baver d'envie devant ce que permettent les drivers proprios?"
Certains ont des réponses absolues et je les envie...

Linux

Posté par Matthieu C () le 01/05/2006 à 13:32. (lien). Évalué à 10.

Malheureusement cela ne va pas s'arrêter car plusieurs systèmes, réputés open-source, ont laissé tomber et décidé d'accepter ces blobs" (c'est moi qui souligne).
N'est-ce pas plutôt les utilisateurs qui ont laissés tombés ?

Dans le cas de Linux, aucun blob n'est supporté par les développeur de kernel.org, au contraire si certaines parties sont détectées comme servant à charger un blob, elles sont ejecté (c'est ce qui à été fait dans le cas du driver pwc).

De même sous Linux, certains blob sont RE (reverse engineering) comme par exemple le driver ethernet de nvidia (qui au passage à servi de specification pour écrire le driver openbsd) ou encore le driver wifi broadcom, pour pouvoir être intégré dans la branche principale.

Certains développeurs en sont même à mettre du export_gpl partout.


Par contre certaines distributions sous la pression des utilisateurs se mettent à fournir des drivers proprio au lieu d'encourager leur clients à choisir des solutions supportant/compatible avec le libre ou de convaincre les constructeurs de libérer leur spécifications/drivers.

des efforts "dipomatiques" ont-il été faits pour la libération des spéc?

Posté par padawan () le 01/05/2006 à 16:07. (lien). Évalué à 3.

il est vrai que c'est peut-être un peu à cause des utilisateurs que certains "trahissent" et blobent leur distribution. Cependant, je n'ai pas l'impression que des efforts diplomatiques ont été fait pour la libération des spécifications des différents matériels, ou du moins ça n'a pas été médiatisé sur les médias du libre.
Certains comme RMS ou Theo DeRaad ont des discours assez virulent envers tout ce qui est propriétaire (RMS ayant récemment dit que les catholiques - lui est athé - devraient considérer les logiciels propriétaires comme diaboliques ... je suis pro-libre mais de là à penser ça !!!).

Bien que les drivers n'aient (amha) aucun rapport avec les logiciels (on a quand même le droit de faire tout ce qui est moral et/ou légal avec un objet palpable qu'on a acheté, non ?) et que les spécifications devraient être totalement libre, je pense qu'il faut de temps en temps modérer un peu les discours, essayer de discuter calmement et faire le possible pour convaincre objectivement nos interlocuteurs. Il ne faut pas oublier que les fabricants ont presque toujours fait du propriétaire et qu'ils sont sous la pression de leur concurrents, il faut les rassurer, leur faire comprendre qu'il n'y a réellement aucun risque à publier leurs spécifications ou alors que le risque est acceptable étant donné la possibilité d'avoir de nouveaux clients, de jouir de plus de publicité et d'avoir de nouveaux développeurs pour gratis qui les aideront dans leur quête du pilote le plus parfait et performant. Il faut leur montrer que la publication des spécification n'a pas lésé certains de leurs concurrents qui ont franchi le pas.
Car finalement, un discours dur entraine au mieux un renfermement défensif au pire un entêtement qui risque de faire disparaître à tout jamais l'éventualité d'un publication des spécifications matérielles.

Je pense aussi qu'une seule main ne peut pas applaudir, ne serait-il pas temps que les differents acteurs du libre fasse la paix, oublient leur différends, se rappellent de ce qui les unie et se réunissent autour d'une fondation ou d'une alliance pour mettre au point un programme commun pour la liberté logicielle pour faire entendre leur voix et monter leur nombre et leur force pour être considérés comme un interlocuteur digne de respect ?
dans chaque parti il y a des courants de pensée mais la philosophie motrice reste la même.

Est-ce que quelqu'un a des informations sur des efforts qui ont été faits dans ce sens svp ?

merci

________
zisis note e troll !

Et l'EFI?

Posté par paco69 () le 01/05/2006 à 16:53. (lien). Évalué à 7.

Bonjour à tous,

Croyez vous que l'EFI (Extensible Firmware Interface) peut arranger tous les problèmes de drivers? ou du moins une grande partie des drivers?

Rebondissement

Posté par Bertrand Jacquin (Jabber id, page perso, ) le 01/05/2006 à 16:53. (lien). Évalué à 4.

Je voulais faire just un rebondissement par rapport à ces blobs et aux drivers proprio (sous Linux, xBSD et autres).

Aujourd'hui, quel constructeur permet d'utiliser une carte vidéo sans pilotes propio ? Ou du moins quels sont les cartes bien supportées ? Avec un minimum de 3d.

J'ai recemment acheté une carte vidéo ATI x800 en PCI Express pour l'utiliser sur un AMD64. Et c'est la croix et la bannière pour la faire fonctionner.

Les drivers de Xorg ne me permettent pas l'utiliser avec une résolution supérieur a 640x480 (C'est pas franchement terrible). Avec les pilotes proprio, je ne peux que l'utiliser avec Xorg 6.8.2 (pas avec le X modulaire) et marche mal avec le kernel >= 2.6.15.

Voila, ce que j'attend c'est une carte qui marche mais aujourd'hui a part du Nvidia ou ATI, le paysage est pas tellement diversifié. Et google non plus remarqué.

Je suis pour l'utilisation de pilotes libres sans blobs mais est-ce que c'est possible ? Quel carte fonctionne bien avec des pilotes libre ?

Autres nouveautés

Posté par herodiade () le 01/05/2006 à 22:36. (lien). Évalué à 10.

Quelques autres nouveautés qui m'ont interpellé dans cette version, pour compléter un peu la dépêche:

- support ipv6 dans ppp (enfin !!!)
- trunk (interfaces agregees) supporte maintenant le failover et roulent bien avec carp et pfsync.
- support des cartes ethernet 10Gbps LS/SR et CX4 intel (ixgb(4), et peut etre
des gigabits Sun).
- refactoring complet et nombreuses ameliorations de lint et xlint (puis correction de nombreux petits bugs potentiel sur l'ensemble du systeme, grace à ce nouveau lint).
- ré-audit des sources à la recherche d' "int overflows" (et adoption de mesures préventives contre les trucs vicieux, comme le vilain malloc(x*y)).
- ports: update de gettext en 0.14.5 (il n'etait plus updaté depuis des années !)
- les sont libs compilees par defaut avec -g, les binaires linkes avec -X
- correction de l'implementation de W^X d'après les commentaires de Julien Tinnes, suite à son article dans le magazine misc: http://marc.theaimsgroup.com/?l=openbsd-cvs&m=1137105999(...)
- log (user) dans pf.conf: permet de logguer l'uid/gid du process de la socket (visibles par ex sur tcpdump -i pflog0).

Ayé

Posté par gnumdk (page perso, ) le 01/05/2006 à 22:53. (lien). Évalué à 2.

Voila, rentré de week end, mise à jour terminée :)

J'ai juste un petit probleme avec pfstat qui refuse de s'installer, on dirait que les packages sont pas encore vraiment prets... Une idée?

# pkg_add pfstat
Can't install gd-2.0.33p2: lib not found fontconfig.3.0
Even by looking in the dependency tree:
jpeg-6bp3, png-1.2.8, libiconv-1.9.2p3
Maybe it's in a dependent package, but not tagged with @lib ?
(check with pkg_info -K -L)
If you are still running 3.6 packages, update them.
Can't install gd-2.0.33p2: lib not found freetype.13.1
Can't install pfstat-1.7p1: can't resolve gd-2.0.33p2

Et effectivement, pas de fontconfig.3.0 sur les serveurs, et des versions de paquets différents...

Où sont les blobs ?

Posté par cbon linux (page perso, ) le 10/05/2006 à 10:20. (lien). Évalué à 0.

salut,

j'ai installé Debian, y a des blobs dessus ? Ca me génerait. (on voit là l'avantage de OpenBSD que je connais mal et qui a une licence chelou non gpl).

Quels sont ces blobs existants aujourd'hui ?

Solutions aux blobs par niveau de gravité :
1* N'est-il pas possible pour les hackers (ceux qui touchent grave à l'informatique) de coder des drivers gpl pour remplacer ces blobs ?
2* Et sinon, n'est-il pas possible de demander à la boite qui fait ce hardware blobien de sortir des drivers gpl et de les inclure dans el kernelo del linuxo olé ?
3* Et encore sinon, ba il faudrait que les gens achètent que du "bon hardware qui a des drivers gpl et toc" ? (moi j'achète mes légumes bio).

Merci

--
blog

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.2185s (dont 0.0425 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !