Pour l'instant, DragonFly est encore en 1:N mais le passage en 1:1 est prévu (avec l'utilisation de libthread_xu pour gérer les threads utilisateurs) . Par contre il n'y a pas vraiment de date arrêtée. Je ne sais pas exactement ce qui empêche le passage en 1:1 mais c'est probablement du côté du noyau.
En fait, je voulais dire qu'il y a des problèmes de license avec l'utilisation de code venant de RTLinux (RTHAL).
J'espère donc que ces problèmes vont disparaître avec l'utilisation de Adeos.
De plus, RTAI a plus de fonctionnalités que RTLinux et est plus activement développé.
Sous RTAI, on peut avoir des tâches temps-réel en mode utilisateur (avec LXRT).
Lorsque je l'ai utilisé il y a 2-3 ans, je me rappelle que la partie affichage/interaction de mon projet était une tâche LXRT.
De plus, j'ai eu des échanges de mails très constructifs avec Paolo (qui dirige le projet RTAI) lorsque je trouvais des bogues... car, bien sûr, il y avait des bugs (d'ailleurs RTLinux en a autant probablement) mais je n'i pas eu de gros problèmes de stabilité.
Maintenant, je ne suis que de loin RTAI. La nouvelle direction qu'ils prennent semble intéressante. J'espère que les éventuels problèmes de license vont disparaître.
On peut espérer que ces développeurs n'utilisent pas une méthode de signature/chiffrement déconseillée par l'auteur de gpg (affichant même un warning d'ailleurs). Et, par ailleurs, ils peuvent révoquer leur clé si elle est concernée par cette faille.
[^] # Re: on peut les utiliser ?
Posté par sbugsin . En réponse à la dépêche L'alternative BSD. Évalué à 2.
cette même liste avec une interface plus "sexy" :
http://www.pkgsrc.se
[^] # threading 1:1 DragonFlyBSD
Posté par sbugsin . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 3.
Pour info, la roadmap écrite en octobre 2005 (en anglais) :
http://leaf.dragonflybsd.org/mailarchive/kernel/2005-10/msg0(...)
Pour l'instant les développements nécessaires à ce sujet semblent ralentis, voire arrêtés.
[^] # Re: ...
Posté par sbugsin . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 3.
Pour l'instant, DragonFly est encore en 1:N mais le passage en 1:1 est prévu (avec l'utilisation de libthread_xu pour gérer les threads utilisateurs) . Par contre il n'y a pas vraiment de date arrêtée. Je ne sais pas exactement ce qui empêche le passage en 1:1 mais c'est probablement du côté du noyau.
[^] # Re: Je me dévoue
Posté par sbugsin . En réponse à la dépêche Sortie de Vim 7. Évalué à -1.
[^] # Re: bye bye MS
Posté par sbugsin . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 0.
Mais bon je ne me fais pas trop d'illusions sur la plupart de nos hommes politiques.
[^] # Re: Ma contribution la plus importante pour le logiciel libre est :
Posté par sbugsin . En réponse au sondage Ma contribution la plus importante pour le logiciel libre est :. Évalué à 2.
Effectivement, comme tu le soulignes, ces "petites" contributions sont réellement importantes.
[^] # Re: Winamp 3 à la poubelle ??
Posté par sbugsin . En réponse à la dépêche Winamp 3 en open source. Évalué à 8.
AMA, il vaut mieux améliorer/porter XMMS que de bosser sur un winamp buggué.
[^] # Re: RTAI annonce la version 3.0-test1
Posté par sbugsin . En réponse à la dépêche RTAI annonce la version 3.0-test1. Évalué à 1.
En fait, je voulais dire qu'il y a des problèmes de license avec l'utilisation de code venant de RTLinux (RTHAL).
J'espère donc que ces problèmes vont disparaître avec l'utilisation de Adeos.
Voilà :-)
[^] # Re: RTAI annonce la version 3.0-test1
Posté par sbugsin . En réponse à la dépêche RTAI annonce la version 3.0-test1. Évalué à 6.
Sous RTAI, on peut avoir des tâches temps-réel en mode utilisateur (avec LXRT).
Lorsque je l'ai utilisé il y a 2-3 ans, je me rappelle que la partie affichage/interaction de mon projet était une tâche LXRT.
De plus, j'ai eu des échanges de mails très constructifs avec Paolo (qui dirige le projet RTAI) lorsque je trouvais des bogues... car, bien sûr, il y avait des bugs (d'ailleurs RTLinux en a autant probablement) mais je n'i pas eu de gros problèmes de stabilité.
Maintenant, je ne suis que de loin RTAI. La nouvelle direction qu'ils prennent semble intéressante. J'espère que les éventuels problèmes de license vont disparaître.
[^] # Re: Et les clefs des dev Debian et autres gros projects
Posté par sbugsin . En réponse à la dépêche Un bug de GnuPG compromet plusieurs centaines de clés. Évalué à 4.