DragonflyBSD 1.0rc1

Posté par twisla (site web personnel) le 06 juillet 2004 à 14:35. Modéré par Nÿco.

Étiquettes :

juil.

2004

La première release candidate du fork de FreeBSD 4.X est dans les bacs.
L'optique de DragonflyBSD est la scalabilité , de la simple machine de bureau au cluster massif, mais uniquement sur architecture x86 actuellement.

Pour rappel, Matt Dillon, à l'époque est un des principaux devs de la core team FreeBSD n'aimait pas les directions prises pour la branche 5.X, il a donc décidé de reprendre le code et apporter les évolutions qui lui paraissent appropriées. DFBSD est un système encore jeune, bien que stable, l'optique de développement est d'incorporer petit à petit les changements de manière à garder un système fonctionnel. Je vous laisse parcourir les liens dont le site du projet qui détaille les aspects purement techniques qui passent un petit peu au dessus des compétences d'un simple utilisateur comme moi.

À noter que l'image ISO est un livecd qui vous laisse un shell root et permet une installation à la main, une bonne connaissance des *BSDs est nécéssaire.
Il existe un projet d'installeur "headless" disposant de 2 interfaces, une en cgi/c via http, ainsi qu'une en ncurses, se rapprochant du vénérable sysinstall de FreeBSD, mais il n'est pas encore synchronisé sur la 1.0rc1.

Aller plus loin

# FreeBSD 5.X vs 4.X

Posté par Beretta_Vexee le 06 juillet 2004 à 15:40. Évalué à 7.

Je suis l'actualité BSD d'assez loin quelqu'un pourrait developper les aspets de la branche 5.x qui n'apprecie pas ?
Tous les FreeBSDistes que je connais ne jure que je connaisse ( bon ok j'en connais que 3-4 ) ne jure que par la branche 5.X qui est celon eux super innovante, perfomante etc etc ... et que contrairement a linux on riguole pas avec les maj sous BSD ;-)

Qu'en est il vraiment ?
- [^] # Re: FreeBSD 5.X vs 4.X
  
  Posté par benja le 06 juillet 2004 à 16:42. Évalué à 10.
  
  Le principal reproche de Matt à l'orientation de FreeBSD concerne l'utilisation massive de mutex dans le noyau. Selon lui, une utilisation de mutex au travers des différents niveau du noyau (par exemple passer un mutex en argument d'une fonction d'un sous-niveau du noyau pour qu'elle puisse le déverouiller) entraine une complexité difficile à maintenir et des pertes de performances dues aux deadlocks, aux inversions de priorité et à l'overhead des mutex.
  
  Matt a implementé un scheduleur lwkt avec une architecture appropriée au SMP. Chaque processeur se voit attribuer un scheduleur lwkt et les threads sont compartimenté par processeur. Les mutex sont remplacé par les "serialized tokens" qui garantissent à un ensemble de thread qu'ils ne tourneront jamais en même temps à conditions qu'ils ne bloquent pas dans un appel système.
  - [^] # Re: FreeBSD 5.X vs 4.X
    
    Posté par zorel le 06 juillet 2004 à 17:47. Évalué à 3.
    
    Les threads compatimentés par CPU? C'est à dire qu'un process et ses threads ne tourneront que sur un seul CPU?
    
    Quand aux mutex, c'est dommage maintenant qu'ils sont quasiment cablés dans le processeurs. Alors parler d'overhead des mutex, j'y crois pas trop en fait. Pour la complexité, je dis pas, mais pour l'overhead...
    
    Son scheduler, il est hyper-threading aware et de complexité O(1) ?
    - [^] # Re: FreeBSD 5.X vs 4.X
      
      Posté par ribwund le 06 juillet 2004 à 18:52. Évalué à 3.
      
      En fait le but ultime de dragonfly, ce n'est pas le smp mais plutot le systeme a image unique pour clusters (voir mosix, openssi, kerrighed pour des examples).
      
      L'avantage des tokens, c'est qu'ils peuvent passer par reseau et pas seulement par les interruptions.
    - [^] # Re: FreeBSD 5.X vs 4.X
      
      Posté par benja le 06 juillet 2004 à 20:26. Évalué à 3.
      
      Les threads peuvent toujours migrer de processeur grace a un inter-processor interrupt (IPI). L'avantage de la compartimentation c'est que les caches des processeur ne dupliquent pas les même données.
      
      Concernant l'hyperthreading, l'architecture du scheduler lwkt permet de le faire fonctionner facilement.
      
      Pour plus d'info, il y a une page sur la wikipedia: http://en.wikipedia.org/wiki/Dragonflybsd(...)
      http://www.dragonflybsd.org/goals/threads.cgi(...)
    - [^] # Re: FreeBSD 5.X vs 4.X
      
      Posté par Frederick Ros le 07 juillet 2004 à 08:26. Évalué à 1.
      
      > Quand aux mutex, c'est dommage maintenant qu'ils sont quasiment
      > cablés dans le processeurs. Alors parler d'overhead des mutex, j'y
      > crois pas trop en fait. Pour la complexité, je dis pas, mais pour
      > l'overhead...
      
      Ben IMHO, sur systeme SMP, il y a overhead .. S'il faut invalider les zones memoires correspondantes, il va bien falloir que ca parte sur le bus ..etc....
      
      Mais je pense que le plus gros pb est effectivement la complexite resultante .. Passe encore quand le lock/release se fait dans ta fonction, mais si si lock dans une fonction, passe le lock a une autre (qui le passera peut-etre a une autre ...) , ben pour retrouver ses petits ca doit pas etre triste ....
# tentative de français

Posté par Olivier Jeannet le 06 juillet 2004 à 15:59. Évalué à 3.

L'auteur a pris soin de mettre en italique tous les mots anglais, mais je me demandais si on ne pouvait pas essayer de moins utiliser de jargon. Voici ma tentative :

La première pré-version de la branche de FreeBSD 4.x est dans les bacs.
L'optique de DragonflyBSD est la linéarité, de la simple machine de bureau au cluster massif, mais uniquement sur architecture x86 actuellement.

Pour rappel, Matt Dillon, à l'époque est un des principaux devs de l'équipe centrale de FreeBSD, n'aimait pas [...]

Mes 2 centimes :-)
- [^] # Re: tentative de français
  
  Posté par Beretta_Vexee le 06 juillet 2004 à 16:06. Évalué à 3.
  
  tu as oublié "grappe massive" pour achever le ridicule.
  
  mes 0.02
  - [^] # Re: tentative de français
    
    Posté par Anonyme le 06 juillet 2004 à 16:53. Évalué à 1.
    
    Ridicule ? Je ne vois pas ce qu'il y a de ridicule dans tout ceci (sinon qu'il existe des termes plus courants, plus simples, que « linéarité ») ; Bien moins ridicule que l'emploi de mot qui n'existent ni en français ni en anglais (« scalabilité » ???).
    - [^] # Re: tentative de français
      
      Posté par Houbaa le 06 juillet 2004 à 17:37. Évalué à 5.
      
      « scalabilité » ???
      
      j'arrive pas à trouver plus court que "capacité de montée en charge"
      d'autres propositions ?
      - [^] # Re: tentative de français
        
        Posté par ocroquette le 06 juillet 2004 à 17:51. Évalué à 2.
        
        Elasticité ? Même si ça s'éloigne du mot anglais, ça se rapproche du concept.
      - [^] # Re: tentative de français
        
        Posté par durandal le 06 juillet 2004 à 19:27. Évalué à 4.
        
        Peut-être qu'on pourrait trouver le mot approprié en l'empruntant à la mécanique, s'il y en a un qui voudrait dire "capacité de monter en puissance" pour un moteur, un peu comme la notion de couple, non ? (Enfin, j'y connais pas grand chose en mécanique...)
        
        En tout cas, "scalabilité" ça ne signifie rien pour moi, donc je suis pour en chercher un équivalent en français.
# Ayéééééé !! La RC2 est en ligne !!!

Posté par Bouchilloux Christophe le 06 juillet 2004 à 16:07. Évalué à 4.

Il faut croire que les RC sont biens suivies, à peine quelques jours et une première mise à jour est là ... a chercher ici :

http://www.dragonflybsd.org/main/download.cgi(...)
# recitification

Posté par twisla (site web personnel) le 06 juillet 2004 à 18:04. Évalué à 6.

Petite précision que l'on m'a faite entre temps, Matt Dillon était un contributeur régulier, et non un membre de la core team FreeBSD.

Suivre le flux des commentaires

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