Journal La release de FreeBSD 5.3 est-elle une bonne cuvée ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
21
déc.
2004
Selon : http://www.newsforge.com/print.pl?sid=04/12/14/1518217(...) il semble bien que non.

Sans revenir sur les problèmes initiaux de choix techniques (ayant conduit au fork de DragonflyBSD) il apparaît que l'implémentation et la stabilité de cette release 5.3 (sensée être Production ready) est loin d'être optimale.
Le nouveau scheduler ULE n'est toujours pas activé alors que c'est une des grandes nouveautés des 5.x. Il existe plusieurs problèmes avec les réseaux Gigabit et l'hyperthreading. Sur les AMD64 avec plus de 4Go de mémoire le système n'est pas très stable.
L'auteur de l'article semble vraiment déçu et la liste des améliorations depuis le 5.2.1 est vraiment pitoyable : ce ne sont quasiment que des améliorations de logiciels tiers !
(GCC is now at 3.4.2, Binutils at 2.15, and GDB at 6.1. Also, X.org has been upgraded to 6.7, GNOME to 2.6.2 and KDE to 3.3.0).

La conclusion de l'article est particulièrement sévère :

A mediocre release

While the FreeBSD team seems to have accomplished some of its goals for 5-STABLE, they have also introduced a number of critical bugs. Where FreeBSD used to be a highly usable, reliable, and scalable operating system, the last three releases have been increasingly substandard, culminating in a hardly usable operating system on our test machines. The FreeBSD development team has a tradition of writing good code and maintaining a high-quality operating system. Unfortunately, FreeBSD 5.3-RELEASE lends little credence to that reputation.
  • # Ouaip

    Posté par  . Évalué à 7.

    C'est triste a dire mais je suis d'accord :-/

    J'ai du abandonner FreeBSD entre 5.1 (-CURRENT cependant) et j'y suis revennu a 5.3 et pour moi le système a clairement regressé (au revoir ULE...).

    La reactivité est à des années lumière de linux, toujours des problèmes de locking qui trainent un peu partout, son qui saccade en monté en charge etc. C'est domage 5- était prometeuse... Il y a 18 mois. Maintenant ca semble être un branche morte qui a trop attendu apres les testeurs, elle n'a plus grand chose d'inovante par rapport à ses concurents.

    Reste beaucoup de fonctionalités interessantes, entachees par un amère gout de "pas fini".
    • [^] # Re: Ouaip

      Posté par  (site web personnel) . Évalué à 5.

      tu crois en DragonFlyBSD ou pas ?
      perso je pense que NetBSD (pour la portabilité) et OpenBSD (pour la sécurité) ont encore un grand et bel avenir...mais pour FreeBSD je pense que Linux va vraiment le tuer sur le créneau des OS généralistes (modulo le fait que le libre ne meurt pas toussa...mais bon la diffusion va VRAIMENT faire pale figure par rapport aux distros Linux).
      • [^] # Re: Ouaip

        Posté par  . Évalué à 4.

        D'un point de vu technique j'ai vu qu'ils avaient fait de jolies choses après je n'ai pas testé.

        Il faut aussi garder à l'esprit que Dragonfly a pour le moment l'avantage d'avoir une base d'utilisateurs très réduite ce qui permet de developper plus de fonctionalités en passant moins de temps sur le QA. Si tu regardes linux semble aussi vouloir résoudre le problème en laissant la stabilisation aux distribs puis remonté des patchs en upstream.

        Mais chez FreeBSD on gère la stabilisation en interne et c'est clairement ce qui a tué la 5.3. Annoncée comme prometeuse il y a longtemps, elle devient decevante, sortie trop tardive ou pas assez parfaite. 8 mois entre 5.2.1 et 5.3 pour quel résultat du point de vu utilisateur ?


        Attendons de voir si le changement de release engineering pourra faire sortir FreeBSD d'une trajectoire qui semble allez droit dans le mur tellement linux place la barre haut pour s'assurer une survie. Après c'est utilisable ce message est écrit depuis FreeBSD mais sans cette impression de peut mieux faire ca sera formidable :-)
    • [^] # Re: Ouaip

      Posté par  . Évalué à 4.

      -> La reactivité est à des années lumière de linux

      Dans quel sens? je pense dans le sens "FreeBSD plus réactif que Linux", mais je n'en suis pas sûr. J'avais testé FreeBSD il y a un an (une 4.9 je crois, en tout cas c'était la branche 4 à coup sûr) et il est vrai que le système me paraissait plus rapide par rapport à ce qu'il était sous Linux. Mais j'ai pas eu le temps de me plonger vraiment dans cette distrib (sur mon PC pro, je me vois mal passer plusieurs jours à configurer/maitriser le système avant d'être efficace dessus), je suis donc repassé sous Slackware.

      -> des problèmes de locking qui trainent un peu partout

      C'est quoi un problème de locking?
      • [^] # Re: Ouaip

        Posté par  . Évalué à 5.

        > Dans quel sens?

        Dans le sens que le système est moins reactif et qu'il bloque plus souvent les mauvais process. Ce n'est pas rare de voir que ton terminal patine pendant quelques dixièmes de seconde, C'etait excusable y'a quelques années maintenant ca fait plus tache :-)

        De même la technique de swapping de FreeBSD pour les WS je la trouve bof, pour les serveurs ca se discute plus.

        > C'est quoi un problème de locking?

        FreeBSD a pris la direction de faire du verouillage fin. C'est utile pour le multi-processeur. Deux CPUs ne doivent pas toucher à la même structure de donnée en même temps, autrement tes informations vont etre dans etat inchorent.

        FreeBSD 4 appliquait un "Giant locking" c'est a dire qu'il n'y a qu'une condition de verouillage, tu prends ton verrou en rentrant dans la routine et tu le relaches à la fin. C'est simple mais peu performant si tu fais monter le nombre de processeur.

        FreeBSD a choisi de multiplier les conditions de locking, tu peux ne verouiller que ce que tu as besoin. C'est mieux en perf mais c'est plus casse geule. Et FreeBSD essuis encore un peu les platres de ce choix.
        • [^] # Re: Ouaip

          Posté par  (site web personnel) . Évalué à 2.

          Normalement, la conséquence c'est qu'il supporte mieux la montée en charge sur des systeme multi-processeur avec des vérouillage + fins.
        • [^] # Re: Ouaip

          Posté par  . Évalué à 8.

          FreeBSD a choisi de multiplier les conditions de locking, tu peux ne verouiller que ce que tu as besoin. C'est mieux en perf mais c'est plus casse geule. Et FreeBSD essuis encore un peu les platres de ce choix.
          Pour le moment, FreeBSD 5.x/6-CURRENT n'est pas giant free. Seule la pile reseau l'est (enfin presque partout) et la VM l'est sous -CURRENT only (cf debug.mpsafenet et debug.mpsafevm). Ce qui est peu pour assurer des perfs "convenables".
          Actuellement, les efforts se portent principalement sur la -CURRENT. Les patches de jeffr pour un Giant-free VFS ou le phk_bufwork sont prometteurs.

          Pour en revenir a "la chute de FreeBSD", tout s'est fait rapidement en fait. Beaucoup de nouveautes sont apparues tardivement, a cause de la sacro-sainte (chez FreeBSD) conservation ABI/API, juste avant le (vrai) features freeze. Ce qui a fait que pendant les 3 derniers mois, le bugtracking a ete ardu. Le timing d'intregration a parfois ete fatal: integration SMPng + KSE en meme temps, merge de la branche netperf, gcc 3.4 qui a paralyse le ports tree, le support TLS, etc...
          Tout ca s'est fait dans la plus grande precipitation. C'est pour cela aussi qu'il y a eu un changement dans le cycle des releases : eviter le plus possible ce genre de problemes, en laissant les nouvelles features pourrir le moins longtemps possible.

          Aujourd'hui FreeBSD 5.x souffre du syndrome FreeBSD 3.x. Note positive, FreeBSD commence a s'ouvrir vers de nouveaux horizons au lieu de se confiner dans ses certitudes (cf wishlist de scottl http://lists.freebsd.org/pipermail/freebsd-hackers/2004-December/00(...) ).

          FreeBSD 5.x a bcp d'avantages, on arrive a en tirer des choses pas mal comme serveur, il ne faut pas tout jeter qd meme, mais elle decoit un peu. N'ayons pas peur d'esperer un retour a la normale prochainement ;-)

Suivre le flux des commentaires

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