Re: Slowdown problem of a Debian package
On Mon, Jun 24, 2013 at 12:46:03PM +0900, Shigio YAMAGUCHI wrote:
> Hello again,
>
> Ron, I explained that the privilege of the database directory
> is left to the system administrator. You can change it as you
> like (user id, group id, permission, or etc).
> The purpose of 'bless.sh' script is to separate two permissions,
> that is, for running htags and for updating database referenced
> by CGI programs. So, if the database is writable, administrative
> privilege is not needed for running htags.
>
> As for 'bless.sh' script, though I know that it looks strange,
> there is no root user who invokes it without reading. It is
> important that it is essentially one line script and can be
> understood in 10 seconds. He will do the same thing by his hand.
It is not acceptable, and certainly not necessary, to provide an
interface in a distro package with a caveat of "you must audit
this yourself every time before you run it".
If people want to do that with their own hand-hacked stuff, which
they do understand all the implications of, that is fine, but this
is not an assumption you can make for users of distro packages.
People use distro packages precisely because they don't want to and
expect not to have to do that sort of thing for everything they use.
> The method of using UNIX file system as a key-value database
> is a way which is used by 'qmail' etc. No file format
> (no interpretation) is the best for security.
>
> Is the problem solved? Are any other problems left behind?
> It is obscure for me.
If your only suggestions are "this script is fine" and "if you don't
like it you can chmod 777 the secure directory instead", then no,
nothing has changed, let alone been 'solved'.
> Supposing your not answering, I would like to say as follows:
>
> Now, I would like to expect that somebody in the Debian community
> take over the maintenance job and release 'Better GLOBAL' as
> he want. It may include the programs by Ron and Taisuke.
> I know that they are very motivated things.
We already did this in 1999. In long discussions with you about what
the best possible solution that satisfied the needs of distro users
would be. You said you did not want to include those changes upstream
which was fine, but we agreed on the problems and the best solutions
that we could arrive at to them.
You keep saying "if you don't like it you can fork it", and that is
fine too, that is what we have done. But you cannot then also complain
that the fork is not following your new work as closely as you would
like, when you change many things in incompatible ways, and introduce
new questionable interfaces.
I already discussed this with you when you proposed bless.sh and/or
chmod 777 as a candidate for replacing what we did in 1999 some months
back now. I was actually quite excited by the prospect of finally
having a solution from you that we could use, and only disappointed
by the details of the actual implementation and how short it fell of
what was really needed here.
I'd be delighted to no longer have to carry a fork of this, but not
at the cost of introducing _all_ of the problems that the work we
did together back then set out to resolve. You either need to come
up with a Real solution, or accept that the incompatible changes
you have made will make them difficult to import into our fork.
Two of us now have offered you solutions and you say you don't like
them. That is your right. But refusing to accept that there is
even a problem will not make that problem go away, or make this
suitable to be included in the distro in the form you propose.
If you want to make a genuine effort to fix that, I will give you
my time to review and package it. But I cannot keep giving you
time to just repeat the same arguments, with the same refusal to
fix the problem at the end of them and no real progress to show.
> On the contrary, I am thinking of the ending support of system
> CGI by htags, because it is rarely used, and is not so important
> as a tagging system.
I already suggested that in our previous discussion, but you had
rejected that too. But if you are reconsidering this, then it
may actually be the best option of all.
I personally think that the time to kill off htags entirely has
now long passed. In 1999 it was relatively unique and possibly
the best of its breed. Today though, doxygen has long since
surpassed it for generating hypertext markup for source code,
and it even has support for using gtags with it. And it does
not have any of the problems that are at issue here. At all.
I do really think that it would be a much better use of all of
our time for you to focus on the core thing which global does,
the tag indexing, and leave the task of generating markup to
doxygen, making any improvements that may be needed _there_ if
there is still something missing from it that htags provides.
If htags is gone, then this problem does indeed just go away.
About the only person that I have been aware of who still is
interested in htags has been Taisuke. My impression also is
that it is rarely used.
So I am interested in any reasons that Taisuke might have for
why doxygen is not a sufficient solution to use.
If there turns out to be no reason not to use it instead, then
I very much think that this is the way forward we should follow.
There is no reason to try to reproduce what it does if it is
now doing it much better than we do and it has the mindshare of
many more developers supporting it.
What do you think?
Cheers,
Ron
Reply to: