Salut Vincent Y a pas mal de cas un peu particuliers comme ça. J'en ai un peu parlé avec l'auteur, il sait quels sont les points qui peuvent potentiellement poser problèmes (les codes qui dépend de l'architecture, les librairies liées statiquement, les build-deps, etc, pas mal de points ont d'ailleurs été débattus dans les commentaires de l'article). De toute façon, il faudra patcher lourdement les paquets si on veut absolument qu'ils sortent du bytecode portable, et éventuellement, certains paquets précompilés pour des codes qui posent problème sur une ou plusieurs archis.
De toute façon on est là en terrain complètement inexploré, va effectivement y avoir pas mal de soucis auxquels on s'attend pas, va falloir trouver des solutions intelligentes, etc. Je sais pas si ça va marcher ou pas, mais quoi qu'il en soit, ça sera intéressant :-) En ce qui concerne la comparaison de taille, il donne des chiffres, la différence est quand même notable... le souci... c'est que du binaire, ça passe très bien à la compression, le bytecode beaucoup moins. Au final, une fois le paquet compressé, la différence de taille est plus si significative :-/ Content en tout cas que ça intéresse quelqu'un. Pour le coup c'est vraiment technique, mais vraiment intéressant 8D A pluche Le lundi 13 septembre 2010 à 22:38 +0200, Vincent a écrit : > Léo Testard wrote: > > Je vous laisse le lire et me dire ce que vous en pensez : > > http://linuxfr.org/~steckdenis/28718.html > > L'idée est intéressante, et l'auteur semble motivé. Peut-être un peu > trop motivé pour garder la tête complètement froide :) Je note, en lisant : > > - "le bytecode est largement plus petit que le code compilé" > > Ca, j'aimerais bien voir des chiffres pour comparer. Enfin je veux bien > que ça évite les archives par architecture. > > - "on supporte toutes les architectures que LLVM supporte" > > Pas faux, mais d'un autre côté, "exit" les routines assembleurs SIMD > pour tous les softs multimédias et autres. A moins de pouvoir malgré > tout ajouter des parties pré-compilées natives ? > > - "les LiveCD qui doivent être précompilés sont générés très facilement > et rapidement" > > Déjà que quand on se contente d'installer des .deb c'est long, alors je > ne vois pas comment en compilant du .ll pré-compilé ça va accélérer les > choses. Evidemment, tout dépend de ce qu'on appelle "long"... > > - "(donc juste les libs à passer en paramètre -l à ld)" ... "Pas besoin > de build-dependecies, tous les fichiers .h ont été parsés, et le code se > trouve directement dans le fichier bytecode." > > Ca, ça se contredit un peu. D'un côté il faut "linker" contre des libs, > mais on n'a pas besoin de dépendances ? > > ...enfin il ne faut pas que ton copain s'arrête à mes râleries, hein. > C'est toujours plus facile de lister une tonne d'inconvénients que > d'écrire un prototype. Alors bon courage à lui. > Diffusez cette liste aupres de vos relations :-) Linux Azur : http://www.linux-azur.org Vous etes responsable de vos propos. *** Merci de rediger sans SMS, ni HTML ni PJ ***
