J'ai lu moi aussi le journal de Steckdenis. Ce que j'ai lu m'enthousiasme 
beaucoup sur les suites de l'évolution de l'administration des paquets 
logiciels au sein d'un système.
Et si tous les obstacles encore présents mentionnés par Vincent (et peut-être 
d'autres encore imprévus d'ailleurs) arrivent à être franchis les uns après les 
autres avec le temps, je crois comprendre qu'on aura un outil d'une puissance 
encore inégalée jusqu'à présent. Alors courage à tous ceux qui bossent sur le 
sujet et surtout à notre ami Steckdenis !

On est dans un domaine dans lequel GNU/Linux a déjà dépassé depuis longtemps 
les systèmes proprios en matière de technologie informatique et ça ne fera que 
creuser un écart encore plus grand, qui sera totalement irratrapable par ces 
"amateurs de l'informatique". Et donc des arguments supplémentaires pour la 
promotion du libre. Alors je dis, si la piste est vraiment bonne, FONCEZ...et 
bonne chance !!!

:-D :-D :-D

Amicalement,

Sylvio(06700)
06 68 85 44 03


> Subject: Re: [Tech] LLVM et gestion des paquets
> From: [email protected]
> To: [email protected]
> Date: Mon, 13 Sep 2010 22:49:50 +0200
> 
> 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 ***



Répondre à