Re: [Kos-dev] Comment attirer de nouveaux développeurs ?

[Thomas Petazzoni]

Bonjour,

David MENTRE wrote:

> À noter que la partie française est vide (en lang=fr). C'est pour ça que
> je n'avais pas vu tes suggestions.

Effectivement. La partie française est désormais en ligne (modulo les 
oublis, fautes d'orthographe, etc.).

> Vous gagnez du temps en parlant français (et c'est souvent plus
> clair). Maintenant, avec l'anglais, tu changes d'échelle => développeurs
> potentiels au niveau mondial.

C'est sûr que l'on gagne du temps en français. Mais la communauté des 
développeurs d'OS français a l'air déjà assez mince, alors ceux qui 
s'intéressent à KOS sont encore moins nombreux.

Mais peut être qu'avec SOS on va susciter des vocations ? ;-)

> Dans la communauté Caml, tout le code et doc sont en anglais, mais le
> français est parfois utilisé. À mon avis, il faut que le code soit
> *impérativement* en anglais.

Le code de KOS est en anglais, identifiants de variables/fonctions et 
commentaires.

> Je pense que le principal problème de KOS actuellement, c'est le manque
> d'un objectif, même irréalisable. Il existe déjà une floppée d'OS[1],
> donc il faut trouver une raison pourquoi les gens développeraient plutôt
> pour KOS que pour un autre.
> 
> Donc il faut que vous trouviez un objectif.

L'objectif principal est toujours le même : apprendre. Et même si le 
projet est déjà avancé, il reste des choses à apprendre. Les nouveaux 
arrivants peuvent apprendre soit en codant de nouvelles choses (drivers, 
pile réseau, filesystems, fonctionnalités diverses et variées), soit en 
étudiant ce qui existe déjà, au fur et à mesure.

Ceci dit, l'objectif est quand même d'essayer d'avoir une relative 
compatibilité POSIX. Au moins de quoi faire tourner un shell, les outils 
GNU classiques. L'objectif ultime étant, comme c'est marqué maintenant 
sur le site, de pouvoir compiler KOS sous KOS.

Pourquoi coder pour KOS plutôt que pour un autre ? Principalement parce 
que tu trouves les développeurs sympas et que tu t'entends bien avec 
eux. Peut être aussi parce que les discussions sont en français, donc 
c'est moins lourd à suivre qu'un projet anglophone.

Mais c'est clair que KOS ne propose rien de véritablement révolutionnaire.

>  - il devient envisageable de vérifier de manière formelle certaines
>    parties d'un OS, même écrit en C ;

Oui, tu m'en as déjà parlé, c'est un sujet qui te passionne ! 
Personnellement, je ne suis pas (encore ?) intéressé par ces sujets, 
j'ai d'autres motivations dans le projet.

>    1. des « modules » noyaux qui puissent s'exécuter isolés les uns des
>       autres (que le plantage de l'un ne vautre pas les autres) ;

Ça pourrait être une idée, mais je crois que le projet ne s'y prête plus 
vraiment. Pour réaliser cela, il faut par exemple faire ce que fait GoOS 
(http://goos.sourceforge.net/overview.php), c'est à dire du code scanning.

>    2. un système de « pipe » entre modules, à la Unix mais qui permette
>       des interfaces plus compliquées, avec des types structurés de
>       données et des exceptions (autrement dit, un système d'IPC comme
>       sur Mach ou dans Corba).

Pareil, nous ne sommes pas partis sur ce genre de trucs.

Les deux fonctionnalités que tu viens de citer se rapprochent plus à mon 
avis de ce qu'on peut attendre d'un système à base de micro-noyau avec 
des serveurs autour.

>  - avoir un shell pour faire des commandes de base (lancer un module,
>    dumper des états, ...) ;

On dispose déjà d'un shell noyau très minimal permettant de lister les 
threads et leurs états, d'afficher la mémoire, d'afficher le contenu 
d'un fichier du disque dur, etc..

>  - avoir un système de documentation du code, pour écrire la doc en même
>    temps que le code (cf. noweb, doxygen, ...) ;

Tout le nouveau code est commenté avec doxygen. Même si je ne suis pas 
tout à fait satisfait des possibilités de documentation avec cet outil, 
c'est déjà mieux que rien. Voir par exemple les fichiers 
modules/x86/mm/_vmap.c et modules/x86/mm/_rmap.c.

>  - avoir un environnement de développement user minimal (pas forcément
>    une libc) ;

C'est dans le module kos-sys. C'est très minimal, mais on peut faire 
fork(), exec(), brk(), open() et write() sur une console.

>  - comme cela a été suggéré, avoir un module hello-world documenté pour
>    démarrer rapidement.

Bonne idée. J'essaie de faire ça très prochainement.

> Pour ma part, je serais intéressé par les développements suivants sur
> KOS (si j'avais le temps ;) :

[ Toutes tes idées sont de bonnes idées. De toute façon, toutes les 
pistes sont bonnes à explorer. ]

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni at jabber.dk
KOS: http://kos.enix.org/ - SOS: http://sos.enix.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://the-doors.enix.org/pipermail/kos-dev/attachments/20050112/3a156017/signature.pgp