<br><br><div><span class="gmail_quote">On 7/3/07, <b class="gmail_sendername">Gürer Özen</b> &lt;<a href="mailto:gurer@pardus.org.tr">gurer@pardus.org.tr</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sunday 01 July 2007 22:17:41 Nicolas Lara wrote:<br><br>&gt; As promised I expanded my proposal to better explain the idea of the config<br>&gt; manager.<br><br>Thanks, well prepared, took a bit of time to read it, here are my thoughts:
<br><br>Monitoring /etc seems a very good idea. It is not limited to a local copy, you<br>can keep several servers&#39; configuration in a central repository for example.</blockquote><div><br>Good idea :)&nbsp;&nbsp; Im thinking that with that maybe having interesting configurations available for download could also be done in the future. (something like: I want apache configured with cacti and virtual hosts.. well, lets downloaded from the config repo...).
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I didn&#39;t understand the &quot;adding inotify module to kernel&quot; part, if you are
<br>talking about inotify support, that is already included in all Pardus kernels<br>as it is very useful and used in many places. If you talking about our /etc<br>monitor application, that is bad design to put something belongs to userspace
<br>to the kernel.</blockquote><div><br><br>I didn&#39;t know the support was already in the kernel. I just did ls /dev/inotify&nbsp; and assumed the, since the device wasn&#39;t there, that the kernel was not build with inotify support. Of course the monitoring app should be in userspace :)
<br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Config API is hard to evaluate. Hopefully it can be implemented as a python<br>
module in separate package, and can be used in some packages to test.<br><br>Provide part is not necessary. You can already create a class in Comar model,<br>and configure the application with a separate script providing such class.
</blockquote><div><br>I don&#39;t understand much of Comar because i haven&#39;t used it too much and there&#39;s not much documentation in english. I liked a lot the provide part :p, but if comar already handles it better.
<br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For user settings, it is best to not mix package-manager in and use a custom<br>
settings application.</blockquote><div><br>You mean to create an application to manage user settings? That is the same thing I propose for user settings only that the config scripts should come with the packages.<br>&nbsp;</div>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">_______________________________________________<br>Pardus-devel mailing list<br><a href="mailto:Pardus-devel@pardus.org.tr">
Pardus-devel@pardus.org.tr</a><br><a href="http://liste.uludag.org.tr/mailman/listinfo/pardus-devel">http://liste.uludag.org.tr/mailman/listinfo/pardus-devel</a><br></blockquote></div><br><br>Thanks for the reply :)<br clear="all">
<br>-- <br>Nicolas Lara<br>Linux user #380134<br>Public key id: 0x152e7713 at <a href="http://keyserver.noreply.org/">http://keyserver.noreply.org/</a><br># Anti-Spam e-mail addresses:<br>python -c &quot;print &#39;@&#39;.join([&#39;nicolaslara&#39;, &#39;.&#39;.join([x for x in reversed( &#39;com|gmail&#39;.split(&#39;|&#39;) )])])&quot;
<br>python -c &quot;print &#39;@&#39;.join([&#39;nicolas&#39;, &#39;.&#39;.join([x for x in reversed( &#39;ve|usb|labf|ac&#39;.split(&#39;|&#39;) )])])&quot;