Logram se prend en main

Bonjour,

J'inaugure les commentaires en vous signalent que je ne serai malheureusement pas là pendant une bonne partie de la journée. On va donc pouvoir mettre en oeuvre la nouvelle hiérarchie de Logram . S'il l'accepte, je charge Malgon (le pauvre) de gérer l'équipe pendant la journée. Je lui souhaite bon courage, parce que je sens à nouveau qu'il y aura du monde !

A plus.

Bon, j'accepte

Alors je precise que vous pouvez encore venir sur IRC, la discussion sera "re-transmise" après sur le forum

Serveur : irc.uni-irc.net
Chan : #logram-project

Faut p-e préciser à quoi correspondent les différentes équipes pour que les gens puissent se proposer non?

Ok.

Donc, nous avons 4 équipes :

• Les codeurs des Llibs, qui codent les Llibs, justement
• Les codeurs de petites applications (pas encore pour tout de suite, les Llibs doivent êtres un peu développées)
• Les gestionnaires de projets : les modos, les validos, etc, ainsi que ceux chargés du recrutement
• Les autres : ceux qui suivent le projet pour le forum On se détend, et qui soutiennent le moral

A plus.

Au poil!

De la structure! C'est tout ce qu'il nous faut!
Il fallait vraiment des gens pour coordonner tout le bazar qu'était la programmation de Logram

Bah, c'est une bonne nouvelle, on va pouvoir avancer plus vite (puis, je suis content car je soutenais l'idée d'utiliser le noyau Linux ).

Citation : Steckdenis

Ça devient vraiment n'importe quoi

Si tu penses qu'écrire dans un fichier pour afficher quelque chose à l'écran est ce qu'il y a de plus rapide, Logram va vraiment se planter. Et bonne chance pour la compatibilité avec les jeux Windows...

Ça va être super de jouer à des jeux avec un fps de 1 image par 2 secondes... ( Chiffre fictif )

Je ne me suis pas exprimé précédemment sur l'utilisation d'un noyau Linux, mais je crois que Logram perd tout son intérêt, qui était à la base d'apprendre comment fonctionne un OS, et pas de le vendre à grande échelle ( Je sais que ça a déjà été dit ).

Si je n'étais pas propriétaire du nom de domaine, je crois que je serais aussi parti comme Royalbru.

Je veux bien aider pour les applications et plus particulièrement pour la personnalisation de l'interface graphique .

Tout dépend de comment est utilisé le framebuffer. La console l'utilise mal : à chaque ligne d'écrite, il faut reparser tous les caractères, et réafficher tout le framebuffer, et c'est extrêmement lent.

Ensuite, avec les MTRRs activés dans le noyau, ainsi que le support de PCI/AGP, je réussis à obtenir facilement +- 30fps en 1280x1024x32bpp !

Linux gère bien les fichiers, profitons-en. D'ailleurs, sur ce point, le serveur X ne s'illustre pas trop. Sans un bon pilote graphique (donc quand on utiliser le pilote VESA), on peut sentir de bonnes saccades quand on déplace une fenêtre.

Le tout est de bien coder. Si à chaque fois qu'on change un petit caractère à l'écran, on redessine tous les caractères dans le framebuffer, ça ne va pas aller. Il faut optimiser, et tout ira bien .

A plus.

EDIT: Ah oui, j'oublie de le dire : je ne fais pas ça pour vendre, loin de là. Si je voulais vendre Logram, j'aurais gardé l'idée de refaire tout à zéro, avec le rêve d'obtenir quelque chose d'extra, etc. Ici, je préfère fâcher quelques personnes (même si j'aurais préféré que tout le monde soit content) et permettre à toutes les autres de coder, plutôt que de tout faire moi-même, pour finalement pas grand chose, et une communauté mourrante (je sais pas si tu as vu, mais depuis le mois de septembre, il y a grand maximum 60 visiteurs par jours, même les week-end. Depuis que j'ai lancé la news sur le noyau Linux, on passe à plus de 150, et les forums se remplissent. Ce n'est pas du marketing, c'est juste pour un peu réveiller les gens. Je ne veux plus n'avoir plus que les news sur les nouvelles versions, espacées de plusieurs mois. Logram doit être dynamique).

N'empêche qu'un accès au disque dur est beaucoup plus lent qu'un accès à la RAM.

Ah, la magie de Linux : ce fichier n'est pas sur le disque dur : c'est un fichier qui se trouve dans le système de fichiers virtuel devfs. En fait, si j'écris dans /dev/fb0, je ne vais pas écrire physiquement sur le disque, je vais envoyer au pilote vesafb l'instruction vesafb_write. Le seul goulet d'étranglement, c'est la vitesse du bus (PCI) ou du processeur.

A plus.

Donc c'est en quelque sorte un "flux de sortie" nan ?

Moi je suis d'accord .

Exactement. Pour ça, Linux n'est pas très clair, avec ses points de montages, ses i-nodes, etc. Quand tu écris dans un fichier, tu ne sais jamais s'il se trouve sur le disque, sur le réseau, en RAM, su quelle partition, etc. C'est très pratique tout de même .

Content que tu sois d'accord .

Toutes ces idées sont génial!!!!

Je ne suis pas d'accord avec les gents qui sont contre le fait que Logram utilise un noyau Linux. Regardez MacOS. Et arrêtez de croire que Logram va être une de ces distributions qui se ressembles toutes. Tout d'abord de suis super content de savoir que Logram n'utilisera pas X11. C'est déjà une grande différence. KDE/Gnome/XFCE l'utilise déjà.

L'API LOGRAM ou les Llibs, sont aussi une très bonne idée. Indispensable au fonctionnement de Logram et à sont développement/expansion. Il sera donc facile de créer des programmes dessus.

Un bon projet, c'est une très bonne organisation. Mais il faut aussi de la communication. C'est fondamental.

J'aimerais bien être acteur du projet. Vous aidez, programmer, ou réaliser autre chose pour Logram. Mais il manque (je sais ce n'est pas encore mis en place réellement) un bon tuto pour nous mettre en route (nous programmeur).

Il faudrait aussi des règles de programmations (tailles des fichiers, commentaires régulièrement) et un suivit précis de qui a fait quoi et quand.

Picxime

Je ferai un big-tuto "Développer (pour) Logram" .

Pour les Llibs, j'essaye de les commencer, mais c'est difficile, car exporter des classes C++ (et oui, je me suis mis au C++ ) dans un fichier .so est difficile. Pour le moment, voici déjà comment on pourrait les utiliser :

Code : cpp
Quand j'aurai réussi (donc que tout compilera bien, et ne segfaultera pas), une ligne devrait s'afficher à l'écran. A ce moment, je rajoute encore quelques détails (les bases, pour qu'on sache où je veux en venir), je réfléchis bien à la structure, et je crée un tuto sur la programmation des Llibs, pour que tout le monde puisse y participer.

Environnement requis

Même pas besoin de LFS, il faut juste que votre distrib boot en mode console (Google...), et utilise la framebuffer (ajouter dans le GRUB, sur la ligne qui boot votre noyau, "vga=ask". Ensuite, choisissez un mode au démarrage (c'est facile )).

Ensuite, GCC/G++, Les binutils, et c'est tout .

A plus.

Bonjour à tous!

Picxime: La raison pourquoi plusieurs personnes sont contre ces le changement de philosophie. Avant c'était bâtir un OS de zéro et là sa change un peut. Chacun ces opinion.

steckdenis: Pour programmer les nouvelles bases de Logram (avec noyau Linux), est-ce nécessaire ou bon de connaitre l'assembleur?

Pour ce qui est de : compiler Logram et le tester (avec grub?) est-ce possible avec un Live CD de Linux?

Quelle distribution en Live CD fonctionnerai sur un Pentium 4 32bits, 512MB de RAM. Je crois que Ubuntu est compatible j'ai raison?
Combien de temps sa peut me prendre à charger le live CD 5minute, 3heure?

Je sais que je pose plusieurs questions mais je veut apprendre

Merci et bonne journée.

Logram est maintenant plus haut niveau : les Llibs (le plus bas niveau de Logram) sont en C++ .

Logram étant basé sur Linux, tu installes les Llibs sur n'importe quelle distrib qui utilise le framebuffer (sur un live-CD, à l'écran de boot, tu appuies sur F4 puis sur 800x600 ou autre).

Sur un P4 32-bit et 512Mo de RAM, n'importe quoi tourne !

A plus.

Euh ... J'ai pas bien du suivre, mais ce dont tu parles, steckdenis, est déjà en place ("Logram étant basé...") ? (si oui, je dois être complètement à côté de la plaque , je regarde pas tous les jours les sources et tu n'es as pas parlé sur le forum...)

Sinon, je pense qu'on devrait pensé à la partie théorique sur les fonctionnalités un peu plus en profondeur (tu montres déjà un code alors qu'il faudrait réfléchir dessus un peu plus. Après, ce n'est que mon avis, bien sur (je dis ça je ne dis rien ...). Ça éviterait de faire comme ce qu'il se passe en ce moment, qui nous oblige à supprimer une grande partie ce que l'on a déjà fait).

Deuxième sinon, je suis absolument volontaire pour aider (avec mes moyens moyens (premier moyens = entre petit et grand et deuxième moyens = ce que je peux faire ), même, et surtout, dans la partie théorique.

Et puis, si jamais on veut faire le noyau plus tard ... Il serait sage de penser à conserver tout ce qu'on a fait pour le moment (mais je suis sur que Steckdenis y a déjà pensé )...

Tout d'abord, les sources de Logram Kernel sont sur deux CDs différents : un dans un cadre accroché au mur et l' autre dans une enveloppe à mon nom dans un tirroir. Pas de risques de ce côté. Je peux donc purger le SVN et mettre en place la nouvelle architecture (passer de /trunk, ... à /llibs, /utilitaires, /images, /sons, /desktop, etc).

Pour l'architecture, ce que je montre est le fruit de mes tests, pas l'architecture définitive. Le meilleur moyen de bien coder est de savoir de quoi on a besoin, et de ne pas se retrouver bloqué, en devant modifier une bonne partie du travail (c'était courant pour Logram Kernel, surtout pour la gestion des threads : CreateThreads est passé de 4 à 12 paramètres en 2 jours, la TSS multipliée par 2 ).

Pour le moment, je réfléchis à l'architecture, et je compte créer un tuto qui récapitulera tout l'architecture et le développement de Logram, accessible à tous, et je devrais trouver un moyen de le rendre éditable par tout le monde (en jouant sur les user_id peut-être, ou avec un petit if() dans le code, quoique l'interface de tutos ne s'y prète gerre ).

A plus.

Citation :

Ca s'appelle un wiki