• [^] # Re: rentrons dans le vif du sujet

    Posté par (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.

    Euh, c'est vrai, une compil kernel ça prend 30s sur un Atom.

    Tu réponds pas au problème : pour des questions d'emprunte mémoire, de sécurité, de spécificité matérielle, on a pas envie de charger tout le bouzin en mémoire. Comment en Lisaac je charge dynamiquement des modules en mémoire sans passer par une compilation/déploiement séparée ?

    Faut savoir : le principal intérêt de Lisaac, c'est la compil globale qui apporte un gain de perf. Si le code est "modulable" et compilable/déployable séparrement, le compilo peut plus faire son boulot de compilation globale, on perd une bonne partie de l'intérêt de Lisaac.
    Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
    Peut être que sur de l'embarqué où le kernel n'est pas trop complexe et qu'il y a un seul mainteneur ca peut servir à quelque chose... ou pas.

    il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout.
    \o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
    J'attend aussi de voir le débuggueur...

    Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
    On a l'impression qe Lisaac se focalise uniquement sur le dev et l'exécution.