Articles précédents : Distribution
- [32] Kaella (Knoppix Linux Azur) en version 1.1
- [107] La slackware 10 est sortie
- [46] CRUX 2.0 : « orientée développement et légèreté »
- [18] Annonce du Desktop Linux Server
- [33] Knoppix passe au DVD !
- [20] Gentoo Inc. devient Gentoo Foundation
- [28] WinLibre
- [33] Les Packs Éducatifs Libres
- [135] Les images ISO "Mandrake 10.0 Official" disponibles au téléchargement
- [29] DFS : Debian From Scratch
Liens connexes
- La news sur /. (392 hits)
- DrangonflyBSD (667 hits)
- L'installeur (337 hits)
- L'image ISO sur un mirroir (245 hits)
Dépêche modérée par
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.
La news sur /. (392 hits)
DrangonflyBSD (667 hits)
L'installeur (337 hits)
L'image ISO sur un mirroir (245 hits)
> Lire la suite (14 commentaires, moyenne: 4). [dépêche : 746 caractères]
À 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.
FreeBSD 5.X vs 4.X
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 ?
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
-
[^]Re: FreeBSD 5.X vs 4.X
Posté par benja () le 06/07/2004 à 14:42. (lien). Évalué à 11.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/07/2004 à 15:47. (lien). É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/07/2004 à 16:52. (lien). É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/07/2004 à 18:26. (lien). É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 (page perso, ) le 07/07/2004 à 06:26. (lien). É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
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 guiral Lacotte (Jabber id, ) le 06/07/2004 à 14:06. (lien). Évalué à 3.tu as oublié "grappe massive" pour achever le ridicule.
mes 0.02--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: tentative de français
Posté par gnap gnap (page perso, ) le 06/07/2004 à 14:53. (lien). É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 stephane martin () le 06/07/2004 à 15:37. (lien). Évalué à 5.« scalabilité » ???
j'arrive pas à trouver plus court que "capacité de montée en charge"
d'autres propositions ?--
Every time you write invalid markup, God kills a kitten-
[^]Re: tentative de français
-
[^]Re: tentative de français
Posté par durandal () le 06/07/2004 à 17:27. (lien). É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 !!!
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
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.
twisla



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.