>> Il y a eu une dispute il y a dix ans et X.org c'est la version "semi
>> commerciale" a utiliser si on veut faire marcher des nvidias ( c'est
> pour
>> cela que je n'en achete pas ) car on compile la base et on prends les
>> binaires correspondant a la carte. Et maintenant les codes s'écartent.
>> 
> Gni, pouvez vous m'apporter une preuve de ce que vous avancez.
J'ai compris, j'essayes ce WE de compiler radeonhd en mode org <= 6.9



>> > distribution eput sembler pertinent : plus besoin de télécharger des
>> > milliers de fichiers concernant des cartes graphiques inexistantes sur
>> > *notre* machine, mais juste télécharger les pilotes correspondant à
>> > notre matériel.
>> 
>> Le choix est parfaitement pertinent, mais la facon dont ca a été fait
> m'a
>> paru foutage de geule et destinée a dissuader de prendre en source.
>> 
> La barrière d'entrée est peut-être un peu élevée !
Le probleme n'est pas les 30 projets mais le fait qu'il y a factorielle 30
ordres possibles. Bien sur les drivers d'une famille ne doivent pas avoir
de dépendances entre eux ce qui va limiter le nombre de combinaisons.

Chez gcc il y a le core et les languages, si on veut compiler
indépoendament on prends dabord la base puis les languages. Chez geda il y
a la base et gschem, gattribs etc... ( si vous voulez je vous fais une conf
la dessus mais faut que j'y réflechisse car 6 sujets en 90 minutes ! ).Le
probleme est juste l'absence de graphique indiquant les dépendances car 30
projets en configuration de base c'est un script qui fait tar cd xyz
configure make make install cd.. pour une liste de noms.

C'est pas la premiere fois que je vois des choses géniales en technique
pure mais aucun effort pour les utilisateurs on le marketing. Résultat le
projet peut ensuite etre giclé pour ce types de raisons.

> 
>> Chez gcc par example on peut télécharger l'archive globale ou les
> modules
>> un par un mais ca reste une archive par language. Je ne vois pas trop
>> l'interret de vouloir splitter ca par instruction ( if.c else.c for.c
>> long.c return.c etc... ), ce sont des choses qui vont ensemble.
> Beaucoups
>> de projets sont modulaires avec un configure au niveau haut qui créé
> un
>> Makefile qui va rentrer dans toutes les sous directories et faire un
> make
>> dedand.
>> 
>> Avec X.org il faut i) télécharger les fichiers un par un ( lftp doit
>> pouvoir me faire du get *.tar.bz2 ) ii) les décompacter un par un iii)
>> rentrer dans les directories, a tous les coups dans le bon ordre iv)
>> compiler et installer. Je n'ai pas trouvé d'archive générale.
>> 
> lftp le fait. 
> D'autre part, je compile X.org en version modulaire tous les 3 mois (à
> chaque 
> mise à jour) et je suis très content de cette architecture modulaire
qui
> 
> m'évite de télécharger une grosse archive concernant tout un tas de
> bazar qui 
> ne m'intéressent pas.
Encore une fois ca serait mieux si c'etait par theme.

LE TRUC qui me plairrait c'est le DMX ( pas 512 ! ). Ca me permettrait
d'avoir de l'écran multiple avec des cartes a 39 euros en utilisant
diverses machines. Les conditions sont que ce soit simple ( qu'on puisse
faire du shutdown sur l'une des machines ) et que l'on puisse regarder la
télé avec. Ca progresse peut etre encore ( c'est a dire sans le mode
frame buffer ), le DMX est un serveur qui utilise les autres serveurs comme
client, il y peut etre maintenant le moyen de se connecter directement a
l'un des serveurs satélites pour les streams video ( limités a cet écran
).

Si il y avait un overview je pourrais prendre ce qui s'y rapporte. Ca n'est
pas forcement compliqué. Le probleme c'est qu'avec xfree86 on ne se posait
pas ce genre de questions donc on ne sais pas.
> 
>> > D'autre part, la compilation d'un projet tel que X.org est une tâche
>> > ardue, sur laquelle je vous recommande vivement de bien vous
> documenter.
>> 
>> xfree86 : make world et hop. Ils ne sont pas toujours a jour sur les
> modifs
>> des includes du kernel, suffit quelquefois de switcher de kernel (
> surtout
>> en regardant les dates le leur release ).
>> 
> X.org est libre, il suffit de participer et d'envoyer un patch !
C'est vrais que j'ai toujours été utilisateur avec Linux. Peut etre aussi
par manque de temps pour la gestion qu'il peut y avoir derriere. En effet
la licence GNU dit que si on ajoute une fonctionalité a un logiciel, il
faut remettre sur le serveur les modifications/le nouvelle fonctionnalité.
Le probleme c'est que si le pape du projet ( pour certains ) n'en veut pas
pour diverses raisons ( pointilleux sur les coding styles, réécriture
dans peu de temps etc... ) je vais etre obligé de maintenir un fork du
projet.


> 
>> En fait j'ai toujours cherché une solution la plus simple car je n'ai
> pas
>> besoin des fonctions 2D ni 3D, j'affiches du texte, des graphiques et
> des
>> schémas ( en gros emacs, gschem, ng-spice, vhdl, pcb, gtkwave, gerbv,
>> gsview etc... ). Par contre je possedes deux grands écrans et beaucoups
> de
>

_________________________________
Linux mailing list
[email protected]
http://lists.parinux.org/mailman/listinfo/linux

Répondre à