Hyksos
Guru
- Joined
- May 28, 2011
- Messages
- 474
- Reaction score
- 70
Like I said in another thread I'm reinstalling the hell out of piaf currently messing with vmware and installing piaf into it from a usb key.
Works well considering the key never really knows by itself how the machine will set up the /dev/sd*.
I used iso2usb without any modifications except for messing with the sda, sdb, etc. But I guess that is for another day.
Doing that I realized that by default piaf creates problem for every install where gvoice won't be used. Yeah It's not news I have to s/load/noload for the modules in modules.conf if I don't use gvoice.
That is my question, is it really good default behavior to enable those and have the system fill the logs and ramp up memory usage for every install where gvoice is not used and the user doesn't know immediately he should noload those modules?
Ok, so it's not a bug, I posted it here since my goal is to understand why the system is delivered "broken" or assuming you will use gvoice. Let's be clear by broken I simply mean that if someone inputs no gvoice trunks and doesn't noload the modules the system is indeed not a good "state" and you eventually realize it from the ram usage of the log filling up.
I lot of stuff is in piaf/incredible that all the people don't use, I'm for that and think it's great that it's easily accessible if I need it (I love piaf like everybody for that reason) but not a lot of it actually "break" the system just because I don't use it.
I wonder what people who know more about all of it think of this and if it's by design? In a perfect world where I bounty it up to the right guy, what would be the problem if those modules where enabled when the first gvoice trunk is created and disabled when the last one is deleted? Is it all there is to it? Maybe it's not like that simply because the gvoice module was not created by someone on the piaf dev team and so it currently does not enable or disable it's "dependencies" in the modules.conf.
What am I not getting here?
Works well considering the key never really knows by itself how the machine will set up the /dev/sd*.
I used iso2usb without any modifications except for messing with the sda, sdb, etc. But I guess that is for another day.
Doing that I realized that by default piaf creates problem for every install where gvoice won't be used. Yeah It's not news I have to s/load/noload for the modules in modules.conf if I don't use gvoice.
That is my question, is it really good default behavior to enable those and have the system fill the logs and ramp up memory usage for every install where gvoice is not used and the user doesn't know immediately he should noload those modules?
Ok, so it's not a bug, I posted it here since my goal is to understand why the system is delivered "broken" or assuming you will use gvoice. Let's be clear by broken I simply mean that if someone inputs no gvoice trunks and doesn't noload the modules the system is indeed not a good "state" and you eventually realize it from the ram usage of the log filling up.
I lot of stuff is in piaf/incredible that all the people don't use, I'm for that and think it's great that it's easily accessible if I need it (I love piaf like everybody for that reason) but not a lot of it actually "break" the system just because I don't use it.
I wonder what people who know more about all of it think of this and if it's by design? In a perfect world where I bounty it up to the right guy, what would be the problem if those modules where enabled when the first gvoice trunk is created and disabled when the last one is deleted? Is it all there is to it? Maybe it's not like that simply because the gvoice module was not created by someone on the piaf dev team and so it currently does not enable or disable it's "dependencies" in the modules.conf.
What am I not getting here?