Older blog entries for uweo (starting at number 14)

fefe: of course size is important.

It's now three weeks without gas heating and water in my rooms (in all my rooms, though - i originally hoped to have water in the bath room).

Life is complicated.
Nothing happened on any free software project for quite a long time, until yesterday at least. It took some time to recover from that security hole: I was so sure that "too much trust" can't happen to me. The lesson hit me hard.

I actually learned something from it, and did some changes to the design of the whois server i started to write this week. Well, minor changes, fortunately.
Regarding whois server: the beast will possibly end up as GPL - $boss mentioned this (why he did it is a different story). Even after one week i still believe that the design is right, and apart from a few compatibility hacks to allow it to be used as a drop-in replacement at [unnamed COM-NET-ORG registrar] it will be quite nice (and even these hacks may be turned of).
I'd love to use a template system for the output, but that will not work out, too many things depend on the content of a record (at least that's the unfortunate situation at the registrar). I'm still undecided whether i'll include script language code in the output template, or create the complete output using a script language. [i tend to do the later, i don't need to parse templates that way].

Aside from that: I'm still living inside a building yard. The gas heating has been removed, and it will take 10 further days until the new one is installed (and even then things will get "funny": a low temperature boiler will then feed old time radiators). Right now it's somewhat cold in my rooms ...
Things will get worse: i'll not have water in the kitchen any longer. It will pay out in the long run, though.

A totally unrelated question: a friend of mine want's to install a VPN to my site. Nice idea, but i've a strong feeling that PPP over SSH isn't really a bright idea (my understand of TCP congestion control is that it isn't meant to be used over another congestion controlled media). He thinks it works, i think it _can't_ work with a loaded low-bandwidth link. Who is right, or where can i read more?

spot: please don't mention the daemons of /. I'd hate to see them getting busy here.

Released ftpcopy-0.3.3.

When i wrote the program i thought something like "why bother? It's me own FTP server anyway": I wrote the program to automatically copy files between 2 servers. When i re-read the code i thought the same. Later i decided to use it to mirror other servers, too, and even later i decided to make the code available to others ...
When i read about the scp security hole on bugtraq i suddenly *knew* where to look into.

The lesson? Don't allow bad code to exist, even for internal use.

The good news: My caffeine addiction seems to wear off. I was really, really tired on saturday and sunday, but i'm beginning to feel better again. No coke, no tea for almost 100 hours ...
I didn't get a caffeine addiction for three years, up to 2000-07. But then the stress level increased drastically, and i, once again, was stupid enough to let work get too much influence on my life.

The bad news: i detected a security problem in ftpcopy. No buffer overrun, no printf/syslog hole: "too much trust in the FTP server". Damned.

The telekom installed the TAE for the DSL line on monday. Today QSC installed the DSL pipeline. It even worked ... 144kbit isn't bad.
The provider didn't get the hint on the IP address application (n IP address _plus_ firewall, so an additional /30 or a DSL pipe in bridge mode would have been perfect), but proxy arp is fine for this situation, so i went that way.

Changing the IP addresses of five machines was an interesting experience. If my customers told me that changing IP addresses is beyond them for some reason or couldn't be finished in the next few months ... in short, i really didn't believe them. Now it do.
Change IP addresses. Change main filter. Change DNS server address. Change multiple application and server configurations. Change multiple access lists (host.allow, tcpservers configuration). Tell the outside world about the change. Fix multiple access lists there. Fix a number of ssh configurations or authorized_keys since the reverse mapping is not working now. Detected an overly long /etc/hosts on one machine. It's quite late now.
I still have to move my brothers machine to the new address, but that can wait until he notices that something is broken.

Anyway, i'm quite happy about that. Seing that the telekom get's something right at the first time is delightful.

On the free software front not much has happened. I finished the basic design of the trouble ticket system. The only thing i left out was indexing - i'll first look at which kind of queries will be needed and then decide how to do that. Actually, this thing begins to interest me, and so the coding was quite easy (still unfinished).

The patch is now where it should have been: klogd_lose.patch.
Sorry.

I looked at a number of trouble ticket and bug tracking systems in the last two days. To put it mildly: they all lack.
I'm astonished that the majority of them, especially the newer ones, are web-based. Hey, people, get a clue:

• discussions with clients is best done through email.
• email has lower turnaround times.
• if done correctly email is more secure, especially if you don't use passwords. [use a one-time key for each trouble ticket, and let the customer decide with whom he wants to share this]. This obviously isn't that important in for open source bug tracking.

Well, maybe it's just me, but i don't want to use a web browser to update the state of a ticket after i resolved the thing together with the customer. I just want to set the state to resolved in the last mail i send.
Apart from that email is just more easy - to use and to program processors for.

And all i've seen seem to be a bit unflexible. I'm not going to introduce different task-systems for company hotline (non-software customers), software customer support and developers internal stuff. My cow-orkers would kill me before i finish the sentence, i think.
In other words: the basic design has to be very, very simple, but extensible.

There is nothing wrong with having a web interface (aside from 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 interface, but you can create some kind of web interface for almost everything without too much work.

I also went through my personal todo list:

1. BBS software: decided to not work on it anymore. Not even bug fixing. It's not something i want to continue working on. I wouldn't design it like this, and the basic design is from 1988 or so (and the UI is even older). Period.
2. 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 i didn't have in 1993, and they _will_ make the thing more beautiful. But the change is quite fundamental, and anyway, the best way to get rid of bloat and historical workaround in code is to rewrite it.
   Schedule: don't know.
3. utftpd: i'll rewrite it. The configuration file language is fine, except there shouldn't be a configuration file language at all. Yeah, it's highly flexible. And this is not needed.
   I'll keep the one client, one TFTP server process design for now, but will cleanup the server if i happen to find something which wouldn't work in a single server design. I'm still unsure whether multicast TFTP is useful. Mind you, utftpd has been written to backup my router configuration files.
   Schedule: This year.
4. udpserver: decided to finish it. I need something like this to start the TFTP server.
   Schedule: Soon.
5. syslog server: decided to finsish it. I do not really need it, (except that linux sysklogd is horrible), but a clean and reliable implementation of a syslog daemon which doesn't fill the disk is worthwhile. [takes and translates network 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 machine then the log server at my workplace, but now i think this software might be useful for others, too.
   • speaking of linux sysklogd: That hack _still_ loses if the syslogd is restarted. I sent a fix for that to the authors / maintainers in 1996 and 1998. See this patch. Shall i be amused?
6. lrzsz v1: i'm tempted to remove all traced of internationaliation from lrzsz. gettext _still_ is at version 0.10.35, and still throws out that annoying warning that messages must not contain \r (which is wrong, btw). I would also get rid of a number of bugs in Makefile.in.in, of which the wrong usage or not-usage of DESTDIR is the most annoying. And 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 mailed twice a day.

7. lrzsz v2: Will possibly finish writing X/Ymodem sender and receiver tools this year. I'm not happy about the sender state machine now, it works, but it looks ugly. This needs more thinking.
   The Zmodem state machine will get even more ugly. I need to re-read a few descriptions of the protocol first.
8. watchdog: the watchdog software the company uses now could benefit from a cleanup. It now runs for more than 6 months, and all the problems with the design should have 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 moment the interval of 300 seconds is fixed. I should get rid of this, for cleanness sake. Oh, and i need to convince the boss to release it under GPL. Should be easy.
9. conflib:
   support discontinued. I don't use it anymore.
10. ftpcopy:
    i will implement some kind of "move" functionality -

           ftpcopy ftp://re.mo.te/ ./re.mo.te/
    
           (cd re.mo.te ; find . -type f -print0) | xargs -0
    
    
               ftpdelete ftp://re.mo.te/ 
    

    Not using -print0 is also possible. Files with \n inside the file name are then just not deleted. (i suspect that the are impossible to download anyway).

Netscape eats an astonishing amount of memory now. Oh, well. Maybe i should start to post with some other tool.

• What a week. Bug hunting continued. I'm used to read sources with difficult identation, but ... let's say it politely: one of my cow-orkers has a strange, very strange, way to indent his perl code. And a habit to let variable names and comments get out of sync with the code. Together with hurry, haste and brokenness (sp?) it may be the most difficult code i've read in the last 20 months.
  And database triggers are, well, somewhat counterintuitive.

  1. update table where key = x;
  2. if (ok)
  3.   delete from table where key = x;
  

  Bug? No, delete-trigger. No single word about it in the code, of course. Ugh.

• I didn't try to do much coding outside work. I'm feeling somewhat tired ... burned out? May be.
  
  1. finally updated the getopt clones documentation.
  2. updated ftpcopy to use the lastest strhash.
  3. added a missing \n in the ftpcopy logging output. It's one of those things which could have been easiely catched by a test suite.
  4. ^z or any other interrupting signal was handled as timeout.

• <rant>
  Why can't linux distributors, debian and *bsd maintainers send the patches they apply to the packages back to the author? Is it really so much fun to apply and fix the same patch to 5 revisions of the software? Or is maintaining paid or honored by the number of patches applied?
  </rant>
  

• LC_ALL=fi_FI logger test
  LC_ALL=C logger test2
  tail /var/log/messages
  Please ... someone please spend a cluon on whoever did that.

aaronl: Is it just bad mood or are you trying to discredit yourself totally? Technically you are right, but your behaviour ...

itp: I think you'll be surprised by the number of people who neither use or like GNOME (or KDE). Not everybody needs the value added by those toolkits.

mjs: You forgot to take some things into account, too. A better procedure may be to:

1. reboot.
2. make sure all libraries you can reasonably expect to be loaded _are_ loaded and used in a typical way.
3. free >>record
4. run the program / toolkit
5. free ...
   The difference between the last and this output usually is somewhat higher than the "real" memory usage of the program / toolkit and includes fragmentation and caching inside other services.
6. run the program / toolkit again.
7. free ...
   If the difference is about the same than step 2 was well done (it usually isn't).
8. repeat the last two steps until the result get's stable.
9. repeat the whole process a few times (including reboot, of course). Omit step 2 at least once.

This way you catch memory fragmentation (X server, window manager, kernel) and caching (x font server, x server, DNS caches, whatever).
Interpretation of the results is another story. Reducing them to a single number is useless or a lie in many cases.

Finished the xmodem sending. It works. It actually is even a little bit faster than lsx from the lrzsz suite. Why? I didn't think about performance ...
Error handling is quite simple: count the number of errors per block. If it reaches a fixed number then abort. Good enough? At least not worse than lsx.
Thought about doing a fallback from 1024 to 128 just a little bit too late. Well, no other xmodem implementation i'm aware of can do it, too, but that is no excuse. I feel a bit stupid. But on the other hand: it's a prototype, and if there is a reason to prototype something then it's to show stupidities early, right?

• No, i do not believe in rapid prototyping for low to medium sized software. Actually i do not believe in rapid prototyping at all. Prototypes are useful, especially in major projects, where one want's to get things into a somehow useful state very early. But rapid prototyping?
  People should think, especially about the major design decisions. User interfaces, the most prominent victims of rapid prototyping, are major design decisions. Rapid thinking is a contradiction in terms.
  I also think that rapid prototyping often leads to omitting testing of the modules. The desire to put things together early and see whether it fits seems to be very strong, stronger than that of testing for correctness.
  </rant>

Speaking about xmodem: Now, some hours later, i still don't understand why the fallback isn't implemented in any xmodem sending software i know. There are still devices left which don't accept more than 128 bytes per block, and a fallback mechanism would get rid of that interoperability problem. There has to be a drawback?

Anyway, it's time to stop dealing with computers for today.