Mais n'ayant pas les connaissances pour évaluer lvvm vs gcc, te surtout pas l'envie de rentrer dans un début philosophique me dépassant (et sachant que des argumentaires techniques peuvent y être mûs par la seule volonté de valoriser une vision philosophique). Ayant encore moins les notions permettant de jauger la qualité, les résultats, les tenants et aboutissants du bytecode vs compilé, je nepeux que me contenter de dire :
La solution "architecture" me semble belle. Et ça me plait :) Donc pas la vision purement technique sur les moyens d'y arriver mais la finalité du projet : disposer de 'binaires' initiaux très 'légers', très 'portables', et très 'indépendant'. La phase finale étant assurée par la machine cliente. Je trouve cela beau et formidable.
Un seul bémol, sur l' argumentaire : Une éxécution super rapide chez le poste client, car optimisé aux petits oignons pour son CPU, quel qu'il soit (dernier Core i7, AMD Phenom, un PPC, un Cell, un ARM, etc)
Là j' ai des doutes. D' une part parceque les bibliothèques sont toujours ce qu' elles sont : des binaires classiquement installés. Ce qui, je présumé, grève significativement l' argument, pour une partie des fonctions d' une bonne partie des binaires logiciels fait de cette nouvelle manière.
Il faudrait peut être que cela soit, plutôt que de suite vouloir faire un gestionnaire de paquet, une distribution faite sur ce mode. Proposer un "stage 1" à-la-Gentoo, qui permet d' installer une distribution avec ce mode de fonctionnement d'installation. Le but n'étant pas de faire une nouvelle distro, mais de valider totalement ce -futur- gestionnaire de paquet, en validant son fonctionnement de manière quasi-globale.
Si j'ai pas trop faux, et de toutes façons dans tout les cas, je suppose que tu as besoin d'aide ? Perso je peux pas apporter grand chose, peut être une cotisation supplémentaire chez tuxfamily.org pour que tu ai une super archi d'une part, et peut être d'autre part une machine ?
[^] # Re: Sympa ce journal
Posté par bubar🦥 . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 2.
Mais n'ayant pas les connaissances pour évaluer lvvm vs gcc, te surtout pas l'envie de rentrer dans un début philosophique me dépassant (et sachant que des argumentaires techniques peuvent y être mûs par la seule volonté de valoriser une vision philosophique). Ayant encore moins les notions permettant de jauger la qualité, les résultats, les tenants et aboutissants du bytecode vs compilé, je nepeux que me contenter de dire :
La solution "architecture" me semble belle. Et ça me plait :) Donc pas la vision purement technique sur les moyens d'y arriver mais la finalité du projet : disposer de 'binaires' initiaux très 'légers', très 'portables', et très 'indépendant'. La phase finale étant assurée par la machine cliente. Je trouve cela beau et formidable.
Un seul bémol, sur l' argumentaire :
Une éxécution super rapide chez le poste client, car optimisé aux petits oignons pour son CPU, quel qu'il soit (dernier Core i7, AMD Phenom, un PPC, un Cell, un ARM, etc)
Là j' ai des doutes. D' une part parceque les bibliothèques sont toujours ce qu' elles sont : des binaires classiquement installés. Ce qui, je présumé, grève significativement l' argument, pour une partie des fonctions d' une bonne partie des binaires logiciels fait de cette nouvelle manière.
Il faudrait peut être que cela soit, plutôt que de suite vouloir faire un gestionnaire de paquet, une distribution faite sur ce mode. Proposer un "stage 1" à-la-Gentoo, qui permet d' installer une distribution avec ce mode de fonctionnement d'installation. Le but n'étant pas de faire une nouvelle distro, mais de valider totalement ce -futur- gestionnaire de paquet, en validant son fonctionnement de manière quasi-globale.
Si j'ai pas trop faux, et de toutes façons dans tout les cas, je suppose que tu as besoin d'aide ? Perso je peux pas apporter grand chose, peut être une cotisation supplémentaire chez tuxfamily.org pour que tu ai une super archi d'une part, et peut être d'autre part une machine ?
mes deux cents.
cordialement.