gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] experimental debian packages


From: Igor Wronsky
Subject: Re: [GNUnet-developers] experimental debian packages
Date: Sun, 9 Feb 2003 10:58:29 +0200 (EET)

On Sat, 8 Feb 2003, Christian Grothoff wrote:

> I think we should probably change the GNUnet code to fallback to
> /etc/gnunet.conf if ~/.gnunet/gnunet.conf is not found. Is /etc/gnunet.conf a
> good location? Or should it be /etc/gnunet/gnunet.conf? Or
> /var/gnunet/etc/gnunet.conf? Where should the "shared", systemwide gnunetd
> databases be placed anyway? I would think /var/gnunet/ would be the most
> appropriate thing. Any other opinions?

Just put them compile time configurable and leave it up to the
distro makers to decide where they should be. /etc and /var are
sensible defaults imho. You perhaps shouldn't create etc subdir
if we have only one cfg file.

> > I think having some stats in gnunet-gtk would pretty nice as well.
> Well, either do it yourself or add a feature request to Mantis to make someone
> else do it, I guess. I think Igor's priority for GTK will rather be segfaults
> & memory leaks for now, but I could be wrong...

Well, you are wrong, in the sense that for two zeroes, !(0>0)
is true ;) . To put it more plainly, I'm not interested in working
on gnunet-gtk at the moment. I admit its faults, of course.
but most of the problems are too evasive, or don't appear
on my system, or are relatively unimportant (in the current
context - but of course its a chicken/egg problem, if the
gui sucks, the system might look bad, but if there's
nothing in the network, what need for awesome gui?). When I
enhanced the GUI some time back, the reasons were both to make
it more reasonable and to get a bit of whiff of how the gnunet
clients work. But actually I've always hoped that someone who
really knows gui coding would take it from there. A good sign of
healthy system would of course be the mushrooming of third-party
independent clients and GUIs, but both remain yet to come.


ps. I do have some non-zero priority for getting rid of
the 300mb lookup database (its mostly unnecessary layer now
that we have the bloom filters), but I wouldn't oppose if
someone gets to it first. ;)


Igor





reply via email to

[Prev in Thread] Current Thread [Next in Thread]