Cloop est une solution assez lourde: il faut 1G de RAM+SWAP pour générer le fichier comprimé de knoppix.
En plus même la nouvelle version 2 ne compile pas sur le 2.6 (l'interface des périphériques blocks a changé).
La solution gcloop est intéressante: détourner la possibilité de chiffrement du périphérique loop pour décompresser. cloop reprend beaucoup de code de loop, autant utiliser loop carrément, non? Mais apparement les développeurs de gcloop ont du modifier le loop du kernel quand même.
Dans les deux cas ce sont des modules externes au noyau à compiler.
Le plus simple à mettre en oeuvre est cramfs. Il est inclus dans le noyau standard et mkcramfs est dans toutes les distributions.
squashfs est un patch à appliquer au noyau. Il y a un utilitaire (mksquashfs) pour créer le fichier comprimé. C'est un poil plus lourd que cramfs (à cause du côté non intégré partout) mais la génération est moins lourde qu'avec cloop.
Bref Slack a pris une solution simple mais efficace, là ou knoppix cherche plutôt une efficacité et une performance à l'utilisation.
Une bonne idée serait de générer des isos identiques (quant au contenu) avec toutes les solutions et de mesurer les performances (chargement, utilisation (accès, accés multiple, utilisation de la mémoire, etc...)
[^] # Re: Slackware Live CD
Posté par fleny68 . En réponse à la dépêche Slackware Live CD. Évalué à 7.
En plus même la nouvelle version 2 ne compile pas sur le 2.6 (l'interface des périphériques blocks a changé).
La solution gcloop est intéressante: détourner la possibilité de chiffrement du périphérique loop pour décompresser. cloop reprend beaucoup de code de loop, autant utiliser loop carrément, non? Mais apparement les développeurs de gcloop ont du modifier le loop du kernel quand même.
Dans les deux cas ce sont des modules externes au noyau à compiler.
Le plus simple à mettre en oeuvre est cramfs. Il est inclus dans le noyau standard et mkcramfs est dans toutes les distributions.
squashfs est un patch à appliquer au noyau. Il y a un utilitaire (mksquashfs) pour créer le fichier comprimé. C'est un poil plus lourd que cramfs (à cause du côté non intégré partout) mais la génération est moins lourde qu'avec cloop.
Bref Slack a pris une solution simple mais efficace, là ou knoppix cherche plutôt une efficacité et une performance à l'utilisation.
Une bonne idée serait de générer des isos identiques (quant au contenu) avec toutes les solutions et de mesurer les performances (chargement, utilisation (accès, accés multiple, utilisation de la mémoire, etc...)