23 Sep 2000
(updated 24 Sep 2000 at 08:32 UTC) »
I looked at a number of trouble ticket and bug tracking
systems in the last two days. To put it mildly: they all
I'm astonished that the majority of them, especially the
ones, are web-based. Hey, people, get a clue:
- discussions with clients is best done through
- email has lower turnaround times.
- if done correctly email is more secure, especially if
use passwords. [use a one-time key for each trouble
and let the customer decide with whom he wants to
this]. This obviously isn't that important in for
Well, maybe it's just me, but i don't want to use a web
to update the state of a ticket after i resolved the thing
with the customer. I just want to set the state to
in the last mail i send.
Apart from that email is just more easy - to use and to
And all i've seen seem to be a bit unflexible. I'm not going
introduce different task-systems for company hotline
(non-software customers), software customer support and
developers internal stuff. My cow-orkers would kill me
i finish the sentence, i think.
In other words: the basic design has to be very, very
There is nothing wrong with having a web interface (aside
the simple fact that i will not use it if i don't need to
use it), but
being forced to use one? Heck, no.
And you can't easiely put something else about a web
but you can create some kind of web interface for almost
without too much work.
I also went through my personal todo list:
- BBS software: decided to not work on it anymore. Not
bug fixing. It's not something i want to continue
I wouldn't design it like this, and the basic design
1988 or so (and the UI is even older).
- gateway: will rewrite it. The basic design is
still ok, but i' m a better coder today, and have
learned a few
lessons. Beside that: I now have some libraries with
have in 1993, and they _will_ make the thing more
But the change is quite fundamental, and anyway, the
way to get rid of bloat and historical workaround in
to rewrite it.
Schedule: don't know.
- utftpd: i'll rewrite it. The configuration file
is fine, except there shouldn't be a configuration
at all. Yeah, it's highly flexible. And this is not
I'll keep the one client, one TFTP server
design for now, but will cleanup the server if i
to find something which wouldn't work in a single
design. I'm still unsure whether multicast TFTP is
Mind you, utftpd has been written to backup my router
Schedule: This year.
- udpserver: decided to finish it. I need something
like this to start the TFTP server.
- syslog server: decided to finsish it. I do not really
(except that linux sysklogd is horrible), but a clean
reliable implementation of a syslog daemon which
fill the disk is worthwhile. [takes and translates
input, sends it to multilog]
Schedule: Soon. What needs to be done is to write
a useful configuration tool.
Originally i didn't ever want to use it one any other
then the log server at my workplace, but now i think
software might be useful for others, too.
- speaking of linux sysklogd: That hack _still_ loses if
syslogd is restarted. I sent a fix for that to the
/ maintainers in 1996 and 1998. See
this patch. Shall i be amused?
- lrzsz v1: i'm tempted to remove all traced of
from lrzsz. gettext _still_ is at version 0.10.35,
and still throws
out that annoying warning that messages must not
\r (which is wrong, btw). I would also get rid of
a number of bugs in Makefile.in.in, of which the
usage or not-usage of DESTDIR is the most annoying.
building the package on a machine without GNU make
will then be possible.
No, i'm not volunteering to maintain gettext.
Schedule: Still undecided.
- in case you wonder: my personal build environment
disencourages warnings. It's quite annoying to get them
twice a day.
- lrzsz v2: Will possibly finish writing X/Ymodem
sender and receiver tools this year. I'm not happy
the sender state machine now, it works, but it looks
This needs more thinking.
The Zmodem state machine will get even more ugly. I
to re-read a few descriptions of the protocol first.
- watchdog: the watchdog software the company uses now
could benefit from a cleanup. It now runs for more
months, and all the problems with the design should
shown up by now. Actually quite a number did show up,
and the ad-hoc changes not only made the code messy,
but desynchronized code and documentation.
Schedule: This year.
Mostly easy stuff, but the scheduler ... at the
interval of 300 seconds is fixed. I should get rid of
for cleanness sake. Oh, and i need to convince the
to release it under GPL. Should be easy.
support discontinued. I don't use it anymore.
i will implement some kind of "move" functionality -
ftpcopy ftp://re.mo.te/ ./re.mo.te/
Not using -print0 is also possible. Files with \n inside
the file name are then just not deleted. (i suspect that
are impossible to download anyway).
(cd re.mo.te ; find . -type f -print0) | xargs -0
Netscape eats an astonishing amount of memory now. Oh, well.
Maybe i should start to post with some other tool.