jeudi 10 avril
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | O'Reilly | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Liens connexes

Dépêche modérée par

Dépêche éditée par

BSD : Sortie de FreeBSD 7.0 et 6.3

Posté par Bapt (page perso, ). Modéré le 28 février 2008.
FreeBSD
Deux nouvelles versions de FreeBSD viennent de sortir pour ce début d'année: la version 6.3 et la toute nouvelle version 7.0.
La version 6.3 sortie le 18 janvier est la dernière version de maintenance de la branche RELENG_6, cette mise à jour concerne :
  • Correctifs de sécurité (bind, libarchive, random, openssl et libc)
  • Amélioration de l'ACPI,
  • Ajout de nombreux pilotes,
  • Amélioration de freebsd-update qui permet maintenant, en plus des mises à jours de sécurité, de faire des montées de version.
  • Réimplémentation de unionfs
Mais l'actualité majeure concerne la version 7.0 : en effet c'est la première version stable de la branche RELENG_7 qui apporte beaucoup de nouveautés. Parmi les fonctionnalités majeures apportées par cette version on peut noter :
  • Amélioration du support des portables,
  • Prise en charge de ZFS,
  • Passage à GCC-4.2,
  • Poursuite de la suppression du « Giant Lock »,
  • Virtualisation complète de la pile réseau,
  • Stabilisation et amélioration de l'ordonnanceur de processus « SCHED_ULE »,
  • Gestion de la journalisation pour UFS,
  • libthr devient la bibliothèque de gestions des threads par défaut.
NdM : Merci à FRLinux d'avoir également proposé une dépêche.

> Lire la dépêche (90 commentaires, moyenne: 4,2).  

Après une très longue phase Beta/RC qui a permis de mettre et de corriger de très nombreux bugs, et plusieurs mois de retard, la très attendue version 7.0 vient de sortir. Beaucoup de développements à tous les niveaux :

Noyau et Espace Utilisateur
ZFS(1M) est le système de fichiers « révolutionnaire » de Sun. Le port de ZFS sous FreeBSD, bien que considéré comme expérimental, est parfaitement fonctionnel, dotant ainsi le système d'un nouveau système de fichiers moderne très complet. FreeBSD est le second système d'exploitation libre à bénéficier du support pour ce système de fichier en natif (le premier étant OpenSolaris). La licence CDDL ne permettant pas l'inclusion dans le noyau, ZFS est donc disponible sous la forme de module, mais il peut quand même être utilisé pour la partition système. À noter que son support est considéré comme expérimental et qu'il n'est pas recommandé de l'utiliser sur des machines de production.
Après reiserfs(5), xfs est le second système de fichiers « exotique » Linux a être implémenté en lecture seule sous FreeBSD. Étant sous licence GPL, il est incompatible avec une inclusion directe dans le noyau, le support est donc disponible sous la forme d'un module.
tmpfs a été développé initialement sous NetBSD à l'occasion du Google Summer of Code, celui-ci a ensuite été porté sous FreeBSD.
Le système de fichiers UFS profite d'une nouveauté basée sur l'infrastructure de stockage GEOM. En effet FreeBSD 7.0 introduit l'outil gjournal qui offre enfin la journalisation au système de fichier UFS ainsi que potentiellement à n'importe quel Système de fichier tirant parti de l'infrastructure GEOM. Gjournal ne remplace par les softupdates mais propose une alternative, il permet entre autre d'éviter de devoir faire une vérification du système de fichiers en tâche de fond après un incident.
L'ordonnanceur SCHED_ULE à été complètement revu, il est désormais beaucoup plus stable et plus réactif, en particulier quand le système est fortement chargé. Il fournit des performances nettement supérieures sur les systèmes multiprocesseurs mais aussi sur les système uniprocesseurs, et deviendra l'ordonnanceur par défaut pour la prochaine version de FreeBSD (7.1).
Le linuxulator permet désormais d'émuler certaines fonctions du noyau linux 2.6.16. Cette fonctionnalité n'est pas encore présente par défaut, mais peut être activée par sysctl(8) : compat.linux.osrelease=2.6.16. Actuellement la compatibilité par défaut reste basée sur l'émulation de Linux 2.4.2.
La majorité des composants importants sont désormais libres de "Giant Lock", plusieurs processus peuvent donc exécuter du code kernel sur plusieurs processeurs simultanément. La majorité des pilotes (notamment cartes réseaux et contrôleurs de disques) ainsi que les systèmes de fichiers virtuels basés sur pseudofs (procfs, linprocfs et linsysfs) sont concernés.
La commande freebsd-update permettait jusque là de faire les mises à jours de sécurité relatives au noyau et à l'espace utilisateur de manière binaire. Désormais, elle permet aussi via l'option upgrade de faire des montées de version (en choisissant la release de destination avec l'option -r).
Le but à terme est de recoder la totalité des GNU binutils sous license BSD afin de tirer profit de libelf. C'est le projet « ElfToolChain » qui s'appuie sur libarchive et libelf.
libthr est une implémentation 1:1 des threads POSIX, apportant un gain de rapidité conséquent pour toutes les applications utilisant des threads (notamment MySQL) par rapport à l'implémentation précédente en N:M. Un comparatif des performances entre les différentes versions de FreeBSD ainsi qu'avec d'autres systèmes d'exploitations est disponible avec de nombreuses explications techniques.
Le code permettant d'agréger des interfaces réseaux pour augmenter le débit et améliorer la tolérance aux pannes a été intégré à FreeBSD 7.0. Cet outil trunk a été importé directement du système d'exploitation OpenBSD.
Toujours dans le domaine des réseaux il est maintenant possible d'utiliser certaines cartes accélératrices de type TSO (TCP/IP segmentation offload) et LRO (Large Receive Offload) au lieu de faire ces opérations uniquement avec le processeur central.
L'architecture Alpha a été abandonnée dans branche RELENG_7 et CURRENT, en revanche le support continue pour les branches RELENG_5 et RELENG_6

Merci à tout ceux qui ont contribué à la rédaction de cet article sur le wiki et merci à baud123 pour son wiki.

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.

Interressant

Posté par reno () le 28/02/2008 à 13:54. (lien). Évalué à 3.

Le passage du threading M:N au 1:1 par défaut est similaire a celui qui a été fait par Linux.

Sinon, l'interview m'a rendu curieux à propos de SCTP que je ne connaissais pas, et c'est vrai que ce "super-TCP" a l'air interressant..

Pas pu attendre vendredi....

Posté par patrick_g (page perso, ) le 28/02/2008 à 14:01. (lien). Évalué à 10.

Je voudrai réagir aux propos d'un des développeurs FreeBSD dans l'interview géante d'ONLamp.
Un certain Warner Losh est employé par sa boite pour bosser sur la problématique de l'embarqué (plus spécifiquement la compatibilité avec les processeurs ARM ou MIPS) et il dit ceci (traduction perso) :
"La montée en puissance de FreeBSD dans le monde de l'embarqué se poursuivra. L'application de plus en plus agressive de la GPL par le Software Freedom Law Center et d'autres a créé une demande pour des logiciels avec une licence qu'il est plus facile de respecter".

Je dois dire que j'ai été choqué quand j'ai lu cette déclaration.
La GPL est souvent violée par les vendeurs de matériel embarqué et la liberté des utilisateurs est foulée aux pieds. Le Software Freedom Law Center se bat pour le respect de la licence et pour que la liberté des utilisateurs de logiciels libres ne soit pas anéantie par des firmes prédatrices.
Et que dit ce monsieur Losh ? Que ce combat pour le respect de la GPL et pour la liberté des utilisateurs est une opportunité pour FreeBSD !
Les firmes voulant nier la liberté de l'utilisateur (en lui vendant un matériel sans donner le code et donc en empêchant le partage) vont se tourner vers FreeBSD. Avant elles violaient tranquillement la GPL mais le combat opiniatre du Software Freedom Law Center a rendu cela difficile et cela ouvre un boulevard pour FreeBSD.
Warner Losh est donc parfaitement conscient que son travail sur l'embarqué est destiné quasi-exclusivement à des firmes non éthiques. Il est parfaitement conscient que le matériel vendu par ces firmes sera une "boite noire" et que l'utilisateur sera verouillé, enfermé, sans possibilité de lire ou de partager le code.
Mais il s'en fout. Tout ce qu'il voit c'est qu'il est payé pour faire ça et tant pis pour les autres. Tout ce qu'il voit c'est que la lutte pour le respect de la liberté de l'utilisateur a "créé une demande" pour FreeBSD dont il peut profiter.

PS : Ce post évoque juste une déclaration d'un dev dans une interview et il n'a rien à voir avec la qualité de FreeBSD. Ce n'est pas une attaque contre cet OS. Je l'ai installé la semaine dernière sur mon second laptop, juste pour voir, et ça à l'air très bien (mais j'ai pas de son pour l'instant). Merci donc de ne pas m'accuser d'être un anti-BSD fanatique.

Performances réseaux

Posté par Victor STINNER (page perso, ) le 28/02/2008 à 15:35. (lien). Évalué à 6.

Dans l'interview ONLamp, on peut lire :
« It seems network performance is much better in 7.0!

Andre Oppermann: In general it can be said that the FreeBSD 7.0 TCP stack is three to five times faster (either in increased speed where not maxed out, or reduced CPU usage). It is no problem to fill either 1 Gb/s or 10 Gb/s links to the max. »

Interview :
http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-free(...)

Le nouveau scheduler de processus (ULE) et le nouvel allocateur de mémoire montre d'excellentes performances sur des machines multi-processeurs (ce qui sera de plus en plus courant). Petit article que j'ai écrit sur les allocateurs mémoires :
http://www.haypocalc.com/blog/index.php/2007/11/08/87-gestio(...)

gcc 4.2.1

Posté par zul (Jabber id, page perso, ) le 28/02/2008 à 16:01. (lien). Évalué à 8.

A propos de gcc 4.2, j'ai deux questions (pour lesquelles tu ne pourra pas forcement repondre).

- Intégration de OpenMP facile dans FreeBSD ?
- Intégration de code sous GPLv3 n'a t il pas posé des problèmes légaux dans FreeBSD? ou du moins suscités des questions ? Je demande ça parce que pour le projet NetBSD, ca a pas l'air si evident que ça. On a fait appel à des avocats spécialisés sur ce genre de question, et de nombreux utilisateurs / développeurs continuent à se poser des questions sur la viabilité de la chose ? (en particulier dans l'embarqué).

(oui NetBSD, c'est un vrai méchant projet plein de barbus qui aiment pas le libre, bien sûr).

GPL

Posté par ciol () le 28/02/2008 à 19:08. (lien). Évalué à 1.

Étant sous licence GPL, il est incompatible avec une inclusion directe dans le noyau

Pourquoi ?

TSO et LRO

Posté par Brice Goglin () le 28/02/2008 à 23:42. (lien). Évalué à 3.

> Toujours dans le domaine des réseaux il est maintenant possible
> d'utiliser certaines cartes accélératrices de type TSO (TCP/IP
> segmentation offload) et LRO (Large Receive Offload) au lieu de
> faire ces opérations uniquement avec le processeur central.

Cartes accélératrices est très abusé là...

TSO c'est juste découper un gros paquet à envoyer en plusieurs MTU et être capable d'ajuster quelques headers genre le numéro de séquence. Pas de quoi casser 3 pattes à un canard. Toutes les cartes modernes dignes de ce nom savent le faire.

LRO, c'est une autre histoire. Il n'a d'Offload que son nom. Agréger des paquets en réception implique de connaître l'état de toutes les connexions. C'est impossible dans les cartes réseau pour des raisons de ressources mémoire, de puissance et synchro avec l'hôte. Toutes les implémentations actuelles de LRO sont logicielles. C'est la pile basse de réception (au niveau des drivers) qui agrège des paquets avant de les passer à la pile haute (genre TCP) pour réduire les coûts. Mais on sait très bien faire ça sans assistance d'une carte "accélératrice". La plupart des drivers Linux qui font du LRO le font purement logiciellement.

Le seul point sur lequel les cartes peuvent aider le LRO, c'est le header-splitting qui consiste à déposer les headers et données en des endroits séparés en mémoire pour faciliter l'agrégation LRO au dessus. Certaines cartes savent faire ça (Neterion notamment), mais beaucoup de drivers n'en ont pas besoin pour avoir du LRO très performant (Myri-10G et eHEA notamment).