enlightenment-users

When I load or unload a module I get the following=20
[jim@... ~]$ enlightenment_remote -module-load monitor
WARNING: Weird line in resolv.conf: ; generated by NetworkManager, do not e=
dit!
WARNING: Weird line in resolv.conf: ; Use a local caching nameserver
controlled by NetworkManager
[jim@... ~]$ enlightenment_remote -module-unload weather
WARNING: Weird line in resolv.conf: ; generated by NetworkManager, do not e=
dit!
WARNING: Weird line in resolv.conf: ; Use a local caching nameserver
controlled by NetworkManager
[jim@... ~]$
I use NetworkManager For My wireless connections. =20
Why is E reading /etc/resolv.conf ?? =20
Last Night I removed everything E related. all rpms the entire .e
directory and started from scratch. Eclair still will not run and
the weather module sucks after this latest round of updates. last time
the weather module worked was with cvs version 0807 built by Didler.
granted the Segfults in E are not as prevelant as before but I like
these 2 apps.
System Specs =20
FC4=20
~ 1.5 pentium M=20
~ Centrino package=20
~related software
2.6.12-1.1398_FC4
gcc-c++-4.0.1-4.fc4
gcc-gfortran-4.0.1-4.fc4
libgcc-4.0.1-4.fc4
gcc-4.0.1-4.fc4
--=20
Registered Linux User: #376813
http://www.fedorajim.homelinux.com

On Friday, 26 August 2005, at 11:19:54 (+0900),
Carsten Haitzler wrote:
> It's trying to be friendly and read everything for you! :) seriously
> - e has its own dns lookup code because gethostbyname is a blocking
> call. this is actually only used if making remote connections, but
> it has to parse /etc/resolve.conf to know what to do. this means
> ecore_con is then capable of doing nslookups asynchronously - not
> holding the process hostage to waiting for a dns lookup timeout or
> reply. it always parses this data wehn starting up the connections
> subsystem (ecore_con) but it doesnt mean its making remote
> connections.
This is a horrific hack. It doesn't even take into account nsswitch
settings.
There are numerous ASYNC DNS packages out there to be used. Why not
use one?
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@...>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"Applying computer technology is simply finding the right wrench to
pound in the correct screw." -- Unknown

On Wednesday, 31 August 2005, at 09:16:33 (+0900),
Carsten Haitzler wrote:
> > There are numerous ASYNC DNS packages out there to be used. Why not
> > use one?
>
> we looked at 2
Heh. "Numerous" turned out to be 3; most of the ones I was thinking
of were actually all ADNS (which is GPL).
> 2. the other wasn't even included in debian's massive list of packages - that
> means users now have to go fine another lib they need and compile and install
> it - and we don't provide it. it was a tossup here, but i don't think any of us
> was that happy about sucking in an external build dep just for this simple
> thing, thus sebastien implemented dns lookups. he did the hard bit - reading
> the rfc's and doing the network protocol handling. the easy stuff is left to
> do :)
I'm not sure I'd agree that NIS/YP and LDAP are "easy stuff."
But ecore already has hooks for spawning subprograms and getting
callbacks, right? Why not write a wrapper around gethostbyname() that
ecore_con would spawn? That way we wouldn't have to rewrite the whole
damn thing. (Although if we do, we should make it a separate
project.)
Another idea I had: What about a standalone GPL daemon program that
communicates via IPC and uses ADNS? Client programs wouldn't link to
it, so no viral infection. Thoughts?
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@...>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"If the homo sapiens were, in fact, *homo* sapiens, is that why
they're extinct?" "Joey, homo sapiens are people." "Hey, I'm not
judging!" -- Joey Tribbiani and Ross Gellar, "Friends"

On Tue, 30 Aug 2005 22:01:57 -0400 Michael Jennings <e-users@...> babbled:
> On Wednesday, 31 August 2005, at 09:16:33 (+0900),
> Carsten Haitzler wrote:
>
> > > There are numerous ASYNC DNS packages out there to be used. Why not
> > > use one?
> >
> > we looked at 2
>
> Heh. "Numerous" turned out to be 3; most of the ones I was thinking
> of were actually all ADNS (which is GPL).
>
> > 2. the other wasn't even included in debian's massive list of packages -
> > that means users now have to go fine another lib they need and compile and
> > install it - and we don't provide it. it was a tossup here, but i don't
> > think any of us was that happy about sucking in an external build dep just
> > for this simple thing, thus sebastien implemented dns lookups. he did the
> > hard bit - reading the rfc's and doing the network protocol handling. the
> > easy stuff is left to do :)
>
> I'm not sure I'd agree that NIS/YP and LDAP are "easy stuff."
how many people do dns via nis/yp or ldap? sure - nice theory - but actually do
dns VIA that? i knwo dns servers are oftne BACKED by ldap as such - but other
than very specific special cases in niche areas - actual dns VIA nis/yp or
ldap... i don't know.
> But ecore already has hooks for spawning subprograms and getting
> callbacks, right? Why not write a wrapper around gethostbyname() that
> ecore_con would spawn? That way we wouldn't have to rewrite the whole
> damn thing. (Although if we do, we should make it a separate
> project.)
AFTER seb had written the dns procotol handling that came to mind and i
suggested it... but i have to say i respect seb's work on doing th edns
protocol handling and reading the rfc's etc. and i dont see just nuking the
code as good. i am leaving it in seb's hands for now. it needs completeness
handling. i dont see ldap/nis/yp as usefully worth implementing and if you
happen to have a system with these setups - then fall back to blocking
gethostbyname is an option :) something about a librarye forking off child
processes seems a bit evil to me - and thus i hesitate on it. but then again
re-implementing dns is evil too :)
> Another idea I had: What about a standalone GPL daemon program that
> communicates via IPC and uses ADNS? Client programs wouldn't link to
> it, so no viral infection. Thoughts?
that's possible - but its a service that has to sit around and be managed. i'd
much sooenr go with the fork off a child to dns lookup via gethostbyname then
punt the retuned data via fd back to the parent method long before this :)
> Michael
>
> --
> Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@...>
> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
> -----------------------------------------------------------------------
> "If the homo sapiens were, in fact, *homo* sapiens, is that why
> they're extinct?" "Joey, homo sapiens are people." "Hey, I'm not
> judging!" -- Joey Tribbiani and Ross Gellar, "Friends"
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> enlightenment-users mailing list
> enlightenment-users@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
裸好多 raster@...
Tokyo, Japan (東京 日本)

On Wednesday, 31 August 2005, at 11:59:43 (+0900),
Carsten Haitzler wrote:
> how many people do dns via nis/yp or ldap? sure - nice theory - but
> actually do dns VIA that? i knwo dns servers are oftne BACKED by
> ldap as such - but other than very specific special cases in niche
> areas - actual dns VIA nis/yp or ldap... i don't know.
It's not DNS via NIS/YP. It's name resolution via NIS/YP. It's
really no different than using /etc/hosts. Just like /etc/passwd is
the local file which can supplement NIS or LDAP account info,
/etc/hosts can supplement NIS/LDAP host resolution. And yes, it's
done, usually in Windows-centric (Active Directory) setups that want
to use WINS and ADS without having to set up DNS.
> AFTER seb had written the dns procotol handling that came to mind and i
> suggested it... but i have to say i respect seb's work on doing th edns
> protocol handling and reading the rfc's etc. and i dont see just nuking the
> code as good. i am leaving it in seb's hands for now. it needs completeness
> handling. i dont see ldap/nis/yp as usefully worth implementing and if you
> happen to have a system with these setups - then fall back to blocking
> gethostbyname is an option :) something about a librarye forking off child
> processes seems a bit evil to me - and thus i hesitate on it. but then again
> re-implementing dns is evil too :)
Yeah, it's a lesser of two evils thing. The problem with the current
method is that the standard dictates checking nsswitch *before* doing
the lookup and potentially not using DNS at all. Honestly I think
forking a new process/thread (just fork(), no exec(), maybe vfork() if
possible?) is cleaner than trying to re-implement not only DNS but
nsswitch too.
> that's possible - but its a service that has to sit around and be
> managed. i'd much sooenr go with the fork off a child to dns lookup
> via gethostbyname then punt the retuned data via fd back to the
> parent method long before this :)
Fair enough. :)
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@...>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"I want to stand with you on a mountain. I want to bathe with you
in the sea. I want to lay like this forever, until the sky falls
down on me." -- Savage Garden, "Truly, Madly, Deeply"

On Tue, 30 Aug 2005 23:14:40 -0400 Michael Jennings <e-users@...> babbled:
> On Wednesday, 31 August 2005, at 11:59:43 (+0900),
> Carsten Haitzler wrote:
>
> > how many people do dns via nis/yp or ldap? sure - nice theory - but
> > actually do dns VIA that? i knwo dns servers are oftne BACKED by
> > ldap as such - but other than very specific special cases in niche
> > areas - actual dns VIA nis/yp or ldap... i don't know.
>
> It's not DNS via NIS/YP. It's name resolution via NIS/YP. It's
well dns == dynamic name resolution... i was being loose with my terms i
admit :)
> really no different than using /etc/hosts. Just like /etc/passwd is
> the local file which can supplement NIS or LDAP account info,
> /etc/hosts can supplement NIS/LDAP host resolution. And yes, it's
> done, usually in Windows-centric (Active Directory) setups that want
> to use WINS and ADS without having to set up DNS.
ugh! ok - point taken - i dont live in any of those setups... ever! :)
> > AFTER seb had written the dns procotol handling that came to mind and i
> > suggested it... but i have to say i respect seb's work on doing th edns
> > protocol handling and reading the rfc's etc. and i dont see just nuking the
> > code as good. i am leaving it in seb's hands for now. it needs completeness
> > handling. i dont see ldap/nis/yp as usefully worth implementing and if you
> > happen to have a system with these setups - then fall back to blocking
> > gethostbyname is an option :) something about a librarye forking off child
> > processes seems a bit evil to me - and thus i hesitate on it. but then again
> > re-implementing dns is evil too :)
>
> Yeah, it's a lesser of two evils thing. The problem with the current
> method is that the standard dictates checking nsswitch *before* doing
> the lookup and potentially not using DNS at all. Honestly I think
> forking a new process/thread (just fork(), no exec(), maybe vfork() if
> possible?) is cleaner than trying to re-implement not only DNS but
> nsswitch too.
thats true - the fork will be really lean as its copy on write only a small
stack segment will be copied over. and yes - i admit - we need to honor
nsswitch etc. etc. etc. if doing dns DIY. :)
> > that's possible - but its a service that has to sit around and be
> > managed. i'd much sooenr go with the fork off a child to dns lookup
> > via gethostbyname then punt the retuned data via fd back to the
> > parent method long before this :)
>
> Fair enough. :)
it's all a matter fo levels of evil i guess. god damn why did they not just
impement a proper async dns lookup to start with in libc! ARGH! fools! :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
裸好多 raster@...
Tokyo, Japan (東京 日本)

On Wed, 31 Aug 2005 15:47:10 -0400 Michael Jennings <e-users@...> babbled:
> On Wednesday, 31 August 2005, at 15:29:14 (+0200),
> Bertrand Jacquin wrote:
>
> > There's a librarie which do Async DNS resolv with a "AS-IS" license :
> > C-ares : http://daniel.haxx.se/projects/c-ares/
> > Hope that could help
>
> Debian doesn't have c-ares, but it does have the older ares library:
>
> http://packages.debian.org/cgi-bin/search_packages.pl?keywords=ares&searchon=names&subword=1&version=all&release=all
>
> Raster, what do you think?
oh god back to this. ok - for now i think keep what we have. it seems to work -
either go the fork child to gethostbyname or complete what we have is the way
to go. if we dont complete what we have soon i might just make a fork() version
of it :) seb? what do u think??
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
裸好多 raster@...
Tokyo, Japan (東京 日本)