Journal FreeBSD 6.2 beta1

Posté par  (site web personnel) .
Étiquettes :
0
28
sept.
2006
Le 21 septembre est sortie la première version beta de FreeBSD 6.2, au menu :
- Ajout d'un driver linsysfs : permettant d'émuler le /sys de linux afin d'améliorer le linuxulator (emulation linux)
- import de csup : utilitaire permettant de remplacer cvsup, il est écrit en C, et ne permet que de faire de checkout, très pratique pour mettre à jour les sources, la doc et les ports de son FreeBSD
- import de freebsd-update : un utilitaire permettant de mettre à jour par patch binaires le kernel et le userland de FreeBSD : correctifs de sécurité, montée de version. freebsd-update est un google summer of code visant à améliorer l'utilitaire freebsd-update disponible dans le ports.

Les habituelles mises à jours de logiciels userland.

A noter aussi de très nombreuses amélioration du linuxulator (un autre SoC) :
- l'environnement par défaut à sauté de RH8 vers Fedora Core 4,
- mise à jour des appels kernel (syscall - je sais pas comment traduire) disponible vers ceux d'un noyau linux 2.6.16 (pas encore complet).

Les notes de version : http://www.freebsd.org/relnotes/6-STABLE/relnotes/i386/new.h(...)
L'annonce : http://lists.freebsd.org/pipermail/freebsd-stable/2006-Septe(...)
  • # Merci ...

    Posté par  . Évalué à 5.

    D'avoir posté un journal intéressant ...
    Sinon syscall => appel système.
    • [^] # Re: Merci ...

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

      De rien :)
      sinon syscall=>appel système, tout bêtement, c'est marrant comme on ne voit pas les choses les plus simple :)
  • # Mouaif....

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

    C'est pas pour troller mais quand on compare avec les releases note de Linux on se rend bien compte du différentiel de rapidité de développement. C'est plus que flagrant, presque choquant.

    Cette version FreeBSD 6.2 apporte quoi ?
    Ils mettent surtout l'accent sur la compatibilité avec Linux => c'est bien mais ce n'est pas une qualité propre pouvant faire la différence !
    Le reste c'est des détails, des montées de version en userland et des corrections de bugs.

    Je sais, je sais : la 6.2 est amélioration incrémentale et le vrai boulot se fait dans la branche 7 mais bon....Linux offre tous les deux ou trois mois des avancées importantes ! Et avec la stabilité ! (ce qui n'a pas été le cas de la branche 5.x de FreeBSD).

    Conclusion : FreeBSD n'est pas compétitif avec Linux. OpenBSD l'est car il se concentre sur une niche (la sécurité) et il le fait bien. FreeBSD n'a pas de niche, l'intention c'est de faire un OS généraliste comme Linux...ben dommage pour eux mais l'écart grandit mois après mois.
    • [^] # Re: Mouaif....

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

      Oh il est beau celui-là, tant pis je marche dedans...

      La grosse différence entre le développement de FreeBSD et de Linux, c'est que tout les commits ne sont pas mis dans le relnotes, seules les parties visible (intéressante) donc forcément le relnotes est moins important que celui de linux. Le nombre de développeurs est quand à lui aussi beaucoup moins important, ce qui expluique peut être aussi moins de code produit.
      Maintenant j'utilise FreeBSD au quotidien, et tout mon matos est reconnu, aucun soucis de ce côté là, les évolutions sont douces et suivent le marché (peut être un tout petit peu moins vite que Linux mais quand même) ce qui me convient très bien, pas de mauvaise surprise à l'update du genre oups j'ai mis à jour mon kernel, mais udev ne marche plus.
      Les API ne sont pas cassées tous les 4 matins (j'ai dit que je marchais dans le troll) ne nécessitant par de recoder tout ou parti des drivers dépendant (donc moins de code nécessaire).
      Quand une techno rentre dans le kernel, elle y reste pour un moment, car elle est mûrement réfléchit et codée en conséquence (API comprise) donc pas besoin de la modifier régulièrement : exemple devfs fait très bien sont boulot et les modifs sont mineurs comparées à celle de udev qui sont cassées régulièrement (devfs et udev sont userland et hors kernel, mais très dépendantes du kernel).

      Je connais Linux depuis bien plus longtemps (et beaucoup mieux) que FreeBSD et apprécie aussi la rapidité de développement de ce dernier, mais je suis aussi saoulé de voir régulière des modifications de fonds sur des fonctions importantes du noyaux qui peuvent généré des bouleversement de mon système. Mon niveaux en programmation kernel est trop faible pour en tirer de réelles conclusion et surtout pour juger les développeurs, et je ne doute pas de la qualité des développeurs kernel linux (bien au contraire) en revanche je doute sur la métodologie appliquée quand à l'étude des solutions apportées. Mon impression (peut être loin de la réalité) c'est que sous linux on discute de l'idée, on est d'accord, puis on dit vas y implémente. Ensuite on se dit, l'idée est toujours bonne, mais il y a une erreur de conception là on ne peut pas faire X. OK on casse et on le recode en partie, tant pis pour les inpactes. Sous FreeBSD on discute des technos, on fait la conception ensemble pour regarder tous les inpacts et ensuite on dit vas y code. Quand on l'intègre il y a rarement besoin de revenir dessus. Je me doute bien que ça ne se passe pas tout le temps comme ça, mais c'est le sentiment que j'ai.

      Pour finir, mon utilisation perso de ma machine sous FreeBSD et sous linux est identique (même avec des trucs modernes : Camera DV, Téléphone en bluetooth, etc.). Donc si FreeBSD code moins pour arriver au même résultat, tant mieux pour eux et pour moi.
      • [^] # Re: Mouaif....

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

        Humff....tu joue pas trop le jeu je trouve. J'étais sensé récolter des insultes en échange de mon troll et toi tu sort des vrais argument ;-)

        Pour le reste je relève cette phrase :

        >> Sous FreeBSD on discute des technos, on fait la conception ensemble pour regarder tous les inpacts et ensuite on dit vas y code. Quand on l'intègre il y a rarement besoin de revenir dessus.

        Mouaif. Pas convaincu. Compare par exemple les scheduler des deux OS : Celui de Linux 2.6, écrit par Ingo Molnar, est d'excellente qualité (scalable et tout et tout) alors que pour ULE....ben....on attends toujours quoi....
        • [^] # Re: Mouaif....

          Posté par  . Évalué à 5.

          alors que pour ULE....ben....on attends toujours quoi....
          normal il n'est plus maintenu ;-)

          Mais je vais apporter de l'eau a ton moulin... juste pour infos.
          En suivant -CURRENT on peut se rendre compte que SCHED_CORE a fait son apparition, base sur ULE mais plus threads friendly. En parlant de threads, on remarque que KSE commence a etre attaque: performances variables face a libthr dans certains cas (MySQL), blocages important pour le portage sur sun4v (Kip Macy est tres virulent la dessus). Il y a meme un branche perforce ou le support KSE a ete vire (non sans humour Peter Wemm l'a nommee bike_sched). Certains ont la gueule de bois M:N, et se tournent vers le 1:1. Sun a fait la meme chose il y a deja qq annees.
          gjournal, accueilli par la foule en delire, se heurte aussi a des opinions hostiles, tous simplement parceque certains attendent la journalisation native pour UFS. plutot qu'une journalisation un niveau en dessous avec des hooks dans le code du FS. Et j'en passe...

          Mais je te rassure y'a pas mal de dev cools en cours ;-)
          Dernier point, beaucoup de developpeurs proposent des backports de leur patches pour 6.x (c'etait plus difficile entre les 5.x et 6.0-CURRENT). C'est parfois dommage que ca n'atteigne pas le CVS...
          • [^] # Re: Mouaif....

            Posté par  . Évalué à 6.

            tu veux dire qu'il manque ULE ?
    • [^] # Commentaire supprimé

      Posté par  . Évalué à 1.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Mouaif....

      Posté par  . Évalué à 5.

      Bon, je marche dedans, tant pis.

      Je sais, je sais : la 6.2 est amélioration incrémentale et le vrai boulot se fait dans la branche 7 mais bon....

      Oui, cela apporte une bien meilleure stabilité de vérifier l'impact avant de commiter...
      D'ailleurs, c'était également le mode de développement de Linux a l'époque du 2.5 vs 2.4... Dommage que ce ne soit plus vraiment le cas avec le 2.6 qui part un peu dans tous les sens amha.

      Linux offre tous les deux ou trois mois des avancées importantes ! Et avec la stabilité !


      Cela partait bien... Dommage que la seconde phrase vienne décridibiliser le reste de l'intervention.
      Parce que bon, pour avoir un parc assez hétérogène avec des machines assez stressées sous Linux, Solaris FreeBSD, NetBSD, Tru64, etc, Linux a tendance à être le moins stable de l'ensemble, et ce de manière assez sensible.

      (ce qui n'a pas été le cas de la branche 5.x de FreeBSD).

      Faux. Les 5.0 et 5.1 ne l'étaient pas, mais ils n'ont jamais étés annoncées comme tels non plus.
      Alors certe, ne pas numéroter ces versions 4.99.9_1 était sans doute une erreur par rapport aux daicideurs pressés qui veulent toujours la dernière version sans se renseigner un peu, mais bon, si on regarde le noyau 2.6 avant la version 2.6.8...

      Actuellement, nous avons encore deux serveurs en RELENG_5 en production, et comparés à une fedora 3 même à jour, il n'y a pas photo...

      Pour finir, je dirai que la principale différence pour moi, c'est que Linux repose sur le modèle du bazar (comparé à la cathédrale). Cela a du bon, tant que l'on ne met pas le nez dans le code. Parce que sinon, on s'apperçoit que comparé aux BSD c'est vraiment le bazar... dans tous les sens du terme :(
      • [^] # Re: Mouaif....

        Posté par  . Évalué à 2.

        concernant la scalabilité et la fiabilité, je confirme... un de mes clients, gros site internet dont je ne citerais pas le nom, avait tout son parc de serveurs web (environ 50 bécanes) sous Debian Linux... et il a dû migrer sur BSD pour cause d'instabilité du noyau, trous de sécurité trop réguliers (d'où reboot), etc....

        A l'opposé, dans mon ancienne vie, je bossais sur un gros site internet aussi (rencontre), dont les serveurs web étaient sur Linux, avec Zend, Jabber... pour assurer la montée en charge, il fallait rajouter une dizaine de serveurs chaque mois. En gros, chaque machine pouvait supporter entre 300 et 500 users, ce que je trouvais à l'époque minable, pour des machines dl360, bi pro Intel.
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 0.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Mouaif....

            Posté par  . Évalué à 0.

            Oui, enfin, si un changement d'OS permet de mieux supporter la charge toute chose égale par ailleurs (ce que l'on peut supposer au moins dans le premier cas), je doute que ce genre de modification ne fasse gagner un facteur 10 QUE au noyau Linux (ou alors c'est encore pire que ce que je pensais).
  • # precisions sur FreeBSD-update

    Posté par  . Évalué à 3.

    FreeBSD-update n'est pas un projet SoC. C'est issue d'une levee de fonds par Colin Percival. Il ne permet pas _simplement_ de passer d'une version a une autre. En effet ce sont des updates pour une release et non pour une branche, je ne peux tout simplement pas passer de FreeBSD 6.2 a FreeBSD 6.3 via freebsd-update. Ca semble contournable, pour le client aucun pb, c'est surtout du cote du "serveur" (dont les sources sont enfin disponibles).
    On notera aussi l'arrivee de OpenBSM [1] en experimental.


    [1] http://www.trustedbsd.org/openbsm.html

Suivre le flux des commentaires

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