Bonjour,
Vu l'effervescence provoquée par la dernière news, vous devez être au courant des dernières informations. Je rappelle brièvement les faits :
Ca fait des années que je code Logram, et presque 6 mois (déjà

) que je le code avec le reste de l'équipe. Tout se passait très bien, et tout se passe encore très bien. Le problème, c'est que dans l'équipe, il y avait (royalbru est parti

) deux codeurs systèmes : moi et royalbru. Les autres suivaient le projet de près ou de loin, mais sans vraiment participer.
J'ai donc pris les choses en main : on va utiliser le noyau Linux (donc un noyau tout fait et qui a fait ses preuves) comme coeur de Logram. Le problème, c'est que le noyau Linux ne vient pas tout seul, il faut aussi lui ajouter quelques outils, comme Bash, GCC, les binutils, uDev, SysVinit, etc pour qu'il soit bootable. Cet ensemble d'utilitaire s'appelle le
un LFS (pour Linux From Scratch). C'est très instructif, il vous apprend dès le départ à créer votre propre système, mais là n'est pas la question

.
Un LFS n'est pas suffisant pour avoir un système correct, et surtout graphique. Je me suis donc posé la question, et j'ai posé cette même question au reste de l'équipe, de savoir à quel point il fallait intégrer des outils GNU dans ce LFS pour avoir Logram. Je m'exprime plus clairement : un LFS, c'est le shell Bash, et rien d'autre. Vous ne pouvez rien faire, ni même pinger votre routeur, ou aller sur internet. La seule chose qu'il permet, c'est de compiler d'autres applications.
L'architecture de Logram
Trêve de bavardages, passons aux choses sérieuses

!
Le choix qui a plus ou moins été retenu (pas beaucoup de personnes se sont prononcées) a été de prendre le noyau Linux, ainsi que quelques outils GNU (GCC, mais aussi les net-tools, Lynx, et d'autres petites applications sympa), et de tout construire autour. Il restait un choix à faire :
X11 ou pas
X11, pour le mode graphique.
J'ai donc installé X11 sur mon LFS, et j'ai vu que c'est très lourd pour pas grand chose (bon, on a quand-même la gestion des polices, la gestion des événements, etc), mais ça reste limité à du "connu".
Voici donc ce que je propose : utiliser le
framebuffer. Rien de plus simple, rien de plus rapide, rien de plus
amusant instructif. Ca va plaire aux développeurs avancés, et surtout, ça va permettre de faire ce qu'on veut (onglets, IA, compatibilité Windows (bon, ça c'est pas graphique), etc) !
Le principe est simple (attention, ce qui suit est relativement technique) : le framebuffer est un fichier (/dev/fb0 en l'occurance) dans lequel on écrit. La différence entre ce fichier et un autre, c'est que tout ce qu'on écrit dedans est affiché à l'écran

. Par exemple, pour afficher un pixel vert à la position 10x10, on place la valeur 0x0000FF00 dans le dword situé à (10*largeur_écran)+10. On a un pixel vert de dessiné.
Bien évidemment, les applications ne vont pas s'amuser à écrire dans ce fichier, loin de là. Elles vont utiliser la
signature de Logram, son cachet si vous préférez, ce qui va le rendre
unique : les
Logram's libs.
Les
Logram's Libs seront un ensemble de bibliothèques que pourront utiliser les applications, un peu comme une API : elle feront tout, absolument tout. Le but des
Llibs, c'est de proposer aux applications un environnement normalisé, et puissant, un peu comme Qt. Le gros avantage, c'est comme KDE et ses kdelibs, c'est qu'on charge au démarrage les Llibs, et qu'on n'y touche plus. Les applications démarreront donc à la vitesse de l'éclair

!
Les Llibs, en plus de gérer l'aspect graphique, géreront aussi tout le système. A nouveau, je me base sur KDE qui m'a beaucoup impressionné de ce côté : toutes les applications KDE peuvent utiliser les Kio-Slaves, et d'autres mécanismes vraiment puissants. Les Llibs permetteront également ceci, par exemple, une application pourra très facilement accéder à un fichier sur un FTP avec cette simple ligne de commande :
Code : cppFile = new LFile("ftp://ftp.perso.free.fr/~machin/fichier.ext");
Les Llibs se chargeront d'afficher si nécessaire une boîte de login, de gérer la connexion, et de retourner le résultat.
Ouch, je plains les codeurs, ils vont vraiment devoir beaucoup à coder.
Pas tellement. Les Llibs seront une interface, et contiendront toute la logique, mais elles relègeront à d'autres librairies le sâle boulot (libftp, libxml, libpng, etc). Ainsi, les Llibs seront puissantes, sans trop de travail, et donc sans trop de bugs

!
Autour des Llibs, l'environnement de bureau Logram, et tout ce qui va avec. Avec ça, on aura, sur un système Logram de base, 80% de code Logram, et 20% de code GNU (sachant que par exemple, pour le noyau Linux, ce ne sont que des pilotes).
Participer au codage de Logram
Vous voulez participer au codage de Logram, c'est simple, ça se fait en étapes :
- Il vous faut une base. Le LFS (adresse plus haut) est une très bonne base, et pas trop difficile à mettre en place (j'avertis juste d'une chose : Logram basé sur Linux sera portable. Il faut donc savoir le construire. Le LFS en 32-bit marche impec. en 64-bit, il faut quelques manipulations : construire les binutils dans leur dossier (pas dans un autre, il y a un fichier qui manque), ajouter à ./configure de GCC --diable-multilib, et copier/coller GRUB de votre distrib vers le LFS. Il faut également, au tout début, créer les dossier /lib et /usr/lib, et créer un lien symbolique de /lib64 et /usr/lib64 vers ces dossiers. Le but est de faire en sorte que /lib=/lib64 et que /usr/lib=/usr/lib64).
- Une fois le LFS fait, il faut le configurer. Je vous conseille fortmenent d'être connecté en Ethernet, quoique le wifi, avec les bons pilotes, marche aussi. Là, il faut aussi quelques conseils : pas de dhcp (il plante), et surtout, une fois que tout est bien configurer, ajouter la route par défaut : "route add default gw 192.168.0.1 netmask 255.255.255.0". Sans ça, impossible de sortir du réseau.
- Se connecter au dépôt SVN de Logram, et télécharger les fichiers sources.
Je crois avoir tout dit, bon dév.

.
L'organisation de Logram
Logram s'organise aussi. Soyons clair, ce chapitre sera moins fourni que le précédant, car qui dit organisation, dit discussion, et ça prend déjà plus de temps. Voici donc simplement les bases de l'organisation de Logram.
Au lieu d'être
linéaire (tout le monde donne des ordres à tout le monde, et en recoit), ce qui menait à rien, on va organiser tout ça hiérarchiquement.
En haut de la pyramise, les
chefs de projets (moi et un autre, si jamais
le wifi me joue des tours je suis indisponible pour un moment, ou très occupé, comme maintenant avec le LFS). Ils seront au courant de tout, les informations leur seront présentée correctement et clairement par les autres membres. Ainsi, ils auront une vue générale de Logram, et pourront donc gérer le projet en entier, sans l'éclater, et en pouvant toujours synchroniser les différentes tâches, et tout coordonner.
À l'étage du millieu, nous trouverons les
directeurs de projet (si vous avez un meilleur nom, dites-le moi

). Ils seront au nombre de 3-4 ou un peu plus, et seront les directeurs de sous équipes. Leur boulot : coordonner les membres de leur équipe, et informer les chefs de projet de ce qui se passe (de manière synthétisée, etc).
En "bas" (mais en réalité, ce seront les personnes les plus importantes) se trouveront les
éxécuteurs. Ils feront le travail. Rassurez-vous, ce ne sera pas une tyranie. Les directeurs de projets pourront être également éxécuteurs, etc. C'est comme maintenant : un modo est un membre, et un modo peut locker le topic d'un autre modo (voir le ban

).
Bref, tout ceci commence à prendre forme, mais c'est encore un petit peu flou.
Conclusion
Je crois que c'est tout. Je précise que vous pouvez à nouveau poster des commentaires de news, j'ai désactivé l'envoi automatique de MPs (je me demande comment ça se fait qu'un truc pareil a été codé

).
Je précise que rien n'est fait, ce n'est qu'une synthèse du topic "Discussion IRC" (dans On se détend), qui résume quelques idées données, et mes propres réflexions. Si vous voulez vous opposer à quelque chose, ou en débattre, ou poser des questions, ne vous privez pas (mais s'il vous plaît, évitez de parler sans vous renseigner, comme pour la news précédante : «C'est pas nous qui le faisons ça puxx»).
Bon débat

.