[openbeosnetteam] Re: our package
- From: Lars Hansson <lars-openbeos-net@xxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 02 Sep 2004 10:57:33 +0800
Waldemar Kornewald wrote:
That is what I searched for as the best solution. :)
I can try to write a small perl script that translates those etc files into structures
and then we can import it into our libbind. I cannot imagine that "services"
changes often (if at all)I will try to integrate the following into libbind and libnet:
Not often but they do change, at least services.
And there are good reason for why at least services should be
user/system configurable.
Axel already stated he prefers plain text config files so i dont see why
it would be a big problem keep 'services' around, the average user
rarely touches it anyway but for those who needs to mess with it it's
nice if it is stored in a file somewhere. Of course it doesnt have to be
called 'services'.
'protocols' can probably safely be put into libraries though.
Is /etc/networks only used by "route"? If so, we could possibly drop it? :)
What is left is only resolv.conf. We should at some point replace it with a kernel DNS handler (which could support temporary and static DNS entries, I wrote this too often).
Another option here is to have a dns proxy daemon (NOT nameserver) that
handles dns lookups, ie something like pdnsd
(http://www.phys.uu.nl/~rombouts/pdnsd.html).
I dont think putting the dns lookup task inside the kernel is a good idea.
/boot/system/config would be better, IMHO. That would allow the same naming
scheme as in /boot/home/config.
But we already have /boot/system/add-ons. Should we replace it with a link and
move the folder to /boot/system/config (or /boot/config?) in order to be more
consistent with the /boot/home/config directory structure?
add-on's arent configuration files so imho they shouldnt be put in a
configuration location.
---
Lars Hansson
Other related posts:
