Future Plans

PIKT could use a GUI, not so much to overlay piktc management as to handle incoming alert messages. This could take form as, for example, a Tk/Tcl or Java front-end acting on syslog messages sent to the console machine.

Although there are methods to program against endlessly repeating nuisance messages (so-called "nagmail"), PIKT would benefit from more automated ways to do this. Message routing could also be improved.

PIKT has a steep learning curve, and setup can be daunting. A project is underway to put together a PIKT "standard library" of ready-to-run defines, macros, alerts, scripts, programs, and objects sets. We need to improve the user's "out-of-the-box" experience.

The weakest link in PIKT's chain is the script interpreter, pikt. Although it gets the job done, it is not fast or feature-complete. Pikt is not a stand-alone, all-purpose scripting language, and you cannot effectively call Pikt scripts from programs written in other scripting languages. Pikt was designed to aid in systems administration and to run "fast enough" in a small memory space within the broader PIKT system. Plans are to rewrite Pikt's underlying engine, perhaps using GNU Guile or embedded Perl.

PIKT requires a thorough security audit, and its client-server communications need to be made iron-clad secure. Adding encryption and Kerberos authentication is under consideration. We also plan to implement a comprehensive security package of PIKT defines, macros, scripts, and objects sets to work alone or in concert with other security products.

PIKT has an Introduction and comprehensive Reference Manual but lacks a Getting Started guide, also an Operations Manual.

1st page