A general question : is it better to have one big module than several small modules?
Thank you for kind attention.
Salix Live 13.1 modules
Re: Salix Live 13.1 modules
Making one big module is much simpler especially if it is meant to be a personal LiveCD.ikke wrote:A general question : is it better to have one big module than several small modules?
Thank you for kind attention.
The reason Salix Live uses 3 main modules plus a few others is mainly related to the need of the live installer. We need to be able to offer a true Salix vanilla core, basic or full install from the Live CD just like Salix standard iso does.
Furthermore, when we will offer different Salix Live versions, they will use a common base & some common modules while differing extra modules will determine for example if either XFCE or LXDE is used.
What really matters is where you are going, not where you come from.
Re: Salix Live 13.1 modules
Thank you for reaction.
Appreciate the way you are handling the base modules. That's your responsibility. And you do it very well.
My question was about the modules made by the user.
Best Regards,.
Appreciate the way you are handling the base modules. That's your responsibility. And you do it very well.
My question was about the modules made by the user.
Feel it is simpler to make many smaller modules : easier to maintain. But maybe they take more space. Or other disadvantages?Akuna wrote: Making one big module is much simpler especially if it is meant to be a personal LiveCD.
Best Regards,.
Re: Salix Live 13.1 modules
Ok, for user modules, it depends on the size/scale.
For each module, a loopback interface is created/used, and a branch is used in aufs2.
Theorically, using multiple modules instead of one big could create a little overhead (mutliple compression headers, multiple inode tables, identical chunks in different modules will be duplicated). But I feel this overhead is very limited.
I, however, advise no to use a module per package if you use, let's say more than 10 packages. Better to add them in one module instead, like this for example :
As a conclusion, aggregate your packages in modules in functionnal way is the good solution. But you can do as you want, if you don't reach hundreds of modules.
For each module, a loopback interface is created/used, and a branch is used in aufs2.
Theorically, using multiple modules instead of one big could create a little overhead (mutliple compression headers, multiple inode tables, identical chunks in different modules will be duplicated). But I feel this overhead is very limited.
I, however, advise no to use a module per package if you use, let's say more than 10 packages. Better to add them in one module instead, like this for example :
Code: Select all
# mkdir mymodule
# export ROOT=$PWD/mymodule
# for p in *.txz *.tgz; do installpkg $p; done
# unset ROOT
# dir2lzm mymodule mymodule.lzm
Re: Salix Live 13.1 modules
Thank you very much. Feel I will follow your advice and make some 3-4 bigger modules instead of the 12-13 I have now.JRD wrote:Ok, for user modules, it depends on the size/scale.
For each module, a loopback interface is created/used, and a branch is used in aufs2.
---
As a conclusion, aggregate your packages in modules in functionnal way is the good solution. But you can do as you want, if you don't reach hundreds of modules.
Would like to state that being able to add your my own modules is one of the main reasons I am using everywhere Salix Live 13.1 installed on an usb-stick.
Merci beaucoup.