GnuSrc et Cream-Browser

Au sujet de Cream, tu est en train de recréer Konqueror avec le système de KParts de KDE .

Et oui, si j'entre une url en HTTP, c'est la KPart KHTML (ou KdeWebkit) qui est utilisée. Pour du FTP ou un fichier normal, c'est la KPart FileBrowser utilisée, avec utilisation des KIO pour gérer les protocoles. Enfin, tu connais normalement ce système .

Sinon, rien ne presse pour le LFS de Logram. Je ne pense pas que tu auras à créer les paquets, en ce sens que si tu fais ça, je serai insupportable . En effet, j'ai une très bonne idée du comment je veux que les choses soient faites, et je risque de t'énnerver à te faire recommencer .

Non, pour aider, il te suffit de faire ce que tu fais : hacker ce que tu veux. En effet, en créant ta distro, tu vas trouver des options de compilation pour accélérer un programme, ou comment intégrer un truc, ou comment organiser des fichiers de conf, etc.

Ensuite, je te demanderai des conseils et tu saura y répondre .

Pour ce qui est de Konqueror, en effet je m'en suis inspiré, sauf que ici c'est GTK et du C, donc saymieux™

Et pour la LFS le logram, ben faudra que tu me donne un cahier des charges précis, car je veux la faire afin que tu puisse te concentrer sur Setup (crois pas que tu va tout faire afin d'avoir tout le mérite !). De plus le travail en équipe, ben saymieux™

De toute façon, la LFS ne commence pas avant la fin de Setup, et le développement de la LFS permettra de voir ce qui doit être changé dans Setup en vue d'une version 0.1.1 ou 0.2.

Ce qui m'aiderais vraiment, mais alors vraiment vraiment est une petite liste de tâches me permettant de savoir quoi faire et comment :

• Comparer init-ng et upstart, j'hésite entre les deux (plus Init-ng, sauf si upstart a une killer-feature qu'initng n'a pas)
• Voir s'il n'existe pas une autre LibC que la GNU GLibc, par exemple une plus rapide, mais tout aussi fonctionnelle (donc voir si uClibc est POSIX et gère tout le nécessaire)
• Tester et re-tester Clang, compilateur de la distrib
• IMPORTANT, surtout que ça rendrait Logram unique : voir avec les autotools, CMake, Jam etc comment générer des bytecode LLVM à la place des éxécutables et bibliothèques, pour implémenter dans ce que je décris dans mon award-winning journal LLVM dans un gestionnaire de paquets ?. Les avantages seraient multiples : optimisation pour le processeur de l'utilisateur sans une longue compilation, patches plus petits (le bytecode LLVM n'ayant pas les problèmes du binaire natif pour les deltas binaires), marketing
• Savoir où en est Gallium3D, s'il est intégré à Mesa, s'il marche bien, etc
• Si t'as une carte nVidia qui traîne, essayer Nouveau avec le tout dernier kernel de développement
• te renseigner sur la création de thèmes graphiques GRUB 2
• Savoir s'il existe des applis Qt qui utilisent les exceptions C++. Si non, excellent, on pourra compiler Qt avec -fno-exceptions, et ainsi diviser sa taille et son occupation RAM par deux, en multipliant sa vitesse par ~50% !
• Trouver des astuces de sysadmin ancien-gentooiste, pour par exemple la compilation de Xorg, les éléments de base d'une bonne distrib, les services peu connus comme atd, crond, sshd, le système de démarrage
• Trouver comment facilement générer un initrd.

Si t'arrives à faire tout ça, t'auras largement plus de mérite que moi . Parce que je ne ferai que les compilations (sur des Dual Quad Core i7 à 3Ghz de mon père , paquets uploadés à 3Mbps sur une connexion 100Mbps, donc j'ai le matériel nécessaire), mais que ce sera très bien fait (utilisation maximale de Setup, développement des lh_tools, comme lh_strip, lh_menu, etc. À mettre en rapport avec les debian_helpers ).

• Upstart est le système d'init de Ubuntu, c'est une raison suffisante pour utiliser init-ng selon moi.
• Pour ce qui est de la libc, on peut très bien utiliser celle de BSD qui sera certainement compatible avec Linux (au pire on trifouille un peu le code pour le rendre compatible).
• Clang, ca c'est a faire.
• Ca c'est relativement simple suffit de dire aux autotools de compiler avec LLVM en utilisant tel ou tel options, suffit de savoir manier ses outils et tu peux tout faire :)
• Gallium3D, je ne connais pas. Je sens que je vais devoir googler
• J'ai une carte nVidia MSI7300GT, quand je fut sous NetBSD il y a 6-7 mois, j'ai eu l'occasion de tester se driver (nvidia ne fait pas de driver pour cet OS), il est particulièrement bien foutu, rapide, performant (du moins pour la 2D, la 3D j'ai pas test). Donc je pense qu'à l'heure actuelle, il est encore mieux. De plus j'ai rédigé un article pour ce driver dans OpenSource Magazine, le chèque que je receverai ira en partie comme donnation pour ce projet (et je compte dailleurs utiliser ce driver une fois qu'il supportera la 3D)
• Pour GRUB 2, pas de problème, Google est mon ami.
• Je ne connais pas assez bien Qt et le C++ pour te répondre à ca, mais on pourrait laisser le choix à l'utilisateur.
• Ca c'est simple, RTFM :D
• Egalement simple : Google et RTFM

En gros, lorsque tu me dira ce que tu veux dans la LFS et que je la ferrai, il me suffira de googler un peu.

De plus j'ai pensé à une chose : La construction d'une LFS se fait en deux temps :

• construction d'un système temporaire
• chroot dans ce système
• compilation de l'environement de base à l'aide de cet environement temporaire.

Ici au lieu de compiler l'environement de base, pourquoi ne pas tout simplement installer setup dans l'environement temporaire et lui faire installer les paquets nécéssaire ?

Un paquet Logram doit être compilé pour Logram, donc il faut un système temporaire qui te permettra d'un peu hacker les paquets.

En fait, ce que tu peux faire, c'est une LFS, qui va jusqu'à Xorg, éventuellement Qt et KDE. Comme ça, tu ne dois pas faire les paquets (donc je ne t'embêterai pas avec ), mais tu peux quand-même expérimenter tout ce que tu veux et résoudre les problèmes que je pose.

Ou alors, tu fais ta distrib, et tu rencontreras les mêmes problèmes, ainsi que les problématiques liées à l'empaquetage (dépendances sources VS dépendances éxécutables, split des paquets, gestion de la version des bibliothèques, etc).

Merci en tous cas .