[rfk-dev] possible enhancements

leonardr at linux.ucla.edu leonardr at linux.ucla.edu
Thu May 13 17:02:40 CDT 2004

> 2) NKIs should be seperated from the binary and kept somewhere like
> /usr/local/share/rfk/nki/.  Furthermore, it should be possible to have
> multiple NKI files.

I agree. I would also love to be able to load NKIs from a URL. I wouldn't
want to write that C code, though. Sometimes I toy with the idea of
writing a Python RFK that's easier to hack.
> 3) What does the version number reflect?

It has no meaning; it was a parody of the idea of version numbers in
general. The subversion number is obviously the number of NKIs, but in a
world where NKIs don't live in the binary and every possible string is a
potential NKI, it should be removed, or set to aleph-null or n or oo or
Ax(NKI(x)) or something.

Another possibility (I don't remember) is that the version number is so
high because I intended for the version number to run *backward*, each new
release having a lower version number and a higher subversion number,
until version 0.oo was reached. That would be would be the perfect
version, and at that point the software would achieve enlightenment.

It's a tub of chitin chitlins.

More information about the rfk-dev mailing list