a few ideas

[Stefan Wold]

On Sat, 4 Mar 2006, Jean Michel Bruenn wrote:

> Dear lunar community,
>
> i have some ideas cause of Lunar itself, perhaps you like one or more of my ideas
>
> 1.) Autoupdates
> 2.) Autooptimizations
> 3.) Fastest mirror detection
> 4.) Security patches/bugfixes
> 5.) Timecheck/Statistics
>
> 1.) Autoupdate
> When this feature is enabled, it should run as a cronjob. It Should update modules. When compiling of a module failes the script should resurrect the old running module. After it the script 'could' mail the User/Admin of the System informations about the update.
>

As far as I know this feature kinda exist already, even though I never 
used the ability. You can enable mail reports in the feature menu. And 
adding a cronjob to do "lunar update" is possible already and it is a 
minor effort.

>
> 2.) Autooptimizations
> When the user comes into the lunar optimize dialog there could be a button like "Check it automatically" we get most informations automatically, why we don't use them automatically?
> We see MMX, SSE, SSE2, SSE3, 3dnow, CPU, and we have some RECOMMENDED settings - With an automatically check, we could use the stuff we 'see'.
> There's should be no need to use this detection script - It's only a nice-to-have for some users - and after it the user should check all settings again, the script could print out the detected settings to let the user check them.

Even though it would be pretty simple to do I think it is a bit to 
dangerous. Most of those features arn't always safe. And users tend to use 
features like that because they automaticly would believe it's safe since 
we added it there.


> 3.) Fastest mirror detection
> I would, if users like such a thing, write this script. In the mirror dialog should be a little cute button "Fastest mirror detection" if a user hits it, the script will tracepath and 'maybe' ping all mirrors ('maybe' cause, if 400 lunar users ping the same host, it could look a bit.. strange.. EVIL) - With the Data our script found we sort the mirrors and print out a list what we would choose. The user could choose then "use our detected list" "edit one or more of this mirrors" "..i choose it better myself"
> as i think, a good feature again... I think it's good when users from xyz-country use mirrors from xyz-country they will be faster than mirrors from zyx.

Ping and traceroute isn't necessarily a good way to messure best mirror. 
There are other ways to choose the one closest to you based on country of 
resident. But I don't find it to be a problem choosing the mirror I know 
are best for myself manually.


> 4.) Security patches/bugfixes
> Perhaps we should have an own directory and specific ppl for security patches and bugfixes, if there's a new patch for openssl as example, we don't have to edit the openssl-module, we have to edit or write a patch to the security-modules - directory. So that we could have module-admins especially for security issues/patches without need to change original modules. That could made by a little function like check_for_patches_in_moonbase(); ^.^ Well i don't know if this is a good idea or not but so we could
>  * keep modules clean
>  * have specific ppl for security updates/patches
>  * The user Could choose - Want to use security updates or not.

In my opinion devs should already patch moonbase if there is a security 
issue, or bump the version.



> 5.) Statistics
> Definatly a 'nice-to-have' not a needed feature. Striker wrote if i remember right a little script what shows the needed time for compiling a module - Maybe we could make a little page in Lunar with Statistics and include this script froms striker to the lunar tools i like this script. on Such a statistic page we could show informations about failed and compiled modules, Used Space for lunar Cache, Used Space what we could Prune, Perhaps statistics from ccache if the user have it installed and such things. We could make with this Data for-fun-benchmarks too. But as i said.. only a nice-to-have not a really needed feature.


Would be interesting if there was a report home feature for this (a toggle 
feature of course) which grab cputype and compile time for certain 
packages to make average compile times available.

Sincerely
Stefan Wold