[ Thread Index |
Date Index
| More lists.tuxfamily.org/slitaz Archives
]
>> Le kernel n'a besion que de peu de choses pour lancer Slitaz. C'est le
>> bootloader qui fait tout. On peu donc compiler un maximum de choses en
>> module (drivers ide/scsi, filesystems... ). Il suffit qu'il puisse
>> exploiter le rootfs. On peut alors imaginer un script de boot qui
>> efface les modules inutilisés dont on est sûr qu'il ne seront pas
>> nécessaires pour le hotplug (c'est là tout le problème). Ca renderait
>> de la mémoire pour firefox...
>
> Juste, mais là tous les modules compressés avec son = ~2 Mb, si on fait
> un truc sound=no on gagne 1,4 Mb, il reste donc 600 Ko de mods, faut
> il vraiment les supprimer ?
Le jeu n'en vaut pas la chandelle en effet. Et puis avec le parametre
config=<device>,<script> chacun peut le faire s'il le veut ;^)
>
> Maintenent si on tente de mettre plus de drivers en mods on peut faire
> descendre le kernel à 1 Mb contre 1,6 environ, mais sa nous fait écrire
> des scipts de detection automatique... pour carte réseau, PCMCIA,
> IDE,...
>
> Il me semble que le kernel standard devrait contenir le support IDE,
> sinon on devrat aussi faire un rootfs ou un init en cas d'installation.
> En ce moment, pas besoin de se poser de questions, copie de tous le CD
> sur le disque, rm init et reboot.
Keep it simple. J'ai dit une bêtise.
>
>> Il serait peut-être intéressant de gérer les distributions sur le
>> mirroir. Une distribution serait un ensemble cohérant des packages
>> géré par tazlito.
>
> C'est pensé comme cela depuis le début.
>
>> Cela permettrait de définir des versions spécialisés : router,
>> cellphone, pbx,
>> office, virtualizer, development...
>>
>> Accessoirement, cela permetterait de savoir exactement de quelle
>> configuration
>> logicielle dont on parle.
>
> Exact, chaque liste contient la liste des paquets et pourrait contenir
> tes propositions SHOT_DESC, MINIMU_... En ce moment c'est un peut
> comme Mercurial, cd dans le répertoire de la distro qui contient tous
> les fichiers (liste des paquets et tazlito.conf). On pourrait donc
> aussi rajouter les variables que tu propose dans ce fichier, mais il me
> semble effectivement plus judicieux de centraliser et modifier Tazlito
> en conséquence.
>
>> exemple /var/lib/tazlito/distributions.list:
>> base-1.0
>> media_box-0.2
>> router-0.1
>>
>> exemple base-1.0.tazdist:
>> SHORT_DESC="SliTaz base distribution"
>> MINIUM_RAM_SIZE="96Mb"
>> ISO_SIZE="25878528"
>> ================================================================================
>> atk 1.12.4 x-window
>> atk-dev 1.12.4 x-window
>> base-files 1.0.1 base-system
>> ...
>
> En suite, dans le genre :
>
> # tazlito gen-distro flavor=base-1.0
>
>> >> Le package lzma est nécessaire pour fabriquer linux-lzma, unlzma
>> >> est déjà inclut dans slitaz.
>> >
>> > Faut lzma sur le LiveCD/RAM pour reconstruire des ISO en live, on
>> > peut le mettre dans base-apps non ?
>>
>> Vu que ca ne sert que pour fabriquer des packages, slitaz-toolchain
>> serait plus
>> aproprié. Idem pour bash.
>
> La toolchain sur le LiveCD ? Bash ok mais... Si on fait de CD avec
> saveurs on peut faire un LiveCD slitaz-devel proposant toolchain minimal
> et tcc (gcc va jamais tenir dans moins de 30 Mb, non ?) + Ruby/Python
> par exemple mais sans le renard...
>
> Et j'insiste. Je pensais faire un script qui génére un LiveCD depuis un
> système Live en fonctionnement, genre une image du système, on copie le
> tout dans un rootfs, on compresse avec lzma et on génére une ISO ?
J'avais oublié qu'il fallait compresser rootfs... A-t-on vraiment besion
de bash pour
installer des packages ? L'idée était d'alléger le LiveCD au contraire.
En tout cas, il n'y a pas de raisons d'installer slitaz-toolchain dans le CD.
>
> On fait un dépôt Mercurial pour slitaz-tools afin qu'on puisse bosser
> sur Tazlito ou Tazlito a droit à son propre dépôt ?
Up2U
>
> Et... comment on nomme le nouveau rootfs... rootfs.lzma (trop long)...
> taz.lzm... ?
rootfs ?
---
SliTaz GNU/Linux Mailing list.
Web site : http://www.slitaz.org/